Date: Sat, 30 Dec 2006 19:26:57 -0200 From: JoaoBR <joao@matik.com.br> To: Sam Leffler <sam@errno.com> Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again Message-ID: <200612301926.57736.joao@matik.com.br> In-Reply-To: <4596CA1A.9040906@errno.com> References: <200612282002.11562.joao@matik.com.br> <4596CA1A.9040906@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 o=
f=20
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=20
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=
=20
servers where wingate and similar softwares are running, when we cut them o=
ut=20
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=20
access point
in order to check better what is happening we set up some freebsd clients=20
releng_6 as well
when this oversized packages are appearing first we see ath up/down events =
on=20
the client, on windows machines the signal drops and comes back as well, so=
I=20
guess it is the same
if this oversize packages "are persistence" after a while the AP goes down =
and=20
does not come back
we do see other 11b/g APs out there and measured the spectrum but there is =
no=20
meaningfull interference, also, in this specific case, here we do have=20
channel 1,6 and 11 and all Aps are 2km away from each other.=20
>
> > 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 w=
ith=20
pigtail, coax and 18dBi Omni or 90 degree panel
> > ifconfig
> >
> > ath0: flags=3D8943<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 bmi=
ss
> > 7 -pureg protmode CTS -wme burst ssid HIDE -apbridge dtimperiod 1 bintv=
al
> > 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=
=20
higher processors, 256Mb or more RAM
CPU: AMD Athlon(tm) 64 Processor 3500+ (2199.77-MHz 686-class CPU)
Origin =3D "AuthenticAMD" Id =3D 0x20ff2 Stepping =3D 2
=20
=46eatures=3D0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE=
,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FX
SR,SSE,SSE2>
Features2=3D0x1<SSE3>
AMD Features=3D0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow>
AMD Features2=3D0x1<LAHF>
real memory =3D 401539072 (382 MB)
avail memory =3D 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=3D0x020000 card=3D0x3a131186 chip=3D0x0013168c rev=3D=
0x01=20
hdr=3D0x00
vendor =3D 'Atheros Communications Inc.'
device =3D 'AR5212, AR5213 802.11a/b/g Wireless Adapter'
class =3D network
subclass =3D ethernet
thank's
=2D-=20
Jo=E3o
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612301926.57736.joao>