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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Michal Kazior]

Post by 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 nl8=

0211

Post by Okhwan Lee
chandef =3D local->monitor_chandef; // copy current c=

handef

Post by Okhwan Lee
chandef.width =3D NL80211_CHAN_WIDTH_20; // set bandw=

idth

Post by Okhwan Lee
chandef.center_freq1 =3D 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.

Post by Okhwan Lee
However, the receiver invokes kernel panic when receives the Action f=

rame.

Post by Okhwan Lee
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.

Post by Okhwan Lee
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 ou=

r

Post by Okhwan Lee
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=C5=82
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Okhwan Lee]

Hi,

Thank you for your answer.

Post by Michal Kazior
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.

=46irst, 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 set=
ting.
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 occu=
rred,
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) .

Post by Michal Kazior
The iw set channel is for monitor interfaces only so trying to make i=

t

Post by Michal Kazior
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

Post by Michal Kazior

Hi,
We are trying to implement a protocol to evaluate the performance ou=

r

Post by Michal Kazior

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 follow=
/*************** net/mac80211/rx.c ******************/
// receive action frame, change bandwidth 80 -> 20
rtnl_lock(); //lock rtnetlink used in pre_doit of nl=

80211

Post by Michal Kazior

chandef =3D local->monitor_chandef; // copy current =

chandef

Post by Michal Kazior

chandef.width =3D NL80211_CHAN_WIDTH_20; // set band=

width

Post by Michal Kazior

chandef.center_freq1 =3D 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 o=

f

Post by Michal Kazior
the hack above. Remember to get your locking right.

However, the receiver invokes kernel panic when receives the Action =

frame.

Post by Michal Kazior

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 o=

ur

Post by Michal Kazior

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 i=

t

Post by Michal Kazior
work with, e.g. a station interface will bring you pain.
Micha=C5=82

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html