Since 2.6.26. I use ath5k instead of madwifi-ng. For several reasons I disabled the dhcp-server of my wlan-router and configured the wlan-devices static. /etc/conf.d/net: modules="wpa_supplicant" wpa_supplicant_ath0="-Dwext" config_ath0="192.168.100.100/24" routes_ath0="default via 192.168.100.1" dns_servers_ath0="192.168.100.100" But instead of assigning this configuration to the network-device, ath0 tries to get an ip by dhclient: /var/log/messages: Oct 7 15:41:26 Blechkasten ath0: Initial auth_alg=0 Oct 7 15:41:26 Blechkasten ath0: authenticate with AP 00:1d:19:ba:1e:72 Oct 7 15:41:26 Blechkasten ath0: RX authentication from 00:1d:19:ba:1e:72 (alg=0 transaction=2 status=0) Oct 7 15:41:26 Blechkasten ath0: authenticated Oct 7 15:41:26 Blechkasten ath0: associate with AP 00:1d:19:ba:1e:72 Oct 7 15:41:26 Blechkasten ath0: RX AssocResp from 00:1d:19:ba:1e:72 (capab=0x431 status=0 aid=1) Oct 7 15:41:26 Blechkasten ath0: associated Oct 7 15:41:26 Blechkasten ath0: switched to short barker preamble (BSSID=00:1d:19:ba:1e:72) Oct 7 15:41:26 Blechkasten Adding 1461904k swap on /dev/sda2. Priority:-1 extents:1 across:1461904k Oct 7 15:41:26 Blechkasten rc[3125]: segfault at 960 ip b80e50d4 sp bfff4708 error 4 in ld-2.8.so[b80dc000+1a000] Oct 7 15:41:26 Blechkasten rc[2430]: segfault at 2f00 ip b80d6ac6 sp bfff5ce0 error 4 in libutil-2.8.so[b80d6000+2000] Oct 7 15:41:27 Blechkasten dhclient: wmaster0: unknown hardware address type 801 Oct 7 15:41:30 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 6 Oct 7 15:41:36 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 9 Oct 7 15:41:45 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 15 Oct 7 15:42:00 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 11 Oct 7 15:42:11 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 15 Oct 7 15:42:26 Blechkasten dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5 Oct 7 15:42:31 Blechkasten dhclient: No DHCPOFFERS received. During the boot process I recognize this behaviour in that way, that the system hangs for about one minute while booting. After completing the boot-process I have to restart the net.ath0-service, then the static configuration will assign to the device and the card works quite unproblematic. Reproducible: Always Steps to Reproduce: 1. Boot the system with static net configuration (no dhcp) connected to the red by a wlan-device Actual Results: There's no ip assigned to the wlan network card. Expected Results: The wlan-configuration should be able to work without dhclient. I simply want to have a static configured working wlan-device. Additional comments: 1. This behaviour is independet of the kind of the ath5k-module. I tried it as module and also as compiled in into the kernel. No difference. 2. If there's an entry in /var/lib/dhcp/dhclient.leases, that is vaild for this network, then dhclient tries to assign this entry and the red works afterwards. But this "workaround" isn't an acceptable behaviour.
*** Bug 240429 has been marked as a duplicate of this bug. ***
So, to clarify - if you ensure that dhclient is not running, clear the IPs from ath0 and restart net.ath0 then you just get the static IP assignment just fine?
(In reply to comment #2) > So, to clarify - if you ensure that dhclient is not running, clear the IPs from > ath0 and restart net.ath0 then you just get the static IP assignment just fine? > yes. After finishing the boot process I have just to restart /etc/init.d/net.ath0 and get my fixed ip from /etc/conf.d/net.
So something else must be starting dhclient. Maybe networkmanager or some equivalent?
(In reply to comment #4) > So something else must be starting dhclient. Maybe networkmanager or some > equivalent? > networkmanager isn't installed. I found a quick and dirty workaround. I put in /etc/conf.d/local.start the following lines: /etc/init.d/net.ath0 restart /etc/init.d/pdnsd restart Then it works. Where could I search else to find the "bad" guy who wants dhclient?
(In reply to comment #5) > Where could I search else to find the "bad" guy who wants > dhclient? You could try removing dhclient (from net-misc/dhcp) and seeing what complains
I did it: /var/log/messages showed the following: Oct 14 15:54:35 Blechkasten ath0: Initial auth_alg=0 Oct 14 15:54:35 Blechkasten ath0: authenticate with AP 00:1d:19:ba:1e:72 Oct 14 15:54:35 Blechkasten ath0: RX authentication from 00:1d:19:ba:1e:72 (alg=0 transaction=2 status=0) Oct 14 15:54:35 Blechkasten ath0: authenticated Oct 14 15:54:35 Blechkasten ath0: associate with AP 00:1d:19:ba:1e:72 Oct 14 15:54:35 Blechkasten ath0: RX AssocResp from 00:1d:19:ba:1e:72 (capab=0x431 status=0 aid=1) Oct 14 15:54:35 Blechkasten ath0: associated Oct 14 15:54:35 Blechkasten ath0: switched to short barker preamble (BSSID=00:1d:19:ba:1e:72) Oct 14 15:54:36 Blechkasten avahi-daemon[3141]: Found user 'avahi' (UID 114) and group 'avahi' (GID 1017). Oct 14 15:54:36 Blechkasten avahi-daemon[3141]: Successfully dropped root privileges. Oct 14 15:54:36 Blechkasten avahi-daemon[3141]: avahi-daemon 0.6.23 starting up. Oct 14 15:54:36 Blechkasten avahi-daemon[3141]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Oct 14 15:54:36 Blechkasten avahi-daemon[3141]: Successfully called chroot(). Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Successfully dropped remaining capabilities. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Loading service file /services/sftp-ssh.service. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Loading service file /services/ssh.service. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Joining mDNS multicast group on interface ath0.IPv4 with address 192.168.100.100. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: New relevant interface ath0.IPv4 for mDNS. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Network interface enumeration completed. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Registering new address record for 192.168.100.100 on ath0.IPv4. Oct 14 13:54:36 Blechkasten avahi-daemon[3141]: Registering HINFO record with values 'I686'/'LINUX'. Oct 14 15:54:37 Blechkasten pdnsd[3181]: pdnsd-1.2.7-par starting. Oct 14 13:54:37 Blechkasten avahi-daemon[3141]: Server startup complete. Host name is Blechkasten.local. Local service cookie is 3835186093. Oct 14 15:54:37 Blechkasten sshd[3207]: Server listening on 0.0.0.0 port 22. Oct 14 13:54:38 Blechkasten avahi-daemon[3141]: Service "Blechkasten" (/services/ssh.service) successfully established. Oct 14 13:54:38 Blechkasten avahi-daemon[3141]: Service "SFTP File Transfer on Blechkasten" (/services/sftp-ssh.service) successfully established. I have that suspicion that the avahi-daemon is the guilty one. Maybe I will test more.
Found this: http://www.len.ro/2007/05/disabling-avahi-daemon/ I will test it, if my openoffice has finished compiling. :)
Ok, it's not the Avahia-daemon. I deactivated the daemon in the USE-Flags, so the ahavi service isn't started. I also renamed /sbin/dhclient to /sbin/dhclient.bak /sbin/dhclient-script /sbin/dhclient-script.bak The system boots, the network starts, nothing complains, everything looks fine until the start of the ntp-client, which fails. After the login the network is not reachable, the IP isn't assigned to my ath0-device. And ironically since a view days I have the same problem with kdm (Version4.2). The boot service starts the xdm script. The display is changing the resolution, but fails to start. Dmesg tells: [drm] Setting GART location based on new memory map [drm] Loading R100 Microcode [drm] writeback test succeeded in 1 usecs mtrr: no MTRR for e0000000,1000000 found After restarting the service with: /etc/init.d/xdm restart the XServer starts without any problems and kdm loads fine.
Created attachment 169038 [details] dmesg Don't care about the eth0-service. That device was started manually afterwards to get access via nfs.
Created attachment 169040 [details] Boot messages
Created attachment 169042 [details] emerge --info
Created attachment 169044 [details] ifconfig
Created attachment 169048 [details] /etc/conf.d/net
Nothing here indicates a problem with OpenRC. It looks like wpa_supplicant did not associate, or wpa_cli did not fire off net.ath0 start after association. To verify, when ifconfig does not have an address try this IN_BACKGROUND=1 /etc/init.d/net.ath0 start And attach output.
Ok, here's the output: root@Fehlermelder ~ <15:46:32> > IN_BACKGROUND=1 /etc/init.d/net.ath0 start * WARNING: net.ath0 has already been started root@Fehlermelder ~ <15:46:53> > IN_BACKGROUND=1 /etc/init.d/net.ath0 restart * Stopping sshd ... [ ok ] * Stopping pdnsd ... [ ok ] * Bringing down interface ath0 * Bringing up interface ath0 * 192.168.100.102/24 ... [ ok ] * Adding routes * default via 192.168.100.1 ... [ ok ]root@Fehlermelder ~ <15:46:57> > * Starting pdnsd ... [ ok ] * Starting sshd ... [ ok ] root@Fehlermelder ~ <15:47:15> > ping www.google.de PING www.l.google.com (209.85.129.99) 56(84) bytes of data. 64 bytes from fk-in-f99.google.com (209.85.129.99): icmp_seq=1 ttl=245 time=19.8 ms How I said: After the boot process, ath0 doesn't have an IP. Network is not reachable. A simply restart of the device is sufficient to activate it. There are no error messages, no log entries, nothing where you could find an error message - even if you remove dhclient.
I can only assume that this is a madwifi / wpa_supplicant issue as my ipw2200 works fine for this scenario.
Hey Sven, did the error disappear for you? It seems me that I have a very similar error. Regards Juergen
(In reply to comment #18) > did the error disappear for you? It seems me that I have a very similar error. No, it's still present. I the meantime I did the following changes: - change from ISO to UTF-8 - deinstalled every zeroconf stuff (avahi, mDNSResponder, zeroconf) - upgraded vom openrc-0.30 to 0.43 - kernel upgrade from 2.6.26 to 2.6.28 - other systemrelated updates When I opened the bug, the system stopped when starting dbus for one minute without any message in the boot screen. To get to know the reason I had to look into /var/log/messages (see above). Now I get those suspect dhcp trials directly in the boot screen. Because of all the system updates I did since open the bug, I suppose the error isn't an openrc bug. I suspect, in the obscure deep of the system there's a evil configuration file that's responsible for this strange behaviour, because on my other computer I don't have these issues with almost the same configuration.
Please retest with the latest openrc. Will close 2011/01/01 if there is no response.
Hi Robin, The problem disappeared after I changed the Internet provider and got a new DSL-modem. Also I've got a new notebook where I installed of course a new Gentoo. Therefore I can't reproduce the error anymore. Just close the bug.
Thanks, closing with TESTREQUEST for the next person to hit this to test for us.
