* Re: [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-26 11:19 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274872467.5277.1783.camel@wimaxnb.nmp.nokia.com>
On Wed, 2010-05-26 at 14:14 +0300, Juuso Oikarinen wrote:
> > > +static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
> > > + struct in_ifaddr *ifa_list)
> > > +{
> > > + struct ieee80211_local *local = hw_to_local(hw);
> > > + int ret = 0;
> > > +
> > > + if (local->ops->configure_ip_filter)
> > > + ret = local->ops->configure_ip_filter(hw, ifa_list);
> > > + return ret;
> > > +}
> >
> > Tracing would be nice, you should even able able to trace all addresses
> > in a variable-length array.
> >
>
> I looked into the tracing. I still prefer using the ifa_list directly as
> argument to the driver, and not copy the addresses in it to another
> array.
>
> The ifa_list is a linked list, and does AFAIK does not directly fit into
> the tracing infrasturcture.
>
> Hence I added a trace for this op, but omitted tracing the IP addresses.
Yeah, that's fine ... it later occurred to me that I also left that out
for the multicast list for exactly this reason.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth
From: Johannes Berg @ 2010-05-26 11:21 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linville, linux-wireless
In-Reply-To: <1274870625-19712-1-git-send-email-ext-teemu.3.paasikivi@nokia.com>
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
^ permalink raw reply
* [RFC PATCHv2] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-26 11:29 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 | 56 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 4 +++
6 files changed, 117 insertions(+), 1 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..12e51f0 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,51 @@ 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;
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +657,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 +700,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..15d6b79 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -858,6 +858,10 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
ieee80211_recalc_smps(local, sdata);
mutex_unlock(&local->iflist_mtx);
+ rtnl_lock();
+ ieee80211_set_arp_filter(sdata);
+ rtnl_unlock();
+
netif_tx_start_all_queues(sdata->dev);
netif_carrier_on(sdata->dev);
}
--
1.6.3.3
^ permalink raw reply related
* regulatory problems with ath5k
From: Arnd Hannemann @ 2010-05-26 11:23 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: ath5k-devel@lists.ath5k.org
Hi,
I'm trying to use 802.11a channels in AP mode with my ath5k nics with kernel 2.6.34.
And after setting up crda, udev and wireless regdb, "iw list" still shows flags
"passive scanning, no IBSS" for most of the 802.11a channels (see below.)
I wonder what I'm doing wrong here?
Band 2:
Frequencies:
* 5180 MHz [36] (20.0 dBm) (radar detection)
* 5200 MHz [40] (20.0 dBm) (radar detection)
* 5220 MHz [44] (20.0 dBm) (radar detection)
* 5240 MHz [48] (20.0 dBm) (radar detection)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5500 MHz [100] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5520 MHz [104] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5540 MHz [108] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5560 MHz [112] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5580 MHz [116] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5600 MHz [120] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5620 MHz [124] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5640 MHz [128] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5660 MHz [132] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5680 MHz [136] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5700 MHz [140] (26.0 dBm) (passive scanning, no IBSS, radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
hannemann@mrouter46:~ $ sudo iw reg get
country DE:
(2400 - 2483 @ 40), (N/A, 20)
(5150 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
(5470 - 5725 @ 40), (N/A, 26), NO-OUTDOOR, DFS
dmesg snippet:
May 26 12:10:36 mrouter46 kernel: [ 30.023089] console [netcon0] enabled
May 26 12:10:36 mrouter46 kernel: [ 30.023103] netconsole: network logging started
May 26 12:10:36 mrouter46 kernel: [ 30.314702] cfg80211: Calling CRDA to update world regulatory domain
May 26 12:10:37 mrouter46 kernel: [ 30.555745] ath5k 0000:00:0c.0: registered as \'phy0\'
May 26 12:10:37 mrouter46 kernel: [ 31.039151] ath: EEPROM regdomain: 0x8114
May 26 12:10:37 mrouter46 kernel: [ 31.039168] ath: EEPROM indicates we should expect a country code
May 26 12:10:37 mrouter46 kernel: [ 31.039188] ath: doing EEPROM country->regdmn map search
May 26 12:10:37 mrouter46 kernel: [ 31.039205] ath: country maps to regdmn code: 0x37
May 26 12:10:37 mrouter46 kernel: [ 31.039222] ath: Country alpha2 being used: DE
May 26 12:10:37 mrouter46 kernel: [ 31.039237] ath: Regpair used: 0x37
May 26 12:10:37 mrouter46 kernel: [ 31.054155] cfg80211: World regulatory domain updated:
May 26 12:10:37 mrouter46 kernel: [ 31.054178] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
May 26 12:10:37 mrouter46 kernel: [ 31.054207] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May 26 12:10:37 mrouter46 kernel: [ 31.054232] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
May 26 12:10:37 mrouter46 kernel: [ 31.054258] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
May 26 12:10:37 mrouter46 kernel: [ 31.054284] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May 26 12:10:37 mrouter46 kernel: [ 31.054310] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May 26 12:10:38 mrouter46 kernel: [ 31.212057] phy0: Selected rate control algorithm \'minstrel\'
May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k phy0: RF5112B multiband radio found (0x36)
May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k 0000:00:0e.0: registered as \'phy1\'
May 26 12:10:38 mrouter46 kernel: [ 31.622592] cfg80211: Calling CRDA for country: DE
May 26 12:10:38 mrouter46 kernel: [ 31.688006] cfg80211: Regulatory domain changed to country: DE
May 26 12:10:38 mrouter46 kernel: [ 31.688030] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
May 26 12:10:38 mrouter46 kernel: [ 31.688057] (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
May 26 12:10:38 mrouter46 kernel: [ 31.688080] (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
May 26 12:10:38 mrouter46 kernel: [ 31.688103] (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: EEPROM regdomain: 0x8114
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: EEPROM indicates we should expect a country code
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: doing EEPROM country->regdmn map search
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: country maps to regdmn code: 0x37
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: Country alpha2 being used: DE
May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: Regpair used: 0x37
May 26 12:10:38 mrouter46 kernel: [ 31.758662] phy1: Selected rate control algorithm \'minstrel\'
May 26 12:10:38 mrouter46 kernel: [ 31.759383] ath5k phy1: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
May 26 12:10:38 mrouter46 kernel: [ 31.759383] ath5k phy1: RF5112B multiband radio found (0x36)
Best regards,
Arnd
^ permalink raw reply
* Re: [RFC PATCHv2] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-26 11:52 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274873379-12944-1-git-send-email-juuso.oikarinen@nokia.com>
On Wed, 2010-05-26 at 14:29 +0300, Juuso Oikarinen wrote:
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -858,6 +858,10 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
> ieee80211_recalc_smps(local, sdata);
> mutex_unlock(&local->iflist_mtx);
>
> + rtnl_lock();
> + ieee80211_set_arp_filter(sdata);
> + rtnl_unlock();
> +
Please analyse locking in more detail and enable lockdep :)
This will cause deadlocks.
johannes
^ permalink raw reply
* Is there a bug in 2.6.29-rc8 support of Ad-Hoc mode?
From: Gordon, Charles @ 2010-05-26 11:57 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
I am trying to get a driver I'm developing to work with Ad-Hoc mode on
Linux 2.6.29-rc8. I am running into a problem. I have traced it down
to the routine ieee80211_scan_work. I use the following commands to
start Ad-Hoc mode:
ifconfig wlan0 down
iwconfig wlan0 mode Ad-Hoc essid "AdHocID"
ifconfig wlan0 up
What happens is that the iwconfig command starts a scan for other PCs
using the AdHocID before the second ifconfig command is executed
(while the interface is still down). When ieee80211_scan_work is
executed, it bails out at this statement:
/*
* Avoid re-scheduling when the sdata is going away.
*/
if (!netif_running(sdata->dev))
return;
This aborts the scan, but leaves local->sw_scanning set. This
prevents future scans from running. When ieee80211_start_scan
executes it bails out at this statement:
if (local->sw_scanning || local->hw_scanning) {
if (local->scan_sdata == scan_sdata)
return 0;
return -EBUSY;
}
Can someone either confirm that this is a known problem with
2.6.28-rc8, or tell me what my driver could be doing to cause this
problem?
Thanks for any help you can provide.
^ permalink raw reply
* [PATCH] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-26 12:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 12 need to be marked
basic.
Change this.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/mac80211/ibss.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index b2cc1fd..448cf57 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 12 are basic */
capability, 0);
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-26 12:34 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1274877272-22487-1-git-send-email-juuso.oikarinen@nokia.com>
On Wed, 2010-05-26 at 15:34 +0300, Juuso Oikarinen wrote:
> Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
> ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 12 need to be marked
> basic.
>
> Change this.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> net/mac80211/ibss.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> index b2cc1fd..448cf57 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 12 are basic */
12?
In any case, this is incorrect in 5 GHz (at least the comment is).
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-26 12:42 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274877298.3658.6.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 14:34 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 15:34 +0300, Juuso Oikarinen wrote:
> > Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
> > ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 12 need to be marked
> > basic.
> >
> > Change this.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> > net/mac80211/ibss.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> > index b2cc1fd..448cf57 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 12 are basic */
>
> 12?
>
> In any case, this is incorrect in 5 GHz (at least the comment is).
Damn! The comment has a typo!
I must have a serious brain leak.
-Juuso
> johannes
>
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Bob Copeland @ 2010-05-26 12:43 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Weedy, linux-wireless, Johannes Berg
In-Reply-To: <AANLkTimIeTadyAhUuri2P630mpDwmBk4B90RpERLbaFE@mail.gmail.com>
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.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-26 12:48 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 11 need to be marked
basic.
Change this.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/mac80211/ibss.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
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 */
capability, 0);
}
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC PATCHv2] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-26 12:51 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274874739.3658.5.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 13:52 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 14:29 +0300, Juuso Oikarinen wrote:
>
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -858,6 +858,10 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
> > ieee80211_recalc_smps(local, sdata);
> > mutex_unlock(&local->iflist_mtx);
> >
> > + 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.
-Juuso
> johannes
>
^ permalink raw reply
* Re: [RFC PATCHv2] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-26 12:52 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274878272.5277.1890.camel@wimaxnb.nmp.nokia.com>
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.
johannes
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-26 12:53 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1274878088-22785-1-git-send-email-juuso.oikarinen@nokia.com>
On Wed, 2010-05-26 at 15:48 +0300, Juuso Oikarinen wrote:
> Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
> ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 11 need to be marked
> basic.
>
> Change this.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> net/mac80211/ibss.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> 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.
We've had this discussion before. Making more rates required will break
compatibility with 11b devices.
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.
johannes
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Juuso Oikarinen @ 2010-05-26 13:13 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274878391.3658.9.camel@jlt3.sipsolutions.net>
On Wed, 2010-05-26 at 14:53 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 15:48 +0300, Juuso Oikarinen wrote:
> > Currently the mac80211 marks rates 1 and 2 mbps as basic rates for created
> > ad-hoc networks. To be certifiable, rates 1, 2, 5.5 and 11 need to be marked
> > basic.
> >
> > Change this.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> > net/mac80211/ibss.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > 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.
>
> 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?
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.
-Juuso
> johannes
>
^ permalink raw reply
* Re: Problems connectring to an AP with Acer Aspire Revo
From: Christian P. Schmidt @ 2010-05-26 13:14 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274729665.2091.15280.camel@rchatre-DESK>
On 05/24/2010 09:34 PM, reinette chatre wrote:
> On Sat, 2010-05-22 at 01:29 -0700, Christian P. Schmidt wrote:
>> However, even with the new card, I could not make any kernel from 2.6.32
>> to 2.6.34 connect to any of my access points. Those are a Telekom DSL
>> router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
>> and even no encryption at all. My laptop with an Intel WiFi Link 5300
>> has no problems whatsoever in any of the modes.
>
> Could you please post some logs captured during your association
> attempts? Were there any errors in your logs? In addition to this,
> having mac80211 verbose debugging enabled will help and also
> wpa_supplicant logs. That will give us a place to start.
>
> Reinette
>
wpa_supplicant isn't particularly verbose:
Selected interface 'wlan0'
Interactive mode
> scan_r
bssid / frequency / signal level / flags / ssid
00:10:db:a1:69:21 2447 223
[WPA2-PSK-TKIP+CCMP-preauth][ESS] digadd
00:10:db:a1:69:20 2447 214 [ESS] test
<2>Authentication with 00:10:db:a1:69:21 timed out.
> <2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:20 (SSID='test' freq=2447 MHz)
<2>Authentication with 00:10:db:a1:69:20 timed out.
<2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:20 (SSID='test' freq=2447 MHz)
<2>Authentication with 00:10:db:a1:69:20 timed out.
<2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:21 (SSID='digadd' freq=2447
MHz)
<2>Authentication with 00:10:db:a1:69:21 timed out.
> <2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:21 (SSID='digadd' freq=2447
MHz)
<2>Authentication with 00:10:db:a1:69:21 timed out.
dmesg with verbose mac80211:
[66188.364996] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
in-tree:d
[66188.365474] iwlagn: Copyright(c) 2003-2010 Intel Corporation
[66188.365839] iwlagn 0000:05:00.0: PCI INT A -> Link[LN4A] -> GSI 19
(level, low) -> IRQ 19
[66188.365855] iwlagn 0000:05:00.0: setting latency timer to 64
[66188.365909] iwlagn 0000:05:00.0: Detected Intel Wireless WiFi Link
5100AGN REV=0x54
[66188.386206] iwlagn 0000:05:00.0: Tunable channels: 13 802.11bg, 24
802.11a channels
[66188.387527] iwlagn 0000:05:00.0: firmware: requesting
iwlwifi-5000-2.ucode
[66188.449118] iwlagn 0000:05:00.0: loaded firmware version 8.24.2.12
[66188.450753] phy1: Selected rate control algorithm 'iwl-agn-rs'
[66198.724027] phy1: device now idle
[66198.725051] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[66199.028356] phy1: device no longer idle - scanning
[66202.396651] phy1: device now idle
[66202.398713] phy1: device no longer idle - working
[66202.398733] wlan0: direct probe to 00:10:db:a1:69:21 (try 1)
[66202.598036] wlan0: direct probe to 00:10:db:a1:69:21 (try 2)
[66202.798041] wlan0: direct probe to 00:10:db:a1:69:21 (try 3)
[66202.998031] wlan0: direct probe to 00:10:db:a1:69:21 timed out
[66203.001034] phy1: device now idle
[66212.399658] phy1: device no longer idle - scanning
[66215.779131] phy1: device now idle
[66215.779591] phy1: device no longer idle - working
[66215.779607] wlan0: direct probe to 00:10:db:a1:69:21 (try 1)
[66215.979026] wlan0: direct probe to 00:10:db:a1:69:21 (try 2)
[66216.179027] wlan0: direct probe to 00:10:db:a1:69:21 (try 3)
[66216.379030] wlan0: direct probe to 00:10:db:a1:69:21 timed out
[66216.382034] phy1: device now idle
[66225.784782] phy1: device no longer idle - scanning
[66229.164447] phy1: device now idle
[66229.164848] phy1: device no longer idle - working
[66229.164864] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
[66229.364034] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
[66229.564030] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
[66229.764027] wlan0: direct probe to 00:10:db:a1:69:20 timed out
[66229.767035] phy1: device now idle
[66239.165261] phy1: device no longer idle - scanning
[66242.537751] phy1: device now idle
[66242.538524] phy1: device no longer idle - working
[66242.538545] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
[66242.738028] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
[66242.938033] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
[66243.138029] wlan0: direct probe to 00:10:db:a1:69:20 timed out
[66243.142031] phy1: device now idle
I kind of feel that no packets are sent, since I can't see them on the
firewall, even with packet dumps, not even association attempts.
Running tcpdump on the client doesn't show anything either, but I'm not
sure whether it would normally capture association attempts.
Regards,
Christian
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-26 13:27 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274879624.5277.1917.camel@wimaxnb.nmp.nokia.com>
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?
> > 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.
> 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 :)
johannes
^ permalink raw reply
* Re: Is there a bug in 2.6.29-rc8 support of Ad-Hoc mode?
From: John W. Linville @ 2010-05-26 13:28 UTC (permalink / raw)
To: Gordon, Charles; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <8DCC153EAFE67A4B990A840E829F704B017C658D5E6C@mtk-sms-exch01.digi.com>
On Wed, May 26, 2010 at 06:57:31AM -0500, Gordon, Charles wrote:
> I am trying to get a driver I'm developing to work with Ad-Hoc mode on
> Linux 2.6.29-rc8. I am running into a problem. I have traced it down
> to the routine ieee80211_scan_work. I use the following commands to
> start Ad-Hoc mode:
>
> ifconfig wlan0 down
> iwconfig wlan0 mode Ad-Hoc essid "AdHocID"
> ifconfig wlan0 up
FWIW, this should probably look more like the following:
ifconfig wlan0 down
iwconfig wlan0 mode Ad-Hoc
ifconfig wlan0 up
iwconfig wlan0 essid "AdHocID"
If that doesn't work, you may be experiencing some bug. But...
> Can someone either confirm that this is a known problem with
> 2.6.28-rc8, or tell me what my driver could be doing to cause this
> problem?
This kernel is ancient, even if you meant 2.6.29-rc8 like you
said originally. And it is not even an actual release version
(e.g. 2.6.29). I could be wrong, but I doubt there will be much
interest among the people here in working on the internals of such
an old kernel. Is there some reason you can't try something newer?
2.6.34 was just released...
Good luck!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Johannes Berg @ 2010-05-26 14:14 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274879624.5277.1917.camel@wimaxnb.nmp.nokia.com>
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.
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
* [PATCH] mac80211: remove bogus mod_timer() call
From: Johannes Berg @ 2010-05-26 14:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
The IBSS code has a bogus mod_timer(..., 0) call,
we shouldn't ever pass a constant value to the
function since any constant value could be in the
future or the past.
However, invoking the timer here is not necessary
at all, since we just finished scanning and just
need to have the IBSS code run again from the
workqueue later, so factor out the work starting
and use that instead.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
The problem was introduced in 2.6.32 ... not sure if that means it
should be sent to stable or not, I guess not since we haven't really had
issues with it that I know of.
net/mac80211/ibss.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/mac80211/ibss.c 2010-05-25 20:44:41.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2010-05-25 20:45:57.000000000 +0200
@@ -798,6 +798,15 @@ static void ieee80211_ibss_work(struct w
}
}
+static void ieee80211_queue_ibss_work(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+ struct ieee80211_local *local = sdata->local;
+
+ set_bit(IEEE80211_IBSS_REQ_RUN, &ifibss->request);
+ ieee80211_queue_work(&local->hw, &ifibss->work);
+}
+
static void ieee80211_ibss_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
@@ -810,8 +819,7 @@ static void ieee80211_ibss_timer(unsigne
return;
}
- set_bit(IEEE80211_IBSS_REQ_RUN, &ifibss->request);
- ieee80211_queue_work(&local->hw, &ifibss->work);
+ ieee80211_queue_ibss_work(sdata);
}
#ifdef CONFIG_PM
@@ -859,7 +867,7 @@ void ieee80211_ibss_notify_scan_complete
if (!sdata->u.ibss.ssid_len)
continue;
sdata->u.ibss.last_scan_completed = jiffies;
- mod_timer(&sdata->u.ibss.timer, 0);
+ ieee80211_queue_ibss_work(sdata);
}
mutex_unlock(&local->iflist_mtx);
}
^ permalink raw reply
* RE: Is there a bug in 2.6.29-rc8 support of Ad-Hoc mode?
From: Gordon, Charles @ 2010-05-26 15:07 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100526132811.GA5823@tuxdriver.com>
Hi John,
Switching to your sequence of commands:
> ifconfig wlan0 down
> iwconfig wlan0 mode Ad-Hoc
> ifconfig wlan0 up
> iwconfig wlan0 essid "AdHocID"
solves the problem.
Thanks for the help!
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Wednesday, May 26, 2010 9:28 AM
To: Gordon, Charles
Cc: linux-wireless@vger.kernel.org
Subject: Re: Is there a bug in 2.6.29-rc8 support of Ad-Hoc mode?
On Wed, May 26, 2010 at 06:57:31AM -0500, Gordon, Charles wrote:
> I am trying to get a driver I'm developing to work with Ad-Hoc mode on
> Linux 2.6.29-rc8. I am running into a problem. I have traced it down
> to the routine ieee80211_scan_work. I use the following commands to
> start Ad-Hoc mode:
>
> ifconfig wlan0 down
> iwconfig wlan0 mode Ad-Hoc essid "AdHocID"
> ifconfig wlan0 up
FWIW, this should probably look more like the following:
ifconfig wlan0 down
iwconfig wlan0 mode Ad-Hoc
ifconfig wlan0 up
iwconfig wlan0 essid "AdHocID"
If that doesn't work, you may be experiencing some bug. But...
> Can someone either confirm that this is a known problem with
> 2.6.28-rc8, or tell me what my driver could be doing to cause this
> problem?
This kernel is ancient, even if you meant 2.6.29-rc8 like you
said originally. And it is not even an actual release version
(e.g. 2.6.29). I could be wrong, but I doubt there will be much
interest among the people here in working on the internals of such
an old kernel. Is there some reason you can't try something newer?
2.6.34 was just released...
Good luck!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] mac80211: remove tx status ampdu_ack_map
From: Johannes Berg @ 2010-05-26 15:19 UTC (permalink / raw)
To: John Linville; +Cc: Reinette Chatre, linux-wireless
There's a single use of this struct member, but
as it is write-only it clearly not necessary.
Thus we can free up some space here, even if we
don't need it right now it seems pointless to
carry around the variable.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 1 -
include/net/mac80211.h | 5 +----
2 files changed, 1 insertion(+), 5 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn-tx.c 2010-05-26 17:16:01.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn-tx.c 2010-05-26 17:16:05.000000000 +0200
@@ -1231,7 +1231,6 @@ static int iwlagn_tx_status_reply_compre
info->flags |= IEEE80211_TX_STAT_ACK;
info->flags |= IEEE80211_TX_STAT_AMPDU;
info->status.ampdu_ack_len = successes;
- info->status.ampdu_ack_map = bitmap;
info->status.ampdu_len = agg->frame_count;
iwlagn_hwrate_to_tx_control(priv, agg->rate_n_flags, info);
--- wireless-testing.orig/include/net/mac80211.h 2010-05-26 17:15:29.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-05-26 17:15:56.000000000 +0200
@@ -412,8 +412,6 @@ struct ieee80211_tx_rate {
* @driver_data: array of driver_data pointers
* @ampdu_ack_len: number of acked aggregated frames.
* relevant only if IEEE80211_TX_STAT_AMPDU was set.
- * @ampdu_ack_map: block ack bit map for the aggregation.
- * relevant only if IEEE80211_TX_STAT_AMPDU was set.
* @ampdu_len: number of aggregated frames.
* relevant only if IEEE80211_TX_STAT_AMPDU was set.
* @ack_signal: signal strength of the ACK frame
@@ -448,10 +446,9 @@ struct ieee80211_tx_info {
struct {
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
u8 ampdu_ack_len;
- u64 ampdu_ack_map;
int ack_signal;
u8 ampdu_len;
- /* 7 bytes free */
+ /* 15 bytes free */
} status;
struct {
struct ieee80211_tx_rate driver_rates[
^ permalink raw reply
* RE: wireless-regdb: A band is missing for IL
From: David Quan @ 2010-05-26 16:21 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Luis R. Rodriguez, Michael Green, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTin4UbuZOfpJ23KLq8HRfVcEKmHAAeEtSSxDE9Vu@mail.gmail.com>
Unii1 = 5150 - 5250
Unii2 = 5250 - 5350
http://en.wikipedia.org/wiki/U-NII
Currently our internal database shows no HT40 support for Israel in 5Ghz.
Only in 2Ghz it supports both HT20/40.
5) The allow of HT40 is not control by WFA, but by regulatory. So even if WFA allows HT40 general support in 5Ghz,
if the country do not allow it, it is not allowed.
6) Yes, however, I am not sure if ath9k supported this yet or not. Will chat with Luis.
David
-----Original Message-----
From: Emmanuel Grumbach [mailto:egrumbach@gmail.com]
Sent: Tuesday, May 25, 2010 11:26 PM
To: David Quan
Cc: Luis R. Rodriguez; Michael Green; linville@tuxdriver.com; linux-wireless@vger.kernel.org
Subject: Re: wireless-regdb: A band is missing for IL
I don't know exactly what Unii1 and Unii2 means but, this is the
latest regulatory authoritative document (in hebrew):
http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf
In short:
1. 5150 - 5250
2. 5250 - 5350 DFS mandatory
3. outdoor is forbidden for both
4. 200mW maximum e.i.r.p.
5. 40 Mhz is allowed for all WiFi Alliance equipment in 5.2GHz
6. 40 Mhz is allowed for WiFi Alliance equipment that have "40 MHz
operation in 2.4 GHz, with coexistence mechanisms" only
I know how to enforce 1 - 4. But 5 and 6 is another story....
Anyway, I will send an RFC soon.
Emmanuel Grumbach
egrumbach@gmail.com
On Tue, May 25, 2010 at 23:39, David Quan <David.Quan@atheros.com> wrote:
> Israel follows ETSI3_WORLD,
> this means
>
> Unii1 + Unii2 is supported. Unii2 requires DFS for APs.
>
> 2ghz Ch1-13 supported.
>
>
> -----Original Message-----
> From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
> Sent: Tuesday, May 25, 2010 12:08 PM
> To: Emmanuel Grumbach; Michael Green; David Quan
> Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org
> Subject: Re: wireless-regdb: A band is missing for IL
>
> Michael, please review and let us know what you think.
>
> Luis
>
> On Tue, May 25, 2010 at 12:03 AM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
>> According to http://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.29
>>
>> Channels 34 - 64 are allowed in 20 Mhz in Israel. This is not what is
>> written in db.txt:
>>
>> country IL:
>> (2402 - 2482 @ 40), (N/A, 20)
>>
>> This wikipedia page relies on an official page from the Israel
>> Ministry of the Communication.
>>
>> Emmanuel Grumbach
>> egrumbach@gmail.com
>> --
>> 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: [PATCH] cfg80211: Fix user-space crda query stall
From: Luis R. Rodriguez @ 2010-05-26 16:46 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1274850519.5277.1413.camel@wimaxnb.nmp.nokia.com>
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.
Luis
Luis
^ permalink raw reply
* Re: [RFC] wireless-regdb: Add A band in IL
From: Luis R. Rodriguez @ 2010-05-26 16:51 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linville, linux-wireless, Michael Green, David Quan
In-Reply-To: <1274856569-13436-1-git-send-email-emmanuel.grumbach@intel.com>
On Tue, May 25, 2010 at 11:49 PM, Emmanuel Grumbach
<emmanuel.grumbach@intel.com> wrote:
> A band in allowed in IL, according to official document issued by the Ministry
> of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
>
> 5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
> 5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
>
> 40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
>
> ***************************************************************
> Not to be merged for the moment
> ***************************************************************
>
> CC: Michael Green <Michael.Green@atheros.com>
> CC: David Quan <David.Quan@atheros.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> db.txt | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index e63a43e..d49c397 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -319,6 +319,8 @@ country IE:
>
> country IL:
> (2402 - 2482 @ 40), (N/A, 20)
> + (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
> + (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
I believe the one standing issue here is you are enabling HT40 on 5
GHz, how about enabling 2.4 GHz first, and then through a separate
patch and time/review we review the HT40 stuff, unless you are in no
rush to get 2.4 GHz enabled.
Luis
^ 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