I have a system setup as an AP using an atheros card. It worked fine until recently when I decided to install fresh the 2008 beta. I'm now unable to get my atheros card to work in AP mode. I have tried both 0.9.3.3 and 0.9.4 with both hardneed-2.6.24-r2 and hardened-2.6.23-r12. both kernels have no settings active i.e. SELinux, PAX or GRSecurity etc. When you run the /etc/init.d/net.ath0 script the system always locks up. There is no Reproducible: Always Steps to Reproduce: 1. emerge kernal and madwifi-ng module 2. set it up as an AP 3. reboot Actual Results: The system will hang shortly after running the net.ath0 script. You can test this by going into Interactive boot mode and skipping the net.ath0 section. Your system will boot perfectly.
Hi, let's find out if we can get some error messages. please start in interactive mode and go to shell. Then run $ tail -f /var/log/messages & $ /etc/init.d/net.ath0 start and there should be some output you can post here
There is no chance of getting any information after running /etc/init.d/net.ath0 as the system totally freezes. if you count to 10 after running net.ath0 my system is totally dead. No kernel panic. it just stops. Here's my output from things: # /etc/init.d/net.ath0 start * Starting ath0 * Configuring wireless network for ath0 * ath0 configured as ESSID "R2D2" * in master mode on channel 2 (WEP disabled) * Bringing up ath0 * 10.0.0.1 [ ok ] rjs ~ # rjs ~ # cat /etc/modprobe.d/ath_pci options ath_pci autocreate=ap rjs ~ # cat /etc/conf.d/net config_eth0=( "dhcp" ) dhcpcd_eth0="-t 0" config_wlan0=( "null" ) modules_ath0=("iwconfig") config_ath0=( "10.0.0.1 netmask 255.255.255.0 broadcast 10.0.255" ) essid_ath0="R2D2" mode_ath0="master"
one thing I've just thought of is that I use metalog as my syslog. this could be buffering things for a short time and that could be why I've not got anything new added to my log files. I'll reboot and check my buffering and see if I get any new output. if it helps, I don't mind sending someone an Atheros PCI card to help troubleshoot.
Please provide `emerge --info` output.
Created attachment 155211 [details] emerge --info
Created attachment 155213 [details] kernel config
ok, there's good news and bad news ;-) if I start my system without running net.ath0 I am able to see my wifi0 and ath0 interfaces when I type "ip add list" However, I can then bring up the AP by typing the following: iwconfig ath0 mode master iwconfig ath0 essid R2D2 ifconfig ath0 10.0.0.1/24 now if I restart my required services i.e dhcpd, named and shorewall I am able to use my system as an AP. It looks like there is something in net.lo that causes this to hang :-(
oops, I forgot that before setting the "master" mode I "ifconfig ath0 up" the device to make it active. this has avoided using any /etc/init.d/net.* scripts and it all works fine.
what happens if you run /etc/init.d/net.ath0 --debug start?
Created attachment 155417 [details] output from net.ath --debug start the instant we get to the very last line with "+ exit 0" the system freezes. My putty/ssh client ends the connection as it tells me the host isn't there anymore. I can no loger use the computer and I'm unable to ping the hardwired net.eth0 device either.... it all stops.
I noticed in that debug output that my broadcast address was missing a '0', but adding that in didn't fix it from freezing :-(
Created attachment 155445 [details] Robert Reese - .config
Created attachment 155447 [details] Robert Reese - emerge --info
(In reply to comment #11) > I noticed in that debug output that my broadcast address was missing a '0', but > adding that in didn't fix it from freezing :-( > Too have the same issue. As soon as the net.ath0 script runs the system hangs. I have attached my info above.
(In reply to comment #14) > (In reply to comment #11) > > I noticed in that debug output that my broadcast address was missing a '0', but > > adding that in didn't fix it from freezing :-( > > > > Too have the same issue. As soon as the net.ath0 script runs the system hangs. > I have attached my info above. > Sorry, forgot to mention that I too can bring the interface up manually and everything seems fine, in fact I am connect through the system in master mode right now.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #11) > > > I noticed in that debug output that my broadcast address was missing a '0', but > > > adding that in didn't fix it from freezing :-( > > > > > > > Too have the same issue. As soon as the net.ath0 script runs the system hangs. > > I have attached my info above. Also, I don't believe this is limited to 2008 beta as my make.profile is still linked to 2007.0 > > > > > Sorry, forgot to mention that I too can bring the interface up manually and > everything seems fine, in fact I am connect through the system in master mode > right now. >
FYI I created my own init script to bring the card up and config it for master and it works fine at boot.
Robert could you attach script here? Also in your initial post you mention that previously everything worked. Did you use exact same kernels/modules? Also search upstream bugreports if you find something relevant there could fill in URL and if there is not upstream bug reports, please, fill in new one and update URL here :)
(In reply to comment #18) > Robert could you attach script here? Also in your initial post you mention that > previously everything worked. Did you use exact same kernels/modules? Also > search upstream bugreports if you find something relevant there could fill in > URL and if there is not upstream bug reports, please, fill in new one and > update URL here :) I had a working system until I re-installed with a 2008.0 stage3 tarball. I was using the same 2.6.24-r2 kernel before on my working system and for the rebuild I used the same /etc/kernels/kernel-config-x86-2.6.24-hardened-r2 file for the new kernel build. I believe that this is a problem more to do with the baselayout scripts rather than something wrong in the madwifi-ng module. I say this because if you don't use an /etc/init.d/net.ath0 script to configure your interface everything works fine. For example, here are the commands I have added to my /etc/conf.d/local.start: ifconfig ath0 up iwconfig ath0 mode master iwconfig ath0 essid MYWLAN ifconfig ath0 10.0.0.1 netmask 255.255.255.0
Reading bugs over bugzilla I found that madwifi-ng modules are really very fragile. It's even hard to say when they does work and when not. People tried to investigate similar problems but the fixes which helped some people breaked others. Some people fixed some issues putting different stuff in preup() function, but again: no universal solution found. So I'm not sure what can we do with this software at the moment. I've looked at debian package and they do not' use any patches too, while they have similar reports. Thus at the moment I'm more inclined to say that this is upstream bug. (resolving UPSTREAM for now).
(In reply to comment #20) > Reading bugs over bugzilla I found that madwifi-ng modules are really very > fragile. It's even hard to say when they does work and when not. People tried > to investigate similar problems but the fixes which helped some people breaked > others. Some people fixed some issues putting different stuff in preup() > function, but again: no universal solution found. > > So I'm not sure what can we do with this software at the moment. I've looked at > debian package and they do not' use any patches too, while they have similar > reports. > > Thus at the moment I'm more inclined to say that this is upstream bug. > (resolving UPSTREAM for now). > Here is the script I am using, it is actually VERY simple and just a bash script: #!/bin/bash iwconfig ath0 essid mwap iwconfig ath0 channel 11 iwconfig ath0 rate 54M ifconfig ath0 up ifconfig ath0 10.10.220.254 netmask 255.255.255.240 That is pretty much it. I just copied it /etc/init.d/net.ath0 and it works as a work-around. Like I said earlier I don't believe this to be limited to the stage3 2008 tarball as I used stage3-x86-2007.0.tar.bz2 for this build. I agree that this driver is touchy, but I there has to be something in the network init script that is causing this. Of not I have seen the card lock the system up by bringing it manually if certain attributes are configured before other. I dont remember specifically but an example would be something like applying the channel to the interface before the ssid is applied. The above sequence in my "script" has worked every time though.
(In reply to comment #21) > (In reply to comment #20) > > Reading bugs over bugzilla I found that madwifi-ng modules are really very > > fragile. It's even hard to say when they does work and when not. People tried > > to investigate similar problems but the fixes which helped some people breaked > > others. Some people fixed some issues putting different stuff in preup() > > function, but again: no universal solution found. > > > > So I'm not sure what can we do with this software at the moment. I've looked at > > debian package and they do not' use any patches too, while they have similar > > reports. > > > > Thus at the moment I'm more inclined to say that this is upstream bug. > > (resolving UPSTREAM for now). > > > > Here is the script I am using, it is actually VERY simple and just a bash > script: > > #!/bin/bash > iwconfig ath0 essid mwap > iwconfig ath0 channel 11 > iwconfig ath0 rate 54M > ifconfig ath0 up > ifconfig ath0 10.10.220.254 netmask 255.255.255.240 > > That is pretty much it. I just copied it /etc/init.d/net.ath0 and it works as a > work-around. > > Like I said earlier I don't believe this to be limited to the stage3 2008 > tarball as I used stage3-x86-2007.0.tar.bz2 for this build. I agree that this > driver is touchy, but I there has to be something in the network init script > that is causing this. Of not I have seen the card lock the system up by > bringing it manually if certain attributes are configured before other. I dont > remember specifically but an example would be something like applying the > channel to the interface before the ssid is applied. The above sequence in my > "script" has worked every time though. > And just FYI I set master mode as module option in /etc/modprobe.d/ath_pci file: options ath_pci autocreate=ap
I'm sorry, but I don't understand how this can be an upstream problem? If it was a problem in the madwifi module then we'd not be able to configure things without using the /etc/init.d/net.* scripts. This looks prettly black and white to me that it an issue with /etc/init.d/net.lo rather than a bug in Madwifi-ng. As we can see from this thread, for more than one person it *IS* working if they avoid using the gentoo init.d scripts. I can't see any reason to marking this as upstream?
(In reply to comment #22) > And just FYI I set master mode as module option in /etc/modprobe.d/ath_pci > file: > options ath_pci autocreate=ap yes, I've been doing the same :-)
(In reply to comment #24) > (In reply to comment #22) > > And just FYI I set master mode as module option in /etc/modprobe.d/ath_pci > > file: > > options ath_pci autocreate=ap > > yes, I've been doing the same :-) > Might be off topic but it would be cool if we could get just the first interface to come up in ap and the rest are normal.
(In reply to comment #25) > Might be off topic but it would be cool if we could get just the first > interface to come up in ap and the rest are normal. > you can already do that, read up on how to do module aliases ;-) add this to your ath_pci file where you set the device as ap etc. --- start of additions to /etc/modprobe.d/ath_pci alias ath0 ath_pci alias ath1 ath_pci options ath0 autocreate=ap options ath1 autocreate=sta --- end of example --- This should work (from memory, and not tested) so if it doesn't please open a thread on the forums rather than coming back to this bug report and I'll try and help there as its not relevant to this topic.
Well, actually this is duplicate of bug 212180. But I'll not close this bug atm as such... Now that bug is resolved as upstream too because this driver should not hang the system in *any* cases because openrc/baselayout does not do anything specific besides what wireless-tools interface allows us to do... It's not sane to introduce any hacks around buggy driver code just to avoid hang in this specific situation. It's driver that should be fixed. But taking into account that upstream now is more concentrated on new driver which will be distributed with kernel let's try to find better solution for this problem... Please try to run from remote machine /etc/init.d/net.ath0 --debug start &> net.ath0.log to see what commands our init system calls (I assume you are using openrc). And then try to localize at what command system hangs running them manually one by one. Please, attach output and any further ideas here... Also you could try set channel as suggested in that bug in preup function and report if that works for you.
I had problems which I described in bug 212180. Madwifi have buggy channel switch. There are also problems with channels on my eeePC. Madwifi first d not set correct channel, but when restarted again it does. Looks like the only solution is to set channel BEFORE doing anything else with athX. This can really help: CHANNEL="1" preup(){ if [ "${IFACE}" = "ath0" ]; then /sbin/iwconfig ath0 channel ${CHANNEL} return $? fi }
Richard, can you confirm observations made by Dmitry?
(In reply to comment #29) > Richard, can you confirm observations made by Dmitry? > I don't think I've ever set a specific channel number, but I will try in the morning and let you know :-)
nope, sorry, it still hangs just at slightly different times. The /etc/init.d/net.ath0 output tells me that the channel has been set to channel 1 rather than the channel 10 that the preup asks for. With the preup active the net.ath0 script is able to exit back to the command prompt before the system hangs. Without the preup the script hangs during execution. Is there any way to get a list of commands the net.ath0 executes so I can try them one at a time to see where the problem is??
I've noticed that in the output from net.ath0 the ESSID looks to be being set before master mode is called and in my local.start file I am setting master mode before the ESSID. Perhaps you can only set master mode when its not associated to an ESSID?? I will switch my script round when I'm home later today to see if it locks up also.
Nope, its not the ESSID being set at the wrong time. I wonder if this still happens with Baselayout-2? Is Baselayout-2 stable enough to upgrade with yet?? (In reply to comment #32) > I've noticed that in the output from net.ath0 the ESSID looks to be being set > before master mode is called and in my local.start file I am setting master > mode before the ESSID. > > Perhaps you can only set master mode when its not associated to an ESSID?? > > I will switch my script round when I'm home later today to see if it locks up > also. >
good morning everybody, i am expirencing the same issue. on my old server (amd - 32bit) the 0.9.4 and 0.9.3.3 versions worked without any problems. By installing a new server (amd - 64bit) the system freezes as discribed evreytime i start the init script. i am using an AR5212 chip as an AP. The only solution i found was using newer drivers. currently i am using the 0.10.5.6 version, but it is not really stable. i am getting a lot of these errors: wifi0: ath_rxorn_tasklet: Receive FIFO overrun; resetting. wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11) does somebody know any solution, yet? is the ath5k driver ready for master mode now? greets, ben
(In reply to comment #34) > good morning everybody, > i am expirencing the same issue. on my old server (amd - 32bit) the 0.9.4 and > 0.9.3.3 versions worked without any problems. By installing a new server (amd - > 64bit) the system freezes as discribed evreytime i start the init script. i am > using an AR5212 chip as an AP. The only solution i found was using newer > drivers. currently i am using the 0.10.5.6 version, but it is not really > stable. i am getting a lot of these errors: I don't think its anything to do with the madwifi-ng driver anymore as when you configure things by hand it all works! (see a post above for the commands I use). IMHO it's something in the baselayout that's messing things up as it seems to configure the interface in an odd way. When you say your using version 0.10.5.6 what is that for??
0.10.5.6 means, i am using the madwifi-ng and madwifi-ng-tools ebuild vrom here: https://bugs.gentoo.org/show_bug.cgi?id=234126
after updated to baselayout-2.0.0, madwifi-ng svn,openrc-0.3.0-r1，the system still hang after start net.ath0. /etc/conf.d/net: modules_ath0="iwconfig" mode_ath0="master" essid_ath0="MyWlan" channel_ath0="1" iwpriv_ath0="bgscan 0" key_ShingsPvtWlan=sdaad34efdgredxzvsdzf I created /etc/init.d/net.ath0 and replace the original one, the system works perfectly: #!/sbin/runscript depend() { after net.lo return 0 } start() { ebegin "Starting ath0" iwconfig ath0 mode master iwconfig ath0 essid MyWlan iwconfig ath0 channel 1 iwconfig ath0 key sdaad34efdgredxzvsdzf iwpriv ath0 bgscan 0 eend $? } stop() { ebegin "Stopping ath0" eend $? }
Created attachment 195716 [details] Brad Worley: .config
Created attachment 195717 [details] Brad Worley: emerge --info
i can confirm this as well. 1.) using the net.ath0 init script hangs the system, but not into a panic. instead, i can use Alt+F2 to switch to the second virtual screen (with no getty) and back, but nothing is running. 2.) AR5212 chipset (netgear wpn311), madwifi-ng-0.9.4. 3.) running the following commands after startup bring the interface up correctly, without hanging the system: # ifconfig ath0 up # iwconfig ath0 mode master # iwconfig ath0 essid ESSID # ifconfig ath0 192.168.0.1 netmask 255.255.255.0 4.) extra information: # cat /etc/modprobe.d/ath_pci options ath_pci autocreate=ap # cat /etc/conf.d/net config_eth1=( "dhcp" ) config_ath0=( "192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255" ) mode_ath0="master" essid_ath0="ESSID" same behavior. will try the workaround by forging a custom init script instead. ~ brad.
*** Bug 289516 has been marked as a duplicate of this bug. ***
I had to reinstall my router, tried the default setup via conf.d/net instead of the custom script and was happy to see that the system doesn't hang anylonger. The version of madwifi-ng i'm running is 0.9.4.4133.20100621 on an otherwise stable x86 installation which currently means gentoo-sources 2.6.36-gentoo-r5. the wlan card is: 00:11.0 Ethernet controller: Atheros Communications Inc. AR5413 802.11abg NIC (rev 01) Subsystem: Giga-byte Technology GN-WI01HT Wireless a/b/g MiniPCI Adapter Kernel driver in use: ath_pci
i've encountered same problem with madwifi. Channel switching is problematic when 'option autocreate=ap' is used. Leave it unset to happily switch channels. I am aware that this is partial solution, but as far as i tested it, Gentoo's initscript net.ath0 _can_ switch mode to master(ap) without hanging whole system. Try this one as evidence. for i in `seq 1 12`;do iwconfig ath0 channel $i;echo $i 'still alive';sleep 2;done
(In reply to comment #43) > i've encountered same problem with madwifi. Channel switching is problematic > when 'option autocreate=ap' is used. Leave it unset to happily switch channels. > I am aware that this is partial solution, but as far as i tested it, Gentoo's > initscript net.ath0 _can_ switch mode to master(ap) without hanging whole > system. > > Try this one as evidence. > for i in `seq 1 12`;do iwconfig ath0 channel $i;echo $i 'still alive';sleep > 2;done > Sorry, it was not quite true. It is inproblematic when using any madwifi with AR5212, which i have in my laptop. With AR2413 in my workstation autocreate=ap and then switching channels still causes system to hang, Gentoo also is not able to switch between modes.
Madwifi has been masked as it has been replaced by ath5k/ath9k upstream for years now. Please migrate to a maintained driver.
