Proposal: identifying modems and mobile broadband cards

[Dan Williams]

On Fri, 2008-02-08 at 22:09 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > While adding mobile broadband card support to NetworkManager, it turned
> > out that we needed a more specific way of finding modems.  Most of these
> > devices present themselves as a few serial ports, either /dev/ttyUSBx
> > or /dev/ttyACMx.  The first serial port is the communications port,
> > which acts just like a modem and supports AT commands.  When the data
> > connection is open though, you must talk to the device (for signal
> > strength, etc) on the other serial ports because interrupting the data
> > stream for an AT command is a Bad Thing.
> > 
> > We can already search for the 'serial' capability, but any serial port
> > (including COM ports) has that capability, and we certainly don't want
> > to go around poking the ports to see what's there.
> > 
> > Second, we need to differentiate between CDMA and GSM based mobile
> > broadband cards, and the best way to do that is through FDI files too.
> > 
> > Proposal:
> > 
> > - The interface that has the 'serial' capability acquires the 'modem'
> > capability if that serial interface is indeed known to be a modem
> 
> I agree here. We should do that. Marking the real modem interface as
> modem would be a big win.
> 
> > - A property "modem.type" gets added with the value "at" if the modem
> > supports Hayes-compatible AT commands
> 
> Do we really need that. Modem that doesn't do AT commands is kinda
> weird. Do we have any of these and could we actually reliable identify
> them. For me capability=modem implies AT commands.

Fair enough, I don't really have any strong feelings about this part.

> Or do we wanna do capability=hayes?

Well, strictly speaking "modems" don't necessarily have a command set; I
didn't want to make things to specific to start with.  Don't care much
here either.

> > - A property "modem.phy_type" gets added that contains a value like
> > 'gsm', 'cdma', or 'wimax', maybe even 'pots' for old-school modems
> 
> Why? Lets use AT commands in the client (NM or umtsmon etc.) for that. I
> am afraid that vendors screw this up when we do purely identification
> via USB or PCI vendor and product here.

The downside of doing it this way is that you have to actually poke the
device to know what type of device it is; and it's not always that easy
to identify (might have to have quirks for a lot of cards, etc), and
it's something that would benefit all clients of HAL, and not requiring
everything to re-implement the same type detection code.  How many AT
commands do you have to issue? What's the decision tree here for
detecting device type, and how complex does it get?

That said, I do know of cases where vendors hide protocols to detect
card types and use the same p/v ids.  But the alternative is extremely
ugly and duplicating code in everything that would want to know the
device type (NM, VMC, umtsmon, comgt, etc) is just wrong.

> And btw. WiMAX will not be AT modem based.

I've heard that some Zyxel cards are like this, but most of the new
stuff coming out in the next few months is likely to need real, actual
drivers I've heard.

> > - Eventually we could put AT commands for common operations into the FDI
> > files and clients like NM could retrieve them from HAL
> 
> I think that is a really bad idea. This code either belongs in the
> client or should be done via a HAL probe extension.

Ok, fair enough; it was something davidz had mentioned a while ago.

Dan