Re: GPRS support for Ofono
Hi Remi, I haven't had time to look at the context stuff yet. It's just worse. oFono is enforcing an integer ID on any primary context. This is again an idiosyncrasy of AT commands. With ISI modems, the context ID space is managed by the modem, so oFono does not get to choose. In theory, I could remap those, but that really would not make sense. there has to be a mapping on some level. At least one driver has to do some sort of mapping. If you have a better idea to handle it in the core daemon, please propose something. Please remember that non of us have the ISI specification and until you guys communicate these details with us, we go based on what public specifications are using. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann mar...@holtmann.org wrote: since we have the upstream GPRS support for MBM and HSO devices, it would be great to have this for Phonet, too. I tried to work on the patch, but without proper documentation it is impossible. So please adapt it to the current upstream and resend it. I can't quite implement the current API for ISI modem. For a start, ofono is currently crashing in setpowered as soon as it sees an ISI modem. But there are some more fundamental issues. First, the ISI General Packet Data Service does not provide any location informations (roaming/not roaming, area code, cell ID). And I must say I don't understand why this is part of the GPRS atom. This has nothing to do with packet data. Second, I couldn't figure how to handle auto-attach. The ISI protocol supports it, but I could not find the driver callback. Thus, I would have to force the device into manual mode. This is going to be an issue as some operators require auto-attach Also, it prevents optimizing context activation when detached, i.e. follow on GPRS attach, which the ISI modem provides. I haven't had time to look at the context stuff yet. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
- Message d'origine - But there are some more fundamental issues. First, the ISI General Packet Data Service does not provide any location informations (roaming/not roaming, area code, cell ID). And I must say I don't understand why this is part of the GPRS atom. This has nothing to do with packet data. That is because 3GPP in their infinite wisdom structured the spec this way. Just because AT commands group both pieces of unrelated data does not mean it is a good idea. I fail to see why the DBus and driver API should do the same mistake as 3GPP 27.007. There are 2 registration states, one reported by CREG and one reported by CGREG. Both report essentially the same information, namely registration status, lac, cellid and radio access technology. The way we know an AT-command based modem is attached is when we start receiving these CGREG indications (registered/roaming + lac/ci/rat) A device cannot attach to GPRS an a different network than the one it is registered with. I do not see the value of tying those in oFono. The caller can use the network registration interface, and in fact, I think it should. I am not an expert on GPRS internals but I guess the protocol does not provide those values, and this is just a misdesign of AT commands. I'm open to suggestions on how to fix this (for instance we can get rid of Status, LocationAreaCode, CellId attributes, since they're essentially the same as in NetworkRegistration interface), but for now this can be easily faked by just re-using the information you're providing to netreg atom. I could steal that data, but it would be vomitively ugly. Worse, it would be hide a race condition through the DBus interface. There is no way for me to request both atomically. Second, I couldn't figure how to handle auto-attach. The ISI protocol supports it, but I could not find the driver callback. Thus, I would have to force the device into manual mode. This is going to be an issue as some operators require auto-attach Is this where the network requests an attach or are you talking about something else? No no, I am not talking about network-initiated context *activation*. I am talking about the requirement from some operator that the device be always *attached* even if it has no active contexts. Note that the battery impact is negligible. Also, this is NOT quite the same as attaching when oFono starts: the device could be outside of the GPRS network; auto-attach will get it attached as soon as possible. Rémi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Rem, That is because 3GPP in their infinite wisdom structured the spec this way. Just because AT commands group both pieces of unrelated data does not mean it is a good idea. I fail to see why the DBus and driver API should do the same mistake as 3GPP 27.007. I already told you I'm open to fixing it. However 27.007 is the only standard we have right now. There are 2 registration states, one reported by CREG and one reported by CGREG. Both report essentially the same information, namely registration status, lac, cellid and radio access technology. The way we know an AT-command based modem is attached is when we start receiving these CGREG indications (registered/roaming + lac/ci/rat) A device cannot attach to GPRS an a different network than the one it is registered with. I do not see the value of tying those in oFono. The caller can use the network registration interface, and in fact, I think it should. Different network probably not, but different base station? Again I'm not the expert here either. The API was posted for review back in early September, and Nokia participated in the design. If someone can give a definitive answer we can look into making our API more sane. I'm open to suggestions on how to fix this (for instance we can get rid of Status, LocationAreaCode, CellId attributes, since they're essentially the same as in NetworkRegistration interface), but for now this can be easily faked by just re-using the information you're providing to netreg atom. I could steal that data, but it would be vomitively ugly. Worse, it would be hide a race condition through the DBus interface. There is no way for me to request both atomically. What race condition? The attach callback does not mean we're attached at that point, it just means we're trying to. Attached status only comes in once we're 'registered' to GPRS, so you can safely query whatever you need and then call ofono_gprs_status_notify Is this where the network requests an attach or are you talking about something else? No no, I am not talking about network-initiated context *activation*. I am talking about the requirement from some operator that the device be always *attached* even if it has no active contexts. Note that the battery impact is negligible. Also, this is NOT quite the same as attaching when oFono starts: the device could be outside of the GPRS network; auto-attach will get it attached as soon as possible. I believe the current API already covers this. Context active state and attached state are tracked separately. Thus you can be attached with no active context, I do it all the time. Can't you just turn on your 'auto- attach' mode when oFono calls 'set_attached' with TRUE and turn off attachment when oFono calls 'set_attached' with FALSE? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, - Message d'origine - I already told you I'm open to fixing it. However 27.007 is the only standard we have right now. That's easy to fix. Remove those from the GPRS status. The core only reports these attributes, it doesn't actually use them for anything. When attached you can simply send a status=registered, LAC, CellId and Tech set to -1. We can see about removing these a bit later. Different network probably not, but different base station? Again I'm not the expert here either. The API was posted for review back in early September, and Nokia participated in the design. That is not possible either to our understanding. If it were possible, the ISI modems would expose that data separately, which they don't. I suspect you're right. I believe the current API already covers this. Context active state and attached state are tracked separately. Thus you can be attached with no active context, I do it all the time. Can't you just turn on your 'auto- attach' mode when oFono calls 'set_attached' with TRUE and turn off attachment when oFono calls 'set_attached' with FALSE? That is different. If you are outside of coverage, or in a non-GPRS area, you can turn auto-attach on. That will make some operators happy but it wont't attach just yet. Sorry I don't see a practical difference. You set 'Powered' to TRUE, gprs atom issues a 'set_attached' with TRUE. Once you have attached the driver sends out a ofono_gprs_status_notify. Whether this happens in 1 second or 2 hours doesn't really matter. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
- Message d'origine - Again, I don't see a point of exposing this to the user. Worst case we can always add intelligence / heuristics to oFono to attempt re-attaching periodically. We have to solve this for all modems, since there are no such 'auto-attach' semantics in 27.007. If it comes to the question of usefulness, I find the current attach/detach to be even more useless than always-attach/demand-attach. AT modems will attach automatically when a context is activated, so do ISI modems (when adequately configured), and foobar modems could always emulate it (from inside their context API). I agree that auto-attach is not of much use to end-users, for the exact same reason that attach is not very useful. But it is apparently of use to network operators at least. One strategy you can use today is to just activate auto-attach when the driver is asked to attach and force a detach when the driver is asked to detach. This is essentially the behavior of most AT command modems. Sure. ISI modems can do that too. And I argue it makes manual attach/detach even more useless than auto-attach. I'd note that flight mode requires deregistering from the network as a whole, not just detaching from GPRS anyway. So I can implement the current attach/detach logic, but it seems not very pertinent to me as an API. I have two suggestions here: 1. Lets make it work first, we can then make it work better. 2. Can you describe these optimizations and suggest how the API/behavior can be changed to take advantage of them? We just need to know if the core or the upper-layer application intends to activate a context. It is a boolean flag hint to Attach basically. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Ismo, since we have the upstream GPRS support for MBM and HSO devices, it would be great to have this for Phonet, too. I tried to work on the patch, but without proper documentation it is impossible. So please adapt it to the current upstream and resend it. Yes, the GPRS ISI support has been delayed. Because the internal API between the Ofono GPRS atom and the modem driver was changed, the ISI driver won't work out of the box. I have been recently quite busy with other tasks, but I'll try to find the time to do the porting or preferably get Rémi to do it. :-) Since the ISI GPRS support was already demonstrated to be working, the actual work amount shouldn't be too big. I tried it by myself, but without the ISI specification, it is a pretty big effort. So we rely on you guys to do it. Do you have any estimate when this could be achieved. I am asking because this feature is also useful for desktop users wanting to attach their Nokia phone just for Internet access. Better than Dialup and PPP since they would get proper signal strength etc. with it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Tue, 01 Sep 2009 15:42:40 -0700, Marcel Holtmann mar...@holtmann.org wrote: Our current assumption is that the basic setup of IP address, netmask and broadcast are done by oFono. Only routing and DNS are up to other programs like ConnMan for example. WHAAT? No way. There is just no way. We need to support letting the calling program configure the routing parameters manually. For instance, if we want to connect to multiple primary access points, it simply won't work if Ofono configures everything. Instead, we need to either setup source routing or separate network name-spaces. Ofono does not know what the caller intends to do with the APN (and should not need to), so it cannot configure IP parameters. Besides, it makes very little if any sense to configure IP parameters but not DNS. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, Our current assumption is that the basic setup of IP address, netmask and broadcast are done by oFono. Only routing and DNS are up to other programs like ConnMan for example. WHAAT? No way. There is just no way. We need to support letting the calling program configure the routing parameters manually. For instance, if we want to connect to multiple primary access points, it simply won't work if Ofono configures everything. Instead, we need to either setup source routing or separate network name-spaces. Ofono does not know what the caller intends to do with the APN (and should not need to), so it cannot configure IP parameters. Besides, it makes very little if any sense to configure IP parameters but not DNS. personally I don't care who finally sets the IP for the interface. It really just makes no difference. What problem do you see if oFono would set the IP address on that newly created interface that is up and running now? My point is that gateway and DNS is out of the question for oFono. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 02:16:40 -0700, Marcel Holtmann mar...@holtmann.org wrote: Hi Remi, Our current assumption is that the basic setup of IP address, netmask and broadcast are done by oFono. Only routing and DNS are up to other programs like ConnMan for example. WHAAT? No way. There is just no way. We need to support letting the calling program configure the routing parameters manually. For instance, if we want to connect to multiple primary access points, it simply won't work if Ofono configures everything. Instead, we need to either setup source routing or separate network name-spaces. Ofono does not know what the caller intends to do with the APN (and should not need to), so it cannot configure IP parameters. Besides, it makes very little if any sense to configure IP parameters but not DNS. personally I don't care who finally sets the IP for the interface. It really just makes no difference. What problem do you see if oFono would set the IP address on that newly created interface that is up and running now? Then the application cannot influence the way it's done. That's the whole point. Maybe I want to migrate the interface in a new namespace. For that, it must (1) create the interface, (2) migrate it, (3) configure it, in that order. So Ofono cannot do (3) if it cannot do (2), and it certainly should not do (2) by itself. So it has to stick to (1). -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Ismo, of this discussion. I'd like all interested to comment. What needs improvement? What is missing? What should be removed? Here are some comments. Some of the comments were already present in the IRC discussion, but I'll repeat them here anyway. First of all, the both Denis's proposal and mine look quite much the same -- the basic objects are the GPRS manager and the PDP contexts, and they offer quite the same functionality. Please correct me if I understood some parts of Denis's proposal incorrectly. The big differences between the API proposals are the creation and connecting of the contexts and the handling of the attached/detached state. I'll try to address the both issues below. In this proposal the contexts PDP contexts are persistent on the device, meaning that they stay there also when Ofono is shut down. The idea is that the contexts are made to Ofono by the GPRS provisioning programs or by the UI, and then ConnMan or another upper layer needs just to activate the context to actually do the connection. In my proposal I thought that the higher layer components would keep track of the access points and call the Connect() method with the suitable connection parameters. This is a philosophical difference from the provisioning point of view. An operator will likely support multiple configured access points, and the provisioning program should know their purpose from the configuration file (internet/MMS/WAP/...). This metadata is not there in the Ofono context, meaning that the provisioning program needs to store somewhere else the mapping between Ofono context object paths and the neccessary metadata. This begs the question: why not store all connection data (APN, authentication data, other metadata) to this external store in the first place? I mentioned that already. We do wanna store something like Type that says internet, mms, wap etc. The only comment here was that for network initiated context we have no idea of its intent. The attachment to the GPRS network in this proposal is bit vague. To my understanding, to attach the GPRS you need to set Powered property on and RoamingAllowed on. To detach you need to set the Powered property off. Since attaching can take a long time (or fail), does this mean that the attach errors are handled in the Powered property setter callback? Or what happens when (during roaming) the Powered is already on and the user puts the RoamingAllowed on -- where are the attach errors handled? I kind of think that it might be a better idea to just expose the GPRS registration status and the attach status, and let a higher level component explicitly set the attach/detach with either a readwrite property or Attach() and Detach() methods. Powered = on and RoamingAllowed = yes and Roaming = true will lead to auto-attach. Powered = on and RoamingAllowed = no and Roaming = true will lead to detach. Powered = on and Roaming = false will lead to auto-attach. Powered = off will lead to detach. We are not going to expose Attach() or Detach() method. As explained there are global anyway and so pointless to expose. This can be handled in the background without bothering the higher level application with these details. In my proposal the Status variable was a three-state variable, having the states attached, detached and suspended. Suspended was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the suspended status was not supported by spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? Still one difference to my proposal was the dropping of the TX and RX byte counts, and the explanation that those statistics would be handled by the upper layers by reading the values from the network interface. I mentioned the problem where the connection was terminated by the network and the network interface was brought down before the upper layer had a chance to read the values. After giving the matter some thought, I still feel that for this reason the modem driver would need to get the TX/RX data and send it to the upper levels, if at all possible. Since many operators charge by the amount of data transferred, not losing the TX/RX data is quite crucial. At least Nokia phones
Re: GPRS support for Ofono
On Wed, 02 Sep 2009 05:02:46 -0700, Marcel Holtmann mar...@holtmann.org wrote: I mentioned that already. We do wanna store something like Type that says internet, mms, wap etc. The only comment here was that for network initiated context we have no idea of its intent. And we do not want to. The attachment to the GPRS network in this proposal is bit vague. To my understanding, to attach the GPRS you need to set Powered property on and RoamingAllowed on. To detach you need to set the Powered property off. Since attaching can take a long time (or fail), does this mean that the attach errors are handled in the Powered property setter callback? Or what happens when (during roaming) the Powered is already on and the user puts the RoamingAllowed on -- where are the attach errors handled? I kind of think that it might be a better idea to just expose the GPRS registration status and the attach status, and let a higher level component explicitly set the attach/detach with either a readwrite property or Attach() and Detach() methods. Powered = on and RoamingAllowed = yes and Roaming = true will lead to auto-attach. That's just _idiotic_ from the naming perspective. A modem can have radio on or off. Whether this is done by completely powering the modem off, or by going into some kind of flight mode, is driver-specific. Hence the powered name is semantically wrong. When possible, it's actually best to keep the modem in flight mode, so that e.g. the SIM is still usable. The story is basically the same with roaming. Roaming means you are outside your home network. It does not mean that you want to auto-attach or not. Some people _never_ want to auto-attach, and some people _always_ want to auto-attach. In fact, different operators have different requirements with that regard. Sure, some people want to auto-attach if and only if not roaming. Given that roaming is not just about GPRS, the name is wrong and confusing. But more importantly, we need t support turning the radio on while in the home network yet _not_ attach automatically. This has operator requirements as well as power saving implications. We are not going to expose Attach() or Detach() method. And we are going to expose it. I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why Internet is momentarily broken. It's as simple as that. Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. (...) This is for ConnMan or similar to figure out. And we can always count via netfilter or some other facility. Counting inside oFono makes no sense. However we could send out a statistics signal before taking the interface down if it would be really needed. Making it part of the properties and having to poll for it is wrong. This has legal(ish) implications related to charging. Skipping this is not exactly an option (for a device vendor). I actually agree that this is ugly in some ways. In theory, I don't really care if Ofono or the over-lying connection manager takes care of it. *But* we even need to collect statistics for contexts not handled in Ofono (e.g. Windows PC tethering). And I doubt that Connman would be able to do that properly. It's ugly and annoying, but we have to suck it up. As I said, I think that the differences between this proposal and mine are mostly philosophical -- should the context data be stored in Ofono or in the upper layers of the stack? And should Ofono set the policies (for instance the roaming case) or just act as a low-level interface to the GPRS functionality? While oFono is sort of low-level, it is not that low-level. If it would we could expose the native AT commands. So in summary the PDP context are stored persistently in oFono. Like BlueZ remember paired devices. I fail to see how providing a direct low-level interface would prevent us from providing _also_ a higher-level interface. The later can handle provisioning and data persistence. -- Rémi Denis-Courmont ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, Powered = on and RoamingAllowed = yes and Roaming = true will lead to auto-attach. Powered = on and RoamingAllowed = no and Roaming = true will lead to detach. Powered = on and Roaming = false will lead to auto-attach. Powered = off will lead to detach. Why is auto-attach dependent on roaming? power consumption. No need to attach if you don't wanna allow data roaming. We are not going to expose Attach() or Detach() method. As explained there are global anyway and so pointless to expose. This can be handled in the background without bothering the higher level application with these details. AFAIK, attach status of GPRS has both regulatory aspects to consider (some operators require always attached vs. some prohibit it) as well as power consumption issues (auto-attach might draw more power than on-demand, although there's an inverse effect on latency). These are issues you need to take into account, and higher layers in the stack definitely *need* to be aware of as well. Also, I don' t think oFono is the correct place for these decisions - better expose a necessary API and let upper layers deal with it. I disagree. We can have a config option that always attaches or attached on demand, but this should not be exposed to any higher level applications. In general, I appreciate the attempt to hide ugly details from applications, but unfortunately some things can't well be hidden. Another unrelated, but similar issue is network scanning. It just isn't going to work without us exposing it in the D-Bus API explicitly. The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Now, there is no way we can have GPRS suspend without warning just because the stack deems it necessary to scan for networks. Again the intention is good, but the end result not so good. I don't want to start patching oFono to support this type of basic stuff. I mentioned this before. We might need to add a config option to allow integrators choose different behavior. In my proposal the Status variable was a three-state variable, having the states attached, detached and suspended. Suspended was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the suspended status was not supported by spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? You will find that practically every Nokia phone behaves this way, i.e., you make a call in 2G, and the UI will inform you that GPRS is suspended while on call. So what is the difference signaling a disconnect and re-connect to the application? Still one difference to my proposal was the dropping of the TX and RX byte counts, and the explanation that those statistics would be handled by the upper layers by reading the values from the network interface. I mentioned the problem where the connection was terminated by the network and the network interface was brought down before the upper layer had a chance to read the values. After giving the matter some thought, I still feel that for this reason the modem driver would need to get the TX/RX data and send it to the upper levels, if at all possible. Since many operators charge by the amount of data transferred, not losing the TX/RX data is quite crucial. At least Nokia phones have a GPRS data counter feature, that is supposed to show the transferred data. This said, I know that not all modem drivers can get the data from a connection that has been terminated by the network, but that does not mean that the modem drivers that can get the data should just discard it. This is for ConnMan or similar to figure out. And we can always count via netfilter or some other facility. Counting inside oFono makes no sense. However we could send out a statistics signal before taking the interface down if it would be really needed. Making it part of the properties and having to poll for it is wrong. I believe emitting a signal was Ismo's original proposal. I will talk with Stephen and David about this and what it a proper way to collect
Re: GPRS support for Ofono
Hi Remi, I mentioned that already. We do wanna store something like Type that says internet, mms, wap etc. The only comment here was that for network initiated context we have no idea of its intent. And we do not want to. The attachment to the GPRS network in this proposal is bit vague. To my understanding, to attach the GPRS you need to set Powered property on and RoamingAllowed on. To detach you need to set the Powered property off. Since attaching can take a long time (or fail), does this mean that the attach errors are handled in the Powered property setter callback? Or what happens when (during roaming) the Powered is already on and the user puts the RoamingAllowed on -- where are the attach errors handled? I kind of think that it might be a better idea to just expose the GPRS registration status and the attach status, and let a higher level component explicitly set the attach/detach with either a readwrite property or Attach() and Detach() methods. Powered = on and RoamingAllowed = yes and Roaming = true will lead to auto-attach. That's just _idiotic_ from the naming perspective. A modem can have radio on or off. Whether this is done by completely powering the modem off, or by going into some kind of flight mode, is driver-specific. Hence the powered name is semantically wrong. When possible, it's actually best to keep the modem in flight mode, so that e.g. the SIM is still usable. The story is basically the same with roaming. Roaming means you are outside your home network. It does not mean that you want to auto-attach or not. Some people _never_ want to auto-attach, and some people _always_ want to auto-attach. In fact, different operators have different requirements with that regard. Sure, some people want to auto-attach if and only if not roaming. Given that roaming is not just about GPRS, the name is wrong and confusing. But more importantly, we need t support turning the radio on while in the home network yet _not_ attach automatically. This has operator requirements as well as power saving implications. you did read the API docs Denis send around? These are not global Powered and RoamingAllowed properties. They are specific to the GPRS Manager and thus have specific meaning in that context. It has nothing to do with flight mode or radio off. And for the different operator policy/behavior, that should be configured via config option and not via D-Bus. The integrator should make a choice. It it is a list of mappings of operator = attach policy, then that is also fine. We are not going to expose Attach() or Detach() method. And we are going to expose it. And for what good is this. So we have two applications fighting about Attach and Detach and some weird policy somewhere upper in the stack with no real sense on what is happening. Sorry but I am not buying this at all. If the only argument is that different providers require different auto-attach policies then we have that as described via a config option and be done with it. Otherwise I like to see real examples where something like ConnMan, an MMS application or any other application need control over the attach status. I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why Internet is momentarily broken. It's as simple as that. Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some suspended state. (...) This is for ConnMan or similar to figure out. And we can always count via netfilter or some other facility. Counting inside oFono makes no sense. However we could send out a statistics signal before taking the interface down if it would be really needed. Making it part of the properties and having to poll for it is wrong. This has legal(ish) implications related to charging. Skipping this is not exactly an option (for a device vendor). I actually agree that this is ugly in some ways. In theory, I don't really care if Ofono or the over-lying connection manager takes care of it. *But* we even need to collect statistics for contexts not handled in Ofono (e.g. Windows PC tethering). And I doubt that Connman would be able to do that properly. It's ugly and annoying, but we have to suck it up. As I mentioned it before. We figure something out. We do have the same problem for all hotplug network devices. Especially with hotplug 3G dongles, we need to do something better than counting by ourself. The kernel should do it for us. If you yank the dongle,
Re: GPRS support for Ofono
Hi Ismo, This is a philosophical difference from the provisioning point of view. An operator will likely support multiple configured access points, and the provisioning program should know their purpose from the configuration file (internet/MMS/WAP/...). This metadata is not there in the Ofono context, meaning that the provisioning program needs to store somewhere else the mapping between Ofono context object paths and the neccessary metadata. This begs the question: why not store all connection data (APN, authentication data, other metadata) to this external store in the first place? Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. In my proposal the Status variable was a three-state variable, having the states attached, detached and suspended. Suspended was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the suspended status was not supported by So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) Still one difference to my proposal was the dropping of the TX and RX byte counts, and the explanation that those statistics would be handled by the upper layers by reading the values from the network interface. I mentioned the problem where the connection was terminated by the network and the network interface was brought down before the upper layer had a chance to read the values. After giving the matter some thought, I still feel that for this reason the modem driver would need to get the TX/RX data and send it to the upper levels, if at all possible. Since many operators charge by the amount of data transferred, not losing the TX/RX data is quite crucial. At least Nokia phones have a GPRS data counter feature, that is supposed to show the transferred data. This said, I know that not all modem drivers can get the data from a connection that has been terminated by the network, but that does not mean that the modem drivers that can get the data should just discard it. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. Nokia hardware supports this explicitly, but many others don't. I don't want nasty kludges inside oFono to enable this. Btw, is the context API missing the PDP type (IPv4 or IPv6)? I left this out explicitly since I've never seen anything besides IP being used. But we can add this easily enough if there's need. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Denis, 2009/9/2 Denis Kenzior denk...@gmail.com: So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. Ahem. Just like access selection mode is not in 27.007, yet Nokia has it, and most AT modems have proprietary commands to query and set it [1]. Maybe you call that the necessary exception to the rule, but I think we might as well change the rule to: If a feature is explicitly requested by users of oFono, and can be reasonably provided by modems that have it without braking those that don't have it, it will be supported. And 27.007 can go fsck itself. ;-) spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) You want the UI to implement this heuristic, when the modem plugin has explicit knowledge of that state, but isn't telling? Please explain how that makes the UI simpler? Cheers, Aki [1] http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, We are not going to expose Attach() or Detach() method. As explained there are global anyway and so pointless to expose. This can be handled in the background without bothering the higher level application with these details. AFAIK, attach status of GPRS has both regulatory aspects to consider (some operators require always attached vs. some prohibit it) as well as power consumption issues (auto-attach might draw more power than on-demand, although there's an inverse effect on latency). These are issues you need to take into account, and higher layers in the stack definitely *need* to be aware of as well. Also, I don' t think oFono is the correct place for these decisions - better expose a necessary API and let upper layers deal with it. I know you guys are coming from mobile phone perspective, but that one isn't the only scenario. We have netbooks/laptops with gprs data cards to consider as well. Hardcoding operator requirements is also not an option, since SIM cards can be changed. I fundamentally disagree that the logic should be in the higher layers. oFono has all the information to handle this, and can be hinted on what is appropriate behavior easily enough. oFono should simply store the auto-attach preferences in its IMSI-indexed preference store. The operator can bootstrap these preferences if required. In general, I appreciate the attempt to hide ugly details from applications, but unfortunately some things can't well be hidden. Another unrelated, but similar issue is network scanning. It just isn't going to work without us exposing it in the D-Bus API explicitly. Modem drivers will have some control over whether the scan is performed automatically, but denying the capability for everyone is not the right thing to do either. The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit : Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. This is not going to work. Depending on the operator, you may have more than one type for a single context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. Internet with only Web and Internet with full IP). As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. I have a feeling this does not work either. If I upgrade my subscription, the APN may change while not the IMSI, no? In my proposal the Status variable was a three-state variable, having the states attached, detached and suspended. Suspended was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the suspended status was not supported by So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. Our general rule is that if we have a UI requirement, or better an actual use case for it, we support it. Suspended GPRS fits both. spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) Is this some kind of joke? Don't you know the difference between pause and stop on your MP3 player and between suspend to memory and power off on your computer? Second guessing does not fit in my definition of easy to use self- documenting for an API. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. There is no way some random userland interface application can do it just by requesting the kernel, since it cannot know when to request those statistics. Nokia hardware supports this explicitly, but many others don't. That's irrelevant. Hardware support helps in the sense that it can include statistics for contexts external to Ofono. If the hardware does not support it, then it needs to be done manually in the GPRS middleware. That won't make the requirement go away. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
2009/9/2 Denis Kenzior denk...@gmail.com: AFAIK, attach status of GPRS has both regulatory aspects to consider (some operators require always attached vs. some prohibit it) as well as power consumption issues (auto-attach might draw more power than on-demand, although there's an inverse effect on latency). These are issues you need to take into account, and higher layers in the stack definitely *need* to be aware of as well. Also, I don' t think oFono is the correct place for these decisions - better expose a necessary API and let upper layers deal with it. I know you guys are coming from mobile phone perspective, but that one isn't the only scenario. We have netbooks/laptops with gprs data cards to consider as well. Hardcoding operator requirements is also not an option, since SIM cards can be changed. I fundamentally disagree that the logic should be in the higher layers. oFono has all the information to handle this, and can be hinted on what is appropriate behavior easily enough. oFono should simply store the auto-attach preferences in its IMSI-indexed preference store. The operator can bootstrap these preferences if required. Operator requirements were only half of the story. You need to be able to disable auto-attach in low power conditions, and this logic definitely doesn't belong in oFono. This applies equally well to mobile phones as it does to laptops/netbooks. In general, I appreciate the attempt to hide ugly details from applications, but unfortunately some things can't well be hidden. Another unrelated, but similar issue is network scanning. It just isn't going to work without us exposing it in the D-Bus API explicitly. Modem drivers will have some control over whether the scan is performed automatically, but denying the capability for everyone is not the right thing to do either. Agree, and I don't think that was what I was suggesting either. The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. +1 Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit : Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. This is not going to work. Depending on the operator, you may have more than one type for a single context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. Internet with only Web and Internet with full IP). Worst case we make the field completely freeform. Right now we really only care about internet type for connman. As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. I have a feeling this does not work either. If I upgrade my subscription, the APN may change while not the IMSI, no? Yes, but then you will probably receive an SMS/OTA message with new connection details. Which either oFono or some external application will apply to your GPRS settings. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. The rx/tx counter not being reported via PropertyChanged is also a bad idea since it breaks our API conventions. I can deal with a one-time signal being emitted when the interface has gone away though. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why Internet is momentarily broken. It's as simple as that. +1 Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some suspended state. IF_OPER_DORMANT seems a more accurate reflection of the state. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Waldo, I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The cases you describe imply that oFono is not even in control of the gprs context. How would we track/report the tx/rx statistics in that case? The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. I don't disagree, but not every modem can track these statistics and this isn't described by 27.007. I suggest the initial support should be enabled by the modem driver implementing a custom D-Bus interface and expose these details however it wishes. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The cases you describe imply that oFono is not even in control of the gprs context. How would we track/report the tx/rx statistics in that case? It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. I don't disagree, but not every modem can track these statistics and this isn't described by 27.007. I suggest the initial support should be enabled by the modem driver implementing a custom D-Bus interface and expose these details however it wishes. The modem driver has no desires of its own :-) It really comes down to what the UI needs and I doubt that the UI wants to deal with this on a modem by modem basis, but sure it's a possibility. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Aki, AFAIK, attach status of GPRS has both regulatory aspects to consider (some operators require always attached vs. some prohibit it) as well as power consumption issues (auto-attach might draw more power than on-demand, although there's an inverse effect on latency). These are issues you need to take into account, and higher layers in the stack definitely *need* to be aware of as well. Also, I don' t think oFono is the correct place for these decisions - better expose a necessary API and let upper layers deal with it. I know you guys are coming from mobile phone perspective, but that one isn't the only scenario. We have netbooks/laptops with gprs data cards to consider as well. Hardcoding operator requirements is also not an option, since SIM cards can be changed. I fundamentally disagree that the logic should be in the higher layers. oFono has all the information to handle this, and can be hinted on what is appropriate behavior easily enough. oFono should simply store the auto-attach preferences in its IMSI-indexed preference store. The operator can bootstrap these preferences if required. Operator requirements were only half of the story. You need to be able to disable auto-attach in low power conditions, and this logic definitely doesn't belong in oFono. This applies equally well to mobile phones as it does to laptops/netbooks. this a different requirement. Where do you get your low power information from? I would prefer that we add a plugin that gets informed of this low power situation and then is able to adjust such things. I am against exposing this in user application/UI API. I am with you that such requirements have to be met, but not via the D-Bus API. So these kind of policy details are device/manufacturer specific and having a custom plugins that can be enabled by the integrator sounds best to me if a config file is not flexible enough. In general, I appreciate the attempt to hide ugly details from applications, but unfortunately some things can't well be hidden. Another unrelated, but similar issue is network scanning. It just isn't going to work without us exposing it in the D-Bus API explicitly. Modem drivers will have some control over whether the scan is performed automatically, but denying the capability for everyone is not the right thing to do either. Agree, and I don't think that was what I was suggesting either. The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. +1 Sounds like a plan. So we do need an /etc/ofono/main.conf :) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
Hi Waldo, I am still not seeing the point in what suspended will do for us and the UI. And that Maemo 5 exposed such a state in the UI is not an argument to keep doing it. I asked this before, what are we suppose to be doing when we get signaled suspended? User, as well as intelligent (connectivity-aware) applications, need to know about this so that they understand why Internet is momentarily broken. It's as simple as that. +1 they need to know if they can do something useful with this information. If not, then this state is just pointless. However the D-Bus API is the wrong location for this detail. Oh we could also use the network device carrier flag, and then use Netlink (and we probably should do that too), but we all know how horrible Netlink is from userland. Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some suspended state. IF_OPER_DORMANT seems a more accurate reflection of the state. Yep. That sounds good. We don't use that in ConnMan right now, but that can be fixed of course. I still need to figure out what we are suppose to do when this gets signaled to us. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Marcel, The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. +1 Sounds like a plan. So we do need an /etc/ofono/main.conf :) So my current thinking is to introduce a method to NetworkRegistration property called 'ProposeOperatorScan' and a new property called 'OperatorScanInterval'. The driver api can then support a (non-standard *gasp*) option to say whether this scan was initiated actively or not. Maybe the Nokia modems can use this information not to drop the GPRS link if it isn't an active scan being performed. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, Actually this one is missing from the API proposal. Marcel already wanted the context type (internet, mms, wap, etc) information. I've updated the proposed API in git. This is not going to work. Depending on the operator, you may have more than one type for a single context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g. Internet with only Web and Internet with full IP). we might need some extra work here and define what we want. I am confident that we can break this down to something useful. Worst case we something free form. As discussed previously, we want oFono to manage this data, since it can do this by using the IMSI. So if you insert a different operator SIM your APN settings are magically updated for that operator. I have a feeling this does not work either. If I upgrade my subscription, the APN may change while not the IMSI, no? We can update these details at any time. Storing them on a per ISMI basis is a good idea and something new that oFono does (as far as what I have seen). So if you switch SIM cards, then you don't have to worry about anything when traveling. It does the right thing you configured. Especially with the devices like the Nokia netbook and the iPhone where you can easily switch SIM cards without power on/off this will come in handy. If an upgrade of the subscription needs manual interaction from the user or an operator message to update the settings, then that is fine. Since the user did something to begin with. So they are aware of that something changed (hope the operator told them). While just switching a SIM card and by accident using a wrong APN and causing expensive roaming would be a worse thing. Especially since there is an expectation from the user when switching SIM cards. In my proposal the Status variable was a three-state variable, having the states attached, detached and suspended. Suspended was specified to mean that the GPRS was attached, but temporarily not available (for instance because of a 2G phone call or temporary loss of cellular connectivity). In the IRC discussion someone said that this property would not be part of Denis's API because the tri-state variables were bad and the suspended status was not supported by So the general rule is that if a feature isn't explicitly allowed in 27.007, we do not support it. There are exceptions to this of course. 27.007 only supports two states for context: activated and deactivated. Our general rule is that if we have a UI requirement, or better an actual use case for it, we support it. Suspended GPRS fits both. Can you share these UI requirements with us. spec 27.007. However, the problem is that Maemo 5 already has UI support for indicating that the connection is suspended, and that makes it harder to drop the feature. Could the suspended status enum still be left there, and just have the modems that don't support the feature to never go to suspended mode? I'd rather not. If this feature is really required, then some sort of heuristic can be applied. (e.g. Powered on, Attached on, but context is deactivated most likely means temporary unavailability of resources) Is this some kind of joke? Don't you know the difference between pause and stop on your MP3 player and between suspend to memory and power off on your computer? Second guessing does not fit in my definition of easy to use self- documenting for an API. This really belong in the kernel. Only the kernel can reliably know when a network interface has been brought down and notify the interested applications with the statistics. You're missing the point. Yes, any body can extract the statistics for a running context. But data counters are cumulating. To compute the sum properly, there are but two options: # Either the GPRS middleware requests kernel per-interface statistics right before destroying the interface, and sums with the earlier total. # Or the modem does it internally. There is no way some random userland interface application can do it just by requesting the kernel, since it cannot know when to request those statistics. So my 2 cents here are that whatever so modem does for statistics it should match the details its exports via the networking interface. And on the kernel part and destroyed interface, as I mentioned, we need to discuss this with the kernel guys. I wanna get an answer what can be done to help us. We have most kernel guys at netconf in Portland in three weeks and I gonna check with them. Nokia hardware supports this explicitly, but many others don't. That's irrelevant. Hardware support helps in the sense that it can include statistics for contexts external to Ofono. If the hardware does not support it, then it needs to be done manually in the GPRS middleware. That won't make the requirement go away. What do you expect middleware to do exactly. Our
RE: GPRS support for Ofono
Hi Waldo, I know why you want this, but I'm still against the counter being an oFono driver API. There needs to be a proper kernel interface that signals the application when an interface has gone away with the rx/tx details. This way we handle this generically for all modems without relying on some intrinsic hardware capabilities. This still doesn't solve the case where the modem is accessed from a PC client and forwards PPP data as that data will not go through any network interface, e.g. BT DUN or USB tethering. The cases you describe imply that oFono is not even in control of the gprs context. How would we track/report the tx/rx statistics in that case? It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. how should it do this if oFono is not in the mix. If you are using Bluetooth DUN and point it to a virtual TTY, then you are out of look. If using USB CDC ACM then same applies. The real solution here is Bluetooth PAN and USB CDC Ether which do properly interact with the networking stack. The modem is really in the best position to provide the most reliable information on data usage. You can still use statistics from the network interfaces as a fall-back in case the modem can not provide this information. I don't disagree, but not every modem can track these statistics and this isn't described by 27.007. I suggest the initial support should be enabled by the modem driver implementing a custom D-Bus interface and expose these details however it wishes. The modem driver has no desires of its own :-) It really comes down to what the UI needs and I doubt that the UI wants to deal with this on a modem by modem basis, but sure it's a possibility. The current consent is that we might send a one time signal with all statistics details once the interface goes away. Or we can make the kernel help us here. However I prefer that we sit this out a little and play with what is possible before knocking down an API. I am not even sure what different hardware would give us and how things need to work. I don't see us having enough information to understand what is needed from a hardware, driver or oFono core point of view. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Denis, The reason is simple, Nokia modems suspend GPRS when scanning (or registering), simply because the operation will take roughly three times as long with GPRS attached. You will find this feature in current phones, too. Then ideally you should have two scan modes, periodic and user initiated. For periodic mode we don't care how long it takes. +1 Sounds like a plan. So we do need an /etc/ofono/main.conf :) So my current thinking is to introduce a method to NetworkRegistration property called 'ProposeOperatorScan' and a new property called 'OperatorScanInterval'. The driver api can then support a (non-standard *gasp*) option to say whether this scan was initiated actively or not. Maybe the Nokia modems can use this information not to drop the GPRS link if it isn't an active scan being performed. I really prefer if we put this into /etc/ofono/main.conf since the UI should not configure this at all. It is more a one time setting based on what the integrator expects as a behavior. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le jeudi 3 septembre 2009 00:01:03 Marcel Holtmann, vous avez écrit : It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. how should it do this if oFono is not in the mix. If you are using Bluetooth DUN and point it to a virtual TTY, then you are out of look. If using USB CDC ACM then same applies. The real solution here is Bluetooth PAN and USB CDC Ether which do properly interact with the networking stack. When we have patched all the Windows PC of the world, we can consider it. In the mean time, AT+PPP emulation is required. Some modems do provide data counters including that. I've seen it as a requirement that I would rather have avoided but could not. It's ugly and arguably stupid, but required anyway. In fact, if Ofono won't do it, ConnMan will have to, which is probably by all means worse. You can argue that it should be a driver-specific feature, but it has to be there. Hence, I would guess that more than one driver will support eventually, at which point it should probably be in the common API. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Hi Remi, It's probably difficult if the PC client is allowed to redefine GPRS contexts, but otherwise oFono should at least be able to report the total tx/rx for the context's it has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the stats to update them, e.g. when a BT DUN connection is disconnected. how should it do this if oFono is not in the mix. If you are using Bluetooth DUN and point it to a virtual TTY, then you are out of look. If using USB CDC ACM then same applies. The real solution here is Bluetooth PAN and USB CDC Ether which do properly interact with the networking stack. When we have patched all the Windows PC of the world, we can consider it. my approach would be to try and see how far we get this pushing towards PAN and CDC Ether :) In the mean time, AT+PPP emulation is required. Some modems do provide data counters including that. I've seen it as a requirement that I would rather have avoided but could not. It's ugly and arguably stupid, but required anyway. In fact, if Ofono won't do it, ConnMan will have to, which is probably by all means worse. Actually it is worth for high-speed modems with a network interface and no internal PPP emulation, we would have to do that emulation somewhere in the host stack. And now my brain hurts :( You can argue that it should be a driver-specific feature, but it has to be there. Hence, I would guess that more than one driver will support eventually, at which point it should probably be in the common API. We have to figure something out, but right I would prefer if we GPRS up and running and after that tackle the statistics part. Since without GPRS, we don't need the statistics ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Ismo Puustinen a écrit : I started working on Ofono GPRS support. Hello, With GPRS support, Ofono become very interesting! I failed to understand how the isi_gprs code in your patch communicate with a PPP stack. For example, I currently use a project where the APN is configured and a connection open with it. Then a pppd process is started to establish the IP link. It seem that you make this in a other (and certainly better) way, but I missed the big picture. Best Regards, Jean-Christian de Rivaz ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
On Tue, Sep 01, 2009 at 14:02:43, Jean-Christian de Rivaz wrote: I failed to understand how the isi_gprs code in your patch communicate with a PPP stack. For example, I currently use a project where the APN is configured and a connection open with it. Then a pppd process is started to establish the IP link. It seem that you make this in a other (and certainly better) way, but I missed the big picture. The best way to do this is without PPP and this is probably what Ismo is doing. You would just create a new net_device like eth0 and hide all the ISI and cellular messaging behind that interface providing a clean IP network device. Best regards, Mikkel Christensen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Le mardi 1 septembre 2009 23:17:36 Jean-Christian de Rivaz, vous avez écrit : Thanks for the explanation. I will start learning how phonet works. But I expect there exists a PPP stack somewhere in phonet because the modem I use don't have one. ISI modems have a PPP server-side implementation to handle USB CDC ACM and BlueTooth DUN. But there is only one instance per modem, so we reserve it for the dumb Windows PC that we may be connected to ;) And I don't think it's possible to have a IP link over GPRS without the PPP protocol between them. It might be possible in the standard, but I have not found any network offering such a PP over GPRS data service. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: GPRS support for Ofono
On Tue, Sep 01, 2009 at 15:17:36, Jean-Christian de Rivaz wrote: Thanks for the explanation. I will start learning how phonet works. But I expect there exists a PPP stack somewhere in phonet because the modem I use don't have one. And I don't think it's possible to have a IP link over GPRS without the PPP protocol between them. On most modern modems there is no need to have a PPP link between the Application Processor (AP) and the modem. They will often be able to transmit IP traffic directly to the AP. Hence there is no PPP stack in phonet. If your modem does not support raw IP messaging (or any other datagram service) to the AP you will probably be stuck with good old PPP. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: GPRS support for Ofono
Everyone,
So as it happens I had also been brainstorming a GPRS API for the last several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment. What needs
improvement? What is missing? What should be removed?
Please note that Secondary PDP contexts, Traffic Filters and Network Activated
(Incoming) PDP contexts are not covered in this proposal. These features are
not commonly used and none of us have real experience with them yet. However,
we considered these features and have left room in the APIs for further
expansion.
Data Connection Manager hierarchy
=
Service org.ofono
Interface org.ofono.DataConnectionManager
Object path [variable]
Methods dict GetProperties()
Returns all global system properties. See the
properties section for available properties.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
void DeactivateAll()
Deactivates all active contexts.
object CreateContext()
Creates a new Primary context. Returns the object
path of the created context.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} PrimaryContexts [readonly]
List of all primary contexts objects.
boolean Attached [readonly]
Contains whether the Packet Radio Service is attached.
The attach state might change dynamically based on
availability of network resources. If this value
changes to false, the user can assume that all
contexts have been deactivated.
If the modem is detached, certain features will not
be available, e.g. receiving SMS over packet radio
or network initiated PDP activation.
boolean RoamingAllowed [readwrite]
Contains whether data roaming is allowed. In the off
setting, if the packet radio registration state
indicates that the modem is roaming, oFono will
automatically detach and no further connection
establishment will be possible.
boolean Powered [readwrite]
Controls whether packet radio use is allowed. Setting
this value to off detaches the modem from the
Packet Domain network.
string Status [readonly]
The current packet radio registration status of a modem.
The possible values are:
unregistered Not registered to any network
registeredRegistered to home network
searching Not registered, but searching
deniedRegistration has been denied
unknown Status is unknown
roaming Registered, but roaming
uint16 LocationAreaCode [readonly, optional]
Contains the current location area code.
uint32 CellId [readonly, optional]
Contains the current network cell id.
string Technology [readonly, optional]
Contains the technology of the current network.
The possible values are: GSM, GSMCompact, UTRAN,
GSM+EGPS, UTRAN+HSDPA,
UTRAN+HSUPA,
UTRAN+HSDPA+HSUPA,
E-UTRAN
Primary Data Context hierarchy
=
Service org.ofono
Interface org.ofono.PrimaryDataContext
Object path [variable]
Methods dict
Re: GPRS support for Ofono
Hi Denis,
So as it happens I had also been brainstorming a GPRS API for the last
several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment. What needs
improvement? What is missing? What should be removed?
Please note that Secondary PDP contexts, Traffic Filters and Network
Activated
(Incoming) PDP contexts are not covered in this proposal. These features are
not commonly used and none of us have real experience with them yet.
However,
we considered these features and have left room in the APIs for further
expansion.
Data Connection Manager hierarchy
=
Service org.ofono
Interface org.ofono.DataConnectionManager
I think this should be GPRSManager or something to clearly separate
between GRPS connections and actual data connection,
Object path [variable]
Methods dict GetProperties()
Returns all global system properties. See the
properties section for available properties.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
void DeactivateAll()
Deactivates all active contexts.
object CreateContext()
Creates a new Primary context. Returns the object
path of the created context.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
I assume this is void RemoveContext(object context)
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Propertiesarray{object} PrimaryContexts [readonly]
List of all primary contexts objects.
Calling this just Contexts seems to more reasonable. See comment about
interface name below.
boolean Attached [readonly]
Contains whether the Packet Radio Service is attached.
The attach state might change dynamically based on
availability of network resources. If this value
changes to false, the user can assume that all
contexts have been deactivated.
If the modem is detached, certain features will not
be available, e.g. receiving SMS over packet radio
or network initiated PDP activation.
boolean RoamingAllowed [readwrite]
Contains whether data roaming is allowed. In the off
setting, if the packet radio registration state
indicates that the modem is roaming, oFono will
automatically detach and no further connection
establishment will be possible.
boolean Powered [readwrite]
Controls whether packet radio use is allowed. Setting
this value to off detaches the modem from the
Packet Domain network.
string Status [readonly]
The current packet radio registration status of a modem.
The possible values are:
unregistered Not registered to any network
registeredRegistered to home network
searching Not registered, but searching
deniedRegistration has been denied
unknown Status is unknown
roaming Registered, but roaming
uint16 LocationAreaCode [readonly, optional]
Contains the current location area code.
uint32 CellId [readonly, optional]
Contains the current network cell id.
string Technology [readonly, optional]
Contains the technology of the current network.
The possible values are: GSM, GSMCompact, UTRAN,
GSM+EGPS, UTRAN+HSDPA,
UTRAN+HSUPA,
Re: GPRS support for Ofono
Hi Marcel,
Service org.ofono
Interface org.ofono.DataConnectionManager
I think this should be GPRSManager or something to clearly separate
between GRPS connections and actual data connection,
Two reasons for this:
- Purpose of DataConnectionManager is easier to understand for people
new to
GSM. Whereas GPRSManager really doesn't tell them anything. Everywhere else
we tend to use more easily understood terminology than what is used in the
specifications.
- GPRS is not easily Carmel-cased. E.g. we'd have to name it
GprsManager.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
I assume this is void RemoveContext(object context)
You're absolutely correct.
Properties array{object} PrimaryContexts [readonly]
List of all primary contexts objects.
Calling this just Contexts seems to more reasonable. See comment about
interface name below.
That sounds fine to me.
Primary Data Context hierarchy
=
Service org.ofono
Interface org.ofono.PrimaryDataContext
I would prefer if we just call this GRPSContext and explain that this is
for the primary context. The confusion between primary context and
secondary context is some GSM specific non-sense.
Should we just simply name this 'Context' and name the secondary pdp context
'SubContext'?
array{string} DomainNameServers [readonly, optional]
Holds the list of domain name servers for this
context.
What about the gateway value. In theory we can just route it to the
interface, but if the device fakes a real Ethernet interface and the
gateway is in a different subnet we need a proper host route first.
Yes, this one needs to be added. Good catch.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
