# Wireless interface gets shut down

## smlgbl

Hello,

I don't know why this is happening, but lately i have come across this problem:

After some time of working, my wireless interface just gets shut down. I can't really say if it is always after the same amount of time.

All i get in the logs is this:

```
Feb 12 19:34:49 stradivari dhcpcd[6044]: terminating on signal 15

Feb 12 19:34:49 stradivari ACPI: PCI interrupt for device 0000:00:0f.0 disabled

Feb 12 19:34:49 stradivari ath_pci: driver unloaded

Feb 12 19:34:49 stradivari ath_rate_sample: unloaded

Feb 12 19:34:49 stradivari ath_hal: driver unloaded

Feb 12 19:34:49 stradivari wlan: mac acl policy unregistered

Feb 12 19:34:49 stradivari wlan: driver unloaded
```

What is going on? Anybody have clues? I mean, why is it getting the signal? If i am stupid here, pls point that out!

FYI:

```
System uname: 2.6.15-nitro3 i686 AMD Athlon(tm) XP 1600+

Gentoo Base System version 1.12.0_pre14
```

Working with wpa_supplicant-0.5.1 and the latest madwifi from portage (20060201).

Otherwise everything is working fine. It is not really a big problem, as i can just restart net.ath0 afterwards, but it kind of bugs me.

Another hint: Basically happens when i am not really doing anything network related, like really nothing or watching a movie.

Any hints are appreciated!

regards,

----------

## mars-red

I feel like a huge dope admitting this, but when I was having similar problems it ended up being that I kept hitting the hardware kill switch for my wireless radio by accident.  The button is in the worst place on my Sager laptop, so if you lean forward with it in your lap, the button gets pressed without you realizing it.

Eliminate that as a possible cause first, or you will drive yourself nuts (like me).    :Embarassed: 

----------

## smlgbl

Thanks a lot, but it is not a laptop! Normal desktop.

----------

## mars-red

Ah.  Nevermind.   :Smile: 

----------

## smlgbl

I think i solved it.

The connection to my DSL-Router and Wireless-AP Fritx-Box Fon Wlan 7050 seemed to just go down after a while.

So i switched off the option of so-called g++ mode, and it seems to be more stable like that. Will still test and then put __SOLVED__ to the title.

----------

## smlgbl

OK, i was wrong, didn't solve it. Still happens. Getting on my nerves now, big time.   :Evil or Very Mad: 

Is there a way of watching the signal strength aso. without constantly looking at my gKrellm?

Pls, any help is appreciated.

----------

## sundialsvc4

Well, that "terminated on signal 15" message seems strange.  That's SIGTERM, and that implies to me some kind of explicit request.  Not a hardware or software failure.

The first place I'd look is the "/var/log/everything/current" (or whatever) system log-file to see what is happening just before the connection goes down.  It's doubly-odd that dhcpcd is dropping for any reason...  it usually stays up the whole time the system's booted.

----------

## mars-red

haader, if you use KDE there's a little KDE panel applet that you can dock into the taskbar that will give you three small bars that represent the noise level, signal strength, and overall link quality.  It' handy to use, because it's easy to interpret and really doesn't take up any space.

----------

## smlgbl

Hi guys,

thanks a lot for your help already.

This little handy applet you are talking about is probably equivalent to what i meant with that gKrellm for the wireless card. It shows me these things, but i don't want to be looking at it constantly in 3 hours, so i thought maybe i can have it make a log or something to make sure it is not just the connection that gets dropped. But even then it would be odd for dhcpcd to just shut down.

Basically what happens is the same as when i shut the system down, except that no other process does what dhcpcd does. Before the above excerpt from the log there is nothing that would have a connection to that. Not even time-wise. I mean, the last entry before dhcpcd shutting down is sometimes hours or minutes earlier.

Thanks a lot so far. Any other suggestions are welcome!

----------

## dgaffuri

I've the same problem after upgrading to last unstable baselayout and switching to wpa_supplicant (iwconfig doesn't work anymore for me). Every night, at random hours, network stops with signal 15 received from dhcpcd.

----------

## UberLord

 *haader wrote:*   

> 
> 
> ```
> Feb 12 19:34:49 stradivari dhcpcd[6044]: terminating on signal 15
> 
> ...

 

Kernel thinks your hardware has been unplugged/disabled

 *Quote:*   

> 
> 
> FYI:
> 
> ```
> ...

 

As yes. Try a decent kernel like gentoo-sources   :Rolling Eyes: 

----------

## smlgbl

So far i never had any problems with Nitro-Sources, but just timewise it might be the problem. but i don't recall when exactly i tried the latest version or when the problem actually started.

But i'll look into the gentoo-sources.

Might it be the new baselayout dgaffuri pointed out?

Thanks a lot, to all of you.

----------

## mars-red

I've had fantastic luck with gentoo-sources, and everything works (including lappy stuff like power saving, speedstep, etc etc).

I have noticed the new ~x86 ipw2200 does not work on my system - drive loads and adapter finds wireless network, but is unable to get dhcp address - I rolled back to previous ipw2200 and it's happy again.  I don't believe that's related to your problem, though.

----------

## UberLord

 *haader wrote:*   

> Might it be the new baselayout dgaffuri pointed out?

 

As a developer for baselayout I can state that baselayout does not do anything with the disabling of hardware nor the unloading of modules.

However, feel free to experiment with the baselayout versions in portage  :Smile: 

----------

## dgaffuri

 *haader wrote:*   

> Might it be the new baselayout dgaffuri pointed out?

 

I rather suspect wpa_supplicant.

----------

## ghutzl

I am having the exact same problem. With the exception that my wireless connection barely stays up more than 10 minutes. Here's part of my /var/log/messages:

```

Feb 21 20:24:51 B9993RZV dhcpcd[9868]: broadcasting DHCP_REQUEST for 192.168.1.6

Feb 21 20:24:53 B9993RZV dhcpcd[9868]: broadcastAddr option is missing in DHCP server response. Assuming 192.168.1.255

Feb 21 20:24:53 B9993RZV dhcpcd[9868]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Feb 21 20:24:53 B9993RZV dhcpcd[9868]: dhcpT1value is missing in DHCP server response. Assuming 43200 sec

Feb 21 20:24:53 B9993RZV dhcpcd[9868]: dhcpT2value is missing in DHCP server response. Assuming 75600 sec

Feb 21 20:24:53 B9993RZV dhcpcd[9868]: DHCP_ACK received from  (192.168.1.254)

Feb 21 20:24:53 B9993RZV dhcpcd[9872]: terminating on signal 15

```

I can restart the connection by "/etc/init.d/net.ath0 restart" but after a couple of minutes the connection drops again.  :Sad: 

```

*/ $ uname -a

Linux B9993RZV 2.6.15-gentoo-r1 #3 Thu Feb 9 17:20:05 CET 2006 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux

```

So at least you see you are not alone  :Smile:  .

But seriously, I definitely want to figure this one out and get it fixed, but I have no clue. I am using baselayout-1.12.0_pre16-r1 and wpa_supplicant-0.5.1. My wireless card is atheros based therefore I use madwifi-driver-0.1443.20060207 . Anyone having some hint what to look for?

Thanks!

----------

## smlgbl

I didn't really change anything, but it seems like it didn't do it yesterday or today. I'll keep on watching. Fortunately it's not as bad with me as with ghutzl, sorry.

I tried just going back to wpa_supplicant-0.5.0, but i didn't know how to with portage.

----------

## ghutzl

I think I can help you with downgrading to an older version: Just mask the higher versions that you don't want by adding them to your /etc/portage/package.mask. For getting wpa_supplicant-0.5.0 you just add these two lines to your /etc/portage/package.mask:

```
=wpa_supplicant-0.5.0-r1

=wpa_supplicant-0.5.1
```

The following line would maks all ebuilds of wpa_supplicant higher than 0.5.0:

```
>wpa_supplicant-0.5.0
```

When you emerge wpa_supplicant now it should emerge wpa_supplicant-0.5.0.

I am still trying to investigate the problem. I was thinking about a program to monitor signals, so i could find out from where the signal 15 comes from. Currently my solution is to attatch the gdb debugger to the dhcp process with

```
gdb --pid=<PID>
```

But now I don't know if I should cry or laugh, but it does not happen any more !!!??? At least not for the past 20 min. or so. I will wait a little longer and see.....

----------

## ghutzl

More news....

gdb didn't help. The dhcp process  got killed and gdb just told me about the SIGTERM that the process got, but not from where it got it. Seems like I have to look for something else. Anyone having any idea?

----------

## UberLord

Why not try another dhcp client? There's another 3 in portage

----------

## smlgbl

Hey guys,

as sudden as it started it left again. I haven't had this problem for a couple of days. Just disappeared.

...these things make me wonder...

----------

## morbid

I'm still having this issue.  I've been thinking it was ifplugd... but net.ath0 shows as still running when my ath0 interface disappears.  It has nothing to do with usage either... it keeps crapping out while I'm downloading OOo 2.0.2.

Oh... the reason I've thought it was ifplugd is because I never start net.ath0... it starts automatically.  But in my ifplugd config, I specify it to only manage eth0 and also to ignore wireless connections.  Neither net.ath0 or net.eth0 are in a runlevel.

----------

## smlgbl

I also experience it again. At first i wanted to just try another dhcp-client, like uberlord suggested, but now i've just tried updating madwifi, as there is an update available. We'll see, i just did the update like half hour ago, but will post back soon, if there are any changes.

----------

## smlgbl

Could the people experiencing this problem pls post their kernel-versions and details, just to see if it is maybe the kernel-sources or nitro or something!

Thanks!

----------

## morbid

sys-apps/baselayout-1.12.0_pre16-r3

net-wireless/madwifi-driver-0.1473.20060312

net-wireless/madwifi-tools-0.1473.20060312

net-wireless/wireless-tools-28_pre15

sys-kernel/archck-sources-2.6.15_p7

Despite these versions... I've been having this issue for about 3 months.

And I guess it's not ifplugd... I stopped it and manually started ath0 and eth0, but ath0 keeps disappearing and net.ath0 shows as "inactive".

----------

## 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.

----------

## 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.

----------

## ghutzl

Hi it's me again.  :Smile: 

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,

----------

## 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

 *l1th10n wrote:*   

> 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.

 

Fixed in 1.12.0_pre17-r3.

Thanks for the very detailed report  :Smile: 

If only other reports where as detailed   :Evil or Very Mad: 

----------

## smlgbl

 *UberLord wrote:*   

> 
> 
> Fixed in 1.12.0_pre17-r3.
> 
> 

 

Maybe this is the wrong place now, but i just upgraded to the abovementioned version, and now i am getting lots of 

```
svcdir: read only variable! /etc/conf.d/rc line 200
```

Also wpa_supplicant doesn't call dhcpcd automatically anymore. I guess. It gets a connection, but i have to manually run dhcpcd to get an IP.

Any help appreciated. Or should i just revert to the old version?

Besides: How do i tell, if dhcpcd or udhcpc is used by wpa_supplicant?

----------

## UberLord

 *haader wrote:*   

> Maybe this is the wrong place now, but i just upgraded to the abovementioned version, and now i am getting lots of 
> 
> ```
> svcdir: read only variable! /etc/conf.d/rc line 200
> ```
> ...

 

Are you referencing /etc/conf.d/rc or rc in any config files? If not, tar up your /etc/{rc.conf,conf.d,init.d} and email it to me at uberlord@gentoo.org please

 *Quote:*   

> Also wpa_supplicant doesn't call dhcpcd automatically anymore. I guess. It gets a connection, but i have to manually run dhcpcd to get an IP.

 

Maybe related to the above error. I'm pretty sure this is a configuration issue.

 *Quote:*   

> Besides: How do i tell, if dhcpcd or udhcpc is used by wpa_supplicant?

 

Set RC_VERBOSE="yes" and RC_PARALLEL_STARTUP="no" to see what modules are loaded.

----------

## aurorix

I can confirm this issue is SOLVED for me.

Thanks.

----------

