Transmission power issue after switching channel-width

[Oliver]

Hey,

Here's an intresting one for Ubiquiti tech support. While doing some tests on the v3.2.2 RC firmware on my PS5's to help find yet undiscovered problems, I switched my units from 40MHz to 5MHz channel-width, but never successfully got the units connected at that width. After restoring my previous configuration, which I had saved beforehand, throughput and negogiated speed of my link where suddenly way down. It appears as if the signal-strength received at the AP-side of the link, from the station-side, has jumped from around -70dBm to -82dBm. This is about what I would get when the output-power in the web-interface would be set to it's lowest setting, 7dBm. It is, however, set at 20dBm. No matter what power-level I set, the received signal at the AP doesn't change at all. "Obey regulatory power" is obviously turned off. The received signal-strength at the client-side seems to be what it always has been.

As I mentioned, I reloaded the original configuration from file. I rebooted both sides of the link and even powercycled the client-side, but no luck. I haven't powercycled the AP-side yet, but will do so tomorrow. I've read postings here from others about these units losing tx-power or rx-sensitivity after a firmware-upgrade, if I'm not mistaken. Do I have a broken unit or is there anything else I could try? Thanks in advance!


Grtz,

Oliver

[Oliver]

Here's a followup, which also includes the config of the affected unit, minus some private info, which I replaced by "xxx".

The other side is similar, except that it runs in AP+WDS-mode. It was with this config that I changed the channel-width to 5 MHz and lowered the power-output to 15dBm, when the link didn't come up and the unit lost most of it's output-power. BTW: anything below 40MHz wide channels doesn't appear to work in the v3.2.2 RC firmware, when country is set to "Netherlands".

Firmware-version is v3.2.2 RC. I've since tried powercycling, factory-defaulting and reverting to v3.1.1, with no luck. Power-output remains at the minimum, no matter how it's set in the web-interface. Is my hardware broken, or could some EEPROM-data somewhere have gotten corrupted and are there other things I can try to bring it back?


Regards,

Oliver

Config:

aaa.1.status=disabled
aaa.1.wpa.key.1.mgmt=WPA-PSK
aaa.1.wpa.psk=xxx
aaa.status=disabled
bridge.1.devname=br0
bridge.1.fd=1
bridge.1.port.1.devname=eth0
bridge.1.port.1.status=enabled
bridge.1.port.2.devname=ath0
bridge.1.port.2.status=enabled
bridge.1.stp.status=disabled
bridge.status=enabled
dhcpc.1.devname=br0
dhcpc.1.status=disabled
dhcpc.status=disabled
dhcpd.1.status=disabled
dhcpd.status=disabled
dnsmasq.1.devname=eth0
dnsmasq.1.status=enabled
dnsmasq.status=disabled
ebtables.1.cmd=-t nat -A PREROUTING --in-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.1.status=disabled
ebtables.2.cmd=-t nat -A POSTROUTING --out-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.2.status=disabled
ebtables.3.cmd=-t broute -A BROUTING --protocol 0x888e --in-interface ath0 -j DROP
ebtables.3.status=enabled
ebtables.50.status=disabled
ebtables.51.status=disabled
ebtables.52.status=disabled
ebtables.status=enabled
httpd.https.port=443
httpd.https.status=enabled
httpd.port=80
httpd.status=enabled
igmpproxy.status=disabled
iptables.3.status=disabled
iptables.status=disabled
netconf.1.alias.1.status=disabled
netconf.1.alias.2.status=disabled
netconf.1.alias.3.status=disabled
netconf.1.alias.4.status=disabled
netconf.1.alias.5.status=disabled
netconf.1.alias.6.status=disabled
netconf.1.alias.7.status=disabled
netconf.1.alias.8.status=disabled
netconf.1.devname=eth0
netconf.1.ip=0.0.0.0
netconf.1.netmask=255.255.255.0
netconf.1.promisc=enabled
netconf.1.status=enabled
netconf.1.up=enabled
netconf.2.alias.1.status=disabled
netconf.2.alias.2.status=disabled
netconf.2.alias.3.status=disabled
netconf.2.alias.4.status=disabled
netconf.2.alias.5.status=disabled
netconf.2.alias.6.status=disabled
netconf.2.alias.7.status=disabled
netconf.2.alias.8.status=disabled
netconf.2.allmulti=enabled
netconf.2.devname=ath0
netconf.2.ip=0.0.0.0
netconf.2.netmask=255.255.255.0
netconf.2.status=enabled
netconf.2.up=enabled
netconf.3.autoip.status=disabled
netconf.3.devname=br0
netconf.3.ip=xxx
netconf.3.netmask=255.255.255.248
netconf.3.status=enabled
netconf.3.up=enabled
netconf.status=enabled
netmode=bridge
ntpclient.1.server=pool.ntp.org
ntpclient.1.status=enabled
ntpclient.status=enabled
ppp.1.password=
ppp.1.status=disabled
ppp.status=disabled
radio.1.ack.auto=disabled
radio.1.acktimeout=33
radio.1.chanshift=5
radio.1.clksel=0
radio.1.countrycode=528
radio.1.devname=ath0
radio.1.dfs.status=
radio.1.frag=off
radio.1.ieee_mode=ast
radio.1.mcastrate=54M
radio.1.mode=managed
radio.1.rate.auto=enabled
radio.1.rate.max=54M
radio.1.rts=off
radio.1.rx_antenna=1
radio.1.rx_antenna_diversity=disabled
radio.1.status=enabled
radio.1.thresh62a=28
radio.1.thresh62b=28
radio.1.thresh62g=28
radio.1.tx_antenna=1
radio.1.tx_antenna_diversity=disabled
radio.1.txpower=13
radio.countrycode=528
radio.ratemodule=ath_rate_minstrel
radio.status=enabled
resolv.nameserver.1.ip=xxx
resolv.nameserver.1.status=enabled
resolv.nameserver.2.ip=xxx
resolv.nameserver.2.status=enabled
resolv.status=enabled
route.1.devname=br0
route.1.gateway=xxx
route.1.ip=0.0.0.0
route.1.netmask=0
route.1.status=enabled
route.status=enabled
sshd.port=22
sshd.status=enabled
syslog.remote.status=
syslog.status=enabled
tshaper.status=disabled
users.1.name=root
users.1.password=xxx
users.1.status=enabled
users.status=enabled
wireless.1.addmtikie=enabled
wireless.1.ap=00:15:6D:B5:12:A1
wireless.1.authmode=1
wireless.1.compression=enabled
wireless.1.devname=ath0
wireless.1.fastframes=enabled
wireless.1.frameburst=enabled
wireless.1.hide_ssid=disabled
wireless.1.l2_isolation=enabled
wireless.1.macclone=disabled
wireless.1.scan_list.status=disabled
wireless.1.security=none
wireless.1.signal_led1=94
wireless.1.signal_led2=80
wireless.1.signal_led3=73
wireless.1.signal_led4=65
wireless.1.sper=disabled
wireless.1.ssid=xxx
wireless.1.status=enabled
wireless.1.wds=enabled
wireless.1.wmm=enabled
wireless.1.wmmlevel=0
wireless.status=enabled
wpasupplicant.device.1.devname=ath0
wpasupplicant.device.1.driver=madwifi
wpasupplicant.device.1.profile=WPA-PSK
wpasupplicant.device.1.status=enabled
wpasupplicant.profile.1.name=WPA-PSK
wpasupplicant.profile.1.network.1.bssid=00:15:6D:B5:12:A1
wpasupplicant.profile.1.network.1.key_mgmt.1.name=WPA-PSK
wpasupplicant.profile.1.network.1.pairwise.1.name=CCMP
wpasupplicant.profile.1.network.1.proto.1.name=RSN
wpasupplicant.profile.1.network.1.psk=xxx
wpasupplicant.profile.1.network.1.ssid=xxx
wpasupplicant.status=enabled

[UBNT-Mike.Ford]

Hey Oliver,

I got this to my software team to investigate.

Thanks,

Mike

[UBNT-Mike.Taylor]

Oliver,

This is indeed an interesting issue. We haven't heard anything like this. There are a couple of questions to help diagnose it:

1) is signal strength of other devices still ok at the AP?
2) if you connect to another AP does the signal strength look any better?
3) If you downgrade to 2.2.1 or 3.1.1 does it look any different?

For the 5/10 Mhz use - you said that it didn't work in your country code, but have you tested with any other country codes? Please see if you can make it work with US or World country codes.

We have been working on refining the signal/noise strength reporting to resolve some customer issues with certain chips. On some systems, the reported signal level may be reported a bit lower on 3.2.2 than on 3.2/3.2.1 but the actual transmission power isn't affected - just reporting. We have made iteratively better workarounds for this issue we were working on. Some of the early solutions (on firmware versions we pulled) were incorrectly compensating on boards with a hardware txpower offset (increase) that is not visible to the driver/OS. I think 3.2.2 final will be slightly different still, but will be more accurate as a relative signal strength indicator.

Let me know what you find.

Thanks,

Mike

[Oliver]

Hey Mike,

As even with my restored previous configuration, one side of the link is reporting a much weaker signal and throughput is less than half of what it used to be, I have already gone ahead and requested an RMA. So in a couple of weeks your tech-department will get to be able to take the actual unit apart and have a look for themselves. I'll be as curious as they are what the cause of the problem will turn out to be. :-) Meanwhile, I'll answer some of your questions.

> 1) is signal strength of other devices still ok at the AP?

Actually, I haven't checked yet, as there are no other 5 GHz-devices in range of the AP-side and I haven't had a laptop with an a-card handy for testing yet. I can tell you that the received signal-strength from the client at the AP remains the same. Having the transmit-power slider at the client on 7 dBm or 26 dBm doesn't make any difference. Now the thought had crossed my mind that the AGC at the AP-side might be on the fritz and always attenuates the incoming signal to exactly the same weak strength somehow, but if I associate the PS5 client-side to a local Cisco 1250 AP, I still get the same results. The received signal at the AP doesn't change, regardless of how the power at the PS5 is set. Anyways, that's why I'll do tests with the RMA-unit first, before sending the suspected defective unit back. To be absolutely sure I got the right one. :-)

> 2) if you connect to another AP does the signal strength look any better?

Heh, already answered above. :-)

> 3) If you downgrade to 2.2.1 or 3.1.1 does it look any different?

Tried downgrading to v3.1.1 and factory-defaulting. Problem remained.

> For the 5/10 Mhz use - you said that it didn't work in your country code, but have you tested with any other country codes? Please see if you can make it work with US or World country codes.

I'm a bit reluctant to start fiddling with the channel-width again. For all we know I triggered some kind of bug and will blow out the AP-side of the link as well, requiring another RMA. I'm willing to try, but the risk will be yours. :-) BTW: When switching to a lower channel-width, the client does see the AP on a scan, but with an all-zero MAC-address and it doesn't connect, even with all encryption and access-control turned off. It even did this for 20MHz channel-width and it still wouldn't connect. If I then chose "Compliance test" as the country on the client, the link established, if I remember correctly.

Is there anything low-level I can try to tweak from the shell to try to bring the tx-power back? Although it could very well be, it somehow doesn't feel like a hardware-problem. Let me know if you need more info.



Grtz,

Oliver

[UBNT-Mike.Taylor]

You could use iwconfig and see what the reported txpower, signal and noise are. If you tried 3.1.1 and had the same result, then it may very well be a hardware problem.

When you send in the RMA, make a note on the package Attn: Mike Taylor and I'll get it. I'd like to check it out. Ideally, leave it configured as it was when having the problem.


Thanks,

Mike

[Oliver]

Hey Mike,

I had already tried iwconfig to tweak the tx-power on the bad unit and a whole battery of iwpriv-commands, but no luck. Didn't compare the output to v3.1.1, though. If this is a software-problem, it'll probably be some piece of persistent storage outside of the flash config-area that got changed / corrupted somehow, like the tuning / parameter-EEPROM most wireless radio's have. I was more thinking along the lines of tweaking that. :-)

I'll make sure the package reaches you. The configuration attached to my second post in this thread is pretty much what I'm still using, so you can load that and fill in the "xxx"'s with your own data. If you want, I can provide the configuration for the AP-side in the same way, so you can recreate the situation.


Grtz,

Oliver

[Oliver]

Hey Mike,

FYI: Every time I reply to this thread, I get this error:

Failed sending email :: PHP ::

DEBUG MODE

Line : 234
File : emailer.php


Must be some email-notification failing. Thought you'd want to know.


Grtz,

Oliver

[UBNT-Mike.Ford]

Hey Guys,

Im looking into the PHP error, only happens with certain accounts.

Thanks,

Mike

[Oliver]

Hey Mike Taylor,

Update: The RMA arrived and I have since done some climbing to replace the suspect client-side unit. I had loaded the exact same configuration on the new unit as was present on the old one and only changed the MAC-addresses for the WDS-peer and MAC-ACL on the AP-side to the new client-side MAC-address. Signal-strength and throughput returned to their values from before the problems began.

Now that I have easy physical access to the old unit, I've also tried OpenWRT v8.09 RC1 and AirOS v2.1.1 on it, without luck. Txpower remained stuck at it's lowest level.

Mike Taylor, please answer my PM. I'm ready to ship the old unit to you.


Grtz,

Oliver

[tcook]

Has there been a resolution to this? I am having exactly the same problem with a PTP link. Link is 4.1 miles LOS. When first installed I was able to get ~-55dbm signal at each end. Upgraded radios and reduced channel bandwidth and now I can only achieve a best of ~-80dbm. Seems the amps are dead in the radios. Changing the power levels from min to max has no affect.

[UBNT-Mike.Taylor]

Oliver,

I think you meant Mike Ford. If you were discussing RMA/shipping then it was Mike Ford you were talking to. I don't recall seeing any PM from you but I would have forwarded it to Mike Ford.

Thanks,

Mike