Garbage output during boot menu via usb serial console on linux host

[journeyman]

I am using a generic cisco style USB to serial cable to gain console on a 60F. The host in a small raspberry pi. This works fine except when the FortiGate is rebooting. Between "Restarting System" and "System is starting..." the console reads garbage.

I have used both minicom and picocom. Basically they give different garbage, with picocom being more resilient.

It is particularly interesting that the problem is only for the duration of the boot loader output. Without interrupting the console connection it is working to begin with, then the FortiGate bootloader spits out garbage, and then once the OS itself starts the output is normal again. Which is a pity because that's the point of rebooting via console, we prefer to format our units and then TFTP our production OS onto a clean unit.

The idea behind a raspberry pi is a small unit we can ship around that provides both the tftp server and can easily handle multiple console cables (for initial build and working on clusters).

This tech tip describes the problem exactly (garbage output between good output either side), but the fixes aren't exactly applicable and don't discuss the root cause.

Does anyone know the cause of the problem, or a fix?

[AEK]

This happens with some FGT models when you use cable other than Fortinet's. Even Cisco cable can cause this garbage output.

Just use a Fortinet cable and it will be clean output.

[journeyman]

Thank you.

I did not even know there was a Fortinet USB console cable (we use 60 series hardware). I've purchased a couple of cables and waiting for them to arrive. Pondered asking our Account Manager but figured this was quicker.

While waiting I have done some testing, this may be interesting for others:

- the usb cables on site appear identical to a cable in the lab (same lsusb output on linux, same vendor ID and product ID, same ebay vendor). The only "difference" is the site cables are new and the lab cable is a few years old.

-lsusb output is "ID 1a86:7523 QinHeng Electronics CH340 serial converter"

- the raspberry pi on site and in the lab are both 2B. Their SD cards were cloned. But the pi on site has been updated to a newer kernel. So far this is the only observable difference between site hardware and the lab.

- the lab raspberry pi works perfectly with the generic USB x RJ45 console cable.

- the lab raspberry pi works perfectly with an old ftdi dual DB9M serial adapter and a genuine cisco DB9F x RJ45 serial cable.

- the lab raspberry pi needs a configuration change to work with an old ftdi dual DB9M serial adapter and a DIY 3-wire DB9F x RJ45 serial cable. Minicom defaults to hardware flow control which needs to be disabled via Ctrl A Z O > edit serial ports > F once this is done it works perfectly.

- the site raspberry pi does not change behaviour if hardware flow control is disabled (worth a try).

As of now, the raspberry pi OS appears to be the issue. As mentioned, waiting on Fortinet cables to arrive.

[journeyman]

TLDR: The FGT-60F console port behaves differently to FGT-60D and FGT-60E. It requires the Fortinet USB console cable instead of a Cisco generic USB console cable to access the boot menu whereas older hardware does not. Normal RS232 cables work with all hardware.

A few things have happened since my previous post, here is a summary.

- There was nothing wrong with the raspberry pi on site.

- The Cisco generic USB console cable works perfectly with FGT-60D and FGT-60E hardware (the gear we had in the lab). This was eventually tested with three raspberry pi builds (site, lab and a brand new build).

- The Cisco generic USB console cable works with the FGT-60F while FortiOS is up but output from the boot loader menu is garbled.

- The Fortinet USB console cable works* with the FGT-60F with the following observations:

- Using Linux / minicom / Fortinet console cable works with no modifications while FortiOS is up.

- However, only during the boot menu, the FGT-60F ignores keystrokes under  Linux / minicom / Fortinet USB console cable.

- The solution found was to disable hardware flow control within minicom ( Ctrl A > Z > O > edit serial ports > F > Exit.

For reference, the Cisco generic cable is detected by Linux as "ch341-uart" using a driver of the same name. The Fortinet cable is detected as "FTDI USB Serial Device converter" using driver ftdi-sio.

Note the above refers to USB console cables. Anything that presents a true RS232 port appears to always work correctly with a three wire DB9 x RJ45 console cable.

While on the subject of minicom, newer builds appear to limit the display window to 80 characters wide and truncate lines over that length.

From here for some reason launching minicom using `TERM=linux minicom[...]` allows the display to be resized above 80 wide. I have not yet found settings to adjust linewrapping behaviour.

I hope the above helps someone else.

[AEK]

Thanks for sharing, Journeman

I use kermit & putty under Linux and as far as I remember I never had such issue (with Fortinet cable).

[sw2090]

Don't Cisco have an incompatible Pinout? 

I used HP,DELL as well as FOrtinet Cables and I never had any garbage output with any FortiGate (and we have models from 40F up to 400F). 

The only Fortinet device that hit me with garbage was some FortiExtender but that was due to wrong speed settings on the serial connection :)

Sebastian

[journeyman]

The Fortigate RJ45 pinout is a subset of the Cisco RJ45 pinout. There are posts on this forum (admittedly from long ago) advising that the Cisco cable works fine (and this was my prior experience).

If the terminal emulator in use implements hardware flow control it will need to be disabled. This should be independent of the cable used.

I have no explanation for the behaviour observed - garbled output within the boot menu on a 60F - particularly since the Cisco cable works fine outside of that brief window.

But, kinda crucial if you want to format the firewall and load firmware from there as we do.

We've been deploying 60F for a while now but up until now console was Putty > Terminal server DB9 RS232 > 3 wire cable (not Cisco).

This behaviour was only discovered using a USB x RJ45 cable.The idea was a portable tftp server with console connectivity using a raspberry pi to build clusters from scratch remotely (mobile uplink, no internet) - and in the end we succeeded. We initially used Cisco cables because we had them and they should have worked.

RJ45 Pin	Fortigate	Cisco
1	-	CTS
2	-	DSR
3	RXD	RXD
4	-	GND
5	GND	GND
6	TXD	TXD
7	-	DTR
8	-	RTS