When knetworkmanager attempts to make a network connection, it will fail if any stage fails to work, even if that stage is dhcp. I have found that in crowded enviornments, dhcp fails far more often than anything else. In that case, knetworkmanager makes a connection, has the dhcp lease fail and then it kills the connection. This occurs with both dhcpcd and dhclient. dhclient.conf has really good documentation on its timeouts, so I am right now using dhclient. I examined the default settings for dhclient and they turn out to be extraordinarily conservative. The default retry interval is 60 seconds. Coincidentally, the default timeout is also 60 seconds. The implication is that with the default settings, my laptop will only make 1 attempt to talk to the DHCP server and if there is a collision that blocks that communication attempt, my system would not make a second attempt. I assume that dhcpcd has the same problem. I worked around this issue by lowering the default retry time to 3 seconds from 60 seconds. The fix works beautifully for me, but this is a really frustrating problem and I am sure that it sends people away from Gentoo (and Linux in general). To make life easier for people, I suggest reducing the default retry times on Gentoo. Also, please note that this issue occurs on other Linux distributions. My university's LUG has been discussing this issue for a while. It was not until today that I was frustrated enough to investigate the cause and put some sort of workaround in place on my system. I think some things probably need to change at upstream. The dhclient people probably should change their default settings. The KDE people might want to modify knetworkmanager to allow people to override the defaults and also to allow connections to occur without dhcp. I will be too busy to talk to people to try to resolve these issues at upstream for at least another few weeks.
Please test with >=kde-misc/knetworkmanager-0.8.80. In my opinion you should report your concerns upstream.
People are currently discussing connection issues in crowded areas on a few mailing lists, including the LKML. Intel's developers are looking into bugs in iwlagn that could contribute to this. There are multiple issues in the wireless stack that contribute to connection issues, although this seems to be the main one: http://en.wikipedia.org/wiki/Hidden_node_problem This is a kernel issue because rts is off by default and "auto" mode does not work. RTS/CTS is supposed to address this issue. The issue here is exacerbated by the kernel issue, although it could be fixed by implementing RFC 4436 in dhcpcd and/or dhclient.
I cant find the point why this should be a Gentoo bug?!
(In reply to comment #3) > I cant find the point why this should be a Gentoo bug?! At the time, I thought that reporting the issue to Gentoo would make sense since the handbook claims that Gentoo is developing dhcpcd and I was forced to change DHCP client software to deal with it: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?style=printable&part=4&chap=3#doc_chap3
See no information in mentioned metadata that gentoo is the developer of dhcp client, gentoo only provides it. This bug should be closed.
(In reply to comment #4) > (In reply to comment #3) > > I cant find the point why this should be a Gentoo bug?! > > At the time, I thought that reporting the issue to Gentoo would make sense > since the handbook claims that Gentoo is developing dhcpcd and I was forced to > change DHCP client software to deal with it: > > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?style=printable&part=4&chap=3#doc_chap3 That was a misunderstanding then... dhcpcd bugs are not handled by Gentoo bugzilla. There's two things that you could do: * file a ticket against dhcpcd, see http://roy.marples.name/projects/dhcpcd/newticket * head to our brand-new wiki at http://wiki.gentoo.org/ and leave some tips and tricks there how to make wifi working in crowded networks. Anyway, glad that you got the issue sorted out.
