Change channel bandwidth without iw command

Change channel bandwidth without iw command

[Okhwan Lee]

Hi,

We are trying to implement a protocol to evaluate the performance our
algorithm using QCA9880.

To implement our protocol, a receiver have to change the bandwidth
when a Action frame (what we define) is successfully received.
We know that the QCA9880 can change bandwidth by using iw command in
monitor mode.
So, we use similar function path used by "iw dev set freq ..."
When the receiver detects the reception of the Action frame we call
"ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:

/*************** net/mac80211/rx.c ******************/

// receive action frame, change bandwidth 80 -> 20

                rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
                chandef = local->monitor_chandef; // copy current chandef
                chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
                chandef.center_freq1 = 5180; // set center freq...
                ieee80211_set_monitor_channel(wiphy, &chandef);
                rtnl_unlock();

/********************************************************/

However, the receiver invokes kernel panic when receives the Action frame.
As fas as we know, the panic is occurred in ath10k_config_chan of
ath10k device driver.
To the best our knowledge, our implementation exploits same function
path of iw command in nl80211, cfg80211, mac80211 and ath10k.
Moreover, we confirm that the input parameters (wiphy, chandef) in our
implementation are identical to the parameters used by iw command.

Is there any reason why we cannot change bandwidth?
Of course, iw command work correctly.

If you have any idea to solve this, please let me know.

Thanks a lot for your reading.

Sincerely yours,

Okhwan Lee , Ph.D. student

Re: Change channel bandwidth without iw command

[Michal Kazior]

On 22 October 2014 12:14, Okhwan Lee <ohlee@mwnl.snu.ac.kr> wrote:
> Hi,
>
> We are trying to implement a protocol to evaluate the performance our
> algorithm using QCA9880.
>
> To implement our protocol, a receiver have to change the bandwidth
> when a Action frame (what we define) is successfully received.
> We know that the QCA9880 can change bandwidth by using iw command in
> monitor mode.
> So, we use similar function path used by "iw dev set freq ..."
> When the receiver detects the reception of the Action frame we call
> "ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:
>
> /*************** net/mac80211/rx.c ******************/
>
> // receive action frame, change bandwidth 80 -> 20
>
>                 rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
>                 chandef = local->monitor_chandef; // copy current chandef
>                 chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
>                 chandef.center_freq1 = 5180; // set center freq...
>                 ieee80211_set_monitor_channel(wiphy, &chandef);
>                 rtnl_unlock();
>
> /********************************************************/

If my understanding is correct you're doing it wrong.

You probably want to modify chanctx of a vif the frame is associated
with and notify the driver via appropriate mac80211 helpers instead of
the hack above. Remember to get your locking right.


> However, the receiver invokes kernel panic when receives the Action frame.
> As fas as we know, the panic is occurred in ath10k_config_chan of
> ath10k device driver.

The panic printout would be most helpful. My best guess is this
crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
because ar->chandef.chan is NULL. This is probably the case since you
use monitor_chandef which is probably "empty" at the point you invoke
your code.


> To the best our knowledge, our implementation exploits same function
> path of iw command in nl80211, cfg80211, mac80211 and ath10k.
> Moreover, we confirm that the input parameters (wiphy, chandef) in our
> implementation are identical to the parameters used by iw command.
>
> Is there any reason why we cannot change bandwidth?
> Of course, iw command work correctly.

The iw set channel is for monitor interfaces only so trying to make it
work with, e.g. a station interface will bring you pain.


Michał

Re: Change channel bandwidth without iw command

[Okhwan Lee]

Hi,

Thank you for your answer.

> The panic printout would be most helpful. My best guess is this
> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> because ar->chandef.chan is NULL. This is probably the case since you
> use monitor_chandef which is probably "empty" at the point you invoke
> your code.

First, we confirm that ar->chandef.chan is not NULL.
We find out the the error occurs when "wait_for_completion_timeout" is called.
Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
We have no idea about the details of function, but it make waiting
time duration for previous event.
We also test by replacing wait_for_completion_timeout to
wait_for_completion (i.e., it use maximum timeout value)
But the kernel panic is still there.

However, it is not easy to printout the messages when the panic is occurred,
because the system stop (similar to bluescreen in widnows?).
After reboot the system, the log messagess from panic is not recored
in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .

> The iw set channel is for monitor interfaces only so trying to make it
> work with, e.g. a station interface will bring you pain.

We already know about this. So, we test this in monitor mode.

Thank you for your answer.

Sincerely yours,

Okhwan

2014-10-22 19:40 GMT+09:00 Michal Kazior <michal.kazior@tieto.com>:
> On 22 October 2014 12:14, Okhwan Lee <ohlee@mwnl.snu.ac.kr> wrote:
>> Hi,
>>
>> We are trying to implement a protocol to evaluate the performance our
>> algorithm using QCA9880.
>>
>> To implement our protocol, a receiver have to change the bandwidth
>> when a Action frame (what we define) is successfully received.
>> We know that the QCA9880 can change bandwidth by using iw command in
>> monitor mode.
>> So, we use similar function path used by "iw dev set freq ..."
>> When the receiver detects the reception of the Action frame we call
>> "ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:
>>
>> /*************** net/mac80211/rx.c ******************/
>>
>> // receive action frame, change bandwidth 80 -> 20
>>
>>                 rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
>>                 chandef = local->monitor_chandef; // copy current chandef
>>                 chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
>>                 chandef.center_freq1 = 5180; // set center freq...
>>                 ieee80211_set_monitor_channel(wiphy, &chandef);
>>                 rtnl_unlock();
>>
>> /********************************************************/
>
> If my understanding is correct you're doing it wrong.
>
> You probably want to modify chanctx of a vif the frame is associated
> with and notify the driver via appropriate mac80211 helpers instead of
> the hack above. Remember to get your locking right.
>
>
>> However, the receiver invokes kernel panic when receives the Action frame.
>> As fas as we know, the panic is occurred in ath10k_config_chan of
>> ath10k device driver.
>
> The panic printout would be most helpful. My best guess is this
> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> because ar->chandef.chan is NULL. This is probably the case since you
> use monitor_chandef which is probably "empty" at the point you invoke
> your code.
>
>
>> To the best our knowledge, our implementation exploits same function
>> path of iw command in nl80211, cfg80211, mac80211 and ath10k.
>> Moreover, we confirm that the input parameters (wiphy, chandef) in our
>> implementation are identical to the parameters used by iw command.
>>
>> Is there any reason why we cannot change bandwidth?
>> Of course, iw command work correctly.
>
> The iw set channel is for monitor interfaces only so trying to make it
> work with, e.g. a station interface will bring you pain.
>
>
> Michał

Re: Change channel bandwidth without iw command

[Michal Kazior]

On 23 October 2014 08:57, Okhwan Lee <ohlee@mwnl.snu.ac.kr> wrote:
> Hi,
>
> Thank you for your answer.
>
>> The panic printout would be most helpful. My best guess is this
>> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
>> because ar->chandef.chan is NULL. This is probably the case since you
>> use monitor_chandef which is probably "empty" at the point you invoke
>> your code.
>
> First, we confirm that ar->chandef.chan is not NULL.
> We find out the the error occurs when "wait_for_completion_timeout" is called.
> Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
> We have no idea about the details of function, but it make waiting
> time duration for previous event.
> We also test by replacing wait_for_completion_timeout to
> wait_for_completion (i.e., it use maximum timeout value)
> But the kernel panic is still there.
>
> However, it is not easy to printout the messages when the panic is occurred,
> because the system stop (similar to bluescreen in widnows?).
> After reboot the system, the log messagess from panic is not recored
> in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .

Can you at least do a photo of the panic, post it to an image hosting
site and link it, please?


Michał

Re: Change channel bandwidth without iw command

[Okhwan Lee]

 Hi, 

This linked images are the printed error messages when the kernel is in panic. 
http://www.mwnl.snu.ac.kr/~ohlee/1.jpg
http://www.mwnl.snu.ac.kr/~ohlee/2.jpg

Thank you for your help.

Okhwan


--  
Okhwan Lee
Sent with Airmail  

켜짐 2014년 10월 24일 에서 오후 4:49:23, Michal Kazior (michal.kazior@tieto.com(mailto:michal.kazior@tieto.com)) 작성됨:

> On 23 October 2014 08:57, Okhwan Lee wrote:
> > Hi,
> >
> > Thank you for your answer.
> >
> >> The panic printout would be most helpful. My best guess is this
> >> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> >> because ar->chandef.chan is NULL. This is probably the case since you
> >> use monitor_chandef which is probably "empty" at the point you invoke
> >> your code.
> >
> > First, we confirm that ar->chandef.chan is not NULL.
> > We find out the the error occurs when "wait_for_completion_timeout" is called.
> > Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
> > We have no idea about the details of function, but it make waiting
> > time duration for previous event.
> > We also test by replacing wait_for_completion_timeout to
> > wait_for_completion (i.e., it use maximum timeout value)
> > But the kernel panic is still there.
> >
> > However, it is not easy to printout the messages when the panic is occurred,
> > because the system stop (similar to bluescreen in widnows?).
> > After reboot the system, the log messagess from panic is not recored
> > in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .
>  
> Can you at least do a photo of the panic, post it to an image hosting
> site and link it, please?
>  
>  
> Michał

Re: Change channel bandwidth without iw command

[Michal Kazior]

On 24 October 2014 13:30, Okhwan Lee <ohlee@mwnl.snu.ac.kr> wrote:
>  Hi,
>
> This linked images are the printed error messages when the kernel is in panic.
> http://www.mwnl.snu.ac.kr/~ohlee/1.jpg
> http://www.mwnl.snu.ac.kr/~ohlee/2.jpg

Thanks.

Panic doesn't seem to include anything directly related to ath10k
which suggests this may be some nasty memory corruption issue. You
might want to enable memory debugging when building kernel (Kernel
Hacking) - hopefully it'll get some extra info before the panic.

How did you come to a conclusion that ath10k's monitor vdev stopping
and wait_for_completion_timeout() are involved?


Michał

Re: Change channel bandwidth without iw command

[Okhwan Lee]

 Hi, 

Thanks for your help.

We just disable some functions step by step. 
Then we can conclude that wait_for_completion_timeout makes kernel panic. 
We guess that monitor vdev stopping after reception of a Action frame requires more time than the case when using iw command. 
Instead of wait_for_completion_timeout, we also use alternative function, wait_for_completion (uses maximum timeout value), 
but the panic is still there.

We don’t have the expert on kernel memory debugging from now on. 
We have to study more how to handle it. 

Again, thank you.
 
Okhwan Lee
Sent with Airmail  

켜짐 2014년 10월 24일 에서 오후 8:38:44, Michal Kazior (michal.kazior@tieto.com(mailto:michal.kazior@tieto.com)) 작성됨:

>