ath0 timeout problem - again

Sat Dec 30 14:27:05 PST 2006

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

> > {
> > 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

> > 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 at 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

-- 

João

A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br