gsm0710muxd without DBUS or ptys

31 January 2009, 20:51 UTC

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:// or

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


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.


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.


Re: gsm0710muxd without DBUS or ptys (08 April 2010, 08:02 UTC)


I could not agree more with you on the DBUS topic. Adding abstractions on top of other abstractions leads to nothing good. Ask the JAVA folks :)

I am working on my own custom software for the Freerunner and stumbled upon your gsm0710muxd work. Are you actively working on it? Do you have interest in keeping your branch up-to-date with the original?



Re: gsm0710muxd without DBUS or ptys (08 April 2010, 20:47 UTC)

I'm not really actively working on it, though I should. There is something wrong with the flow control. I think I know what but haven't actually fixed it yet.

But I thought the 'original' was dead-in-the-water. I just did a 'git pull' from git:// and got a new file called THIS_IS_DEPRECATED_USE_LIBGSM0710MUX.

Do you know of a different site where work is happening on gsm0710muxd??


Re: gsm0710muxd without DBUS or ptys (07 May 2010, 03:48 UTC)

Man this is very important and silly at the same time. I have this NeoVento distro and I need to get the signal strength from the cell fone freerunner and I need it quick dude. If you could help me out where I could find signal strength being logged (in dbm) or whatever that would be extremely great! I have been trying very hard to find but with no luck!!! KINDLY help!! email is in the link.


Re: gsm0710muxd without DBUS or ptys (07 May 2010, 04:13 UTC)

The command to get the signal strength is AT+CSQ

I don't know what the units are but the range seems to be 0--32.

See also to find out about signal strength from other nearby towers.


Re: gsm0710muxd without DBUS or ptys (07 May 2010, 10:10 UTC)

Thanks a million for replying. I know it'll sound more stupid but for some reason, most likely due to having a new distribution called Neo Vento, I am unable to execute these commands that you mentioned. I knew of these already but the page asks to either run "gsmd" or "cu -l /dev/ttySAC0" before entering these commands and entering both tells me that command not found:

debian-gta02:~# gsmd -bash: gsmd: command not found debian-gta02:~# cu -l /dev/ttySAC0 -bash: cu: command not found

and i directly entering the AT commands obviously dont work. Any other ideas please? Doesn't the phone have something similar to the data stored by accelerometers? like for accelerometers, the data is stored in /dev/input/event2 or even3. Isn't the signal strength periodically logged in some form in a file? Well eagerly waiting for your reply.


Re: gsm0710muxd without DBUS or ptys (07 May 2010, 10:43 UTC)

Sorry, I cannot help directly. I looks like neovento uses the FSO stack, so there is probably some dbus command to find out the signal strength.

As it is debian based you could install 'cu' using 'apt-get install cu'. You would probably need to kill the FSO daemon that is accessing /dev/ttySAC0 before 'cu' will be able to access it.

I suggest you look for information about dbus access to the FSO stack.