That's funny. I clicked on the HN article on the home page about the AT Protocol[1] expecting an article on the Hayse set. And then I scrolled down and saw this article.
> Modem vendors continue to build on AT. If you look at LTE modems made for IoT applications, for example, it's common for them to provide a complete HTTP implementation (and sometimes MQTT, and sometimes some kind of proprietary message broker protocol) accessible via AT commands. That means you can implement an IoT device without a network stack at all, deferring all network operations to the modem itself. With a JSON-over-HTTP backend, for example, you might send AT commands with JSON payloads over the serial control channel and then get JSON back. You never interact with the network at all, the modem is a completely self-contained system. At the extreme, you might implement your entire device using exclusively the modem. This is a common approach for telematics devices like GPS trackers: they consist of nothing but a cellular modem, the telemetry application is built for the modem using an SDK from its vendor, and you interact with it using AT commands. IoT-class modems frequently provide GPIO and user flash for just this purpose.
> This had a major denial of service security implication in that it would lead to the modem hanging up the connection should the computer ever try to transmit the byte sequence +++ATH0 in data mode.
Does this mean you couldn't send the documentation for the modem using the modem?
as do virtually all LTE-M (etc) cellular modules. I still have to maintain several model and even firmware specific AT command lists for several modules to work correctly :( (shakes fist at sierra wireless)
> M0 or M Speaker Mute, completely silent during dialing M3 is also common, but different on many brands
As a teenager with my first modem (I think I started with a 14.4, so not that early) I had no idea how to mute the modem with those commands yet while connecting to BBSes.
So I created my own "mute" (for during connection negociation at the beginning of a call, the modems were extremely noisy) system...
Late at night, when my parents were asleep, I'd unscrew the cover of the modem, take the PCB out and muffle it between two pillows while the connection was establishing.
Worked flawlessly.
As I was both up to no good and because I didn't want risking shorting the PCB, I'd then put the cover back on. Rinse and repeat every night.
That's funny. I clicked on the HN article on the home page about the AT Protocol[1] expecting an article on the Hayse set. And then I scrolled down and saw this article.
[1] https://news.ycombinator.com/item?id=49527123
My first job in IT was at AOL tech support and we could rattle off modem strings from memory :-)
I still think to Hayes AT commands almost every time I see an article about the AT protocol, thinking "who is still using analog phone modems"?
They're still used today for cellular modems
Yep. And not your grandpa's AT command set - it's been extended to support HTTP.
https://computer.rip/2026-04-26-voice-modems.html
> Modem vendors continue to build on AT. If you look at LTE modems made for IoT applications, for example, it's common for them to provide a complete HTTP implementation (and sometimes MQTT, and sometimes some kind of proprietary message broker protocol) accessible via AT commands. That means you can implement an IoT device without a network stack at all, deferring all network operations to the modem itself. With a JSON-over-HTTP backend, for example, you might send AT commands with JSON payloads over the serial control channel and then get JSON back. You never interact with the network at all, the modem is a completely self-contained system. At the extreme, you might implement your entire device using exclusively the modem. This is a common approach for telematics devices like GPS trackers: they consist of nothing but a cellular modem, the telemetry application is built for the modem using an SDK from its vendor, and you interact with it using AT commands. IoT-class modems frequently provide GPIO and user flash for just this purpose.
Hayes modems were pretty much the crème de la crème back then.
I never heard of them since the CompuServe and AOL times.
> This had a major denial of service security implication in that it would lead to the modem hanging up the connection should the computer ever try to transmit the byte sequence +++ATH0 in data mode.
Does this mean you couldn't send the documentation for the modem using the modem?
No. You had to wait a moment after sending +++ to get the OK prompt, then you could send ATH0 then CR.
Blasting +++ATH0 (CR) would have done nothing, AFAICR.
Still useful to know if you have a cellular hotspot. GSM uses AT commands for lots of things.
as do virtually all LTE-M (etc) cellular modules. I still have to maintain several model and even firmware specific AT command lists for several modules to work correctly :( (shakes fist at sierra wireless)
> M0 or M Speaker Mute, completely silent during dialing M3 is also common, but different on many brands
As a teenager with my first modem (I think I started with a 14.4, so not that early) I had no idea how to mute the modem with those commands yet while connecting to BBSes.
So I created my own "mute" (for during connection negociation at the beginning of a call, the modems were extremely noisy) system...
Late at night, when my parents were asleep, I'd unscrew the cover of the modem, take the PCB out and muffle it between two pillows while the connection was establishing.
Worked flawlessly.
As I was both up to no good and because I didn't want risking shorting the PCB, I'd then put the cover back on. Rinse and repeat every night.
I put a blob of putty in the speaker hole on my first 'hard' modem for this exact reason