Interesting message in another list.
for me fedora is very slow to get dhcp address.
---------- Forwarded message ---------- From: Sridhar Dhanapalan sridhar@laptop.org.au Date: Fri, Jul 29, 2011 at 12:51 PM Subject: Rapid DHCP To: OLPC Devel devel@lists.laptop.org, OLPC Australia list olpc-au@lists.laptop.org
Here's an article that tries to explain why Mac OS is so much faster at connecting to networks than Linux and Windows:
http://cafbit.com/entry/rapid_dhcp_or_how_do
Could such an implementation be considered for the OLPC OS? XOs go on and off the network all the time, as power management kicks in and the machines move in and out of AP range (or switch to a different AP). This is a disruptive process, and speeding it up would be welcome.
Sridhar
Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia M: +61 425 239 701 E: sridhar@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
On Fri 29 July 2011 13:10:34 Itamar Reis Peixoto wrote:
Interesting message in another list.
for me fedora is very slow to get dhcp address.
Reading the hackernews comments on it makes me wonder if this is a very good idea. It may work for people in certain usecases, but in the case of Fedora probably not so much
http://news.ycombinator.com/item?id=2756952 http://news.ycombinator.com/item?id=2757785
for examples
r
---------- Forwarded message ---------- From: Sridhar Dhanapalan sridhar@laptop.org.au Date: Fri, Jul 29, 2011 at 12:51 PM Subject: Rapid DHCP To: OLPC Devel devel@lists.laptop.org, OLPC Australia list olpc-au@lists.laptop.org
Here's an article that tries to explain why Mac OS is so much faster at connecting to networks than Linux and Windows:
http://cafbit.com/entry/rapid_dhcp_or_how_do
Could such an implementation be considered for the OLPC OS? XOs go on and off the network all the time, as power management kicks in and the machines move in and out of AP range (or switch to a different AP). This is a disruptive process, and speeding it up would be welcome.
Sridhar
Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia M: +61 425 239 701 E: sridhar@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
On 07/30/2011 04:48 AM, Ryan Rix wrote:
...
Reading the hackernews comments on it makes me wonder if this is a very good idea. It may work for people in certain usecases, but in the case of Fedora probably not so much
http://news.ycombinator.com/item?id=2756952 http://news.ycombinator.com/item?id=2757785
---------- Forwarded message ----------
...
Hmm ... the complaint of changing IP does not seem to make sense - as I read the article - the MAC simply remembers server info and instead of a blind dhcp (which causes delays if you are now on a new network as the dhcp server will not NAK a network for which is not authoritative), it ARP's the remembered server first which is very fast - hard to see how this would cause problems (shy of bugs of course)...
gene/
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com) wrote:
Hmm ... the complaint of changing IP does not seem to make sense - as I read the article - the MAC simply remembers server info and instead of a blind dhcp (which causes delays if you are now on a new network as the dhcp server will not NAK a network for which is not authoritative), it ARP's the remembered server first which is very fast - hard to see how this would cause problems (shy of bugs of course)...
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com) wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
Seems like a pretty reasonable thing to do - surely better than just waiting for a timeout to decide if the server is not there ... are you aware of any gotcha's ?
On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com) wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
Seems like a pretty reasonable thing to do - surely better than just waiting for a timeout to decide if the server is not there ... are you aware of any gotcha's ?
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient is smart enough to attempt to reclaim the lease if it's not already expired. Note that the Mac attempts to ARP a number of different DHCP servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be pointless with NetworkManager, because it's extremely unlikely that the DHCP server on your wifi network has changed; NM would simply know that the last DHCP server used *on that wifi network* was 192.168.1.1 and not bother to try talking to other ones like Mac OS X appears to do.
NM could use the same method of ARPing multiple DHCP servers that Mac OS X does, but it wouldn't provide much additional benefit, if any, at least on WiFi networks. It could be used on wired networks to (a) determine which wired network you're connected to, and (b) do rapid DHCP. Again, NM already knows what DHCP server and what lease was last used on the specific wifi network you just connected to, and it won't bother doing a DISCOVER, it'll just jump to RENEW if your lease is still valid.
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location.
Dan
Dan, that works on wireless networks. On wired networks the ARP technique determines *which* of the valid leases you should attempt to restore. So on a wired network you: 1. ARP the known DHCP server IPs to discover the subnet. 2. ARP the IP from the valid lease on that subnet to avoid collision. 3. Restore the ifconfig from the still valid lease. 4. Renew the lease.
This should be pretty sane and gives large speedups to resuming on wired (which people with docks do a lot).
Nathaniel On Jul 30, 2011 6:45 PM, "Dan Williams" dcbw@redhat.com wrote:
On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com) wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
Seems like a pretty reasonable thing to do - surely better than just waiting for a timeout to decide if the server is not there ... are you aware of any gotcha's ?
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient is smart enough to attempt to reclaim the lease if it's not already expired. Note that the Mac attempts to ARP a number of different DHCP servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be pointless with NetworkManager, because it's extremely unlikely that the DHCP server on your wifi network has changed; NM would simply know that the last DHCP server used *on that wifi network* was 192.168.1.1 and not bother to try talking to other ones like Mac OS X appears to do.
NM could use the same method of ARPing multiple DHCP servers that Mac OS X does, but it wouldn't provide much additional benefit, if any, at least on WiFi networks. It could be used on wired networks to (a) determine which wired network you're connected to, and (b) do rapid DHCP. Again, NM already knows what DHCP server and what lease was last used on the specific wifi network you just connected to, and it won't bother doing a DISCOVER, it'll just jump to RENEW if your lease is still valid.
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location.
Dan
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, 2011-07-30 at 19:41 -0400, Nathaniel McCallum wrote:
Dan, that works on wireless networks. On wired networks the ARP technique determines *which* of the valid leases you should attempt to restore. So on a wired network you:
Right, which is why I noted a couple of times about wifi specifically, but perhaps not as clearly as I should have. Obviously NM doesn't yet know which network you're on for wired, and ARP can help there.
- ARP the known DHCP server IPs to discover the subnet.
- ARP the IP from the valid lease on that subnet to avoid collision.
- Restore the ifconfig from the still valid lease.
- Renew the lease.
This should be pretty sane and gives large speedups to resuming on wired (which people with docks do a lot).
Yup, though on wired the impact is a lot lower since medium is a lot more reliable than wifi, and DHCP tends to happen a lot more quickly. The problem with wired is that broadcast and multicast frames often end up getting dropped because they aren't necessarily re-transmitted when there's interference or channel contention. That usually doesn't happen on wired networks. But yes, it can help speed things up on wired, and it can help determine what connection we should be associating with the link as you describe.
Dan
Nathaniel
On Jul 30, 2011 6:45 PM, "Dan Williams" dcbw@redhat.com wrote:
On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com)
wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
Seems like a pretty reasonable thing to do - surely better than
just
waiting for a timeout to decide if the server is not there ... are
you
aware of any gotcha's ?
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient
is
smart enough to attempt to reclaim the lease if it's not already expired. Note that the Mac attempts to ARP a number of different
DHCP
servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be
pointless
with NetworkManager, because it's extremely unlikely that the DHCP server on your wifi network has changed; NM would simply know that
the
last DHCP server used *on that wifi network* was 192.168.1.1 and not bother to try talking to other ones like Mac OS X appears to do.
NM could use the same method of ARPing multiple DHCP servers that
Mac OS
X does, but it wouldn't provide much additional benefit, if any, at least on WiFi networks. It could be used on wired networks to (a) determine which wired network you're connected to, and (b) do rapid DHCP. Again, NM already knows what DHCP server and what lease was
last
used on the specific wifi network you just connected to, and it
won't
bother doing a DISCOVER, it'll just jump to RENEW if your lease is
still
valid.
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had
if
the lease is still valid, while NetworkManager waits for the DHCP
server
confirm the lease. So we could presumptuously configure the
interface
with the previous address from the lease and then only tear it down
if
the DHCP server fails or rejects the renewal.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up
in
the same location.
Dan
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2011-08-01 at 12:10 -0500, Dan Williams wrote:
On Sat, 2011-07-30 at 19:41 -0400, Nathaniel McCallum wrote:
Dan, that works on wireless networks. On wired networks the ARP technique determines *which* of the valid leases you should attempt to restore. So on a wired network you:
Right, which is why I noted a couple of times about wifi specifically, but perhaps not as clearly as I should have. Obviously NM doesn't yet know which network you're on for wired, and ARP can help there.
- ARP the known DHCP server IPs to discover the subnet.
- ARP the IP from the valid lease on that subnet to avoid collision.
- Restore the ifconfig from the still valid lease.
- Renew the lease.
This should be pretty sane and gives large speedups to resuming on wired (which people with docks do a lot).
Yup, though on wired the impact is a lot lower since medium is a lot more reliable than wifi, and DHCP tends to happen a lot more quickly. The problem with wired is that broadcast and multicast frames often end
Should read "The problem with wifi", not wired.
up getting dropped because they aren't necessarily re-transmitted when there's interference or channel contention. That usually doesn't happen on wired networks. But yes, it can help speed things up on wired, and it can help determine what connection we should be associating with the link as you describe.
Dan
Nathaniel
On Jul 30, 2011 6:45 PM, "Dan Williams" dcbw@redhat.com wrote:
On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists@sapience.com)
wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
Lennart
Seems like a pretty reasonable thing to do - surely better than
just
waiting for a timeout to decide if the server is not there ... are
you
aware of any gotcha's ?
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient
is
smart enough to attempt to reclaim the lease if it's not already expired. Note that the Mac attempts to ARP a number of different
DHCP
servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be
pointless
with NetworkManager, because it's extremely unlikely that the DHCP server on your wifi network has changed; NM would simply know that
the
last DHCP server used *on that wifi network* was 192.168.1.1 and not bother to try talking to other ones like Mac OS X appears to do.
NM could use the same method of ARPing multiple DHCP servers that
Mac OS
X does, but it wouldn't provide much additional benefit, if any, at least on WiFi networks. It could be used on wired networks to (a) determine which wired network you're connected to, and (b) do rapid DHCP. Again, NM already knows what DHCP server and what lease was
last
used on the specific wifi network you just connected to, and it
won't
bother doing a DISCOVER, it'll just jump to RENEW if your lease is
still
valid.
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had
if
the lease is still valid, while NetworkManager waits for the DHCP
server
confirm the lease. So we could presumptuously configure the
interface
with the previous address from the lease and then only tear it down
if
the DHCP server fails or rejects the renewal.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up
in
the same location.
Dan
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 07/30/2011 06:49 PM, Dan Williams wrote:
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there. dhclient is
Cool - so is NM already pretty optimal for the case when one sleeps a laptop - and wakes it up in a new wireless domain?
How does it know the dhcp server is still there when the laptop has moved on?
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Probably best not to do this - as it can lead to duplicate IP's on the network - even if briefly - wasn't something like this an issue with some smartphones and princeton univ wifi - and led to them banning android for whatever version had the problem ?
http://code.google.com/p/android/issues/detail?id=11236
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location.
I tend to wake mine up in new locations a lot ... NM doesn't seem to take very long to latch onto the new one.
On Sat, Jul 30, 2011 at 11:30:30PM -0400, Genes MailLists wrote:
On 07/30/2011 06:49 PM, Dan Williams wrote:
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Probably best not to do this - as it can lead to duplicate IP's on the network - even if briefly - wasn't something like this an issue with some smartphones and princeton univ wifi - and led to them banning android for whatever version had the problem ?
No, it cannot lead to duplicate IPs *if the lease is still valid*. If the client has a cached lease, and the lease has not yet reached expiry, then the promise that the DHCP server has made to that client for it to use that IP address for that period of time is still valid and the client is free to continue use that IP address.
This was a case of a client continuing to use an IP address /after it had expired/. This is clearly broken behavior.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location.
I tend to wake mine up in new locations a lot ... NM doesn't seem to take very long to latch onto the new one.
Most of the problems I have after resume are with flakey wireless drivers and/or wpa_supplicant making a solid association to an AP before even getting to the DHCP stage.
On 07/31/2011 12:35 AM, Chuck Anderson wrote:
On Sat, Jul 30, 2011 at 11:30:30PM -0400, Genes MailLists wrote:
On 07/30/2011 06:49 PM, Dan Williams wrote:
... So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal
..
Probably best not to do this - as it can lead to duplicate IP's on the
..
No, it cannot lead to duplicate IPs *if the lease is still valid*. If the client has a cached lease, and the lease has not yet reached expiry, then the promise that the DHCP server has made to that client
Okidok sure - I read the 'presumptively configure' .. 'if ..server .. rejects renewal' differently ... thanks for correcting.
gene
On Sun, Jul 31, 2011 at 12:35:29AM -0400, Chuck Anderson wrote:
On Sat, Jul 30, 2011 at 11:30:30PM -0400, Genes MailLists wrote:
On 07/30/2011 06:49 PM, Dan Williams wrote:
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Probably best not to do this - as it can lead to duplicate IP's on the network - even if briefly - wasn't something like this an issue with some smartphones and princeton univ wifi - and led to them banning android for whatever version had the problem ?
No, it cannot lead to duplicate IPs *if the lease is still valid*. If the client has a cached lease, and the lease has not yet reached expiry, then the promise that the DHCP server has made to that client for it to use that IP address for that period of time is still valid and the client is free to continue use that IP address.
Most (broken) domestic routers forget the DHCP leases they gave out after being rebooted.
Rich.
On Sat, 2011-07-30 at 17:49 -0500, Dan Williams wrote:
NM already keeps DHCP information around based on the network you're connecting to, so we don't need to ARP a bunch of servers just to determine whether the DHCP server we wanted is still there.
That's fine on wireless, but not so useful on wired.
But who cares? RA works nice and fast; it's only Legacy IP that's slow...
On Sat, 2011-07-30 at 17:49 -0500, Dan Williams wrote:
What's unique about the method described there is that the Mac configures the interface with the same IP address it previously had if the lease is still valid, while NetworkManager waits for the DHCP server confirm the lease. So we could presumptuously configure the interface with the previous address from the lease and then only tear it down if the DHCP server fails or rejects the renewal.
Of course, none of this helps if your DHCP leases are short, but it certainly helps if you put your laptop to sleep a lot and wake it up in the same location.
...which I do, all the time, and it certainly is a bit annoying waiting the ~10-15 secs it takes for things to kick in. There seems to be something of a delay before gnome-power-manager totally wakes up, realizes it's now on battery power (if I disconnected since suspending), and right around that time is when NM actually starts re-connecting to the network. It seems like there's <SOMETHING> which has to happen after wake before NM even attempts to re-establish a connection, and that's the longest delay, at least for me. Anyone know what that something is, and whether it can be optimized?
(This improvement would also help, of course. It would be *great* if I could wake up my laptop and have it back on the network and functional within a second or so).
On 08/01/2011 07:25 PM, Adam Williamson wrote:
It seems like there's <SOMETHING> which has to happen after wake before NM even attempts to re-establish a connection, and that's the longest delay, at least for me. Anyone know what that something is, and whether it can be optimized?
I don't know what your networks look like, but are you perhaps seeing the delay in (not)discovering IPv6 on an IPv4-only network? My wife's f15 machine was doing this on our home network and I just disabled IPv6 in the connection definition and it got much faster. Not sure if that's a good default behavior given typical use cases.
-Bill
On Tue, 2011-08-02 at 17:12 -0400, Bill McGonigle wrote:
On 08/01/2011 07:25 PM, Adam Williamson wrote:
It seems like there's <SOMETHING> which has to happen after wake before NM even attempts to re-establish a connection, and that's the longest delay, at least for me. Anyone know what that something is, and whether it can be optimized?
I don't know what your networks look like, but are you perhaps seeing the delay in (not)discovering IPv6 on an IPv4-only network? My wife's f15 machine was doing this on our home network and I just disabled IPv6 in the connection definition and it got much faster. Not sure if that's a good default behavior given typical use cases.
I doubt it. I don't think the <SOMETHING> is inherently networking. I think it's something that has to clear before NM even kicks in. I should check the log timestamps to make sure, though.
On Wed, 2011-08-03 at 00:09 -0700, Adam Williamson wrote:
On Tue, 2011-08-02 at 17:12 -0400, Bill McGonigle wrote:
On 08/01/2011 07:25 PM, Adam Williamson wrote:
It seems like there's <SOMETHING> which has to happen after wake before NM even attempts to re-establish a connection, and that's the longest delay, at least for me. Anyone know what that something is, and whether it can be optimized?
I don't know what your networks look like, but are you perhaps seeing the delay in (not)discovering IPv6 on an IPv4-only network? My wife's f15 machine was doing this on our home network and I just disabled IPv6 in the connection definition and it got much faster. Not sure if that's a good default behavior given typical use cases.
I doubt it. I don't think the <SOMETHING> is inherently networking. I think it's something that has to clear before NM even kicks in. I should check the log timestamps to make sure, though.
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Dan
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net
On 08/03/2011 01:19 PM, Dan Williams wrote:
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up.
How do apps, e.g. Thunderbird, know when they're online? dbus, /sys?
If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right?
-Bill
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle bill@bfccomputing.com wrote:
On 08/03/2011 01:19 PM, Dan Williams wrote:
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up.
How do apps, e.g. Thunderbird, know when they're online? dbus, /sys?
If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right?
It seems like NM's state transitions need to become more explicit. 1. IPv4 connected 2. IPv6 connected 3. "internet" connected (including proxy discovery)
Nathaniel
On Wed, Aug 3, 2011 at 1:43 PM, Nathaniel McCallum nathaniel@natemccallum.com wrote:
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle bill@bfccomputing.com wrote:
On 08/03/2011 01:19 PM, Dan Williams wrote:
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up.
How do apps, e.g. Thunderbird, know when they're online? dbus, /sys?
If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right?
It seems like NM's state transitions need to become more explicit.
- IPv4 connected
- IPv6 connected
- "internet" connected (including proxy discovery)
I have also thought that it would be interesting to handle the case of VPNs in this way as well. That way an app can discover if a resource (like a mail server) requires a certain VPN to be up. It can then request the VPN to be connected, or at least not throw up connection errors if the VPN is down.
Nathaniel
On Wed, 2011-08-03 at 13:43 -0400, Nathaniel McCallum wrote:
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle bill@bfccomputing.com wrote:
On 08/03/2011 01:19 PM, Dan Williams wrote:
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up.
How do apps, e.g. Thunderbird, know when they're online? dbus, /sys?
If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right?
It seems like NM's state transitions need to become more explicit.
- IPv4 connected
- IPv6 connected
- "internet" connected (including proxy discovery)
I wrote a blog post about this:
http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-address...
And we could do this. But it's unlikely that app authors would actually are about this en masse since it's more than just a single yes/no sort of thing. Next, you've got DNS lookups which can be either IPv4 or IPv6 depending on what the DNS server returns; if you do an IPv4 request and the site's DNS server returns an AAAA record, what do you do with that if you don't have IPv6 connectivity yet? Basically it just gets more complicated, and I'm not optimistic that app authors will really hook into the additional information. But it may still be worth trying.
Dan
On Mon, Aug 15, 2011 at 05:25:49PM -0500, Dan Williams wrote:
On Wed, 2011-08-03 at 13:43 -0400, Nathaniel McCallum wrote:
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle bill@bfccomputing.com wrote:
On 08/03/2011 01:19 PM, Dan Williams wrote:
The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing.
Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up.
How do apps, e.g. Thunderbird, know when they're online? dbus, /sys?
If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right?
It seems like NM's state transitions need to become more explicit.
- IPv4 connected
- IPv6 connected
- "internet" connected (including proxy discovery)
I wrote a blog post about this:
http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-address...
And we could do this. But it's unlikely that app authors would actually are about this en masse since it's more than just a single yes/no sort of thing. Next, you've got DNS lookups which can be either IPv4 or IPv6 depending on what the DNS server returns; if you do an IPv4 request and the site's DNS server returns an AAAA record, what do you do with that if you don't have IPv6 connectivity yet? Basically it just gets more complicated, and I'm not optimistic that app authors will really hook into the additional information. But it may still be worth trying.
Have you seen the IETF's Happy Eyeballs drafts? It explains how to implement apps and systems to provide the best user experience in the face of various IPv4 + IPv6 connectivity combinations.
http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-03
On Sat, 2011-07-30 at 16:37 +0200, Lennart Poettering wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
I don't think so. ConnMan doesn't remember the last DHCP setup at all, and doesn't even set the DHCP_REQUESTED_IP option — so it gets gratuitously changed IP addresses each time it reconnects to the network. Patches to fix that were posted in the last week or so.
Am 31.07.2011 12:17, schrieb David Woodhouse:
On Sat, 2011-07-30 at 16:37 +0200, Lennart Poettering wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
I don't think so. ConnMan doesn't remember the last DHCP setup at all, and doesn't even set the DHCP_REQUESTED_IP option — so it gets gratuitously changed IP addresses each time it reconnects to the network
should it be not the job of the DHCP-Server to remember what IP the MAC got and if it should get a knew one?
for me the only right thing the client can do is waking up and request a new IP, so you got everytime a new one if your location was changed and if the dhcpd remembers the MAC the same you had last there
On Sun, 2011-07-31 at 12:25 +0200, Reindl Harald wrote:
Am 31.07.2011 12:17, schrieb David Woodhouse:
On Sat, 2011-07-30 at 16:37 +0200, Lennart Poettering wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
I don't think so. ConnMan doesn't remember the last DHCP setup at all, and doesn't even set the DHCP_REQUESTED_IP option — so it gets gratuitously changed IP addresses each time it reconnects to the network
should it be not the job of the DHCP-Server to remember what IP the MAC got and if it should get a knew one?
Yes, the server should be caching leases and returning the same IP address to the client when the client requests it, if the lease is still valid. If the lease is no longer valid, the server forces a new DISCOVER/REQUEST/ACK sequence, which can take a long time.
The client can make this process quicker by using unicast RENEW requests to the DHCP server if the lease is still valid, in which case you can skip the whole broadcast DISCOVER process and possibly get your lease in 2 packets (RENEW then ACK) instead of 4 or 5 with a random backoff in between if you have to DISCOVER.
So both sides need to do some work to make things go as quickly as possible.
for me the only right thing the client can do is waking up and request a new IP, so you got everytime a new one if your location was changed and if the dhcpd remembers the MAC the same you had last there
This is what happens unless we know we're reconnecting to a saved network, in which case if the lease is still valid we can simply request our old address and chances are the server will ACK that request, and then things are faster. No sense in requesting a completely new IP if the lease we were given by the server is still valid.
Dan
On Mon, 2011-08-01 at 12:15 -0500, Dan Williams wrote:
So both sides need to do some work to make things go as quickly as possible.
Do you know if dd-wrt 'does the right thing'? It's the standard fix for 'help! I bought a consumer router!', and has a pretty responsive maintenance team, so that would be one easy place to attack the DHCP server side of things, if it's not already been done.
On 08/01/2011 07:15 PM, Dan Williams wrote:
On Sun, 2011-07-31 at 12:25 +0200, Reindl Harald wrote:
Am 31.07.2011 12:17, schrieb David Woodhouse:
On Sat, 2011-07-30 at 16:37 +0200, Lennart Poettering wrote:
IIRC connman (i.e. NM's competition) can do the ARP magic, too.
I don't think so. ConnMan doesn't remember the last DHCP setup at all, and doesn't even set the DHCP_REQUESTED_IP option — so it gets gratuitously changed IP addresses each time it reconnects to the network
should it be not the job of the DHCP-Server to remember what IP the MAC got and if it should get a knew one?
Yes, the server should be caching leases and returning the same IP address to the client when the client requests it, if the lease is still valid. If the lease is no longer valid, the server forces a new DISCOVER/REQUEST/ACK sequence, which can take a long time.
The client can make this process quicker by using unicast RENEW requests to the DHCP server if the lease is still valid, in which case you can skip the whole broadcast DISCOVER process and possibly get your lease in 2 packets (RENEW then ACK) instead of 4 or 5 with a random backoff in between if you have to DISCOVER.
So both sides need to do some work to make things go as quickly as possible.
Actually the client should be already getting the lease in 2 packets.
When client restarts (connecting after waking from sleep) it needs to confirm that its address is still valid. So it sends REQUEST with the old address. This REQUEST is broadcasted because the address may be invalid (client has moved to another network), even if the lease on that address has not expired.
When the server receives the REQUEST it checks that the address is from a subnet assigned to the network segment to which the client is attached. The server knows what client (MAC) has what address. It's also persistently stored in servers leases DB. The request is then either ACKed (usually), so the client gets the lease in 2 packets or NAKed, in which case new DISCOVER/OFFER/REQUEST/ACK solicitation follows.
Jiri
for me the only right thing the client can do is waking up and request a new IP, so you got everytime a new one if your location was changed and if the dhcpd remembers the MAC the same you had last there
This is what happens unless we know we're reconnecting to a saved network, in which case if the lease is still valid we can simply request our old address and chances are the server will ACK that request, and then things are faster. No sense in requesting a completely new IP if the lease we were given by the server is still valid.
Dan
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Bill McGonigle -
Chuck Anderson -
Dan Williams -
David Woodhouse -
Genes MailLists -
itamar -
Jiri Popelka -
Lennart Poettering -
Nathaniel McCallum -
Reindl Harald -
Richard W.M. Jones -
Ryan Rix