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

I am really fine if we simply mark them as capability=modem. And leave
the second TTY port as capability=serial. This especially helps for this
binary only add-on ports of a bunch of cards.

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

Good questions. I live in a GSM and UMTS world (UMTS uses CDMA btw.) and
there you have a nice ETSI command set. So that is pretty simple.

So maybe we should make it as ETSI and others as ... I really don't know
since I only heard about these EVDO cards. Do they follow the ETSI AT
command standard? Or how do you actually dial?

Do you actually care about what baseband technology is behind it?

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

If it is two AT commands to get the type, then I would say it is fine if
they are well defined. If it is full of quirks, then lets use FDI files
for that. The client can still ignore the HAL value.

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

>From my knowledge all WiMAX stuff is native IP based. However I have
seen AP that did PPPoE for the pre-WiMAX stuff and emulating then plain
PPP over serial is not far away. Not that it makes sense.

Also there is a difference between stationary WiMAX and mobile WiMAX.

Regards

Marcel