Re: hostapd deauthentication every 5 seconds [FIXED]
Interesting, thanks for the info - should I post a new bug report as that one is closed? If you can repeat it on a -current snapshot, yes please. I have upgraded to the latest -current snapshot (see dmesg below). My AP has now been up for 48hrs without interruption, so I can confirm that ral+ wpa works on my 2860 card (SparkLAN WMIR-215GN). Thanks to the developers for all the hard work on this - you have a happy customer who is off to buy another T-Shirt. Additionally thanks to all those who have contributed to this thread which has pointed me in the right direction. Cheers now, Joe. OpenBSD 4.8-current (GENERIC) #356: Thu Sep 16 06:07:14 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 268009472 (255MB) avail mem = 253652992 (241MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:18:e5:d4 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:18:e5:d5 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 15, address 00:0d:b9:18:e5:d6 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 12 function 0 Ralink RT2860 rev 0x00: irq 9, address 00:0e:8e:22:66:d8 ral0: MAC/BBP RT2860 (rev 0x0102), RF RT2820 (MIMO 2T3R) glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: LEXAR ATA FLASH CARD wd0: 1-sector PIO, LBA, 7631MB, 15630048 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 12, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 12 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 biomask 71e7 netmask ffe7 ttymask mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum softraid0 at root root on wd0a swap on wd0b dump on wd0b clock: unknown CMOS layout
Re: hostapd deauthentication every 5 seconds
for wpa+ral, you should definitely run -current or 4.8. On 2010-09-18, Todd Carson t...@daybefore.net wrote: On Sat, Sep 18, 2010 at 01:01:43PM +0100, Joe Martel wrote: If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap box it might temporarily fix things Yes it does, thanks. Have added a cron job to run this every 24hrs. I have a similar problem against which ifconfig down; up isn't effective. My card is an RT2561, and when I turn on ifconfig debug on both the client and AP, I see that the AP responds to the association request and sends the first packet of the 4-way handshake. The client receives the association response, fails to receive the handshake initiation, and receives a deauth after timing out. AP side: ral0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 105 mode 11g ral0: sending assoc_resp to xx:xx:xx:xx:xx:xx on channel 6 mode 11g ral0: sending msg 1/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx last message repeated 2 times ral0: station xx:xx:xx:xx:xx:xx deauthenticate (reason 15) ral0: sending deauth to xx:xx:xx:xx:xx:xx on channel 6 mode 11g client side: athn0: sending auth to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received auth from yy:yy:yy:yy:yy:yy rssi 47 mode 11g athn0: sending assoc_req to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received assoc_resp from yy:yy:yy:yy:yy:yy rssi 46 mode 11g athn0: associated with yy:yy:yy:yy:yy:yy (...) athn0: received deauth from yy:yy:yy:yy:yy:yy rssi 46 mode 11g Turning off WPA2 doesn't allow clients to use the network; it just fails differently, though I unfortunately don't have log captures of that at the moment. The only reliable way I've found to resurrect the AP is a cold power cycle. Is this also a known issue? Is there any more targeted tracing I could try compiling into my kernels besides RAL_DEBUG, ATHN_DEBUG, IEEE80211_DEBUG? I'm wondering if this has something to do with crypto parameters on the card not being reset in all cases, but I don't know enough about either the hardware or the 802.11 protocol to have any idea whether that makes sense.
Re: hostapd deauthentication every 5 seconds
On 2010-09-18, Joe Martel j...@joemartel.com wrote: Known problem (see PR 5958), no fix known but it may be connected with wireless stations using power-saving mode. Interesting, thanks for the info - should I post a new bug report as that one is closed? If you can repeat it on a -current snapshot, yes please. Afaik my stations are not using power-saving mode (they all have a power cord, so I assume they would not need to save power) power-saving with 802.11* is where the AP buffers frames for clients so they don't have to turn on their receiver so often (they turn it on at certain intervals so they can learn if they have to leave it on for longer to receive any buffered frames). There are a couple of different specs, an older one that many devices support, and a newer 802.11e WMM-PS one. It's not necessarily connected with whether or not a device is on battery power. * Macbook Pro * Cisco WVC2300 * Playstation 3 Other devices in the local area might do it too. (And some devices turn on power-saving mode without a way to disable it e.g. Blackberrys and I think some iPhones).
Re: hostapd deauthentication every 5 seconds
Interesting, thanks for the info - should I post a new bug report as that one is closed? If you can repeat it on a -current snapshot, yes please. I'm happy to help by upgrading to a -current snapshot. Have read FAQ 5 but, when 4.8 is released in November, can I upgrade from -current to 4.8Rel ? Afaik my stations are not using power-saving mode (they all have a power cord, so I assume they would not need to save power) power-saving with 802.11* is where the AP buffers frames for clients so they don't have to turn on their receiver so often (they turn it on at certain intervals so they can learn if they have to leave it on for longer to receive any buffered frames). There are a couple of different specs, an older one that many devices support, and a newer 802.11e WMM-PS one. It's not necessarily connected with whether or not a device is on battery power. Cheers for the info - I see from rt2860.c on -current, that a lot of work has gone into the driver (indeed, all the ral drivers) since 4.7.
Re: hostapd deauthentication every 5 seconds
On 2010-09-20, Joe Martel j...@joemartel.com wrote: Interesting, thanks for the info - should I post a new bug report as that one is closed? If you can repeat it on a -current snapshot, yes please. I'm happy to help by upgrading to a -current snapshot. Have read FAQ 5 but, when 4.8 is released in November, can I upgrade from -current to 4.8Rel ? That would be a downgrade (the tree was tagged in August; the gap between then and release is for testing, cd production, package building, etc). Downgrading might work, but it's not really supported, and you may get into a slight mess with shared libraries. Easier to stick with -current until 4.9 if you do that (or just stick with -current; I would suggest keeping an eye on at least plus48.html if not the source-changes list if running -current but it's not really difficult/scary).
Re: hostapd deauthentication every 5 seconds
AP side: ral0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 105 mode 11g ral0: sending assoc_resp to xx:xx:xx:xx:xx:xx on channel 6 mode 11g ral0: sending msg 1/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx last message repeated 2 times ral0: station xx:xx:xx:xx:xx:xx deauthenticate (reason 15) ral0: sending deauth to xx:xx:xx:xx:xx:xx on channel 6 mode 11g Have now switched on ifconfig debug - will post results when the problem next occurs... For the record, a correct handshake looks like this: AP side: ral0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 36 mode 11g ral0: sending assoc_resp to xx:xx:xx:xx:xx:xx on channel 8 mode 11g ral0: sending msg 1/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx ral0: received msg 2/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx ral0: sending msg 3/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx ral0: received msg 4/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx There is also an occasional group handshake, which looks like this: AP side: ral0: sending msg 1/2 of the group key handshake to xx:xx:xx:xx:xx:xx ral0: received msg 2/2 of the group key handshake from xx:xx:xx:xx:xx:xx Also, I see this in syslog during times when I know the wireless was down - could this be related? Sep 19 09:00:11 bowser /bsd: Data modified on freelist: word 5 of object 0xd1147000 size 0xffc previous type devbuf (0xefffeecb != 0xefffeecc)
Re: hostapd deauthentication every 5 seconds
Known problem (see PR 5958), no fix known but it may be connected with wireless stations using power-saving mode. Interesting, thanks for the info - should I post a new bug report as that one is closed? Afaik my stations are not using power-saving mode (they all have a power cord, so I assume they would not need to save power) * Macbook Pro * Cisco WVC2300 * Playstation 3 If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap box it might temporarily fix things Yes it does, thanks. Have added a cron job to run this every 24hrs.
Re: hostapd deauthentication every 5 seconds
Known problem (see PR 5958), no fix known but it may be connected with wireless stations using power-saving mode. Interesting, thanks for the info - should I post a new bug report as that one is closed? Afaik my stations are not using power-saving mode (they all have a power cord, so I assume they would not need to save power) * Macbook Pro * Cisco WVC2300 * Playstation 3 If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap box it might temporarily fix things Yes it does, thanks. Have added a cron job to run this every 24hrs.
Re: hostapd deauthentication every 5 seconds
On Sat, Sep 18, 2010 at 01:01:43PM +0100, Joe Martel wrote: If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap box it might temporarily fix things Yes it does, thanks. Have added a cron job to run this every 24hrs. I have a similar problem against which ifconfig down; up isn't effective. My card is an RT2561, and when I turn on ifconfig debug on both the client and AP, I see that the AP responds to the association request and sends the first packet of the 4-way handshake. The client receives the association response, fails to receive the handshake initiation, and receives a deauth after timing out. AP side: ral0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 105 mode 11g ral0: sending assoc_resp to xx:xx:xx:xx:xx:xx on channel 6 mode 11g ral0: sending msg 1/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx last message repeated 2 times ral0: station xx:xx:xx:xx:xx:xx deauthenticate (reason 15) ral0: sending deauth to xx:xx:xx:xx:xx:xx on channel 6 mode 11g client side: athn0: sending auth to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received auth from yy:yy:yy:yy:yy:yy rssi 47 mode 11g athn0: sending assoc_req to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received assoc_resp from yy:yy:yy:yy:yy:yy rssi 46 mode 11g athn0: associated with yy:yy:yy:yy:yy:yy (...) athn0: received deauth from yy:yy:yy:yy:yy:yy rssi 46 mode 11g Turning off WPA2 doesn't allow clients to use the network; it just fails differently, though I unfortunately don't have log captures of that at the moment. The only reliable way I've found to resurrect the AP is a cold power cycle. Is this also a known issue? Is there any more targeted tracing I could try compiling into my kernels besides RAL_DEBUG, ATHN_DEBUG, IEEE80211_DEBUG? I'm wondering if this has something to do with crypto parameters on the card not being reset in all cases, but I don't know enough about either the hardware or the 802.11 protocol to have any idea whether that makes sense.
hostapd deauthentication every 5 seconds
Hi Misc,
I have used OpenBSD 4.7 on a PCEngines ALIX to create a wireless access point
(AP).
I am running hostapd, primarily to log auth and deauth of stations from my
AP.
After 72 hours of excellent running, my station loses wireless connectivity.
/var/log/daemon reveals that:
* AP sends a deauthentication to station
* Station sends an association request
* AP responds with association response
* AP sends a deauthentication to station
* Repeat to fade
I have read the manpage for hostapd, but I don't know where to look next.
Have had a brief look at the source of hostapd - I'm no developer, but nothing
jumps out at me.
Any suggestions appreciated!
(attached hostapd.conf, /var/log/daemon, dmesg)
Cheers now,
Joe.
Output of tail /var/log/daemon
Sep 17 13:20:51 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: deauthentication, radiotap v0,
chan 8, 11g
Sep 17 13:20:56 bowser hostapd[3835]: ral0: 00:22:6b:e7:62:54
00:0e:8e:22:66:d8, bssid 00:0e:8e:22:66:d8: association request, radiotap v0,
SHORTPRE, chan 8, 11g, sig -38dBm, signal 36dB
Sep 17 13:20:56 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: association response, radiotap
v0, chan 8, 11g
Sep 17 13:20:56 bowser hostapd[3835]: ral0/vr0: sent ADD notification for
00:22:6b:e7:62:54
Sep 17 13:20:56 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: deauthentication, radiotap v0,
chan 8, 11g
Sep 17 13:21:01 bowser hostapd[3835]: ral0: 00:22:6b:e7:62:54
00:0e:8e:22:66:d8, bssid 00:0e:8e:22:66:d8: association request, radiotap v0,
SHORTPRE, chan 8, 11g, sig -36dBm, signal 34dB
Sep 17 13:21:01 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: association response, radiotap
v0, chan 8, 11g
Sep 17 13:21:01 bowser hostapd[3835]: ral0/vr0: sent ADD notification for
00:22:6b:e7:62:54
Sep 17 13:21:02 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: deauthentication, radiotap v0,
chan 8, 11g
Sep 17 13:21:06 bowser hostapd[3835]: ral0: 00:22:6b:e7:62:54
00:0e:8e:22:66:d8, bssid 00:0e:8e:22:66:d8: association request, radiotap v0,
SHORTPRE, chan 8, 11g, sig -36dBm, signal 34dB
Sep 17 13:21:06 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: association response, radiotap
v0, chan 8, 11g
Sep 17 13:21:06 bowser hostapd[3835]: ral0/vr0: sent ADD notification for
00:22:6b:e7:62:54
Sep 17 13:21:06 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: deauthentication, radiotap v0,
chan 8, 11g
Sep 17 13:21:11 bowser hostapd[3835]: ral0: 00:22:6b:e7:62:54
00:0e:8e:22:66:d8, bssid 00:0e:8e:22:66:d8: association request, radiotap v0,
SHORTPRE, chan 8, 11g, sig -36dBm, signal 34dB
Sep 17 13:21:11 bowser hostapd[3835]: ral0: 00:0e:8e:22:66:d8
00:22:6b:e7:62:54, bssid 00:0e:8e:22:66:d8: association response, radiotap
v0, chan 8, 11g
Sep 17 13:21:11 bowser hostapd[3835]: ral0/vr0: sent ADD notification for
00:22:6b:e7:62:54
/etc/hostapd.conf
---
wlan=ral0
wired=vr0
# Define the MAC addresses (BSSIDs) for your accesspoints in a table.
table myess {
00:0e:8e:22:66:d8
}
table myclients {
00:22:6b:e7:62:54
}
set hostap interface $wlan
set hostap mode radiotap
set iapp interface $wired
set iapp mode broadcast port 2313
set iapp handle subtype add notify
hostap handle type management subtype assoc request bssid myess with log
hostap handle type management subtype assoc response bssid myess with log
hostap handle type management subtype reassoc request bssid myess with log
hostap handle type management subtype reassoc response bssid myess with log
hostap handle type management subtype disassoc bssid myess with log
hostap handle type management subtype deauth bssid myess with log
# Finally log any rogue accesspoints limited to every 6 mins
hostap handle type management subtype beacon \
with log limit 360 sec
dmesg
-
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 268009472 (255MB)
avail mem = 250978304 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33
glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10,
Re: hostapd deauthentication every 5 seconds
On 2010-09-17, Joe Martel mailing-li...@joemartel.com wrote: After 72 hours of excellent running, my station loses wireless connectivity. Known problem (see PR 5958), no fix known but it may be connected with wireless stations using power-saving mode. If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap box it might temporarily fix things (when I used OpenBSD for APs I had a cronjob to do that..)
