cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
PATCH 1/1 cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
The cfg80211_set_freq function now also saves the channel for monitor interfaces.
This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct channel when the channel was switched in monitor mode.
--- net/wireless/chan.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
net/wireless/chan.c +3 -4
@@ -51,9 +51,6 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,struct ieee80211_channel *chan;int result; -if (wdev && wdev->iftype ==NL80211_IFTYPE_MONITOR ) - wdev =NULL ; -if (wdev) {ASSERT_WDEV_LOCK (wdev);
@@ -69,7 +66,9 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,return -EINVAL ; result = rdev->ops->set_channel (&rdev->wiphy, - wdev ? wdev->netdev :NULL , + wdev && wdev->iftype != +NL80211_IFTYPE_MONITOR ? + wdev->netdev :NULL , chan, channel_type);if (result)return result;
Signature · 1 line
1.6.3.3
Quoted 25 lines · David Gnedt
The
cfg80211_set_freqfunction now also saves the channel for monitor interfaces.
This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct channel when the channel was switched in monitor mode.Signed-off-by David Gnedt <[email protected]>---
net/wireless/chan.c | 7 +++----1 files changed, 3 insertions(+), 4 deletions(-)net/wireless/chan.c +0
-3@@ -51,9 +51,6 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev, struct ieee80211_channel *chan; int result; - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) - wdev = NULL; - if (wdev) { ASSERT_WDEV_LOCK(wdev);
net/wireless/chan.c int cfg80211_set_freq(struct cfg80211_registered_device *rdev, · line 71
Quoted 7 lines
net/wireless/chan.c +3
-1@@ -69,7 +66,9 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev, return -EINVAL; result = rdev->ops->set_channel(&rdev->wiphy, - wdev ? wdev->netdev : NULL, + wdev && wdev->iftype != + NL80211_IFTYPE_MONITOR ? + wdev->netdev : NULL,
Just out of curiosity: why is it important to pass NULL as netdev for monitor interfaces?
Quoted 11 lines
net/wireless/chan.c +0
-1chan, channel_type); if (result) return result; --1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Johannes Berg
maintainerQuoted 4 lines · David Gnedt
The
cfg80211_set_freqfunction now also saves the channel for monitor interfaces.
This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct channel when the channel was switched in monitor mode.
This is still wrong, as discussed previously on this list.
johannes
Quoted 10 lines · Johannes Berg
Quoted 4 lines · David Gnedt
The
cfg80211_set_freqfunction now also saves the channel for monitor interfaces.
This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct channel when the channel was switched in monitor mode.This is still wrong, as discussed previously on this list.
johannes
And the conclusion was... ?
(BTW, I say that a GIWFREQ on a monitor interface should always return the channel the PHY is tuned to at the moment when it is issued. Most tools seem to expect this behavior.)
Am 2010-07-19 23:06, schrieb Gábor Stefanik:
Quoted 3 lines
(BTW, I say that a GIWFREQ on a monitor interface should always return the channel the PHY is tuned to at the moment when it is issued. Most tools seem to expect this behavior.)
I agree, that would be the expected behaviour.
I am not very familar with the entire wireless subsystem yet, but wouldn't that imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
Because if the card is hopping channels (e.g. because of 2 station interfaces on different channels), only the driver itself can tell what's really the current channel.
Nevertheless a default implementation for this new "get_channel" can be written at mac80211 level (or even cfg80211?), which tries to find the current channel by looking at all virtual interfaces, so only mac80211 drivers which allow multiple channels (and non-mac80211 drivers) need to implement it.
Regards,
David
Johannes Berg
maintainerQuoted 9 lines · David Gnedt
Am 2010-07-19 23:06, schrieb Gábor Stefanik:
Quoted 3 lines
(BTW, I say that a GIWFREQ on a monitor interface should always return the channel the PHY is tuned to at the moment when it is issued. Most tools seem to expect this behavior.)
I agree, that would be the expected behaviour.
I am not very familar with the entire wireless subsystem yet, but wouldn't that imply a interface change in cfg80211 and mac80211 to add an "
get_channel" function?
Yes, I think so.
Quoted 3 lines
Because if the card is hopping channels (e.g. because of 2 station interfaces on different channels), only the driver itself can tell what's really the current channel.
Right. Although in that case I'm not sure we should be telling userspace what channel the monitor interface is on, since there's no single channel it is on, and I certainly hope userspace won't be requesting the channel many times per second!
Quoted 4 lines
Nevertheless a default implementation for this new "
get_channel" can be written at mac80211 level (or even cfg80211?), which tries to find the current channel by looking at all virtual interfaces, so only mac80211 drivers which allow multiple channels (and non-mac80211 drivers) need to implement it.
Indeed, but I think mac80211 would be more appropriate than cfg80211 since the latter won't really have all the information unless it makes a whole bunch of assumptions that we'll eventually have to reconsider.
johannes
Quoted 13 lines · Johannes Berg
Quoted 9 lines · David Gnedt
Am 2010-07-19 23:06, schrieb Gábor Stefanik:
Quoted 3 lines
(BTW, I say that a GIWFREQ on a monitor interface should always return the channel the PHY is tuned to at the moment when it is issued. Most tools seem to expect this behavior.)
I agree, that would be the expected behaviour.
I am not very familar with the entire wireless subsystem yet, but wouldn't that imply a interface change in cfg80211 and mac80211 to add an "
get_channel" function?Yes, I think so.
Quoted 8 lines
Quoted 3 lines
Because if the card is hopping channels (e.g. because of 2 station interfaces on different channels), only the driver itself can tell what's really the current channel.
Right. Although in that case I'm not sure we should be telling userspace what channel the monitor interface is on, since there's no single channel it is on, and I certainly hope userspace won't be requesting the channel many times per second!
Well, there is no reason why channel-hopping due to multiple virtual PHYs and channel-hopping by userspace control (see Kismet) should behave differently GIWFREQ-wise. Also, userspace (apart from maybe hostapd - I haven't looked into that at all) seems to expect GIWFREQ on a monitor interface to unconditionally return the channel the radio is tuned to at the moment.
Quoted 13 lines
Quoted 5 lines
Nevertheless a default implementation for this new "
get_channel" can be written at mac80211 level (or even cfg80211?), which tries to find the current channel by looking at all virtual interfaces, so only mac80211 drivers which allow multiple channels (and non-mac80211 drivers) need to implement it.Indeed, but I think mac80211 would be more appropriate than cfg80211 since the latter won't really have all the information unless it makes a whole bunch of assumptions that we'll eventually have to reconsider.
johannes
Signature · 1 line
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)