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
>
> [EMAIL PROTECTED]: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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
