Bugzilla – Bug 2740
WifiPhy: ChannelWidth forced to default when using ChannelNumber instead of Frequency
Last modified: 2017-05-19 02:33:45 UTC
Created attachment 2844 [details] Simple illustrative script based on tutorial/third The ChannelNumber attribute of WifiPhy is set to default value by WifiPhy::ConfigureChannelForStandard in the following cases: - no Frequency nor ChannelNumber set - only ChannelNumber set, but not Frequency This is not very convenient, because the user will think that both Frequency and ChannelNumber based configurations should be equivalent, or, better yet, that simply setting ChannelWidth should be sufficient. I have also seen that there is no verification on the bandwidth obtained for the corresponding channel number. In the provided script, commenting out the standard and wifiManager parts, while keeping channel number 42 will lead to an 80MHz band for a default 11a device during the setup phase.
(In reply to Rediet from comment #0) > Created attachment 2844 [details] > Simple illustrative script based on tutorial/third > > The ChannelNumber attribute of WifiPhy is set to default value by > WifiPhy::ConfigureChannelForStandard in the following cases: > - no Frequency nor ChannelNumber set > - only ChannelNumber set, but not Frequency > This is not very convenient, because the user will think that both Frequency > and ChannelNumber based configurations should be equivalent, or, better yet, > that simply setting ChannelWidth should be sufficient. The interaction between these attributes is carefully documented here: https://www.nsnam.org/docs/models/html/wifi-user.html#wifiphy-attribute-interactions There are two ways to configure: 1) set frequency and channel width directly 2) set a channel number and a standard, which will assign frequency and channel width based on an internal map to these values I'm open to suggestions on how to make this clearer, but the overall problem is that some of these parameter configurations are mutually exclusive. The thinking behind this was that the most common configuration to support is the user who wants to set a standard and a well-defined channel number. In such a case, we do not allow attributes Frequency and ChannelWidth to override the combination. However, for users who want fine-grained control of frequency and width, we allow that as an alternative (and this is possible if the user refrains from setting a channel number). > > I have also seen that there is no verification on the bandwidth obtained for > the corresponding channel number. In the provided script, commenting out the > standard and wifiManager parts, while keeping channel number 42 will lead to > an 80MHz band for a default 11a device during the setup phase. I would argue that this is a configuration error based on the above.
I'm very sorry, I had carefully read the manual (twice!) but didn't remember to apply the recommendations in it when coding. In addition, I had also used the wrong channel width/channel number combination in the script. I'm thus invalidating the "bug". Just a comment though, would it be possible to just leave a hint in the Doxygen comments of the class declarations (of let's say SetFrequency, SetChannelWidth, SetChannelNumber)? I don't know if it'll be useful for everyone, but when coding I often refer to the Doxygen (but not necessarily to the model library).