Summary: | sys-apps/openrc: static net configuration fails with ath5k | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven Müller <musv> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | musv |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | openrc:oldnet due:2011/01/01 | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
dmesg
Boot messages emerge --info ifconfig /etc/conf.d/net |
Description
Sven Müller
2008-10-07 14:18:02 UTC
*** 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. |