Bridging atheros/ethernet seems incredibly slow

Sam Leffler sam at errno.com
Thu Dec 15 11:21:55 PST 2005


Nate Nielsen wrote:
> Has anyone else seen a problem where bridging an Atheros wireless with
> an ethernet interface has painfully slow throughput?
> 
> I have two boxes sitting next to each other both running FreeBSD 6.0.
> 
>    BOX 1          BOX 2
> ---- A +++++++++++ B/C -----
> 
> Two Atheros (5213) 802.11a cards (A and B above) are connected to each
> other using adhoc mode. I can get roughly 10+ Mbps of throughput between
> A and B (measured using iperf, flood pings, simple tcp transfer).
> 
> One box has it's wireless NIC (ie: B above) bridged with an ethernet
> interface (ie: C above).  Throughput to the ethernet nic is nice and
> high (20+ Mbps).
> 
> However when sending traffic through the bridge, the transfer rate drops
> below 500Kbps.
> 
> Non issues:
> - The CPU's on neither box are being taxed.
> - I've tried both bridge(4) and if_bridge(4). Same results.
> - Locking down the wireless speed doesn't help (just a wild guess).

adhoc mode is not intended for bridging; I'm a bit surprised it works at 
all (I've never tried it).  There are special hacks in 
ieee80211_deliver_data specific to hostap.  Andrew Atrens recently hit a 
similar problem in a similar config and diagnosed it as promiscuous mode 
causing retransmits over the wireless network (the bridge forces the 
interface into promiscuous mode).

> 
> Interesting things:
> 
> Running 'ifconfig ath0 list sta' on BOX 1 shows all sorts of mac
> addresses on the BOX 2 side of the network. The first is the wireless
> adhoc peer. Maybe that's to be expected:
> 
> 
>>ADDR               AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS ERP
>>00:01:b4:02:0d:e7    0   52   6M   43    0    258  33072 I      0
>>00:30:48:76:55:4a    0   52   6M   43   15      7  32016        0
>>00:11:43:d1:07:7d    0   52   6M   43   15      0  32528        0
>>00:48:54:70:10:09    0   52   6M   44   45      0  26368        0
>>00:0e:a6:91:60:c1    0   52   6M   44  105      0  16576        0
>>00:a0:cc:5e:b0:b6    0   52   6M   43   15      0  31344        0
>>00:20:ed:60:58:ac    0   52   6M   43  180      0   5600        0
>>00:0b:db:a3:68:91    0   52   6M   42  150      0  10688        0
>>00:0d:61:37:3e:36    0   52   6M   43  120      0  14896        0
>>00:02:e3:08:8b:d1    0   52   6M   41   45      0  28112        0

sta/neighbor entries are created on demand due to traffic.  This means 
each frame coming through the bridge and out the wireless interface will 
cause an entry to be created.

> 
> 
> Doing a flood ping from BOX A to a machine bridged across the link is
> not lossy, instead the send rate is limited. That is, the ping packets
> are sent slowly.
> 
> athstats on BOX 2 shows:
> 
> 
>>13 tx management frames
>>7 tx frames discarded prior to association
>>544 tx failed 'cuz too many retries
>>6014 long on-chip tx retries
>>876 tx frames with no ack marked
>>1952 rx failed 'cuz frame too short
>>5129 rx failed 'cuz of PHY err
>>    1524 OFDM timing
>>    3605 OFDM illegal rate
>>1 beacons transmitted
>>91 periodic calibrations
>>rssi of last ack: 36
>>avg recv rssi: 38
>>1 switched default/rx antenna
>>Antenna profile:
>>[1] tx     1192 rx    18513
>>[2] tx       68 rx        1
> 
> 
> Anyone have any ideas on where I should look for the problem?

These are not the stats you want :)  Look at the 802.11 layer.  FWIW I 
recently reorgnized the tools and renamed them so the program you want 
is now called wlanstats and is found in tools/tools/net80211.

	Sam


More information about the freebsd-net mailing list