Wireless interface gets shut down

[smlgbl]

Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-nitro3 i686)
=================================================================
System uname: 2.6.15-nitro3 i686 AMD Athlon(tm) XP 1600+
Gentoo Base System version 1.12.0_pre14

wpa_supplicant v0.5.1
net-wireless/madwifi-driver-0.1473.20060312
net-wireless/madwifi-tools-0.1473.20060312
net-wireless/wireless-tools-28_pre10

So far the connection just gets slower and slower, starts with 54 MB/s and slowly goes down to 1MB/s. Then it just disappears. Can't say this is always the procedure, as i don't sit in front of it all the time.
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening'

[smlgbl]

Quick update:

Meanwhile using 2.6.16-nitro_git3-Kernel, the madwifi-svn-version provided by Tiger683 in the thread about that kernel-patchset and like i mentioned before, i moved the access point from under my bed, to next to it. So far it seems to be stable now. I hope it stays that way.
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening'

[ghutzl]

Hi it's me again.

I still see that problem, too. I tried a couple of things in the meantime:

• I tried every dhcp client available in portage and nothing changed. (pump, dhcpcd, dhclient, ...)
  
• Tried different versions of madwifi
  
• Ping of some server about every 30sec , e.g. ping -i 30 www.google.de
  -> This seemed to help a little, at least it kept the connection up a little longer. But after some time the connection drops anyway.
  -> Can anyone reproduce this, please? (Or is our just random and I was lucky while I tried it?)
  

Here is my System info:

Portage 2.1_pre7-r4 (default-linux/x86/2006.0, gcc-3.3.6, glibc-2.3.5-r3, 2.6.15-gentoo-r1 i686)
=================================================================
System uname: 2.6.15-gentoo-r1 i686 Intel(R) Pentium(R) M processor 1700MHz
Gentoo Base System version 1.12.0_pre16

sys-apps/baselayout-1.12.0_pre16-r3
net-wireless/madwifi-driver-0.1485.20060325
net-wireless/madwifi-tools-0.1485.20060325
net-wireless/wireless-tools-28_pre14
sys-kernel/gentoo-sources-2.6.15-r1
net-wireless/wpa_supplicant-0.5.2

[l1th10n]

This one was really bugging me! So after hours of investigation I found out how to fix the problem. As I originally suspected it was a bug with the baselayout scripts (I will fill out a bugzilla report later). I got the latest version of baselayout (1.12.0_pre17-r2) and the problem still exists in this version. The problem occurs in the /lib/rcscripts/net.modules.d/dhcpcd.sh file, line 60. start-stop-daemon is used instead of the /sbin/start-stop-daemon. Using the start-stop-daemon function defined in /lib/rcscripts/sh/rc-daemon.sh to kill a process without creating the process (as is done in dhcpd.sh) causes the /var/lib/init.d/daemons/net.xxx to lose track of the wpa_supplicant process. When this occurs the code in the /lib/rcscripts/net.modules.d/wpa_supplicant.sh module kills the wpa_supplicant process when the wifi connection is lost. And thus no more wifi. If you edit the dhcpcd.sh file and change start-stop-daemon to /sbin/start-stop-daemon then the cascade of failure will not occur and the wifi connection will reestablish after the wifi connection is temporarily lost.

Actually there is also a bug in the start-stop-daemon function which removed the reference to wpa_supplicant when start-stop-daemon --kill was called with reference to dhcpcd.

Hope this helps.

[smlgbl]

Thanks for those hints, but i don't seem to have any reference to the start-stop-daemon in the "dhcpcd" called file in the /lib/rc-scripts/net.modules.d/ directory.
I grepped for start-stop-daemon in that directory and the only references are found in the wpa_supplicant file. I've changed those now. Gotta try.
But it is difficult to say if this is it, as it still happens, but only like once a week. Don't know.

Thanks again, will reply when there is something new.

regards,
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening'

[aurorix]

l1th10n,

I'm running the same version of baselayout you are (1.12.0_pre17-r2) and appear to be having the same problem as other people in this thread. I've looked thru the scripts and what you're saying appears to make sense (good job tracking it down!) My wireless is usually guaranteed to require a restart after having been left overnight; I've made the change now, and will let you know tomorrow how it goes.

[UberLord]

[smlgbl]

[UberLord]

[aurorix]

I can confirm this issue is SOLVED for me.

Thanks.