RE: USSD interface for ModemManager
It's network and service dependant. So for UK, Holland, Greece, Egypt there are retry schedules for services. (Other Networks may have different Nodes from different vendors so I'm not 100% sure.) We defined a table on the HLR and MLR to control those schedules. The schedules are non linear and asymmetric. E.g. 0min, 30min, 1hr, 4hr and another may be 5min, 35min, 65min, 4hr+5min etc.. This means that if a VLR were to fall over then suddenly comes back up you don't start firing off millions of MWD to all subs on that node. I take your point and nice idea. My thoughts are what USSD will and are being used for. Very much a way of building services that pass through or over the core network. Meaning that the logic is really part of the service. We are building our PAYT features into the betavine client now for 4 of our networks. We have no plans to persist state or start receiving lost messages to infer state. All too complex!!! :-) So if the modem manager core was to spit out lost messages our client would just bin them and start from a known state. I know of no USSD service that is network initiated, but I don't know them all! India is the country that use this service most for obvious reasons. I'll make some enquires next week on some example services used in India utilising USSD and post a link here for anyone interested to read on the betavine web site. Hope this helps, kind regards Nicholas. -Original Message- From: Dan Williams [mailto:d...@redhat.com] Sent: 11 March 2010 23:25 To: Herriot, Nicholas, VF-Group Cc: networkmanager-list@gnome.org Subject: Re: USSD interface for ModemManager On Wed, 2010-03-10 at 13:23 +0100, Herriot, Nicholas, VF-Group wrote: Hi all, stick_head_above_parapit Just thought I'd put Vodafone's views forward. Pablo the API is fine, and I'm happy we mirror the ConnMan guys. I've been reading through their doc's and Ofono Stack. There is no need to over-work the USSD API. If the network sends a USSD message which requires action and get's no response it will either: 1) stick it on a retry queue. Any idea how often the network will retry? 2) don't action the request until it got a response. Ok; though depending on how long before the network retries, the client app may not get the request for at least the retry interval. I'd still rather have the client app be able to get that request immediately though, that just seems nicer. Furthermore, if a client starts up and see's a buffered/cached USSD message saying that you have to respond to subscribed to that new data service how would the client know what it's for? For that use case to These properties are for /network/-initiated requests, thus I assume that the request from the network includes all necessary details? Client-initiated requests would still use Initiate() of course. Or does the network initiate requests related to the client-initiated request? That model would have problems... work the client would have to persist the state - but in our example the app crashed so did not get to persist anything! -Message to Marcel- You are a very cheeky man! But very true! :-) -Message to Dan- Chill out you are still the incumbent! ;-) Competition is not a problem; it makes everyone better. The problem is lack of focus on the technical issues under discussion, instead sending mails the lists saying hey, use my project! it's awesome!. This list is about development of NetworkManager and ModemManager. It's fine to reference some other project, even competing ones, with respect to specific technical issues. It is not OK to evangelize other projects. (e.g. any reason why you are not using oFono.) Besides, I doubt Pablo is much interested in using oFono, since he works on a different modem manager and thus oFono is competing with Wader in the same way it competes with ModemManager. Which shows some misunderstanding on Marcel's part as to what the original USSD discussion was actually about. Good: oFono developed an API for USSD already, perhaps you should take a look at it to learn from the mistakes we made and the problems we encountered Bad: any reason why you are not using oFono. It is a full telephony stack and does a lot more things in the background that are mandatory. And you would not have to implement the whole USSD support all by yourself. Especially when we merge the integrated PPP support into oFono, then it might be a nice alternative for you actually. I think you can see the difference. Dan -Message to all- Vodafone are using wader-core to deliver a packaged modem manager, which is why Pablo has been asking about USSD. The reason why Vodafone have pursued it's coarse of action in regards to building their own modem manager and not use NM or CM directly are: 1)- The open source community do not have the time and resources to deliver the functionality with the huge range of manufacturers dongles. We are extended a hand to ensure
Re: USSD interface for ModemManager
Hi all, stick_head_above_parapit Just thought I'd put Vodafone's views forward. Pablo the API is fine, and I'm happy we mirror the ConnMan guys. I've been reading through their doc's and Ofono Stack. There is no need to over-work the USSD API. If the network sends a USSD message which requires action and get's no response it will either: 1) stick it on a retry queue. 2) don't action the request until it got a response. Furthermore, if a client starts up and see's a buffered/cached USSD message saying that you have to respond to subscribed to that new data service how would the client know what it's for? For that use case to work the client would have to persist the state - but in our example the app crashed so did not get to persist anything! -Message to Marcel- You are a very cheeky man! But very true! :-) -Message to Dan- Chill out you are still the incumbent! ;-) -Message to all- Vodafone are using wader-core to deliver a packaged modem manager, which is why Pablo has been asking about USSD. The reason why Vodafone have pursued it's coarse of action in regards to building their own modem manager and not use NM or CM directly are: 1)- The open source community do not have the time and resources to deliver the functionality with the huge range of manufacturers dongles. We are extended a hand to ensure that our datacards will work on Linux. We think that it's best served by putting our time into the device - plugin and operator feature set into the betavine connection manger. We have no wish to control or dominate anybody's Network Manger, but do wish to ensure our datacards and services work. To answer Marcel's question. We believe ConnMan is behind in areas of dongle support otherwise we would be using the USSD stack if possible (Why re-invent the wheel right!). We also are not sure how to incorporate our plugin modem architecture and many other features YET! - it would maybe take longer to do this than to add in USSD to wader-core. Our thoughts were to push forward with supporting Network Manager deliver a good modem manager experience till April time. If anyone wants to take any of this off line and ask me more of Vodafone's plans please ping me. This flame war stuff between NM and CM has to stop! Not good for Linux. Not good for OS. Not good for the community! Not professional! Regards, Nicholas. /stick_head_above_parapit On Tue, 2010-03-09 at 13:45 +0100, Pablo Mart? Gamboa wrote: Hi Dan, Marcel and others, we would like to extend the ModemManager API so that it can handle USSD commands. The USSD API of oFono [0] looks quite nice IMHO and I'd like to propose a similar API: I'd actually change two things; this API (and by extension the ofono one) doesn't allow clients to respond to a USSD request that is pending when they start up. Say your app sends the request, then crashes or something. When it's crashed, the network sends the response. Now your app can't get the response when it starts back up and handle it, it would have to cancel the USSD session and send the request again. A more robust API would change the NotificationReceived and RequestReceived signals into properties instead, which can be queried when your app starts up. See below... I did add a org.freedesktop.DBus.Properties.MmPropertiesChanged signal to ModemManager a bit ago, mainly to support the org.freedesktop.ModemManager.Modem.Enabled property. So we can certainly use that. USSD Interface === Service org.freedesktop.ModemManager Interface org.freedesktop.ModemManager.Modem.Gsm.Ussd Methods string Initiate(string command) Sends a USSD command string to the network initiating a session. When the request is handled by the appropriate node of the network, the method returns the response or an appropriate error. The network may be awaiting further response from the ME after returning from this method and no new command can be initiated until this one is cancelled or ended. void Respond(string reply) Send a response to the network either when it is awaiting further input after Initiate() was called or after a network-initiated request. void Cancel() Cancel an ongoing USSD session, mobile- or network-initiated. Signals NotificationReceived(string message) I would change this to a read-only NetworkNotification property, and then we can use the normal D-Bus properties API to get it, and the MmPropertiesChanged signal to notify when it changes. Signal is emitted on a network-initiated USSD request for which no response is needed. RequestReceived(string message) Same here, I'd suggest a read-only NetworkRequest property. Obviously when there is no request from the network, these two properties would be empty strings. Any thoughts on this? Dan Signal is emitted on a network-initiated USSD request for which a response must be sent using the Respond method unless it is cancelled or
RE: Problem with Simple.Connect
Dan,
If we could get some betavine developers to work on this, would you accept
fixes from us (Vodafone) into NM to get the issues addressed highlighted by
Pablo? Or should we wait for your team to help with this area?
We are just a bit concerned as we have demonstrations to give in the coming
weeks of our integration work with Wader.
Kind regards, Nicholas Herriot.
From: Pablo Martí Gamboa [mailto:pma...@warp.es]
Sent: 26 October 2009 12:36
To: Dan Williams
Cc: networkmanager-list@gnome.org; Tambet Ingo; Herriot, Nicholas, VF-Group
Subject: Re: Problem with Simple.Connect
2009/10/26 Pablo Martí Gamboa pma...@warp.es
2009/10/9 Dan Williams d...@redhat.com
On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
I forgot to mention that when I press Disconnect from
nm-applet,
that just issues an Enable(false) to the device rather than
Disconnect(); Enable(false);, I asked yesterday in #nm and
nobody
seemed to recall why that decision had been made, they just
remembered
that it was more reliable for a particular device. In my case
it is
the other way around! will nm0.8 ship like this?
Right now NM doesn't call disconnect at all, AFAIK. It just
calls
Enable(false). We assume that also cleans up the connection and
disables the modem, since disabling the modem implies the
connection is
torn down. Is that not working?
For projects like NM this behaviour is acceptable, between every
connection attempt you don't do any operations with the 3G device. However for
projects like Wader, this is an unfortunate change. Now when we issue a
DeactivateConnection, we get an Enable(false) sent to our device,
deactivating the radio and leaving the device unusable for some operations. Why
don't we stick to the original vocabulary? Enable(true); Connect(settings);
Disconnect(); Enable(false);
Right now the harm is already done, and we are going to have to ship
with a workaround for this behaviour (unless somehow the patch makes it into
the distros before 0.8, which for Ubuntu is already too late).
Please please, go back to the old behaviour.
I finally gave up and disabled NM compatibility, the reason is that NM does not
respect current ModemManager vocabulary and adding so many workarounds is
polluting my code:
* When a device is announce via DeviceAdded, NM sends right away two
Enable(0) (should be boolean). workaround #1
* When a Simple.Connect call is issued, NM sends right away two Enable(0)
(I assume that to make sure we are not connected) thus breaking my internal
state, workaround #2
* When I press Disconnect from nm-applet, it won't send a Disconnect,
it sends Enable(0) twice again. workaround #3
* When a Simple.Connect call is issued, NM does not bother to Enable(true)
the device, it assumes that the internal simple state machine will do it for
us. Not working around it :S
Also I'm having reliability problems with PPP devices and Simple.Connect, first
attempt will work (most of the time) but the second will never.
Bear in mind that I am not dissing anyone's work here, this is just a summary
of some of the problems that an alternate ModemManager implementor faces if she
strives for total compatibility. Hopefully in the future I'll be able to
re-enable the compatibility...
Best regards,
Pablo
BTW, how do you handle breaking into the ongoing PPP session on
a 1-port
modem and hanging up the connection? +++ATH? Or AT D1,
setting the
serial port's DTR to off and then ATH?
Dan
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Problem with Simple.Connect
I thought the +++ escape sequence was rarely used. I've read that it's usually disabled to avoid malfunction in case these characters are legitimately a part of the data stream? If this is a workaround where do people suggest the intelligence be placed? -Original Message- From: Eugene Crosser [mailto:cros...@average.org] Sent: 14 October 2009 07:05 To: Dan Williams Cc: Pablo Martí Gamboa; Herriot, Nicholas, VF-Group; networkmanager-list@gnome.org Subject: Re: Problem with Simple.Connect Dan Williams wrote: But with DTR and without ATH, isn't the connection still active? It thought DTR transitions just broke into command mode so you *could* run ATH. I didn't think they terminated an active data connection too... In the olden days of dialup modems, dropping DTR was the official way to terminate the connection. The sequence of pause+++pauseATH\r was considered a workaround, for the case when you had a three wire cable and the modem was configured to ignore (the absence of) DTR. Eugene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Mobile broadband: Franklin CDU 680
Hi, What make and model are the 3 USB modems that you are using? Kind regards, Nicholas Hi there. I'm running Ubuntu Jaunty with nm 0.7.0.100. I have some of these mobile broadband USB modems that I'm trying to make it work on ubuntu. The carrier is Iusacell (Mexico). I see that some support for this carrier was added to mobile-broadband-provider-info on October 2008 ( http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00366 .html ). In fact, I can see the carrier when I run the connection assistant: I select Iusacell from the lists of carriers, click accept and nothing happens. The modem is being detected as ttyUSB0. What else do I need to do to make it work? Regards, Noe nieto -- next part -- An HTML attachment was scrubbed... URL: http://mail.gnome.org/archives/networkmanager-list/attachments/20090619 /374d20b8/attachment.html -- ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list End of NetworkManager-list Digest, Vol 57, Issue 30 *** ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Network Manager's supported Modem list
I guess my question has already been answered. Network Manager does not have a strategy for testing and integration with different USB Modems to ensure compatibility. Which is understandable given the remit. I guess this should be work carried out between Hardware manufacturer and Network operators. What would be better would be: 1) A list of devices that have been tested and verified to work, with a list of tests that were carried out. (Community members could help with this.) 2) A list of devices that have unique 'code' in the application that are needed to handle them, coupled with the generic list. It's a shame there is no way for plugins to be written to cope with USB modem card differences as is done for the Betavine.net linux driver. (e.g. The product ID/ Vendor ID on some Huawei cards which are incorrect in purpose to get round an issue on Window machines.) This kind of thing could be handled in plugin maybe! .. ;-) ... I agree, it would help support guys everywhere. Kind regards, Nicholas. -Original Message- From: Peteris Krisjanis [mailto:pec...@gmail.com] Sent: 22 May 2009 08:46 To: Dan Williams Cc: Herriot, Nicholas, VF-Group; networkmanager-list@gnome.org Subject: Re: Network Manager's supported Modem list But it would be hard to make such list looking at the code? If not, I could try to make such list. It would help Linux support guys everywhere. Cheers, Peter 2009/5/21 Dan Williams d...@redhat.com: On Wed, 2009-05-20 at 14:11 +0200, Herriot, Nicholas, VF-Group wrote: Hi, Is there such a thing as Network Manager's supported USB Modem list? And if this is a 'no' what part of the code base do I look at to find out the supported modems? It depends on a few things... first, the kernel drivers having the IDs for the modems. In general, NM will support generic modems that use ATDT-style connection setup (ie, PPP). It also supports Option 'hso'-style modems that use OWAN-style call setup. As of 0.7.1, I think we've got support for most of the modems that are currently in wide use. We do occasionally find quirks (like Huawei CDMA modems from Reliance India that return COMMAND NOT SUPPORT instead of ERROR, for example). i.e. is there a 'conf' file with scripts for each modem? Nope, they are handled automatically in the code. Scripts aren't really flexible enough, or if they are, they turn into a programming language anyway. Dan Kind regards, Nicholas. Nicholas Herriot Web Technologies Researcher Vodafone Group RD - UK www.betavine.net www.betavine.mobi (from mobile) Mobile: +44 (0) 7717275049 Fax: +44 (0) 1635 686484 Vodafone Group Service Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN Registered in England No 3802001 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- mortigi tempo Pēteris Krišjānis ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: nm-tool doesn't show my mobile broadband card
Hi Jochen, What stick are you using? i.e. Make and model number? You can find that out with lsusb. Kind regards, Nicholas Herriot. Date: Fri, 8 May 2009 14:38:01 -0700 (PDT) From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: nm-tool doesn't show my mobile broadband card To: NetworkManager-list@gnome.org Message-ID: 23448718.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii Hi, I have a so-called web'n'walk stick. I managed to have it reported not as a USB drive, but as a modem by using usb_modeswitch: [...@mcjwi ~]$ hal-find-by-capability --capability=modem /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_0 /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_1 I also have created an entry under Mobile Broadband using nm-connection-editor. However, I can't get the stick to do any dial attempts. A possible reason might be, that nm-tool shows the Ethernet and Wireless devices, but not my modem. Any ideas, what might be wrong? Thanks, Jochen ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: pessimistic NetworkManager and off-line mode
Hi I'm new to NetworkManager Mailing list, I represent the guys at betavine http://www.betavine.net Having read this post I feel I have to add my bit in to the mix! NetworkManager will report online/offline state accurately for connections that are managed by NM. accurately, except for private networks, firewalls, etc. Which is probably OK. We also have major problems with our Modem connectivity software (see http://www.betavine.net/bvportal/web/linux_drivers for more info) and Ubuntu 9.04 where applications are not aware that our modem manager has made a connection. I've had a long discussion with Dan about this over the phone and would like to get other peoples opinions and ideas. There seems to be two methodologies around this: 1) You may have more than one connection manager (e.g. A Network Manager and a Modem Manger). Applications that run and require network connectivity would maybe ask Network Manager via D-Bus have you got a connection. If the answer is no, they move on to the Modem Manager and do the same thing. I'd like to hear peoples opinions on this? 2) Network manager has a way to pass connectivity information to it. (e.g. An API for an app to send info about a connection to Network Manager. Hence a Modem Manager could say I've made a connection, here are the details about this connection.). Network manager would then be the global manager of the connection and still be the single point of contact for apps to talk to when discovering connections on the system. As before I'd like to here peoples opinions on this. However, if NM is running and you still do your own connection stuff outside of NM it will not know that you are online and suggest that you are offline. Thanks for the clarification. I think one of problems lies in suggest, which actually sounds more like affirm. How hard would it be for NM to detect there are some non-managed interfaces? That does not seem like a lot to ask. Especially not hard in the NM_CONTROLLED=no case. I'd like to know this to. I've thought about this for some time now and I believe it's good to keep Network Manager at the centre of the universe. However, I can see how this starts to creek a little when the idea of A connection can be so vast! We have over 1/2 million downloads of our software on Netbooks and Laptops and our Forum posts are starting to fill up with people saying I can't get my Mobile Connect software to work with Ubunutu 9.04! Maybe I should tell them to contact the Network Manager team for help! :-) Kind regards, Nicholas Herriot. Cheers, Marc Nicholas Herriot Web Technologies Researcher Vodafone Group RD - UK www.betavine.net www.betavine.mobi (from mobile) Mobile: +44 (0) 7717275049 Fax: +44 (0) 1635 686484 Vodafone Group Service Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN Registered in England No 3802001 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
