Trouble using Break Key sequence to access ROMmon on a Cisco Router

[boclay]

Use Space Bar to simulate Break Key Sequence

Read this article if you are trying to generate a Break Key Sequence to access ROMmon, and the Break Key sequence does NOT seem to make it to the router.

Today, I needed to access ROMmon on an IR1101 Industrial Router for password recovery. Unfortunately, the Break Key sequence was NOT making it to the router. I know the Break-Key sequence (Ctrl-Fn-B or Fn-B) on my Lenovo laptop works because I used it recently to break into a different router. That router has an RJ45 console port. The IR1101 has a USB mini console port, so my Lenovo laptop was using a different serial port driver when connecting to the IR1101.

The work-around was to “simulate” a Break Key by changing the baud rate of my connection in Putty to 1200 and pressing the space bar. I found this information in a very old post where the author mentions HyperTerm and using a PS/2 (Does anyone else besides me remember the PS/2?)

Here are the steps:
Complete these steps to simulate a break key sequence:

    Connect to the router with these terminal settings:

    1200 baud rate
    No parity
    8 data bits
    1 stop bit
    No flow control

    You no longer see any output on your screen, and this is normal.

    Power cycle (switch off and then on) the router and press the SPACEBAR for 10-15 seconds in order to generate a signal similar to the break sequence.

    Disconnect your terminal, and reconnect with a 9600 baud rate. You enter the ROM Monitor mode.

  

[Richard Burts]

Thanks for posting your experience with this. I have posted suggestions about this approach using baud of 300. Interesting that 1200 also works. I guess the main thing is the terminal emulator needs to transmit enough slower than what the device is expecting that the device treats it as a break signal.

[sdino]

Hi @Richard Burts @ @boclay,

Tried to use the following baud rate speed to prompt to ROMMON but seems not working.

• Baud rate speed: 300 or 1200 or 9600
• Data bits: 8
• Stop bits: 1
• Parity: None
• Flow Control: XON/XOFF or None

Normal Putty the works.

• Baud rate speed: 115,200
• Data bits: 8
• Stop bits: 1
• Parity: None
• Flow Control: XON/XOFF or None

Thanks

[Richard Burts]

I am sorry that this approach is not working for you. The key to this is to generate a signal during the boot process at a very low baud rate. I have had success using 300. Others have reported that it worked at 1200. I can only say that the higher the baud rate the less likely it is to work.

I am not sure why it has not worked for you. Perhaps the 1100 does not support this, or perhaps SDWAN changes the processing.

[sdino]

Hi @boclay,

Appreciate Cisco VIP (Luny Celicourt) for sharing this link and special thanks to you for posting this blog. Basically, happily received from a friend 5 units of IRS 1100-4GLTEGB with Viptela SDWAN OS 19.2.1.

Tried to convert to IOS-XE from Viptela SDWAN OS but not able to be prompted to ROMMON even had tried your recommendations (Note: Wanted to be in ROMMON to boot using IOS-XE, following this port -> Solved: I stuck in ROMMON mode for ISR1100 4G router - Cisco Community).

Step 1: Putty settings to "1200-8-1-None-None".

Step 2: Then this is the screen output after rebooting the ISR 1100-4GLTEGB and press SPACEBAR for 10-15 seconds in order to generate a signal similar to the break sequence.

Step 3: Disconnect your terminal, and reconnect back local console with Putty settings at 115,200-8-1-None-None.

Step 4: Then this is the output - not to be prompted to ROMMON. Tried 3 times but the same.

Just want to know please if ISR 1100-4GLTEGB can be converted to IOS-XE OS.

Thanks

[Joseph W. Doherty]

Ah, very interesting; a technique I was unaware of.

From my browser's AI summary:

On some systems, a break signal can be generated by reducing the baud rate to 300 bps and pressing the space bar, which sends a continuous stream of low-level data that simulates a break.

My browser's AI summary also provides:

A system break signal is a special control signal used in serial communication, particularly defined by the RS-232 standard, where the data line is held in the "space" (low) state for a duration longer than a standard data character transmission. This duration is typically at least 100 milliseconds, which is longer than the time required to send a complete byte including start, data, parity, and stop bits. This extended space condition is distinguishable from normal data and can trigger specific actions on the receiving end, such as interrupting a process or initiating a system reset.

In the above, mention is made of pressing the space bar key, which is actually a good choice, on par, perhaps, with using capital "A", but perhaps even better might be using the character "@".

The reason for selecting the forgoing (printable) ASCII characters, each has a long run of continuous zeros in their byte, which would best mimic a break signal.  I.e.:

" " = 0010 0000 - 5 zeros

"A" = 0100 0001 - 5 zeros

"@" = 0100 0000 - 6 zeros

Oh, as to what bps setting you need, in the above, if a break signal needs to be longer than a "standard" data character transmission, if receiving device is set for 9600 bps, and using the common start bit, 8 data bits, and one stop bit (10 bits), 1 character would be bps divided by 10, so we need a "fake" break signal rate about 10x slower, i.e. 960 bps.  Further, if we only have 5 continuous zero bits, we need to half the rate again, i.e. 480 bps.  If so, 300 bps would seem a better choice than 1200.

[sdino]

Hi @Joseph W. Doherty,

Appreciate to repy here, tried this recommendation but the same boot up outcome.

Thanks

[Joseph W. Doherty]

---

@sdino wrote:

Hi @Joseph W. Doherty,

Appreciate to repy here, tried this recommendation but the same boot up outcome.

---

I would have expected some "gibberish" if running different from the expect bps rate.

[Richard Burts]

It is difficult to tell from the posted output the details of what procedure you used. So let me ask did you:

- set baud rate on your terminal emulator to 300.

- power down.

- power up and immediately press and hold the enter key.

- keep the enter key pressed for at least 30 seconds or until you see activity in the terminal emulator.

- set the baud rate in your terminal emulator back to its normal value.

- attempt to connect to the console.

[Joseph W. Doherty]

---

@Richard Burts wrote:

- power up and immediately press and hold the enter key.

- keep the enter key pressed for at least 30 seconds or until you see activity in the terminal emulator.

---

Again, possibly holding down the enter key isn't the best option, vs. space, "A" or "@".

[Richard Burts]

Joseph

Thank you for identifying a major blunder on my part. My brain was thinking space bar while my fingers typed enter key. 

[Joseph W. Doherty]

(Does anyone else besides me remember the PS/2?)

Laugh, I do.

I also remember the introduction of the original IBM PC, and many other micro computers before the PC (personally owning one before the PC, so for me, the PC was a yawn, but the first [40 or so pound?] "portable" [Compaq] was a surprise, as was the Sinclair).

[sdino]

Not sure @Joseph W. Doherty if using different laptop will going to work the break sequence. Thanks