Proposal: identifying modems and mobile broadband cards

[Marcel Holtmann]

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.

Or do we wanna do capability=hayes?

> - 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.

And btw. WiMAX will not be AT modem based.

> - 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.

Regards

Marcel