Re: [PATCH] Delay full modem initialization until SIM is unlocked
- From: "Tambet Ingo" <tambet gmail com>
- To: "Dennis Noordsij" <dennis noordsij helsinki fi>
- Cc: Pablo Martí <pmargam gmail com>, networkmanager-list gnome org
- Subject: Re: [PATCH] Delay full modem initialization until SIM is unlocked
- Date: Thu, 29 May 2008 14:51:33 +0300
On Thu, May 29, 2008 at 2:12 PM, Dennis Noordsij
<dennis noordsij helsinki fi> wrote:
> I'd like to further improve easy of use with gsm devices, but it would
> help if someone could point me in the right direction (i.e. what needs
> to be touched to implement this, does it need HAL support, does it
> belong in NM, or nm-applet specific?) or comment on the following:
The general design should be to add new methods/properties to
NMGsmDevice class and expose these over dbus in the
introspection/nm-device-gsm.xml.
> - The device supports being "on" and "off". I.e., at startup it could be
> allowed to just connect to a network. Then, setting up a data connection
> will be very fast since it doesn't have to find the network first. The
> nm-applet would allow you to disable the modem the same way you disable
> wireless; the modem can be told to turn off its radio and save power
> that way, and similarly will join a network again once the radio is
> turned back on. I think this applies to all gsm modems (AT+CFUN
> command), so perhaps does not need special HAL attributes.
Good idea. It is marked as an optional feature in the specification,
so it might or might not work. I guess it could just be a noop if the
device doesn't support it. It should probably be a propery of
NMManager class (just like turning wireless on/off) which in turn
iterates over all registered devices and calls their enable/disable
radio method.
> - The init can be improved a bit, i.e. making sure the settings are sane
> and the radio is actually on (otherwise NM will loop forever waiting for
> a network to be joined).
Yeah, totally.
> - It would be nice if the nm-applet could display which network is being
> used (once a data connection has been made) and wether it's the home
> network or roaming.
>
> - Similarly, it would be nice to know which data mode is being used.
For these two we'd need to support monitoring. See my comments to the
next block.
> - This device (Dell branded Novatell EU780D) has a second port which can
> be used for status queries. It uses a binary protocol which turns out to
> be AT commands over a variation of the Brew protocol (bitpim was helpful
> to find the crc algorithm etc), Actually the Windows driver does
> everything except the actual dialing and PPP over the second port. It
> means with this device you are able to monitor the signal strength and
> battery status (in case you're using a mobile phone as a modem over usb
> or bluetooth) even while you have a data connection up. This would need
> changes I guess in a lot of places, HAL to identify and tag this modem
> as having this capability; a small lib to do the AT request/response
> encoding, etc, but it would be really nice to have.
This is actually needed for a lot of functionality, but it looks like
the monitoring device is not standardized and (almost?) every device
has it's own way of doing things. Some have proprietary binary
formats, some have AT commands. If it's done in NM, I'd like to
implement a plugin system for this, otherwise the code will get
unreadable and unmaintainable very quickly...
Another possibility we've been considering is to delegate all the
dialup handling to an out of process helper program, much like
wpa_supplicant is used for wireless. The lack of standards and lack of
implementing existing standards in mobile devices makes it a very
difficult job to support a wide range of hardware and it probably
deserves a dedicated program. The requirements from NM are that the
program implements easy to use high level dbus interfaces that
abstract all the quirks (again, much like wpa_supplicant). Currently,
the only candidate for this is VMC, Pablo could give more information
on that.
> - Not GSM specific, but relevant since data traffic is usually not
> flat-fee, to have sent/received byte counters. (i.e. is this something
> NM would broadcast over dbus or would nm-applet just query the device
> itself?)
Very good suggestion again, I'll look into doing it right away.
Tambet
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]