Re: cu/screen non-functional on 115200 (9600 ok)

[Crystal Kolipe]

On Fri, Jan 07, 2022 at 06:31:38PM +, Laura Smith wrote:
> > Is there any hardware handshaking on this serial connection?
> 
> Not AFAIK, vendor spec for connection is "serial port settings are 115200, 8 
> data bits, and no parity"
> I'm using a good old "Cisco-style" cable (serial at one end, RJ45 at the 
> other)

It probably does have hardware handshaking then, which is a good thing.

> Not AFAIK. I had vendor support guy on the line and I was screensharing. His 
> expectation was everything should be at 115200.

What serial interface are you using on the OpenBSD machine?  Is it a puc device 
by any chance?  It's possible that the serial port on your OpenBSD machine is 
actually running at 115200, even though you have it set to 9600.

I'm also wondering if it's possible that when the switch is reset, the serial 
line is going low for long enough to be recognised as a break and confusing 
misbehaviour that way.

Re: cu/screen non-functional on 115200 (9600 ok)

[Crystal Kolipe]

On Fri, Jan 07, 2022 at 06:01:39PM +, Laura Smith wrote:
> Hi
> 
> I'm having a really weird experience on a 6.9 box trying to connect to a 
> switch serial console.
> 
> If I run "cu -r" then I can see the switch (when the switch is running its 
> fine, I can interact with the CLI, but if the switch reboots, I just get 
> random characters)

So is it just during the boot sequence that you get noise, and then at some 
point you can access it again at 9600, or does rebooting it make it impossible 
to access again until you restart cu?

Is there any hardware handshaking on this serial connection?

Is the line noise actually always random characters or mostly ÿÿÿ ?

It sounds like the switch is simply using one baud rate during boot, and 
switching to 9600 afterwards.

However, I have noticed when using cu on a 115200 baud link with no 
handshaking, that when sending more than about 2 or 3 kilobytes of text 
continuously at maximum speed, (using the local ~> escape), that the cu session 
can freeze and only be recovered by exiting and restarting cu.  I also saw a 
kernel panic on one occasion, but was unable to reproduce it.

I had assumed that this was a bug in the USB serial driver, but I haven't 
investigated it further and it may be something else.