Re: ral(4) stops generating traffic
On Fri, 17 Oct 2008, Guido Tschakert wrote: Stuart Henderson schrieb: I think I probably see the same thing on RT2860, but you've got further tracking down what's happening than me (my debugging is hampered by the AP being about 2 hour's drive away..) In gmane.os.openbsd.misc, you wrote: # dmesg | grep ral ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10EEPROM rev=1, FAE=1 ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) After an unfixed amount of time, from a few minutes up to a few days, the interface simply stops respoding to probe requests: After reading this, I think I have a similar problem (But sorry, I did not dig any deeper) First the part of the dmesg: ral0 at pci0 dev 20 function 0 Ralink RT2860 rev 0x00: irq 15, address xx:xx:xx:xx:xx:xx ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) and my /etc/hostname.ral0 contains: inet x.y.z.w a.b.c.d NONE media autoselect mode 11g mediaopt hostap nwid abc wpa wpapsk 0xa0101010101010101010101010101010101010101010101010101010101010101 wpaprotos wpa1 chan 11 description WLAN WPA From time to time I could not connect any more so I had to restart ral0 which leads to my (quick'n'dirty) workaround. In my /etc/crontab is the following line: 30 4 * * * root /bin/sh /etc/netstart ral0 Up to now this worked for me and I have forgotten about the problem :-( until I read this thread... Glad to see it's not just me.. I was actually thinking this might be a bug in the net80211 code, but you guys are also getting this with a 2860. I used sendbug, the bug is kernel/5958. Hopefully damien@ or someone else will have time to try to reproduce it.. bbee
Re: ral(4) stops generating traffic
Glad to see it's not just me.. I was actually thinking this might be a
bug in the net80211 code, but you guys are also getting this with a
2860.
I have a similar ral in a 5501 and it's reliable. I don't recall needing
to touch it.
ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10, address
00:0c:f6:xx:xx:xx
ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R)
This is an old snapshot, nobody mentioned if this is a regression.
kern.version=OpenBSD 4.4-current (GENERIC) #1037: Mon Sep 1 13:47:20
MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
There are many 802.11 ifconfig incantations. It may be something (not)
in hostname.ralx.
!/sbin/ifconfig \$if mediaopt hostap mode 11g nwid ${_nwid} \
wpa wpapsk ${_wpakey} wpaciphers ccmp wpagroupcipher ccmp \
wpaprotos wpa2 wpaakms psk chan 13 up
ral0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu
1500
lladdr 00:0c:f6:xx:xx:xx
groups: wlan
media: IEEE802.11 autoselect mode 11g hostap
status: active
ieee80211: nwid OpenBSD chan 13 bssid 00:0c:f6:xx:xx:xx wpapsk
not displayed wpaprotos wpa2 wpaakms psk wpaciphers ccmp
wpagroupcipher ccmp 100dBm
OpenBSD 4.4-current (GENERIC) #1037: Mon Sep 1 13:47:20 MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD
586-class) 500 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 536440832 (511MB)
avail mem = 510271488 (486MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/70/03, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 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: 0xc8000/0xa800
cpu0 at mainbus0
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31
glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11,
address 00:00:24:ca:3d:98
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5,
address 00:00:24:ca:3d:99
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9,
address 00:00:24:ca:3d:9a
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12,
address 00:00:24:ca:3d:9b
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10, address
00:0c:f6:xx:xx:xx
ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R)
glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 0,
32-bit 3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 20 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: TOSHIBA THNCF256MMA
wd0: 1-sector PIO, LBA, 244MB, 500736 sectors
wd0(pciide0:0:0): using PIO mode 0
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15,
version 1.0, legacy support
ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15
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
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
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 e1c5 netmask ffe5 ttymask
mtrr: K6-family MTRR support (2 registers)
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
ral(4) stops generating traffic
Hi, I 'm running OpenBSD 4.4-current (RALDBG) #0: Fri Oct 10 16:56:50 CEST 2008, which is GENERIC with RAL_DEBUG, but I've seen this problem with previous kernels and without RAL_DEBUG, too. # dmesg | grep ral ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10EEPROM rev=1, FAE=1 ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) This is a pci Edimax EW-7728IN, which I believe is the same card that was donated to damien@ (?) and that led to 28xx support. After an unfixed amount of time, from a few minutes up to a few days, the interface simply stops respoding to probe requests: # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO not subtype beacon 14:17:40.761912 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 16): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -19dBm, antenna 2, signal 17dB 14:17:40.963338 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 32): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -17dBm, antenna 2, signal 15dB 14:21:03.860025 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1120): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -27dBm, antenna 1, signal 25dB 14:21:04.306901 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1520): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -23dBm, antenna 1, signal 21dB Whereas normally you'd see the probe req, probe resp, auth req, auth resp, assoc req, assoc resp, wpa dance. # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO | grep beacon | grep AP-MAC Shows that it stops sending beacon frames. It's still picking up the beacons from the 5 other wlans it can see, so rx seems to work fine. # ifconfig ral0 down ifconfig ral0 up Fixes everything, until it happens again after a seemingly random interval. The kernel doesn't log anything unusual even with RAL_DEBUG. I suppose I should sendbug, but I think lots of people have these cards so I'd like to know if anyone else is seeing this. Any ideas? Thanks and please cc, bbee
Re: ral(4) stops generating traffic
I think I probably see the same thing on RT2860, but you've got further tracking down what's happening than me (my debugging is hampered by the AP being about 2 hour's drive away..) In gmane.os.openbsd.misc, you wrote: Hi, I 'm running OpenBSD 4.4-current (RALDBG) #0: Fri Oct 10 16:56:50 CEST 2008, which is GENERIC with RAL_DEBUG, but I've seen this problem with previous kernels and without RAL_DEBUG, too. # dmesg | grep ral ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10EEPROM rev=1, FAE=1 ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) This is a pci Edimax EW-7728IN, which I believe is the same card that was donated to damien@ (?) and that led to 28xx support. After an unfixed amount of time, from a few minutes up to a few days, the interface simply stops respoding to probe requests: # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO not subtype beacon 14:17:40.761912 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 16): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -19dBm, antenna 2, signal 17dB 14:17:40.963338 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 32): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -17dBm, antenna 2, signal 15dB 14:21:03.860025 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1120): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -27dBm, antenna 1, signal 25dB 14:21:04.306901 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1520): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -23dBm, antenna 1, signal 21dB Whereas normally you'd see the probe req, probe resp, auth req, auth resp, assoc req, assoc resp, wpa dance. # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO | grep beacon | grep AP-MAC Shows that it stops sending beacon frames. It's still picking up the beacons from the 5 other wlans it can see, so rx seems to work fine. # ifconfig ral0 down ifconfig ral0 up Fixes everything, until it happens again after a seemingly random interval. The kernel doesn't log anything unusual even with RAL_DEBUG. I suppose I should sendbug, but I think lots of people have these cards so I'd like to know if anyone else is seeing this. Any ideas? Thanks and please cc, bbee
Re: ral(4) stops generating traffic
Stuart Henderson schrieb: I think I probably see the same thing on RT2860, but you've got further tracking down what's happening than me (my debugging is hampered by the AP being about 2 hour's drive away..) In gmane.os.openbsd.misc, you wrote: Hi, I 'm running OpenBSD 4.4-current (RALDBG) #0: Fri Oct 10 16:56:50 CEST 2008, which is GENERIC with RAL_DEBUG, but I've seen this problem with previous kernels and without RAL_DEBUG, too. # dmesg | grep ral ral0 at pci0 dev 14 function 0 Ralink RT2860 rev 0x00: irq 10EEPROM rev=1, FAE=1 ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) This is a pci Edimax EW-7728IN, which I believe is the same card that was donated to damien@ (?) and that led to 28xx support. After an unfixed amount of time, from a few minutes up to a few days, the interface simply stops respoding to probe requests: # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO not subtype beacon 14:17:40.761912 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 16): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -19dBm, antenna 2, signal 17dB 14:17:40.963338 CLI1-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 32): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -17dBm, antenna 2, signal 15dB 14:21:03.860025 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1120): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -27dBm, antenna 1, signal 25dB 14:21:04.306901 CLI2-MAC ff:ff:ff:ff:ff:ff, bssid ff:ff:ff:ff:ff:ff (seq 1520): 802.11: probe request, radiotap v0, 1Mbit/s, chan 6, 11g, sig -23dBm, antenna 1, signal 21dB Whereas normally you'd see the probe req, probe resp, auth req, auth resp, assoc req, assoc resp, wpa dance. # tcpdump -nvvvs 1000 -i ral0 -y IEEE802_11_RADIO | grep beacon | grep AP-MAC Shows that it stops sending beacon frames. It's still picking up the beacons from the 5 other wlans it can see, so rx seems to work fine. # ifconfig ral0 down ifconfig ral0 up Fixes everything, until it happens again after a seemingly random interval. The kernel doesn't log anything unusual even with RAL_DEBUG. I suppose I should sendbug, but I think lots of people have these cards so I'd like to know if anyone else is seeing this. Any ideas? Thanks and please cc, bbee After reading this, I think I have a similar problem (But sorry, I did not dig any deeper) First the part of the dmesg: ral0 at pci0 dev 20 function 0 Ralink RT2860 rev 0x00: irq 15, address xx:xx:xx:xx:xx:xx ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (2T3R) and my /etc/hostname.ral0 contains: inet x.y.z.w a.b.c.d NONE media autoselect mode 11g mediaopt hostap nwid abc wpa wpapsk 0xa0101010101010101010101010101010101010101010101010101010101010101 wpaprotos wpa1 chan 11 description WLAN WPA From time to time I could not connect any more so I had to restart ral0 which leads to my (quick'n'dirty) workaround. In my /etc/crontab is the following line: 30 4 * * * root /bin/sh /etc/netstart ral0 Up to now this worked for me and I have forgotten about the problem :-( until I read this thread... guido
