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
[PATCH 1/2] G1: Add initial HTC G1 modem support
This is without SMS support; that'll come later.
From 32b333d82642af33a5de5867042248f271fcf1a1 Mon Sep 17 00:00:00 2001
From: Andres Salomon dilin...@collabora.co.uk
Date: Tue, 25 Aug 2009 16:04:48 -0400
Subject: [PATCH 1/2] G1: Add initial HTC G1 modem support
G1 plugin is based on generic_at, with a bunch of stuff dropped
and simplified. We use AT+CFUN=1 for powering on rather than having
a configurable init string. We also manually set the default state
during init (the G1 appears to start in mode V0 by default). The
device (/dev/smd0) is hardcoded.
---
Makefile.am |3 +
plugins/g1.c | 182 ++
2 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 plugins/g1.c
diff --git a/Makefile.am b/Makefile.am
index 71b402b..c5103d7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -99,6 +99,9 @@ builtin_sources += plugins/generic_at.c
builtin_modules += mbm
builtin_sources += plugins/mbm.c
+
+builtin_modules += g1
+builtin_sources += plugins/g1.c
endif
if MAINTAINER_MODE
diff --git a/plugins/g1.c b/plugins/g1.c
new file mode 100644
index 000..ab88e1c
--- /dev/null
+++ b/plugins/g1.c
@@ -0,0 +1,182 @@
+/*
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2009 Intel Corporation. All rights reserved.
+ * Copyright (C) 2009 Collabora Ltd. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stdlib.h
+#include errno.h
+
+#include glib.h
+#include gatchat.h
+#include gatsyntax.h
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include ofono/plugin.h
+#include ofono/log.h
+#include ofono/modem.h
+#include ofono/call-barring.h
+#include ofono/call-forwarding.h
+#include ofono/call-meter.h
+#include ofono/call-settings.h
+#include ofono/devinfo.h
+#include ofono/message-waiting.h
+#include ofono/netreg.h
+#include ofono/phonebook.h
+#include ofono/sim.h
+#include ofono/sms.h
+#include ofono/ssn.h
+#include ofono/ussd.h
+#include ofono/voicecall.h
+
+static void g1_debug(const char *str, void *data)
+{
+ DBG(%s, str);
+}
+
+/* Detect hardware, and initialize if found */
+static int g1_probe(struct ofono_modem *modem)
+{
+ GAtSyntax *syntax;
+ GAtChat *chat;
+
+ DBG();
+
+ syntax = g_at_syntax_new_gsmv1();
+ chat = g_at_chat_new_from_tty(/dev/smd0, syntax);
+ g_at_syntax_unref(syntax);
+
+ if (chat == NULL)
+ return -EIO;
+
+ if (getenv(OFONO_AT_DEBUG) != NULL)
+ g_at_chat_set_debug(chat, g1_debug, NULL);
+
+ ofono_modem_set_data(modem, chat);
+
+ return 0;
+}
+
+static void g1_remove(struct ofono_modem *modem)
+{
+ GAtChat *chat = ofono_modem_get_data(modem);
+
+ DBG();
+
+ ofono_modem_set_data(modem, NULL);
+ g_at_chat_unref(chat);
+}
+
+static void cfun_set_on_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+
+ DBG();
+
+ if (ok)
+ ofono_modem_set_powered(modem, TRUE);
+}
+
+/* power up hardware */
+static int g1_enable(struct ofono_modem *modem)
+{
+ GAtChat *chat = ofono_modem_get_data(modem);
+
+ DBG();
+
+ /* ensure modem is in a known state; verbose on, echo/quiet off */
+ g_at_chat_send(chat, ATE0Q0V1, NULL, NULL, NULL, NULL);
+
+ /* power up modem */
+ g_at_chat_send(chat, AT+CFUN=1, NULL, cfun_set_on_cb, modem, NULL);
+
+ return 0;
+}
+
+static void cfun_set_off_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+
+ DBG();
+
+ if (ok)
+ ofono_modem_set_powered(modem, FALSE);
+}
+
+static int g1_disable(struct ofono_modem *modem)
+{
+ GAtChat *chat = ofono_modem_get_data(modem);
+
+ DBG();
+
+ /* power down modem */
+ g_at_chat_send(chat, AT+CFUN=0, NULL, cfun_set_off_cb, modem, NULL);
+
+ return 0;
+}
+
+static void g1_populate(struct ofono_modem *modem)
+{
+ GAtChat *chat = ofono_modem_get_data(modem);
+ struct ofono_message_waiting *mw;
+
+ DBG();
+
+ ofono_devinfo_create(modem, 0, atmodem, chat);
+ ofono_ussd_create(modem, 0, atmodem, chat);
+ ofono_sim_create(modem, 0, atmodem, chat);
+
Re: [PATCH 1/2] G1: Add initial HTC G1 modem support
Hi Andreas, G1 plugin is based on generic_at, with a bunch of stuff dropped and simplified. We use AT+CFUN=1 for powering on rather than having a configurable init string. We also manually set the default state during init (the G1 appears to start in mode V0 by default). The device (/dev/smd0) is hardcoded. --- Makefile.am |3 + plugins/g1.c | 182 ++ 2 files changed, 185 insertions(+), 0 deletions(-) create mode 100644 plugins/g1.c patch has been applied. I did have a trailing whitespace mistake, but I think git was just being paranoid. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/2] G1: Add a G1 syntax for parsing
Hi Andreas, This is based on the generic_at parser, with unnecessary stuff removed. The G1 routinely screws up CRLFs, so the parser needs to account for that. This parser ignores leading CRLFs (which is what reference-ril does as well), as well as trailing LFs (which are sometimes left out). CRs are used as end-of-message indicators. Since we're not bothering tracking CRLFs, there's also no need for a GARBAGE state, or MULTILINE stuff. --- plugins/g1.c | 87 - 1 files changed, 85 insertions(+), 2 deletions(-) this patch has been applied now, too. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] G1: Add an SMS quirk for CNMI mode
From 853ec0707530ee9c35a41bea3f8a6cfd067c7317 Mon Sep 17 00:00:00 2001
From: Andres Salomon dilin...@collabora.co.uk
Date: Wed, 2 Sep 2009 19:35:40 -0400
Subject: [PATCH] G1: Add an SMS quirk for CNMI mode
The G1 doesn't support mode2, despite advertising it.
The G1 chokes w/ an Error 303 when we specify NMI mode 2. Adding a quirk
to drop that mode from the supported list (just use mode 1) allows the G1
to properly deal with SMS.
---
drivers/atmodem/sms.c| 19 ++-
drivers/atmodem/vendor.h |1 +
plugins/g1.c |3 +++
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c
index fc6c052..fc53480 100644
--- a/drivers/atmodem/sms.c
+++ b/drivers/atmodem/sms.c
@@ -35,6 +35,7 @@
#include ofono/sms.h
#include smsutil.h
#include util.h
+#include vendor.h
#include gatchat.h
#include gatresult.h
@@ -570,17 +571,25 @@ static inline gboolean append_cnmi_element(char *buf, int
*len, int cap,
}
static gboolean build_cnmi_string(char *buf, int *cnmi_opts,
- gboolean cnma_enabled)
+ struct sms_data *data)
{
+ const char *mode;
int len = sprintf(buf, AT+CNMI=);
- /* Mode doesn't matter, but sounds like 2 is the sanest option */
- if (!append_cnmi_element(buf, len, cnmi_opts[0], 2310, FALSE))
+ if (data-vendor == OFONO_VENDOR_HTC_G1)
+ /* The G1 advertises support for mode 2, but returns an error
+* if we attempt to actually use it. */
+ mode = 1;
+ else
+ /* Sounds like 2 is the sanest mode */
+ mode = 2310;
+
+ if (!append_cnmi_element(buf, len, cnmi_opts[0], mode, FALSE))
return FALSE;
/* Prefer to deliver SMS via +CMT if CNMA is supported */
if (!append_cnmi_element(buf, len, cnmi_opts[1],
- cnma_enabled ? 21 : 1, FALSE))
+ data-cnma_enabled ? 21 : 1, FALSE))
return FALSE;
/* Always deliver CB via +CBM, otherwise don't deliver at all */
@@ -666,7 +675,7 @@ static void at_cnmi_query_cb(gboolean ok, GAtResult
*result, gpointer user_data)
goto out;
}
- if (build_cnmi_string(buf, cnmi_opts, data-cnma_enabled))
+ if (build_cnmi_string(buf, cnmi_opts, data))
supported = TRUE;
if (data-cnma_enabled)
diff --git a/drivers/atmodem/vendor.h b/drivers/atmodem/vendor.h
index ebf771b..9551a10 100644
--- a/drivers/atmodem/vendor.h
+++ b/drivers/atmodem/vendor.h
@@ -21,4 +21,5 @@
enum ofono_vendor {
OFONO_VENDOR_GENERIC = 0,
+ OFONO_VENDOR_HTC_G1 = 1,
};
diff --git a/plugins/g1.c b/plugins/g1.c
index 30b9f94..c515575 100644
--- a/plugins/g1.c
+++ b/plugins/g1.c
@@ -47,6 +47,8 @@
#include ofono/ussd.h
#include ofono/voicecall.h
+#include drivers/atmodem/vendor.h
+
/* Supply our own syntax parser */
enum G1_STATE_ {
@@ -234,6 +236,7 @@ static void g1_populate(struct ofono_modem *modem)
ofono_call_meter_create(modem, 0, atmodem, chat);
ofono_call_barring_create(modem, 0, atmodem, chat);
ofono_ssn_create(modem, 0, atmodem, chat);
+ ofono_sms_create(modem, OFONO_VENDOR_HTC_G1, atmodem, chat);
ofono_phonebook_create(modem, 0, atmodem, chat);
mw = ofono_message_waiting_create(modem);
--
1.6.3.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] G1: Add an SMS quirk for CNMI mode
Hi Andres, The G1 doesn't support mode2, despite advertising it. The G1 chokes w/ an Error 303 when we specify NMI mode 2. Adding a quirk to drop that mode from the supported list (just use mode 1) allows the G1 to properly deal with SMS. --- drivers/atmodem/sms.c| 19 ++- drivers/atmodem/vendor.h |1 + plugins/g1.c |3 +++ 3 files changed, 18 insertions(+), 5 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Comments about ofono-0.4 release
Hi guys, since we had so much movement in the source code, I went ahead and tagged a new version. So welcome our 0.4 release. The internal modem driver and feature frameworks got a whole re-write, but I am not going into that details here. Go and join the IRC if you really care about it ;) With this release the generic_at driver is gone and replaced by modem configuration driver and a separate one for phone simulator. So the file you wanna look at is /etc/ofono/modem.conf now. It lets you specify various modems and which driver they are suppose to be used. The file is pretty self explanatory. In addition the phone simulator driver, we now have a working driver for the Android/HTC G1 devices. And an initial driver for the Ericsson MBM laptop cards that at least adds support for SMS text messaging. The daemon can also now be built with udev support. This is by default enabled, but can be disabled if required or the target platform doesn't use udev. The udev support will extend the modem configuration file and allow for dynamic modem configuration. We are not there yet at this point of time, but should be getting there pretty soon. And as an extra goody, I converted to a full non-recursive build system which should speed up everything and also allow the linker to do a better job in stripping unused symbols. The biggest advantage of course is when using automake-1.11, it looks way more sexy now :) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
