ignored txpower offset on Ubiquiti NanoStation M2 #94
Comments
|
Is there a fix for this bug on the horizon? Or is this an openwrt issue? |
|
All OpenWRT builds for Ubiquiti devices are affected so it would be best to fix it upstream. |
|
is there an openwrt bug report already or should we create one? |
|
Sorry, had forgotten to forward it to OpenWRT, here it is now: https://dev.openwrt.org/ticket/16744 |
|
This problem does also appear on my Ubiquiti PicoStation M2. Probably more Ubiquiti devices are affected. |
|
Upstream has changed the issue to "wontfix" a few days ago. Any suggestions on what do to next? |
|
bekommen wir das nicht gelöst, in dem wir $irgendwie für die betroffenen geräte die sendeleistung manuell festlegen, ohne uns auf upstream zu verlassen? |
|
Wenn wir das tun, können wir den Patch auch gleich Upstream einreichen. Im Endeffekt läuft es ja wirklich nur auf eine Liste mit den Verstärkungsfaktoren der Geräte hinaus. |
|
Such a list does exist in libiwinfo (although entries for many Ubiquiti devices are missing at the moment). We'd just need to think of a nice way to use this list for the default settings. |
|
I've added some updated offsets for the NanoStation M2, M5 and Loco M2. The txpower offsets should be included in the values in the new wifi-config LuCI module, so hopefully those values are accurate now. In particular, the NanoStation M5 value was updated from 5 to 16 dBi. Please test if the new values make any sense; if they do, we might start to think about ways to base the default txpower setting on them. |
|
Okay, I've found a way to set the correct txpower offsets by default. Still, we need to find out what the correct offsets are. The current data file can be found at: http://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=hardware.txt;h=4cac0a1258e266e6d2f5de0f601274f3cd11e31a;hb=HEAD As you can see, only a few devices of the Airmax series have txpower offsets defined. The hardware IDs (the first 4 columns) can be found out using the We will need the correct offsets for the following devices:
The bullet and the rocket are a bit special as they don't come with an antenna, but getting the offsets between AirOS and OpenWrt with the same antenna would be interesting here too. We are not sure if the offsets are just antenna gain, or if there is an additional offset. The most effective way to determine this offset is setting the device to maximum power on OpenWrt while measuring the received signal on another device, and then repeating this from AirOS, setting the same power that iwinfo reported on OpenWrt. The difference between the measured signal levels is the offset. To get the best results, the test setup should be as reproducible as possible, but it is also advisable to repeat this test with different setups and at different times. |
|
hierzu gekürztes Zitat aus dem IRC-Channel vom 4. März:
|
|
I do have access to some hardware at our hackerspace, but no idea how to measure the correct(!) offset - can I help somehow? I'm somewhat missing details on that issue - all is very confusing.
And there are some bugs:
Are you aware of any errata page, here? What is your proposal for operating Ubnt-HW using OpenWRT. Thanks, |
|
da wurde auch schon ein wenig dokumentiert zu dem Thema, fand ich gerade: |
|
Rocket M2 only shows up ('iw list') with 18dbm on all channels instead of 28dbm. |
|
@NeoRaider what do you think about using iwinfo as drafted in freifunk-berlin/firmware#381 like this (https://github.com/SvenRoederer/freifunk-berlin-firmware-packages/blob/fix/issue381/utils/freifunk-berlin-network-defaults/uci-defaults/freifunk-berlin-default-txpower) to limit the TX-power by default? |
rotanid
added
the
9. meta: known issue
|
@NeoRaider Here are the power offsets. Ubiquity seems to ignore the device ID. I think some of the existing OpenWrt entries are wrong and I assume that they do not contain the antenna gains as equal boards used in products with different antennas have the same offsets. These values seem to be PA values. Edit: |
|
@rotanid Can you please add it to the 2019.1 milestone and pin the issue? I'd be happy about a Gluon-specific solution. With the knowledge of the antenna gains and the power offsets, we can write a package that sets the proper values respecting EIRP and a site.conf option to reset existing custom values. I've submitted the patch: |
|
you can work on this issue without the things you request, and help is welcome. |
|
@rotanid The possibility that we have devices running with more than 10 times the allowed EIRP even if you manually decrease the tx-power by the antenna gain does not deserve high priority? Edit: The "real" EIRP is EIRP=TXPower+Ath9kTXOffset+Ath9kAntennaGain+(PAGain or TXOffset)+(AntennaGain if it is not included in Ath9kTXOffset or Ath9kAntennaGain) There is a program to dump the ath9k values from a ART-partition dump https://github.com/pepe2k/ar9300_eeprom . Unfortunately it does not yet support the offsets used by Ubiquiti. I'm currently looking into the ath9k sources to try to fix it. TP-Link defines the antenna and PA-Gains in the TX-Offset field. Thus we did never have problems with those devices. I assume that Ubiquiti does similar with their antenna gains (although ath9k-ART has a special field for antenna gains). The PA gain however is included in Ubiquiti's firmware for the subvendor device IDs of the chips. Thus we need to check if the antenna gains are defined in the ART partition. If that is the case, with the patch to the iwinfo hardware.txt, iwinfo gives us the correct values. If not we have to define the antenna gains manually using iw matching the board names. Still when the WLAN devices' configs are initialized in Gluon in 200-wireless, the iwinfo offsets are not considered at the moment. That means in the worst case if the user has a HP device and the antenna gains are not considered in the ART-partition and he or she does not set the offsets accordingly we may have 100 times the allowed EIRP. If that is the case I wonder that nobody was ever bothered by the BNetzA. BTW you can read the power offset of a device running stock Ubiquiti firmware in the /proc/ubnthal/board.info or /proc/ubnthal/system.info file (I'm not sure about which was the correct name). OpenWrt is not really interested in fixing this as iw is a program shipped by the kernel and has no possibility to define such offsets. And linux is not interested in supporting this because they ship drivers for WLAN chipsets, but do not support custom boards with an additional PA chip. |
|
if someone else would have the knowledge and time to fix it, it would have been done long time ago. |
|
The patch has been merged. Still I need to do some testing whether the antenna gain is defined in the ART partition. If yes, then there is only a simple Gluon upgrade script missing to set the correct TX power on first boot. If no, I need to find out how Ubiquiti does it and maybe add definitions depending on the model names. |
|
A patch for Gluon is on the way, but I really need help to find the missing pieces and identify some Ubiquiti devices (some could be found just by pure logic and good old human pattern recognition). Please help, solving the puzzle. To be sure @Adorfer needs to measure a Bullet or Picostation with his power meter with OpenWrt compared to stock firmware. |
I do not have one or the other in my hands. |
|
Unfortunately no, MIMO routers give bad measurements... |
Bandwidth info for qos-scripts and SmartGateway (olsrd) will now be configured through ffwizard-berlin. This fixes freifunk-gluon#94.
|
I know this topic is probably a sore spot by now. |
It seems that the 12 dBi antenna of the Ubiquiti NanoStation M2 is properly set in the firmware, at least a 12dB txpower offset is noted in iwinfo. However, the txpower is not reduced accordingly:
$ iwinfo wlan0 ESSID: "luebeck.freifunk.net" Access Point: 24:A4:3C:AC:F4:AC Mode: Master Channel: 1 (2.412 GHz) Tx-Power: 30 dBm Link Quality: 40/70 Signal: -70 dBm Noise: -89 dBm Bit Rate: 43.6 MBit/s Encryption: none Type: nl80211 HW Mode(s): 802.11bgn Hardware: 168C:002A 0777:E012 [Ubiquiti NanoStation M2] TX power offset: 12 dB Frequency offset: none Supports VAPs: yes wlan0-1 ESSID: "02:d1:11:37:fc:38" Access Point: 02:D1:11:37:FC:38 Mode: Ad-Hoc Channel: 1 (2.412 GHz) Tx-Power: 30 dBm Link Quality: 69/70 Signal: -41 dBm Noise: -89 dBm Bit Rate: 102.3 MBit/s Encryption: unknown Type: nl80211 HW Mode(s): 802.11bgn Hardware: 168C:002A 0777:E012 [Ubiquiti NanoStation M2] TX power offset: 12 dB Frequency offset: none Supports VAPs: yesThe "Tx-Power" field seems to include the tx power offset (https://dev.openwrt.org/browser/branches/attitude_adjustment/package/iwinfo/src/iwinfo_cli.c?rev=36121#L433). However it should say "Tx-Power: 20 dBm".
The reg domain is set correctly, too:
$ iw reg get country DE: (2400 - 2483 @ 40), (N/A, 20) (5150 - 5250 @ 80), (N/A, 20), NO-OUTDOOR (5250 - 5350 @ 80), (N/A, 20), NO-OUTDOOR, DFS (5470 - 5725 @ 80), (N/A, 27), DFS (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOORThe text was updated successfully, but these errors were encountered: