* [RFC PATCHv5] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 11:00 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 14 ++++++++++
net/mac80211/driver-ops.h | 17 ++++++++++++
net/mac80211/driver-trace.h | 25 ++++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..69f0a63 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,53 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +659,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +702,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* Re: new bluetooth id for lenovo T410s?
From: Marcel Holtmann @ 2010-05-27 10:47 UTC (permalink / raw)
To: Martin Vogt; +Cc: linux-wireless
In-Reply-To: <4BFE4124.2090601@itwm.fraunhofer.de>
Hi Martin,
so first of all, this is the wrong mailing list. You should be using
linux-bluetooth@vger.kernel.org.
> I have a new Lenovo T410s with the compat-wireless package for 2.6.34.
>
> My bluetooh chip seems not to work:
>
> linux-4box:~ # lsusb | grep Broadcom
> Bus 001 Device 005: ID 0a5c:217f Broadcom Corp.
>
> This device id (from lsub) is missing in ./drivers/bluetooth/btusb.c:
>
> /* IBM/Lenovo ThinkPad with Broadcom chip */
> { USB_DEVICE(0x0a5c, 0x201e), .driver_info = BTUSB_WRONG_SCO_MTU },
> { USB_DEVICE(0x0a5c, 0x2110), .driver_info = BTUSB_WRONG_SCO_MTU },
Please send in the output of /proc/bus/usb/devices for your devices
since I doubt it is not supported. There are general interface
descriptors that make the devices work. Only if Lenovo screwed something
up, then this is needed.
Regards
Marcel
^ permalink raw reply
* new bluetooth id for lenovo T410s?
From: Martin Vogt @ 2010-05-27 9:53 UTC (permalink / raw)
To: linux-wireless
Hello,
I have a new Lenovo T410s with the compat-wireless package for 2.6.34.
My bluetooh chip seems not to work:
linux-4box:~ # lsusb | grep Broadcom
Bus 001 Device 005: ID 0a5c:217f Broadcom Corp.
This device id (from lsub) is missing in ./drivers/bluetooth/btusb.c:
/* IBM/Lenovo ThinkPad with Broadcom chip */
{ USB_DEVICE(0x0a5c, 0x201e), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x2110), .driver_info = BTUSB_WRONG_SCO_MTU },
Most likely the T410s has this chip onboard:
Broadcom Model: BCM2045B (BDC-2).
But I haven't found any resources on the lenovo pages about that.
Only this:
http://www.thinkwiki.org/wiki/ThinkPad_Bluetooth_with_Enhanced_Data_Rate_(BDC-2.1)
Do you think I should add the ids to btusb.c?
+{ USB_DEVICE(0x0a5c, 0x217f), .driver_info = BTUSB_WRONG_SCO_MTU },
and test it?
regards,
Martin
^ permalink raw reply
* Re: [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth
From: Johannes Berg @ 2010-05-27 9:27 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274950081.20619.18.camel@paavo-desktop>
On Thu, 2010-05-27 at 11:48 +0300, Teemu Paasikivi wrote:
> On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> > On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > > authentication message was not found from the authtry_bsses table.
> > >
> > > During the beginning of the authentication there is a small time window, when
> > > handling of the received deauthentication message can cause information
> > > for the access point to be removed from the authtry_bsses table before
> > > authentication response is received. This triggers the warning. This has
> > > been seen happening with several access points occasionally. At least
> > > one of those (Asus) has been seen to send spurious deauthentication
> > > messages after deauthentication. Possibly this warning could be triggered also
> > > by forged deauthentication messages sent at a correct time.
> >
> > This doesn't seem right. Why is mac80211 not preventing those messages
> > from bubbling up in that case?
> >
> > FWIW, this check is there for a reason -- we want to avoid telling
> > userspace twice that we disconnected from a given AP, and we shouldn't
> > be processing it anyway.
> Normally, when the stack in the idle state, or connected to other access
> point, those deauth messages doesn't cause a problem. The problem arises
> if that spurious deauth message is received at the right moment, when
> authentication to the access point has been started but response is not
> yet received. If I'm correct in that the deauthentication message from
> the AP during authentication is legal, this would be quite hard to
> filter out.
Yes .. I understand the scenario. You don't want to filter it out, you
want to abort the authentication so you kill the work for it and never
send the timeout to cfg80211.
johannes
^ permalink raw reply
* Re: [RFC PATCHv4] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-27 9:24 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274951799-18615-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, 2010-05-27 at 12:16 +0300, Juuso Oikarinen wrote:
> +static int ieee80211_ifa_changed(struct notifier_block *nb,
> + unsigned long data, void *arg)
> +{
> + struct in_ifaddr *ifa = arg;
> + struct ieee80211_local *local =
> + container_of(nb, struct ieee80211_local,
> + ifa_notifier);
> + struct net_device *ndev = ifa->ifa_dev->dev;
> + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> + struct ieee80211_sub_if_data *sdata;
> + struct ieee80211_if_managed *ifmgd;
> +
> + /* Make sure it's our interface that got changed */
> + if (!wdev)
> + return NOTIFY_DONE;
> +
> + if (wdev->wiphy != local->hw.wiphy)
> + return NOTIFY_DONE;
> +
> + /* We are concerned about IP addresses only when associated */
> + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> + ifmgd = &sdata->u.mgd;
> + mutex_lock(&ifmgd->mtx);
> + if (ifmgd->associated)
> + ieee80211_set_arp_filter(sdata);
> + mutex_unlock(&ifmgd->mtx);
> +
> + return NOTIFY_DONE;
> +}
Still broken, you misunderstood my comment.
johannes
^ permalink raw reply
* Re: [RFC PATCHv3] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-27 9:17 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274951117.5277.3155.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-05-27 at 12:05 +0300, Juuso Oikarinen wrote:
> > > + /* We are concerned about IP addresses only when associated */
> > > + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> > > + mutex_lock(&sdata->u.mgd.mtx);
> > > + ifmgd = &sdata->u.mgd;
> > > + if (ifmgd->associated)
> > > + ieee80211_set_arp_filter(sdata);
> > > + mutex_unlock(&sdata->u.mgd.mtx);
> >
> > I'm sure this will fail in interesting ways since nothing guarantees
> > that this interface is in managed mode.
>
> S***, I need a vacation. This is bound to fail even if the interface is
> in managed mode, as it's not protecting the right thing.
>
> I was already looking at the ifmgd->mtx but somehow managed to
> copy-paste this one :(
Hm? If you bail out on non-managed or something like that, it should be
fine? ifmgd->mtx is the same as sdata->u.mgd.mtx, you just don't need
the ifmgd variable here.
johannes
^ permalink raw reply
* [RFC PATCHv4] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 9:16 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 14 ++++++++++
net/mac80211/driver-ops.h | 17 ++++++++++++
net/mac80211/driver-trace.h | 25 ++++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..69f0a63 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,53 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +659,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +702,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC PATCHv3] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 9:05 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274948667.3669.19.camel@jlt3.sipsolutions.net>
On Thu, 2010-05-27 at 10:24 +0200, ext Johannes Berg wrote:
> On Thu, 2010-05-27 at 09:04 +0300, Juuso Oikarinen wrote:
>
> > +static int ieee80211_ifa_changed(struct notifier_block *nb,
> > + unsigned long data, void *arg)
> > +{
> > + struct in_ifaddr *ifa = arg;
> > + struct ieee80211_local *local =
> > + container_of(nb, struct ieee80211_local,
> > + ifa_notifier);
> > + struct net_device *ndev = ifa->ifa_dev->dev;
> > + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> > + struct ieee80211_sub_if_data *sdata;
> > + struct ieee80211_if_managed *ifmgd;
> > +
> > + /* Make sure it's our interface that got changed */
> > + if (!wdev)
> > + return NOTIFY_DONE;
> > +
> > + if (wdev->wiphy != local->hw.wiphy)
> > + return NOTIFY_DONE;
> > +
> > + /* We are concerned about IP addresses only when associated */
> > + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> > + mutex_lock(&sdata->u.mgd.mtx);
> > + ifmgd = &sdata->u.mgd;
> > + if (ifmgd->associated)
> > + ieee80211_set_arp_filter(sdata);
> > + mutex_unlock(&sdata->u.mgd.mtx);
>
> I'm sure this will fail in interesting ways since nothing guarantees
> that this interface is in managed mode.
S***, I need a vacation. This is bound to fail even if the interface is
in managed mode, as it's not protecting the right thing.
I was already looking at the ifmgd->mtx but somehow managed to
copy-paste this one :(
-Juuso
> johannes
>
^ permalink raw reply
* Re: [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth
From: Teemu Paasikivi @ 2010-05-27 8:48 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274872877.3658.4.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > authentication message was not found from the authtry_bsses table.
> >
> > During the beginning of the authentication there is a small time window, when
> > handling of the received deauthentication message can cause information
> > for the access point to be removed from the authtry_bsses table before
> > authentication response is received. This triggers the warning. This has
> > been seen happening with several access points occasionally. At least
> > one of those (Asus) has been seen to send spurious deauthentication
> > messages after deauthentication. Possibly this warning could be triggered also
> > by forged deauthentication messages sent at a correct time.
>
> This doesn't seem right. Why is mac80211 not preventing those messages
> from bubbling up in that case?
>
> FWIW, this check is there for a reason -- we want to avoid telling
> userspace twice that we disconnected from a given AP, and we shouldn't
> be processing it anyway.
>
> johannes
>
Normally, when the stack in the idle state, or connected to other access
point, those deauth messages doesn't cause a problem. The problem arises
if that spurious deauth message is received at the right moment, when
authentication to the access point has been started but response is not
yet received. If I'm correct in that the deauthentication message from
the AP during authentication is legal, this would be quite hard to
filter out.
Best regards,
Teemu
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-27 8:28 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274947895.3669.16.camel@jlt3.sipsolutions.net>
On Thu, 2010-05-27 at 10:11 +0200, ext Johannes Berg wrote:
> On Thu, 2010-05-27 at 08:06 +0300, Juuso Oikarinen wrote:
> > On Wed, 2010-05-26 at 16:14 +0200, ext Johannes Berg wrote:
> > > TBD
> > >
> > > Needs to be split up (setting bss_conf and the bss_change flag is a
> > > separate bugfix) and tested but this is what I think it should be like.
> >
> > Yes, I think this would work. Are you planning on working on this patch?
>
> No.
Okay, I'll take the patch and work it further.
-Juuso
> johannes
>
^ permalink raw reply
* Re: [RFC PATCHv3] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-27 8:24 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274940287-18980-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, 2010-05-27 at 09:04 +0300, Juuso Oikarinen wrote:
> +static int ieee80211_ifa_changed(struct notifier_block *nb,
> + unsigned long data, void *arg)
> +{
> + struct in_ifaddr *ifa = arg;
> + struct ieee80211_local *local =
> + container_of(nb, struct ieee80211_local,
> + ifa_notifier);
> + struct net_device *ndev = ifa->ifa_dev->dev;
> + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> + struct ieee80211_sub_if_data *sdata;
> + struct ieee80211_if_managed *ifmgd;
> +
> + /* Make sure it's our interface that got changed */
> + if (!wdev)
> + return NOTIFY_DONE;
> +
> + if (wdev->wiphy != local->hw.wiphy)
> + return NOTIFY_DONE;
> +
> + /* We are concerned about IP addresses only when associated */
> + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> + mutex_lock(&sdata->u.mgd.mtx);
> + ifmgd = &sdata->u.mgd;
> + if (ifmgd->associated)
> + ieee80211_set_arp_filter(sdata);
> + mutex_unlock(&sdata->u.mgd.mtx);
I'm sure this will fail in interesting ways since nothing guarantees
that this interface is in managed mode.
johannes
^ permalink raw reply
* A mailing list for regulatory wireless-regdb changes
From: Luis R. Rodriguez @ 2010-05-27 8:15 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-wireless, Michael Green, David Quan, Emmanuel Grumbach,
John W. Linville
David, can I trouble you for a mailman wireless-regdb mailing list on
infradead.org? This would be used by those who are not developers and
do not need to be subscribed to linux-wireless. An example are
regulatory guys at different companies and generally interested
people/developers on the topic. This should hopefully accelerate the
turn around time for reviewing of patches and also a good placeholder
for us to go back and check the discussions that went on about this.
Luis
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-27 8:12 UTC (permalink / raw)
To: Bruno Randolf
Cc: Juuso Oikarinen, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <201005270941.30654.br1@einfach.org>
On Thu, 2010-05-27 at 09:41 +0900, Bruno Randolf wrote:
> > + } else {
> > + /*
> > + * If no rates were explicitly configured,
> > + * use the mandatory rate set for 11b or
> > + * 11a for maximum compatibility.
> > + */
> > + struct ieee80211_supported_band *sband =
> > + wiphy->bands[ibss.channel->band];
> > + int j;
> > + u32 flag = ibss.channel->band == IEEE80211_BAND_5GHZ ?
> > + IEEE80211_RATE_MANDATORY_A :
> > + IEEE80211_RATE_MANDATORY_B;
> > +
> > + for (j = 0; j < sband->n_bitrates; j++) {
> > + if (sband->bitrates[j].flags & flag)
> > + ibss.basic_rates |= j;
> > + }
> > + }
>
> couldn't we use ieee80211_mandatory_rates() here?
Yeah, but it would have to migrate to cfg80211.
johannes
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-27 8:11 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274936780.5277.2879.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-05-27 at 08:06 +0300, Juuso Oikarinen wrote:
> On Wed, 2010-05-26 at 16:14 +0200, ext Johannes Berg wrote:
> > TBD
> >
> > Needs to be split up (setting bss_conf and the bss_change flag is a
> > separate bugfix) and tested but this is what I think it should be like.
>
> Yes, I think this would work. Are you planning on working on this patch?
No.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Johannes Berg @ 2010-05-27 8:11 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, juuso.oikarinen, ath5k-devel, linux-wireless
In-Reply-To: <1274947716.3669.13.camel@jlt3.sipsolutions.net>
On Thu, 2010-05-27 at 10:08 +0200, Johannes Berg wrote:
> On Thu, 2010-05-27 at 09:45 +0900, Bruno Randolf wrote:
> > IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5 & 11 Mbits are
> > mandatory rates for what they call High Rate direct sequence spread spectrum
> > (HR/DSSS) PHY (with long PLCP).
>
> You're confused. Clause 18 is 11g, we knew that those were mandatory
> there, see the code you're modifying.
>
> Clause 15 is 11b, and it shouldn't change.
No wait, I'm confused. Clause 19 is 11g, and Clause 18 is 11b. But
what's Clause 15? Huh now I need to look back at this in more detail.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Johannes Berg @ 2010-05-27 8:08 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, juuso.oikarinen, ath5k-devel, linux-wireless
In-Reply-To: <20100527004545.11541.88667.stgit@tt-desk>
On Thu, 2010-05-27 at 09:45 +0900, Bruno Randolf wrote:
> IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5 & 11 Mbits are
> mandatory rates for what they call High Rate direct sequence spread spectrum
> (HR/DSSS) PHY (with long PLCP).
You're confused. Clause 18 is 11g, we knew that those were mandatory
there, see the code you're modifying.
Clause 15 is 11b, and it shouldn't change.
So NACK.
johannes
^ permalink raw reply
* [PATCH] libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
From: Sascha Silbe @ 2010-05-23 8:03 UTC (permalink / raw)
To: linux-wireless
This patch fixes the libertas driver incorrectly reporting that Wake-on-LAN
is not supported if Wake-on-LAN is currently disabled.
---
drivers/net/wireless/libertas/ethtool.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
Without patch:
root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: d
Wake-on: d
root@xo15-minimal:~# ethtool -s wlan0 wol pum
root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: pumb
Wake-on: pum
root@xo15-minimal:~# ethtool -s wlan0 wol d
root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: d
Wake-on: d
root@xo15-minimal:~#
With patch:
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: d
xo-sascha:~# ethtool -s eth0 wol pum
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: pum
xo-sascha:~# ethtool -s eth0 wol d
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: d
diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 6eb9a88..4a337b7 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -145,14 +145,11 @@ static void lbs_ethtool_get_wol(struct net_device *dev,
{
struct lbs_private *priv = dev->ml_priv;
- if (priv->wol_criteria == 0xffffffff) {
- /* Interface driver didn't configure wake */
- wol->supported = wol->wolopts = 0;
- return;
- }
-
wol->supported = WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY;
+ if (priv->wol_criteria == EHS_REMOVE_WAKEUP)
+ return;
+
if (priv->wol_criteria & EHS_WAKE_ON_UNICAST_DATA)
wol->wolopts |= WAKE_UCAST;
if (priv->wol_criteria & EHS_WAKE_ON_MULTICAST_DATA)
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-27 6:17 UTC (permalink / raw)
To: ext Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinPO1vuErc3GgDHWJ2rdG_9Sfd5WqCuvnj3DfMl@mail.gmail.com>
On Wed, 2010-05-26 at 18:46 +0200, ext Luis R. Rodriguez wrote:
> On Tue, May 25, 2010 at 10:08 PM, Juuso Oikarinen
> <juuso.oikarinen@nokia.com> wrote:
> > On Tue, 2010-05-25 at 21:02 +0200, ext Luis R. Rodriguez wrote:
> >> On Mon, May 24, 2010 at 11:50 PM, Juuso Oikarinen
> >> <juuso.oikarinen@nokia.com> wrote:
> >> > The userspace crda utility can fail to respond to kernel requests in (at least)
> >> > two scenarios: it is not runnable for any reason, or it is invoked with a
> >> > country code not in its database.
> >> >
> >> > When the userspace crda utility fails to respond to kernel requests (i.e. it
> >> > does not use NL80211_CMD_SET_REG to provide the kernel regulatory information
> >> > for the requested country) the kernel crda subsystem will stall. It will
> >> > refuse to process any further regulatory hints. This is easiest demonstrated
> >> > by using for instance the "iw" tool:
> >> >
> >> > iw reg set EU
> >> > iw reg set US
> >> >
> >> > "EU" is not a country code present in the database, so user space crda will
> >> > not respond. Attempting to define US after that will be silently ignored
> >> > (internally, an -EAGAIN is the result, as the "EU" request is still
> >> > "being processed".)
> >> >
> >> > To fix this issue, this patch implements timeout protection for the userspace
> >> > crda invocation. If there is no response for five seconds, the crda code will
> >> > force itself to the world regulatory domain for maximum safety.
> >> >
> >> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> >>
> >> This is a great idea, I really like it and appreciate you taking the
> >> time to work on this, however to do this it requires a little more
> >> work and will point out the notes below. So NACK for now but with some
> >> fixes I think this would be great.
> >>
> >> > ---
> >> > net/wireless/reg.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> >> > 1 files changed, 44 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> >> > index 8f0d97d..6c945f0 100644
> >> > --- a/net/wireless/reg.c
> >> > +++ b/net/wireless/reg.c
> >> > @@ -385,6 +385,40 @@ static inline void reg_regdb_query(const char *alpha2) {}
> >> > #endif /* CONFIG_CFG80211_INTERNAL_REGDB */
> >> >
> >> > /*
> >> > + * This gets invoked if crda in userspace is not responding (it's not getting
> >> > + * executed or the country code in the hint is not in the database.
> >> > + */
> >> > +
> >> > +static void call_crda_timeout_work(struct work_struct *work)
> >> > +{
> >> > + if (!last_request)
> >> > + return;
> >> > +
> >> > + printk(KERN_INFO "cfg80211: crda request timed out, reverting to 00\n");
> >> > +
> >> > + mutex_lock(&cfg80211_mutex);
> >> > +
> >> > + /*
> >> > + * As we are not getting data for the current country, force us back
> >> > + * to the world regdomain.
> >> > + */
> >> > + last_request->alpha2[0] = '0';
> >> > + last_request->alpha2[1] = '0';
> >> > + set_regdom(cfg80211_world_regdom);
> >> > + mutex_unlock(&cfg80211_mutex);
> >> > +}
> >>
> >>
> >> Actually you may want to consider using restore_regulatory_settings()
> >> instead as that would:
> >>
> >> * set the world regdom
> >> * then set the first user specified regulatory domain if they had one picked
> >>
> >> This would mean we would go into a loop here though if the user had
> >> specified 'EU' though so this routine first needs to be fixed to
> >> annotate a regulatory domain as invalid. Note that a regulatory cannot
> >> be invalid if CRDA just times out -- CRDA could time out if it was not
> >> present. So this is a bit tricky and not sure how to resolve it. John
> >> recently added support for building the regulatory database as part of
> >> the kernel but at the same time support letting CRDA still update the
> >> same info if it is present. Then for those setup it could be possible
> >> 'DE' exists on the core kernel regulatory database but if CRDA is not
> >> installed then CRDA will time out.
> >>
> >> Maybe what we can do is if both the internal kernel regdb *and* CRDA
> >> times out then mark the user specified request as invalid and restore
> >> to using the world regdom. This would allow the user to later install
> >> a CRDA with some newer regdb in userspace, for example. This allows
> >> for upgrading the db itself from userspace without making kernel
> >> changes. It allows for countries to be created.
> >
> > Sounds fair. Here's my initial thought:
> >
> > I will look into adding validation of the country code with the kernel
> > internal database if the db is enabled in the config - in which case we
> > proceed as you describe. In case the internal db is disabled in the
> > config, we proceed as the patch currently does?
> >
> > Would that sound like an acceptable approach?
>
> The first part yes, the second part no. You want to still do the
> restore of the regdomains, that routine already does most of the work
> you need to do except sanity checking in case the data the user
> submitted is bogus/invalid.
Ok.
As you say, currently the restore function will cause a loop, if the
user space CRDA is not available to run, as the function will invoke it
again.
Validating the country code is not easy without the kernel built-in
database, I'll need to think about another way of handling this
scenario.
I'll think about it and come back later.
-Juuso
>
> Luis
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCHv3] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 6:04 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 14 ++++++++++
net/mac80211/driver-ops.h | 17 ++++++++++++
net/mac80211/driver-trace.h | 25 ++++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..58e744b 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,53 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ mutex_lock(&sdata->u.mgd.mtx);
+ ifmgd = &sdata->u.mgd;
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&sdata->u.mgd.mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +659,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +702,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Benoit Papillault @ 2010-05-27 6:02 UTC (permalink / raw)
To: Bruno Randolf
Cc: linville, juuso.oikarinen, johannes, ath5k-devel, linux-wireless
In-Reply-To: <20100527004545.11541.88667.stgit@tt-desk>
Le 27/05/2010 02:45, Bruno Randolf a écrit :
> IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5& 11 Mbits are
> mandatory rates for what they call High Rate direct sequence spread spectrum
> (HR/DSSS) PHY (with long PLCP).
>
> Signed-off-by: Bruno Randolf<br1@einfach.org>
> ---
> net/wireless/util.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index 3416373..f6f4101 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -100,17 +100,17 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband,
> case IEEE80211_BAND_2GHZ:
> want = 7;
> for (i = 0; i< sband->n_bitrates; i++) {
> - if (sband->bitrates[i].bitrate == 10) {
> + if (sband->bitrates[i].bitrate == 10 ||
> + sband->bitrates[i].bitrate == 20 ||
> + sband->bitrates[i].bitrate == 55 ||
> + sband->bitrates[i].bitrate == 110) {
> sband->bitrates[i].flags |=
> IEEE80211_RATE_MANDATORY_B |
> IEEE80211_RATE_MANDATORY_G;
> want--;
> }
>
> - if (sband->bitrates[i].bitrate == 20 ||
> - sband->bitrates[i].bitrate == 55 ||
> - sband->bitrates[i].bitrate == 110 ||
> - sband->bitrates[i].bitrate == 60 ||
> + if (sband->bitrates[i].bitrate == 60 ||
> sband->bitrates[i].bitrate == 120 ||
> sband->bitrates[i].bitrate == 240) {
> sband->bitrates[i].flags |=
> @@ -125,7 +125,7 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband,
> sband->bitrates[i].flags |=
> IEEE80211_RATE_ERP_G;
> }
> - WARN_ON(want != 0&& want != 3&& want != 6);
> + WARN_ON(want != 0&& want != 3);
> break;
> case IEEE80211_NUM_BANDS:
> WARN_ON(1);
>
Acked-by: Benoit Papillault <benoit.papillault@free.fr>
Regards,
Benoit
^ permalink raw reply
* Re: [RFC PATCHv2] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 5:36 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274878321.3658.7.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 14:52 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 15:51 +0300, Juuso Oikarinen wrote:
>
> > > > + rtnl_lock();
> > > > + ieee80211_set_arp_filter(sdata);
> > > > + rtnl_unlock();
> > > > +
> > >
> > > Please analyse locking in more detail and enable lockdep :)
> > >
> > > This will cause deadlocks.
> >
> > I have lockdep permanently enabled in my development kernel. It has
> > given me no complaints in testing with the corresponding wl1271 driver
> > patch.
> >
> > But I will look into those locks further if I can figure out any
> > deadlock scenarios.
>
> Interesting .. because for sure a lot of the ieee80211_mgd_* functions
> are called with rtnl held and lock the mgd mutex, but it is the other
> way around here.
You are right. There are at least some paths where mgd mutex is locked
with rtnl held, so there is a risk of deadlock. This has not occurred in
my limited testing, but is certainly possible, and obviously we should
always do locking in the same order.
I'll have to see if I can move this notification outside the mgd lock,
and if I can't, I'll have to use a workqueue function.
-Juuso
> johannes
>
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-27 5:06 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274883276.3658.15.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 16:14 +0200, ext Johannes Berg wrote:
> TBD
>
> Needs to be split up (setting bss_conf and the bss_change flag is a
> separate bugfix) and tested but this is what I think it should be like.
Yes, I think this would work. Are you planning on working on this patch?
-Juuso
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> include/net/cfg80211.h | 2 +
> net/mac80211/ibss.c | 5 +++-
> net/mac80211/ieee80211_i.h | 2 +
> net/wireless/nl80211.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 55 insertions(+), 1 deletion(-)
>
> --- wireless-testing.orig/include/net/cfg80211.h 2010-05-26 15:43:20.000000000 +0200
> +++ wireless-testing/include/net/cfg80211.h 2010-05-26 15:43:54.000000000 +0200
> @@ -801,6 +801,7 @@ struct cfg80211_disassoc_request {
> * @beacon_interval: beacon interval to use
> * @privacy: this is a protected network, keys will be configured
> * after joining
> + * @basic_rates: bitmap of basic rates to use when creating the IBSS
> */
> struct cfg80211_ibss_params {
> u8 *ssid;
> @@ -809,6 +810,7 @@ struct cfg80211_ibss_params {
> u8 *ie;
> u8 ssid_len, ie_len;
> u16 beacon_interval;
> + u32 basic_rates;
> bool channel_fixed;
> bool privacy;
> };
> --- wireless-testing.orig/net/wireless/nl80211.c 2010-05-26 15:46:01.000000000 +0200
> +++ wireless-testing/net/wireless/nl80211.c 2010-05-26 16:08:28.000000000 +0200
> @@ -3955,6 +3955,53 @@ static int nl80211_join_ibss(struct sk_b
> }
> }
>
> + if (info->attrs[NL80211_ATTR_BSS_BASIC_RATES]) {
> + u8 *rates = nla_data(info->attrs[NL80211_ATTR_BSS_BASIC_RATES]);
> + int n_rates = nla_len(info->attrs[NL80211_ATTR_BSS_BASIC_RATES]);
> + struct ieee80211_supported_band *sband =
> + wiphy->bands[ibss.channel->band];
> + int i, j;
> +
> + if (n_rates == 0) {
> + err = -EINVAL;
> + goto out;
> + }
> +
> + for (i = 0; i < n_rates; i++) {
> + int rate = (rates[i] & 0x7f) * 5;
> + bool found = false;
> +
> + for (j = 0; j < sband->n_bitrates; j++) {
> + if (sband->bitrates[j].bitrate == rate) {
> + found = true;
> + ibss.basic_rates |= j;
> + break;
> + }
> + }
> + if (!found) {
> + err = -EINVAL;
> + goto out;
> + }
> + }
> + } else {
> + /*
> + * If no rates were explicitly configured,
> + * use the mandatory rate set for 11b or
> + * 11a for maximum compatibility.
> + */
> + struct ieee80211_supported_band *sband =
> + wiphy->bands[ibss.channel->band];
> + int j;
> + u32 flag = ibss.channel->band == IEEE80211_BAND_5GHZ ?
> + IEEE80211_RATE_MANDATORY_A :
> + IEEE80211_RATE_MANDATORY_B;
> +
> + for (j = 0; j < sband->n_bitrates; j++) {
> + if (sband->bitrates[j].flags & flag)
> + ibss.basic_rates |= j;
> + }
> + }
> +
> err = cfg80211_join_ibss(rdev, dev, &ibss, connkeys);
>
> out:
> --- wireless-testing.orig/net/mac80211/ibss.c 2010-05-26 16:09:11.000000000 +0200
> +++ wireless-testing/net/mac80211/ibss.c 2010-05-26 16:12:32.000000000 +0200
> @@ -172,11 +172,13 @@ static void __ieee80211_sta_join_ibss(st
> rcu_assign_pointer(ifibss->presp, skb);
>
> sdata->vif.bss_conf.beacon_int = beacon_int;
> + sdata->vif.bss_conf.basic_rates = basic_rates;
> bss_change = BSS_CHANGED_BEACON_INT;
> bss_change |= ieee80211_reset_erp_info(sdata);
> bss_change |= BSS_CHANGED_BSSID;
> bss_change |= BSS_CHANGED_BEACON;
> bss_change |= BSS_CHANGED_BEACON_ENABLED;
> + bss_change |= BSS_CHANGED_BASIC_RATES;
> bss_change |= BSS_CHANGED_IBSS;
> sdata->vif.bss_conf.ibss_joined = true;
> ieee80211_bss_info_change_notify(sdata, bss_change);
> @@ -529,7 +531,7 @@ static void ieee80211_sta_create_ibss(st
> sdata->drop_unencrypted = 0;
>
> __ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
> - ifibss->channel, 3, /* first two are basic */
> + ifibss->channel, ifibss->basic_rates,
> capability, 0);
> }
>
> @@ -910,6 +912,7 @@ int ieee80211_ibss_join(struct ieee80211
> sdata->u.ibss.fixed_bssid = false;
>
> sdata->u.ibss.privacy = params->privacy;
> + sdata->u.ibss.basic_rates = params->basic_rates;
>
> sdata->vif.bss_conf.beacon_int = params->beacon_interval;
>
> --- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-05-26 16:11:51.000000000 +0200
> +++ wireless-testing/net/mac80211/ieee80211_i.h 2010-05-26 16:12:02.000000000 +0200
> @@ -393,6 +393,8 @@ struct ieee80211_if_ibss {
> unsigned long request;
> unsigned long last_scan_completed;
>
> + u32 basic_rates;
> +
> bool timer_running;
>
> bool fixed_bssid;
>
>
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-27 4:50 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274880434.3658.14.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 15:27 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 16:13 +0300, Juuso Oikarinen wrote:
>
> > > > diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> > > > index b2cc1fd..0b8360c 100644
> > > > --- a/net/mac80211/ibss.c
> > > > +++ b/net/mac80211/ibss.c
> > > > @@ -529,7 +529,8 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
> > > > sdata->drop_unencrypted = 0;
> > > >
> > > > __ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
> > > > - ifibss->channel, 3, /* first two are basic */
> > > > + ifibss->channel,
> > > > + 15, /* 1, 2, 5.5 and 11 are basic */
> > >
> > > It's still wrong for 5 GHz.
> >
> > Yes, it is as wrong for 5GHz as it was before the change.
>
> No it wasn't wrong before the change, and only the comment is now
> wrong ...
>
> before the change, 6 and 9 mbps were basic for 5ghz, now it would be
> 5,9,12 and 18. Neither set actually overlaps with the mandatory rates,
> which is a bug I guess?
Ah, now I get it. So the rate bitmap changes - I had a confusion here.
> > > We've had this discussion before. Making more rates required will break
> > > compatibility with 11b devices.
> >
> > I don't understand this. AFAIK also in 11b all these rates are
> > mandatory. How come this breaks 11b?
>
> No, only 1mbit is really mandatory in 11b. So I guess our default should
> be just "1" rather than "3" or something like that.
That's weird. At least in certification PoV, AFAIK, a device would not
pass with just 1mbit even for 11b.
> > This change is for creating IBSS, not joining. In case of joining, we
> > still adhere to the basic rates set by the creator, or that is what I
> > understand based on the code.
> >
> > > What should be done here is add a basic rates parameter to the IBSS join
> > > nl80211 command so that you can decide at runtime which rates to use as
> > > basic.
> >
> > Yeah, this is a solution needed latest when 5GHz support is implemented.
>
> Well this hopefully doesn't come as a surprise to you, but mac80211 does
> support 5 GHz operation :)
Yeah, I know there is support (even the wl1271 has preliminary) but
there are also some issues ;)
So it seems to me that if we want this fixed, we would have to go with
an interface update?
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite
From: Richard Farina @ 2010-05-27 3:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <1274860275.3658.0.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Wed, 2010-05-26 at 00:54 +0200, Gábor Stefanik wrote:
>
>
>>>> - if (wdev)
>>>> - wdev->channel = chan;
>>>> + wdev = old_wdev;
>>>> + wdev->channel = chan;
>>>>
>>> NACK. That will crash when there really is no interface being passed in.
>>>
>>> johannes
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>> Well, the original version already dereferences wdev in "if
>> (wdev->iftype...", so the crash is nothing new if it exists.
>>
>
> It has also been fixed since.
>
>
Can someone port this patch up so it includes the fix Johannes is
speaking of? Kind of craptastic to have not one but TWO bugs which
completely break monitor mode AND channel hopping. If we fix both at
once we can have a working driver :-) I have plenty of testers standing by.
Thanks,
Rick
> johannes
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Richard Farina @ 2010-05-27 3:49 UTC (permalink / raw)
To: Bob Copeland; +Cc: Gábor Stefanik, Weedy, linux-wireless, Johannes Berg
In-Reply-To: <AANLkTilXJHs8emXX4YNHbPq0SkuC4Z22NEh-T6mwUSHS@mail.gmail.com>
Bob Copeland wrote:
> 2010/5/25 Gábor Stefanik <netrolller.3d@gmail.com>:
>
>> On Tue, May 25, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>
>>>> 2010/5/24 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>
>>>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>>>
>>>>>> 2010/5/23 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>>>
>>>>>>> In the meantime, one thing to test: Add a printk of sc->opmode.
>>>>>>>
>>>>>> May 24 22:04:20 tiny-h4x kernel: [41147.243149] sc->opmode: 02 (over9000 times)
>>>>>>
>>>>>> So i'm guessing I did it wrong (I don't know C).
>>>>>> printk(KERN_NOTICE "sc->opmode: %02x\n", sc->opmode);
>>>>>>
>>>>>>
>>>>> No, that is correct, and proves my theory (2 is NL80211_IFTYPE_STATION
>>>>> - it should be 6 for monitor mode).
>>>>>
>>>>> BTW, please use "Reply to all".
>>>>>
>>>>>
>>>> gmail got rid of the "Reply to all by default" option :<
>>>>
>>>> When you have a patch I will be waiting.
>>>>
>>> Sorry, I missed this thread somehow. Thanks for the detective
>>> work and apologies for my stupid goof. Gábor, are you prepping
>>> a patch? I can fix it if you like.
>>>
>>>
>> If you can, please fix it - I know what the bug is, but have no solid
>> idea about a fix.
>>
>
> Ok, it should be enough to look at the filter flags instead of
> the opmode -- I knew in the back of my mind that the monitor
> stuff was bogus (part of the reason I did the patch in the first
> place) but just got confused by what was already there I guess.
>
>
I've got a lot of people very interested in this fix. Let me know what
kind of support you need to make this happen. You know where to find me
on irc ;-)
Thanks,
Rick
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox