How to get a serial console on a device that won’t let you in

Most managed network hardware has a port that does not care about IP addresses, VLANs, firmware state, or whether the device has finished booting. It has no link light and cannot be firewalled off. That is the console port, and when a switch is stuck in a boot loop or a firewall has a password nobody wrote down, it is the only way in. The awkward part is never the typing — it is the cable, the driver and the baud rate before the first character appears.

Connector

RJ-45, USB mini-B, USB-C or micro-USB

Cable

Rollover for RJ-45; a data USB lead otherwise

First guess

9600 baud, 8N1, flow control none

Second guess

115200 baud, same frame

Appears as

COM3 / /dev/cu.usbserial-* / /dev/ttyUSB0

What the port actually does

Underneath, it is an asynchronous serial line, usually RS-232: no addressing, no negotiation, no concept of a link being up. Two wires carry data in opposite directions, a third is common ground, and whatever the device decides to print, it prints. That primitiveness is the point — the console is wired to the device’s first UART, which the bootloader claims before any operating system loads, so you see ROM monitor output, memory tests and kernel panics well before there is a network stack to SSH into. It is also why it keeps working when the management VLAN is wrong or the config has been wiped.

Finding it on the hardware

On rack gear the port is labelled CONSOLE or CON and sits slightly apart from the Ethernet ports, often behind a differently coloured bezel — Cisco has used light blue for decades. It usually lives on the management side of the chassis next to the out-of-band Ethernet port, which is the one thing you can genuinely confuse it with.

On smaller devices it is a USB socket, and the confusion is worse: plenty of access points put a micro-USB console next to a micro-USB power input, with nothing but a silkscreen label between them. Look before you plug.

Consumer routers and cheap switches often have a console too, but unpopulated — four holes marked GND, TX, RX and VCC. Those are 3.3 V TTL headers, not RS-232, and a real RS-232 driver swings ±3 to ±15 V, so connecting one does not misbehave, it destroys the pin. That job needs a TTL-level adapter and a soldering iron.

Rollover cables, and the three USB generations

Cisco fixed the RJ-45 console pinout in the 1990s — pin 1 RTS, pin 2 DTR, pin 3 TxD, pins 4 and 5 ground, pin 6 RxD, pin 7 DSR, pin 8 CTS — and the rest of the industry copied it rather than fight it. Both the device and your adapter are wired as DTE, so both try to transmit on pin 3. Something has to cross them over, and that something is the rollover cable: all eight conductors reversed end to end, pin 1 to pin 8, pin 2 to pin 7, and so on.

Nobody buys a bare rollover cable and a DB9 adapter any more; what you buy is a USB-to-RJ45 console cable with the serial chip moulded into the USB plug. USB mini-B consoles came next — an ordinary A-to-mini-B lead with no special wiring, but the serial chip has moved inside the device rather than the cable, which changes the driver question entirely. USB-C is the current generation, on recent HPE Aruba CX and Catalyst 9000 hardware among others.

Which chip you have, and what it wants

Four families of bridge chip account for nearly everything on the market, plus Cisco’s own silicon. They behave identically once they work, and differ entirely in how they get there.

To identify yours: Device Manager on Windows (right-click, Properties, Details, Hardware Ids), lsusb on Linux, system_profiler SPUSBDataType on macOS. USBVID_05A6&PID_0009 with a yellow triangle is a Cisco console port waiting for Cisco’s driver package, downloadable only while signed in. That same port catches people out on Linux for the opposite reason: it binds cdc_acm rather than a USB-serial driver, so it appears as /dev/ttyACM0, not ttyUSB0. If you are hunting for a ttyUSB node that never turns up, that is why.

Prolific deserves a specific warning. The PL2303TA and PL2303HXA revisions are end-of-life, and current Prolific drivers deliberately refuse to start them: Windows reports Code 10, the hardware is fine, and there is nothing to troubleshoot. The old signed driver works, but Windows Update tends to put the new one back on the next cumulative patch. Counterfeit FTDI chips are the same story from the other direction — FTDI’s driver has historically detected and refused to drive them. Buy genuine FTDI or Silicon Labs silicon and neither problem exists.

Linux needs no installation at all — ftdi_sio, cp210x, pl2303 and ch341 all ship with the kernel. It has one notorious booby trap instead. The brltty braille-display daemon carries udev rules matching 10c4:ea60 and 1a86:7523, so on Ubuntu and its derivatives it claims your adapter and immediately disconnects it. The symptom is a /dev/ttyUSB0 that appears and vanishes within a second:

usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1

If you do not use a braille display, remove the package. macOS has the mirror-image trap: it ships its own CH34x driver, AppleUSBCHCOM, and installing WCH’s on top produces two serial devices for one adapter, neither working properly. If a CH340 cable behaves oddly on a Mac, look for a third-party driver someone installed years ago.

8N1, and why 9600 is the safe first guess

Serial links have no clock line, so both ends agree in advance how fast to sample the wire and how the bits are arranged. “9600 8N1” is that agreement: 9600 bits per second, eight data bits per character, no parity bit, one stop bit. The rate applies only to the serial segment beyond the bridge chip — the USB side runs at USB speed and knows nothing about it, which is why Windows offering you COM3 proves the bridge chip is alive and nothing else. Not the cable, not the port, not the far end.

9600 is the right first guess because it is what most vendors still ship, and because it is slow enough to survive a marginal cable. Set flow control to none. This matters more than it sounds: many console cables carry only TxD, RxD and ground, so if you select RTS/CTS the far end never asserts CTS and your terminal refuses to send anything. Output arrives perfectly, keystrokes vanish, and it looks exactly like a dead keyboard.

These are defaults, not laws. Anyone can change the speed — line con 0 then speed 115200 on IOS — and on a second-hand device somebody probably did.

Opening a terminal

On Windows, PuTTY is still the standard. Find the port in Device Manager under Ports (COM & LPT), or run [System.IO.Ports.SerialPort]::GetPortNames() in PowerShell. Pick Serial, set Speed, and check that Connection → Serial shows 8 data bits, 1 stop bit, no parity, flow control None. From a shortcut it fits on one line:

putty -serial COM3 -sercfg 9600,8,n,1,N

Tera Term does the same job and handles logging better. Windows Terminal has no serial support at all.

On macOS, list the devices and attach with screen:

$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port    /dev/cu.usbserial-AB0KX1QZ
$ screen /dev/cu.usbserial-AB0KX1QZ 9600

Use the cu. node, never the matching tty. one: the tty. device blocks on carrier detect, which a console cable never asserts, so opening it simply hangs. Kill the session with Ctrl-A then K — closing the window leaves it running and the port locked. screen -ls shows it, screen -X -S <id> quit clears it.

On Linux, watch the kernel log while you plug the cable in. It gives you the chip and the device name in one go:

$ sudo dmesg -w
usb 1-2: New USB device found, idVendor=0403, idProduct=6001
usb 1-2: Product: FT232R USB UART
ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

Then screen /dev/ttyUSB0 9600, picocom -b 9600 /dev/ttyUSB0 or minicom -D /dev/ttyUSB0 -b 9600. “Permission denied” means the wrong group — dialout on Debian and Ubuntu, uucp on Arch and Fedora. Run sudo usermod -aG dialout $USER, then log out and back in, because a new shell is not enough. With two adapters plugged in the ttyUSB0 and ttyUSB1 names can swap on reboot; ls -l /dev/serial/by-id/ gives stable names tied to each chip’s serial number.

Nothing appears

The usual first experience is a black window and no feedback of any kind, because a serial port cannot tell you it is wrong. Work through it in this order.

1. Press Enter twice. Plenty of devices print nothing until they receive a character. A blank screen on a healthy console is normal.
2. Power-cycle the device and watch. The most informative test there is. If boot text appears, cable, port and baud rate are all correct, and the problem is on the transmit side — almost always flow control, or the Cisco USB precedence above.
3. Check you are on the right port. Unplug the adapter and watch the COM list, /dev/cu.* or dmesg. Whichever entry disappears is yours.
4. Make sure nothing else holds it. A forgotten PuTTY window or a detached screen session holds the port open and locks everyone else out silently.
5. Suspect the USB cable. Charge-only leads carry no data conductors. If the adapter never enumerates, swap the lead first.
6. Confirm the RJ-45 lead is a rollover. Hold both ends side by side, latches the same way. On a rollover the colour order is exactly reversed; on a patch lead it is identical.
7. Set flow control to none. If output flows but typing does nothing, this is the answer far more often than a broken keyboard.
8. Try the other speed. Rubbish on screen means the framing is wrong, which is good news — it proves the wiring works. Step through 115200, 57600, 38400, 19200, 9600.

Wrong baud looks like this, and it is unmistakable once you have seen it:

Expected:   Switch con0 is now available
            Press RETURN to get started.

Wrong rate: @~oK|?~3o@~?K|o~@?3|K~o@?

A bootloader often uses a fixed factory speed even when the running configuration has changed the speed the OS uses. If boot messages are readable and the login prompt is garbage, the config changed the rate mid-boot, and the config’s rate is the one you need.

What the console gets you

The obvious win is a command prompt on a device with no usable IP address, which is also the fastest way to find a device that has fallen off the network entirely. The bigger win is everything that happens before the prompt.

Because the console is live from power-on, it is where every vendor’s password recovery begins. Interrupt the boot and you land in the bootloader, where the configuration file has not been read yet and the password in it does not apply. On Cisco that means sending a break within about sixty seconds of power-on to reach rommon, then setting the configuration register to 0x2142 so the startup config is skipped on the next boot. On Junos, press the space bar at the loader countdown and boot single-user with boot -s. The recovery ladder covers the rest in order of how much you stand to lose, and the managed switch procedure has the model-by-model detail.

Sending a break is its own small skill, because it is not a character — it is the line held low for longer than one frame, which no keystroke produces. In PuTTY, right-click the title bar and choose Special Command → Break. In screen, Ctrl-A then Ctrl-B. In minicom, Ctrl-A then F. Macs have no Break key at all, which is why people give up on the ROMMON break far too early.

If the device has simply been reset and you only need the factory credentials, the A–Z defaults index is quicker than any of this, and the Cisco defaults page covers the usual combinations before you reach for a cable.