gsm0710muxd without DBUS or ptys

Since time immemorial, the Hayes "AT" command set has been used for controlling modems and so it is only sensible that controlling modern phones such as GSM devices should also use the AT command set. One problem is that AT is single threaded - while you are on a data call you cannot check signal strength.

So the clever folks who designed the latest version of the "GSM over AT" spec included mutliplexing, so you can have several virtual connections to your phone, one for data, one for control, one for async notifications etc.

This is all implemented quite nicely in gsm0710muxd which is used by Openmoko (and probably elsewhere). But of course it isn't quite as nice as I wanted it. So I've hacked it a bit. My current version can be found at git://neil.brown.name/gsm0710muxd or http://neil.brown.name/git/gsm0710muxd.

There are two things I didn't like. The first is the dependence on DBUS. The second is that insistence on using PTYs to access each channel

DBUS

It's probably just me. Maybe I'm a closet Luddite. Or maybe I don't understand the real value. But I don't like DBUS.

For a start the names are ugly. Having reversed domain names to keep everything unique may be very sensible from a safety perspective, but it really is ugly. And it feels like it excludes developers who don't have their own domain name which doesn't seem right. And I really don't think that name space collision is really going to be that much of a problem.

And then there is the fact that I don't really understand the need for three different names when accessing something. I think you need to name the interface, the object, and the method, or something like that. It strikes me as much more complex than needed. Having one hierarchical name in there make sense. Having three feels like overkill. I suspect you can point to cases where it helps, but I also suspect that in practice they are few and easy to work around.

Having a design that allows complexity simply encourages complexity. Having a design that enforces simplicity encourages developers to find simpler ways to do things.

And the libraries seem a bit clunky to use too, though maybe I haven't tried hard enough.

Anyway I don't like DBUS, but that is the only way to talk to gsm071muxd. So I fixed it.

My codes also listens on a unix domain socket at /var/run/gsm-mux and accepts stream connections. Over these it reads simple commands like "set_power 0" or "get_power" or "reset_modem".

There is also a command "connect" which is really the topic of the next section.

PTYs

With gsm0710muxd, every multiplexed channel is made available via a 'pty'. This seems to make sense as programs that talk to modems expect them to be on some sort of tty, so providing a pty will give them what they expect. It is particularly important to make a pty available as pppd really needs one to do it's ppp magic. So having ptys is good. Requiring them is not so good.

The muxer handles all the tty specific aspects of the protocol (baud rate, flow control etc) so there is really no need to use a pty to talk to the muxer. If a program knows that it is talking through the muxer and doesn't need to care about these details, a simple socket is perfectly adequate for sending commands and receiving responses. And it is much easier to set up and tear down too.

So my enhances gsm0701muxd allow access to a virtual channel over a simple unix domain socket. If you open a control socket to the muxd and issue the "connect" command, then you get connected straight through to a virtual channel with no pty needed. That is much easier to set up.

Ptys are still available, either by the dbus interface or with the "alloc_channel" socket command, but they aren't required.

Pretty simple really. All the old functionality is still there, but there is some new as well that provides an alternative to dbus and ptys. Choice is a good thing.