Re: Troubleshooting mwl8k driver issue
Hello Lennert and David Sorry for jumping and recalling directly your conversation, but this already contains a lot of relevant information. I am an user of two Linksys EA4500 running mwl8k driver on Marvell 88W8366 v48 bot 2.4 and 5.0 Ghz radio. I run LEDE 17.01.1 I have always hit the problem you were discussing, which is become now so worse that the AP is almost unusable. The affected clients are two android devices (6.1 and 7.0) and iPhone 7. However together with the below disconnect issue, there is something else that may be connected to this problem that happens 100% of the time with all the devices you may try: The 5Ghz radio cannot authenticate in EAP (PEAP+mschapv2) mode. The 2.4Ghz radio of mwl8k and other atheros router I have works perfectly, so the freeradius I use (tried both 2.2 and 3.0) is ok. According to the logs, it seems that for some reason the radio cannoct complete the certificates handshake: Wed May 3 21:17:26 2017 : Debug: Going to the next request Wed May 3 21:17:26 2017 : Debug: Waking up in 4.9 seconds. Wed May 3 21:17:31 2017 : Info: Cleaning up request 34 ID 41 with timestamp +574 Wed May 3 21:17:31 2017 : Info: Cleaning up request 35 ID 42 with timestamp +574 Wed May 3 21:17:31 2017 : Info: Cleaning up request 36 ID 43 with timestamp +574 Wed May 3 21:17:31 2017 : Debug: WARNING: !! Wed May 3 21:17:31 2017 : Debug: WARNING: !! EAP session for state 0xd1f19d03d34c849e did not finish! Wed May 3 21:17:31 2017 : Debug: WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility Wed May 3 21:17:31 2017 : Debug: WARNING: !! Wed May 3 21:17:31 2017 : Info: Ready to process requests. In WPA2-PSK mode the disconnection show exactly the same logs David already provided. It is like that the physical layer is not stable enough which cause critical fault in EAP mode and the rekey issue in PSK mode, or something like this. Also, something happened during the transition between snapshot and 17.01 LEDE build, because with snapshot builds from November 2016 the stability was much better, I got disconnection every 30min or even more, now I cannot last more than 2/3 minutes. I am here to provide logs, but if you still have some mwl8k device, the EAP issue can probably be a good starting point for the investigation. Bye > The only thing the log tells me is that this disconnect happens > voluntarily, so I see nothing wrong from just those log messages. > Can you run a sniffer to see what happens on the air when this > disconnect occurs, or increase hostapd verbosity/debugging somehow? I've given hostapd logging a shot. The first 3 logs attached (hostapd_debug-hostap_debug3) are syslogs with logging all the way up. The last one is hostapd being run with the -dd flag. All three of the events have slightly different logs but they're all related to that WPA rekeying event. This is a shot in the dark here, but given that they look to be related to late or missing responses to the rekeying maybe it's the wireless device being slow, or just slow enough to not be able to keep up with the AP? I could build a hostapd with the timeout increased but I don't know if that's a good idea or the right approach here. -- David Gilman :DG< http://gilslotd.com --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=hostapd_debug Mon Jun 27 02:14:05 2016 daemon.debug hostapd: wlan1: WPA rekeying GTK Mon Jun 27 02:14:05 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:06 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:06 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:07 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:07 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:08 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:08 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: WPA_PTK: sm->Disconnect Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: event 3 notification Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.1X: unauthorizing port Mon Jun 27 02:14:11 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DEAUTHENTICATE.indication((bad phone), 2) Mon Jun 27 02:14:11 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DELETEKEYS.request((bad phone)) Mon Jun 27 02:14:11 2016 kern.debug kernel: [ 1952.642536]
Re: Troubleshooting mwl8k driver issue
> The only thing the log tells me is that this disconnect happens > voluntarily, so I see nothing wrong from just those log messages. > Can you run a sniffer to see what happens on the air when this > disconnect occurs, or increase hostapd verbosity/debugging somehow? I've given hostapd logging a shot. The first 3 logs attached (hostapd_debug-hostap_debug3) are syslogs with logging all the way up. The last one is hostapd being run with the -dd flag. All three of the events have slightly different logs but they're all related to that WPA rekeying event. This is a shot in the dark here, but given that they look to be related to late or missing responses to the rekeying maybe it's the wireless device being slow, or just slow enough to not be able to keep up with the AP? I could build a hostapd with the timeout increased but I don't know if that's a good idea or the right approach here. -- David Gilman :DG< http://gilslotd.com Mon Jun 27 02:14:05 2016 daemon.debug hostapd: wlan1: WPA rekeying GTK Mon Jun 27 02:14:05 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:06 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:06 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:07 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:07 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:08 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:08 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/2 msg of Group Key Handshake Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: EAPOL-Key timeout Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: WPA_PTK: sm->Disconnect Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: event 3 notification Mon Jun 27 02:14:09 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.1X: unauthorizing port Mon Jun 27 02:14:11 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DEAUTHENTICATE.indication((bad phone), 2) Mon Jun 27 02:14:11 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DELETEKEYS.request((bad phone)) Mon Jun 27 02:14:11 2016 kern.debug kernel: [ 1952.642536] ieee80211 phy1: Deleted BA stream index 0 Mon Jun 27 02:14:11 2016 kern.debug kernel: [ 1952.642565] ieee80211 phy1: Remove stream for (bad phone) 0 Mon Jun 27 02:14:14 2016 daemon.info hostapd: wlan1: STA (bad phone) IEEE 802.11: deauthenticated due to local deauth request Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.11: authentication OK (open system) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-AUTHENTICATE.indication((bad phone), OPEN_SYSTEM) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DELETEKEYS.request((bad phone)) Mon Jun 27 02:14:29 2016 daemon.info hostapd: wlan1: STA (bad phone) IEEE 802.11: authenticated Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.11: association OK (aid 1) Mon Jun 27 02:14:29 2016 daemon.info hostapd: wlan1: STA (bad phone) IEEE 802.11: associated (aid 1) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-ASSOCIATE.indication((bad phone)) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) MLME: MLME-DELETEKEYS.request((bad phone)) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.11: binding station to interface 'wlan1' Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: event 1 notification Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: start authentication Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.1X: unauthorizing port Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 1/4 msg of 4-Way Handshake Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: received EAPOL-Key frame (2/4 Pairwise) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: sending 3/4 msg of 4-Way Handshake Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) WPA: received EAPOL-Key frame (4/4 Pairwise) Mon Jun 27 02:14:29 2016 daemon.debug hostapd: wlan1: STA (bad phone) IEEE 802.1X: authorizing port Mon Jun 27 02:14:29 2016 daemon.info hostapd: wlan1: STA (bad phone) WPA: pairwise key handshake completed (RSN) Mon Jun 27 02:14:30 2016 daemon.info dnsmasq-dhcp[2989]: DHCPREQUEST(br-lan) 192.168.1.138 (bad phone) Mon Jun 27 02:14:30 2016 daemon.info dnsmasq-dhcp[2989]: DHCPACK(br-lan) 192.168.1.138 (bad phone) android-63ebbc936f7b53af Mon Jun 27 02:24:05 2016 daemon.debug hostapd: wlan1: WPA
Re: Troubleshooting mwl8k driver issue
On Mon, Jun 20, 2016 at 07:36:30PM -0500, David Gilman wrote: > > Nothing in here seems particularly bad. So whatever the problem is, > > I don't think it can be diagnosed from these messages alone. > > > > I went back to the email thread, and it seems that the problem is that > > you're trying to run the card in AP mode but no traffic is making it > > through? Is AP association working at all, or is that failing too? > > The mwl8k is in AP mode and it gets associated just fine. It'll work > for five or so minutes and then you'll get the disconnect and the log > messages in the earlier emails. And it only happens with one of my > wireless devices - the other one will browse all day with a stable > connection to the mwl8k router. > > Back in the OpenWRT issue a few more people have stuck their heads in > to say they're also seeing the same issue. > > https://dev.openwrt.org/ticket/21284 The only thing the log tells me is that this disconnect happens voluntarily, so I see nothing wrong from just those log messages. Can you run a sniffer to see what happens on the air when this disconnect occurs, or increase hostapd verbosity/debugging somehow? -- 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: Troubleshooting mwl8k driver issue
On Sat, Jun 18, 2016 at 11:48:28AM +0300, Lennert Buytenhek wrote: > Nothing in here seems particularly bad. So whatever the problem is, > I don't think it can be diagnosed from these messages alone. > > I went back to the email thread, and it seems that the problem is that > you're trying to run the card in AP mode but no traffic is making it > through? Is AP association working at all, or is that failing too? The mwl8k is in AP mode and it gets associated just fine. It'll work for five or so minutes and then you'll get the disconnect and the log messages in the earlier emails. And it only happens with one of my wireless devices - the other one will browse all day with a stable connection to the mwl8k router. Back in the OpenWRT issue a few more people have stuck their heads in to say they're also seeing the same issue. https://dev.openwrt.org/ticket/21284 -- David Gilman :DG< http://gilslotd.com -- 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: Troubleshooting mwl8k driver issue
On Fri, Jun 17, 2016 at 02:43:03PM -0500, David Gilman wrote: > > As an aside I semi-bricked my router and I'm currently unable to flash > > new images > > I've got my hardware and toolchain back up and running. Here's the > output from the unpatched `iw event -t': > > 1466191960.919661: wlan1: del station fc:c2:de:ac:b1:72 > 1466191966.842698: wlan1 (phy #1): mgmt TX status (cookie 2b): acked > 1466192016.283846: wlan1 (phy #1): mgmt TX status (cookie 2c): acked > 1466192016.284036: wlan1 (phy #1): mgmt TX status (cookie 2d): acked > 1466192016.285194: wlan1 (phy #1): mgmt TX status (cookie 2e): acked > 1466192016.313091: wlan1 (phy #1): mgmt TX status (cookie 2f): acked > 1466192016.369315: wlan1 (phy #1): mgmt TX status (cookie 30): acked > 1466192016.390064: wlan1 (phy #1): mgmt TX status (cookie 31): acked > 1466192016.392064: wlan1: new station fc:c2:de:ac:b1:72 > > And the corresponding syslog output: > > Fri Jun 17 19:32:40 2016 kern.debug kernel: [ 3027.270339] ieee80211 phy1: > Deleted BA stream index 0 > Fri Jun 17 19:32:40 2016 kern.debug kernel: [ 3027.270367] ieee80211 phy1: > Remove stream for fc:c2:de:ac:b1:72 0 > Fri Jun 17 19:32:43 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 > IEEE 802.11: deauthenticated due to local deauth request > Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 > IEEE 802.11: authenticated > Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 > IEEE 802.11: associated (aid 1) > Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 > WPA: pairwise key handshake completed (RSN) > Fri Jun 17 19:33:37 2016 daemon.info dnsmasq-dhcp[2668]: DHCPREQUEST(br-lan) > 192.168.1.138 fc:c2:de:ac:b1:72 > Fri Jun 17 19:33:37 2016 daemon.info dnsmasq-dhcp[2668]: DHCPACK(br-lan) > 192.168.1.138 fc:c2:de:ac:b1:72 android-63ebbc936f7b53af > > So where to go from here? Nothing in here seems particularly bad. So whatever the problem is, I don't think it can be diagnosed from these messages alone. I went back to the email thread, and it seems that the problem is that you're trying to run the card in AP mode but no traffic is making it through? Is AP association working at all, or is that failing too? -- 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: Troubleshooting mwl8k driver issue
On Thu, Jun 09, 2016 at 11:02:47PM -0500, David Gilman wrote: > As an aside I semi-bricked my router and I'm currently unable to flash > new images I've got my hardware and toolchain back up and running. Here's the output from the unpatched `iw event -t': 1466191960.919661: wlan1: del station fc:c2:de:ac:b1:72 1466191966.842698: wlan1 (phy #1): mgmt TX status (cookie 2b): acked 1466192016.283846: wlan1 (phy #1): mgmt TX status (cookie 2c): acked 1466192016.284036: wlan1 (phy #1): mgmt TX status (cookie 2d): acked 1466192016.285194: wlan1 (phy #1): mgmt TX status (cookie 2e): acked 1466192016.313091: wlan1 (phy #1): mgmt TX status (cookie 2f): acked 1466192016.369315: wlan1 (phy #1): mgmt TX status (cookie 30): acked 1466192016.390064: wlan1 (phy #1): mgmt TX status (cookie 31): acked 1466192016.392064: wlan1: new station fc:c2:de:ac:b1:72 And the corresponding syslog output: Fri Jun 17 19:32:40 2016 kern.debug kernel: [ 3027.270339] ieee80211 phy1: Deleted BA stream index 0 Fri Jun 17 19:32:40 2016 kern.debug kernel: [ 3027.270367] ieee80211 phy1: Remove stream for fc:c2:de:ac:b1:72 0 Fri Jun 17 19:32:43 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 IEEE 802.11: deauthenticated due to local deauth request Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 IEEE 802.11: authenticated Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 IEEE 802.11: associated (aid 1) Fri Jun 17 19:33:36 2016 daemon.info hostapd: wlan1: STA fc:c2:de:ac:b1:72 WPA: pairwise key handshake completed (RSN) Fri Jun 17 19:33:37 2016 daemon.info dnsmasq-dhcp[2668]: DHCPREQUEST(br-lan) 192.168.1.138 fc:c2:de:ac:b1:72 Fri Jun 17 19:33:37 2016 daemon.info dnsmasq-dhcp[2668]: DHCPACK(br-lan) 192.168.1.138 fc:c2:de:ac:b1:72 android-63ebbc936f7b53af So where to go from here? -- David Gilman :DG< http://gilslotd.com -- 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: Troubleshooting mwl8k driver issue
On Mon, Jun 06, 2016 at 09:51:46AM +0300, Lennert Buytenhek wrote: > There's a bunch of bad-looking stuff in the posted dmesgs, such as: > > [ 10.983657] pci :00:01.0: enabling device (0140 -> 0142) > [ 11.972069] ieee80211 phy0: Command RF_ANTENNA error 0x2 > [ 11.977455] ieee80211 phy0: failed to set # of RX antennas > [ 11.993318] ieee80211 phy0: Command RF_ANTENNA error 0x2 > [ 11.998713] ieee80211 phy0: failed to set # of TX antennas > [ 12.004243] ieee80211 phy0: 88w8366 v48, c8d719177244, STA firmware 4.1.0.3 > > And: > > [ 22.517451] :02:00.0: unable to load firmware helper image > [ 22.523399] ieee80211 phy1: Cannot start firmware > [ 22.528230] ieee80211 phy1: Trying to reload the firmware again > [ 23.016669] ieee80211 phy1: 88w8366 v7, c8d719177246, AP firmware 5.2.8.17 I've attached my startup dmesg output, I am seeing some of those messages. > Is the behavior consistent per device across boots? I.e. does device > X always work on every boot while device Y never works at all? Yes. > For starters, could you post lspci -n output? 00:01.0 0604: 11ab:6282 (rev 01) 00:02.0 0604: 11ab:6282 (rev 01) 01:00.0 0200: 11ab:2a41 02:00.0 0200: 11ab:2a42 > Also, do you see the same behavior with older kernels, or have you > only tried 4.4? I saw it on kernel 3.18 as well. As an aside I semi-bricked my router and I'm currently unable to flash new images - unfortunate, as I prepped an OpenWRT build with debug logging. I feel committed to seeing this through though so I have another device ordered but I will be unable to test new builds until it gets here in a week or so. -- David Gilman :DG< http://gilslotd.com [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.4.7 (openwrt@0e997fc2ad25) (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r49377) ) #1 Sun May 22 08:20:37 UTC 2016 [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine model: Linksys EA3500 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat c057d838, node_mem_map c3f7a000 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:512k(uboot)ro,16k@512k(u_env),16k@528k(s_env),20m@2m(kernel),20m@2m(rootfs)fs,20m@22m(alt_kernel),20m@22m(alt_rootfs)fs,22m@42m(syscfg) root=/dev/mtdblock6 ro rootfstype=jffs2 serial_number=12C10606503967 uuid=9E782CBBA2A839EF4B650308C7E22720 hw_version=RGWM-C5_0GA device_mac=C0:56:27:BA:65:BD factory_date=2015/06/24 wps_pin=74717897 [0.00] PID hash table entries: 256 (order: -2, 1024 bytes) [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Memory: 58956K/65536K available (3946K kernel code, 135K rwdata, 1444K rodata, 168K init, 197K bss, 6580K reserved, 0K cma-reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xc480 - 0xff80 ( 944 MB) [0.00] lowmem : 0xc000 - 0xc400 ( 64 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc054bdc4 (5392 kB) [0.00] .init : 0xc054c000 - 0xc0576000 ( 168 kB) [0.00] .data : 0xc0576000 - 0xc0597fac ( 136 kB) [0.00].bss : 0xc0597fac - 0xc05c959c ( 198 kB) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] clocksource: orion_clocksource: mask: 0x max_cycles: 0x, max_idle_ns: 9556302233 ns [0.10] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns [0.98] Calibrating delay loop... 795.44 BogoMIPS (lpj=3977216) [0.040090] pid_max: default: 32768 minimum: 301 [0.040217] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.040238] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.040825] CPU: Testing write buffer coherency: ok [0.041209] Setting up static identity map for 0x81e0 - 0x821c [0.041558] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x1 [0.047290] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.047429] pinctrl core: initialized pinctrl subsystem [0.048746] NET: Registered protocol family 16 [0.049248] DMA:
Re: Troubleshooting mwl8k driver issue
On Fri, Jun 03, 2016 at 10:54:52PM -0500, David Gilman wrote: > Lennert, I am a user of your mwl8k driver through the OpenWRT > distribution. When working with certain WiFi devices I get errors in > the kernel logs and network connectivity errors on the wireless device. > The dmesg logs look like this: > > [539374.394607] ieee80211 phy1: Added a new stream for (BSSID MAC) 0 > [539374.394650] ieee80211 phy1: Started stream for (BSSID MAC) 0 > [539374.394732] ieee80211 phy1: tx rings drained > [539374.401372] ieee80211 phy1: Created a BA stream for (BSSID MAC) : tid 0 These are not (necessarily) errors, just debug messages > There are a number of other users who are also experiencing the same > issue on the OpenWRT bug tracker: > > https://dev.openwrt.org/ticket/21284 There's a bunch of bad-looking stuff in the posted dmesgs, such as: [ 10.983657] pci :00:01.0: enabling device (0140 -> 0142) [ 11.972069] ieee80211 phy0: Command RF_ANTENNA error 0x2 [ 11.977455] ieee80211 phy0: failed to set # of RX antennas [ 11.993318] ieee80211 phy0: Command RF_ANTENNA error 0x2 [ 11.998713] ieee80211 phy0: failed to set # of TX antennas [ 12.004243] ieee80211 phy0: 88w8366 v48, c8d719177244, STA firmware 4.1.0.3 And: [ 22.517451] :02:00.0: unable to load firmware helper image [ 22.523399] ieee80211 phy1: Cannot start firmware [ 22.528230] ieee80211 phy1: Trying to reload the firmware again [ 23.016669] ieee80211 phy1: 88w8366 v7, c8d719177246, AP firmware 5.2.8.17 > As I noted in the bug the driver works with some of my wireless devices > and not others which suggests that something subtle is up with some > driver in this picture. Is the behavior consistent per device across boots? I.e. does device X always work on every boot while device Y never works at all? > I don't have a whole lot of experience with kernel development (pretty > much none actually) and I know absolutely nothing about how these WiFi > devices work. However I am willing to work with you or anyone else on > the linux-wireless list (which I have CCd) to help troubleshoot this > issue. I am using OpenWRT on this router and I can get a build > environment set up for debug kernel builds with their toolchain. I'm > running a pretty recent kernel (4.4.7) but git log suggests this driver > hasn't been touched in a while. For starters, could you post lspci -n output? Also, do you see the same behavior with older kernels, or have you only tried 4.4? -- 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
Troubleshooting mwl8k driver issue
Lennert, I am a user of your mwl8k driver through the OpenWRT distribution. When working with certain WiFi devices I get errors in the kernel logs and network connectivity errors on the wireless device. The dmesg logs look like this: [539374.394607] ieee80211 phy1: Added a new stream for (BSSID MAC) 0 [539374.394650] ieee80211 phy1: Started stream for (BSSID MAC) 0 [539374.394732] ieee80211 phy1: tx rings drained [539374.401372] ieee80211 phy1: Created a BA stream for (BSSID MAC) : tid 0 `iw event -t' logs (it looks like OpenWRT is patching the heck out of this tool): 1465008930.594531: wlan1 (phy #1): unknown event 60 1465008930.652119: wlan1 (phy #1): unknown event 60 1465008930.653494: wlan1 (phy #1): unknown event 60 1465008930.655582: wlan1: new station (BSSID MAC) There are a number of other users who are also experiencing the same issue on the OpenWRT bug tracker: https://dev.openwrt.org/ticket/21284 As I noted in the bug the driver works with some of my wireless devices and not others which suggests that something subtle is up with some driver in this picture. I don't have a whole lot of experience with kernel development (pretty much none actually) and I know absolutely nothing about how these WiFi devices work. However I am willing to work with you or anyone else on the linux-wireless list (which I have CCd) to help troubleshoot this issue. I am using OpenWRT on this router and I can get a build environment set up for debug kernel builds with their toolchain. I'm running a pretty recent kernel (4.4.7) but git log suggests this driver hasn't been touched in a while. -- David Gilman :DG< http://gilslotd.com -- 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
