On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez > <mcgrof@xxxxxxxxxxxxxxxx> wrote: >> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez >> <mcgrof@xxxxxxxxxxxxxxxx> wrote: >>> This set of 8 patches adds DFS master support to the Linux wireless subsystem. >>> I've reviewed future possible changes to DFS master regions and it seems that >>> we are not going to be having multiple DFS regions for one country, instead >>> we'll always have one DFS region for one country. >>> >>> The changes here are spread out throughout wireless-regdb, crda the kernel and >>> lastly iw. The changes made allow for older verions of CRDA to work with new >>> wireless-regdb files with DFS region support. If you want DFS master region >>> support you'll need to upgrade your CRDA, your kernel and then hope someone >>> implements DFS master support for your respective driver. >>> >>> This patch series does not have specific driver changes, although some seem to >>> be backing in the oven right now. >> >> Here's a puzzle though... If we change this series to use the other >> pad byte that was available, the first pad byte, instead of the last >> one, we loose backward compatibility support and I cannot figure out >> why. What I ended up seeing was that crda sends the message, and for >> some reason (return code is 222 from nl_wait_for_ack(), whatever that >> is) the kernel rejects it. I suspect it may have to do with some sort >> of offset to the *other* data that makes some of the rules output >> invalid data for the attribute policy, but at least when I hexdump the >> wireless-regdb the only changes I see are in the signature and the pad >> shift. >> >> I got tired of trying though and after seeing flipping the pad bytes >> things worked decided to stay with it. In my original RFC in December >> I had used u16 instead, but since the data was in the last pad byte >> things still worked. So something is fishy about only using the first >> pad byte. The change below, as far as I can tell, should not have any >> issues but it does with the older version of CRDA and even a new one. > > Johannes spotted the issue, I'll send the fix, thanks to Johannes. > John, Johannes the patches still apply my fix goes on top of these > changes, the fix is not addressing a regression introduced by this > patchset, instead it fixes a long standing issue which would prevent > us from using the next available pad byte. I'm going to respin this to make use of 2 bits: 00 unset 01 FCC 10 ETSI 11 JP We may need some more DFS values later but Luis -- 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
