Re: ath0 timeout problem - again

JoaoBR wrote:
On Saturday 30 December 2006 18:20, Sam Leffler wrote:

thank you for answering, lots of good points and I will try to answer any of
them


I really do not know what this event means (ether type 5e4), for my
understandings it is vague in the source, so I am lost here
Seems pretty clear: it's the type field extracted from the ethernet
header of the oversized packet. A quick check of sys/net/ethernet.h
shows no such ETHERTYPE defined. So something in your network is
transmitting packets that either being rx'd incorrectly or, more likely,
corrupted in transit.


good so far, point here is that we can not limit that someone tx this kind of
packets but should find a way that this traffic do not DoS the AP.

ipfw accepts 0x5e4 but at the end it does not get this packages
changing mtu on any interface does not change a thing


when we track the oversized packages they we found they are coming from nat
servers where wingate and similar softwares are running, when we cut them out
the mentioned traffic stopps and the AP does not interrupt service anymore

So the packet is real and it's being dropped at the 802.3 layer as it
should. If the printf is the problem remove it or rate limit it. I
think it should be rate-limited or just stuck under a debug flag but
I'll leave that to someone else. Alternatively we can enforce the mtu
in the ath driver and drop it there.



{
I get continously:

kernel: ath0: link state changed to DOWN
kernel: ath0: link state changed to UP

when WL client but it recovers when the AP comes back to normal
so wl-cli mode is not the issue
}
Sorry this is hard to understand. You are saying that when you see
packets discarded on the ap the client stations lose their association
to the ap? You've said nothing about your environment but I'd guess
you've got some heavy interference like a microwave oven operating.



we use Freebsd releng_6 running Dlink 520 or 530 cards (ATH) in hostap mode as
access point

in order to check better what is happening we set up some freebsd clients
releng_6 as well

when this oversized packages are appearing first we see ath up/down events on
the client, on windows machines the signal drops and comes back as well, so I
guess it is the same

if this oversize packages "are persistence" after a while the AP goes down and
does not come back

we do see other 11b/g APs out there and measured the spectrum but there is no
meaningfull interference, also, in this specific case, here we do have
channel 1,6 and 11 and all Aps are 2km away from each other.





ath stats:

70777 data frames received
71551 data frames transmit
420 tx frames with an alternate rate
10821 long on-chip tx retries
260 tx failed 'cuz too many retries
11M current transmit rate
10489 tx management frames
1 tx frames discarded prior to association
786 tx frames with no ack marked
80516 tx frames with short preamble
54395 rx failed 'cuz of bad CRC
146438 rx failed 'cuz of PHY err
145013 CCK timing
1425 CCK restart
5295 beacons transmitted
19 periodic calibrations
42 rssi of last ack
31 avg recv rssi
-98 rx noise floor
572 cabq frames transmitted
11 cabq xmit overflowed beacon interval
This should not happen. You have stations in power save mode in your
bss and the transmission of queued multicast frames overflowed the
interval following the beacon frame. This should be handled (I
explicitly tested it) but you might want to observe if this occurs when
you have problems.


this ath stats are from exactly the moment when the card in apmode stopped


1525 switched default/rx antenna
Antenna profile:
[1] tx 41285 rx 4
This makes no sense; you rx'd 4 frames total? That's inconsistent with
the "data frames received" counter and makes me question whether these
numbers are meaningful.


same answer as above, I like to remember we are in an outdoor environment with
pigtail, coax and 18dBi Omni or 90 degree panel

Not sure how this statement bears any relationship to my question.





ifconfig

ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ether 00:13:46:8b:f1:86
media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b <hostap>
status: associated
ssid omegasul channel 1 (2412) bssid 00:13:46:8b:f1:86
authmode OPEN privacy ON deftxkey 1
wepkey 1:40-bit
wepkey 2:40-bit
wepkey 3:40-bit
wepkey 4:40-bit powersavemode OFF powersavesleep 100 txpowmax 36
txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 bmiss
7 -pureg protmode CTS -wme burst ssid HIDE -apbridge dtimperiod 1 bintval
100
Unfortunately you've not provide critical info like the mac+phy of the
card and the platform (E.g. is this a soekris box). As I said I can try
to _HELP_ you but I cannot fix your problem. You need to diagnose what
is happening.

great, this are normally MicroATX MBs Asus or Epox, with Athlon 64 3000 or
higher processors, 256Mb or more RAM

CPU: AMD Athlon(tm) 64 Processor 3500+ (2199.77-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x20ff2 Stepping = 2

Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FX
SR,SSE,SSE2>
Features2=0x1<SSE3>
AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow>
AMD Features2=0x1<LAHF>
real memory = 401539072 (382 MB)
avail memory = 383447040 (365 MB)
ioapic0 <Version 2.1> irqs 0-23 on motherboard
wlan: mac acl policy registered
ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

ath0: <Atheros 5212> mem 0xfddd0000-0xfdddffff irq 20 at device 0.0 on pci2
ath0: Ethernet address: 00:17:9a:0a:7a:5b
ath0: mac 7.9 phy 4.5 radio 5.6
ath0: using 150 rx buffers
ath0: using 300 tx buffers

ath0@pci2:0:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01
hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter'
class = network
subclass = ethernet


thank's


So I have no idea what your problem is. If you can create a way for me
to reproduce your problem I can look at it. Otherwise you'll have to
dig for yourself.

Sam
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • ath0 timeout problem - again
    ... CPU, memory but is related in a certain way to the ath drv - same machine, ... 70777 data frames received ... 11M current transmit rate ... wepkey 1:40-bit ...
    (freebsd-stable)
  • Re: Call for bfe(4) testers.
    ... I recompiled a fresh RELENG_7 kernel with the files above, ... no toe capability of 0xc421d800 ... Transmit good frames: 1884 ...
    (freebsd-current)
  • Re: Call for bfe(4) testers.
    ... I recompiled a fresh RELENG_7 kernel with the files above, ... no toe capability of 0xc421d800 ... Transmit good frames: 1884 ...
    (freebsd-current)
  • Re: ath0 timeout problem - again
    ... packets discarded on the ap the client stations lose their association ... 70777 data frames received ... 11M current transmit rate ... wepkey 1:40-bit ...
    (freebsd-stable)
  • Re: Thread deadlock misery
    ... The Sleep() call in the StatCalc thread is ... Below is some actual code from my transmit thread. ... about 300 frames, this thread halts. ... if(WSASendTo(DUTSocket, ...
    (microsoft.public.vc.language)