Date: Mon, 10 Jun 2002 19:12:05 -0400 From: "Yeasah Pell" <yeasah@apocalypse.org> To: <stable@FreeBSD.ORG> Subject: if_an woes Message-ID: <002401c210d4$3d0eda90$0200a8c0@gauss>
next in thread | raw e-mail | index | archive | help
I recently switched from RELENG_4_5 to the "unofficial" RELENG_4_6, and
since then I've started seeing rather serious stalls and lost connections on
my wireless interface (if_an). This is an aironet wireless PC Card in a PCI
adapter, and is labelled as a DELL PC4800B. The Intel dual-port wired NIC on
the same machine is unaffected (fxp0, fxp1). It seems to take some amount of
uptime before the wireless interface starts to misbehave noticably.
So far, I've tried:
1) Turing off RFC1323 extensions.
2) Making if_an a kernel module, so I can reload it dynamically when it
starts to really fail (see syslog messages below) -- [BTW, I noticed that if
I make miibus and fxp into modules, I panic on boot, and if I make fxp a
module and miibus built-in, fxp tries to load miibus as a module, fails, and
I get no fxp.]
3) Tried if_an.ko from my kernel.GENERIC (from FreeBSD 4.2, crazy, amazed it
worked...), and it still seemed to exhibit the same problem, or at least the
4.2 <-> 4.6 interface issues masqueraded as the same problem :-)
4) Tried disabling those services that require user kernel modules (e.g.
drm-kmod, vmware)
5) Tried rebuilding a 4.5 release kernel with the same config as the 4.6,
which works fine -- no delays, no dropped connections.
Now that I have it built as a kernel module, I can bounce the driver with
kldunload and kldload and the problem disappears for a while. Merely taking
the interface down and up is not sufficient -- the driver must be reloaded.
I've created an interface-bouncing script, but that's getting really old
fast. :-)
[BTW, I've noticed that the dhcpd I have running on both fxp1 and an0 goes
berserk eating CPU once an0 goes away, and has to be restarted. I eventually
get this in the log (after I restart dhcpd): "dhcpd: receive_packet failed
on an0: Device not configured". Doesn't stop doing this, even when an0 comes
back. Of course, this is with the isc-dhcp3-3.0.1.r9 from ports, so forget I
said anything]
Once, I actually got the wireless NIC to fail outright, and the following
messages appeared in /var/log/messages:
Jun 8 19:10:00 turing /kernel: an0: seek to record failed
Jun 8 19:10:10 turing last message repeated 15 times
Jun 8 19:10:10 turing /kernel: an0: xmit failed
Jun 8 19:10:12 turing /kernel: an0: seek to record failed
Jun 8 19:10:12 turing /kernel: an0: seek to record failed
Jun 8 19:10:12 turing /kernel: an0: xmit failed
Jun 8 19:10:12 turing /kernel: an0: seek to record failed
Jun 8 19:10:12 turing /kernel: an0: seek to record failed
Jun 8 19:10:14 turing /kernel: an0: xmit failed
Jun 8 19:10:14 turing /kernel: an0: seek to record failed
Jun 8 19:10:17 turing last message repeated 5 times
Jun 8 19:10:18 turing /kernel: an0: xmit failed
Jun 8 19:10:18 turing /kernel: an0: seek to record failed
Jun 8 19:10:32 turing last message repeated 9 times
Jun 8 19:10:32 turing /kernel: an0: device timeout
Jun 8 19:10:32 turing /kernel: an0: reset failed
Jun 8 19:10:32 turing /kernel: an0: failed to allocate 1586 bytes on NIC
Jun 8 19:10:32 turing /kernel: an0: reset failed
Jun 8 19:10:32 turing /kernel: an0: failed to allocate 1586 bytes on NIC
Jun 8 19:10:32 turing /kernel: an0: tx buffer allocation failed
Unfortuately, I've not seen these messages since, just random network
failures. That was the first time I saw the problem, though, and I assume if
I let the system continue to run uncorrected after I notice problems, I'll
eventually get these messages again.
I should mention that I have been compiling the 4.6 kernel with the ATAPICAM
patches, although I can't imagine there being a connection to this problem.
(Boy, I sure wish some form of ATAPI CAM linkage was in the official kernel
source, even if it were disabled by default...)
Any clues are greatly appreciated. If I can provide additional information,
just let me know and I'll do my best to collect it. I plan to do some
tcpdumping soon and I'll try to catch some stalls or dropped connections in
the act and see what is going on at the packet level.
Here's some additional information about my configuration ----------
My rc.local contains the following setup for the interface:
ancontrol -c 3
ancontrol -n SCHWIDE
ancontrol -o 0
Here are some dumps of anconfig info when the NIC is dropping/stalling
packets:
bash-2.05a$ ancontrol -S
MAC address: [ 00:40:96:30:ad:47 ]
Operating mode: [ configured MAC ON RX ON synced ]
Error code: [ 00 ]
Signal quality: [ 04 ]
Signal strength: [ 82% ]
Max Noise: [ 0% ]
Current TX rate: [ 11 ]
Current SSID: [ SCHWIDE ]
Current AP name: [ ]
Current BSSID: [ 02:90:aa:a4:44:3e ]
Beacon period: [ 100 ]
DTIM period: [ 1 ]
ATIM duration: [ 0 ]
HOP period: [ 200 ]
Channel set: [ 0 ]
Current channel: [ 3 ]
Hops to backbone: [ 0 ]
Total AP load: [ 0 ]
Our generated load: [ 0 ]
Accumulated ARL: [ 0 ]
bash-2.05a$ ancontrol -I
OUI: [ 00:40:96 ]
Product number: [ 7 ]
Manufacturer name: [ Aironet Wireless Communications ]
Produce name: [ PC4800B ]
Firmware version: [ 3 ]
OEM MAC address: [ 00:40:96:30:ad:47 ]
Aironet MAC address: [ 00:40:96:30:ad:47 ]
Radio type: [ 802.11 DS ]
Regulatory domain: [ 0 ]
Assigned CallID: [ ff:ff:ff:ff:ff:ff ]
Supported speeds: [ 1.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ]
RX Diversity: [ antenna 1 and 2 ]
TX Diversity: [ antenna 1 and 2 ]
Supported power levels: [ 5 15 30 0 0 0 0 0 ]
Hardware revision: [ 00:20 ]
Software revision: [ 00:00 ]
Software subrevision: [ 00:00 ]
Interface revision: [ 00:00 ]
Bootblock revision: [ 01:32 ]
bash-2.05a$ ancontrol -T
RX overruns: [ 0 ]
RX PLCP CSUM errors: [ 2499 ]
RX PLCP format errors: [ 93 ]
RX PLCP length errors: [ 0 ]
RX MAC CRC errors: [ 700 ]
RX MAC CRC OK: [ 191715 ]
RX WEP errors: [ 0 ]
RX WEP OK: [ 0 ]
Long retries: [ 727 ]
Short retries: [ 421 ]
Retries exhausted: [ 53 ]
Bad ACK: [ 727 ]
Bad CTS: [ 421 ]
RX good ACKs: [ 21345 ]
RX good CTSs: [ 103 ]
TX good ACKs: [ 24806 ]
TX good RTSs: [ 524 ]
TX good CTSs: [ 2 ]
LMAC multicasts transmitted: [ 1 ]
LMAC broadcasts transmitted: [ 1025133 ]
LMAC unicast frags transmitted: [ 21398 ]
LMAC unicasts transmitted: [ 21398 ]
Beacons transmitted: [ 1024656 ]
Beacons received: [ 133287 ]
Single transmit collisions: [ 0 ]
Multiple transmit collisions: [ 0 ]
Transmits without deferrals: [ 0 ]
Transmits deferred due to protocol: [ 4 ]
Transmits deferred due to energy detect: [ 1148663 ]
RX duplicate frames/frags: [ 1 ]
RX partial frames: [ 0 ]
TX max lifetime exceeded: [ 0 ]
RX max lifetime exceeded: [ 0 ]
Sync lost due to too many missed beacons: [ 0 ]
Sync lost due to ARL exceeded: [ 0 ]
Sync lost due to deauthentication: [ 0 ]
Sync lost due to disassociation: [ 0 ]
Sync lost due to excess change in TSF timing: [ 18 ]
Host transmitted multicasts: [ 3 ]
Host transmitted broadcasts: [ 13 ]
Host transmitted unicasts: [ 19507 ]
Host transmission failures: [ 13 ]
Host received multicasts: [ 24 ]
Host received broadcasts: [ 4614 ]
Host received unicasts: [ 12362 ]
Host receive discards: [ 0 ]
HMAC transmitted multicasts: [ 0 ]
HMAC transmitted broadcasts: [ 467 ]
HMAC transmitted unicasts: [ 1891 ]
HMAC transmissions failed: [ 45 ]
HMAC received multicasts: [ 0 ]
HMAC received broadcasts: [ 138124 ]
HMAC received unicasts: [ 21 ]
HMAC receive discards: [ 2581 ]
HMAC transmits accepted: [ 138145 ]
SSID mismatches: [ 0 ]
Access point mismatches: [ 0 ]
Speed mismatches: [ 0 ]
Authentication rejects: [ 0 ]
Authentication timeouts: [ 0 ]
Association rejects: [ 0 ]
Association timeouts: [ 0 ]
Management frames received: [ 0 ]
Management frames transmitted: [ 0 ]
Refresh frames received: [ 0 ]
Refresh frames transmitted: [ 0 ]
Poll frames received: [ 0 ]
Poll frames transmitted: [ 0 ]
Host requested sync losses: [ 0 ]
Host transmitted bytes: [ 16577381 ]
Host received bytes: [ 2358348 ]
Uptime in microseconds: [ -684603459 ]
Uptime in seconds: [ 111043 ]
Sync lost due to better AP: [ 0 ]
bash-2.05a$ ancontrol -C
Operating mode: [ ad-hoc ]
Receive mode: [ broadcast/multicast/unicast ]
Fragment threshold: [ 2312 ]
RTS threshold: [ 2312 ]
MAC address: [ 00:40:96:30:ad:47 ]
Supported rates: [ 65.0Mbps 2.0Mbps 5.5Mbps
11.0Mbps ]
Short retry limit: [ 16 ]
Long retry limit: [ 16 ]
TX MSDU lifetime: [ 5000 ]
RX MSDU lifetime: [ 10000 ]
Stationary: [ Off ]
Ordering: [ Off ]
Device type: [ PC4800 ]
Scanning mode: [ active ]
Probe delay: [ 3 ]
Probe energy timeout: [ 3 ]
Probe response timeout: [ 20 ]
Beacon listen timeout: [ 40 ]
IBSS join network timeout: [ 10000 ]
Authentication timeout: [ 2000 ]
WEP enabled: [ no ]
Authentication type: [ open ]
Association timeout: [ 2000 ]
Specified AP association timeout: [ 10000 ]
Offline scan interval: [ 0 ]
Offline scan duration: [ 0 ]
Link loss delay: [ 0 ]
Max beacon loss time: [ 500 ]
Refresh interval: [ 10000 ]
Power save mode: [ none ]
Sleep through DTIMs: [ Off ]
Power save listen interval: [ 200 ]
Power save fast listen interval: [ 100 ]
Power save listen decay: [ 2 ]
Power save fast listen decay: [ 200 ]
AP/ad-hoc Beacon period: [ 100 ]
AP/ad-hoc ATIM duration: [ 0 ]
AP/ad-hoc current channel: [ 3 ]
AP/ad-hoc DTIM period: [ 1 ]
Radio type: [ 802.11 DS ]
RX Diversity: [ antenna 1 only ]
TX Diversity: [ antenna 1 only ]
Transmit power level: [ 30 ]
RSS threshold: [ 0 ]
Node name: [ FreeBSD ]
ARL threshold: [ 65535 ]
ARL decay: [ 65535 ]
ARL delay: [ 65535 ]
Configuration: [ Home Configuration ]
WEP Key status:
Key 0 is set 40 bits
Key 1 is set 40 bits
Key 4 is set 40 bits
The active transmit key is 4
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002401c210d4$3d0eda90$0200a8c0>