Re: ath0 timeout problem - again

JoaoBR wrote:
I need some help here, this is not a single case, I get this on a several
machines, this is releng_6 , recent, but old problem getting ugly


first I get this kind of events in messages, independent if it is client mode
or hostap or adhoc

Dec 28 16:50:53 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
flags 3 len 1522 > max 1514)
Dec 28 16:51:01 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
flags 3 len 1522 > max 1514)
Dec 28 16:58:16 ap1-cds kernel: ath0: device timeout
... timeout event repeats

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.


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



but when the machine is running hostap the link state up/down events do not
come up but transmission is interrupted, or better, goes slow and stops
then - and stops forever until cold reboot, no chance to get this card back,
not even unload ath and reload the driver (that was a try but I use it
compiled into the kernel)
this is not related to any WEP settings or any rate, this problem is coming up
with either rate-sample or rate_onoe


this is not related to the "tx stopped" problem (OACTIVE) and it is not
related to any [TX|RX]BUF value (whatever it is set to)

this problem is not a single case and not hardware related, here I mean MB,
CPU, memory but is related in a certain way to the ath drv - same machine,
but wi0 (prism card) and it does NOT happen this way


I am with this problem since 6.0 and would be glad if somebody could convince
Mr. Sam L. to attend this since it is a serious issue - any FreeBSD releng_6
has this problem but releng_5 does not

Well "Mr. Sam L" has other things to do that are more important to him.
If you want help I can try to provide it but this is not exactly a
problem one can diagnose from afar. I suggest you sniff traffic from a
separate station and try to identify what is going on in the network
when you this event occur. It would also help to do the obvious things
like swap ath cards. You've also said nothing about your environment
such as the mac+phy revs for the card and the computer this is operating in.


depending on the amount of traffic I get this any hour ( when 2-3Mbit/s or
more) or several times a day (when 1-2Mbit/s)

it get worse when I have more then one ath card installed

Sounds like you've got radio/antenna issues that manifest themselves as
noise that drives the radio's into silence. Diagnosing something like
that may requires tools like a spectrum analyzer.



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.

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.


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.

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

  • Re: ath driver transmits frames only after a low watermark is filled
    ... TCP connections that consist of small short bursts of one-way (transmission) traffic often stall until traffic is received over another TCP connection. ... This makes me think there is some kind of low watermark functionality in the hardware/driver that doesn't send frames until a certain number of them have been queued for transmission, or until a frame has been received. ... Also, I guess this is the reason that the ath module caused the system to freeze at shutdown or when the module is unloaded, unless I do an "ifconfig ath0 down" before unloading - the unloading code is probably waiting for all queued frames to be transmitted, but that never happens. ...
    (freebsd-stable)
  • Re: TcpClient buffer size limit?
    ... > mega byte frames. ... > So I'm looking for the optimum TCP connection and configuration to achieve ... > transmission faster. ... > interface type TCP registry settings and an application buffer size of 64K ...
    (microsoft.public.dotnet.languages.csharp)
  • [PATCH 02/22] [PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards
    ... Fixes Rhine I cards disclosing fragments of previously transmitted frames ... Before transmission, any socket buffer shorter than the ethernet ...
    (Linux-Kernel)
  • Re: ath driver transmits frames only after a low watermark is filled
    ... How is data transmission related to power management? ... TCP connections that consist of small short bursts of one-way ... unloading - the unloading code is probably waiting for all queued frames ...
    (freebsd-stable)
  • Re: ath0: ath_reset: unable to reset hardware; hal status 3
    ... I am having the same type of trouble with a Dynex card. ... Device timeout' on the main console screen. ... The card does not appear to reset itself. ... 84874 data frames received ...
    (freebsd-stable)