jeremy lansman | 24 Oct 21:05 2014
Picon

Channel Estimation Question

Hi.

I beg your pardon for asking a newbe question...but..here goes anyway.

My problem is with an Intel Advanced 6230.  I have noted over the year + 
I have used it under Ubuntu that it seems to have a problem when I move 
the laptop.  This is consistent with a channel estimation (tap 
equalizer) issue under COFDM modulation.
No, I do not know about wi-fi, and I do not relish digging into driver 
stuff.  But I do know digital RF in general.
If it is going to take more hoursout of my life , maybe I should buy an 
external wi-fi for the lap top and put up with the resultant klutz.

This is ping to my AP after I move about:
64 bytes from 10.5.50.1: icmp_seq=509 ttl=64 time=1057 ms
64 bytes from 10.5.50.1: icmp_seq=510 ttl=64 time=5382 ms
64 bytes from 10.5.50.1: icmp_seq=511 ttl=64 time=4386 ms
64 bytes from 10.5.50.1: icmp_seq=512 ttl=64 time=3383 ms
64 bytes from 10.5.50.1: icmp_seq=513 ttl=64 time=2376 ms
64 bytes from 10.5.50.1: icmp_seq=514 ttl=64 time=1438 ms
64 bytes from 10.5.50.1: icmp_seq=515 ttl=64 time=433 ms
64 bytes from 10.5.50.1: icmp_seq=516 ttl=64 time=823 ms
64 bytes from 10.5.50.1: icmp_seq=517 ttl=64 time=1533 ms

This is if I sit still a while:
64 bytes from 10.5.50.1: icmp_seq=583 ttl=64 time=1.18 ms
64 bytes from 10.5.50.1: icmp_seq=584 ttl=64 time=1.79 ms
64 bytes from 10.5.50.1: icmp_seq=585 ttl=64 time=0.871 ms
64 bytes from 10.5.50.1: icmp_seq=586 ttl=64 time=2.96 ms
64 bytes from 10.5.50.1: icmp_seq=587 ttl=64 time=1.28 ms
(Continue reading)

greearb | 24 Oct 20:12 2014

[PATCH] mac80211-hwsim: support SGI-20

From: Ben Greear <greearb@...>

This lets hostapd start if you have SGI-20 configured
as one of your HT capabilities.

Signed-off-by: Ben Greear <greearb@...>
---
 drivers/net/wireless/mac80211_hwsim.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 19ecf29..8ad82b0 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
 <at>  <at>  -2168,6 +2168,7  <at>  <at>  static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
 		sband->ht_cap.ht_supported = true;
 		sband->ht_cap.cap = IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
 				    IEEE80211_HT_CAP_GRN_FLD |
+				    IEEE80211_HT_CAP_SGI_20 |
 				    IEEE80211_HT_CAP_SGI_40 |
 				    IEEE80211_HT_CAP_DSSSCCK40;
 		sband->ht_cap.ampdu_factor = 0x3;
--

-- 
1.7.11.7

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

(Continue reading)

Ben Greear | 24 Oct 18:42 2014

Question phy capabilities in 'iw'

Here is the capabilities list from an mac80211_hwsim driver.

I am curious what information this is actually trying to convey.

For instance, why is AP in two different places, with different
values (2048 in first section, 8 in second) ?

	valid interface combinations:
		 * #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 2048,
		   total <= 2048, #channels <= 1
		 * #{ AP } <= 8,
		   total <= 8, #channels <= 1, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

Thanks,
Ben

--

-- 
Ben Greear <greearb@...>
Candela Technologies Inc  http://www.candelatech.com

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

Ali Abedi | 24 Oct 18:04 2014
Picon
Picon

strange MPDU loss pattern

Hello,

We study the effects of 802.11n frame aggregation on throughput. We 
noticed a
strange pattern in the MPDU loss within an aggregated frame. It seems 
that the
second half of the MPDUs (those with higher sequence numbers) in an 
aggregated frame
are more likely to be lost. Is this a known fact or is there any 
explanation for it?

For example if 32 frames are aggregated with sequence numbers 100 to 131.
Frames with sequence numbers 100-115 are more likely to be received 
correctly
than 116-131.

Best,
Ali
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

greearb | 24 Oct 17:35 2014

[PATCH v2] iw: support setting vif MAC during creation

From: Ben Greear <greearb@...>

This saves an extra call to change it later, and will
also keep udev from potentially messing with a vif
it should not be messing with.

Signed-off-by: Ben Greear <greearb@...>
---

v2:  Removed header changes per request.

 info.c      |  2 ++
 interface.c | 20 ++++++++++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/info.c b/info.c
index c5917d7..6244218 100644
--- a/info.c
+++ b/info.c
 <at>  <at>  -558,6 +558,8  <at>  <at>  broken_combination:
 			printf("\tDevice supports scan flush.\n");
 		if (features & NL80211_FEATURE_AP_SCAN)
 			printf("\tDevice supports AP scan.\n");
+		if (features & NL80211_FEATURE_MAC_ON_CREATE)
+			printf("\tDevice supports configuring vdev MAC-addr on create.\n");
 	}

 	if (tb_msg[NL80211_ATTR_TDLS_SUPPORT])
diff --git a/interface.c b/interface.c
index f769752..f8e39b3 100644
(Continue reading)

Adrien Decostre | 24 Oct 17:23 2014
Picon

Questions regarding ath9k and new EN 300 328 regulation

Dear all,

I am looking for information about the compliancy of the ath9k driver
to the EN 300 328 ETSI regulation.

Would someone know if ath9k has already been tested for this regulation?

Is it needed to enable any specific flag in ath9k to guarantee
compliancy to the adaptivity tests described in EN 300 328?

I already tried by applying the patches “ath9k: Fix regulatory
compliance” (http://www.spinics.net/lists/linux-wireless/msg115798.html)
 and “ath9k: Fix ETSI compliance for AR9462 2.0”
(http://www.spinics.net/lists/linux-wireless/msg118665.html) but this
does not seem to be sufficient.

Many thanks in advance for any help

Best regards
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Petko Manolov | 24 Oct 16:34 2014

iwlmwm dump

	Hi guys,

Since this is happening regularly on my machine i thought you might be interested.

cheers,
Petko

[    3.788633] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7260-10.ucode failed with error -2
[    3.790849] iwlwifi 0000:01:00.0: loaded firmware version 23.214.9.0 op_mode iwlmvm

[ 1057.767587] ------------[ cut here ]------------
[ 1057.767609] WARNING: CPU: 0 PID: 3524 at drivers/net/wireless/iwlwifi/mvm/tx.c:190
iwl_mvm_set_tx_params+0x57a/0x5d0 [iwlmvm]()
[ 1057.767611] Got an HT rate for a non data frame 0x8
[ 1057.767613] Modules linked in: kvm_intel kvm microcode iwlmvm iwlwifi
[ 1057.767626] CPU: 0 PID: 3524 Comm: wpa_supplicant Not tainted 3.17.1 #38
[ 1057.767628] Hardware name: LENOVO 20266/Yoga2, BIOS 76CN27WW 09/17/2013
[ 1057.767630]  0000000000000009 ffffffff8155934f ffff880097a0b958 ffffffff8106768d
[ 1057.767636]  0000000000001808 ffff880097a0b9a8 ffff88025483e5e0 ffff880097735d00
[ 1057.767640]  0000000000000000 ffffffff810676f7 ffffffffa0034638 ffff880200000020
[ 1057.767645] Call Trace:
[ 1057.767660]  [<ffffffff8155934f>] ? dump_stack+0x41/0x51
[ 1057.767666]  [<ffffffff8106768d>] ? warn_slowpath_common+0x6d/0x90
[ 1057.767670]  [<ffffffff810676f7>] ? warn_slowpath_fmt+0x47/0x50
[ 1057.767679]  [<ffffffff811d9e6a>] ? crypto_ccm_init_tfm+0x4a/0xa0
[ 1057.767688]  [<ffffffffa00245ba>] ? iwl_mvm_set_tx_params+0x57a/0x5d0 [iwlmvm]
[ 1057.767696]  [<ffffffffa0024838>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
[ 1057.767703]  [<ffffffffa001db4b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
[ 1057.767709]  [<ffffffff8153bfc9>] ? __ieee80211_tx+0x2b9/0x3c0
[ 1057.767714]  [<ffffffff8153e3d3>] ? ieee80211_tx+0xb3/0x100
(Continue reading)

Kalle Valo | 24 Oct 13:44 2014

Pull request: ath 20141024

Hi John,

here are the latest ath10k patches plus a small logging change to ath6kl
and wil6210. Unfortunately this time there's a small conflict in
drivers/net/wireless/ath/wil6210/wil6210.h but luckily it's easy to fix.
Here's an example how I propose to resolve it:

----------------------------------------------------------------------
#define wil_to_ndev(i) (wil_to_wdev(i)->netdev)
#define ndev_to_wil(n) (wdev_to_wil(n->ieee80211_ptr))
#define wil_to_pcie_dev(i) (&i->pdev->dev)

__printf(2, 3)
void wil_dbg_trace(struct wil6210_priv *wil, const char *fmt, ...);
__printf(2, 3)
void wil_err(struct wil6210_priv *wil, const char *fmt, ...);
__printf(2, 3)
void wil_info(struct wil6210_priv *wil, const char *fmt, ...);
#define wil_dbg(wil, fmt, arg...) do { \
	netdev_dbg(wil_to_ndev(wil), fmt, ##arg); \
	wil_dbg_trace(wil, fmt, ##arg); \
} while (0)

#define wil_dbg_irq(wil, fmt, arg...) wil_dbg(wil, "DBG[ IRQ]" fmt, ##arg)
#define wil_dbg_txrx(wil, fmt, arg...) wil_dbg(wil, "DBG[TXRX]" fmt, ##arg)
----------------------------------------------------------------------

I think a lesson learned here is that I should not apply patches which
touch wil6210 and instead ask the submitter to split the patch. Sorry
for this.
(Continue reading)

Johannes Berg | 23 Oct 20:35 2014
Picon

pull-request: mac80211 2014-10-23

John,

Please pull the below changes for the current 3.18 preparations. More
details below.

Thanks,
johannes

---

The following changes since commit
35a9ad8af0bb0fa3525e6d0d20e32551d226f38e:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2014-10-08 21:40:54 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
tags/mac80211-for-john-2014-10-23

for you to fetch changes up to 11b2357d5dbce999803e9055f8c09829a8a87db4:

  mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
(2014-10-20 16:37:01 +0200)

----------------------------------------------------------------
Here are a few fixes for the wireless stack: one fixes the
RTS rate, one for a debugfs file, one to return the correct
channel to userspace, a sanity check for a userspace value
and the remaining two are just documentation fixes.
(Continue reading)

Ben Greear | 23 Oct 18:53 2014

mac80211-hwsim question

From what I can tell, when hwsim sends frames to wmediumd using netlink sockets,
it does not include any channel/frequency information in the netlink packet.

Any reason not to add that?

Thanks,
Ben

--

-- 
Ben Greear <greearb@...>
Candela Technologies Inc  http://www.candelatech.com

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

Larry Finger | 23 Oct 18:27 2014
Picon

[PATCH V3.18] rtlwifi: Add check for get_btc_status callback

Drivers that do not use the get_btc_status() callback may not define a
dummy routine. The caller needs to check before making the call.

Signed-off-by: Larry Finger <Larry.Finger@...>
Cc: Murilo Opsfelder Araujo <mopsfelder@...>
Cc: Mike Galbraith <umgwanakikbuti@...>
Cc: Thadeu Cascardo <cascardo@...>
---

John,

This missing statement is causing kernel crashes for several of the drivers.
This patch should be applied ASAP.

Larry
---

 drivers/net/wireless/rtlwifi/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 667aba8..25daa87 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
 <at>  <at>  -1796,7 +1796,8  <at>  <at>  static int rtl_pci_start(struct ieee80211_hw *hw)
 	rtl_pci_reset_trx_ring(hw);

 	rtlpci->driver_is_goingto_unload = false;
-	if (rtlpriv->cfg->ops->get_btc_status()) {
+	if (rtlpriv->cfg->ops->get_btc_status &&
(Continue reading)


Gmane