Re: ANN: NetworkManager 1.0.0 released!
On Tue, Dec 23, 2014 at 12:43 PM, Bjørn Mork wrote: >>> > So you need the full context type choice for QMI as well. The odd >>> > two-step dual-stack connection does not change this. The PDP type is >>> > always selected by the first connection. >>> >>> Is that true even if we use different separate WDS clients? If either >>> IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will >>> create separate WDS clients, each of them with a different "Set IP >>> Family Preference" set before calling "Start Network". Are we >>> achieving something correct with this logic? Or not? And if not, how >>> are we supposed to request IPv4v6 using only QMI? (i.e. not with the >>> default profile being configured via AT commands). >> >> I verified a while back that this is what Verizon's connection manager >> did on Windows with the UML290 to achieve a working dual-stack >> connection. And yes, all 3 PDP contexts in the modem were "IPV4V6". >> AFAIK there is no way to get a dual-stack connection without starting >> two WDS clients and setting the IP Family Preference. > > Yes. But note that the shared "IPV4V6" bearer is created by the *first* > WDS client issuing "start network". The second WDS client is simply a > QMI management oddity. It does not create or modify the bearer in any > way. How could it? > > Depending on your profile config, the results of two successive WDS > start network commands will be: > > profile PDP type = IPV4V6 > ipfamily=4; WDS client A start network => success, IPV4V6 bearer created > ipfamily=6; WDS client B start network => success > > profile PDP type = IPV4 > ipfamily=4; WDS client A start network => success, IPV4 bearer created > ipfamily=6; WDS client B start network => failure > > profile PDP type = IPV6 > ipfamily=4; WDS client A start network => failure > ipfamily=6; WDS client B start network => success, IPV6 bearer created > That's much clearer now, thanks! > > The only way you can select the bearer PDP type is by modifying the > profile (either default or referenced from the profile TLV). If you > don't control the profile, then the result is arbitrarily defined by the > existing default. We really need to look for a way to define IPV4V6 profiles with QMI then, there has to be some way to do that. And we should switch the implementation to activate already predefined profiles, instead of what we currently do with the StartNetwork passing APN explicitly. -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Dan Williams writes: > On Mon, 2014-12-22 at 21:46 +0100, Aleksander Morgado wrote: >> >> > So you need the full context type choice for QMI as well. The odd >> > two-step dual-stack connection does not change this. The PDP type is >> > always selected by the first connection. >> >> Is that true even if we use different separate WDS clients? If either >> IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will >> create separate WDS clients, each of them with a different "Set IP >> Family Preference" set before calling "Start Network". Are we >> achieving something correct with this logic? Or not? And if not, how >> are we supposed to request IPv4v6 using only QMI? (i.e. not with the >> default profile being configured via AT commands). > > I verified a while back that this is what Verizon's connection manager > did on Windows with the UML290 to achieve a working dual-stack > connection. And yes, all 3 PDP contexts in the modem were "IPV4V6". > AFAIK there is no way to get a dual-stack connection without starting > two WDS clients and setting the IP Family Preference. Yes. But note that the shared "IPV4V6" bearer is created by the *first* WDS client issuing "start network". The second WDS client is simply a QMI management oddity. It does not create or modify the bearer in any way. How could it? Depending on your profile config, the results of two successive WDS start network commands will be: profile PDP type = IPV4V6 ipfamily=4; WDS client A start network => success, IPV4V6 bearer created ipfamily=6; WDS client B start network => success profile PDP type = IPV4 ipfamily=4; WDS client A start network => success, IPV4 bearer created ipfamily=6; WDS client B start network => failure profile PDP type = IPV6 ipfamily=4; WDS client A start network => failure ipfamily=6; WDS client B start network => success, IPV6 bearer created The only way you can select the bearer PDP type is by modifying the profile (either default or referenced from the profile TLV). If you don't control the profile, then the result is arbitrarily defined by the existing default. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On Mon, 2014-12-22 at 21:46 +0100, Aleksander Morgado wrote: > Are you suggesting that by default NM should try with IPv4 or IPv6 PDP > context types if both are enabled and IPV4V6 fails? > >>> > >>> Yes, I think that would be the best solution. > >>> > In QMI modems it is ModemManager the one connecting separately IPv4 > and IPv6 WDS sessions when IPv4v6 is requested. > >>> > >>> Yep, when that's possible that's even better. My Nokia 21M-02 does > >>> pretty much the same in the firmware. But I'm not so sure if we can > >>> rely on such functionality always being possible? > >>> > >> > >> MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we > >> try one or the other, because the ModemManager API allows asking for > >> both cases. The fact that in QMI we default to separate IPv4 and IPv6 > >> is because we can do so using different WDS clients on the same > >> control port, but maybe we shouldn't, and instead just expose we > >> support separate IPv4 and IPv6? > > > > Nope. As discussed recently, we need to be aware of the distintion > > between IPV4, IPV6 and IPV4V6 on QMI modems as well. Your first QMI > > WDS start network command will select one of these types. The second > > start network command can only succeed if the selected type was IPV4V6. > > > > On the other hand, as Tore points out, there might be situations where > > you want to select IPV4 or IPV6 explicitly, even if the modem appears to > > support IPV4V6. > > > > So you need the full context type choice for QMI as well. The odd > > two-step dual-stack connection does not change this. The PDP type is > > always selected by the first connection. > > Is that true even if we use different separate WDS clients? If either > IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will > create separate WDS clients, each of them with a different "Set IP > Family Preference" set before calling "Start Network". Are we > achieving something correct with this logic? Or not? And if not, how > are we supposed to request IPv4v6 using only QMI? (i.e. not with the > default profile being configured via AT commands). I verified a while back that this is what Verizon's connection manager did on Windows with the UML290 to achieve a working dual-stack connection. And yes, all 3 PDP contexts in the modem were "IPV4V6". AFAIK there is no way to get a dual-stack connection without starting two WDS clients and setting the IP Family Preference. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Are you suggesting that by default NM should try with IPv4 or IPv6 PDP context types if both are enabled and IPV4V6 fails? >>> >>> Yes, I think that would be the best solution. >>> In QMI modems it is ModemManager the one connecting separately IPv4 and IPv6 WDS sessions when IPv4v6 is requested. >>> >>> Yep, when that's possible that's even better. My Nokia 21M-02 does >>> pretty much the same in the firmware. But I'm not so sure if we can >>> rely on such functionality always being possible? >>> >> >> MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we >> try one or the other, because the ModemManager API allows asking for >> both cases. The fact that in QMI we default to separate IPv4 and IPv6 >> is because we can do so using different WDS clients on the same >> control port, but maybe we shouldn't, and instead just expose we >> support separate IPv4 and IPv6? > > Nope. As discussed recently, we need to be aware of the distintion > between IPV4, IPV6 and IPV4V6 on QMI modems as well. Your first QMI > WDS start network command will select one of these types. The second > start network command can only succeed if the selected type was IPV4V6. > > On the other hand, as Tore points out, there might be situations where > you want to select IPV4 or IPV6 explicitly, even if the modem appears to > support IPV4V6. > > So you need the full context type choice for QMI as well. The odd > two-step dual-stack connection does not change this. The PDP type is > always selected by the first connection. Is that true even if we use different separate WDS clients? If either IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will create separate WDS clients, each of them with a different "Set IP Family Preference" set before calling "Start Network". Are we achieving something correct with this logic? Or not? And if not, how are we supposed to request IPv4v6 using only QMI? (i.e. not with the default profile being configured via AT commands). -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
* Balázs Pozsár > Speaking of theoretical cases, couldn't it be a problem if for example > the modem and the network both support IPV4V6, and the user expects it, > but somehow that connection fails on the first try (could happen due to > any temporary reason), and then NM/MM would fall back to for example > IPv4-only? So the user would get a "successful" connection, but the one > which he expected. Yes, this would be analogous to an Ethernet using DHCPv6 for address assignment but the DHCPv6 server/relay is temporarily down when the network connection attempt is being made. I think that ending up with IPv4-only (rather than failing outright) is acceptable in this case. (Except, of course, the user has set may-fail=false for IPv6.) Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On 12/22/2014 10:49 AM, Tore Anderson wrote: Anyway, I have no strong opinions on where the fallback should be located and how it should work in detail, but I do think *something* is needed if you want to avoid lots of bug reports complaining that their WWAN connection profiles no longer work after upgrading to NM1.0+MM1.4. Speaking of theoretical cases, couldn't it be a problem if for example the modem and the network both support IPV4V6, and the user expects it, but somehow that connection fails on the first try (could happen due to any temporary reason), and then NM/MM would fall back to for example IPv4-only? So the user would get a "successful" connection, but the one which he expected. Balázs Pozsár ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Aleksander Morgado writes: > On Sun, Dec 21, 2014 at 10:39 PM, Tore Anderson wrote: >> Hi Aleksander, >> >>> Are you suggesting that by default NM should try with IPv4 or IPv6 PDP >>> context types if both are enabled and IPV4V6 fails? >> >> Yes, I think that would be the best solution. >> >>> In QMI modems it is ModemManager the one connecting separately IPv4 >>> and IPv6 WDS sessions when IPv4v6 is requested. >> >> Yep, when that's possible that's even better. My Nokia 21M-02 does >> pretty much the same in the firmware. But I'm not so sure if we can >> rely on such functionality always being possible? >> > > MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we > try one or the other, because the ModemManager API allows asking for > both cases. The fact that in QMI we default to separate IPv4 and IPv6 > is because we can do so using different WDS clients on the same > control port, but maybe we shouldn't, and instead just expose we > support separate IPv4 and IPv6? Nope. As discussed recently, we need to be aware of the distintion between IPV4, IPV6 and IPV4V6 on QMI modems as well. Your first QMI WDS start network command will select one of these types. The second start network command can only succeed if the selected type was IPV4V6. On the other hand, as Tore points out, there might be situations where you want to select IPV4 or IPV6 explicitly, even if the modem appears to support IPV4V6. So you need the full context type choice for QMI as well. The odd two-step dual-stack connection does not change this. The PDP type is always selected by the first connection. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
* Aleksander Morgado > MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we > try one or the other, because the ModemManager API allows asking for > both cases. The fact that in QMI we default to separate IPv4 and IPv6 > is because we can do so using different WDS clients on the same > control port, but maybe we shouldn't, and instead just expose we > support separate IPv4 and IPv6? I'm not familiar with QMI, so I might be out of my depth here, but are you saying that for those modems MM will *always* split an IPV4V6 connection request into two (IP+IPV6) bearers? If so I think that's not the ideal thing to do, because IPV4V6 looks different from IP+IPV6 from the network side. For example, with IP+IPV6 you might be provisioned with DNS64 resolvers on the IPV6 PDP context (because the network can't know that you'll establish a separate IP(v4) PDP context), while in IPV4V6 you might get normal resolvers without DNS64. It is also possible for a network operator to limit the amount of parallel PDP contexts allowed. So if that limit is 1, by splitting IPV4V6 unconditionally you'll end up with either IPv4 *or* IPv6 connectivity, not both. Another thing that is technically possible, but probably not very common, is for an operator to only support the IPV4V6 PDP context type but not IP/IPV6. If so splitting would prevent connectivity. If the modem supports the true IPV4V6 context type, and the network does too, then I think that's the one that should be used. Splitting it into two bearers should only be done if either the modem or the network lacks support for true IPV4V6, IMHO. > Probing requires a connection attempt; and a connection attempt will > require some prerequisites like the modem being registered to the > network, or packet service activated. I haven't tried to see what the > error could be if we try a connection even before all those are ready, > but I wouldn't rely on that, even if we do get NoDeviceSupport. Very > firmware specific I would say. Ack. Well, with a fallback mechanism in place you'd recover gracefully from the NoDeviceSupport error anyway, so I'd focus any efforts on that... > It probably makes sense to have this retry mechanism in place in > NetworkManager, although ModemManager could also be a good place to do > this. It all depends on how we want to treat errors in connection to > the different PDP context types: either fail if the exact one is not > supported, or retry with some other combination. A new boolean > property passed in connection details could instruct ModemManager to > work in one way or the other. If you want to explicitly test for > IPv4IPv6 and fail if not supported, we could allow passing a > "strict-pdp-type" boolean flag set to TRUE; otherwise, the default > could be to try with separate IPv4 and IPv6 or even with just IPv4 in > the worst case. ModemManager could be a good place to handle this so > that other connection managers using MM benefit from the change as > well, not just NetworkManager (being this change very mobile broadband > specific). Yes, I think the fallback could be implemented in MM as well - it just needs to be *somewhere*. :-) Note that (AIUI), PDP context type requests are merely advisory; it is possible for a network operator to give you an IPv4-only PDP context if you requested IPv6 or vice versa. So you could say that this "looseness" extends to MM's API, i.e., that NM can say ip-type=ipv6 but if that's not supported it can end up with a ip-type=ipv4 bearer due to an internal MM fallback mechanism kicking in. Anyway, I have no strong opinions on where the fallback should be located and how it should work in detail, but I do think *something* is needed if you want to avoid lots of bug reports complaining that their WWAN connection profiles no longer work after upgrading to NM1.0+MM1.4. Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On Sun, Dec 21, 2014 at 10:39 PM, Tore Anderson wrote: > Hi Aleksander, > >> Are you suggesting that by default NM should try with IPv4 or IPv6 PDP >> context types if both are enabled and IPV4V6 fails? > > Yes, I think that would be the best solution. > >> In QMI modems it is ModemManager the one connecting separately IPv4 >> and IPv6 WDS sessions when IPv4v6 is requested. > > Yep, when that's possible that's even better. My Nokia 21M-02 does > pretty much the same in the firmware. But I'm not so sure if we can > rely on such functionality always being possible? > MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we try one or the other, because the ModemManager API allows asking for both cases. The fact that in QMI we default to separate IPv4 and IPv6 is because we can do so using different WDS clients on the same control port, but maybe we shouldn't, and instead just expose we support separate IPv4 and IPv6? >> Unfortunately I don't know of any command that we could use to query >> the MBIM modem of supported IP types. > > You're getting that NoDeviceSupport error out of it somehow, would it > be possible to probe all three when the modem is initialised? > Probing requires a connection attempt; and a connection attempt will require some prerequisites like the modem being registered to the network, or packet service activated. I haven't tried to see what the error could be if we try a connection even before all those are ready, but I wouldn't rely on that, even if we do get NoDeviceSupport. Very firmware specific I would say. >> If MBIM modems do not always handle IPv4v6 PDP context types, and if >> there is no MBIM command to ask for that, should we instead default to >> not showing IPv4v6 as supported? > > No, I think that's a bad idea. That would mean that IPV4V6 won't work > even if the modem and the network supports it just fine, and IPV4V6 > support is something several operators are rolling out these days. > > Besides, I think retry logic is needed to handle the case where the > modem (not necessarily MBIM) does support IPV4V6 but the network > operator does not *anyway*, and that would deal nicely with this > special case for MBIM modems mis-reporting IPV4V6 support too. It probably makes sense to have this retry mechanism in place in NetworkManager, although ModemManager could also be a good place to do this. It all depends on how we want to treat errors in connection to the different PDP context types: either fail if the exact one is not supported, or retry with some other combination. A new boolean property passed in connection details could instruct ModemManager to work in one way or the other. If you want to explicitly test for IPv4IPv6 and fail if not supported, we could allow passing a "strict-pdp-type" boolean flag set to TRUE; otherwise, the default could be to try with separate IPv4 and IPv6 or even with just IPv4 in the worst case. ModemManager could be a good place to handle this so that other connection managers using MM benefit from the change as well, not just NetworkManager (being this change very mobile broadband specific). -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Hi Aleksander, > Are you suggesting that by default NM should try with IPv4 or IPv6 PDP > context types if both are enabled and IPV4V6 fails? Yes, I think that would be the best solution. > In QMI modems it is ModemManager the one connecting separately IPv4 > and IPv6 WDS sessions when IPv4v6 is requested. Yep, when that's possible that's even better. My Nokia 21M-02 does pretty much the same in the firmware. But I'm not so sure if we can rely on such functionality always being possible? > Unfortunately I don't know of any command that we could use to query > the MBIM modem of supported IP types. You're getting that NoDeviceSupport error out of it somehow, would it be possible to probe all three when the modem is initialised? > If MBIM modems do not always handle IPv4v6 PDP context types, and if > there is no MBIM command to ask for that, should we instead default to > not showing IPv4v6 as supported? No, I think that's a bad idea. That would mean that IPV4V6 won't work even if the modem and the network supports it just fine, and IPV4V6 support is something several operators are rolling out these days. Besides, I think retry logic is needed to handle the case where the modem (not necessarily MBIM) does support IPV4V6 but the network operator does not *anyway*, and that would deal nicely with this special case for MBIM modems mis-reporting IPV4V6 support too. Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On Sun, Dec 21, 2014 at 12:15 PM, Tore Anderson wrote: >> This release brings [...] WWAN IPv6 support > > Before you rush off to upload 1.0.0 to the various distros, I'd like to > remind you of https://bugzilla.gnome.org/show_bug.cgi?id=733696. This > is going to break WWAN connections for quite a few people, and they > will need manual configuration to recover. > > The problem is that NetworkManager 1.0.0 will, when everything is left > at its defaults, attempt to use the dual-stack IPV4V6 PDP context type > if ModemManager reports that the modem supports it. This is a sane > thing to do by default, I think. However - even if the modem supports > it, the network operator might not. If so, the network attachment will > fail. Since NM doesn't retry with IP[v4] and/or IPV6, this failure is > final and the user is left without network connectivity. In order to > force IPv4-only connections, the user must manually disable IPv6 (and > vice versa). > > This will happens for standard WWAN connections where the user goes > through the «Set up a Mobile Broadband Connection» wizard, changing as > little as possible - including any connections created in this way in > previous NM versions. That means that for users who upgrade to NM > 1.0.0, previously working connection profiles will break. > Are you suggesting that by default NM should try with IPv4 or IPv6 PDP context types if both are enabled and IPV4V6 fails? In QMI modems it is ModemManager the one connecting separately IPv4 and IPv6 WDS sessions when IPv4v6 is requested. > This issue is aggravated by the fact that ModemManager will advertise > IPV4V6 support for all MBIM modems (even if the modem doesn't support > it, which I believe is the case for the vast majority of 3G modems), > see > http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-broadband-modem-mbim.c#n486. > That makes NM always try IPV4V6, but if the modem doesn't support it, > MM will immediately fail with the error "NoDeviceSupport". So if the > user has a MBIM modem that doesn't support IPV4V6, NM 1.0.0 will break > regardless of what the network provider supports. Unfortunately I don't know of any command that we could use to query the MBIM modem of supported IP types. If MBIM modems do not always handle IPv4v6 PDP context types, and if there is no MBIM command to ask for that, should we instead default to not showing IPv4v6 as supported? -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
* Dan Williams > I'm very happy to announce that after more than 10 years of development > and 10 years of making the world a better place, NetworkManager 1.0 has > been released! Congratulations! Christmas came early this year... :-) > This release brings [...] WWAN IPv6 support Before you rush off to upload 1.0.0 to the various distros, I'd like to remind you of https://bugzilla.gnome.org/show_bug.cgi?id=733696. This is going to break WWAN connections for quite a few people, and they will need manual configuration to recover. The problem is that NetworkManager 1.0.0 will, when everything is left at its defaults, attempt to use the dual-stack IPV4V6 PDP context type if ModemManager reports that the modem supports it. This is a sane thing to do by default, I think. However - even if the modem supports it, the network operator might not. If so, the network attachment will fail. Since NM doesn't retry with IP[v4] and/or IPV6, this failure is final and the user is left without network connectivity. In order to force IPv4-only connections, the user must manually disable IPv6 (and vice versa). This will happens for standard WWAN connections where the user goes through the «Set up a Mobile Broadband Connection» wizard, changing as little as possible - including any connections created in this way in previous NM versions. That means that for users who upgrade to NM 1.0.0, previously working connection profiles will break. This issue is aggravated by the fact that ModemManager will advertise IPV4V6 support for all MBIM modems (even if the modem doesn't support it, which I believe is the case for the vast majority of 3G modems), see http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-broadband-modem-mbim.c#n486. That makes NM always try IPV4V6, but if the modem doesn't support it, MM will immediately fail with the error "NoDeviceSupport". So if the user has a MBIM modem that doesn't support IPV4V6, NM 1.0.0 will break regardless of what the network provider supports. Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
On Fri, Dec 19, 2014 at 6:42 PM, Dan Williams wrote: > * New client library: libnm > > A new GObject-based client library, "libnm", has been written, > merging the existing libnm-util and libnm-glib and simplifying the API > while using modern GLib APIs (such as using GDBus rather than dbus-glib, > and providing "gio-style" asynchronous operations). IP addresses, > routes, hardware addresses, and other properties are now represented as > strings rather than binary types, allowing much simplified code for most > languages including C, Python, and Javascript. For more information see > https://wiki.gnome.org/Projects/NetworkManager/libnm > > libnm-util and libnm-glib are still available for backward > compatibility, and the D-Bus interface remains fully compatible with > 0.9.10. Can't wait to try the new libnm, thanks to everyone for the effort, and congrats! -- Aleksander https://aleksander.es ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Quoting Dan Williams : I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! Congratulations and many thanks for this wonderful software! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.0 released!
Hi, I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! This release brings a more modern GObject-based client library, many bug fixes and updated translations, more flexible routing, hugely improved nmcli with password support, improved nmtui, a light-weight internal DHCP client, "configure and quit" mode, Bluetooth DUN support with Bluez5, VPN connection persistence, improved cooperation with external tools, expanded manpages and documentation, WWAN IPv6 support, and much much more. Full release notes are below... A huge thanks to everyone who contributed to this release (and there are many of you!), and to everyone who's been a part of the NetworkManager project over the past 10 years. Let's make the next 10 even better! Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.0.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openswan/1.0/NetworkManager-openswan-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.0.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.0.tar.xz Cheers, Dan - This is a new stable release of NetworkManager. Notable changes include the following features and fixes. * New client library: libnm A new GObject-based client library, "libnm", has been written, merging the existing libnm-util and libnm-glib and simplifying the API while using modern GLib APIs (such as using GDBus rather than dbus-glib, and providing "gio-style" asynchronous operations). IP addresses, routes, hardware addresses, and other properties are now represented as strings rather than binary types, allowing much simplified code for most languages including C, Python, and Javascript. For more information see https://wiki.gnome.org/Projects/NetworkManager/libnm libnm-util and libnm-glib are still available for backward compatibility, and the D-Bus interface remains fully compatible with 0.9.10. * New internal DHCP client A faster, lighter-weight internal DHCP client based on code from systemd-networkd has been added, and may be selected with the "dhcp=internal" option in NetworkManager.conf or in a configuration snippet. (Note that it does not yet support as many DHCP options as dhclient, and does not support DHCPv6.) * "Configure interfaces and then quit" mode A new 'configure-and-quit=yes' option has been added for environments with less dynamic network configuration. With this option set in NetworkManager.conf, available interfaces will be configured and NetworkManager will quit, spawning small "nm-iface-helper" processes for each interface that uses DHCP and/or IPv6, to preserve DHCP leases and IPv6 address lifetimes. No helper will be spawned for purely static IP configurations. * Improved cooperation with non-NetworkManager network configuration NetworkManager now does a better job of not interfering with devices which it did not create itself. (In particular, it no longer sets IFF_UP on externally-created devices.) * Improvements to nmcli nmcli now supports password requests and PolicyKit authorizations, allowing fully command-line based activation of connections that require passwords. (Note that activation of VPNs is not yet supported, because of the additional complexity of VPN password properties.) 'nmcli dev connect ' will now automatically create a connection if none exists. This command is now a more useful shortcut to activate a network interface by device name. 'nmcli dev delete ' lets you delete unused software devices (bridge, bond, team, etc). * IPv6 configuration improvements IPv6 router advertisement MTUs are now respected WWAN connections now support IPv6 if the modem and provider support IPv6. When running on 3.17 and later kernels, NetworkManager will handle IPv6 link-local address assignment to ensure that IPv6 connectivity is not enabled on interfaces that are "up" but not active. This means that until an IPv6-enabled connection is started, the interface will have no IPv6 link-local address. (If external tools add IPv6 addresses to the interface, NetworkManager will immediately create the IPv6 link-local address to ensure compliance with RFCs. IPv6 interface configuration that exists before NetworkManager starts is left unchanged.) Manually-configured static IPv6 configuration is kept even if automatic configuration fails. Previously, a connection configured for automatic IPv6 addressing (SLAAC) with additional static IPv6
