I have a USB modem detected as a device device file (/dev/ttyACM0). Redirecting AT commands to the device file seems to work as the modem responds.

Am going with the following assumption, the upper part represents a control channel. Through it one can dial up, setup the modem, cancel the connection... in general do things related to controlling the modem without actually handling the data. By data I mean everything that aren't controls (for example HTTP packets).

Where does the data flow happen? If it's through the same file, how is that multiplexed?

Also ideally, one would like the modem just to be an underlying "service" that provides a network interface with an IP, so one can abstract that out and use TCP/IP sockets. The sockets are implemented in the kernel.

How does this fit into the picture once the modem is exposed as /dev/ttyACM0 in user space?


Devices which use the AT-style modem “interface” operate in a number of states:

  • command mode
  • dialing mode
  • handshake mode
  • data mode

Modems start in command mode, and respond to AT-prefixed commands. Once they establish a connection (following ATD for example, after going through the dialing and handshake modes), they switch to data mode and any data sent to them is transmitted to the device they’re connected to. To switch back to command mode, the sender needs to pause the data flow for a certain time, send +++, then pause again; the modem switches back to command mode and starts responding to AT commands again (and the data flow is interrupted).

Some modems didn’t need the pauses, which meant data would be interpreted as command sequences if it contained +++ (hence the +++ATH0 practical joke on IRC).

To provide another protocol on top of the modem data connection, you need to use another tool. Which tool you use depends on the protocol that the other end expects (SLIP, PPP, PPPoE...); for example, you’d use ppp for PPP (preferably as integrated into your distribution, so the setup ends up being mostly transparent). That will provide some form of IP encapsulation, and then you can use IP as usual. The tool involved will use whatever device is necessary to talk to the modem (/dev/ttyACM0 in your case), and expose another interface which the rest of the system can use for networking purposes (generally speaking, a network interface, e.g. ppp0).

| improve this answer | |
  • To provide another protocol on top of the modem data connection, you need to use another tool So, say, ppp would then consume the device file and be responsible for providing exposing the socket interface? – TheMeaningfulEngineer Apr 17 '18 at 8:48
  • Yes, see my updated answer. – Stephen Kitt Apr 17 '18 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.