[Voyage-linux] Reported RSSI different on AP vs client/throughput problem
Edwin Whitelaw
(spam-protected)
Thu Oct 12 20:28:09 HKT 2006
An update after further study on my part...
It appears that the RSSI on Unit A for the problematic link will drop by
15db, from the low 60s, high 50s to the mid 70s and stay there for
protracted periods of time (often many 10s of minutes but occasionally
for only a minute or two) and then for no apparent reason will revert
back to the excellent signal. A colleague has suggested outside
interference as a cause though, while plausible, that explanation begs
the question as to why the other radio on the same unit sees no
interference at all. The two antennas are 2-3 ft apart, one above and
one below the WRAP enclosure (~1.5ft coax) on a common pole. The
problem link is HPOL while the other is vertical polarity. Current
channel assignments are 153 (for the hpol link) and 149 for the other.
I have tried any number of channels for the hpol link, including those
in the 5.2 band with no change in behavior. The angle between the two
antennas is approx 52 degrees.
Note that the variation in signal between high and low is discreet, ie,
when it's low, it varies only a db or two from around -74db and when in
the good range, it is similarly consistent around -60db. There are are
very few, if any, intermediate values between the high and low. The
RSSI on the client end is _always_ good at approx -59db.
Signal strength variation was determined by running "iwconfig ath0" as a
1 minute cron on a remote diskful machine to assure a persistent record
in case of any reboot.
My next move is to replace the CM9 on the client end with the more
powerful (?) SR5 and possibly the replace the master radio as well. Can
also rotate the antennas back to VPOL.
Can anyone speculate on a possible source of interference that could
cause this? Any other theories on the observed behavior? Suggested fixes?
Still scratching my head on this one. Any comments welcome.
Edwin
Edwin Whitelaw wrote:
> I have essentially identical WRAPs running Voyage 0.2. Unit A has an
> SR5 (ath1) and CM9 (ath0), both in master mode. This system has three
> client WRAPs, one a 5 mile (8000m) PtP link to Unit B and a PtMP link
> to two other clients (C & D) connecting to Unit A's SR5, each with
> SR5s of their own and a second Engenius as a local AP. The A-C and
> A-D distances are 2.3 and 3.5 miles respectively
>
> The PtMP link between A and C&D works fine with similarly reported
> RSSIs on both Master and client end.
>
> Iperf between hh1 (Unit B) and the master (Unit A) will vary between
> <1mbs to well over 10mbs all while the signal strength remains fairly
> constant. On occasion, the link will disappear long enough for ssh to
> drop but will work again within just a few seconds.
>
> Iperf between A and either C or D is excellent with values typically
> just under 20mbs.
>
> Unit B has a CM9 (ath1) and an Engenius NL2511MP Plus (wlan0). The
> client consistently reports excellent signal strengths:
>
> hh1:~# iwconfig ath1
> ath1 IEEE 802.11a ESSID:"buffalo-hh"
> Mode:Managed Frequency:5.765 GHz Access Point:
> 00:0B:6B:36:FE:21
> Bit Rate:24 Mb/s Tx-Power=16 dBm Sensitivity=0/3
> Retry:off RTS thr:off Fragment thr:off
> Encryption key:<key obscured> Security mode:restricted
> Power Management:off
> Link Quality=39/94 Signal level=-56 dBm Noise level=-95 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Note that the tx power is 16db. Setting to 17 works for a while but
> then reverts to 16 after a short time. RSSI values on the master
> don't obviously reflect the 1 db change in any case.
>
> While the master shows:
>
> buffalo-fnb-hh:~# iwconfig ath0
> ath0 IEEE 802.11a ESSID:"buffalo-hh"
> Mode:Master Frequency:5.765 GHz Access Point:
> 00:0B:6B:36:FE:21
> Bit Rate:0 kb/s Tx-Power:17 dBm Sensitivity=0/3
> Retry:off RTS thr:off Fragment thr:off
> Encryption key:<key obscured> Security mode:restricted
> Power Management:off
> Link Quality=21/94 Signal level=-74 dBm Noise level=-95 dBm
> Rx invalid nwid:1 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> I have an almost identical arrangement in another part of my network,
> one WRAP with the same two cards feeding two downstream units at
> similar distances and have no problems.
>
> I at first thought that the antenna and diversity settings were the
> problem but they are the same as int he other system. The antenna
> lead is connected to the primary port on the CM9s.
>
> hh1:~# cat /proc/sys/dev/wifi1/diversity
> 1
> hh1:~# cat /proc/sys/dev/wifi1/txantenna
> 0
> hh1:~# cat /proc/sys/dev/wifi1/rxantenna
> 1
>
> (Just tried disabling diversity both ends of the PtP link. No change
> in behavior)
>
>
> In a PtP link, why do the master and client show such widely differing
> RSSIs? In a PtMP link, does the master show the stronger(est) of the
> client signals?
>
> I have tried any number of channels on the A-B link, including both
> the lower and upper bands. Good RSSI reported on the client end but
> the throughput and flakiness issues remain. My next attempt at fixing
> will be to replace the CM9s with SR5s though have avoided so far since
> that involves two water tank climbs. :-(
>
> dmesg output from client hh1 (Unit B):
>
> hostap_pci: 0.4.4-kernel (Jouni Malinen <jkmaline at cc.hut.fi>)
> hostap_pci: Registered netdevice wifi0
> wifi0: Original COR value: 0x21
> prism2_hw_init: initialized in 196 ms
> wifi0: NIC: id=0x8013 v1.0.0
> wifi0: PRI: id=0x15 v1.1.1
> wifi0: STA: id=0x1f v1.8.2
> wifi0: Intersil Prism2.5 PCI: mem=0xa0000000, irq=9
> wifi0: registered netdevice wlan0
> SC1x00 Watchdog driver by Inprimis Technolgies.
> wd1100.c: a few hacks by erich.titl at think.ch
> Last reboot was by watchdog!
> ath_hal: module license 'Proprietary' taints kernel.
> ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> RF5413)
> wlan: 0.8.4.2 (svn 1527)
> ath_rate_sample: 1.2 (svn 1527)
> ath_pci: 0.9.4.5 (svn 1527)
> wifi1: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> wifi1: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> wifi1: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
> 24Mbps 36Mbps 48Mbps 54
> Mbps
> wifi1: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps
> 54Mbps
> wifi1: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> wifi1: H/W encryption support: WEP AES AES_CCM TKIP
> wifi1: mac 5.9 phy 4.3 radio 3.6
> wifi1: Use hw queue 1 for WME_AC_BE traffic
> wifi1: Use hw queue 0 for WME_AC_BK traffic
> wifi1: Use hw queue 2 for WME_AC_VI traffic
> wifi1: Use hw queue 3 for WME_AC_VO traffic
> wifi1: Use hw queue 8 for CAB traffic
> wifi1: Use hw queue 9 for beacons
> wifi1: Atheros 5212: mem=0x80000000, irq=12
>
> dmesg from master buffalo-fnb-hh Unit A):
>
> ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> RF5413)
> wlan: 0.8.4.2 (svn 1527)
> ath_rate_sample: 1.2 (svn 1527)
> ath_pci: 0.9.4.5 (svn 1527)
> wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
> 24Mbps 36
> Mbps 48Mbps 54Mbps
> wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps
> 54Mbps
> wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> wifi0: H/W encryption support: WEP AES AES_CCM TKIP
> wifi0: mac 5.9 phy 4.3 radio 3.6
> wifi0: Use hw queue 1 for WME_AC_BE traffic
> wifi0: Use hw queue 0 for WME_AC_BK traffic
> wifi0: Use hw queue 2 for WME_AC_VI traffic
> wifi0: Use hw queue 3 for WME_AC_VO traffic
> wifi0: Use hw queue 8 for CAB traffic
> wifi0: Use hw queue 9 for beacons
> wifi0: Atheros 5212: mem=0x80000000, irq=12
> wifi1: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> wifi1: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps
> 54Mbps
> wifi1: H/W encryption support: WEP AES AES_CCM TKIP
> wifi1: mac 5.9 phy 4.3 radio 3.6
> wifi1: Use hw queue 1 for WME_AC_BE traffic
> wifi1: Use hw queue 0 for WME_AC_BK traffic
> wifi1: Use hw queue 2 for WME_AC_VI traffic
> wifi1: Use hw queue 3 for WME_AC_VO traffic
> wifi1: Use hw queue 8 for CAB traffic
> wifi1: Use hw queue 9 for beacons
> wifi1: Atheros 5212: mem=0x80080000, irq=9
>
>
--
<=+=+=+==+=+=+==+=+=+=+=+=+=+=+=>
Edwin Whitelaw, P.E.
New River Valley Unwired, LLC
2200 Lonesome Dove Dr
Christiansburg, VA 24073
540-239-0318
More information about the Voyage-linux
mailing list