11:10 a.m.
Interesting message in another list.
for me fedora is very slow to get dhcp address.
---------- Forwarded message ----------
From: Sridhar Dhanapalan <sridhar(a)laptop.org.au>
Date: Fri, Jul 29, 2011 at 12:51 PM
Subject: Rapid DHCP
To: OLPC Devel <devel(a)lists.laptop.org>, OLPC Australia list
<olpc-au(a)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(a)laptop.org.au
A: G.P.O. Box 731
Sydney, NSW 2001
W: www.laptop.org.au
_______________________________________________
Devel mailing list
Devel(a)lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
------------
Itamar Reis Peixoto
msn, google talk: itamar(a)ispbrasil.com.br
+55 11 4063 5033 (FIXO SP)
+55 34 9158 9329 (TIM)
+55 34 8806 3989 (OI)
+55 34 3221 8599 (FIXO MG)
3:48 a.m.
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(a)laptop.org.au>
Date: Fri, Jul 29, 2011 at 12:51 PM
Subject: Rapid DHCP
To: OLPC Devel <devel(a)lists.laptop.org>, OLPC Australia list
<olpc-au(a)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(a)laptop.org.au
A: G.P.O. Box 731
Sydney, NSW 2001
W: www.laptop.org.au
_______________________________________________
Devel mailing list
Devel(a)lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Ryan Rix -- http://rix.si
== OpenSource.com: Where Open Source Happens! ==
_
\/"/_ All Hail the Beefy Miracle!
/_/
\ \
9:31 a.m.
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/
9:37 a.m.
On Sat, 30.07.11 10:31, Genes MailLists (lists(a)sapience.com) wrote:
>> http://cafbit.com/entry/rapid_dhcp_or_how_do
>
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
--
Lennart Poettering - Red Hat, Inc.
10:46 a.m.
On 07/30/2011 10:37 AM, Lennart Poettering wrote:
On Sat, 30.07.11 10:31, Genes MailLists (lists(a)sapience.com) wrote:
>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
>>
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 ?
5:49 p.m.
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(a)sapience.com) wrote:
>
>>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
>>>
>
> 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
6:41 p.m.
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(a)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(a)sapience.com) wrote:
> >
> >>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
> >>>
>
> >
> > 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12:10 p.m.
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.
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).
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(a)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(a)sapience.com)
wrote:
>> >
>> >>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
>> >>>
>>
>> >
>> > 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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
4:18 p.m.
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.
> 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).
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(a)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(a)sapience.com)
> wrote:
> >> >
> >> >>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
> >> >>>
> >>
> >> >
> >> > 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(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
>
10:30 p.m.
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.
11:35 p.m.
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.
10:41 a.m.
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
3:35 p.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
4:50 a.m.
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...
--
dwmw2
6:25 p.m.
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).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:12 p.m.
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
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
2:09 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:19 p.m.
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
12:38 p.m.
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
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
12:43 p.m.
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle <bill(a)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
12:47 p.m.
On Wed, Aug 3, 2011 at 1:43 PM, Nathaniel McCallum
<nathaniel(a)natemccallum.com> wrote:
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle
<bill(a)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)
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
5:25 p.m.
On Wed, 2011-08-03 at 13:43 -0400, Nathaniel McCallum wrote:
On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle
<bill(a)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)
I wrote a blog post about this:
http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-addr...
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
11:50 p.m.
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(a)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)
I wrote a blog post about this:
http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-addr...
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
5:17 a.m.
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.
--
dwmw2
5:25 a.m.
New subject: Rapid DHCP
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
12:15 p.m.
New subject: Rapid DHCP
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
6:25 p.m.
New subject: Rapid DHCP
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:52 a.m.
New subject: Rapid DHCP
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
4644
days inactive
4662
days old
27 comments
13 participants
participants (13)
-
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