* crash in wireless-next
From: Ben Greear @ 2011-11-04 18:16 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Anyone seen a crash like this? I was restarting my user-space
tools, and had just unloaded the drivers that had,
around 135 virtual stations created. Just my disable-ht
patch series applied on top of yesterday's wireless-testing.
I'll dig into it more when I get a chance, but let me know
if someone is already working on this...
BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [<c076b7e7>] wext_handle_ioctl+0xd9/0x17e
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: ath5k arc4 ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 xt_CT iptable_raw bridge ]
Pid: 1335, comm: hald Tainted: G W 3.1.0-wl+ #3 To Be Filled By O.E.M. To Be Filled By O.E.M./To.
EIP: 0060:[<c076b7e7>] EFLAGS: 00010297 CPU: 0
EIP is at wext_handle_ioctl+0xd9/0x17e
EAX: f06a5000 EBX: 00000001 ECX: 00008b01 EDX: 00000002
ESI: f40b1ed4 EDI: 000008d3 EBP: f40b1e8c ESP: f40b1e74
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hald (pid: 1335, ti=f40b0000 task=f48fb340 task.ti=f40b0000)
Stack:
00008b01 00000001 00008b01 00000000 00008b01 c0a9c140 f40b1f08 c06f9523
bfdc339c 0017a0b9 c06ecfaa 000000d0 f40b1eb0 c0556c1d f0477440 bfdc339c
c06ed007 f40b1ee4 c04ad561 f15a2180 1b96bccf c0a3d9e4 00000020 00000000
Call Trace:
[<c06f9523>] dev_ioctl+0x529/0x561
[<c06ecfaa>] ? sk_prot_alloc+0x23/0xd1
[<c0556c1d>] ? security_sk_alloc+0x10/0x13
[<c06ed007>] ? sk_prot_alloc+0x80/0xd1
[<c04ad561>] ? kmem_cache_alloc+0x24/0x9d
[<c06e8e25>] ? kernel_sendmsg+0x37/0x37
[<c06e9000>] sock_ioctl+0x1db/0x1e7
[<c06e8e25>] ? kernel_sendmsg+0x37/0x37
[<c04c5996>] do_vfs_ioctl+0x464/0x4a9
[<c07919ac>] ? _raw_spin_unlock+0x8/0xa
[<c04b86a4>] ? fd_install+0x44/0x4a
[<c06e9d75>] ? sock_map_fd+0x1f/0x25
[<c06ea637>] ? sys_socket+0x43/0x5a
[<c06ea6c5>] ? sys_socketcall+0x77/0x1b6
[<c04c5a1c>] sys_ioctl+0x41/0x61
[<c07962d8>] sysenter_do_call+0x12/0x28
Code: 75 06 85 db 74 51 89 da 0f b7 7a 04 8d 99 00 75 ff ff 39 fb 73 04 8b 12 eb 11 0f b7 7a 06 8d 99 20
EIP: [<c076b7e7>] wext_handle_ioctl+0xd9/0x17e SS:ESP 0068:f40b1e74
CR2: 0000000000000006
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [RFC v3 2/2] ath9k: integrate initial DFS module
From: Zefir Kurtisi @ 2011-11-04 17:19 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Cc: rodrigue, nbd, shafi.wireless, chunkeey, peter, Zefir Kurtisi
In-Reply-To: <1320427159-18509-1-git-send-email-zefir.kurtisi@neratec.com>
This patch integrates the DFS module into ath9k, including
* build the module into ath9k_hw
* set up DFS debugfs
* define HW capability flag for DFS support
* set by DFS supporting devices
(so far: AR_SREV_9280_20_OR_LATER, TBC)
* define and set DFS opmode flag when on DFS channel
* configure rader params after reset
* provide rader RX filter flag in ath_calcrxfilter()
* forward radar PHY errors to dfs module
This is WIP and at its current stage is limited to test ath9k
pulse detection capabilities. The DFS pattern matching is
TBD in the higher layers and is not part of this patch.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/Makefile | 2 ++
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 3 +++
drivers/net/wireless/ath/ath9k/debug.h | 2 ++
drivers/net/wireless/ath/ath9k/hw-ops.h | 9 +++++++++
drivers/net/wireless/ath/ath9k/hw.c | 7 +++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 16 ++++++++++++++++
drivers/net/wireless/ath/ath9k/recv.c | 19 ++++++++++++++-----
9 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index 36ed3c4..1f260a5 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -29,6 +29,8 @@ ath9k_hw-y:= \
eeprom_9287.o \
ani.o \
btcoex.o \
+ dfs.o \
+ dfs_debug.o \
mac.o \
ar9002_mac.o \
ar9003_mac.o \
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 7ab7a1e..de0309e 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -563,6 +563,7 @@ struct ath_ant_comb {
#define SC_OP_BT_SCAN BIT(13)
#define SC_OP_ANI_RUN BIT(14)
#define SC_OP_PRIM_STA_VIF BIT(15)
+#define SC_OP_DFS BIT(16)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 138ae09..6642108 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1633,6 +1633,9 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_file("debug", S_IRUSR | S_IWUSR, sc->debug.debugfs_phy,
sc, &fops_debug);
#endif
+
+ ath9k_dfs_init_debug(sc);
+
debugfs_create_file("dma", S_IRUSR, sc->debug.debugfs_phy, sc,
&fops_dma);
debugfs_create_file("interrupt", S_IRUSR, sc->debug.debugfs_phy, sc,
diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
index 4f6c939..f70735a 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -19,6 +19,7 @@
#include "hw.h"
#include "rc.h"
+#include "dfs_debug.h"
struct ath_txq;
struct ath_buf;
@@ -180,6 +181,7 @@ struct ath_stats {
struct ath_interrupt_stats istats;
struct ath_tx_stats txstats[ATH9K_NUM_TX_QUEUES];
struct ath_rx_stats rxstats;
+ struct ath_dfs_stats dfs_stats;
u32 reset[__RESET_TYPE_MAX];
};
diff --git a/drivers/net/wireless/ath/ath9k/hw-ops.h b/drivers/net/wireless/ath/ath9k/hw-ops.h
index e74c233..c4ad0b0 100644
--- a/drivers/net/wireless/ath/ath9k/hw-ops.h
+++ b/drivers/net/wireless/ath/ath9k/hw-ops.h
@@ -212,4 +212,13 @@ static inline int ath9k_hw_fast_chan_change(struct ath_hw *ah,
return ath9k_hw_private_ops(ah)->fast_chan_change(ah, chan,
ini_reloaded);
}
+
+static inline void ath9k_hw_set_radar_params(struct ath_hw *ah)
+{
+ if (!ath9k_hw_private_ops(ah)->set_radar_params)
+ return;
+
+ ath9k_hw_private_ops(ah)->set_radar_params(ah, &ah->radar_conf);
+}
+
#endif /* ATH9K_HW_OPS_H */
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 76dbc85..c9ba80d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2333,6 +2333,13 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
pCap->pcie_lcr_offset = 0x80;
}
+ if (AR_SREV_9280_20_OR_LATER(ah)) {
+ /*
+ * TODO: check for which chip-sets we want to support DFS
+ */
+ pCap->hw_caps |= ATH9K_HW_CAP_DFS;
+ }
+
tx_chainmask = pCap->tx_chainmask;
rx_chainmask = pCap->rx_chainmask;
while (tx_chainmask || rx_chainmask) {
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9dbc3cd..4f02f83 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -204,6 +204,7 @@ enum ath9k_hw_caps {
ATH9K_HW_CAP_5GHZ = BIT(14),
ATH9K_HW_CAP_APM = BIT(15),
ATH9K_HW_CAP_RTT = BIT(16),
+ ATH9K_HW_CAP_DFS = BIT(17),
};
struct ath9k_hw_capabilities {
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index d3b92ce..e86d820 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -305,6 +305,10 @@ static bool ath_complete_reset(struct ath_softc *sc, bool start)
ath9k_hw_antdiv_comb_conf_set(ah, &div_ant_conf);
}
+ /* set radar parameters if in DFS mode */
+ if (sc->sc_flags & SC_OP_DFS)
+ ath9k_hw_set_radar_params(ah);
+
ieee80211_wake_queues(sc->hw);
return true;
@@ -1722,9 +1726,21 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
memset(&sc->survey[pos], 0, sizeof(struct survey_info));
}
+ if (curchan->flags & IEEE80211_CHAN_RADAR) {
+ if (!(ah->caps.hw_caps & ATH9K_HW_CAP_DFS)) {
+ ath_err(common, "HW does not support DFS\n");
+ mutex_unlock(&sc->mutex);
+ return -EINVAL;
+ }
+ sc->sc_flags |= SC_OP_DFS;
+ } else
+ sc->sc_flags &= ~SC_OP_DFS;
+
if (ath_set_channel(sc, hw, &sc->sc_ah->channels[pos]) < 0) {
ath_err(common, "Unable to set channel\n");
mutex_unlock(&sc->mutex);
+ /* clear DFS operation flag on failure */
+ sc->sc_flags &= ~SC_OP_DFS;
return -EINVAL;
}
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 0d5f275..76d804c 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -17,6 +17,7 @@
#include <linux/dma-mapping.h>
#include "ath9k.h"
#include "ar9003_mac.h"
+#include "dfs.h"
#define SKB_CB_ATHBUF(__skb) (*((struct ath_buf **)__skb->cb))
@@ -473,6 +474,8 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
rfilt |= ATH9K_RX_FILTER_MCAST_BCAST_ALL;
}
+ if (sc->sc_flags & SC_OP_DFS)
+ rfilt |= ATH9K_RX_FILTER_PHYRADAR;
return rfilt;
#undef RX_FILTER_PRESERVE
@@ -1855,11 +1858,6 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
if (sc->sc_flags & SC_OP_RXFLUSH)
goto requeue_drop_frag;
- retval = ath9k_rx_skb_preprocess(common, hw, hdr, &rs,
- rxs, &decrypt_error);
- if (retval)
- goto requeue_drop_frag;
-
rxs->mactime = (tsf & ~0xffffffffULL) | rs.rs_tstamp;
if (rs.rs_tstamp > tsf_lower &&
unlikely(rs.rs_tstamp - tsf_lower > 0x10000000))
@@ -1869,6 +1867,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
unlikely(tsf_lower - rs.rs_tstamp > 0x10000000))
rxs->mactime += 0x100000000ULL;
+ if ((rs.rs_status & ATH9K_RXERR_PHY) &&
+ (rs.rs_phyerr == ATH9K_PHYERR_RADAR)) {
+ /* DFS: check for radar pulse */
+ ath9k_dfs_process_phyerr(sc, hdr, &rs, rxs->mactime);
+ }
+
+ retval = ath9k_rx_skb_preprocess(common, hw, hdr, &rs,
+ rxs, &decrypt_error);
+ if (retval)
+ goto requeue_drop_frag;
+
/* Ensure we always have an skb to requeue once we are done
* processing the current buffer's skb */
requeue_skb = ath_rxbuf_alloc(common, common->rx_bufsize, GFP_ATOMIC);
--
1.7.4.1
^ permalink raw reply related
* [RFC v3 0/2] ath9k: DFS radar detection
From: Zefir Kurtisi @ 2011-11-04 17:19 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Cc: rodrigue, nbd, shafi.wireless, chunkeey, peter, Zefir Kurtisi
This patch series proposes DFS radar pulse detection for ath9k.
Updates to v2
* use DFS opmode to handle RX filter configuration
* remove dead code
* wrap call to private function
* fix naming convention issues
* add comments
Zefir Kurtisi (2):
ath9k: add DFS radar pulse processing
ath9k: integrate initial DFS module
drivers/net/wireless/ath/ath.h | 2 +
drivers/net/wireless/ath/ath9k/Makefile | 2 +
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/dfs.c | 203 ++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/dfs.h | 38 +++++
drivers/net/wireless/ath/ath9k/dfs_debug.c | 89 ++++++++++++
drivers/net/wireless/ath/ath9k/dfs_debug.h | 59 ++++++++
drivers/net/wireless/ath/ath9k/hw-ops.h | 9 ++
drivers/net/wireless/ath/ath9k/hw.c | 7 +
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 16 +++
drivers/net/wireless/ath/ath9k/recv.c | 19 ++-
14 files changed, 446 insertions(+), 5 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/dfs.c
create mode 100644 drivers/net/wireless/ath/ath9k/dfs.h
create mode 100644 drivers/net/wireless/ath/ath9k/dfs_debug.c
create mode 100644 drivers/net/wireless/ath/ath9k/dfs_debug.h
--
1.7.4.1
^ permalink raw reply
* [RFC v3 1/2] ath9k: add DFS radar pulse processing
From: Zefir Kurtisi @ 2011-11-04 17:19 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Cc: rodrigue, nbd, shafi.wireless, chunkeey, peter, Zefir Kurtisi
In-Reply-To: <1320427159-18509-1-git-send-email-zefir.kurtisi@neratec.com>
This initial DFS module provides basic functionality to deal with
radar pulses reported by the DFS HW pulse detector.
The reported data is evaluated and basic plausibility checks are
performed to filter false pulses. Passing radar pulses are
forwarded to pattern detectors (not part of this patch).
The patch also includes
* new debug level ATH_DBG_DFS
* debugfs DFS radar statistics
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath.h | 2 +
drivers/net/wireless/ath/ath9k/dfs.c | 203 ++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/dfs.h | 38 +++++
drivers/net/wireless/ath/ath9k/dfs_debug.c | 89 ++++++++++++
drivers/net/wireless/ath/ath9k/dfs_debug.h | 59 ++++++++
5 files changed, 391 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/dfs.c
create mode 100644 drivers/net/wireless/ath/ath9k/dfs.h
create mode 100644 drivers/net/wireless/ath/ath9k/dfs_debug.c
create mode 100644 drivers/net/wireless/ath/ath9k/dfs_debug.h
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 46d6926..e38fcad 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -215,6 +215,7 @@ do { \
* @ATH_DBG_HWTIMER: hardware timer handling
* @ATH_DBG_BTCOEX: bluetooth coexistance
* @ATH_DBG_BSTUCK: stuck beacons
+ * @ATH_DBG_DFS: radar datection
* @ATH_DBG_ANY: enable all debugging
*
* The debug level is used to control the amount and type of debugging output
@@ -240,6 +241,7 @@ enum ATH_DEBUG {
ATH_DBG_BTCOEX = 0x00002000,
ATH_DBG_WMI = 0x00004000,
ATH_DBG_BSTUCK = 0x00008000,
+ ATH_DBG_DFS = 0x00010000,
ATH_DBG_ANY = 0xffffffff
};
diff --git a/drivers/net/wireless/ath/ath9k/dfs.c b/drivers/net/wireless/ath/ath9k/dfs.c
new file mode 100644
index 0000000..c6d2eea
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/dfs.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2008-2011 Atheros Communications Inc.
+ * Copyright (c) 2011 Neratec Solutions AG
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "hw.h"
+#include "hw-ops.h"
+#include "ath9k.h"
+#include "dfs.h"
+#include "dfs_debug.h"
+
+/* convert pulse duration to usecs, considering clock mode */
+static u32 dur_to_usecs(struct ath_hw *ah, u32 dur)
+{
+ const u32 AR93X_NSECS_PER_DUR = 800;
+ const u32 AR93X_NSECS_PER_DUR_FAST = (8000 / 11);
+ u32 nsecs;
+ if (IS_CHAN_A_FAST_CLOCK(ah, ah->curchan))
+ nsecs = dur * AR93X_NSECS_PER_DUR_FAST;
+ else
+ nsecs = dur * AR93X_NSECS_PER_DUR;
+
+ return (nsecs + 500) / 1000;
+}
+
+/* internal struct to pass radar data */
+struct ath_radar_data {
+ u8 pulse_bw_info;
+ u8 rssi;
+ u8 ext_rssi;
+ u8 pulse_length_ext;
+ u8 pulse_length_pri;
+};
+
+/* TODO: move into or synchronize this with generic header
+ * as soon as IF is defined */
+struct dfs_radar_pulse {
+ u16 freq;
+ u64 ts;
+ u32 width;
+ u8 rssi;
+};
+
+#define PRI_CH_RADAR_FOUND 0x01
+#define EXT_CH_RADAR_FOUND 0x02
+static bool ath9k_postprocess_radar_event(struct ath_softc *sc,
+ struct ath_radar_data *are, struct dfs_radar_pulse *drp)
+{
+ u8 rssi;
+ u16 dur;
+
+ ath_dbg(ath9k_hw_common(sc->sc_ah), ATH_DBG_DFS,
+ "pulse_bw_info=0x%x, pri,ext len/rssi=(%u/%u, %u/%u)\n",
+ are->pulse_bw_info,
+ are->pulse_length_pri, are->rssi,
+ are->pulse_length_ext, are->ext_rssi);
+
+ /* Only the last 2 bits of the BW info are relevant, they indicate
+ which channel the radar was detected in.*/
+ are->pulse_bw_info &= 0x03;
+
+ switch (are->pulse_bw_info) {
+ case PRI_CH_RADAR_FOUND:
+ /* radar in ctrl channel */
+ dur = are->pulse_length_pri;
+ DFS_STAT_INC(sc, pri_phy_errors);
+ /* cannot use ctrl channel RSSI
+ * if extension channel is stronger */
+ rssi = (are->ext_rssi >= (are->rssi + 3)) ? 0 : are->rssi;
+ break;
+ case EXT_CH_RADAR_FOUND:
+ /* radar in extension channel */
+ dur = are->pulse_length_ext;
+ DFS_STAT_INC(sc, ext_phy_errors);
+ /* cannot use extension channel RSSI
+ * if control channel is stronger */
+ rssi = (are->rssi >= (are->ext_rssi + 12)) ? 0 : are->ext_rssi;
+ break;
+ case (PRI_CH_RADAR_FOUND | EXT_CH_RADAR_FOUND):
+ /*
+ * Conducted testing, when pulse is on DC, both pri and ext
+ * durations are reported to be same
+ *
+ * Radiated testing, when pulse is on DC, different pri and
+ * ext durations are reported, so take the larger of the two
+ * */
+ if (are->pulse_length_ext >= are->pulse_length_pri)
+ dur = are->pulse_length_ext;
+ else
+ dur = are->pulse_length_pri;
+ DFS_STAT_INC(sc, dc_phy_errors);
+
+ /* when both are present use stronger one */
+ rssi = (are->rssi < are->ext_rssi) ? are->ext_rssi : are->rssi;
+ break;
+ default:
+ /* Bogus bandwidth info received in descriptor,
+ so ignore this PHY error */
+ DFS_STAT_INC(sc, bwinfo_discards);
+ return false;
+ }
+
+ if (rssi == 0) {
+ DFS_STAT_INC(sc, rssi_discards);
+ return false;
+ }
+
+ /*
+ * TODO: check chirping pulses
+ * checks for chirping are dependent on the DFS regulatory domain
+ * used, which is yet TBD
+ */
+
+ /* convert duration to usecs */
+ drp->width = dur_to_usecs(sc->sc_ah, dur);
+ drp->rssi = rssi;
+
+ DFS_STAT_INC(sc, pulses_detected);
+ return true;
+}
+#undef PRI_CH_RADAR_FOUND
+#undef EXT_CH_RADAR_FOUND
+
+
+/*
+ * DFS: check PHY-error for radar pulse and feed the detector
+ */
+void ath9k_dfs_process_phyerr(struct ath_softc *sc, void *data,
+ struct ath_rx_status *rs, u64 mactime)
+{
+ struct ath_radar_data ard;
+ u16 datalen;
+ char *vdata_end;
+ struct dfs_radar_pulse drp;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+
+ if ((!(rs->rs_phyerr != ATH9K_PHYERR_RADAR)) &&
+ (!(rs->rs_phyerr != ATH9K_PHYERR_FALSE_RADAR_EXT))) {
+ ath_dbg(common, ATH_DBG_DFS,
+ "Error: rs_phyer=0x%x not a radar error\n",
+ rs->rs_phyerr);
+ return;
+ }
+
+ datalen = rs->rs_datalen;
+ if (datalen == 0) {
+ DFS_STAT_INC(sc, datalen_discards);
+ return;
+ }
+
+ ard.rssi = rs->rs_rssi_ctl0;
+ ard.ext_rssi = rs->rs_rssi_ext0;
+
+ /* hardware stores this as 8 bit signed value.
+ * we will cap it at 0 if it is a negative number
+ */
+ if (ard.rssi & 0x80)
+ ard.rssi = 0;
+ if (ard.ext_rssi & 0x80)
+ ard.ext_rssi = 0;
+
+ vdata_end = (char *)data + datalen;
+ ard.pulse_bw_info = vdata_end[-1];
+ ard.pulse_length_ext = vdata_end[-2];
+ ard.pulse_length_pri = vdata_end[-3];
+
+ ath_dbg(common, ATH_DBG_DFS,
+ "bw_info=%d, length_pri=%d, length_ext=%d, "
+ "rssi_pri=%d, rssi_ext=%d\n",
+ ard.pulse_bw_info, ard.pulse_length_pri, ard.pulse_length_ext,
+ ard.rssi, ard.ext_rssi);
+
+ drp.freq = ah->curchan->channel;
+ drp.ts = mactime;
+ if (ath9k_postprocess_radar_event(sc, &ard, &drp)) {
+ static u64 last_ts;
+ ath_dbg(common, ATH_DBG_DFS,
+ "ath9k_dfs_process_phyerr: channel=%d, ts=%llu, "
+ "width=%d, rssi=%d, delta_ts=%llu\n",
+ drp.freq, drp.ts, drp.width, drp.rssi, drp.ts-last_ts);
+ last_ts = drp.ts;
+ /*
+ * TODO: forward pulse to pattern detector
+ *
+ * ieee80211_add_radar_pulse(drp.freq, drp.ts,
+ * drp.width, drp.rssi);
+ */
+ }
+}
+EXPORT_SYMBOL(ath9k_dfs_process_phyerr);
diff --git a/drivers/net/wireless/ath/ath9k/dfs.h b/drivers/net/wireless/ath/ath9k/dfs.h
new file mode 100644
index 0000000..c73c175
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/dfs.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2008-2011 Atheros Communications Inc.
+ * Copyright (c) 2011 Neratec Solutions AG
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef ATH9K_DFS_H
+#define ATH9K_DFS_H
+
+/**
+ * ath9k_dfs_process_phyerr - process radar PHY error
+ * @sc: ath_softc
+ * @data: RX payload data
+ * @rs: RX status after processing descriptor
+ * @mactime: receive time
+ *
+ * This function is called whenever the HW DFS module detects a radar
+ * pulse and reports it as a PHY error.
+ *
+ * The radar information provided as raw payload data is validated and
+ * filtered for false pulses. Events passing all tests are forwarded to
+ * the upper layer for pattern detection.
+ */
+void ath9k_dfs_process_phyerr(struct ath_softc *sc, void *data,
+ struct ath_rx_status *rs, u64 mactime);
+
+#endif /* ATH9K_DFS_H */
diff --git a/drivers/net/wireless/ath/ath9k/dfs_debug.c b/drivers/net/wireless/ath/ath9k/dfs_debug.c
new file mode 100644
index 0000000..3c03552
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/dfs_debug.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2008-2011 Atheros Communications Inc.
+ * Copyright (c) 2011 Neratec Solutions AG
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+
+#include <linux/debugfs.h>
+
+#include "ath9k.h"
+#include "dfs_debug.h"
+
+
+#if defined(CONFIG_ATH9K_DEBUGFS)
+
+#define ATH9K_DFS_STAT(s, p) \
+ len += snprintf(buf + len, size - len, "%28s : %10u\n", s, \
+ sc->debug.stats.dfs_stats.p);
+
+static ssize_t read_file_dfs(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath_softc *sc = file->private_data;
+ struct ath9k_hw_version *hw_ver = &sc->sc_ah->hw_version;
+ char *buf;
+ unsigned int len = 0, size = 8000;
+ ssize_t retval = 0;
+
+ buf = kzalloc(size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
+ len += snprintf(buf + len, size - len, "DFS support for "
+ "macVersion = 0x%x, macRev = 0x%x: %s\n",
+ hw_ver->macVersion, hw_ver->macRev,
+ (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_DFS) ?
+ "enabled" : "disabled");
+ ATH9K_DFS_STAT("DFS pulses detected ", pulses_detected);
+ ATH9K_DFS_STAT("Datalen discards ", datalen_discards);
+ ATH9K_DFS_STAT("RSSI discards ", rssi_discards);
+ ATH9K_DFS_STAT("BW info discards ", bwinfo_discards);
+ ATH9K_DFS_STAT("Primary channel pulses ", pri_phy_errors);
+ ATH9K_DFS_STAT("Secondary channel pulses", ext_phy_errors);
+ ATH9K_DFS_STAT("Dual channel pulses ", dc_phy_errors);
+
+ if (len > size)
+ len = size;
+
+ retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ kfree(buf);
+
+ return retval;
+}
+
+static int ath9k_dfs_debugfs_open(struct inode *inode, struct file *file)
+{
+ file->private_data = inode->i_private;
+ return 0;
+}
+
+
+static const struct file_operations fops_dfs_stats = {
+ .read = read_file_dfs,
+ .open = ath9k_dfs_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
+
+void ath9k_dfs_init_debug(struct ath_softc *sc)
+{
+ debugfs_create_file("dfs_stats", S_IRUSR,
+ sc->debug.debugfs_phy, sc, &fops_dfs_stats);
+}
+EXPORT_SYMBOL(ath9k_dfs_init_debug);
+
+#endif /* CONFIG_ATH9K_DEBUGFS */
+
diff --git a/drivers/net/wireless/ath/ath9k/dfs_debug.h b/drivers/net/wireless/ath/ath9k/dfs_debug.h
new file mode 100644
index 0000000..079cf53
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/dfs_debug.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2008-2011 Atheros Communications Inc.
+ * Copyright (c) 2011 Neratec Solutions AG
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+
+#ifndef DFS_DEBUG_H
+#define DFS_DEBUG_H
+
+#include "hw.h"
+
+/**
+ * struct ath_dfs_stats - DFS Statistics
+ *
+ * @pulses_detected: No. of pulses detected so far
+ * @datalen_discards: No. of pulses discarded due to invalid datalen
+ * @rssi_discards: No. of pulses discarded due to invalid RSSI
+ * @bwinfo_discards: No. of pulses discarded due to invalid BW info
+ * @pri_phy_errors: No. of pulses reported for primary channel
+ * @ext_phy_errors: No. of pulses reported for extension channel
+ * @dc_phy_errors: No. of pulses reported for primary + extension channel
+ */
+struct ath_dfs_stats {
+ u32 pulses_detected;
+ u32 datalen_discards;
+ u32 rssi_discards;
+ u32 bwinfo_discards;
+ u32 pri_phy_errors;
+ u32 ext_phy_errors;
+ u32 dc_phy_errors;
+};
+
+
+#if defined(CONFIG_ATH9K_DEBUGFS)
+
+#define DFS_STAT_INC(sc, c) (sc->debug.stats.dfs_stats.c++)
+void ath9k_dfs_init_debug(struct ath_softc *sc);
+
+#else
+
+#define DFS_STAT_INC(sc, c) do { } while (0)
+static inline void ath9k_dfs_init_debug(struct ath_softc *sc) { }
+
+#endif
+
+
+#endif /* DFS_DEBUG_H */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3.2] mac80211: warn only once about not finding a rate
From: Johannes Berg @ 2011-11-04 17:07 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
The warning really shouldn't happen, but until we
find the reason why it does don't spew it all the
time, just once is enough to know we've hit it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/net/mac80211.h 2011-11-04 15:10:56.000000000 +0100
+++ b/include/net/mac80211.h 2011-11-04 18:04:48.000000000 +0100
@@ -3576,8 +3576,9 @@ rate_lowest_index(struct ieee80211_suppo
return i;
/* warn when we cannot find a rate. */
- WARN_ON(1);
+ WARN_ON_ONCE(1);
+ /* and return 0 (the lowest index) */
return 0;
}
^ permalink raw reply
* Re: [PATCH v3] cfg80211: merge in beacon ies of hidden bss.
From: Johannes Berg @ 2011-11-04 16:50 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <1320425330.3969.115.camel@jlt3.sipsolutions.net>
On Fri, 2011-11-04 at 17:48 +0100, Johannes Berg wrote:
> (I'm also thinking that maybe hashing the SSID into the tree was a bad
> idea?)
OTOH we don't have a choice unless we make the data structure more like
a hash table which seems more complex.
johannes
^ permalink raw reply
* Re: [PATCH v3] cfg80211: merge in beacon ies of hidden bss.
From: Johannes Berg @ 2011-11-04 16:48 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless
In-Reply-To: <CAMG6FYhbX+zKRw823RmPzwXqVzP7c+5W8pAaR4DGsOm0qnZGpA@mail.gmail.com>
On Fri, 2011-11-04 at 17:12 +0100, Dmitry Tarnyagin wrote:
> The problem with PSM when a hidden SSID was used was originally
> reported by Juuso Oikarinen.
>
> - When generally scanning, the AP is getting a bss entry with
> a zero SSID.
And maybe one with the probe reply too, if you do a scan with the SSID,
but anyway.
> - When associationg, a probe-req is sent to the AP with the SSID,
associating :-)
> and as a result a probe-responseis received with the hidden
probe-response is
> SSID in place. As a consequence, a second bss entry is created
> for the AP, now with the real SSID.
> - After association, mac80211 executes ieee80211_recalc_ps(),
> but does not switch to powersave because the beacon-ies are missing.
>
> As result, the STA does not ever enter PSM.
>
> The patch merges in beacon ies of hidden bss from beacon to the probe
> response, creating a consistant set of ies in place.
consistent
> Patch is depended on "cfg80211: fix cmp_ies" made by Johannes.
Thanks. This looks fine to me.
> + /* sort by length first, then by contents */
> + if (ie1[1] != ie2[1])
> + return ie2[1] - ie1[1];
> +
> + /* zeroed SSID ie is another indication of a hidden bss */
> + for (i = 0; i < ie2[1]; i++)
> + if (ie2[i + 2])
> + return -1;
The "return -1" here seems to be correct, but tricky -- maybe it
warrants a comment?
(I'm also thinking that maybe hashing the SSID into the tree was a bad
idea?)
One thing just occurred to me: This patch doesn't make the problem go
away, it just makes it less likely. Consider this: you ask to connect to
an AP with hidden SSID without scanning first. The scan for this AP
happens so quickly that you don't receive a beacon at all, you only
receive a probe response because the scan falls between two beacons.
In that case, the BSS entry will never be updated to get beacon IEs, so
you will still never enter powersave, because the beacon IEs weren't
present when the BSS entry was created.
You can probably reproduce that case easily by using a large beacon
interval, say 1 second.
To fix this, we need to address the TODO item.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: Allow overriding some HT information.
From: Johannes Berg @ 2011-11-04 16:30 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB4126E.1020802@candelatech.com>
On Fri, 2011-11-04 at 09:27 -0700, Ben Greear wrote:
> > So I still stand by what I said earlier -- you should not allow
> > advertising a smaller value than the hardware wanted to use initially.
> > If the AP doesn't use that smaller value, all is well, but if it
> > actually uses a smaller value then the hardware might fall over.
>
> Ok, I'll add that restriction. When this all settles, maybe I
> can get some info from the ath9k folks about what their hardware
> can actually support.
There's little point in advertising something bigger than the HW
supports, so I'd say that's the smallest :-)
(ok, so this might be for hw crypto, etc., but ath9k could advertise a
smaller value when hw crypto is disabled for example)
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: Allow overriding some HT information.
From: Ben Greear @ 2011-11-04 16:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320423893.3969.104.camel@jlt3.sipsolutions.net>
On 11/04/2011 09:24 AM, Johannes Berg wrote:
> On Fri, 2011-11-04 at 09:17 -0700, Ben Greear wrote:
>
>>>>> The AMPDU density should only allow increasing.
>>>>>
>>>>> I think a lot of this validation should live in cfg80211 so if another
>>>>> driver wants to implement it, this kind of thing is already covered.
>>>>
>>>> The ath9k driver supports 0, and then every value that corresponds to 1us or higher.
>>>> If you set it to 1/2us, for instance, it just quietly rounds up to 1us. It defaults
>>>> to 8, so it appears valid to decrease or increase this value.
>>>
>>> What quietly rounds up?
>>>
>>> If it defaults to 8 then I'm sure there's a reason for it, such as the
>>> crypto engine not being fast enough and needing 8us buffer between
>>> frames. As such, I really don't think decreasing it is valid.
>>
>> See this code in ath9k, top of main.c. It appears to support more
>> than the default of 8. I tested it out, and it appears to work
>> when set to lower values. I am disabling hw-crypt since I need
>> multiple VIFS, but not sure that matters or not.
>>
>> static u8 parse_mpdudensity(u8 mpdudensity)
>
> Well, this is used for TX. You're advertising the value for RX.
> Advertising a smaller value may work for you -- but only if the AP uses
> something larger anyway. It's free to do this. The code you quoted
> implements this -- it looks at what the min spacing is the peer wants,
> and then uses something bigger.
>
> So I still stand by what I said earlier -- you should not allow
> advertising a smaller value than the hardware wanted to use initially.
> If the AP doesn't use that smaller value, all is well, but if it
> actually uses a smaller value then the hardware might fall over.
Ok, I'll add that restriction. When this all settles, maybe I
can get some info from the ath9k folks about what their hardware
can actually support.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: Allow overriding some HT information.
From: Johannes Berg @ 2011-11-04 16:24 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB41014.6000002@candelatech.com>
On Fri, 2011-11-04 at 09:17 -0700, Ben Greear wrote:
> >>> The AMPDU density should only allow increasing.
> >>>
> >>> I think a lot of this validation should live in cfg80211 so if another
> >>> driver wants to implement it, this kind of thing is already covered.
> >>
> >> The ath9k driver supports 0, and then every value that corresponds to 1us or higher.
> >> If you set it to 1/2us, for instance, it just quietly rounds up to 1us. It defaults
> >> to 8, so it appears valid to decrease or increase this value.
> >
> > What quietly rounds up?
> >
> > If it defaults to 8 then I'm sure there's a reason for it, such as the
> > crypto engine not being fast enough and needing 8us buffer between
> > frames. As such, I really don't think decreasing it is valid.
>
> See this code in ath9k, top of main.c. It appears to support more
> than the default of 8. I tested it out, and it appears to work
> when set to lower values. I am disabling hw-crypt since I need
> multiple VIFS, but not sure that matters or not.
>
> static u8 parse_mpdudensity(u8 mpdudensity)
Well, this is used for TX. You're advertising the value for RX.
Advertising a smaller value may work for you -- but only if the AP uses
something larger anyway. It's free to do this. The code you quoted
implements this -- it looks at what the min spacing is the peer wants,
and then uses something bigger.
So I still stand by what I said earlier -- you should not allow
advertising a smaller value than the hardware wanted to use initially.
If the AP doesn't use that smaller value, all is well, but if it
actually uses a smaller value then the hardware might fall over.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-04 16:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB40EBB.9010402@candelatech.com>
On Fri, 2011-11-04 at 09:11 -0700, Ben Greear wrote:
> > I think maybe a single one would be sufficient, but you'd still have no
> > way of knowing what is actually supported for changing. Maybe you could
> > advertise an ht_mask of things that can be changed?
>
> That seems feasible, though it still won't help with the valid ranges
> for mpdu-density, for instance.
Well I still think that reducing the density is not feasible, so
userspace can query the HT info about the min and the mask to see if
what it can do.
> How about if I add some way to query this, but leave the code loose
> in that it won't fail if someone tries to set a value that isn't
> supported. That way, user-space can be lazy if it wants, but
> can also get the details if it cares.
Yeah, that seems like it would be a good way of doing it, although I
think I'd reject it if there's no such configuration possible at all.
> To get this info, I'm going to have to add a new driver API, as far
> as I can tell, and I only have the ability to deal with ath9k, so
> that will be the only driver that reports the mask. Of course,
> others could modify their drivers as they wish.
I think you just have to add the mask to the wiphy struct somewhere. And
the mask wouldn't be specific to ath9k since any mac80211 driver would
be able to deal with it, just no non-mac80211 driver.
You could just have a pointer to the mask in the wiphy struct and if
NULL then it's not allowed, if non-NULL the mask indicates what can be
changed.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: Allow overriding some HT information.
From: Ben Greear @ 2011-11-04 16:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320417690.3969.88.camel@jlt3.sipsolutions.net>
On 11/04/2011 07:41 AM, Johannes Berg wrote:
> On Thu, 2011-11-03 at 10:13 -0700, Ben Greear wrote:
>
>>> Here's another argument for splitting the patches differently -- this
>>> ought to be part of the disable HT40 patch.
>>
>> One thing I could do is move patch 3 to be the first patch. That gives this method
>> reason to exist, but I can leave out the disable-HT40 parts and (re)add that in
>> the disable-ht40 patch.
>
> I think the whole thing could just be one cfg80211 and one mac80211
> patch, wouldn't that make it simpler?
Ok, I will do that.
>>> The AMPDU density should only allow increasing.
>>>
>>> I think a lot of this validation should live in cfg80211 so if another
>>> driver wants to implement it, this kind of thing is already covered.
>>
>> The ath9k driver supports 0, and then every value that corresponds to 1us or higher.
>> If you set it to 1/2us, for instance, it just quietly rounds up to 1us. It defaults
>> to 8, so it appears valid to decrease or increase this value.
>
> What quietly rounds up?
>
> If it defaults to 8 then I'm sure there's a reason for it, such as the
> crypto engine not being fast enough and needing 8us buffer between
> frames. As such, I really don't think decreasing it is valid.
See this code in ath9k, top of main.c. It appears to support more
than the default of 8. I tested it out, and it appears to work
when set to lower values. I am disabling hw-crypt since I need
multiple VIFS, but not sure that matters or not.
static u8 parse_mpdudensity(u8 mpdudensity)
{
/*
* 802.11n D2.0 defined values for "Minimum MPDU Start Spacing":
* 0 for no restriction
* 1 for 1/4 us
* 2 for 1/2 us
* 3 for 1 us
* 4 for 2 us
* 5 for 4 us
* 6 for 8 us
* 7 for 16 us
*/
switch (mpdudensity) {
case 0:
return 0;
case 1:
case 2:
case 3:
/* Our lower layer calculations limit our precision to
1 microsecond */
return 1;
case 4:
return 2;
case 5:
return 4;
case 6:
return 8;
case 7:
return 16;
default:
return 0;
}
}
>> I was thinking that if ht-40 is disabled, then I should clear both the
>> IEEE80211_HT_CAP_SUP_WIDTH_20_40 and the IEEE80211_HT_CAP_SGI_40 from
>> the capabilities. Perhaps there are other flags I should clear as well?
>
> I don't know?
Well, it can always be changed later if I missed something. This code
should have no affect unless the users specifically enable the feature
anyway...and we'll be doing lots of testing on our systems at various
settings...
>>> I'm more and more coming to the conclusion that it would be clearer to
>>> make separate configuration items for the various things. Most
>>> capabilities you could only disable (greenfield, ...) except for maybe
>>> 40mhz-intol, so maybe that would be easier as a separate u16 attribute
>>> "disable these HT capabilities"?
>>
>> It seemed like more work for not much gain to me, but I don't mind splitting
>> it out into separate netlink configurables if you want.
>
> It just seems to me it would clarify the semantics. Not really sure I
> care all that much though.
If it's OK with you, I'll skip this for now. If anyone ever cares,
it would be easy enough to add.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v3] cfg80211: merge in beacon ies of hidden bss.
From: Dmitry Tarnyagin @ 2011-11-04 16:12 UTC (permalink / raw)
To: linux-wireless
The problem with PSM when a hidden SSID was used was originally
reported by Juuso Oikarinen.
- When generally scanning, the AP is getting a bss entry with
a zero SSID.
- When associationg, a probe-req is sent to the AP with the SSID,
and as a result a probe-responseis received with the hidden
SSID in place. As a consequence, a second bss entry is created
for the AP, now with the real SSID.
- After association, mac80211 executes ieee80211_recalc_ps(),
but does not switch to powersave because the beacon-ies are missing.
As result, the STA does not ever enter PSM.
The patch merges in beacon ies of hidden bss from beacon to the probe
response, creating a consistant set of ies in place.
Patch is depended on "cfg80211: fix cmp_ies" made by Johannes.
Signed-off-by: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
---
net/wireless/scan.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 2ab0aba..87d1432 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -328,8 +328,8 @@ static bool is_mesh(struct cfg80211_bss *a,
sizeof(struct ieee80211_meshconf_ie) - 2) == 0;
}
-static int cmp_bss(struct cfg80211_bss *a,
- struct cfg80211_bss *b)
+static int cmp_bss_core(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
{
int r;
@@ -351,7 +351,15 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
- r = memcmp(a->bssid, b->bssid, ETH_ALEN);
+ return memcmp(a->bssid, b->bssid, ETH_ALEN);
+}
+
+static int cmp_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ int r;
+
+ r = cmp_bss_core(a, b);
if (r)
return r;
@@ -362,6 +370,52 @@ static int cmp_bss(struct cfg80211_bss *a,
b->len_information_elements);
}
+static int cmp_hidden_bss(struct cfg80211_bss *a,
+ struct cfg80211_bss *b)
+{
+ const u8 *ie1;
+ const u8 *ie2;
+ int i;
+ int r;
+
+ r = cmp_bss_core(a, b);
+ if (r)
+ return r;
+
+ ie1 = cfg80211_find_ie(WLAN_EID_SSID,
+ a->information_elements,
+ a->len_information_elements);
+ ie2 = cfg80211_find_ie(WLAN_EID_SSID,
+ b->information_elements,
+ b->len_information_elements);
+
+ /* Key comparator must use same algorithm in any rb-tree
+ * search function (order is important), otherwise ordering
+ * of items in the tree is broken and search gives incorrect
+ * results. This code uses same order as cmp_ies() does. */
+
+ /* sort missing IE before (left of) present IE */
+ if (!ie1)
+ return -1;
+ if (!ie2)
+ return 1;
+
+ /* zero-size SSID is used as an indication of the hidden bss */
+ if (!ie2[1])
+ return 0;
+
+ /* sort by length first, then by contents */
+ if (ie1[1] != ie2[1])
+ return ie2[1] - ie1[1];
+
+ /* zeroed SSID ie is another indication of a hidden bss */
+ for (i = 0; i < ie2[1]; i++)
+ if (ie2[i + 2])
+ return -1;
+
+ return 0;
+}
+
struct cfg80211_bss *cfg80211_get_bss(struct wiphy *wiphy,
struct ieee80211_channel *channel,
const u8 *bssid,
@@ -478,6 +532,48 @@ rb_find_bss(struct cfg80211_registered_device *dev,
}
static struct cfg80211_internal_bss *
+rb_find_hidden_bss(struct cfg80211_registered_device *dev,
+ struct cfg80211_internal_bss *res)
+{
+ struct rb_node *n = dev->bss_tree.rb_node;
+ struct cfg80211_internal_bss *bss;
+ int r;
+
+ while (n) {
+ bss = rb_entry(n, struct cfg80211_internal_bss, rbn);
+ r = cmp_hidden_bss(&res->pub, &bss->pub);
+
+ if (r == 0)
+ return bss;
+ else if (r < 0)
+ n = n->rb_left;
+ else
+ n = n->rb_right;
+ }
+
+ return NULL;
+}
+
+static void
+copy_hidden_ies(struct cfg80211_internal_bss *res,
+ struct cfg80211_internal_bss *hidden)
+{
+ if (unlikely(res->pub.beacon_ies))
+ return;
+ if (WARN_ON(!hidden->pub.beacon_ies))
+ return;
+
+ res->pub.beacon_ies = kmalloc(hidden->pub.len_beacon_ies, GFP_ATOMIC);
+ if (unlikely(!res->pub.beacon_ies))
+ return;
+
+ res->beacon_ies_allocated = true;
+ res->pub.len_beacon_ies = hidden->pub.len_beacon_ies;
+ memcpy(res->pub.beacon_ies, hidden->pub.beacon_ies,
+ res->pub.len_beacon_ies);
+}
+
+static struct cfg80211_internal_bss *
cfg80211_bss_update(struct cfg80211_registered_device *dev,
struct cfg80211_internal_bss *res)
{
@@ -590,6 +686,21 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
kref_put(&res->ref, bss_release);
} else {
+ struct cfg80211_internal_bss *hidden;
+
+ /* First check if the beacon is a probe response from
+ * a hidden bss. If so, copy beacon ies (with nullified
+ * ssid) into the probe response bss entry (with real ssid).
+ * It is required basically for PSM implementation
+ * (probe responses do not contain tim ie) */
+
+ /* TODO: The code is not trying to update existing probe
+ * response bss entries when beacon ies are
+ * getting changed. */
+ hidden = rb_find_hidden_bss(dev, res);
+ if (hidden)
+ copy_hidden_ies(res, hidden);
+
/* this "consumes" the reference */
list_add_tail(&res->list, &dev->bss_list);
rb_insert_bss(dev, res);
--
With best regards,
Dmitry Tarnyagin
^ permalink raw reply related
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Ben Greear @ 2011-11-04 16:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1320417771.3969.90.camel@jlt3.sipsolutions.net>
On 11/04/2011 07:42 AM, Johannes Berg wrote:
> On Thu, 2011-11-03 at 11:17 -0700, Ben Greear wrote:
>
>> So back to the capabilities flag like I added in the -v2 patch?
>> Do you want one flag for each thing (set-mcs, disable-ht,
>> disable-ht40, set-mpdu, set-msdu), or maybe one flag for all of
>> this: set-ht-cap
>
> I think maybe a single one would be sufficient, but you'd still have no
> way of knowing what is actually supported for changing. Maybe you could
> advertise an ht_mask of things that can be changed?
That seems feasible, though it still won't help with the valid ranges
for mpdu-density, for instance.
How about if I add some way to query this, but leave the code loose
in that it won't fail if someone tries to set a value that isn't
supported. That way, user-space can be lazy if it wants, but
can also get the details if it cares.
To get this info, I'm going to have to add a new driver API, as far
as I can tell, and I only have the ability to deal with ath9k, so
that will be the only driver that reports the mask. Of course,
others could modify their drivers as they wish.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: mac80211: UAPSD - first release HW buffered frames next also check mac80211 buffered frames
From: Johannes Berg @ 2011-11-04 15:07 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless
In-Reply-To: <CAFED-jnG8+4U49scyEu8Yd7=WXFKGcrqcWw1EtTtaiVsQpwcdQ@mail.gmail.com>
On Fri, 2011-11-04 at 16:04 +0100, Janusz Dziedzic wrote:
> Hello,
>
> Seems currently we have implementation.
>
> if(!driver_release_tids) {
> ...
> } else {
> ...
> }
>
> Shouldn't we first release HW buffered frames and next check also SW
> buffered frames?
Only one of them can be true -- we don't release from driver & mac80211
queues at the same time. Technically we could, but the complexity would
be much higher than your simple patch for more-data handling etc.
johannes
^ permalink raw reply
* mac80211: UAPSD - first release HW buffered frames next also check mac80211 buffered frames
From: Janusz Dziedzic @ 2011-11-04 15:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
Hello,
Seems currently we have implementation.
if(!driver_release_tids) {
...
} else {
...
}
Shouldn't we first release HW buffered frames and next check also SW
buffered frames?
Please check patch:
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 8eaa746..1303bfd 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1328,7 +1328,33 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
return;
}
- if (!driver_release_tids) {
+ /* First release driver buffered frames */
+ if (driver_release_tids){
+ /*
+ * We need to release a frame that is buffered somewhere in the
+ * driver ... it'll have to handle that.
+ * Note that, as per the comment above, it'll also have to see
+ * if there is more than just one frame on the specific TID that
+ * we're releasing from, and it needs to set the more-data bit
+ * accordingly if we tell it that there's no more data. If we do
+ * tell it there's more data, then of course the more-data bit
+ * needs to be set anyway.
+ */
+ drv_release_buffered_frames(local, sta, driver_release_tids,
+ n_frames, reason, more_data);
+
+ /*
+ * Note that we don't recalculate the TIM bit here as it would
+ * most likely have no effect at all unless the driver told us
+ * that the TID became empty before returning here from the
+ * release function.
+ * Either way, however, when the driver tells us that the TID
+ * became empty we'll do the TIM recalculation.
+ */
+ }
+
+ /* Now check SW buffered frames */
+ /* This if (found) seems to be not required in final patch */
+ if (found) {
struct sk_buff_head pending;
struct sk_buff *skb;
int num = 0;
@@ -1387,28 +1413,6 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
ieee80211_add_pending_skbs(local, &pending);
sta_info_recalc_tim(sta);
- } else {
- /*
- * We need to release a frame that is buffered somewhere in the
- * driver ... it'll have to handle that.
- * Note that, as per the comment above, it'll also have to see
- * if there is more than just one frame on the specific TID that
- * we're releasing from, and it needs to set the more-data bit
- * accordingly if we tell it that there's no more data. If we do
- * tell it there's more data, then of course the more-data bit
- * needs to be set anyway.
- */
- drv_release_buffered_frames(local, sta, driver_release_tids,
- n_frames, reason, more_data);
-
BR
Janusz
^ permalink raw reply related
* Re: mac80211: UAPSD - seems MORE_DATA bit is not set in all cases
From: Johannes Berg @ 2011-11-04 14:57 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless
In-Reply-To: <CAFED-jmnK5qKG6pMUHC__8CnoJwaBoihV_U5p-JoyAH6VW1rNw@mail.gmail.com>
On Fri, 2011-11-04 at 15:49 +0100, Janusz Dziedzic wrote:
> Hello,
>
> Seems we don't set MORE_DATA bit correctly in
> ieee80211_sta_ps_deliver_response() fuction.
> In case we have more than one frame in struct sk_buff_head frames we
> don't set MORE_DATA bit.
>
> Proposed fix:
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index ce962d2..8eaa746 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -1354,12 +1354,12 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
> * Use MoreData flag to indicate whether there are
> * more buffered frames for this STA
> */
> - if (!more_data)
> - hdr->frame_control &=
> - cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
> - else
> + if (more_data || !skb_queue_empty(&frames))
> hdr->frame_control |=
> cpu_to_le16(IEEE80211_FCTL_MOREDATA);
> + else
> + hdr->frame_control &=
> + cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
>
> if (ieee80211_is_data_qos(hdr->frame_control) ||
> ieee80211_is_qos_nullfunc(hdr->frame_control))
>
Yeah that seems reasonable. Please submit a proper patch :-)
johannes
^ permalink raw reply
* Re: A new driver is going to be released
From: Larry Finger @ 2011-11-04 14:54 UTC (permalink / raw)
To: Dan Williams; +Cc: Dmitry Tarnyagin, linux-wireless
In-Reply-To: <1320372088.29008.0.camel@dcbw.foobar.com>
On 11/03/2011 09:01 PM, Dan Williams wrote:
> It looks like it's mac80211-based and already in drivers/staging/
> according to the git tree Dmitry pointed to.
A staging driver in a private tree is not the same as one in GregKH's staging
tree. As this cw1200 driver has been seen by a limited number of developers, it
needs to be submitted to staging in mainline before an attempt is made to
convert it to the regular tree.
Larry
^ permalink raw reply
* mac80211: UAPSD - seems MORE_DATA bit is not set in all cases
From: Janusz Dziedzic @ 2011-11-04 14:49 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
Hello,
Seems we don't set MORE_DATA bit correctly in
ieee80211_sta_ps_deliver_response() fuction.
In case we have more than one frame in struct sk_buff_head frames we
don't set MORE_DATA bit.
Proposed fix:
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index ce962d2..8eaa746 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1354,12 +1354,12 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
* Use MoreData flag to indicate whether there are
* more buffered frames for this STA
*/
- if (!more_data)
- hdr->frame_control &=
- cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
- else
+ if (more_data || !skb_queue_empty(&frames))
hdr->frame_control |=
cpu_to_le16(IEEE80211_FCTL_MOREDATA);
+ else
+ hdr->frame_control &=
+ cpu_to_le16(~IEEE80211_FCTL_MOREDATA);
if (ieee80211_is_data_qos(hdr->frame_control) ||
ieee80211_is_qos_nullfunc(hdr->frame_control))
BR
Janusz
^ permalink raw reply related
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-04 14:42 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB2DACE.2000707@candelatech.com>
On Thu, 2011-11-03 at 11:17 -0700, Ben Greear wrote:
> So back to the capabilities flag like I added in the -v2 patch?
> Do you want one flag for each thing (set-mcs, disable-ht,
> disable-ht40, set-mpdu, set-msdu), or maybe one flag for all of
> this: set-ht-cap
I think maybe a single one would be sufficient, but you'd still have no
way of knowing what is actually supported for changing. Maybe you could
advertise an ht_mask of things that can be changed?
> My opinion remains that we should silently ignore un-supported
> values..this way user-space works with the same config on old and new
> kernels. In future patches, we can report the actual settings via
> netlink or similar.
>
> But, I can add logic in user-space to detect kernel versions and
> such and deal with this.
Then you also wouldn't have to muck around with kernel version detection
etc. you could just query the mask of things that can be changed.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: Allow overriding some HT information.
From: Johannes Berg @ 2011-11-04 14:41 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB2CBCC.6080709@candelatech.com>
On Thu, 2011-11-03 at 10:13 -0700, Ben Greear wrote:
> > Here's another argument for splitting the patches differently -- this
> > ought to be part of the disable HT40 patch.
>
> One thing I could do is move patch 3 to be the first patch. That gives this method
> reason to exist, but I can leave out the disable-HT40 parts and (re)add that in
> the disable-ht40 patch.
I think the whole thing could just be one cfg80211 and one mac80211
patch, wouldn't that make it simpler?
> >> + /* Set the AMPDU density. */
> >> + if (sdata->u.mgd.ht_capa_mask.ampdu_params_info&
> >> + IEEE80211_HT_AMPDU_PARM_DENSITY)
> >> + ht_cap->ampdu_density =
> >> + (sdata->u.mgd.ht_capa.ampdu_params_info&
> >> + IEEE80211_HT_AMPDU_PARM_DENSITY)
> >> + >> IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT;
> >> +}
> >
> > The AMPDU density should only allow increasing.
> >
> > I think a lot of this validation should live in cfg80211 so if another
> > driver wants to implement it, this kind of thing is already covered.
>
> The ath9k driver supports 0, and then every value that corresponds to 1us or higher.
> If you set it to 1/2us, for instance, it just quietly rounds up to 1us. It defaults
> to 8, so it appears valid to decrease or increase this value.
What quietly rounds up?
If it defaults to 8 then I'm sure there's a reason for it, such as the
crypto engine not being fast enough and needing 8us buffer between
frames. As such, I really don't think decreasing it is valid.
> > I think there's a lot of data in the ht_cap struct that you don't use,
> > is that right? If so you should reject it being configured. I'm also not
> > quite sure why you support both disable-HT40, and then this setting here
> > that has SUP_WIDTH_20_40 too.
>
> If I add rejection like this, it will make writing backwards compat user
> space very difficult. It would be similar to rejecting unknown netlink
> attributes, for instance.
Good point.
> I was thinking that if ht-40 is disabled, then I should clear both the
> IEEE80211_HT_CAP_SUP_WIDTH_20_40 and the IEEE80211_HT_CAP_SGI_40 from
> the capabilities. Perhaps there are other flags I should clear as well?
I don't know?
> > I'm more and more coming to the conclusion that it would be clearer to
> > make separate configuration items for the various things. Most
> > capabilities you could only disable (greenfield, ...) except for maybe
> > 40mhz-intol, so maybe that would be easier as a separate u16 attribute
> > "disable these HT capabilities"?
>
> It seemed like more work for not much gain to me, but I don't mind splitting
> it out into separate netlink configurables if you want.
It just seems to me it would clarify the semantics. Not really sure I
care all that much though.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/3] mac80211: Support forcing station to disable HT (802.11n).
From: Johannes Berg @ 2011-11-04 14:38 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EB2CCD7.3010907@candelatech.com>
On Thu, 2011-11-03 at 10:18 -0700, Ben Greear wrote:
> >> --- a/net/mac80211/mlme.c
> >> +++ b/net/mac80211/mlme.c
> >
> > I'd rather split this up into cfg80211/mac80211. In fact, maybe
> > splitting it into one cfg80211 and one mac80211 patch, instead of three
> > different patches that span both might be worthwhile?
>
> I really don't care either way. Just let me know how you want it
> and I'll split it up thus. Just please do not change your mind later,
> splitting patches is nothing but work :P
:-)
Shouldn't be a lot of work to split along subsystems, though of course
API updates would have to be done right away.
johannes
^ permalink raw reply
* Re: Open80211s on Android -- iw EOPNOTSUPP error when trying to join mesh network?
From: Johannes Berg @ 2011-11-04 14:14 UTC (permalink / raw)
To: Kiran Karra; +Cc: linux wireless
In-Reply-To: <CAAaUcVxoeOVqXBfSH0WivmOg32yoXMOZTkStg1HxECkAJsv6+Q@mail.gmail.com>
On Fri, 2011-11-04 at 10:06 -0400, Kiran Karra wrote:
> # cd /system/lib/modules
> # insmod p54usb.ko
> The wireless driver loads fine. Next, if I type in:
> # iw phy0 info
> I get a lot of information about my wifi dongle's capabilities. In
> the "Supported interface modes" section, I see that "mesh point" is
> supported.
>
> After this, I do the command:
> # iw phy0 init
Since this doesn't exist upstream, all bets are off from this point on
and you're on your own.
johannes
^ permalink raw reply
* Open80211s on Android -- iw EOPNOTSUPP error when trying to join mesh network?
From: Kiran Karra @ 2011-11-04 14:06 UTC (permalink / raw)
To: linux wireless
Hi All,
I have been trying to get open80211s working on the Android platform
using the Beagleboard. I have a WiFi dongle, which works off the
p54usb driver, and have ported that successfully over to Android. I
have also built libnl1.1 and iw3.1 into my Android distribution.
Additionally, my kernel configuration (kernel version 2.6.37) has the
following options enabled under the NETWORKING --> WIRELESS section (I
removed the options that were not set in order to save space) :
#
# Network testing
#
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=y
CONFIG_NL80211_TESTMODE=y
CONFIG_CFG80211_DEVELOPER_
WARNINGS=y
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_WEXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=y
CONFIG_LIB80211_DEBUG=y
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG_MENU=y
Ok, so I have all the tools above built, and I go to load up the
Android OS on the beagleboard. Once the system comes up, I load the
p54usb wireless module as follows:
# cd /system/lib/modules
# insmod p54usb.ko
The wireless driver loads fine. Next, if I type in:
# iw phy0 info
I get a lot of information about my wifi dongle's capabilities. In
the "Supported interface modes" section, I see that "mesh point" is
supported.
After this, I do the command:
# iw phy0 init
After that, a wlan0 interface seems to be created. To check, I do:
# iw wlan0 info, and I get the printout:
Interface wlan0
ifindex 3
type managed
Next, following the instructions on the o11s.org website for how-to
setup a mesh point network, I type in:
# iw dev wlan0 interface add mesh0 type mp
# ifconfig mesh0 192.168.3.80
After this, I do
# iw dev mesh0 mesh join mymesh
This is when I get my error: command failed: Operation not supported
on transport endpoint (-95)
However, in my netcfg output, I can see that mesh0 is an interface
that is UP and has the IP address that I assigned it. I can also ping
the mesh0 interface from within the beagleboard on which the mesh
interface was created. I'm not sure if that means anything, but I
figured I'd throw it out there. The commands and the outputs of the
netcfg and the ping are shown below:
# netcfg
lo UP 127.0.0.1 255.0.0.0 0x00000049
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
wlan0 DOWN 0.0.0.0 0.0.0.0 0x00001002
mesh0 UP 192.168.3.80 255.255.255.0 0x00001043
# iw mesh0 info
Interface mesh0
ifindex 4
type mesh point
# ping 192.168.3.80
PING 192.168.3.80 (192.168.3.80) 56(84) bytes of data.
64 bytes from 192.168.3.80: icmp_seq=1 ttl=64 time=0.122 ms
64 bytes from 192.168.3.80: icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from 192.168.3.80: icmp_seq=3 ttl=64 time=0.122 ms
64 bytes from 192.168.3.80: icmp_seq=4 ttl=64 time=0.122 ms
^C
--- 192.168.3.80 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.061/0.106/0.122/0.029 ms
# iw dev $MESH_IFACE station dump
** NO RESPONSES ** meaning that this device is not participating in
mesh network??
Can anybody shed light as to why I am unable to join the mesh network
and getting the EOPNOTSUPP error? Any suggestions are greatly
appreciated.
Thanks in advance,
Kiran
^ permalink raw reply
* [PATCH] ath6kl: Fix error in writing create_qos debugfs
From: Vasanthakumar Thiagarajan @ 2011-11-04 13:04 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
100 bytes are allocated to store the parameters which are needed
to create a priority stream. These 100 bytes are not sufficiant and
throws error when running the following command.
echo "6 2 3 1 1 9999999 9999999 9999999 7777777 0 6 45000 200 56789000
56789000 5678900 0 0 9999999 20000 0" > create_qos
179 bytes are needed when the following vlaues are given so that
a maximum possible value in that data type can be given in decimal.
echo "255 255 255 255 255 4294967295 4294967295 4294967295 4294967295
4294967295 255 65535 65535 4294967295 4294967295 4294967295 4294967295
4294967295 4294967295 4294967295 4294967295" > create_qos
Following takes 187 bytes when given in hex
echo "0xff 0xff 0xff 0xff 0xff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xff 0xffff 0xffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xffffffff 0xffffffff" > create_qos
Increase the size to 200 bytes so that it can hold upto the maximum
value possible for that data type.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index 70ea137..370664a 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -1252,7 +1252,7 @@ static ssize_t ath6kl_create_qos_write(struct file *file,
struct ath6kl *ar = file->private_data;
struct ath6kl_vif *vif;
- char buf[100];
+ char buf[200];
ssize_t len;
char *sptr, *token;
struct wmi_create_pstream_cmd pstream;
--
1.7.0.4
^ permalink raw reply related
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