Bug 588553

Forgot to mention, both IPv4 and IPv6 modes are "automatic", as I'm mostly interested in testing the "out of the box" experience.  In the opposite case, with DHCPv4 service and no IPv6 at all, there's no such delay.

Tore

Yeah, at this point we wait for all modes to complete or time out.  Internally in NetworkManager there are some architectural issues that need to be solved for this issue to be fixed up.

The problem with DHCPv4 is that the timeout is very long; you need to wait for at least 60 - 120 seconds before timing out the DHCP request since some networks have very slow DHCP, or the DHCP broadcast packets could get lost on chatty or unreliable networks (on the fringe of wifi range for example).

With IPv6 we time out RAs in 20 seconds, so by the time the DHCPv4 completes in many cases we've already timed out the RA since nothing replied within 20 seconds.

So we'll leave this open until we can do some internal rework to allow better parallel configuration here.

Another open question is how apps are going to respond.  Many apps aren't yet IPv6 aware, and if NM says "hey we're connected" but only to IPv6, apps might try to do stuff and fail because they are expecting IPv4 connectivity.  WE'll have to see if that's an issue in practice.

Note that we can make the latency lower by handling DHCPv4 slightly differently; but we'd need to get events from the DHCP client to do so.  Most of the time if there is a DHCP server on the link it will reply to the request fairly quickly (say within 30 seconds) but it's the subsequent OFFER/CONFIRM conversation that takes longer to complete.

Thus, if the DHCP client were able to tell is if a server replied *at all* at any point during the conversation, we could then provide a better experience and lower latency.  If no server replies at all within 30 or 40 seconds, then we kill the attempt and assume IPv4 is dead.  But if some server replies initially within that time, we increase the timeout and allow the DHCP attempt to proceed for and additional 60 seconds or so, since there's clearly *something* on the link.

This is quite useful for the fringe/loaded network scenario to improve the experience, and would be useful here even if we can't improve the NM architecture as quickly.

It does however require changes to dhclient/dhcpcd to add an extra event.

(In reply to comment #2)

> Another open question is how apps are going to respond.  Many apps aren't yet
> IPv6 aware, and if NM says "hey we're connected" but only to IPv6, apps might
> try to do stuff and fail because they are expecting IPv4 connectivity.  WE'll
> have to see if that's an issue in practice.    

I don't think there's too many applications left that do not support IPv6, and if they don't, it's a bug in those applications and not something NM should attempt to work around.  Bug #195271 tracks the individual bugs submitted on applications due to the lack of IPv6 support - at the time of writing, only ten depending bugs are open (two of them in NM).

From the applications I use often, currently only the NFS kernel server and the Transmission daemon's XML-RPC remote control interface do not properly support IPv6.

I doubt that many (if any) of the applications that don't support IPv6 integrates with NM to determine online/offline state anyway.  Also, I believe all of the commonly used applications installed by default (like Firefox, Evolution, Empathy, and so on), have very mature support for IPv6.

So I really don't think that this is something you need to be concerned about.

Tore

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Created attachment 464751 [details]
Snippet from /var/log/messages

The issue is still present in Fedora 14 (NetworkManager-0.8.1-10.git20100831.fc14.x86_64), see attached log.  Re-opening.

This feature has been in F17 since 0.9.3.x (ie, 0.9.4 devel snapshots)