madwifi makes board crash after bursting packets
Dennis Borgmann <[email protected]> Wed, 17 Nov 2010 15:59:47 +0100
| Newsgroups | gmane.linux.drivers.hostap,gmane.linux.drivers.madwifi.user,gmane.linux.drivers.madwifi.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello madwifi-lists! Hello hostapd-list! Since I do not know, which of the madwifi-lists is still active and read, I post my question to both madwifi-users and madwifi-dev. See my setup below. If I burst data from one point to the other (lets say with 'scp' a file of about 2GB size) at full speed (with the distance I got right now (1m) about 23Mbit/s) the AP crashes after quite some time (~1 hour). I am not able to check what is going on on the machine that runs the AP, because the attached serial console won't respond anymore and I cannot establish any connection to the AP anymore. It is still transmitting beacons and can be recognized by any wireless station (with the one being the client with 'iwlist ath0 scan' and with a laptop not involved in the wireless connection on my desk with 'iwlist wlan0 scan'). So I fear, I cannot give that much debug output, since I can't access the AP anymore. Rebooting the AP solves the problem immediately and the client connects to the AP directly making data transfer possible again. I could not reproduce this problem with low traffic, since I did a 'ping -f IP' last night and it was still up this morning after 14 hours. Running an iperf yesterday got the client crashed. Same problem - I couldn't connect to it anymore via the serial console. Since it is not transmitting beacons while being a station, I cannot tell, if the wireless device was still up in any way. My setup: madwifi 0.9.4 - running on AP and Client hostapd v0.6.9 on AP side with RSN-encryption wpa_supplicant v0.6.9 on client side with RSN-encryption 2 PC Engines ALIX3D2-Boards (x86, 500MHz, headless systems) Alfa networks MiniPCI-WAN cards with Atheros AR5414 chipset I am using madwifi-0.9.4 on a productive system and I am not able to switch to a newer driver within a recent kernel in a rush. Therefore I'd like to stick with it, if that's possible. Does this problem sound familiar to anyone? Are there any hints, what I still might try before I am urged to move to a recent driver? Thanks for any hint. Kind regards, Dennis