Netgate 6100 serial console issues

[aszajlai]

I have been using a raspbian OS on a pi 3 or 4 as a backup server as well as a local host to get to the consoles of my FW to see stuff instead of dragging monitor, keyboards, laptops etc to the gear. I got the 6100 the other day and it wanted to get upgraded to 23.09, I think it came with 23.07 or .05 not 100%. I connect and do a screen -U /dev/ttyUSB0 115200 and get the following:

If I try to reduce the speed it get worse not better even if I match the speed, I've set on the fw. I have tried 57600, 38400. If I walk down and plug into the console with a laptop or plug into the PI the text renders. At this point I don't think it is a problem with the 23.09 as I first thought with the notes from the upgrade to 23.09.

[Gertjan]

@aszajlai said in Netgate 6100 serial console issues:

If I try to reduce the speed it get worse not better even if I match the speed

Using the console (option 8), the GUI (Diagnostics > Command prompt), or SSH (enable the access first under System > Advanced > Admin Access)

Type :

grep 'speed' /boot/loader.conf

and you'll see :

comconsole_speed="115200"

Also : The 6100 manual, start reading from page 45.

Selecting another speed on your side won't make things working better.
Its (it should be) 115200 bits/sec.
Keep in mind : RS232 or 'ancient' serial COM port access isn't auto sensing or something like that.

@aszajlai said in Netgate 6100 serial console issues:

instead of dragging monitor, keyboards, laptops etc to the gear

Just the laptop and the console cable that came with the 6100

Btw : the console access is a must have. But you only really need it if you want to (re) install a "firmware from USB drive". For all other access needs : activate the SSH (see above), get Putty, and you'll be fine.

[stephenw10]

That's not a baud rate problem. If that was mismatched you would see nothing but garbage characters.

What you see there is some other type of terminal mismatch. It seems to be misinterpreting the characters sent destroying the formatting.

[aszajlai]

Thank you both... I think I'm good, I'll see what the non-serial port gives me. Task for another day.

[jimp]

What you are seeing there is also a symptom of having multiple sessions connected to the same serial port. For example, maybe you still have an old screen session you detached from but didn't terminate and its getting half the serial I/O, and your current screen session is getting the other half.

Terminate your session (usually Ctrl-A, \) and then try screen -r and see if you end up reattached to another session. Or from a shell prompt, run screen -ls and see if there are multiple sessions hanging around. Resume them and terminate them as needed.

[aszajlai]

@jimp

That was the issue. I found a post that said to use ctl-a d (looking now that says to disconnect) not to kill the session like ctl-a \ does). Once I cleaned up all the screen connections, I was able to get in and have changed the way I connect and disconnect. Thank you very much!!!

:~# screen -ls
There are screens on:
2554.pts-0.computer (11/27/2023 07:35:26 AM) (Detached)
2552.pts-0.computer (11/27/2023 07:35:06 AM) (Detached)
2550.pts-0.computer (11/27/2023 07:34:38 AM) (Detached)
2547.pts-0.computer (11/27/2023 07:34:18 AM) (Detached)
2544.pts-0.computer (11/27/2023 07:33:41 AM) (Detached)
2514.pts-0.computer (11/27/2023 07:12:56 AM) (Detached)
2511.pts-0.computer (11/27/2023 07:12:27 AM) (Detached)
2508.pts-0.computer (11/27/2023 07:11:44 AM) (Detached)
1616.pts-1.computer (11/26/2023 08:11:02 PM) (Detached)
1612.pts-1.computer (11/26/2023 08:10:05 PM) (Detached)
10 Sockets in /run/screen/S-root.