Re: Exposing enum ieee80211_channel_flags to user
On 11 June 2015 at 11:46, Johannes Berg johan...@sipsolutions.net wrote: On Thu, 2015-06-11 at 11:45 +0200, Johannes Berg wrote: On Thu, 2015-06-11 at 11:35 +0200, Rafał Miłecki wrote: iw also wasn't helpful: Frequencies: * 5180 MHz [36] (30.0 dBm) * 5200 MHz [40] (30.0 dBm) * 5220 MHz [44] (30.0 dBm) * 5240 MHz [48] (30.0 dBm) After some in-kernel debugging (nl80211_set_wiphy, cfg80211_chandef_usable, cfg80211_secondary_chans_ok) I finally realized it was because of: IEEE80211_CHAN_NO_80MHZ Do you have any idea how we could handle such cases nicely? To let user find out what's going on (wrong)? Should iw be extended to print flag names? Or should hostapd check for channels in some smarter way? Any other ideas? We already have the flags exposed to iw, it's just not printing them. There was a patch to print them, but it wasn't complete, and the submitter kinda went away. You can see the discussion here: http://mid.gmane.org/1425452686-28196-1-git-send-email-arnag...@qti.qualcomm.com Upon rereading, I think my preference would be to remove much of the channel list information and add a separate iw command. Do you mean removing channel list from iw phy X info? Can you suggest the new command name? -- Rafał -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing enum ieee80211_channel_flags to user
On Thu, 2015-06-11 at 11:35 +0200, Rafał Miłecki wrote: iw also wasn't helpful: Frequencies: * 5180 MHz [36] (30.0 dBm) * 5200 MHz [40] (30.0 dBm) * 5220 MHz [44] (30.0 dBm) * 5240 MHz [48] (30.0 dBm) After some in-kernel debugging (nl80211_set_wiphy, cfg80211_chandef_usable, cfg80211_secondary_chans_ok) I finally realized it was because of: IEEE80211_CHAN_NO_80MHZ Do you have any idea how we could handle such cases nicely? To let user find out what's going on (wrong)? Should iw be extended to print flag names? Or should hostapd check for channels in some smarter way? Any other ideas? We already have the flags exposed to iw, it's just not printing them. There was a patch to print them, but it wasn't complete, and the submitter kinda went away. You can see the discussion here: http://mid.gmane.org/1425452686-28196-1-git-send-email-arnag...@qti.qualcomm.com johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Exposing enum ieee80211_channel_flags to user
Hi, Recently I spent quite some time trying to figure out why hostapd can't start 80 MHz AP for me with following error: radio1 (1617): nl80211: Failed to set channel (freq=5180): -22 (Invalid argument) My config included: hw_mode=a channel=36 vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=42 I added some debugging to hostapd but it didn't help much: radio1 (1617): Allowed channel: mode=2 chan=36 freq=5180 MHz max_tx_power=20 dBm radio1 (1617): Allowed channel: mode=2 chan=40 freq=5200 MHz max_tx_power=20 dBm radio1 (1617): Allowed channel: mode=2 chan=44 freq=5220 MHz max_tx_power=20 dBm radio1 (1617): Allowed channel: mode=2 chan=48 freq=5240 MHz max_tx_power=20 dBm radio1 (1617): hw vht capab: 0x20, conf vht capab: 0x20 radio1 (1617): Completing interface initialization radio1 (1617): Mode: IEEE 802.11a Channel: 36 Frequency: 5180 MHz radio1 (1617): nl80211: Set freq 5180 (ht_enabled=1, vht_enabled=1, bandwidth=80 MHz, cf1=5210 MHz, cf2=0 MHz) radio1 (1617): * freq=5180 radio1 (1617): * vht_enabled=1 radio1 (1617): * ht_enabled=1 radio1 (1617): * bandwidth=80 radio1 (1617): * channel_width=3 radio1 (1617): * center_freq1=5210 radio1 (1617): * center_freq2=0 radio1 (1617): nl80211: Failed to set channel (freq=5180): -22 (Invalid argument) iw also wasn't helpful: Frequencies: * 5180 MHz [36] (30.0 dBm) * 5200 MHz [40] (30.0 dBm) * 5220 MHz [44] (30.0 dBm) * 5240 MHz [48] (30.0 dBm) After some in-kernel debugging (nl80211_set_wiphy, cfg80211_chandef_usable, cfg80211_secondary_chans_ok) I finally realized it was because of: IEEE80211_CHAN_NO_80MHZ Do you have any idea how we could handle such cases nicely? To let user find out what's going on (wrong)? Should iw be extended to print flag names? Or should hostapd check for channels in some smarter way? Any other ideas? -- Rafał -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing enum ieee80211_channel_flags to user
On Thu, 2015-06-11 at 12:00 +0200, Rafał Miłecki wrote: Upon rereading, I think my preference would be to remove much of the channel list information and add a separate iw command. Do you mean removing channel list from iw phy X info? I'm not sure I'd remove it completely - but perhaps remove all the detail information like DFS time etc. that's just making it really large? I.e. go back to just having a single line of information. Can you suggest the new command name? iw phy X channels would work? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing enum ieee80211_channel_flags to user
On Thu, 2015-06-11 at 11:45 +0200, Johannes Berg wrote: On Thu, 2015-06-11 at 11:35 +0200, Rafał Miłecki wrote: iw also wasn't helpful: Frequencies: * 5180 MHz [36] (30.0 dBm) * 5200 MHz [40] (30.0 dBm) * 5220 MHz [44] (30.0 dBm) * 5240 MHz [48] (30.0 dBm) After some in-kernel debugging (nl80211_set_wiphy, cfg80211_chandef_usable, cfg80211_secondary_chans_ok) I finally realized it was because of: IEEE80211_CHAN_NO_80MHZ Do you have any idea how we could handle such cases nicely? To let user find out what's going on (wrong)? Should iw be extended to print flag names? Or should hostapd check for channels in some smarter way? Any other ideas? We already have the flags exposed to iw, it's just not printing them. There was a patch to print them, but it wasn't complete, and the submitter kinda went away. You can see the discussion here: http://mid.gmane.org/1425452686-28196-1-git-send-email-arnag...@qti.qualcomm.com Upon rereading, I think my preference would be to remove much of the channel list information and add a separate iw command. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing enum ieee80211_channel_flags to user
On 06/11/2015 03:01 AM, Johannes Berg wrote: On Thu, 2015-06-11 at 12:00 +0200, Rafał Miłecki wrote: Upon rereading, I think my preference would be to remove much of the channel list information and add a separate iw command. Do you mean removing channel list from iw phy X info? I'm not sure I'd remove it completely - but perhaps remove all the detail information like DFS time etc. that's just making it really large? I.e. go back to just having a single line of information. Can you suggest the new command name? iw phy X channels would work? Maybe also allow the full dump with an optional --verbose flag: 'iw --verbose phy X info' ? Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing enum ieee80211_channel_flags to user
On Thu, 2015-06-11 at 06:16 -0700, Ben Greear wrote: Maybe also allow the full dump with an optional --verbose flag: 'iw --verbose phy X info' ? Well, as I said, it's not so simple to do this in the info handler since you need to collect all the info first and then print it. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
