Proposal: identifying modems and mobile broadband cards
marcel at holtmann.org
Fri Feb 8 15:23:38 PST 2008
> > > > > 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.
> Yeah, but it's WCDMA which uses 5MHz channels, while
> "CDMAone" (IS-95a/b) uses 1.25MHz channels.
> > 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?
> 1xRTT/EVDO (evolutions of CDMAone which is IS-95) is what half the
> people in the US, Canada, Australia, and New Zealand, and everyone Korea
> use, plus some large operators in China. EVDO is the 3G evolution of
> CDMAone (IS-95 and later) that Verizon, Sprint, Alltel, and others use
> in the US.
> Of the two major cellular standards tracks you have:
> GSM -> GPRS -> EDGE -> UMTS -> HSDPA -> HSUPA
> CDMAone -> 1xRTT (CDMA2000) -> EVDO rev 0 -> EVDO rev A
> The dial just the same as GSM cards, but the differences lie in operator
> selection, address book, and SIM stuff. Since IS-95 based systems and
> later don't use SIM cards (they are typically locked to an operator
> based on the ESN or MEID), they don't have any of those things.
> Furthermore, roaming is controlled through system ID lists loaded into
> the device itself, you cannot choose networks to roam on that your
> operator has not allowed or partnered with. Most CDMA phones allow you
> to set "Roaming: yes/no" but you are almost never allowed to pick a
> specific carrier on which to roam.
> > Do you actually care about what baseband technology is behind it?
> No, but since the CDMA cell standards don't do all the roaming stuff
> that GSM does, you don't have the same network scanning, operator
> selection, or network ID commands and responses as GSM-based cards.
okay. I am personally against listing GSM or CDMA if we basically only
differ between their AT command sets. Since there is more to that.
So can we either list the standard (for the AT part) that they follow.
Something like ETSI and TIA.
Or list all supported technologies in a string list. If we create FDI
files for all cards anyway, then we easily list if they support EDGE or
not. Or HSDPA or not etc.
Or even do both.
> > > 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.
> That's the problem; I'm not 100% sure what we'll need here. The
> variations between cards exist, and we don't know what cards say what
> when you poke them with AT commands. But we do know that almost all the
> mobile broadband cards out today can be categorized into either GSM or
> CDMA based categories. I'm not sure what things like the Blackberry
> Worldphone (from Verizon) expose themselves as when you plug them in
> with USB, since they contain both GSM and CDMA radios.
They might use both AT command sets :(
> > > > 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.
> Yes, all the new stuff should be native IP based. And if we don't care
> about too many of the older cards then we can drop the WiMAX stuff here
> and just treat them more like 802.11.
Until someone sense me an AT based WiMAX card, I tend to ignore them ;)
> > Also there is a difference between stationary WiMAX and mobile WiMAX.
> Yep, but not much to the OS. The only difference is that mobile WiMAX
> (802.16e-2005) has provisions for roaming between base stations, while
> fixed WiMAX (802.16-2004) does not. I'm not sure what the firmware API
> differences are there though.
There are also different frequencies involved if I am not mistaken. Have
to read that up, but it is off-topic anyway.
More information about the hal