The content of this topic has been archived on 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
I'm using sta mode on a wrt54g v2.2. Data transfer is working ok but a bit slower than I expected.
I did an ifconfig and noticed that the number of frame errors on eth1 was high - ranging from 6% to 16% of all packets transferred! This could trigger numerous TCP retransmissions - explaining the lower than expected transfer rates.
Are these sort of numbers normal for wireless? If not what other causes could there be? Any suggestions would be much appreciated.
did you brake the bridge ?
few errors are normal
I'm using sta mode, speed is 55 MBs
wj
Does this "frame" indicate the number of frame errors? This is partial dump from ifconfig for eth1. If so, I've got quite a few myself!
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:225675 errors:0 dropped:0 overruns:0 frame:1802525
TX packets:100556 errors:5 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:219966045 (209.7 MiB) TX bytes:11632211 (11.0 MiB)
don't worry about 5 packets, and is this your WLAN interface ?
and watch for more errors, signal noise etc, you can use netstumbler for that.
wj
Here's a full dump sans IP addresses and MACs:
root@chriberg-longrange2:/# ifconfig
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:128796 errors:0 dropped:0 overruns:0 frame:0
TX packets:174636 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16952501 (16.1 MiB) TX bytes:192021657 (183.1 MiB)
Interrupt:5 Base address:0x2000
eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:399800 errors:0 dropped:0 overruns:0 frame:8237789
TX packets:125504 errors:11 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:268830939 (256.3 MiB) TX bytes:16387948 (15.6 MiB)
Interrupt:4 Base address:0x1000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76 (76.0 B) TX bytes:76 (76.0 B)
vlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.16.1 Bcast:192.168.16.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:128796 errors:0 dropped:0 overruns:0 frame:0
TX packets:174636 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14634173 (13.9 MiB) TX bytes:192021657 (183.1 MiB)
would like to confirm this same problem in our installation. A network with a central WAP54G AP (original Linksys software) and 5 pcs WRT54G:
3 pcs v2 OpenWRT late 2004 snapshot and 2 pcs v2.2 OpenWRT experimental May 25 2005. One of the V2.2 connects to internet via an ADSL modem.
All boxes show no errors on any of their interfaces but the eth1 (wifi). On all boxes the 'ifconfig eth1' shows a very high number of frame errors , in the order of magnitude of total traffic and sometimes by far exceeding that. All WRTs have bridging disabled and act as routers.
Anybody has a clue what might be causing this ??
I can see e.g. during a Dropbear session that a simple keyboard press initiates a series of wireless communications, as if several retransmissions would be required.
All radios have at least 25 dB signal to noise in their radio link.
Example of the 'ifconfig eth1' from the box that connects to ADSL via vlan1:
eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx:xx:xx
inet addr: a.b.c.d Bcast: e.f.g.h Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:51386 errors:0 dropped:0 overruns:0 frame:47355
TX packets:69241 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3462681 (3.3 MiB) TX bytes:95909657 (91.4 MiB)
Interrupt:4 Base address:0x1000
Saw somewhere on the net in cabled situations that frame errors are related to the CRC check on packets not giving the right result and then retransmission requests taking place. Also saw some hints on full-duplex vs. half-duplex conflicts. Cabled ethernet traffic (vlanx) in this case is full-duplex, while the radio links (eth1) are half-duplex. Does OpenWRT take care of that properly??? Any tools around to test this ??
Latest results: the setting of txpwr seems to be related to these frame errors. Going back from the 250 realm to around 75, either through 'wl txpwr xx' or 'wlc eth1 txpwr xx', seems to have a positive effect on frame errors. They do not disappear but reduce in number. The wireless driver then, if set to automatic rate choice, starts to increase speed. So there may be a RF problem involved with distortion on the physical transmission level. Anybody reading this with knowledge of the Broadcom radio chip in V2 and V2.2 and how realistic these higher power settings are ?
rgds, doddel
(Last edited by doddel on 15 Jun 2005, 12:53)
I have the exact same problem: I get 100% frame errors on the wireless interface.
My setting is: WRT54GS with openWRT (obsolete version) running in client mode.
It was running fine for 6 months, and suddenly I got 100% frame error on the wireless interface. I did try to reduce the transmit power to around 71 mW but it didn't do anything for me.
I last tested the device in AP mode: clients could see the wireless SSID and associate. However, not one packet was getting through.
Alystan
Results of continued testing:
set-up:
WAP54g access point with latest Linksys software
WRT54g v2 client in infra mode at 8 km distance with parabolic antennas and amplifiers. S/N ratio > 30 dB. Gmode only (2).
software: HEAD (7-8-2005) compilation with modified wificonf.c to be able to experiment with settings.
problem: excessive frame errors and limitation of effective data rate to ~ 700 kbps even though indicated bit rate ('wl rate') is much higher.
Observations:
frameburst and gmode protection have no significant influence on bit rate.
the client automatically reduces its bitrate to 2 Mbps for least bad result.
Further experiments:
Have used same client WRT54Gv2 but now with WRT54Gv2.2 access point with same HEAD based firmware. Just 1 meter apart and no amplifiers or special antennas.
Observation: when doing file transfers, using openssh sftp server, from client to AP the data rate saturates at some 1.5 Mbps, even though gmode bitrate is 54 Mbps on both sides and does now not reduce. S/N ratio > 50 dB. Used 6 MB file to be sent back and forth. Once per ~10 transfers the AP box hangs up and resets itself.
'Ifconfig eth1' shows very high frame error numbers on both sides.
I think that there is a problem around these frame errors. Perhaps they don't really exist but are just the result of some software interface error but they do upset the box as with plenty of data to be sent and received it cannot cope with a massive amount of retransmissions and associated bookkeeping and intermediate storage of data.
Anybody reading this that is familiar with frame error checking in the radio link and its interface to Busybox ?
Another strange thing is that after booting the box and without yet having had any contact to another box 'ifconfig eth1' shows 0 data transfer but already does show a number of frame errors, as if it is freely generating them by itself.
(Last edited by doddel on 15 Aug 2005, 10:39)
I'm pretty sure this is due to packet collisions from other stations around you. My theory is it causes CRC errors and all kinds of havoc to packets so the interface sees them as Frame errors.
If you could isolate the AP and client in a place that has no other outside stations, possibly remove antennas to be sure and then do a test to see if the Frame errors are still there. Put on the antennas and see if it starts going up at that moment.
What bothers me about seeing this is that the 802.11 layer should be preventing this. The idea is that the ethernet side (which you are looking at with ifconfig eth1) should be just like having a straight wire between AP and client, the 802.11 layer should hide any packet failures, dropped bits etc...
At least that's how I understand it. Anyone else have a grasp on the 802.11 protocol and why we are seeing Frame errors?
It's also possible that this is being reported from the 802.11 layer and they carry it forward so you can see the dropped packets from that layer so you can possibly do something about it. Otherwise we may never know what is going on out there.
And there's a good question, are there any commands so we can see what is really going on at the 802.11 layer?
The discussion might have continued from here.