don at nz.net

Back in the dark days of dial-up and analogue leased lines, I ran across a problem.

I had a file I needed to email to my home box, and MIME wasn’t a thing yet, so I used “uuencode” (a predecessor to base64, converting binary data into text that could be contained in 7-bit printable ASCII characters) to make it suitable for email transmission it, and sent it to my home email address. And as the email was making its way to my home box, my modem reset.

The modem reconnected and it tried again. It reset again. And again. Commence debugging …

to cut a long story short, I discovered that the encoded text contained a line with the string “+++”, followed by the string “AT”, and later a “Z”.

For those fortunate enough never too had to deal with these horrid things…

Most modems used the “AT” command set. That is, a configuration, dial or answer command started with the letters “AT”, followed by a set of mostly single letter commands (occasionally with preceding punctuation to expand the number if commands available), each with an optional, typically numeric parameter. Here’s the set-up string for a CTL Comet-X MD1290 V.34 modem at one end of a leased line (spaces are for clarity, and are not necessary):

    AT E0 L0 &A1 \N4 &D0 &L2 &B1 *A1 +MS=11 S2=255 &W0

The functions of these commands was as follows:

• AT told the modem there was a command coming. (This sequence also told a modem what speed it was communicating at, and also the character length and parity.)
• E0 turned off command echo.
• L0 turned off the speaker.
• &A1 prevented any received data from aborting a the modem handshake.
• \N4 enabled V.42bis error correction and compression.
• &D0 prevented the modem from hanging up on loss of DTR (e.g. if the connected router restarted, was powered off, or disconnected).
• &L2 placed the modem in leased-line answer mode. (The modem at the other send would be set to originate mode, &L1.)
• &B1 enabled leased-line auto-connect modem, so that the modem would go off-hook and attempt to connect immediately after power-on or connection loss.
• *A1 forced the modem to remember what the serial bit rate was when configured, and set to that speed when a connection was established. (This command was actually my suggestion to the manufacturer.)
• +MS=11 forced the modem to the V.34 (33.6kbps) mode.
• S2=255 disabled the escape character.
• &W0 saved the configuration to profile 0 (the default).

This command set was based on one created for the Hayes Smartmodem in the early eighties. In addition to the “AT” commands, there was a mechanism to get the attention of the modem when it was online and not accepting “AT” commands. That mechanism was to send “pause+++pause“.

The “+” was the escape character; the pause was about one second of no transmission. This sequence couldn’t be generated in IP use, because packets are always going to have some data before and/or after the three escape characters. For leased lines, we’d figured that keeping the escape code active would be fine.

But now it seemed it was not fine.

I spoke to the modem manufacturer, and discovered that the modems did not honour the pauses either side of the “+++”, so that sequence in an actual data packet could put the modem into command mode – and a subsequent “AT” command could reset or even reconfigure the modem.

The issue was that the technique of having pauses either side of the escape sequence was patented (at least in the US) by Hayes Microcomputer Products, manufacturer of that original Smartmodem. The CTL modems avoided that patent simply by not honouring the pauses, and that way remained compatible with terminal emulators that, for example, hung up the modem by sending “pause+++pauseATH”. (“H” was the hang-up command.)

But that was obviously not necessary nor desirable for an always-on leased-line modem. Equally obviously, I needed to turn the escape code off on our leased-line modems. The command I needed to issue was:

    AT S2=255 &W0

Easy enough to do from the the end I had access to. But what about the remote ends of all those leased lines? Well, the problem was also the seed of its own solution. The whole problem was that the modem would go into command mode if it received a “+++”. So … let’s do just that. I needed to send, in ASCII and hexadecimal:

    ASCII:  +  +  +  A  T  S  2  =  2  5  5  &  W  0  O  CR
    Hex:    2b 2b 2b 41 54 53 32 3d 32 35 35 26 57 30 4f 0d

That is: get into command mode (“+++”); start a command string (“AT”); disable the escape character (“S2=255”); save the updated configuration (“&W0”); and place the modem back online, exiting from command mode (“O”).

The command to do that was this (or something a lot like it – this was over three decades ago):

    ping -c 1 -s 24 -p 2b2b2b415453323d3235352657304f0d remote-router-IP-address

This command would send a single ICMP echo (ping) packet, with 24 bytes of ICMP payload, including ping’s normal 8 bytes of timestamp (for round-trip-time calculation), plus the 16 bytes of extra payload. The “-p” parameter, specifying the pattern to fill the packet from the end of the timestamp to the end of the packet, contains the escape sequence and command above, without the spaces, and terminated with a carriage return. In hexadecimal. The length needs to be specified to prevent repeats of the fill pattern.

I’d issue that command three times. The first would put the outbound modem (near end) into command mode, disable the escape character, save the configuration and put the modem back online. Since much of the packet was “eaten” by the modem, the packet would be lost.

The second ping would pass through the now-reconfigured near-end modem, be reflected by the remote router (as an ICMP echo reply), and be received by the remote modem, which would process the command, again losing the packet.

The third ping would pass through both modems unmolested, and arrive back at the sender, confirming that the fix had succeeded.