Re: BCM4313 brcmsmac 3.12: only semi-working?
On 19-11-14 22:00, Michael Tokarev wrote:
19.11.2014 22:58, Michael Tokarev wrote:
19.11.2014 20:54, Arend van Spriel wrote:
[]
I submitted two patches upstream and additionally I have attached two other
that are still under review. Could you try these patches and sent me the
content of the two debugfs files 'macstat' and 'hardware' after a stall has
occurred.
You didn't tell which kernel it is based on. So I tried it on 3.16,
Ok, I misunderstood you apparently, -- I only tried 2 patches,
while I should try all 4. So here it goes.
The hardware info again:
chipnum 0x4313
chiprev 0x1
chippackage 0x8
corerev 0x18
boardid 0x1795
boardvendor 0x103c
boardrev P107
boardflags 0x402201
boardflags2 0x884
ucoderev 0x262032c
radiorev 0x1
phytype 0x8
phyrev 0x1
anarev 0xa
nvramrev 8
Macstat:
txallfrm: 287
txrtsfrm: 118
txctsfrm: 25
txackfrm: 60
txdnlfrm: 0
txbcnfrm: 0
txfunfl[8]: 0 0 0 0 0 0 0 0
txtplunfl: 0
txphyerr: 0
pktengrxducast: 0
pktengrxdmcast: 0
rxfrmtoolong: 330
rxfrmtooshrt: 16
rxinvmachdr: 722
rxbadfcs: 4306
rxbadplcp: 7257
rxcrsglitch: 61757
rxstrt: 6667
rxdfrmucastmbss: 41
rxmfrmucastmbss: 25
rxcfrmucast: 116
rxrtsucast: 0
rxctsucast: 59
rxackucast: 19
rxdfrmocast: 70
rxmfrmocast: 84
rxcfrmocast: 211
rxrtsocast: 3
rxctsocast: 20
rxdfrmmcast: 9
rxmfrmmcast: 1486
rxcfrmmcast: 0
rxbeaconmbss: 377
rxdfrmucastobss: 0
rxbeaconobss: 1086
rxrsptmout: 94
bcntxcancl: 0
rxf0ovfl: 0
rxf1ovfl: 0
rxf2ovfl: 0
txsfovfl: 0
pmqovfl: 0
rxcgprqfrm: 0
rxcgprsqovfl: 0
txcgprsfail: 0
txcgprssuc: 0
prs_timeout: 0
rxnack: 0
frmscons: 0
txnack: 0
txglitch_nack: 38
txburst: 4
bphy_rxcrsglitch: 2
phywatchdog: 0
bphy_badplcp: 0
As far as I can see, the stats are never updated during stall,
no numbers are changing, at least while the download is waiting
for the next packet. Sometimes wpa_supplicant does something
little, so some stats gets updated, eg, this is how it looks like
after about 2..3 minutes:
txallfrm: 420
txrtsfrm: 201
txctsfrm: 25
txackfrm: 69
txdnlfrm: 0
txbcnfrm: 0
txfunfl[8]: 0 0 0 0 0 0 0 0
txtplunfl: 0
txphyerr: 0
pktengrxducast: 0
pktengrxdmcast: 0
rxfrmtoolong: 1908
rxfrmtooshrt: 73
rxinvmachdr: 4115
rxbadfcs: 15064
rxbadplcp: 42368
rxcrsglitch: 36620
rxstrt: 26393
rxdfrmucastmbss: 48
rxmfrmucastmbss: 27
rxcfrmucast: 158
rxrtsucast: 0
rxctsucast: 92
rxackucast: 25
rxdfrmocast: 113
rxmfrmocast: 390
rxcfrmocast: 962
rxrtsocast: 38
rxctsocast: 59
rxdfrmmcast: 48
rxmfrmmcast: 7681
rxcfrmmcast: 0
rxbeaconmbss: 1505
rxdfrmucastobss: 0
rxbeaconobss: 6059
rxrsptmout: 171
bcntxcancl: 0
rxf0ovfl: 0
rxf1ovfl: 0
rxf2ovfl: 0
txsfovfl: 0
pmqovfl: 0
rxcgprqfrm: 0
rxcgprsqovfl: 0
txcgprsfail: 0
txcgprssuc: 0
prs_timeout: 0
rxnack: 0
frmscons: 0
txnack: 0
txglitch_nack: 41
txburst: 4
bphy_rxcrsglitch: 5
phywatchdog: 0
bphy_badplcp: 0
This is with 3.18-tobe kernel (current Linus git).
Dunno if this is helpful or not...
Well, it shows tx looks ok, but with download there is not much of that
going on. At least no large packets. However, I did find some missing
pieces related to bt-coex. Given that you device is a wifi-bt combo card
that is likely an issue for you. One of the missing pieces looks in
sprom for parameters and that is provided by bcma. However, it does not
seem to extract bt-coex related stuff. So I have attached a patch based
on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that
content to me.
Regards,
Arend
Thanks,
/mjt
From 29cfa8ec164e2d742f98ddb2c5368b70540f5fab Mon Sep 17 00:00:00 2001
From: Arend van Spriel ar...@broadcom.com
Date: Sun, 23 Nov 2014 10:26:17 +0100
Subject: [PATCH] bcma: dump raw sprom content for debugging
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
drivers/bcma/sprom.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bcma/sprom.c b/drivers/bcma/sprom.c
index efb037f..0c246a4 100644
--- a/drivers/bcma/sprom.c
+++ b/drivers/bcma/sprom.c
@@ -129,10 +129,16 @@ static u8 bcma_sprom_crc(const u16 *sprom, size_t words)
int word;
u8 crc = 0xFF;
+ pr_debug(KBUILD_MODNAME sprom:);
for (word = 0; word words - 1; word++) {
+ if ((word % 10) == 0)
+ pr_debug(\n\t);
+ pr_debug(%04X , sprom[word]);
crc = bcma_crc8(crc, sprom[word] 0x00FF);
crc = bcma_crc8(crc, (sprom[word] 0xFF00) 8);
}
+ if ((word % 10) == 0)
+ pr_debug(\n);
crc = bcma_crc8(crc, sprom[words - 1] 0x00FF);
crc ^= 0xFF;
--
1.9.1
Re: [PATCH v3] ath3k: Add support of MCI 13d3:3408 bt device
After some testing on a few laptops it looks like the firmware loads always
correctly only using AR3012 variant.
So the correct patch follows
---
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index d85ced2..086240c 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -105,6 +105,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x13d3, 0x3393) },
{ USB_DEVICE(0x13d3, 0x3402) },
+{ USB_DEVICE(0x13d3, 0x3408) },
{ USB_DEVICE(0x13d3, 0x3432) },
/* Atheros AR5BBU12 with sflash firmware */
@@ -156,6 +157,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index edfc17b..091c813 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -182,6 +182,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
--
19.11.2014 13:06, Dmitry Tunin wrote:
It seems that I am too stupid.
It is neither AR3012 or AR3011 device.
It is AR9565 with sflash.
Probably it makes sense to do a separate section for these devices.
But still
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_IGNORE },
works better than
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
With the latter I have some issues with turning bt on and off.
19.11.2014 12:40, Michel Memeteau - EKIMIA wrote:
Hi,
I tried to understand why this 0x13d3, 0x3408 device support
wouldn't go in btusb as it's really close to IMC BT chip found in
Realtek Wifi devices which is on the path to go in btusb [1]
then I guess there is a lot of code that could be shared to support
all IMC usb devices in the btusb module.
Regards.
[1] https://github.com/lwfinger/rtl8723au_bt/tree/new
--
Michel Memeteau - Directeur.
Notre Boutique Ordinateurs GNU/Linux : http://shop.ekimia.fr
49 chemin de l'union 13720 La Bouilladisse - France.
Fixe : +33 (0) 972308334 Mobile : +33(0) 624808051
--
2014-11-19 7:46 GMT+01:00 Dmitry Tunin hanipouspi...@gmail.com:
Hi Marcel,
Here is information from /sys/kernel/debug/usb/devices
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3408 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I hope this mail client is OK now.
Add support for bluetooth MCI WB335 (AR9565) Wi-Fi+bt module.
It is AR3011 device according to iProduct == 0.
So btusb should be blacklisted
I submitted a wrong patch before asif it was an AR3012 device,
but it works both ways. This is the right one.
Signed-off-by: Dmitry Tuninhanipouspi...@gmail.com
---
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index d85ced2..3b53116 100644
--- a/drivers/bluetooth/ath3k.c
+++
[PATCH v3 2/3] cfg80211: allow wiphy specific regdomain management
From: Jonathan Doron j...@wizery.com
Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints, country-code IEs and hints from other devices on the same
system. Conversely, a self-managed wiphy does not share its regulatory
hints with other devices in the system. If a system contains several
devices, one or more of which are self-managed, there might be
contradictory regulatory settings between them. Usage of flag is
generally discouraged. Only use it if the FW/driver is incompatible
with non-locally originated hints.
A new API lets the driver send a complete regdomain, to be applied on
its wiphy only.
After a wiphy-specific regdomain change takes place, usermode will get
a new type of change notification. The regulatory core also takes care
enforce regulatory restrictions, in case some interfaces are on
forbidden channels.
Signed-off-by: Jonathan Doron jonathanx.do...@intel.com
Signed-off-by: Arik Nemtsov arikx.nemt...@intel.com
---
include/net/cfg80211.h | 16 +
include/net/regulatory.h | 19 +++
include/uapi/linux/nl80211.h | 5 +++
net/wireless/core.c | 8 +
net/wireless/nl80211.c | 80 ++--
net/wireless/nl80211.h | 1 +
net/wireless/reg.c | 59
7 files changed, 170 insertions(+), 18 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bb748c4..bfe630f 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3808,6 +3808,22 @@ const u8 *cfg80211_find_vendor_ie(unsigned int oui, u8
oui_type,
int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
/**
+ * regulatory_set_wiphy_regd_rtnl - set regdom info for self managed drivers
+ * @wiphy: the wireless device we want to process the regulatory domain on
+ * @rd: the regulatory domain informatoin to use for this wiphy
+ *
+ * Set the regulatory domain information for self-managed wiphys, only they
+ * may use this function. See %REGULATORY_WIPHY_SELF_MANAGED for more
+ * information.
+ *
+ * This function requires the caller to hold the rtnl_lock.
+ *
+ * Return: 0 on success. -EINVAL, -EPERM
+ */
+int regulatory_set_wiphy_regd_rtnl(struct wiphy *wiphy,
+ struct ieee80211_regdomain *rd);
+
+/**
* wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
* @wiphy: the wireless device we want to process the regulatory domain on
* @regd: the custom regulatory domain to use for this wiphy
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index 701177c..d69c3db 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -141,6 +141,24 @@ struct regulatory_request {
* change, the interfaces are given a grace period to disconnect or move
* to an allowed channels. Interfaces on forbidden channels are forcibly
* disconnected.
+ * @REGULATORY_WIPHY_SELF_MANAGED: for devices that employ wiphy-specific
+ * regdom management. These devices will ignore all regdom changes not
+ * originating from their own wiphy.
+ * A self-managed wiphys only employs regulatory information obtained from
+ * the FW and driver and does not use other cfg80211 sources like
+ * beacon-hints, country-code IEs and hints from other devices on the same
+ * system. Conversely, a self-managed wiphy does not share its regulatory
+ * hints with other devices in the system. If a system contains several
+ * devices, one or more of which are self-managed, there might be
+ * contradictory regulatory settings between them. Usage of flag is
+ * generally discouraged. Only use it if the FW/driver is incompatible
+ * with non-locally originated hints.
+ * This flag is incompatible with the flags: %REGULATORY_CUSTOM_REG,
+ * %REGULATORY_STRICT_REG, %REGULATORY_COUNTRY_IE_FOLLOW_POWER,
+ * %REGULATORY_COUNTRY_IE_IGNORE and %REGULATORY_DISABLE_BEACON_HINTS.
+ * Mixing any of the above flags with this flag will result in a failure
+ * to register the wiphy. This flag implies
+ * %REGULATORY_DISABLE_BEACON_HINTS.
*/
enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG = BIT(0),
@@ -150,6 +168,7 @@ enum ieee80211_regulatory_flags {
REGULATORY_COUNTRY_IE_IGNORE= BIT(4),
REGULATORY_ENABLE_RELAX_NO_IR = BIT(5),
REGULATORY_ENFORCE_CHANNELS = BIT(6),
+ REGULATORY_WIPHY_SELF_MANAGED = BIT(7),
};
struct ieee80211_freq_range {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index d775245..3771e7d 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -774,6 +774,9 @@
* peer given by %NL80211_ATTR_MAC. Both peers
pull request: iwlwifi 2014-11-23
Hi John, I have a trivial patch for 3.18. details below. Thanks! The following changes since commit 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b: iwlwifi: pcie: fix prph dump length (2014-11-11 07:24:57 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-john-2014-11-23 for you to fetch changes up to 5ac6c72e594471acfa5b00210c51d533a73413ad: iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands (2014-11-23 21:50:57 +0200) Not all the firmware know how to handle the HOT_SPOT_CMD. Make sure that the firmware will know this command before sending it. This avoids a firmware crash. Luciano Coelho (1): iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands drivers/net/wireless/iwlwifi/iwl-fw.h | 2 ++ drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +--- 2 files changed, 11 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands
From: Luciano Coelho luciano.coe...@intel.com
Older firmwares do not provide support for the HOT_SPOT_CMD command.
Check for the appropriate TLV flag that declares hotspot support in
the firmware to prevent a firmware assertion failure that can be
triggered from the userspace,
Cc: sta...@vger.kernel.org [3.17+]
Signed-off-by: Luciano Coelho luciano.coe...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-fw.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw.h
b/drivers/net/wireless/iwlwifi/iwl-fw.h
index 4f6e668..b894a84 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@ -155,6 +155,7 @@ enum iwl_ucode_tlv_api {
* @IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT: supports Quiet Period requests
* @IWL_UCODE_TLV_CAPA_DQA_SUPPORT: supports dynamic queue allocation (DQA),
* which also implies support for the scheduler configuration command
+ * @IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT: supports Hot Spot Command
*/
enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_D0I3_SUPPORT = BIT(0),
@@ -163,6 +164,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_WFA_TPC_REP_IE_SUPPORT = BIT(10),
IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT = BIT(11),
IWL_UCODE_TLV_CAPA_DQA_SUPPORT = BIT(12),
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT = BIT(18),
};
/* The default calibrate table size if not specified by firmware file */
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index b624058..b6d2683 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -2448,9 +2448,15 @@ static int iwl_mvm_roc(struct ieee80211_hw *hw,
switch (vif-type) {
case NL80211_IFTYPE_STATION:
- /* Use aux roc framework (HS20) */
- ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
- vif, duration);
+ if (mvm-fw-ucode_capa.capa[0]
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT) {
+ /* Use aux roc framework (HS20) */
+ ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
+ vif, duration);
+ goto out_unlock;
+ }
+ IWL_ERR(mvm, hotspot not supported\n);
+ ret = -EINVAL;
goto out_unlock;
case NL80211_IFTYPE_P2P_DEVICE:
/* handle below */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ath10k patches
From: Sujith Manoharan c_man...@qca.qualcomm.com Fixes for WEP. Sujith Manoharan (3): ath10k: Fix shared WEP ath10k: Fix locking for WEP keys ath10k: Fix bug reported by lockdep drivers/net/wireless/ath/ath10k/mac.c | 31 +-- drivers/net/wireless/ath/ath10k/mac.h | 2 ++ drivers/net/wireless/ath/ath10k/wmi.c | 33 + 3 files changed, 64 insertions(+), 2 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Linux kernel 3.12 PN-KEY Mismatch in wpa.c, packet drop
Thank you Johannes for your response. Since we were facing this issue, i looked at the available patches. None solved the issue for us. I may be missing something, can you please let me know if the solution for this is already available? Any inputs much appreciated. regards On Fri, Nov 21, 2014 at 8:49 PM, Johannes Berg johan...@sipsolutions.net wrote: On Fri, 2014-11-21 at 20:42 +0530, deepak kumar Pradhan wrote: Hi, Sorry for interrupting you. The below patch do recovers from pn-key mismatch in kernel 3.12 kernel packet drop issue. I don't know where I need to submit this patch for proper solution. This is the right place for submitting a proper solution, but I believe you've already been told that what you're doing isn't a proper solution at all. johannes -- Deepak Kumar Pradhan -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
