Hi All,
There is a problem with regulatory part of cfg80211 when cfg80211 is
built-in the kernel. On regulatory init cfg80211 will try to notify
user space about changing current domain to world regulatory but at
that time user space is not up and running yet and uevent message will
be lost. So what will happen is that cfg80211 will wait for the
response from user space and all requests to set current regulatory
will be dropped with the following error: ?Pending regulatory request,
waiting for it to be processed...?.
I assume the problem is known so is there any information on wiki how
to fix this in official way? Of course one option is to have cfg80211
as a module but is it really the right wait to go?
--
Best regards,
Eugene
No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
The problem is that cfg80211 will stuck in situation when cfg80211 is
initialized before user space. One way to get cfg80211 out of this
state is to run crda once right after user space is up and running.
But again is this intentional? Or it is more like a workaround?
2013/9/9 Kalle Valo <[email protected]>:
> Eugene Krasnikov <[email protected]> writes:
>
>> There is a problem with regulatory part of cfg80211 when cfg80211 is
>> built-in the kernel. On regulatory init cfg80211 will try to notify
>> user space about changing current domain to world regulatory but at
>> that time user space is not up and running yet and uevent message will
>> be lost. So what will happen is that cfg80211 will wait for the
>> response from user space and all requests to set current regulatory
>> will be dropped with the following error: ?Pending regulatory request,
>> waiting for it to be processed...?.
>
> Does CONFIG_CFG80211_INTERNAL_REGDB help?
>
> --
> Kalle Valo
--
Best regards,
Eugene
Let me try to describe the problem in more details:
1) When user space is calling "iw reg set <contry_code>" iw utility
will send NL80211_CMD_REQ_SET_REG through nl80211 to cfg80211.
2) cfg80211 will process this call in reg_todo work that is defined
here https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n1621
3) reg_todo work is calling reg_process_pending_hints to process the
call from user space where it checks if last request was
processed(https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n1576).
But last request is still there! This last request is
"NL80211_REGDOM_SET_BY_CORE" request that cfg80211 sent on init for
first regulatory domain initialization.
So the problem is that the first request that is sent by inbuilt
cfg80211 will be never process and will always stay in last_request
variable(https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n91)
Kalle, did you ever tried inbuilt into kernel cfg80211? This problem
is 100% reproducible because inbuilt modules will be always initialize
before user space.
2013/9/10 Kalle Valo <[email protected]>:
> Eugene Krasnikov <[email protected]> writes:
>
>> No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
>>
>> The problem is that cfg80211 will stuck in situation when cfg80211 is
>> initialized before user space. One way to get cfg80211 out of this
>> state is to run crda once right after user space is up and running.
>> But again is this intentional? Or it is more like a workaround?
>
> With the internal regdb you do not need crda anymore, so why does it still
> get stuck? Where does it exactly get stuck?
>
> --
> Kalle Valo
--
Best regards,
Eugene
Eugene Krasnikov <[email protected]> writes:
> There is a problem with regulatory part of cfg80211 when cfg80211 is
> built-in the kernel. On regulatory init cfg80211 will try to notify
> user space about changing current domain to world regulatory but at
> that time user space is not up and running yet and uevent message will
> be lost. So what will happen is that cfg80211 will wait for the
> response from user space and all requests to set current regulatory
> will be dropped with the following error: “Pending regulatory request,
> waiting for it to be processed...”.
Does CONFIG_CFG80211_INTERNAL_REGDB help?
--
Kalle Valo
Eugene Krasnikov <[email protected]> writes:
> No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
>
> The problem is that cfg80211 will stuck in situation when cfg80211 is
> initialized before user space. One way to get cfg80211 out of this
> state is to run crda once right after user space is up and running.
> But again is this intentional? Or it is more like a workaround?
With the internal regdb you do not need crda anymore, so why does it still
get stuck? Where does it exactly get stuck?
--
Kalle Valo