Tuesday, December 17, 2013, 3:17:50 AM, you wrote: > Hi Sander, > On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom > <linux@xxxxxxxxxxxxxx> wrote: >> >> Monday, December 16, 2013, 12:37:47 PM, you wrote: >> >>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>>> >>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>>> >>>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>>> <linux@xxxxxxxxxxxxxx> wrote: >>>>>> >>>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>>> >>>>>>> The best way to address all this is by automatic region awareness and >>>>>>> doing the right thing on devices, this however requires good >>>>>>> architecture / calibration data / etc and all that needs to be >>>>>>> verified by the system integrators, and finally they need to be >>>>>>> certified. If you want to hack your firmware and software go at it, >>>>>>> just be aware there are reasons for things. >>>>>> >>>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>>> >>>>> Its simply stupid to have the user be involved, period, the fact that >>>>> a user would be involved should only be for testing or helping >>>>> compliance for a busted device, development, research and obviously >>>>> hacking. Linux allows all these but by default a device with firmware >>>>> and a custom regdomain that will barf if you try to use a channel that >>>>> is not allowed is a restriction in firmware. Feel free to reverse >>>>> engineer that if you don't like it but it just won't be supported or >>>>> go upstream. Now, the common denominator is generally optimized for >>>>> best performance as well so you shouldn't have to do anything, and for >>>>> APs -- this is typically carefully crafted for a region, also highly >>>>> optimized. >>>> >>>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>>> from CRDA code: >>>>>>>> >>>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>>> If i remove that return it processes the request. >>>>>>>> >>>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>>> >>>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>>> the dump seems fine. >>>>>> >>>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>>> unclear from the paste you made. >>>>>> >>>>>>> diff -u file.c.orig file.c >>>>>> >>>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>>> >>>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>>> probably due to those firmware restrictions. >>>> >>>>> Its unclear what results you got, and yeah if the device is restricted >>>>> then its just the fw telling the driver its channels and you can't use >>>>> them. That's it. You won't be able to override information then unless >>>>> you hack the firmware >>>> >>>> Ping ? >>>> >>>> Is there anymore information you need to *fix* the problem ? >> >>> Maybe you did not get the essence of the response from Luis: There is >>> *no* problem to be fixed. >> >> *sigh* .. >> >> Let's start from scratch then ... >> >> >> a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? >> b) If so, does it set a regulatory domain from firmware ? >> c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? >> d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> # iw reg set US >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> >> Dmesg only spits out: >> [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... >> > As has been explained previously, this indicates that, somehow, CRDA > is not answering the kernel's requests as it should. Looking at the > dmesg you posted before, we have: > [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain > which never gets a reply. > Are you using your distro's official CRDA package or have you compiled > your own? It might not be installed properly as it looks like it's not > responding to the kernel's call to update the world regulatory domain. > There's more to installing CRDA than just sticking the executable and > database in the right places. It's the official Debian package. But i have tried to compile the db.txt into the kernel as is mentioned and use the internalregdb kernel config option. Could it be that since i compile all modules in the kernel and use --initrd .. that the CRDA is just not available at *that* earlier moment in boot when that module gets activated ? If so, wouldn't it be feasible to have a) timeout with error message b) clearing the request so a subsequent request can be made ? The way the patches that where posted then circumvent the problem is by just plain ignoring the blocked request. I could see if compiling them as loadable modules helps, another thing would be shoveling the whole CRDA stuff into initrd. > On my system here, I have: > [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain > ... > [ 17.300582] cfg80211: World regulatory domain updated: > [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), > (300 mBi, 2000 mBm) > [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Your dmesg doesn't have the response listed, therefore CRDA is not > responding to the kernel's requests. The kernel will not make > additional requests until the previous one is answered. >> e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? > It _is_ doing this. > The world regulatory domain is the intersection of all the regulatory > domains we know of. This is the _most_ restricted version which > _ensures_ that you're obeying the law _everywhere_. >> f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? > Because there is no bug in the kernel, the bug is in your system's setup. I will leave this one in the clear for the moment ... (nope i will not .. see below ;-) ) >> g) Saying it has got to do with reg db's not being found or all kinds of other arguments while >> the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to >> how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) >> in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) >> or >> with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) >> Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. > These patches _break_ the functionality of the kernel, not fix it. > They allow the kernel to issue requests before the previous one is > answered. This is a bug. There are good reasons why this is not > allowed. Yes because for some reason it's allowed for requests to block for ever ... which could be considered a bug. So yes it's the wrong fix ... but it at least identifies a problem .. infinite blocking requests. I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. > Thanks, -- 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
