On Mon, Mar 16, 2009 at 07:49:00PM -0400, Richard Farina wrote: > For the sake of sanity, I think that the way rules from wireless-regdb > are enforced needs to be changed. An example: > > country US: > (5170 - 5250 @ 40), (3, 17) > (5250 - 5330 @ 40), (3, 20), DFS > > In this case, you will see that I have removed all of the rules that I > do not intend to cite to lower the complexity of the ruleset. > > Take for example, channel 48, center frequency 5240. A standard 20 mhz > mode will work as expected, as well as HT40-, however HT40+ cannot be > set because it would need to cross the rule boundary. Each line of a > regulatory domain section is enforced by itself. Channel 52 has a > similiar problem where 20 and HT40+ work but HT40- will not. Channel 48 with HT40+ would not work regardless of the regulatory rules; (48,52) is not one of the allowed HT40 channel pairs. You can use (36,40), (44,48), (52,56), and (60,64), but not (40,44), (48,52), (56,60). This is not really a regulatory limit but restriction stated in IEEE 802.11n Annex J. And same applies to channel 52 with HT40-. There may be some other examples where the processing of the ruleset could be improved, but this particular example does not look like something that would benefit much from a change here. > As this specific example includes frequencies in the DFS range, you can > obviously see why no one has noticed this failing before. The obviously > expected result is that if two rules abut and a channel is requested > that stradles them, it should take the most restrictive mix between the > two. For instance, if I set channel 48 in HT40+ mode (and we have DFS > support) the rule would be enforced as (3, 17), DFS; while HT40- would > be enforced as the standard (3, 17). If the channel pair (48,52) were allowed by IEEE 802.11n and we supported DFS, yes, I would agree with this. However, neither of those are the case at the moment (and I don't see the former changing in the future either). -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
