From owner-freebsd-stable@FreeBSD.ORG Sat Dec 30 22:27:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A222616A5E3 for ; Sat, 30 Dec 2006 22:27:05 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFEF13C448 for ; Sat, 30 Dec 2006 22:27:04 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kBUMPYob014901; Sat, 30 Dec 2006 19:25:35 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Sam Leffler Date: Sat, 30 Dec 2006 19:26:57 -0200 User-Agent: KMail/1.9.3 References: <200612282002.11562.joao@matik.com.br> <4596CA1A.9040906@errno.com> In-Reply-To: <4596CA1A.9040906@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612301926.57736.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: ath0 timeout problem - again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2006 22:27:05 -0000 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 mtu = 1500 > > ether 00:13:46:8b:f1:86 > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > > 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 Features2=3D0x1 AMD Features=3D0xe2500800 AMD Features2=3D0x1 real memory =3D 401539072 (382 MB) avail memory =3D 383447040 (365 MB) ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: 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