[ANNOUNCE] ModemManager (for GSM and CDMA)

[Tambet Ingo-2]

Announcing ModemManager.
It's a standalone DBus system service to provide a common API to
communicate with broadband modems. It is derived from the modem
handling code from NetworkManager and in addition to DBus API, it adds
more operations (scanning, signal quality, changing network mode,
band, ...). It is easy to extend by having a plugin system to provide
"drivers" for non standard operations. There is currently one plugin
implemented for Huawei cards. It's fully functional and can be used as
an example to write plugins for other cards (hint! hint!).

Some Q&A

Q: Where can I get it?
A: git clone git://gitorious.org/modemmanager/mainline.git modemmanager

Q: What does it have to do with NetworkManager?
A: NetworkManager will use ModemManager instead of current basic code
in the future.

Q: Can I see it in action?
A: Yes! I've ported NM to use it already, but haven't exposed any of
the new functionality in the UI. The fully working branch can be
downloaded from the NetworkManager SVN branch:

svn co svn+ssh://$USERNAME@.../svn/NetworkManager/branches/modem-manager
NetworkManager-mm

[or using anonymous svn]
svn co http://svn.gnome.org/svn/NetworkManage/branches/modem-manager
NetworkManager-mm

Q: Why?
A: There have been some requests to integrate some existing mobile
programs with NM (vodafone, telefonica) and it's never been easier:
All that needs to happen is to implement the same public DBus API and
NM will use that instead.
A2: The current modem handling code in NM is very basic, and
supporting non standard operations and cards is pretty much impossible
without total reorganization. Well, ModemManager is the
reorganization.

Q: You lied, it doesn't support signal monitoring while connected!
A: No, it just means it's a non standard feature and needs a card
specific plugin which isn't written for your card yet.

Q: Is there any documentation available for it?
A: Yes, pass a --with-docs argument to the configure and it'll create
docs/spec.html which is the DBus API reference. There's also some
information in the README file.

Q: Can I write a plugin for my own card?
A: Yes! Take a look at plugins/ directory to see the Huawei plugin, it
should be pretty easy to write new ones based on that.

Q: I think I've found a bug.
A: Great! let me (tambet /at/ gmail.com for now) know. Extra points if
you can provide a patch!

Q: You API sucks!
A: If there's something you'd like to change, either to add new
methods or to modify the existing ones, let me know, it's not set in
the stone.

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Carlos Perelló Marín]

El jue, 31-07-2008 a las 18:10 +0300, Tambet Ingo escribió:
> Announcing ModemManager.

Hi,


> It's a standalone DBus system service to provide a common API to
> communicate with broadband modems. It is derived from the modem
> handling code from NetworkManager and in addition to DBus API, it adds
> more operations (scanning, signal quality, changing network mode,
> band, ...). It is easy to extend by having a plugin system to provide
> "drivers" for non standard operations. There is currently one plugin
> implemented for Huawei cards. It's fully functional and can be used as
> an example to write plugins for other cards (hint! hint!).

Is nice to see this kind of software popping up :-)

Are you in touch with the guys behind mobilemanager
(http://mobilemanager.movilforum.com/)? They sent an announcement about
a DBUS system like ModemManager a couple of months ago. They are part of
Telefonica, and that's the movement they did to integrate their software
with Network Manager.

Cheers.


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

On Thu, Jul 31, 2008 at 6:23 PM, Carlos Perelló Marín <carlos@...> wrote:
> Is nice to see this kind of software popping up :-)
>
> Are you in touch with the guys behind mobilemanager
> (http://mobilemanager.movilforum.com/)? They sent an announcement about
> a DBUS system like ModemManager a couple of months ago. They are part of
> Telefonica, and that's the movement they did to integrate their software
> with Network Manager.

Yes, I know. That's the main reason why we'll be moving to the out of
process DBus service. NM can't support all modem DBus service
implementations out there and this work has partly been for defining a
common API. With the SVN branch of NM I posted, it would be very easy
to integrate whoever might be interested in doing so. For the longer
term, my personal opinion is that system daemons should be written in
C (but it's a matter of opinion, and with out of process
implementation, it's easy to disagree and use something else).

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Roberto Majadas Lopez]

El jue, 31-07-2008 a las 18:47 +0300, Tambet Ingo escribió:

> On Thu, Jul 31, 2008 at 6:23 PM, Carlos Perelló Marín <carlos@...> wrote:
> > Is nice to see this kind of software popping up :-)
> >
> > Are you in touch with the guys behind mobilemanager
> > (http://mobilemanager.movilforum.com/)? They sent an announcement about
> > a DBUS system like ModemManager a couple of months ago. They are part of
> > Telefonica, and that's the movement they did to integrate their software
> > with Network Manager.
>
> Yes, I know. That's the main reason why we'll be moving to the out of
> process DBus service. NM can't support all modem DBus service
> implementations out there and this work has partly been for defining a
> common API. With the SVN branch of NM I posted, it would be very easy
> to integrate whoever might be interested in doing so. For the longer
> term, my personal opinion is that system daemons should be written in
> C (but it's a matter of opinion, and with out of process
> implementation, it's easy to disagree and use something else).

Hi Tambet Ingo:

I'm Roberto Majadas (mobile-manager developer). I was reading your spec
about modem-manager. It's really interesting but i think you are trying
to implement the same thing that we've implementated.

Mobile Manager has a public and documentated Dbus API[1]. It support
many features like pin/puk management, device and status information,
plug & play support, device plugin system....

At the moment we support this devices :
 - Huawei
 - Option
 - Nozomi
 - Sierra
 - Novatel
 - Usb devices
 - Bluetooth devices

And in the future we'll support more devices.

About the programming language that should be written a daemon. Yeah C
it's a good option in fact (i'm C programmer). But there are many, many,
many situations easier to resolve using python in this case. The GPRS/3G
devices sometimes are evils ;), belive me, i was working on it the last
two years :). In this way MobileManager only depends of python,
python-dbus and python-gobject (5-10Mb in memory)

At the moment we use wdial to establish the ppp connection but we can
change it and use NM ppp system.

We are open to talk everything and we are open to colaborate ;)

Btw , we have packaged mobile-manager, you can try it [2]

Roberto Majadas

[1] http://mobilemanager.movilforum.com/index.php/API_Documentation
[2] http://open.movilforum.com/archive/escritorio-movistar/

>
> Tambet
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list@...
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Helmut Schaa]

Am Do 31 Jul 2008 17:10:57 CEST schrieb Tambet Ingo <tambet@...>:

> Q: What does it have to do with NetworkManager?
> A: NetworkManager will use ModemManager instead of current basic code
> in the future.

Great.

Which changes will be needed for NM frontends? Are there any drastic  
API changes or do the settings need refactoring?

Thanks,
Helmut
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

On Fri, Aug 1, 2008 at 8:59 AM, Helmut Schaa <hschaa@...> wrote:
> Which changes will be needed for NM frontends? Are there any drastic API
> changes or do the settings need refactoring?

First of all, this all will happen after 0.7 release.

There are no NetworkManager API changes, but we'll need to add new
methods and signals to the modem devices to use the new functionality.
The settings already contain all the required fields (some of which
are currently not used by NM).

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

On Fri, Aug 1, 2008 at 12:30 AM, Roberto Majadas
<roberto.majadas@...> wrote:

> I'm Roberto Majadas (mobile-manager developer). I was reading your spec
> about modem-manager. It's really interesting but i think you are trying
> to implement the same thing that we've implementated.
>
> Mobile Manager has a public and documentated Dbus API[1]. It support
> many features like pin/puk management, device and status information,
> plug & play support, device plugin system....
>
> At the moment we support this devices :
>  - Huawei
>  - Option
>  - Nozomi
>  - Sierra
>  - Novatel
>  - Usb devices
>  - Bluetooth devices
>
> And in the future we'll support more devices.
>
> About the programming language that should be written a daemon. Yeah C
> it's a good option in fact (i'm C programmer). But there are many, many,
> many situations easier to resolve using python in this case. The GPRS/3G
> devices sometimes are evils ;), belive me, i was working on it the last
> two years :). In this way MobileManager only depends of python,
> python-dbus and python-gobject (5-10Mb in memory)
>
> At the moment we use wdial to establish the ppp connection but we can
> change it and use NM ppp system.
>
> We are open to talk everything and we are open to colaborate ;)

Again, all this work has been done to support other modem driving
solutions (like mobile-manager). There were two missing pieces: It
wasn't possible to use other languages than C before, which is solved
by writing code to NetworkManager to talk to modems over dbus. Another
thing that was missing was the dbus API. Now that is defined as well
(but is open for changes). There are other (from mobile-manager)
interested parties and everyone has their own API. NM shouldn't try to
implement all of them, so we needed to define something that everyone
can target. ModemManager that I just announced is just one
implementer. As you say, it takes time to write a good one, and using
existing programs (which need to adapt the API changes, or just
provide another set of API to be integrated with NM) we have a
complete solution today.

The way to collaborate (to integrate with NM) is to try to implement
the API I've defined, and give me feedback on what should change
there.

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

It looks like I did terrible job explaining _why_ I wrote
ModemManager. Let me try again.

Where were we before ModemManager.
The current state in NetworkManager 0.7 is that we have the absolute
minimum support for modems to claim that we support modems. There are
a couple of advanced solution out there (mobile-manager, vmc, umtsmon)
that do much better job and have many more features. Multiple people
contacted us asking if we could integrate their solution, each with
different API.

How to solve that?
Given that the existing mobile applications were written in other
languages than C, it became clear we need an out of process design for
modems. So DBus was chosen. The next obstacle is that each existing
solution has it's own API. The solution I chose for this is to define
a common API that NetworkManager uses and any project that wants to be
integrated, can implement two simple interfaces. I felt it was a
better choice than using any of the existing APIs to not make anyone
feel left out.

Why did I write ModemManager?
I'm no a genius and can't define API without trying to use it.
Therefore, I needed something to test on. ModemManager is very little
apart from the newly defined DBus interface plus the modem handling
code from NetworkManager. So it's not like I've made huge investments
trying to reimplement a wheel (or existing projects).

Where are we now?
I wrote the code for NetworkManager to support out of processes modem
handling API. It's in 'ModemManager' branch in the NetworkManager's
SVN tree. We have a clear answer to any project that wants to
integrate with NetworkManager.

Do I keep working on ModemManager?
Yes. As long as existing solution can be used with NetworkManager, I
feel like I've solved the main goal. If my pet project doesn't
succeed, there's no great loss. If it does, it gives me (and possibly
others) more choice. If there are two backends, one written in python
and one in C and both do the job for me, I'd choose the C one. Other
people, depending on their specific hardware, beliefs or what not,
might choose the other.

Does it make sense?
Tambet

On Thu, Jul 31, 2008 at 6:10 PM, Tambet Ingo <tambet@...> wrote:

> Announcing ModemManager.
> It's a standalone DBus system service to provide a common API to
> communicate with broadband modems. It is derived from the modem
> handling code from NetworkManager and in addition to DBus API, it adds
> more operations (scanning, signal quality, changing network mode,
> band, ...). It is easy to extend by having a plugin system to provide
> "drivers" for non standard operations. There is currently one plugin
> implemented for Huawei cards. It's fully functional and can be used as
> an example to write plugins for other cards (hint! hint!).
>
> Some Q&A
>
> Q: Where can I get it?
> A: git clone git://gitorious.org/modemmanager/mainline.git modemmanager
>
> Q: What does it have to do with NetworkManager?
> A: NetworkManager will use ModemManager instead of current basic code
> in the future.
>
> Q: Can I see it in action?
> A: Yes! I've ported NM to use it already, but haven't exposed any of
> the new functionality in the UI. The fully working branch can be
> downloaded from the NetworkManager SVN branch:
>
> svn co svn+ssh://$USERNAME@.../svn/NetworkManager/branches/modem-manager
> NetworkManager-mm
>
> [or using anonymous svn]
> svn co http://svn.gnome.org/svn/NetworkManage/branches/modem-manager
> NetworkManager-mm
>
> Q: Why?
> A: There have been some requests to integrate some existing mobile
> programs with NM (vodafone, telefonica) and it's never been easier:
> All that needs to happen is to implement the same public DBus API and
> NM will use that instead.
> A2: The current modem handling code in NM is very basic, and
> supporting non standard operations and cards is pretty much impossible
> without total reorganization. Well, ModemManager is the
> reorganization.
>
> Q: You lied, it doesn't support signal monitoring while connected!
> A: No, it just means it's a non standard feature and needs a card
> specific plugin which isn't written for your card yet.
>
> Q: Is there any documentation available for it?
> A: Yes, pass a --with-docs argument to the configure and it'll create
> docs/spec.html which is the DBus API reference. There's also some
> information in the README file.
>
> Q: Can I write a plugin for my own card?
> A: Yes! Take a look at plugins/ directory to see the Huawei plugin, it
> should be pretty easy to write new ones based on that.
>
> Q: I think I've found a bug.
> A: Great! let me (tambet /at/ gmail.com for now) know. Extra points if
> you can provide a patch!
>
> Q: You API sucks!
> A: If there's something you'd like to change, either to add new
> methods or to modify the existing ones, let me know, it's not set in
> the stone.
>
> Tambet
>

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Stuart Ward]

The whole point of Network Manager is that it is the integrated network access tool. Modems are largely standard. we don't need special software to access different modems. Perhaps we need a configuration strings for some modems but I see no point in having a separate tool for modems.

Equally for GSM modems these are as least as standardised as WiFi cards. So we should not need a seperate tool to manage them.

What Network Manager should show is the GSM signal strength as soon as you plug in a modem, and allow a button to select and establish the connection. Just like the WiFi selection.

Am I missing something here?

-- Stuart Ward M [phone]

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Magnus Boman-2]

Stuart,

On Sat, 2008-08-02 at 12:43 +0100, Stuart Ward wrote:
>
> The whole point of Network Manager is that it is the integrated
> network access tool. Modems are largely standard. we don't need
> special software to access different modems. Perhaps we need a
> configuration strings for some modems but I see no point in having a
> separate tool for modems.

I'm looking forward to your design ideas (and perhaps code?) on how to
make Networking (and especially NM) a generic thing.

>
> Equally for GSM modems these are as least as standardised as WiFi
> cards. So we should not need a seperate tool to manage them.

I'm sure a lot of people with different GSM/CDMA/G3 cars/USB cables etc
would not agree... But., same question as above.

>
> What Network Manager should show is the GSM signal strength as soon as
> you plug in a modem, and allow a button to select and establish the
> connection. Just like the WiFi selection.
>
> Am I missing something here?

How about if you read the email thread(s) about it all? Then you'd know
that you might be missing a few clues...

>
> -- Stuart Ward M [phone]

/Magnus



_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

On Sat, Aug 2, 2008 at 2:43 PM, Stuart Ward <stuart.ward@...> wrote:

> The whole point of Network Manager is that it is the integrated network
> access tool. Modems are largely standard. we don't need special software to
> access different modems. Perhaps we need a configuration strings for some
> modems but I see no point in having a separate tool for modems.
>
> Equally for GSM modems these are as least as standardised as WiFi cards. So
> we should not need a seperate tool to manage them.
>
> What Network Manager should show is the GSM signal strength as soon as you
> plug in a modem, and allow a button to select and establish the connection.
> Just like the WiFi selection.
>
> Am I missing something here?

This is just a code reorganization, the NetworkManager will still be
the frontend for everything. There are no UI or work flow changes
caused by this. As I've tried to explain multiple times already, the
reorganization was done mainly to support other modem backends that
are currently more advanced than what NM has.

Modems are very much _not_ standardized for anything except the very
basic functionality. Your example (signal strength) is a good one:
while not connected, NM does not keep the serial device open just to
get the signal strength. While connected through modem though, it
depends very much on modem hardware how to do it: Some cards have
another serial device for monitoring (some use binary format there,
some use AT commands with different formats), some have one
multiplexed device. So there needs to be different handling for
different cards and providing a plugins framework in ModemManager is
exactly for this.

The big difference between wifi and modems is that wifi scanning takes
less than a second, so we can schedule scans in some intervals. For
modems though, scanning takes a long time (over 10 seconds, sometimes
even close to a minute for cards which support a wide range of
frequencies), so NM can not just randomly block the access to modem
for such long periods of time.

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Sat, 2008-08-02 at 12:43 +0100, Stuart Ward wrote:
>
> The whole point of Network Manager is that it is the integrated
> network access tool. Modems are largely standard. we don't need
> special software to access different modems. Perhaps we need a
> configuration strings for some modems but I see no point in having a
> separate tool for modems.
>
> Equally for GSM modems these are as least as standardised as WiFi
> cards. So we should not need a seperate tool to manage them.

Unfortunately, they are not :(

There are different numbers of command ports (some use one, some have 2,
some have 3), some have different AT command sequence behavior (like
allowing commands before entering PINs or not), some use custom commands
to connect (Option 3G modems use AT_OWANCALL/AT_OWANDATA instead of ATDT
and do not require either a phone # _or_ PPP), others use custom PDP
methods before dialing (IPWireless 4G cards use "PPP" for AT+CGDCONT
instead of "IP"), and of course GSM and CDMA cards have different
command sets entirely.

Furthermore, many cards have custom commands for things like supported
frequency lists, radio power state (at!pcstate on Sierra cards), GPS
functionality, and a host of other things.

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Pablo Martí Gamboa]

On Thu, Jul 31, 2008 at 5:10 PM, Tambet Ingo <tambet@...> wrote:
> Announcing ModemManager.

The ModemManager announcement struck me on holidays, thats why I
didn't say anything :)

<snip>
>
> Q: You API sucks!
> A: If there's something you'd like to change, either to add new
> methods or to modify the existing ones, let me know, it's not set in
> the stone.

The Wader project has started to port its API to the one defined by
ModemManager. While doing so we've got some input for the API design.
The interfaces currently defined are too "flat":

#define MM_DBUS_SERVICE              "org.freedesktop.ModemManager"
#define MM_DBUS_PATH                 "/org/freedesktop/ModemManager"
#define MM_DBUS_INTERFACE            "org.freedesktop.ModemManager"
#define MM_DBUS_INTERFACE_MODEM      "org.freedesktop.ModemManager.Modem"
#define MM_DBUS_INTERFACE_GSM_MODEM  "org.freedesktop.ModemManager.Modem.Gsm"
#define MM_DBUS_INTERFACE_CDMA_MODEM "org.freedesktop.ModemManager.Modem.Cdma"

This interfaces might be enough for ModemManager's purposes as MM is
just interested on 5/6 commands, but for projects like Wader where we
export 40+ methods this flat namespace is nothing but ideal. The
exported methods could be grouped into five different areas:

o.f.MM.M.G.Card
o.f.MM.M.G.Contacts
o.f.MM.M.G.Network
o.f.MM.M.G.PIN
o.f.MM.M.G.SMS

org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
  - DisableEcho() ->
  - EnableEcho() ->
  - Enable(b enable) ->  (This is the Enable method of ModemManager, I
think it goes here but I might be completely wrong here :)
  - GetCharset -> s
  - GetCharsets() -> as
  - GetIMEI() -> s
  - GetIMSI() -> s
  - GetManufacturer() -> s
  - GetModel() -> s
  - GetVersion() -> s  (Firmware version)
  - ResetSettings() ->  (ATZ)
  - SetCharset(s charset) ->

org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
  - Add(s name, s number) -> u
  - Delete(u index) ->
  - Find(s pattern) -> a(uss)
  - Get(u index) -> (uss)
  - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
  - List() -> a(uss)

org.freedesktop.ModemManager.Modem.Gsm.Network:
  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
  - GetInfo() -> (su)  (AT+COPS?)
  - GetNames() -> a(ussuu)   (AT+COPS=?)
  - GetRoamingIDs() -> as    (AT+CPOL?)
  - GetSignalQuality() -> u
  - SetRegistrationNotification(b enable) ->
  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
  - RegisterWithNetID(s netid) ->

  - CregReceived(u status) ->   (signal)
  - SignalQuality(u rssi) ->   (signal)

org.freedesktop.ModemManager.Modem.Gsm.PIN:
  - Change(s oldpin, s newpin) ->
  - Check() -> u  (Returns the SIM auth state, to check it against an enum)
  - Enable(s pin) ->
  - Disable(s pin) ->
  - Send(s pin) ->
  - SendPUK(s puk, s pin) ->

org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
  - Delete(u index) ->
  - Get(u index) -> (ussd)        (The last double is the time when it
was received)
  - GetFormat() -> u   (AT+CPBF?)
  - GetSMSC() -> s
  - List() -> a(ussd)
  - Save(s text, s number) -> u
  - Send -> u
  - SendFromStorage(u index)
  - SetFormat(u format) ->
  - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->   (AT+CNMI=mode,mt,..)
  - SetSMSC(s smsc) ->

  - SMSReceived(u index, s where)    (signal)

This is just food for thought, what think about such an API the
different parties involved?
I've tried to clarify in parentheses all the methods that might be
misleading or might be controversial, with either its purpose or the
correspondent AT command. I think that standard interfaces such as
{SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
methods (specially its naming) are somewhat more controversial and
I'll be happy to discuss 'em.

I've attached this interfaces to the Gsm (WCDMA) part, we still need
to decide what to do with CDMA... Dan? :)

Best regards,

--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Pablo Martí Gamboa]

On Wed, Aug 27, 2008 at 12:54 PM, Pablo Martí <pmarti@...> wrote:

> On Thu, Jul 31, 2008 at 5:10 PM, Tambet Ingo <tambet@...> wrote:
>
> This interfaces might be enough for ModemManager's purposes as MM is
> just interested on 5/6 commands, but for projects like Wader where we
> export 40+ methods this flat namespace is nothing but ideal. The
> exported methods could be grouped into five different areas:
>
> o.f.MM.M.G.Card
> o.f.MM.M.G.Contacts
> o.f.MM.M.G.Network
> o.f.MM.M.G.PIN
> o.f.MM.M.G.SMS
>
> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
>  - DisableEcho() ->
>  - EnableEcho() ->
>  - Enable(b enable) ->  (This is the Enable method of ModemManager, I
> think it goes here but I might be completely wrong here :)
>  - GetCharset -> s
>  - GetCharsets() -> as
>  - GetIMEI() -> s
>  - GetIMSI() -> s
>  - GetManufacturer() -> s
>  - GetModel() -> s
>  - GetVersion() -> s  (Firmware version)
>  - ResetSettings() ->  (ATZ)
>  - SetCharset(s charset) ->
>
> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
>  - Add(s name, s number) -> u
>  - Delete(u index) ->
>  - Find(s pattern) -> a(uss)
>  - Get(u index) -> (uss)
>  - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
>  - List() -> a(uss)
>
> org.freedesktop.ModemManager.Modem.Gsm.Network:
>  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
>  - GetInfo() -> (su)  (AT+COPS?)
>  - GetNames() -> a(ussuu)   (AT+COPS=?)
>  - GetRoamingIDs() -> as    (AT+CPOL?)
>  - GetSignalQuality() -> u
>  - SetRegistrationNotification(b enable) ->
>  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
>  - RegisterWithNetID(s netid) ->

Oh well, I forgot the API already defined by ModemManager for bands:

  - SetBand
  - GetBand

I'm quite kweel with them, thats why I didnt mention 'em

--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

Hey,

First of all, thanks for your comments!

On Wed, Aug 27, 2008 at 1:54 PM, Pablo Martí <pmarti@...> wrote:
> The Wader project has started to port its API to the one defined by
> ModemManager. While doing so we've got some input for the API design.
> The interfaces currently defined are too "flat":
<snip>

> This interfaces might be enough for ModemManager's purposes as MM is
> just interested on 5/6 commands, but for projects like Wader where we
> export 40+ methods this flat namespace is nothing but ideal. The
> exported methods could be grouped into five different areas:
>
> o.f.MM.M.G.Card
> o.f.MM.M.G.Contacts
> o.f.MM.M.G.Network
> o.f.MM.M.G.PIN
> o.f.MM.M.G.SMS

Yeah, agreed.

I reordered the interfaces a bit:

> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
>  - DisableEcho() ->
>  - EnableEcho() ->

These do not do anything useful from the API user's perspective and
shouldn't be included in the public API.

>  - Enable(b enable) ->  (This is the Enable method of ModemManager, I
> think it goes here but I might be completely wrong here :)

Yes. Enable() means initialize the card and check if any secrets are
needed (PIN/PUK).

>  - GetCharset -> s
>  - GetCharsets() -> as
>  - SetCharset(s charset) ->

Do we need these? Do the modems support UTF8? If they do, let's just
default to that. The reason I don't like there much is that they seem
a bit too low level.

>  - GetIMEI() -> s
>  - GetIMSI() -> s
>  - GetManufacturer() -> s
>  - GetModel() -> s
>  - GetVersion() -> s  (Firmware version)

All good ones.

>  - ResetSettings() ->  (ATZ)

That's what Enable(True) does (among other things).

> org.freedesktop.ModemManager.Modem.Gsm.Network:
>  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
>  - GetInfo() -> (su)  (AT+COPS?)
>  - GetNames() -> a(ussuu)   (AT+COPS=?)
>  - GetRoamingIDs() -> as    (AT+CPOL?)
>  - GetSignalQuality() -> u
>  - SetRegistrationNotification(b enable) ->
>  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
>  - RegisterWithNetID(s netid) ->
>
>  - CregReceived(u status) ->   (signal)
>  - SignalQuality(u rssi) ->   (signal)

I think these are too low level. I'd much prefer the current ones from
ModemManager.

> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>  - Change(s oldpin, s newpin) ->
>  - Check() -> u  (Returns the SIM auth state, to check it against an enum)
>  - Enable(s pin) ->
>  - Disable(s pin) ->
>  - Send(s pin) ->
>  - SendPUK(s puk, s pin) ->

Not sure about these. Currently, Check() is part of
Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method
with a boolean argument. What's the difference (code wise) between
Send() and SendPUK()? So that would leave us with 3 methods:
Enable(bool), Send(string), Change(string, string). If so, maybe they
can be part of the Gsm.Card interface?


For the following methods I don't have strong preferences because I've
never used any of these features and thus don't have any hands on
experience. I'd really appreciate if other interested parties
(Telefonica?) could comment these.

> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
>  - Add(s name, s number) -> u
>  - Delete(u index) ->
>  - Find(s pattern) -> a(uss)
>  - Get(u index) -> (uss)
>  - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
>  - List() -> a(uss)

Looks good to me.

> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
>  - Delete(u index) ->
>  - Get(u index) -> (ussd)        (The last double is the time when it
> was received)
>  - GetFormat() -> u   (AT+CPBF?)
>  - GetSMSC() -> s
>  - List() -> a(ussd)
>  - Save(s text, s number) -> u
>  - Send -> u
>  - SendFromStorage(u index)
>  - SetFormat(u format) ->
>  - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->   (AT+CNMI=mode,mt,..)
>  - SetSMSC(s smsc) ->
>
>  - SMSReceived(u index, s where)    (signal)
>
> This is just food for thought, what think about such an API the
> different parties involved?
> I've tried to clarify in parentheses all the methods that might be
> misleading or might be controversial, with either its purpose or the
> correspondent AT command. I think that standard interfaces such as
> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
> methods (specially its naming) are somewhat more controversial and
> I'll be happy to discuss 'em.
>
> I've attached this interfaces to the Gsm (WCDMA) part, we still need
> to decide what to do with CDMA... Dan? :)

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Bastien Nocera]

On Wed, 2008-08-27 at 17:35 +0300, Tambet Ingo wrote:
>
> >  - GetCharset -> s
> >  - GetCharsets() -> as
> >  - SetCharset(s charset) ->
>
> Do we need these? Do the modems support UTF8? If they do, let's just
> default to that. The reason I don't like there much is that they seem
> a bit too low level.

They usually support UCS-2, GSM and ASCII, with varying degrees of
success, but you're completely right that this should never appear in
the public API.

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Pablo Martí Gamboa]

On Wed, Aug 27, 2008 at 4:35 PM, Tambet Ingo <tambet@...> wrote:
>
> I reordered the interfaces a bit:
>
>> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
>>  - DisableEcho() ->
>>  - EnableEcho() ->
>
> These do not do anything useful from the API user's perspective and
> shouldn't be included in the public API.

Agreed

>
>>  - Enable(b enable) ->  (This is the Enable method of ModemManager, I
>> think it goes here but I might be completely wrong here :)
>
> Yes. Enable() means initialize the card and check if any secrets are
> needed (PIN/PUK).

It seems that Enable will raise an exception indicating whats needed,
we'll need to agree on the exceptions name... :)

>
>>  - GetCharset -> s
>>  - GetCharsets() -> as
>>  - SetCharset(s charset) ->
>
> Do we need these? Do the modems support UTF8? If they do, let's just
> default to that. The reason I don't like there much is that they seem
> a bit too low level.

I agree that they dont need to be included in the public API as
they're not that useful for MM, but at the same time if we reach
consensus here, this API might be the de-facto standard for [W]CDMA on
Linux (and perhaps other nix*). And our Asian friends _do_ care about
unicode. This parameter affects responses of commands like (+COPS,
GetSMSC, SetSMSC, AddContact, FindContact, etc.) The idea is to be in
UCS2 as much as possible so everyone is happy, and using IRA,GSM as a
fallback.

>
>>  - GetIMEI() -> s
>>  - GetIMSI() -> s
>>  - GetManufacturer() -> s
>>  - GetModel() -> s
>>  - GetVersion() -> s  (Firmware version)
>
> All good ones.

>
>> org.freedesktop.ModemManager.Modem.Gsm.Network:
>>  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
>>  - GetInfo() -> (su)  (AT+COPS?)
>>  - GetNames() -> a(ussuu)   (AT+COPS=?)
>>  - GetRoamingIDs() -> as    (AT+CPOL?)
>>  - GetSignalQuality() -> u
>>  - SetRegistrationNotification(b enable) ->
>>  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
>>  - RegisterWithNetID(s netid) ->
>>
>>  - CregReceived(u status) ->   (signal)
>>  - SignalQuality(u rssi) ->   (signal)
>
> I think these are too low level. I'd much prefer the current ones from
> ModemManager.

You mean:
 - Register("") -> Tries to register with your home network
 - Register("24301") -> Tries to register with the given MNC

I can agree in this two. "AT+COPS?" is a pretty useful command that
you've (inadvertently) banned here :), ditto with "At+COPS=?" and
"AT+CPOL?" when you have a buggy firmware/old SIM that does strange
things while roaming...

>
>> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>>  - Change(s oldpin, s newpin) ->
>>  - Check() -> u  (Returns the SIM auth state, to check it against an enum)
>>  - Enable(s pin) ->
>>  - Disable(s pin) ->
>>  - Send(s pin) ->
>>  - SendPUK(s puk, s pin) ->
>
> Not sure about these. Currently, Check() is part of
> Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method
> with a boolean argument. What's the difference (code wise) between
> Send() and SendPUK()? So that would leave us with 3 methods:
> Enable(bool), Send(string), Change(string, string). If so, maybe they
> can be part of the Gsm.Card interface?

Enable(b) sounds good to me. The difference between Send and SendPUK
is that the former receives just one parameter (the pin), while the
later receives two, the puk and the new PIN to set in the card. One of
the advantages of having a separate interface is that CDMA devices
cant just skip the .PIN interface. Otherwise they'll support half of
.Card.
>
>
> For the following methods I don't have strong preferences because I've
> never used any of these features and thus don't have any hands on
> experience. I'd really appreciate if other interested parties
> (Telefonica?) could comment these.

Yeah! Roberto?

Best regards,

>
>> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
>>  - Add(s name, s number) -> u
>>  - Delete(u index) ->
>>  - Find(s pattern) -> a(uss)
>>  - Get(u index) -> (uss)
>>  - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
>>  - List() -> a(uss)
>
> Looks good to me.
>
>> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
>>  - Delete(u index) ->
>>  - Get(u index) -> (ussd)        (The last double is the time when it
>> was received)
>>  - GetFormat() -> u   (AT+CPBF?)
>>  - GetSMSC() -> s
>>  - List() -> a(ussd)
>>  - Save(s text, s number) -> u
>>  - Send -> u
>>  - SendFromStorage(u index)
>>  - SetFormat(u format) ->
>>  - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->   (AT+CNMI=mode,mt,..)
>>  - SetSMSC(s smsc) ->
>>
>>  - SMSReceived(u index, s where)    (signal)
>>
>> This is just food for thought, what think about such an API the
>> different parties involved?
>> I've tried to clarify in parentheses all the methods that might be
>> misleading or might be controversial, with either its purpose or the
>> correspondent AT command. I think that standard interfaces such as
>> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
>> methods (specially its naming) are somewhat more controversial and
>> I'll be happy to discuss 'em.
>>
>> I've attached this interfaces to the Gsm (WCDMA) part, we still need
>> to decide what to do with CDMA... Dan? :)
>
> Tambet
>

--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Wed, 2008-08-27 at 15:40 +0100, Bastien Nocera wrote:

> On Wed, 2008-08-27 at 17:35 +0300, Tambet Ingo wrote:
> >
> > >  - GetCharset -> s
> > >  - GetCharsets() -> as
> > >  - SetCharset(s charset) ->
> >
> > Do we need these? Do the modems support UTF8? If they do, let's just
> > default to that. The reason I don't like there much is that they seem
> > a bit too low level.
>
> They usually support UCS-2, GSM and ASCII, with varying degrees of
> success, but you're completely right that this should never appear in
> the public API.

My opinion is that the Modem service (or SMS service or whatever) should
handle the charset internally and convert from UTF-8 to the best that
the hardware supports.  Since everything coming over D-Bus is UTF-8 by
definition, there's no point to exposing that charset functionality
publicly since you can't send the modem service anything that's _not_
UTF-8.  The modem service will have to convert internally no matter
what.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Wed, 2008-08-27 at 12:54 +0200, Pablo Martí wrote:

> On Thu, Jul 31, 2008 at 5:10 PM, Tambet Ingo <tambet@...> wrote:
> > Announcing ModemManager.
>
> The ModemManager announcement struck me on holidays, thats why I
> didn't say anything :)
>
> <snip>
> >
> > Q: You API sucks!
> > A: If there's something you'd like to change, either to add new
> > methods or to modify the existing ones, let me know, it's not set in
> > the stone.
>
> The Wader project has started to port its API to the one defined by
> ModemManager. While doing so we've got some input for the API design.
> The interfaces currently defined are too "flat":
>
> #define MM_DBUS_SERVICE              "org.freedesktop.ModemManager"
> #define MM_DBUS_PATH                 "/org/freedesktop/ModemManager"
> #define MM_DBUS_INTERFACE            "org.freedesktop.ModemManager"
> #define MM_DBUS_INTERFACE_MODEM      "org.freedesktop.ModemManager.Modem"
> #define MM_DBUS_INTERFACE_GSM_MODEM  "org.freedesktop.ModemManager.Modem.Gsm"
> #define MM_DBUS_INTERFACE_CDMA_MODEM "org.freedesktop.ModemManager.Modem.Cdma"
>
> This interfaces might be enough for ModemManager's purposes as MM is
> just interested on 5/6 commands, but for projects like Wader where we
> export 40+ methods this flat namespace is nothing but ideal. The
> exported methods could be grouped into five different areas:
>
> o.f.MM.M.G.Card
> o.f.MM.M.G.Contacts
> o.f.MM.M.G.Network
> o.f.MM.M.G.PIN
> o.f.MM.M.G.SMS
>
> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
>   - DisableEcho() ->
>   - EnableEcho() ->
>   - Enable(b enable) ->  (This is the Enable method of ModemManager, I
> think it goes here but I might be completely wrong here :)
>   - GetCharset -> s
>   - GetCharsets() -> as
>   - GetIMEI() -> s
>   - GetIMSI() -> s
>   - GetManufacturer() -> s
>   - GetModel() -> s
>   - GetVersion() -> s  (Firmware version)
>   - ResetSettings() ->  (ATZ)
>   - SetCharset(s charset) ->
>
> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
>   - Add(s name, s number) -> u
>   - Delete(u index) ->
>   - Find(s pattern) -> a(uss)
>   - Get(u index) -> (uss)
>   - GetPhonebookSize() -> u    (Could be renamed to GetSize() ?)
>   - List() -> a(uss)
>
> org.freedesktop.ModemManager.Modem.Gsm.Network:
>   - GetRegistrationStatus() -> (uu)    (AT+CREG?)
>   - GetInfo() -> (su)  (AT+COPS?)
>   - GetNames() -> a(ussuu)   (AT+COPS=?)
>   - GetRoamingIDs() -> as    (AT+CPOL?)
>   - GetSignalQuality() -> u
>   - SetRegistrationNotification(b enable) ->
>   - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
>   - RegisterWithNetID(s netid) ->
>
>   - CregReceived(u status) ->   (signal)
>   - SignalQuality(u rssi) ->   (signal)
>
> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>   - Change(s oldpin, s newpin) ->
>   - Check() -> u  (Returns the SIM auth state, to check it against an enum)
>   - Enable(s pin) ->
>   - Disable(s pin) ->
>   - Send(s pin) ->
>   - SendPUK(s puk, s pin) ->
>
> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
>   - Delete(u index) ->
>   - Get(u index) -> (ussd)        (The last double is the time when it
> was received)
>   - GetFormat() -> u   (AT+CPBF?)
>   - GetSMSC() -> s
>   - List() -> a(ussd)
>   - Save(s text, s number) -> u
>   - Send -> u
>   - SendFromStorage(u index)
>   - SetFormat(u format) ->
>   - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->   (AT+CNMI=mode,mt,..)
>   - SetSMSC(s smsc) ->
>
>   - SMSReceived(u index, s where)    (signal)
>
> This is just food for thought, what think about such an API the
> different parties involved?
> I've tried to clarify in parentheses all the methods that might be
> misleading or might be controversial, with either its purpose or the
> correspondent AT command. I think that standard interfaces such as
> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
> methods (specially its naming) are somewhat more controversial and
> I'll be happy to discuss 'em.
>
> I've attached this interfaces to the Gsm (WCDMA) part, we still need
> to decide what to do with CDMA... Dan? :)

For the moment for CDMA, just expose the minimal functionality for init,
dialing, hardware info (vendor, manufacturer, etc), signal RSSI, and add
GetESN() and GetMEID() methods (ESN/MEID are CDMA's IMEI).  We'll work
out the rest later once we find out how many of the CDMA modems actually
have open & accessible commands for these things.  I don't know anyone
that actually has a PIN on their CDMA card, and it's less useful there
since there's no SIM with CDMA anyway.

Some Sierra parts expose the GPS functionality though one of the TTY
interfaces with custom AT commands (yes, an AT command to get lat/long)
so maybe you want a org.freedesktop.ModemManager.GPS interface too :)
But that can come later.

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Tambet Ingo-2]

On Wed, Aug 27, 2008 at 6:17 PM, Pablo Martí <pmarti@...> wrote:

>>> org.freedesktop.ModemManager.Modem.Gsm.Network:
>>>  - GetRegistrationStatus() -> (uu)    (AT+CREG?)
>>>  - GetInfo() -> (su)  (AT+COPS?)
>>>  - GetNames() -> a(ussuu)   (AT+COPS=?)
>>>  - GetRoamingIDs() -> as    (AT+CPOL?)
>>>  - GetSignalQuality() -> u
>>>  - SetRegistrationNotification(b enable) ->
>>>  - SetInfoFormat(u mode, u format) -> (i.e. AT+COPS=3,0)
>>>  - RegisterWithNetID(s netid) ->
>>>
>>>  - CregReceived(u status) ->   (signal)
>>>  - SignalQuality(u rssi) ->   (signal)
>>
>> I think these are too low level. I'd much prefer the current ones from
>> ModemManager.
>
> You mean:
>  - Register("") -> Tries to register with your home network
>  - Register("24301") -> Tries to register with the given MNC
>
> I can agree in this two. "AT+COPS?" is a pretty useful command that
> you've (inadvertently) banned here :), ditto with "At+COPS=?" and
> "AT+CPOL?" when you have a buggy firmware/old SIM that does strange
> things while roaming...

I also meant:

GetRegistrationInfo() -> (uss)

The returned arguments mean:
u - Registration status: Idle:Home:Searching:Denied:Unknown:Roaming
s - Registered operator code
s - Registered operator long name

Which would be the union of a lot of commands you proposed.

>>> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>>>  - Change(s oldpin, s newpin) ->
>>>  - Check() -> u  (Returns the SIM auth state, to check it against an enum)
>>>  - Enable(s pin) ->
>>>  - Disable(s pin) ->
>>>  - Send(s pin) ->
>>>  - SendPUK(s puk, s pin) ->
>>
>> Not sure about these. Currently, Check() is part of
>> Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method
>> with a boolean argument. What's the difference (code wise) between
>> Send() and SendPUK()? So that would leave us with 3 methods:
>> Enable(bool), Send(string), Change(string, string). If so, maybe they
>> can be part of the Gsm.Card interface?
>
> Enable(b) sounds good to me. The difference between Send and SendPUK
> is that the former receives just one parameter (the pin), while the
> later receives two, the puk and the new PIN to set in the card. One of
> the advantages of having a separate interface is that CDMA devices
> cant just skip the .PIN interface. Otherwise they'll support half of
> .Card.

We're talking about the interfaces starting with
org.freedesktop.ModemManager.Gsm.* so CDMA can be ignored here.

Tambet
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list