On Tue, 2012-12-04 at 10:28 -0800, Luis R. Rodriguez wrote: > >> This was a side effect of the checks we have in place, it was not expected. > > > > But this is what happens due to the reg.c implementation -- it checks > > that the freqband into which the primary and secondary channel fall each > > allows 40 MHz, even if they are two different freqbands. > > As I implemented it, it should be checking if HT40 is used. If so then > it should be checking to see if the primary can use 40 MHz bandwidth > and then check to see if the secondary can use 20 MHz. The issue > should be that the code should likely is checking that the secondary > requires 40 MHz. It should only need to check if the secondary can use > 20 MHz if HT40 is desired. I don't think this is really what we should do ... In fact given the way we do it now with overlapping freqbands this would cause more problems than it would solve, I think. What it really should check is that for each freqband, as much bandwidth is allowed as falls into that freqband. But given that we have overlapping freqbands, much bandwidth will actually fall into each one of them, so we must allow @40 again ... I'm drawing some pictures now :-) > > Indeed this is what we had, but I built the db.txt parser based on the > > assumption that in fact "@ 20" in the channel 11/12 freqband would have > > been sufficient to allow 40 Mhz on channel 9+. This isn't the case in > > the kernel implementation today. > > I'll fix that, but given you have a slew of updates not sure if this > should go in after / before your changes. I think the easiest for now would be to actually do what's implemented and make this change to dbparse.py: @@ -162,9 +164,6 @@ class DBParser(object): self._syntax_error("Inverted freq range (%d - %d)" % (start, end)) if start == end: self._syntax_error("Start and end freqs are equal (%d)" % start) - if end - start < bw: - self._syntax_error("Invalid bandwidth: %d width channel " - "cannot possibly fit between %d - %d" % (bw, start, end)) except ValueError: self._syntax_error("band must have frequency range") Then we can make the db.txt change I suggested in the the original patch in this thread and keep the rules that both the primary and secondary channel must be in a freqband that allows 40 MHz. Note that this really only applies for the 00 world roaming regdomain (and maybe Japan, but I don't actually think so) since every other regdomain just uses a single rule. johannes