Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Aki, > > Unfortunately that ship has sailed. Every vendor except Nokia uses AT > > command modems, or at least implements a (somewhat) full-featured AT > > backend. > > Not quite the way I see things. There are notable exceptions to this, > for example, Qualcomm modems don't use AT commands but a proprietary > protocol. > > That said, I think designing the modem driver API based on 27.007 was > a good design decision, but the real test of that decision hasn't > really been done yet. Of course you'll find AT modems mostly a good > fit, and in most cases the other protocols too. But calling it a > raving success without, say, QMI support is a bit premature. I am happily inviting Qualcomm to join oFono and add support for their QMI protocol ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Denis, 2011/3/18 Denis Kenzior : > Unfortunately that ship has sailed. Every vendor except Nokia uses AT > command modems, or at least implements a (somewhat) full-featured AT > backend. Not quite the way I see things. There are notable exceptions to this, for example, Qualcomm modems don't use AT commands but a proprietary protocol. That said, I think designing the modem driver API based on 27.007 was a good design decision, but the real test of that decision hasn't really been done yet. Of course you'll find AT modems mostly a good fit, and in most cases the other protocols too. But calling it a raving success without, say, QMI support is a bit premature. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Denis, > On 03/18/2011 03:33 AM, mika.liljeb...@nokia.com wrote: > > On this I agree. Stateless address autoconfiguration is > needed because it is mandatory in both IETF and 3GPP > standards (sorry for the repetition). Static configuration > (optional in IETF standards) may also be needed but that > remains to be seen. It depends on what kind of funky AT > modems are and will be out there. > > > > So you seem to agree as well, and hence why our IPv6 API is the way it > is right now. The plugin API is ok'ish. I made a few improvement proposals and they still stand. No major objections, though. The motive for this discussion was your and Marcel's comments that you were planning to disable IPv6 stateles address autoconfiguration. On that I most definitely disagree. I hope I've managed to talk you out of it. > >> In the end oFono's philosophy is to always err on the side > of 27.007. > >> So far this strategy has never been (completely) wrong. > > > > 27.007 provides a nice checklist for the functionality of > the modem, so in that sense you're right. In another way it > also serves as a lowest common denominator for the same > functionality. However, what 27.007 does not do is specify > system behaviour. It's easy to jump to conclusions just by > looking at what AT commands are available. Most of the > commands are optional, because a lot of freedom has > intentionally been left for the implementors. It is also why, > IMO, the specification is so bad and we have to fight with > all these quirky AT modem implementations. > > > > Unfortunately that ship has sailed. Every vendor except Nokia uses AT > command modems, or at least implements a (somewhat) full-featured AT > backend. oFono is not about to start inventing its own standard and > then try to merge differences between e.g. ISI 2.0, ISI 2.5, AT > commands, CAIF, QCDM, etc. If the industry couldn't agree on a proper > standard protocol, then I doubt oFono will be able to. And we're not > about to start switch/casing modem types in the core. That > way leads to > chaos. > > We chose this path two years ago and have been pretty successful with > it. Complaining about this now is the wrong time. If your > protocol is > different from 27.007, then it just means extra pain for the modem > driver writer. But as you mentioned, 27.007 is the lowest common > denominator and the vendor specific protocols are richer. So > implementing 27.007 behavior is usually workable (though not > always easy) I believe you completely missed the thrust of my comments there. This is not about 27.007 vs some other modem interface. My point, again, is that 27.007 does not specify system behaviour. You need to read a bunch of other 3GPP specs as well in order to understand the requirements for oFono. Otherwise you will come up with weird and disturbing ideas like "let's disable stateless IPv6 address autoconfiguration", which are completely against 3GPP standards. As for being successful, I don't think that has been put to the test yet. There's an implementation out there and the oFono project has gained decent momentum, which is good. However, oFono can only be called mature when there are more than a few oFono based smart phones on the marked, having passed all the certification tests, having met operator requirements and gained operator approvals for their sales channels, as well as having gained customer approval. That's a long road still. Not that it couldn't be done. > The core tries to help you whenever possible here and deviates from > 27.007 when really necessary, but I'm not tempted to stray > too far from > it. Don't get me wrong, 27.007 is a pain and you've seen me > complaining > about its 'peculiarities' often, but it is the best thing we > have right now. I think it's natural that you use 27.007 as a guideline for the plugin interface, for the reasons you mention. It is not a sufficient guideline for oFono core behavour, however. For that you also need to understand the signalling protocols between MS and core network. Understanding the protocols will help you understand how the MT behaves and how oFono core should behave. > > Remember that 3GPP standards specify the behavour between > MS and the nework. I.e., they place requirements on both TE > and MT. The AT interface (TA function) stands in between and > the combination of TE+TA+MT must function in accordance to > 3GPP standards. My point is, you *really* need to read other > 3GPP specification, like 23.060 and 24.008, in order to > understand what requirements 3GPP places on oFono. Reading > 27.007 will not tell you that. > > > > I think everyone here knows that, but in the end 27.007 > weighs in above > all others because that is what everyone implements in the end. Perhaps everyone knows it but has everyone actually read the other standards I mentioned? Sometimes I wonder. What everyone is required to implement in the end is 3GPP sta
Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Mika, On 03/18/2011 03:33 AM, mika.liljeb...@nokia.com wrote: > Hi Denis, > >>> Disabling IPv6 stateless address would be a bold move >> indeed, since it is declared mandatory in both IETF and 3GPP >> standards. Please see [RFC4294] and [3GPP 23.060]. The >> section "Dynamic IPv6 Address Allocation" in 23.060 is very >> clear on how IPv6 address allocation in 3GPPP networks is >> done. See also the section about IPv6 prefix delegation >> (relevant to IPv6 tethering) and applicable parts of 24.008. >>> >> >> This still needs to be figured out. We are aware that >> autoconfiguration >> is mandatory in 3GPP. However, this seems to be going against 27.007. > > There is no contradiction. Let me explain what I mean. The 3GPP standards > mostly talk about MS (mobile station) which comprises of both TE and MT > (terminal equipment and modem terminal). As such, 3GPP specifications place > requirements on both TE and MT. The 27.007 defines a TA (terminal adapter), > which is one possible interface between TE and MT. However, 27.007 is not > mandatory, vendor specific interfaces are also allowed. As a consequence > other interfaces, such as ISI and CAIF, also exist. > No arguments here > While stateless address autoconfiguration is mandatory for MS, a funky AT > modem could potentially have an internal IPv6 stack as part of the TA > function and perform address configuration against the network and then proxy > any IPv6 traffic between the TE and the network. This would meet the > requirements of 3GPP. The *intent* in the 3GPP standards is that TEs can > behave as standard IPv6 hosts (so PCs can use a standard IPv6 stack), which > means that the TE is expected to run the autoconfiguration protocols against > the network in the normal case. Nothing in 27.007 specifically prevents that. > The static address configuration parameters in the AT commands are optional > and will simply be missing, if the modem just acts as a bitpipe between TE > and the network, allowing the TE to run its IPv6 stack in the normal way. > > However, a funky AT modem that implements an IPv6 stack internally and > exposes static address configuration parameters towards TE is certainly > possible. Such a modem would presumably also block the router advertisements > coming from the network, which would effectively disable stateless address > autoconfiguration for the TE. This is not something you need or should do in > connman. Standard IPv6 stack is sufficient. > >> So in the end both might be required. > > On this I agree. Stateless address autoconfiguration is needed because it is > mandatory in both IETF and 3GPP standards (sorry for the repetition). Static > configuration (optional in IETF standards) may also be needed but that > remains to be seen. It depends on what kind of funky AT modems are and will > be out there. > So you seem to agree as well, and hence why our IPv6 API is the way it is right now. >> In the end oFono's philosophy is to always err on the side of 27.007. >> So far this strategy has never been (completely) wrong. > > 27.007 provides a nice checklist for the functionality of the modem, so in > that sense you're right. In another way it also serves as a lowest common > denominator for the same functionality. However, what 27.007 does not do is > specify system behaviour. It's easy to jump to conclusions just by looking at > what AT commands are available. Most of the commands are optional, because a > lot of freedom has intentionally been left for the implementors. It is also > why, IMO, the specification is so bad and we have to fight with all these > quirky AT modem implementations. > Unfortunately that ship has sailed. Every vendor except Nokia uses AT command modems, or at least implements a (somewhat) full-featured AT backend. oFono is not about to start inventing its own standard and then try to merge differences between e.g. ISI 2.0, ISI 2.5, AT commands, CAIF, QCDM, etc. If the industry couldn't agree on a proper standard protocol, then I doubt oFono will be able to. And we're not about to start switch/casing modem types in the core. That way leads to chaos. We chose this path two years ago and have been pretty successful with it. Complaining about this now is the wrong time. If your protocol is different from 27.007, then it just means extra pain for the modem driver writer. But as you mentioned, 27.007 is the lowest common denominator and the vendor specific protocols are richer. So implementing 27.007 behavior is usually workable (though not always easy) The core tries to help you whenever possible here and deviates from 27.007 when really necessary, but I'm not tempted to stray too far from it. Don't get me wrong, 27.007 is a pain and you've seen me complaining about its 'peculiarities' often, but it is the best thing we have right now. > Remember that 3GPP standards specify the behavour between MS and the nework. > I.e., they place requir
RE: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Denis, > > Disabling IPv6 stateless address would be a bold move > indeed, since it is declared mandatory in both IETF and 3GPP > standards. Please see [RFC4294] and [3GPP 23.060]. The > section "Dynamic IPv6 Address Allocation" in 23.060 is very > clear on how IPv6 address allocation in 3GPPP networks is > done. See also the section about IPv6 prefix delegation > (relevant to IPv6 tethering) and applicable parts of 24.008. > > > > This still needs to be figured out. We are aware that > autoconfiguration > is mandatory in 3GPP. However, this seems to be going against 27.007. There is no contradiction. Let me explain what I mean. The 3GPP standards mostly talk about MS (mobile station) which comprises of both TE and MT (terminal equipment and modem terminal). As such, 3GPP specifications place requirements on both TE and MT. The 27.007 defines a TA (terminal adapter), which is one possible interface between TE and MT. However, 27.007 is not mandatory, vendor specific interfaces are also allowed. As a consequence other interfaces, such as ISI and CAIF, also exist. While stateless address autoconfiguration is mandatory for MS, a funky AT modem could potentially have an internal IPv6 stack as part of the TA function and perform address configuration against the network and then proxy any IPv6 traffic between the TE and the network. This would meet the requirements of 3GPP. The *intent* in the 3GPP standards is that TEs can behave as standard IPv6 hosts (so PCs can use a standard IPv6 stack), which means that the TE is expected to run the autoconfiguration protocols against the network in the normal case. Nothing in 27.007 specifically prevents that. The static address configuration parameters in the AT commands are optional and will simply be missing, if the modem just acts as a bitpipe between TE and the network, allowing the TE to run its IPv6 stack in the normal way. However, a funky AT modem that implements an IPv6 stack internally and exposes static address configuration parameters towards TE is certainly possible. Such a modem would presumably also block the router advertisements coming from the network, which would effectively disable stateless address autoconfiguration for the TE. This is not something you need or should do in connman. Standard IPv6 stack is sufficient. > So in the end both might be required. On this I agree. Stateless address autoconfiguration is needed because it is mandatory in both IETF and 3GPP standards (sorry for the repetition). Static configuration (optional in IETF standards) may also be needed but that remains to be seen. It depends on what kind of funky AT modems are and will be out there. > In the end oFono's philosophy is to always err on the side of 27.007. > So far this strategy has never been (completely) wrong. 27.007 provides a nice checklist for the functionality of the modem, so in that sense you're right. In another way it also serves as a lowest common denominator for the same functionality. However, what 27.007 does not do is specify system behaviour. It's easy to jump to conclusions just by looking at what AT commands are available. Most of the commands are optional, because a lot of freedom has intentionally been left for the implementors. It is also why, IMO, the specification is so bad and we have to fight with all these quirky AT modem implementations. Remember that 3GPP standards specify the behavour between MS and the nework. I.e., they place requirements on both TE and MT. The AT interface (TA function) stands in between and the combination of TE+TA+MT must function in accordance to 3GPP standards. My point is, you *really* need to read other 3GPP specification, like 23.060 and 24.008, in order to understand what requirements 3GPP places on oFono. Reading 27.007 will not tell you that. Regards, MikaL ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Mika, On 03/17/2011 03:58 AM, mika.liljeb...@nokia.com wrote: > Hi Denis, Marcel, > > I'll respond just once, since you both commented on pretty much the same > topics. > >>> I notice that your version of the patches are not forming >> the IPv6 link-local address and configuring it on the network >> interface. That's ok, as long as connman takes care of it, >> but it does mean that Ethernet interfaces, which always have >> a link-local address, will autoconfigure immediately while >> point-to-point interfaces will only autoconfigure when >> connman sets the link-local address on them. We talked about >> this with Marcel and at the time concluded that it would make >> more sense to keep things consistent by having oFono >> configure the link-local address on the point-to-point >> interfaces. I had this implemented in my later patch sets. > > [Denis] >> Samuel felt strongly that this should be done by ConnMan. >> There's still >> some questions left around this area. Namely whether we >> should prevent >> auto-configuration or not, etc. > > Disabling IPv6 stateless address would be a bold move indeed, since it is > declared mandatory in both IETF and 3GPP standards. Please see [RFC4294] and > [3GPP 23.060]. The section "Dynamic IPv6 Address Allocation" in 23.060 is > very clear on how IPv6 address allocation in 3GPPP networks is done. See also > the section about IPv6 prefix delegation (relevant to IPv6 tethering) and > applicable parts of 24.008. > This still needs to be figured out. We are aware that autoconfiguration is mandatory in 3GPP. However, this seems to be going against 27.007. So in the end both might be required. >>> void ofono_gprs_context_set_ipv6_prefix_length(struct >> ofono_gprs_context *gc, >>> unsigned >> char length); >>> void ofono_gprs_context_set_ipv6_gateway(struct >> ofono_gprs_context *gc, >>> const char >> *gateway); >>> >>> I'm not sure these are really needed, which is why I >> dropped these from subsequent patches. This information is >> not received from the cellular network as part of context >> activation signalling. On-link prefixes, routes and default >> gateways are received as part of the standard IPv6 stateless >> address autoconfiguration when the interfaces is brought up. >> The only reason to have these would if a specific modem with >> a virtual ethernet interface deviates from the standard >> address configuration practises for some reasons. >> > > [Denis] >> At least the gateway is reported separately for IPv4 and >> IPv6. Refer to >> 27.007 Section 10.1.23 "PDP Context Read Dynamic Parameters". > > [Marcel] >> The AT commands are pretty clear in that they give us actually a >> netmask. > > True at first glance. However, please note the following: > > 1) The netmask and gateway values returned here are invented by the modem. > They do not come from the network, because they are not carried anywhere in > the signalling messages related to PDP context activation. Stateless IPv6 > address autoconfiguration (potentially followed by DHCPv6) is the only way to > get the real information from the network. > > 2) AT+CGPADDR and AT+CGCONTRDP were introduced in 3GPP rel8 and they are both > optional. I.e. pre-rel8 equipment does not have them and rel8+ equipment is > not required to have them. In particular, they are not required for a modem > to be able to support IPv6, so you cannot rely on these commands being > implemented in the modem. > > 3) IPv6 stateless address autoconfiguration is mandatory in 3GPP standards, > as well as in IETF standards. There's no two ways about it. > > Granted, AT+CGPADDR and AT+GCCONTRDP may be useful for supporting some quirky > modems, as already seen with IPv4 and virtual ethernet interfaces. Lacking a > concrete example for such a modem I don't see much point in adding these > methods yet, though. Optional means nothing in 3GPP 27.007, half that spec is marked as optional. And I've already seen CGPADDR in the wild... As I mentioned before, it might be that the modem performs the autoconfiguration and DHCPv6 steps for us. We might not even be able to turn this behavior off. Re-running the autoconfiguration and DHCPv6 on the host side is a waste of time at that point. In the end oFono's philosophy is to always err on the side of 27.007. So far this strategy has never been (completely) wrong. > [Denis] >> However, you might be right and that 27.007 is not a good >> reflection of >> reality. This has happened before ;) > > It is not. 27.007 is just an interface specification for modem vendords. It > does not specify the behaviour and protocols between a UE and the network. > You really need to look at 23.060 and 24.008. It will save you some hassle in > the future. > You're right of course, 27.007 is sometimes very far from the protocol. Unfortunately oFon
RE: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Denis, Marcel, I'll respond just once, since you both commented on pretty much the same topics. > > I notice that your version of the patches are not forming > the IPv6 link-local address and configuring it on the network > interface. That's ok, as long as connman takes care of it, > but it does mean that Ethernet interfaces, which always have > a link-local address, will autoconfigure immediately while > point-to-point interfaces will only autoconfigure when > connman sets the link-local address on them. We talked about > this with Marcel and at the time concluded that it would make > more sense to keep things consistent by having oFono > configure the link-local address on the point-to-point > interfaces. I had this implemented in my later patch sets. [Denis] > Samuel felt strongly that this should be done by ConnMan. > There's still > some questions left around this area. Namely whether we > should prevent > auto-configuration or not, etc. Disabling IPv6 stateless address would be a bold move indeed, since it is declared mandatory in both IETF and 3GPP standards. Please see [RFC4294] and [3GPP 23.060]. The section "Dynamic IPv6 Address Allocation" in 23.060 is very clear on how IPv6 address allocation in 3GPPP networks is done. See also the section about IPv6 prefix delegation (relevant to IPv6 tethering) and applicable parts of 24.008. > > Having separate lists for IPv4 and IPv6 DNS servers made > sense in my first patch set, because a dual context could be > emulated with separate IPv4 and IPv6 contexts and those DNS > servers might have been behind different network interfaces. > However, now this just creates additional complexity for the > drivers. A dual context will get a list of DNS server > addresses, which may contain IPv4 addresses, IPv6 addresses > or both. Now the driver has to sort them into two separate > lists for IPv4 and IPv6. Note that you can make A and > queries to any server, so there is no particular reason to > separate the lists based on address family. [Denis] > We waffled on this one, but it seemed better to keep it symmetric with > the way ConnMan API is setup for IPv6. For AT modems that support > dual-stack, the IPv4 and IPv6 information is returned > separately anyway, > so for the majority of the drivers separating the details is > more efficient. Sounds like connman has some unnecessary complexity here as well. A single DNS server list really should be sufficient. Not a big deal, though, as long as connman combines the lists at some point and gives the whole thing to the DNS resolver. > > void ofono_gprs_context_set_ipv6_prefix_length(struct > ofono_gprs_context *gc, > > unsigned > char length); > > void ofono_gprs_context_set_ipv6_gateway(struct > ofono_gprs_context *gc, > > const char > *gateway); > > > > I'm not sure these are really needed, which is why I > dropped these from subsequent patches. This information is > not received from the cellular network as part of context > activation signalling. On-link prefixes, routes and default > gateways are received as part of the standard IPv6 stateless > address autoconfiguration when the interfaces is brought up. > The only reason to have these would if a specific modem with > a virtual ethernet interface deviates from the standard > address configuration practises for some reasons. > [Denis] > At least the gateway is reported separately for IPv4 and > IPv6. Refer to > 27.007 Section 10.1.23 "PDP Context Read Dynamic Parameters". [Marcel] > The AT commands are pretty clear in that they give us actually a > netmask. True at first glance. However, please note the following: 1) The netmask and gateway values returned here are invented by the modem. They do not come from the network, because they are not carried anywhere in the signalling messages related to PDP context activation. Stateless IPv6 address autoconfiguration (potentially followed by DHCPv6) is the only way to get the real information from the network. 2) AT+CGPADDR and AT+CGCONTRDP were introduced in 3GPP rel8 and they are both optional. I.e. pre-rel8 equipment does not have them and rel8+ equipment is not required to have them. In particular, they are not required for a modem to be able to support IPv6, so you cannot rely on these commands being implemented in the modem. 3) IPv6 stateless address autoconfiguration is mandatory in 3GPP standards, as well as in IETF standards. There's no two ways about it. Granted, AT+CGPADDR and AT+GCCONTRDP may be useful for supporting some quirky modems, as already seen with IPv4 and virtual ethernet interfaces. Lacking a concrete example for such a modem I don't see much point in adding these methods yet, though. [Denis] > For IPv6 we decided to go with prefix length to keep symmetry with > connman, even though 27.007 reports a netmask. D
Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Mika, On 03/16/2011 05:45 AM, mika.liljeb...@nokia.com wrote: > Hi Denis, > >> So during OSTS Samuel, Marcel and I sat down and tried to >> figure out the >> IPv6 stuff. Based on this discussion and your implementation >> I pushed a >> series of patches implementing IPv6 and dual-stack contexts. I have >> taken (and later re-worked) some of your patches so you get >> credit here >> as well. > > Thanks for pushing the patches. I notice that these are based on my initial > set of patches rather than the later ones. A few comments, since I had some > reasons for the changes I did in later patches. > > I notice that your version of the patches are not forming the IPv6 link-local > address and configuring it on the network interface. That's ok, as long as > connman takes care of it, but it does mean that Ethernet interfaces, which > always have a link-local address, will autoconfigure immediately while > point-to-point interfaces will only autoconfigure when connman sets the > link-local address on them. We talked about this with Marcel and at the time > concluded that it would make more sense to keep things consistent by having > oFono configure the link-local address on the point-to-point interfaces. I > had this implemented in my later patch sets. Samuel felt strongly that this should be done by ConnMan. There's still some questions left around this area. Namely whether we should prevent auto-configuration or not, etc. > > A few comments on the driver API: > > void ofono_gprs_context_set_ipv4_address(struct ofono_gprs_context *gc, > const char *address, > gboolean static_ip); > > What's the expected behaviour if this is called with a valid IP address and > static_ip = FALSE? I think you could just drop the boolean flag and assume a > statically configured address if this method is called by the driver, > otherwise do DHCP. Then this is a bug in the driver. Dropping the boolean flag is certainly doable and is probably a good idea. > > void ofono_gprs_context_set_ipv4_dns_servers(struct ofono_gprs_context > *gc, > const char **dns); > > void ofono_gprs_context_set_ipv6_dns_servers(struct ofono_gprs_context > *gc, > const char **dns); > > I would propose to have just a single method for setting all DNS servers. > > Having separate lists for IPv4 and IPv6 DNS servers made sense in my first > patch set, because a dual context could be emulated with separate IPv4 and > IPv6 contexts and those DNS servers might have been behind different network > interfaces. However, now this just creates additional complexity for the > drivers. A dual context will get a list of DNS server addresses, which may > contain IPv4 addresses, IPv6 addresses or both. Now the driver has to sort > them into two separate lists for IPv4 and IPv6. Note that you can make A and > queries to any server, so there is no particular reason to separate the > lists based on address family. > We waffled on this one, but it seemed better to keep it symmetric with the way ConnMan API is setup for IPv6. For AT modems that support dual-stack, the IPv4 and IPv6 information is returned separately anyway, so for the majority of the drivers separating the details is more efficient. > void ofono_gprs_context_set_ipv6_prefix_length(struct > ofono_gprs_context *gc, > unsigned char length); > void ofono_gprs_context_set_ipv6_gateway(struct ofono_gprs_context *gc, > const char *gateway); > > I'm not sure these are really needed, which is why I dropped these from > subsequent patches. This information is not received from the cellular > network as part of context activation signalling. On-link prefixes, routes > and default gateways are received as part of the standard IPv6 stateless > address autoconfiguration when the interfaces is brought up. The only reason > to have these would if a specific modem with a virtual ethernet interface > deviates from the standard address configuration practises for some reasons. At least the gateway is reported separately for IPv4 and IPv6. Refer to 27.007 Section 10.1.23 "PDP Context Read Dynamic Parameters". For IPv6 we decided to go with prefix length to keep symmetry with connman, even though 27.007 reports a netmask. Drivers will need to convert between IPv6 netmask and prefix length, so this might have to be addressed in the future. However, you might be right and that 27.007 is not a good reflection of reality. This has happened before ;) > > Current USB modem sticks don't seem to have IPv6 support, so I'd propose to > just drop these and add an API later if it turns out to be necessary. If USB > sticks do this propertly, they'll just prox
RE: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Mika, > > So during OSTS Samuel, Marcel and I sat down and tried to > > figure out the > > IPv6 stuff. Based on this discussion and your implementation > > I pushed a > > series of patches implementing IPv6 and dual-stack contexts. I have > > taken (and later re-worked) some of your patches so you get > > credit here > > as well. > > Thanks for pushing the patches. I notice that these are based on my initial > set of patches rather than the later ones. A few comments, since I had some > reasons for the changes I did in later patches. > > I notice that your version of the patches are not forming the IPv6 link-local > address and configuring it on the network interface. That's ok, as long as > connman takes care of it, but it does mean that Ethernet interfaces, which > always have a link-local address, will autoconfigure immediately while > point-to-point interfaces will only autoconfigure when connman sets the > link-local address on them. We talked about this with Marcel and at the time > concluded that it would make more sense to keep things consistent by having > oFono configure the link-local address on the point-to-point interfaces. I > had this implemented in my later patch sets. our conclusion was actually that we will disable IPv6 auto-configuration and expect IP address information given to us by the hardware. > A few comments on the driver API: > > void ofono_gprs_context_set_ipv4_address(struct ofono_gprs_context *gc, > const char *address, > gboolean static_ip); We could do that. > What's the expected behaviour if this is called with a valid IP address and > static_ip = FALSE? I think you could just drop the boolean flag and assume a > statically configured address if this method is called by the driver, > otherwise do DHCP. > > void ofono_gprs_context_set_ipv4_dns_servers(struct ofono_gprs_context > *gc, > const char **dns); > > void ofono_gprs_context_set_ipv6_dns_servers(struct ofono_gprs_context > *gc, > const char **dns); > > I would propose to have just a single method for setting all DNS servers. > > Having separate lists for IPv4 and IPv6 DNS servers made sense in my first > patch set, because a dual context could be emulated with separate IPv4 and > IPv6 contexts and those DNS servers might have been behind different network > interfaces. However, now this just creates additional complexity for the > drivers. A dual context will get a list of DNS server addresses, which may > contain IPv4 addresses, IPv6 addresses or both. Now the driver has to sort > them into two separate lists for IPv4 and IPv6. Note that you can make A and > queries to any server, so there is no particular reason to separate the > lists based on address family. Right now I like to keep them separated for a bit more consistent API, but yes essentially it makes no difference what the DNS servers are for since they can be clearly differentiated by its address type. > void ofono_gprs_context_set_ipv6_prefix_length(struct > ofono_gprs_context *gc, > unsigned char length); > void ofono_gprs_context_set_ipv6_gateway(struct ofono_gprs_context *gc, > const char *gateway); > > I'm not sure these are really needed, which is why I dropped these from > subsequent patches. This information is not received from the cellular > network as part of context activation signalling. On-link prefixes, routes > and default gateways are received as part of the standard IPv6 stateless > address autoconfiguration when the interfaces is brought up. The only reason > to have these would if a specific modem with a virtual ethernet interface > deviates from the standard address configuration practises for some reasons. Looking at AT command based modems, then these are needed. I don't see any auto-configuration with these. The prefix length and gateway information come from the modem. > Current USB modem sticks don't seem to have IPv6 support, so I'd propose to > just drop these and add an API later if it turns out to be necessary. If USB > sticks do this propertly, they'll just proxy router advertisements and > neighbor discovery messages over the virtual ethernet interface and any > additional address configuration settings won't be needed. > > If you decide to keep these, prefix length should probably default to 64 and > be always shown in the settings. The AT commands are pretty clear in that they give us actually a netmask. Our success rate with testing IPv6 on a real network with current hardware was rather limited. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Denis,
> So during OSTS Samuel, Marcel and I sat down and tried to
> figure out the
> IPv6 stuff. Based on this discussion and your implementation
> I pushed a
> series of patches implementing IPv6 and dual-stack contexts. I have
> taken (and later re-worked) some of your patches so you get
> credit here
> as well.
Thanks for pushing the patches. I notice that these are based on my initial set
of patches rather than the later ones. A few comments, since I had some reasons
for the changes I did in later patches.
I notice that your version of the patches are not forming the IPv6 link-local
address and configuring it on the network interface. That's ok, as long as
connman takes care of it, but it does mean that Ethernet interfaces, which
always have a link-local address, will autoconfigure immediately while
point-to-point interfaces will only autoconfigure when connman sets the
link-local address on them. We talked about this with Marcel and at the time
concluded that it would make more sense to keep things consistent by having
oFono configure the link-local address on the point-to-point interfaces. I had
this implemented in my later patch sets.
A few comments on the driver API:
void ofono_gprs_context_set_ipv4_address(struct ofono_gprs_context *gc,
const char *address,
gboolean static_ip);
What's the expected behaviour if this is called with a valid IP address and
static_ip = FALSE? I think you could just drop the boolean flag and assume a
statically configured address if this method is called by the driver, otherwise
do DHCP.
void ofono_gprs_context_set_ipv4_dns_servers(struct ofono_gprs_context
*gc,
const char **dns);
void ofono_gprs_context_set_ipv6_dns_servers(struct ofono_gprs_context
*gc,
const char **dns);
I would propose to have just a single method for setting all DNS servers.
Having separate lists for IPv4 and IPv6 DNS servers made sense in my first
patch set, because a dual context could be emulated with separate IPv4 and IPv6
contexts and those DNS servers might have been behind different network
interfaces. However, now this just creates additional complexity for the
drivers. A dual context will get a list of DNS server addresses, which may
contain IPv4 addresses, IPv6 addresses or both. Now the driver has to sort them
into two separate lists for IPv4 and IPv6. Note that you can make A and
queries to any server, so there is no particular reason to separate the lists
based on address family.
void ofono_gprs_context_set_ipv6_prefix_length(struct
ofono_gprs_context *gc,
unsigned char length);
void ofono_gprs_context_set_ipv6_gateway(struct ofono_gprs_context *gc,
const char *gateway);
I'm not sure these are really needed, which is why I dropped these from
subsequent patches. This information is not received from the cellular network
as part of context activation signalling. On-link prefixes, routes and default
gateways are received as part of the standard IPv6 stateless address
autoconfiguration when the interfaces is brought up. The only reason to have
these would if a specific modem with a virtual ethernet interface deviates from
the standard address configuration practises for some reasons.
Current USB modem sticks don't seem to have IPv6 support, so I'd propose to
just drop these and add an API later if it turns out to be necessary. If USB
sticks do this propertly, they'll just proxy router advertisements and neighbor
discovery messages over the virtual ethernet interface and any additional
address configuration settings won't be needed.
If you decide to keep these, prefix length should probably default to 64 and be
always shown in the settings.
> These are highly experimental and have not received much
> testing (since
> I don't really have any facilities to do so). So please look
> and let me
> know if something isn't working as intended.
I'm not able to test dual context but IPv6 seems to work with isimodem. I did
notice that the context settings allocated in assign_context() are leaked if
context activation fails. Easy enough to fix, though:
iff --git a/src/gprs.c b/src/gprs.c
index 00f6d6d..068aaf3 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -322,11 +322,13 @@ static gboolean assign_context(struct pri_context *ctx)
return FALSE;
}
+static void context_settings_free(struct context_settings *settings);
static void release_context(struct pri_context *ctx)
{
if (ctx == NULL || ctx->gprs == NULL || ctx->context_driver == NULL)
return;
+ context_settings_free(ctx->context_driver->settings);
gprs_cid_release(ctx->gprs, ctx->context.cid);
ctx->con
Re: [RESEND 3 PATCH 00/13] IPv6 Support
Hi Mika, On 03/07/2011 08:02 AM, Mika Liljeberg wrote: > Hi All, > > Patches rebased to current master. > > Regards, > > MikaL > > "IPv6 host walked into a bar. No-one would talk to it." > > [RESEND 3 PATCH 01/13] gprs: factor out common code > [RESEND 3 PATCH 02/13] gprs: Update documentation for IPv6 > [RESEND 3 PATCH 03/13] gprs: driver interface changes for IPv6 > [RESEND 3 PATCH 04/13] gprs: core support for IPv6 > [RESEND 3 PATCH 05/13] test: modify test scripts for IPv6 > [RESEND 3 PATCH 06/13] isimodem: IPv6 support > [RESEND 3 PATCH 07/13] atmodem: update to new gprs context interface > [RESEND 3 PATCH 08/13] huaweimodem: update to new gprs context interface > [RESEND 3 PATCH 09/13] mbmmodem: update to new gprs context interface > [RESEND 3 PATCH 10/13] hsomodem: update to new gprs context interface > [RESEND 3 PATCH 11/13] ifxmodem: update to new gprs context interface > [RESEND 3 PATCH 12/13] stemodem: update to new gprs context interface > [RESEND 3 PATCH 13/13] phonesim: add IPv6 support > > Makefile.am|3 +- > doc/connman-api.txt|9 +- > drivers/atmodem/gprs-context.c | 41 ++-- > drivers/hsomodem/gprs-context.c| 48 +++-- > drivers/huaweimodem/gprs-context.c | 43 +++-- > drivers/ifxmodem/gprs-context.c| 36 ++-- > drivers/isimodem/gprs-context.c| 119 +++- > drivers/mbmmodem/gprs-context.c| 65 --- > drivers/stemodem/gprs-context.c| 30 ++- > include/gprs-context.h | 27 ++- > plugins/phonesim.c | 32 +++- > src/gprs.c | 390 > > test/set-context-property | 38 > 13 files changed, 580 insertions(+), 301 deletions(-) So during OSTS Samuel, Marcel and I sat down and tried to figure out the IPv6 stuff. Based on this discussion and your implementation I pushed a series of patches implementing IPv6 and dual-stack contexts. I have taken (and later re-worked) some of your patches so you get credit here as well. These are highly experimental and have not received much testing (since I don't really have any facilities to do so). So please look and let me know if something isn't working as intended. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RESEND 3 PATCH 00/13] IPv6 Support
Hi All, Patches rebased to current master. Regards, MikaL "IPv6 host walked into a bar. No-one would talk to it." [RESEND 3 PATCH 01/13] gprs: factor out common code [RESEND 3 PATCH 02/13] gprs: Update documentation for IPv6 [RESEND 3 PATCH 03/13] gprs: driver interface changes for IPv6 [RESEND 3 PATCH 04/13] gprs: core support for IPv6 [RESEND 3 PATCH 05/13] test: modify test scripts for IPv6 [RESEND 3 PATCH 06/13] isimodem: IPv6 support [RESEND 3 PATCH 07/13] atmodem: update to new gprs context interface [RESEND 3 PATCH 08/13] huaweimodem: update to new gprs context interface [RESEND 3 PATCH 09/13] mbmmodem: update to new gprs context interface [RESEND 3 PATCH 10/13] hsomodem: update to new gprs context interface [RESEND 3 PATCH 11/13] ifxmodem: update to new gprs context interface [RESEND 3 PATCH 12/13] stemodem: update to new gprs context interface [RESEND 3 PATCH 13/13] phonesim: add IPv6 support Makefile.am|3 +- doc/connman-api.txt|9 +- drivers/atmodem/gprs-context.c | 41 ++-- drivers/hsomodem/gprs-context.c| 48 +++-- drivers/huaweimodem/gprs-context.c | 43 +++-- drivers/ifxmodem/gprs-context.c| 36 ++-- drivers/isimodem/gprs-context.c| 119 +++- drivers/mbmmodem/gprs-context.c| 65 --- drivers/stemodem/gprs-context.c| 30 ++- include/gprs-context.h | 27 ++- plugins/phonesim.c | 32 +++- src/gprs.c | 390 test/set-context-property | 38 13 files changed, 580 insertions(+), 301 deletions(-) ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
