Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#10258 closed defect (worksforme)

iwinfo always shows the same txpower range (0-27dBm) regardless of device capability

Reported by: hanno.schupp@… Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:


As per the title, observed on ath5k, ath9k, and b43.
I have tested with many devices such as WRT54GL (max 24dBm), Pico2 (20dBm), Pico2HP and PicoM2HP (30dBm), DIR615C2 (27dBM) amongst many more. Regardless of their actual maximum txpower output iwinfo wlan0 txpowerlist always seems to give 27dBm as maximum txpower.

Why is that (bug)? Is is a bug or is there something I can do in the configuration of the devices to ensure the actual and correct maximum txpower is shown?

Attachments (2)

txpowerfix.patch (716 bytes) - added by anonymous 5 years ago.
txpowerfix.2.patch (820 bytes) - added by svalentine@… 5 years ago.
Update to original patch

Download all attachments as: .zip

Change History (11)

comment:1 Changed 6 years ago by anonymous

Needs to go into Luci track. Please close

comment:2 Changed 6 years ago by jow

  • Resolution set to wontfix
  • Status changed from new to closed

Thats a kernel buig, libiwinfo just queries cfg80211 for those values which incorrectly returns 27dBm in any case.

Changed 5 years ago by anonymous

comment:3 Changed 5 years ago by svalentine@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Actually, this is a bug, at least for mac80211 in AP mode. The problem is in the implementation of nl80211_get_frequency. When using the hostapd info, the call to nl80211_channel2freq always ends up passing a value of 0 for the channel argument. This problem cascades to the nl80211_get_txpwrlist call, as ch_cur always has a value of 0. The resulting behavior causes max_dbm to get limited to whichever channel has the lowest max_dbm.

In anycase, I've attached a patch that fixes the problem, and it is verified to be working correctly, at least for mac80211 in AP mode. I have not explored other configurations.

The patch was made against the Attitude Adjustment branch r34018.

comment:4 Changed 5 years ago by hanno.schupp@…

Thank you svalentine. I feel vindicated. I was taken back at the time by what I thought was a pretty dismissive response to a very visible issue.
Anyway, the bug fix works for me when tested on a couple of tp-links and a pico-m. Nice!

comment:5 Changed 5 years ago by jow

The attached patch will cause a segmentation fault if no hostapd info is found.

Changed 5 years ago by svalentine@…

Update to original patch

comment:6 Changed 5 years ago by svalentine@…

Okay, now I understand what was causing the problem. The first case of your if block on line 799 was always returning true. Normally the syntax should be more explicit:

        if ((res = nl80211_hostapd_info(ifname)) != NULL && ...

The assignment always returns true, so the second part of the if statement is never evaluated (i.e. channel never gets assigned).

I've updated the patch file with the proper syntax and logic. This is verified working with or without hostapd running.

comment:7 Changed 5 years ago by anonymous

Wow... I just woke up, and now that I look at it, what I wrote makes no sense. Actually, I have no idea why the syntax doesn't work right. The patch does work though.

comment:8 Changed 5 years ago by florian

  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:9 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.