| Message ID | 1335517711-6522-1-git-send-email-sedat.dilek@gmail.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Fri, Apr 27, 2012 at 11:08:31AM +0200, Sedat Dilek wrote: > User lautriv asked for belkin N-1 WLAN device support on IRC. > > Further informations from lautriv: > * marvell 80W8031, card-id 11ab:2a02 > * Debian/sid 3.2.x > > On [1] I found a report by Jim Cromie concerning same PCI device-id: > > 00:0e.0 Ethernet controller [0200]: Marvell Technology Group Ltd. > 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] (rev 03) > Subsystem: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] > > So, let's add 0x2a02 to PCI device table. Let's not. There's no firmware for the 8361 that implements the firmware interface currently implemented by the mwl8k driver, so this is pretty useless. > [1] http://www.spinics.net/lists/newbies/msg46601.html From that link: | I have a card which modprobes, despite a PCI-ID mismatch | | [...] | | Given the pci-id mismatch shouldnt this just fail to modprobe ? No. That's not a bug -- you are free to load drivers for hardware not currently in your system. > static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = { > + { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, }, > { PCI_VDEVICE(MARVELL, 0x2a0a), .driver_data = MWL8363, }, A 8361 is certainly not a 8363. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:14 AM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 11:08:31AM +0200, Sedat Dilek wrote: > >> User lautriv asked for belkin N-1 WLAN device support on IRC. >> >> Further informations from lautriv: >> * marvell 80W8031, card-id 11ab:2a02 >> * Debian/sid 3.2.x >> >> On [1] I found a report by Jim Cromie concerning same PCI device-id: >> >> 00:0e.0 Ethernet controller [0200]: Marvell Technology Group Ltd. >> 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] (rev 03) >> Subsystem: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] >> >> So, let's add 0x2a02 to PCI device table. > > Let's not. There's no firmware for the 8361 that implements the > firmware interface currently implemented by the mwl8k driver, so > this is pretty useless. > > >> [1] http://www.spinics.net/lists/newbies/msg46601.html > > From that link: > > | I have a card which modprobes, despite a PCI-ID mismatch > | > | [...] > | > | Given the pci-id mismatch shouldnt this just fail to modprobe ? > > No. That's not a bug -- you are free to load drivers for hardware > not currently in your system. > > >> static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = { >> + { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, }, >> { PCI_VDEVICE(MARVELL, 0x2a0a), .driver_data = MWL8363, }, > > A 8361 is certainly not a 8363. Damn, I got confused by all the numbers. More coffee. Thanks for the clarification. I will inform the user on IRC. Sorry, for the noise. Are you planning to or even working on support (for) 8361 devices? - Sedat - -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:22:49AM +0200, Sedat Dilek wrote:
> Are you planning to or even working on support (for) 8361 devices?
I don't have any such plans, and I don't know of anyone who does.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:40 AM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 11:22:49AM +0200, Sedat Dilek wrote: > >> Are you planning to or even working on support (for) 8361 devices? > > I don't have any such plans, and I don't know of anyone who does. Does 8361 require firmware support? Does a firmware file exist (name?)? Asking just out of curiosity? - Sedat - -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:42:54AM +0200, Sedat Dilek wrote: > >> Are you planning to or even working on support (for) 8361 devices? > > > > I don't have any such plans, and I don't know of anyone who does. > > Does 8361 require firmware support? What do you mean by that? > Does a firmware file exist (name?)? There's firmware for the 8361 out there, however, that version of the firmware implements a firmware API that is different from the one that mwl8k currently implements. You could add 8361 support to mwl8k, but then you'd have to go over all the firmware command invocations in mwl8k and make sure that they will work on the 8361 firmware that you're trying to support as well. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:46 AM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 11:42:54AM +0200, Sedat Dilek wrote: > >> >> Are you planning to or even working on support (for) 8361 devices? >> > >> > I don't have any such plans, and I don't know of anyone who does. >> >> Does 8361 require firmware support? > > What do you mean by that? > IIRC ath5k for example needs no external firmware file. > >> Does a firmware file exist (name?)? > > There's firmware for the 8361 out there, however, that version of > the firmware implements a firmware API that is different from the > one that mwl8k currently implements. > > You could add 8361 support to mwl8k, but then you'd have to go over > all the firmware command invocations in mwl8k and make sure that they > will work on the 8361 firmware that you're trying to support as well. Without having a 8361 this will be even harder to walk through. Anyway, thanks for your detailed explanations. What's the alternative for such affected users? Use ndis-wrapper? - Sedat - -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:56:00AM +0200, Sedat Dilek wrote: > >> >> Are you planning to or even working on support (for) 8361 devices? > >> > > >> > I don't have any such plans, and I don't know of anyone who does. > >> > >> Does 8361 require firmware support? > > > > What do you mean by that? > > IIRC ath5k for example needs no external firmware file. The 8361 requires firmware to be loaded into it before it'll do anything useful. > >> Does a firmware file exist (name?)? > > > > There's firmware for the 8361 out there, however, that version of > > the firmware implements a firmware API that is different from the > > one that mwl8k currently implements. > > > > You could add 8361 support to mwl8k, but then you'd have to go over > > all the firmware command invocations in mwl8k and make sure that they > > will work on the 8361 firmware that you're trying to support as well. > > Without having a 8361 this will be even harder to walk through. > > Anyway, thanks for your detailed explanations. > > What's the alternative for such affected users? > Use ndis-wrapper? I'm not sure. I've never tried to get a 8361 work under Linux. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:58 AM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 11:56:00AM +0200, Sedat Dilek wrote: > >> >> >> Are you planning to or even working on support (for) 8361 devices? >> >> > >> >> > I don't have any such plans, and I don't know of anyone who does. >> >> >> >> Does 8361 require firmware support? >> > >> > What do you mean by that? >> >> IIRC ath5k for example needs no external firmware file. > > The 8361 requires firmware to be loaded into it before it'll do > anything useful. > > >> >> Does a firmware file exist (name?)? >> > >> > There's firmware for the 8361 out there, however, that version of >> > the firmware implements a firmware API that is different from the >> > one that mwl8k currently implements. >> > >> > You could add 8361 support to mwl8k, but then you'd have to go over >> > all the firmware command invocations in mwl8k and make sure that they >> > will work on the 8361 firmware that you're trying to support as well. >> >> Without having a 8361 this will be even harder to walk through. >> >> Anyway, thanks for your detailed explanations. >> >> What's the alternative for such affected users? >> Use ndis-wrapper? > > I'm not sure. I've never tried to get a 8361 work under Linux. Just found on [1] this same wrong patch in [2] :-). Dunno if [3] worked and from where they have stolen fw-files. - Sedat - [1] https://dev.openwrt.org/ticket/7209 [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 12:12:13PM +0200, Sedat Dilek wrote: > >> >> >> Are you planning to or even working on support (for) 8361 devices? > >> >> > > >> >> > I don't have any such plans, and I don't know of anyone who does. > >> >> > >> >> Does 8361 require firmware support? > >> > > >> > What do you mean by that? > >> > >> IIRC ath5k for example needs no external firmware file. > > > > The 8361 requires firmware to be loaded into it before it'll do > > anything useful. > > > > > >> >> Does a firmware file exist (name?)? > >> > > >> > There's firmware for the 8361 out there, however, that version of > >> > the firmware implements a firmware API that is different from the > >> > one that mwl8k currently implements. > >> > > >> > You could add 8361 support to mwl8k, but then you'd have to go over > >> > all the firmware command invocations in mwl8k and make sure that they > >> > will work on the 8361 firmware that you're trying to support as well. > >> > >> Without having a 8361 this will be even harder to walk through. > >> > >> Anyway, thanks for your detailed explanations. > >> > >> What's the alternative for such affected users? > >> Use ndis-wrapper? > > > > I'm not sure. I've never tried to get a 8361 work under Linux. > > Just found on [1] this same wrong patch in [2] :-). > Dunno if [3] worked and from where they have stolen fw-files. > > - Sedat - > > [1] https://dev.openwrt.org/ticket/7209 > [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch > [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch I doubt that [3] is really all that's needed to make it work. But if there's someone for whom it works, I'd like them to run some tests on mwl8k + [3] on 88w8361p. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 12:17 PM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 12:12:13PM +0200, Sedat Dilek wrote: > >> >> >> >> Are you planning to or even working on support (for) 8361 devices? >> >> >> > >> >> >> > I don't have any such plans, and I don't know of anyone who does. >> >> >> >> >> >> Does 8361 require firmware support? >> >> > >> >> > What do you mean by that? >> >> >> >> IIRC ath5k for example needs no external firmware file. >> > >> > The 8361 requires firmware to be loaded into it before it'll do >> > anything useful. >> > >> > >> >> >> Does a firmware file exist (name?)? >> >> > >> >> > There's firmware for the 8361 out there, however, that version of >> >> > the firmware implements a firmware API that is different from the >> >> > one that mwl8k currently implements. >> >> > >> >> > You could add 8361 support to mwl8k, but then you'd have to go over >> >> > all the firmware command invocations in mwl8k and make sure that they >> >> > will work on the 8361 firmware that you're trying to support as well. >> >> >> >> Without having a 8361 this will be even harder to walk through. >> >> >> >> Anyway, thanks for your detailed explanations. >> >> >> >> What's the alternative for such affected users? >> >> Use ndis-wrapper? >> > >> > I'm not sure. I've never tried to get a 8361 work under Linux. >> >> Just found on [1] this same wrong patch in [2] :-). >> Dunno if [3] worked and from where they have stolen fw-files. >> >> - Sedat - >> >> [1] https://dev.openwrt.org/ticket/7209 >> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch > > I doubt that [3] is really all that's needed to make it work. But if > there's someone for whom it works, I'd like them to run some tests on > mwl8k + [3] on 88w8361p. Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. Also, I refreshed and adapted a bit the instructions (see attachment). - Sedat - ### HELP-1: https://forum.openwrt.org/viewtopic.php?pid=103243#p103243 ### HELP-2: https://forum.openwrt.org/viewtopic.php?pid=110004#p110004 ### From HELP-1: To extract the firmware for the mwl8k driver, open your Ubuntu terminal: sudo apt-get install cabextract unshield mkdir mwl8k cd mwl8k wget -O mrv8k_extract_fw.c 'http://marc.info/?l=linux-wireless&m=126540674419330&q=p3' wget ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe mkdir mess cabextract -F Disk1/data*.* -d mess wn311t_4_2_setup.exe unshield -g Driver -d mess x mess/Disk1/data1.cab gcc -o mrv8k_extract_fw mrv8k_extract_fw.c ./mrv8k_extract_fw mess/Driver/netmw145.sys rm -r mess md5sum -b *.fw mv fmimage_8XX1.fw fmimage_8363.fw mv helper_8XX1.fw helper_8363.fw ### From HELP-2: For Marwell 8361P md5sum -b *.fw | egrep '48c79b085f7f5a590d3dbc15647e519f|0fe11f415adbbd5e8ca03641705c4a6c' [ OUTPUT ] 48c79b085f7f5a590d3dbc15647e519f *fmimage_8XX0.fw 0fe11f415adbbd5e8ca03641705c4a6c *helper_8XX0.fw mv fmimage_8XX0.fw fmimage_8361p.fw mv helper_8XX0.fw helper_8361p.fw ### PATCH: https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch -dileks // 27-Apr-2012
On Fri, Apr 27, 2012 at 12:57 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Fri, Apr 27, 2012 at 12:17 PM, Lennert Buytenhek > <buytenh@wantstofly.org> wrote: >> On Fri, Apr 27, 2012 at 12:12:13PM +0200, Sedat Dilek wrote: >> >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? >>> >> >> > >>> >> >> > I don't have any such plans, and I don't know of anyone who does. >>> >> >> >>> >> >> Does 8361 require firmware support? >>> >> > >>> >> > What do you mean by that? >>> >> >>> >> IIRC ath5k for example needs no external firmware file. >>> > >>> > The 8361 requires firmware to be loaded into it before it'll do >>> > anything useful. >>> > >>> > >>> >> >> Does a firmware file exist (name?)? >>> >> > >>> >> > There's firmware for the 8361 out there, however, that version of >>> >> > the firmware implements a firmware API that is different from the >>> >> > one that mwl8k currently implements. >>> >> > >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over >>> >> > all the firmware command invocations in mwl8k and make sure that they >>> >> > will work on the 8361 firmware that you're trying to support as well. >>> >> >>> >> Without having a 8361 this will be even harder to walk through. >>> >> >>> >> Anyway, thanks for your detailed explanations. >>> >> >>> >> What's the alternative for such affected users? >>> >> Use ndis-wrapper? >>> > >>> > I'm not sure. I've never tried to get a 8361 work under Linux. >>> >>> Just found on [1] this same wrong patch in [2] :-). >>> Dunno if [3] worked and from where they have stolen fw-files. >>> >>> - Sedat - >>> >>> [1] https://dev.openwrt.org/ticket/7209 >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch >> >> I doubt that [3] is really all that's needed to make it work. But if >> there's someone for whom it works, I'd like them to run some tests on >> mwl8k + [3] on 88w8361p. > > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. > Also, I refreshed and adapted a bit the instructions (see attachment). > > - Sedat - [ CC Jim Cromie ] Now, with extracted firmware files renamed & copied to /lib/firmware/mwl8k/ and applied patch (see attachment) against Linux-3.4-rc4+ I am seeing with modinfo: $ sudo modinfo mwl8k filename: /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko license: GPL author: Lennert Buytenhek <buytenh@marvell.com> version: 0.13 description: Marvell TOPDOG(R) 802.11 Wireless Network Driver firmware: mwl8k/fmimage_8366_ap-2.fw firmware: mwl8k/fmimage_8366.fw firmware: mwl8k/helper_8366.fw firmware: mwl8k/fmimage_8687.fw firmware: mwl8k/helper_8687.fw firmware: mwl8k/fmimage_8363.fw firmware: mwl8k/helper_8363.fw firmware: mwl8k/fmimage_8361p.fw firmware: mwl8k/helper_8361p.fw srcversion: 9E1479A05C8D67E6AE90746 alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: 0x2a02 PCI device-id depends: mac80211,cfg80211 vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions parm: ap_mode_default:Set to 1 to make ap mode the default instead of sta mode (bool) $ ls -l /lib/firmware/mwl8k/ insgesamt 456 -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- 8361P: Firmware image -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: Helper image -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw As said... ***compile-tested*** only here. I had a short query with lautriv on #linux-wireless this afternoon: * mwl8k kernel-module was autoloaded * wlan0 interface got fired up * ESSID was accepted * logs reported 802.11bgn support is active * (he tested on Linux-3.3.3) With WPA/WPA2 lautriv had some problems as his installation was missing wpasupplicant. He setup a classic /etc/network/interfaces. After resetting his router mwl8k worked nicely. Unfortunately, he was on the run and promised me to send logs and do more testing this evening. So, Lennert if you want more testing - What? How? etc. Thanks in advance. - Sedat -
On Fri, Apr 27, 2012 at 03:29:26PM +0200, Sedat Dilek wrote: > >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? > >>> >> >> > > >>> >> >> > I don't have any such plans, and I don't know of anyone who does. > >>> >> >> > >>> >> >> Does 8361 require firmware support? > >>> >> > > >>> >> > What do you mean by that? > >>> >> > >>> >> IIRC ath5k for example needs no external firmware file. > >>> > > >>> > The 8361 requires firmware to be loaded into it before it'll do > >>> > anything useful. > >>> > > >>> > > >>> >> >> Does a firmware file exist (name?)? > >>> >> > > >>> >> > There's firmware for the 8361 out there, however, that version of > >>> >> > the firmware implements a firmware API that is different from the > >>> >> > one that mwl8k currently implements. > >>> >> > > >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over > >>> >> > all the firmware command invocations in mwl8k and make sure that they > >>> >> > will work on the 8361 firmware that you're trying to support as well. > >>> >> > >>> >> Without having a 8361 this will be even harder to walk through. > >>> >> > >>> >> Anyway, thanks for your detailed explanations. > >>> >> > >>> >> What's the alternative for such affected users? > >>> >> Use ndis-wrapper? > >>> > > >>> > I'm not sure. I've never tried to get a 8361 work under Linux. > >>> > >>> Just found on [1] this same wrong patch in [2] :-). > >>> Dunno if [3] worked and from where they have stolen fw-files. > >>> > >>> - Sedat - > >>> > >>> [1] https://dev.openwrt.org/ticket/7209 > >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch > >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch > >> > >> I doubt that [3] is really all that's needed to make it work. But if > >> there's someone for whom it works, I'd like them to run some tests on > >> mwl8k + [3] on 88w8361p. > > > > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. > > Also, I refreshed and adapted a bit the instructions (see attachment). > > > > - Sedat - > > [ CC Jim Cromie ] > > Now, with extracted firmware files renamed & copied to > /lib/firmware/mwl8k/ and applied patch (see attachment) against > Linux-3.4-rc4+ I am seeing with modinfo: > > $ sudo modinfo mwl8k > filename: > /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko > license: GPL > author: Lennert Buytenhek <buytenh@marvell.com> > version: 0.13 > description: Marvell TOPDOG(R) 802.11 Wireless Network Driver > firmware: mwl8k/fmimage_8366_ap-2.fw > firmware: mwl8k/fmimage_8366.fw > firmware: mwl8k/helper_8366.fw > firmware: mwl8k/fmimage_8687.fw > firmware: mwl8k/helper_8687.fw > firmware: mwl8k/fmimage_8363.fw > firmware: mwl8k/helper_8363.fw > firmware: mwl8k/fmimage_8361p.fw > firmware: mwl8k/helper_8361p.fw > srcversion: 9E1479A05C8D67E6AE90746 > alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* > alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* > alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* > alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* > alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* > alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* > alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* > alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: > 0x2a02 PCI device-id > depends: mac80211,cfg80211 > vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions > parm: ap_mode_default:Set to 1 to make ap mode the default > instead of sta mode (bool) > > $ ls -l /lib/firmware/mwl8k/ > insgesamt 456 > -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- > 8361P: Firmware image > -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw > -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw > -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw > -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw > -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: > Helper image > -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw > -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw > > As said... ***compile-tested*** only here. Which doesn't say much at all, but.. > I had a short query with lautriv on #linux-wireless this afternoon: > * mwl8k kernel-module was autoloaded > * wlan0 interface got fired up > * ESSID was accepted > * logs reported 802.11bgn support is active > * (he tested on Linux-3.3.3) > > With WPA/WPA2 lautriv had some problems as his installation was > missing wpasupplicant. > He setup a classic /etc/network/interfaces. > After resetting his router mwl8k worked nicely. > > Unfortunately, he was on the run and promised me to send logs and do > more testing this evening. ..but this is pretty interesting. I thought that the only available 8361p firmware used an incompatible firmware API, and I didn't know of the existence of an apparently compatible firmware. > So, Lennert if you want more testing - What? How? etc. For one, the output of 'iw phy', please. Also, does monitor mode work? Do you get plausible channel/rxpower values in tcpdump in monitor mode? Are there any messages in the syslog about failing commands? thanks, Lennert -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Fri, Apr 27, 2012 at 03:29:26PM +0200, Sedat Dilek wrote: > >> >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? >> >>> >> >> > >> >>> >> >> > I don't have any such plans, and I don't know of anyone who does. >> >>> >> >> >> >>> >> >> Does 8361 require firmware support? >> >>> >> > >> >>> >> > What do you mean by that? >> >>> >> >> >>> >> IIRC ath5k for example needs no external firmware file. >> >>> > >> >>> > The 8361 requires firmware to be loaded into it before it'll do >> >>> > anything useful. >> >>> > >> >>> > >> >>> >> >> Does a firmware file exist (name?)? >> >>> >> > >> >>> >> > There's firmware for the 8361 out there, however, that version of >> >>> >> > the firmware implements a firmware API that is different from the >> >>> >> > one that mwl8k currently implements. >> >>> >> > >> >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over >> >>> >> > all the firmware command invocations in mwl8k and make sure that they >> >>> >> > will work on the 8361 firmware that you're trying to support as well. >> >>> >> >> >>> >> Without having a 8361 this will be even harder to walk through. >> >>> >> >> >>> >> Anyway, thanks for your detailed explanations. >> >>> >> >> >>> >> What's the alternative for such affected users? >> >>> >> Use ndis-wrapper? >> >>> > >> >>> > I'm not sure. I've never tried to get a 8361 work under Linux. >> >>> >> >>> Just found on [1] this same wrong patch in [2] :-). >> >>> Dunno if [3] worked and from where they have stolen fw-files. >> >>> >> >>> - Sedat - >> >>> >> >>> [1] https://dev.openwrt.org/ticket/7209 >> >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >> >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch >> >> >> >> I doubt that [3] is really all that's needed to make it work. But if >> >> there's someone for whom it works, I'd like them to run some tests on >> >> mwl8k + [3] on 88w8361p. >> > >> > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. >> > Also, I refreshed and adapted a bit the instructions (see attachment). >> > >> > - Sedat - >> >> [ CC Jim Cromie ] >> >> Now, with extracted firmware files renamed & copied to >> /lib/firmware/mwl8k/ and applied patch (see attachment) against >> Linux-3.4-rc4+ I am seeing with modinfo: >> >> $ sudo modinfo mwl8k >> filename: >> /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko >> license: GPL >> author: Lennert Buytenhek <buytenh@marvell.com> >> version: 0.13 >> description: Marvell TOPDOG(R) 802.11 Wireless Network Driver >> firmware: mwl8k/fmimage_8366_ap-2.fw >> firmware: mwl8k/fmimage_8366.fw >> firmware: mwl8k/helper_8366.fw >> firmware: mwl8k/fmimage_8687.fw >> firmware: mwl8k/helper_8687.fw >> firmware: mwl8k/fmimage_8363.fw >> firmware: mwl8k/helper_8363.fw >> firmware: mwl8k/fmimage_8361p.fw >> firmware: mwl8k/helper_8361p.fw >> srcversion: 9E1479A05C8D67E6AE90746 >> alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* >> alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: >> 0x2a02 PCI device-id >> depends: mac80211,cfg80211 >> vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions >> parm: ap_mode_default:Set to 1 to make ap mode the default >> instead of sta mode (bool) >> >> $ ls -l /lib/firmware/mwl8k/ >> insgesamt 456 >> -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- >> 8361P: Firmware image >> -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw >> -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw >> -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw >> -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw >> -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: >> Helper image >> -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw >> -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw >> >> As said... ***compile-tested*** only here. > > Which doesn't say much at all, but.. > As already pointed out, no Marwell WLAN hardware here. Marvell comics of course :-). > >> I had a short query with lautriv on #linux-wireless this afternoon: >> * mwl8k kernel-module was autoloaded >> * wlan0 interface got fired up >> * ESSID was accepted >> * logs reported 802.11bgn support is active >> * (he tested on Linux-3.3.3) >> >> With WPA/WPA2 lautriv had some problems as his installation was >> missing wpasupplicant. >> He setup a classic /etc/network/interfaces. >> After resetting his router mwl8k worked nicely. >> >> Unfortunately, he was on the run and promised me to send logs and do >> more testing this evening. > > ..but this is pretty interesting. I thought that the only available > 8361p firmware used an incompatible firmware API, and I didn't know > of the existence of an apparently compatible firmware. > > >> So, Lennert if you want more testing - What? How? etc. > > For one, the output of 'iw phy', please. > > Also, does monitor mode work? Do you get plausible channel/rxpower > values in tcpdump in monitor mode? > > Are there any messages in the syslog about failing commands? > > > thanks, > Lennert On 1st sight, logs look fine: [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, 00173f3bdde3, STA firmware 2.1.4.25 But WLAN connection is not that fast and stable as lautriv reports (several abnormalities were observed). I requested a tarball which includes: * dmesg (Linux-3.3.3) * e_n_a (/etc/network/interfaces) * ifconfig output * iwconfig output * iw_phy output * ps_axu (WPA) output lautriv will be so kind to be around on #linux-wireless/Freenode the next days (UTC+2: German/Swiss local-time). Just ping him. Hope you have fun, together! - Sedat -
On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek > <buytenh@wantstofly.org> wrote: >> On Fri, Apr 27, 2012 at 03:29:26PM +0200, Sedat Dilek wrote: >> >>> >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? >>> >>> >> >> > >>> >>> >> >> > I don't have any such plans, and I don't know of anyone who does. >>> >>> >> >> >>> >>> >> >> Does 8361 require firmware support? >>> >>> >> > >>> >>> >> > What do you mean by that? >>> >>> >> >>> >>> >> IIRC ath5k for example needs no external firmware file. >>> >>> > >>> >>> > The 8361 requires firmware to be loaded into it before it'll do >>> >>> > anything useful. >>> >>> > >>> >>> > >>> >>> >> >> Does a firmware file exist (name?)? >>> >>> >> > >>> >>> >> > There's firmware for the 8361 out there, however, that version of >>> >>> >> > the firmware implements a firmware API that is different from the >>> >>> >> > one that mwl8k currently implements. >>> >>> >> > >>> >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over >>> >>> >> > all the firmware command invocations in mwl8k and make sure that they >>> >>> >> > will work on the 8361 firmware that you're trying to support as well. >>> >>> >> >>> >>> >> Without having a 8361 this will be even harder to walk through. >>> >>> >> >>> >>> >> Anyway, thanks for your detailed explanations. >>> >>> >> >>> >>> >> What's the alternative for such affected users? >>> >>> >> Use ndis-wrapper? >>> >>> > >>> >>> > I'm not sure. I've never tried to get a 8361 work under Linux. >>> >>> >>> >>> Just found on [1] this same wrong patch in [2] :-). >>> >>> Dunno if [3] worked and from where they have stolen fw-files. >>> >>> >>> >>> - Sedat - >>> >>> >>> >>> [1] https://dev.openwrt.org/ticket/7209 >>> >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >>> >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch >>> >> >>> >> I doubt that [3] is really all that's needed to make it work. But if >>> >> there's someone for whom it works, I'd like them to run some tests on >>> >> mwl8k + [3] on 88w8361p. >>> > >>> > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. >>> > Also, I refreshed and adapted a bit the instructions (see attachment). >>> > >>> > - Sedat - >>> >>> [ CC Jim Cromie ] >>> >>> Now, with extracted firmware files renamed & copied to >>> /lib/firmware/mwl8k/ and applied patch (see attachment) against >>> Linux-3.4-rc4+ I am seeing with modinfo: >>> >>> $ sudo modinfo mwl8k >>> filename: >>> /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko >>> license: GPL >>> author: Lennert Buytenhek <buytenh@marvell.com> >>> version: 0.13 >>> description: Marvell TOPDOG(R) 802.11 Wireless Network Driver >>> firmware: mwl8k/fmimage_8366_ap-2.fw >>> firmware: mwl8k/fmimage_8366.fw >>> firmware: mwl8k/helper_8366.fw >>> firmware: mwl8k/fmimage_8687.fw >>> firmware: mwl8k/helper_8687.fw >>> firmware: mwl8k/fmimage_8363.fw >>> firmware: mwl8k/helper_8363.fw >>> firmware: mwl8k/fmimage_8361p.fw >>> firmware: mwl8k/helper_8361p.fw >>> srcversion: 9E1479A05C8D67E6AE90746 >>> alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* >>> alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: >>> 0x2a02 PCI device-id >>> depends: mac80211,cfg80211 >>> vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions >>> parm: ap_mode_default:Set to 1 to make ap mode the default >>> instead of sta mode (bool) >>> >>> $ ls -l /lib/firmware/mwl8k/ >>> insgesamt 456 >>> -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- >>> 8361P: Firmware image >>> -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw >>> -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw >>> -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw >>> -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw >>> -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: >>> Helper image >>> -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw >>> -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw >>> >>> As said... ***compile-tested*** only here. >> >> Which doesn't say much at all, but.. >> > > As already pointed out, no Marwell WLAN hardware here. Marvell comics > of course :-). > >> >>> I had a short query with lautriv on #linux-wireless this afternoon: >>> * mwl8k kernel-module was autoloaded >>> * wlan0 interface got fired up >>> * ESSID was accepted >>> * logs reported 802.11bgn support is active >>> * (he tested on Linux-3.3.3) >>> >>> With WPA/WPA2 lautriv had some problems as his installation was >>> missing wpasupplicant. >>> He setup a classic /etc/network/interfaces. >>> After resetting his router mwl8k worked nicely. >>> >>> Unfortunately, he was on the run and promised me to send logs and do >>> more testing this evening. >> >> ..but this is pretty interesting. I thought that the only available >> 8361p firmware used an incompatible firmware API, and I didn't know >> of the existence of an apparently compatible firmware. >> >> >>> So, Lennert if you want more testing - What? How? etc. >> >> For one, the output of 'iw phy', please. >> >> Also, does monitor mode work? Do you get plausible channel/rxpower >> values in tcpdump in monitor mode? >> >> Are there any messages in the syslog about failing commands? >> >> >> thanks, >> Lennert > > On 1st sight, logs look fine: > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > 00173f3bdde3, STA firmware 2.1.4.25 > > But WLAN connection is not that fast and stable as lautriv reports > (several abnormalities were observed). > > I requested a tarball which includes: > * dmesg (Linux-3.3.3) > * e_n_a (/etc/network/interfaces) > * ifconfig output > * iwconfig output > * iw_phy output > * ps_axu (WPA) output > > lautriv will be so kind to be around on #linux-wireless/Freenode the > next days (UTC+2: German/Swiss local-time). > Just ping him. > > Hope you have fun, together! > > - Sedat - A new tarball from lautriv with same outputs as before, but now tested with Linux-3.4-rc4. - Sedat -
[dropped lkml from cc] On Sat, Apr 28, 2012 at 4:25 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek > <sedat.dilek@googlemail.com> wrote: >> On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek >> <buytenh@wantstofly.org> wrote: >>> On Fri, Apr 27, 2012 at 03:29:26PM +0200, Sedat Dilek wrote: >>> >>>> >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? >>>> >>> >> >> > >>>> >>> >> >> > I don't have any such plans, and I don't know of anyone who does. >>>> >>> >> >> >>>> >>> >> >> Does 8361 require firmware support? >>>> >>> >> > >>>> >>> >> > What do you mean by that? >>>> >>> >> >>>> >>> >> IIRC ath5k for example needs no external firmware file. >>>> >>> > >>>> >>> > The 8361 requires firmware to be loaded into it before it'll do >>>> >>> > anything useful. >>>> >>> > >>>> >>> > >>>> >>> >> >> Does a firmware file exist (name?)? >>>> >>> >> > >>>> >>> >> > There's firmware for the 8361 out there, however, that version of >>>> >>> >> > the firmware implements a firmware API that is different from the >>>> >>> >> > one that mwl8k currently implements. >>>> >>> >> > >>>> >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over >>>> >>> >> > all the firmware command invocations in mwl8k and make sure that they >>>> >>> >> > will work on the 8361 firmware that you're trying to support as well. >>>> >>> >> >>>> >>> >> Without having a 8361 this will be even harder to walk through. >>>> >>> >> >>>> >>> >> Anyway, thanks for your detailed explanations. >>>> >>> >> >>>> >>> >> What's the alternative for such affected users? >>>> >>> >> Use ndis-wrapper? >>>> >>> > >>>> >>> > I'm not sure. I've never tried to get a 8361 work under Linux. >>>> >>> >>>> >>> Just found on [1] this same wrong patch in [2] :-). >>>> >>> Dunno if [3] worked and from where they have stolen fw-files. >>>> >>> >>>> >>> - Sedat - >>>> >>> >>>> >>> [1] https://dev.openwrt.org/ticket/7209 >>>> >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >>>> >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch >>>> >> >>>> >> I doubt that [3] is really all that's needed to make it work. But if >>>> >> there's someone for whom it works, I'd like them to run some tests on >>>> >> mwl8k + [3] on 88w8361p. >>>> > >>>> > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. >>>> > Also, I refreshed and adapted a bit the instructions (see attachment). >>>> > >>>> > - Sedat - >>>> >>>> [ CC Jim Cromie ] >>>> >>>> Now, with extracted firmware files renamed & copied to >>>> /lib/firmware/mwl8k/ and applied patch (see attachment) against >>>> Linux-3.4-rc4+ I am seeing with modinfo: >>>> >>>> $ sudo modinfo mwl8k >>>> filename: >>>> /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko >>>> license: GPL >>>> author: Lennert Buytenhek <buytenh@marvell.com> >>>> version: 0.13 >>>> description: Marvell TOPDOG(R) 802.11 Wireless Network Driver >>>> firmware: mwl8k/fmimage_8366_ap-2.fw >>>> firmware: mwl8k/fmimage_8366.fw >>>> firmware: mwl8k/helper_8366.fw >>>> firmware: mwl8k/fmimage_8687.fw >>>> firmware: mwl8k/helper_8687.fw >>>> firmware: mwl8k/fmimage_8363.fw >>>> firmware: mwl8k/helper_8363.fw >>>> firmware: mwl8k/fmimage_8361p.fw >>>> firmware: mwl8k/helper_8361p.fw >>>> srcversion: 9E1479A05C8D67E6AE90746 >>>> alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* >>>> alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: >>>> 0x2a02 PCI device-id >>>> depends: mac80211,cfg80211 >>>> vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions >>>> parm: ap_mode_default:Set to 1 to make ap mode the default >>>> instead of sta mode (bool) >>>> >>>> $ ls -l /lib/firmware/mwl8k/ >>>> insgesamt 456 >>>> -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- >>>> 8361P: Firmware image >>>> -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw >>>> -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw >>>> -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw >>>> -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw >>>> -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: >>>> Helper image >>>> -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw >>>> -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw >>>> >>>> As said... ***compile-tested*** only here. >>> >>> Which doesn't say much at all, but.. >>> >> >> As already pointed out, no Marwell WLAN hardware here. Marvell comics >> of course :-). >> >>> >>>> I had a short query with lautriv on #linux-wireless this afternoon: >>>> * mwl8k kernel-module was autoloaded >>>> * wlan0 interface got fired up >>>> * ESSID was accepted >>>> * logs reported 802.11bgn support is active >>>> * (he tested on Linux-3.3.3) >>>> >>>> With WPA/WPA2 lautriv had some problems as his installation was >>>> missing wpasupplicant. >>>> He setup a classic /etc/network/interfaces. >>>> After resetting his router mwl8k worked nicely. >>>> >>>> Unfortunately, he was on the run and promised me to send logs and do >>>> more testing this evening. >>> >>> ..but this is pretty interesting. I thought that the only available >>> 8361p firmware used an incompatible firmware API, and I didn't know >>> of the existence of an apparently compatible firmware. >>> >>> >>>> So, Lennert if you want more testing - What? How? etc. >>> >>> For one, the output of 'iw phy', please. >>> >>> Also, does monitor mode work? Do you get plausible channel/rxpower >>> values in tcpdump in monitor mode? >>> >>> Are there any messages in the syslog about failing commands? >>> >>> >>> thanks, >>> Lennert >> >> On 1st sight, logs look fine: >> >> [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, >> 00173f3bdde3, STA firmware 2.1.4.25 >> >> But WLAN connection is not that fast and stable as lautriv reports >> (several abnormalities were observed). >> >> I requested a tarball which includes: >> * dmesg (Linux-3.3.3) >> * e_n_a (/etc/network/interfaces) >> * ifconfig output >> * iwconfig output >> * iw_phy output >> * ps_axu (WPA) output >> >> lautriv will be so kind to be around on #linux-wireless/Freenode the >> next days (UTC+2: German/Swiss local-time). >> Just ping him. >> >> Hope you have fun, together! >> >> - Sedat - > > A new tarball from lautriv with same outputs as before, but now tested > with Linux-3.4-rc4. > > - Sedat - heres my logs, using firmware extracted by Sedat's script, and the patch on mwl8k.c bottom-line, it appears to be working. its contents are a bit more pedantic, and includes data for another wifi card (rtl8180 based) also in the box. It was obtained by this script: #!/bin/bash # dmesg (Linux-3.3.3) # e_n_a (/etc/network/interfaces) # ifconfig output # iwconfig output # iw_phy output # ps_axu (WPA) output devs="wlan0 wlan1" apmac=00:14:d1:e8:65:0a loudly () { echo "# $@" fname=`echo $@ | sed -e 's/ /-/g'` $@ 2> $fname-err | tee $fname [ $? != 0 ] && echo non-zero exit on $fname: $? [ -s $fname-err ] || rm $fname-err } ( iw --debug event -f > iw-event-f )& pid_event=$! for N in 0 1 ; do loudly iw dev wlan$N interface add fish$N type monitor # flags none loudly iw dev fish$N set channel 8 loudly ifconfig fish$N up ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& pid_dump_fish$N=$! done loudly iw list #loudly iwspy # gives: Interface doesn't support wireless statistic collection for dev in $devs ; do loudly ifconfig $dev loudly iwconfig $dev loudly iwlist $dev scan loudly iw dev $dev info loudly iw dev $dev link loudly iw dev $dev scan loudly iw dev $dev survey dump done for phy in $phys ; do loudly iw phy $phy info done # these are unsupported on wlan0 loudly iw dev wlan1 survey dump loudly iw dev wlan1 station dump loudly iw dev wlan1 station get $apmac for N in 0 1 ; do loudly iw dev fish$N del done kill $pid_dump_fish0 $pid_dump_fish0 kill $pid_event dmesg > dmesg grep -vE '^#|key' /etc/network/interfaces > e_n_a exit
On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <jim.cromie@gmail.com> wrote: > [dropped lkml from cc] > > On Sat, Apr 28, 2012 at 4:25 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >> On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek >> <sedat.dilek@googlemail.com> wrote: >>> On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek >>> <buytenh@wantstofly.org> wrote: >>>> On Fri, Apr 27, 2012 at 03:29:26PM +0200, Sedat Dilek wrote: >>>> >>>>> >>> >> >> >> Are you planning to or even working on support (for) 8361 devices? >>>>> >>> >> >> > >>>>> >>> >> >> > I don't have any such plans, and I don't know of anyone who does. >>>>> >>> >> >> >>>>> >>> >> >> Does 8361 require firmware support? >>>>> >>> >> > >>>>> >>> >> > What do you mean by that? >>>>> >>> >> >>>>> >>> >> IIRC ath5k for example needs no external firmware file. >>>>> >>> > >>>>> >>> > The 8361 requires firmware to be loaded into it before it'll do >>>>> >>> > anything useful. >>>>> >>> > >>>>> >>> > >>>>> >>> >> >> Does a firmware file exist (name?)? >>>>> >>> >> > >>>>> >>> >> > There's firmware for the 8361 out there, however, that version of >>>>> >>> >> > the firmware implements a firmware API that is different from the >>>>> >>> >> > one that mwl8k currently implements. >>>>> >>> >> > >>>>> >>> >> > You could add 8361 support to mwl8k, but then you'd have to go over >>>>> >>> >> > all the firmware command invocations in mwl8k and make sure that they >>>>> >>> >> > will work on the 8361 firmware that you're trying to support as well. >>>>> >>> >> >>>>> >>> >> Without having a 8361 this will be even harder to walk through. >>>>> >>> >> >>>>> >>> >> Anyway, thanks for your detailed explanations. >>>>> >>> >> >>>>> >>> >> What's the alternative for such affected users? >>>>> >>> >> Use ndis-wrapper? >>>>> >>> > >>>>> >>> > I'm not sure. I've never tried to get a 8361 work under Linux. >>>>> >>> >>>>> >>> Just found on [1] this same wrong patch in [2] :-). >>>>> >>> Dunno if [3] worked and from where they have stolen fw-files. >>>>> >>> >>>>> >>> - Sedat - >>>>> >>> >>>>> >>> [1] https://dev.openwrt.org/ticket/7209 >>>>> >>> [2] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_fix_pci_id.patch >>>>> >>> [3] https://dev.openwrt.org/attachment/ticket/7209/mwl8k_8361p.patch >>>>> >> >>>>> >> I doubt that [3] is really all that's needed to make it work. But if >>>>> >> there's someone for whom it works, I'd like them to run some tests on >>>>> >> mwl8k + [3] on 88w8361p. >>>>> > >>>>> > Just asked lautriv to do so (he will do against linux-3.3.3), lets' see. >>>>> > Also, I refreshed and adapted a bit the instructions (see attachment). >>>>> > >>>>> > - Sedat - >>>>> >>>>> [ CC Jim Cromie ] >>>>> >>>>> Now, with extracted firmware files renamed & copied to >>>>> /lib/firmware/mwl8k/ and applied patch (see attachment) against >>>>> Linux-3.4-rc4+ I am seeing with modinfo: >>>>> >>>>> $ sudo modinfo mwl8k >>>>> filename: >>>>> /lib/modules/3.4.0-rc4-5-generic/kernel/drivers/net/wireless/mwl8k.ko >>>>> license: GPL >>>>> author: Lennert Buytenhek <buytenh@marvell.com> >>>>> version: 0.13 >>>>> description: Marvell TOPDOG(R) 802.11 Wireless Network Driver >>>>> firmware: mwl8k/fmimage_8366_ap-2.fw >>>>> firmware: mwl8k/fmimage_8366.fw >>>>> firmware: mwl8k/helper_8366.fw >>>>> firmware: mwl8k/fmimage_8687.fw >>>>> firmware: mwl8k/helper_8687.fw >>>>> firmware: mwl8k/fmimage_8363.fw >>>>> firmware: mwl8k/helper_8363.fw >>>>> firmware: mwl8k/fmimage_8361p.fw >>>>> firmware: mwl8k/helper_8361p.fw >>>>> srcversion: 9E1479A05C8D67E6AE90746 >>>>> alias: pci:v000011ABd00002A43sv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A40sv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A30sv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A2Bsv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A24sv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A0Csv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A0Asv*sd*bc*sc*i* >>>>> alias: pci:v000011ABd00002A02sv*sd*bc*sc*i* <--- 8361P: >>>>> 0x2a02 PCI device-id >>>>> depends: mac80211,cfg80211 >>>>> vermagic: 3.4.0-rc4-5-generic SMP mod_unload modversions >>>>> parm: ap_mode_default:Set to 1 to make ap mode the default >>>>> instead of sta mode (bool) >>>>> >>>>> $ ls -l /lib/firmware/mwl8k/ >>>>> insgesamt 456 >>>>> -rw-r--r-- 1 root root 75848 Apr 27 13:49 fmimage_8361p.fw <--- >>>>> 8361P: Firmware image >>>>> -rw-r--r-- 1 root root 101780 Mär 19 19:32 fmimage_8366_ap-1.fw >>>>> -rw-r--r-- 1 root root 101976 Mär 19 19:32 fmimage_8366_ap-2.fw >>>>> -rw-r--r-- 1 root root 96664 Mär 19 19:32 fmimage_8366.fw >>>>> -rw-r--r-- 1 root root 73252 Feb 23 20:07 fmimage_8687.fw >>>>> -rw-r--r-- 1 root root 2476 Apr 27 13:49 helper_8361p.fw <--- 8361P: >>>>> Helper image >>>>> -rw-r--r-- 1 root root 2476 Mär 19 19:32 helper_8366.fw >>>>> -rw-r--r-- 1 root root 2476 Feb 23 20:07 helper_8687.fw >>>>> >>>>> As said... ***compile-tested*** only here. >>>> >>>> Which doesn't say much at all, but.. >>>> >>> >>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>> of course :-). >>> >>>> >>>>> I had a short query with lautriv on #linux-wireless this afternoon: >>>>> * mwl8k kernel-module was autoloaded >>>>> * wlan0 interface got fired up >>>>> * ESSID was accepted >>>>> * logs reported 802.11bgn support is active >>>>> * (he tested on Linux-3.3.3) >>>>> >>>>> With WPA/WPA2 lautriv had some problems as his installation was >>>>> missing wpasupplicant. >>>>> He setup a classic /etc/network/interfaces. >>>>> After resetting his router mwl8k worked nicely. >>>>> >>>>> Unfortunately, he was on the run and promised me to send logs and do >>>>> more testing this evening. >>>> >>>> ..but this is pretty interesting. I thought that the only available >>>> 8361p firmware used an incompatible firmware API, and I didn't know >>>> of the existence of an apparently compatible firmware. >>>> >>>> >>>>> So, Lennert if you want more testing - What? How? etc. >>>> >>>> For one, the output of 'iw phy', please. >>>> >>>> Also, does monitor mode work? Do you get plausible channel/rxpower >>>> values in tcpdump in monitor mode? >>>> >>>> Are there any messages in the syslog about failing commands? >>>> >>>> >>>> thanks, >>>> Lennert >>> >>> On 1st sight, logs look fine: >>> >>> [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, >>> 00173f3bdde3, STA firmware 2.1.4.25 >>> >>> But WLAN connection is not that fast and stable as lautriv reports >>> (several abnormalities were observed). >>> >>> I requested a tarball which includes: >>> * dmesg (Linux-3.3.3) >>> * e_n_a (/etc/network/interfaces) >>> * ifconfig output >>> * iwconfig output >>> * iw_phy output >>> * ps_axu (WPA) output >>> >>> lautriv will be so kind to be around on #linux-wireless/Freenode the >>> next days (UTC+2: German/Swiss local-time). >>> Just ping him. >>> >>> Hope you have fun, together! >>> >>> - Sedat - >> >> A new tarball from lautriv with same outputs as before, but now tested >> with Linux-3.4-rc4. >> >> - Sedat - > > > heres my logs, using firmware extracted by Sedat's script, > and the patch on mwl8k.c > > bottom-line, it appears to be working. > > its contents are a bit more pedantic, and includes data for > another wifi card (rtl8180 based) also in the box. > It was obtained by this script: > > #!/bin/bash > > # dmesg (Linux-3.3.3) > # e_n_a (/etc/network/interfaces) > # ifconfig output > # iwconfig output > # iw_phy output > # ps_axu (WPA) output > > devs="wlan0 wlan1" > apmac=00:14:d1:e8:65:0a > > loudly () { > echo "# $@" > fname=`echo $@ | sed -e 's/ /-/g'` > $@ 2> $fname-err | tee $fname > [ $? != 0 ] && echo non-zero exit on $fname: $? > [ -s $fname-err ] || rm $fname-err > } > > ( iw --debug event -f > iw-event-f )& > pid_event=$! > > for N in 0 1 ; do > loudly iw dev wlan$N interface add fish$N type monitor # flags none > loudly iw dev fish$N set channel 8 > loudly ifconfig fish$N up > ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& > pid_dump_fish$N=$! > done > > loudly iw list > > #loudly iwspy > # gives: Interface doesn't support wireless statistic collection > > for dev in $devs ; do > loudly ifconfig $dev > loudly iwconfig $dev > loudly iwlist $dev scan > loudly iw dev $dev info > loudly iw dev $dev link > loudly iw dev $dev scan > loudly iw dev $dev survey dump > done > > for phy in $phys ; do > loudly iw phy $phy info > done > > # these are unsupported on wlan0 > loudly iw dev wlan1 survey dump > loudly iw dev wlan1 station dump > loudly iw dev wlan1 station get $apmac > > > for N in 0 1 ; do > loudly iw dev fish$N del > done > > kill $pid_dump_fish0 $pid_dump_fish0 > kill $pid_event > > dmesg > dmesg > > grep -vE '^#|key' /etc/network/interfaces > e_n_a > > exit Hi Jim, thanks for your testing and the nice testcase-script! lautriv you wanna run some more tests with Jim's script? Jim, how stable/fast/reliable is your WLAN connection? Suspend/resume tested? Hope this helps to get native Linux support for 8361p. Regards, - Sedat - P.S.: BTW, only to clarify it should be "e_n_i" as short-form for /etc/network/interfaces file, but e_n_a sounds more female and nicer :-). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <jim.cromie@gmail.com> wrote: >>>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>>> of course :-). (I had to leave that one..:-) >>> >>> A new tarball from lautriv with same outputs as before, but now tested >>> with Linux-3.4-rc4. >>> >>> - Sedat - >> >> >> heres my logs, using firmware extracted by Sedat's script, >> and the patch on mwl8k.c >> >> bottom-line, it appears to be working. >> >> its contents are a bit more pedantic, and includes data for >> another wifi card (rtl8180 based) also in the box. >> It was obtained by this script: >> >> #!/bin/bash >> >> # dmesg (Linux-3.3.3) >> # e_n_a (/etc/network/interfaces) >> # ifconfig output >> # iwconfig output >> # iw_phy output >> # ps_axu (WPA) output >> >> devs="wlan0 wlan1" >> apmac=00:14:d1:e8:65:0a >> >> loudly () { >> echo "# $@" >> fname=`echo $@ | sed -e 's/ /-/g'` >> $@ 2> $fname-err | tee $fname >> [ $? != 0 ] && echo non-zero exit on $fname: $? >> [ -s $fname-err ] || rm $fname-err >> } >> >> ( iw --debug event -f > iw-event-f )& >> pid_event=$! >> >> for N in 0 1 ; do >> loudly iw dev wlan$N interface add fish$N type monitor # flags none >> loudly iw dev fish$N set channel 8 >> loudly ifconfig fish$N up >> ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& >> pid_dump_fish$N=$! >> done >> >> loudly iw list >> >> #loudly iwspy >> # gives: Interface doesn't support wireless statistic collection >> >> for dev in $devs ; do >> loudly ifconfig $dev >> loudly iwconfig $dev >> loudly iwlist $dev scan >> loudly iw dev $dev info >> loudly iw dev $dev link >> loudly iw dev $dev scan >> loudly iw dev $dev survey dump >> done >> >> for phy in $phys ; do >> loudly iw phy $phy info >> done >> >> # these are unsupported on wlan0 >> loudly iw dev wlan1 survey dump >> loudly iw dev wlan1 station dump >> loudly iw dev wlan1 station get $apmac >> >> >> for N in 0 1 ; do >> loudly iw dev fish$N del >> done >> >> kill $pid_dump_fish0 $pid_dump_fish0 >> kill $pid_event >> >> dmesg > dmesg >> >> grep -vE '^#|key' /etc/network/interfaces > e_n_a >> >> exit > > Hi Jim, > > thanks for your testing and the nice testcase-script! > > lautriv you wanna run some more tests with Jim's script? > > Jim, how stable/fast/reliable is your WLAN connection? > Suspend/resume tested? I havent tested reliability in any way. in fact, I havent tested any data-xfer per se, will do an iperf test soon. That said, bitrate is quite low, I havent looked at why. jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 MBit/s my laptop is much faster than both cards in the soekris box, to same AP Connected to 00:14:d1:e8:65:0a (on wlan0) SSID: yoduh freq: 2447 RX: 191134302 bytes (2120068 packets) TX: 17440426 bytes (120666 packets) signal: -45 dBm tx bitrate: 54.0 MBit/s bss flags: dtim period: 0 beacon int: 100 If you all have some suggestions on this, Id like to hear them. And of course, any other testing you'd like too. > > Hope this helps to get native Linux support for 8361p. hear hear. FWIW, I pulled this card out of a dead Netgear WNR854T, which is linux based (and GPL compliant) > Regards, > - Sedat - > > P.S.: BTW, only to clarify it should be "e_n_i" as short-form for > /etc/network/interfaces file, but e_n_a sounds more female and nicer > :-). I caught that, but it wasnt worth "correcting" ;-) thanks Jim -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie <jim.cromie@gmail.com> wrote: > On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <jim.cromie@gmail.com> wrote: > >>>>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>>>> of course :-). > > (I had to leave that one..:-) > > > >>>> >>>> A new tarball from lautriv with same outputs as before, but now tested >>>> with Linux-3.4-rc4. >>>> >>>> - Sedat - >>> >>> >>> heres my logs, using firmware extracted by Sedat's script, >>> and the patch on mwl8k.c >>> >>> bottom-line, it appears to be working. >>> >>> its contents are a bit more pedantic, and includes data for >>> another wifi card (rtl8180 based) also in the box. >>> It was obtained by this script: >>> >>> #!/bin/bash >>> >>> # dmesg (Linux-3.3.3) >>> # e_n_a (/etc/network/interfaces) >>> # ifconfig output >>> # iwconfig output >>> # iw_phy output >>> # ps_axu (WPA) output >>> >>> devs="wlan0 wlan1" >>> apmac=00:14:d1:e8:65:0a >>> >>> loudly () { >>> echo "# $@" >>> fname=`echo $@ | sed -e 's/ /-/g'` >>> $@ 2> $fname-err | tee $fname >>> [ $? != 0 ] && echo non-zero exit on $fname: $? >>> [ -s $fname-err ] || rm $fname-err >>> } >>> >>> ( iw --debug event -f > iw-event-f )& >>> pid_event=$! >>> >>> for N in 0 1 ; do >>> loudly iw dev wlan$N interface add fish$N type monitor # flags none >>> loudly iw dev fish$N set channel 8 >>> loudly ifconfig fish$N up >>> ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& >>> pid_dump_fish$N=$! >>> done >>> >>> loudly iw list >>> >>> #loudly iwspy >>> # gives: Interface doesn't support wireless statistic collection >>> >>> for dev in $devs ; do >>> loudly ifconfig $dev >>> loudly iwconfig $dev >>> loudly iwlist $dev scan >>> loudly iw dev $dev info >>> loudly iw dev $dev link >>> loudly iw dev $dev scan >>> loudly iw dev $dev survey dump >>> done >>> >>> for phy in $phys ; do >>> loudly iw phy $phy info >>> done >>> >>> # these are unsupported on wlan0 >>> loudly iw dev wlan1 survey dump >>> loudly iw dev wlan1 station dump >>> loudly iw dev wlan1 station get $apmac >>> >>> >>> for N in 0 1 ; do >>> loudly iw dev fish$N del >>> done >>> >>> kill $pid_dump_fish0 $pid_dump_fish0 >>> kill $pid_event >>> >>> dmesg > dmesg >>> >>> grep -vE '^#|key' /etc/network/interfaces > e_n_a >>> >>> exit >> >> Hi Jim, >> >> thanks for your testing and the nice testcase-script! >> >> lautriv you wanna run some more tests with Jim's script? >> >> Jim, how stable/fast/reliable is your WLAN connection? >> Suspend/resume tested? > > I havent tested reliability in any way. > in fact, I havent tested any data-xfer per se, > will do an iperf test soon. > > That said, bitrate is quite low, I havent looked at why. > > jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * > iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s > iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s > iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s > iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 MBit/s > > my laptop is much faster than both cards in the soekris box, to same AP > > Connected to 00:14:d1:e8:65:0a (on wlan0) > SSID: yoduh > freq: 2447 > RX: 191134302 bytes (2120068 packets) > TX: 17440426 bytes (120666 packets) > signal: -45 dBm > tx bitrate: 54.0 MBit/s > > bss flags: > dtim period: 0 > beacon int: 100 > > > If you all have some suggestions on this, Id like to hear them. > And of course, any other testing you'd like too. > > >> >> Hope this helps to get native Linux support for 8361p. > > hear hear. > FWIW, I pulled this card out of a dead Netgear WNR854T, > which is linux based (and GPL compliant) > >> Regards, >> - Sedat - >> >> P.S.: BTW, only to clarify it should be "e_n_i" as short-form for >> /etc/network/interfaces file, but e_n_a sounds more female and nicer >> :-). > > I caught that, but it wasnt worth "correcting" ;-) > > thanks > Jim Unfortunately, [1] says not much about debugging. Anyway, Lennert has some new informations. Let's see what the experts will say. - Sedat - [1] http://wireless.kernel.org/en/users/Drivers/mwl8k -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/29/2012 01:26 AM, Sedat Dilek wrote: > On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<jim.cromie@gmail.com> wrote: >> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<sedat.dilek@googlemail.com> wrote: >>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<jim.cromie@gmail.com> wrote: >>>>>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>>>>> of course :-). >> (I had to leave that one..:-) >> >> >> >>>>> A new tarball from lautriv with same outputs as before, but now tested >>>>> with Linux-3.4-rc4. >>>>> >>>>> - Sedat - >>>> >>>> heres my logs, using firmware extracted by Sedat's script, >>>> and the patch on mwl8k.c >>>> >>>> bottom-line, it appears to be working. >>>> >>>> its contents are a bit more pedantic, and includes data for >>>> another wifi card (rtl8180 based) also in the box. >>>> It was obtained by this script: >>>> >>>> #!/bin/bash >>>> >>>> # dmesg (Linux-3.3.3) >>>> # e_n_a (/etc/network/interfaces) >>>> # ifconfig output >>>> # iwconfig output >>>> # iw_phy output >>>> # ps_axu (WPA) output >>>> >>>> devs="wlan0 wlan1" >>>> apmac=00:14:d1:e8:65:0a >>>> >>>> loudly () { >>>> echo "# $@" >>>> fname=`echo $@ | sed -e 's/ /-/g'` >>>> $@ 2> $fname-err | tee $fname >>>> [ $? != 0 ]&& echo non-zero exit on $fname: $? >>>> [ -s $fname-err ] || rm $fname-err >>>> } >>>> >>>> ( iw --debug event -f> iw-event-f )& >>>> pid_event=$! >>>> >>>> for N in 0 1 ; do >>>> loudly iw dev wlan$N interface add fish$N type monitor # flags none >>>> loudly iw dev fish$N set channel 8 >>>> loudly ifconfig fish$N up >>>> ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& >>>> pid_dump_fish$N=$! >>>> done >>>> >>>> loudly iw list >>>> >>>> #loudly iwspy >>>> # gives: Interface doesn't support wireless statistic collection >>>> >>>> for dev in $devs ; do >>>> loudly ifconfig $dev >>>> loudly iwconfig $dev >>>> loudly iwlist $dev scan >>>> loudly iw dev $dev info >>>> loudly iw dev $dev link >>>> loudly iw dev $dev scan >>>> loudly iw dev $dev survey dump >>>> done >>>> >>>> for phy in $phys ; do >>>> loudly iw phy $phy info >>>> done >>>> >>>> # these are unsupported on wlan0 >>>> loudly iw dev wlan1 survey dump >>>> loudly iw dev wlan1 station dump >>>> loudly iw dev wlan1 station get $apmac >>>> >>>> >>>> for N in 0 1 ; do >>>> loudly iw dev fish$N del >>>> done >>>> >>>> kill $pid_dump_fish0 $pid_dump_fish0 >>>> kill $pid_event >>>> >>>> dmesg> dmesg >>>> >>>> grep -vE '^#|key' /etc/network/interfaces> e_n_a >>>> >>>> exit >>> Hi Jim, >>> >>> thanks for your testing and the nice testcase-script! >>> >>> lautriv you wanna run some more tests with Jim's script? >>> >>> Jim, how stable/fast/reliable is your WLAN connection? >>> Suspend/resume tested? >> I havent tested reliability in any way. >> in fact, I havent tested any data-xfer per se, >> will do an iperf test soon. >> >> That said, bitrate is quite low, I havent looked at why. >> >> jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * >> iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s >> iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s >> iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s >> iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 MBit/s >> >> my laptop is much faster than both cards in the soekris box, to same AP >> >> Connected to 00:14:d1:e8:65:0a (on wlan0) >> SSID: yoduh >> freq: 2447 >> RX: 191134302 bytes (2120068 packets) >> TX: 17440426 bytes (120666 packets) >> signal: -45 dBm >> tx bitrate: 54.0 MBit/s >> >> bss flags: >> dtim period: 0 >> beacon int: 100 >> >> >> If you all have some suggestions on this, Id like to hear them. >> And of course, any other testing you'd like too. >> >> >>> Hope this helps to get native Linux support for 8361p. >> hear hear. >> FWIW, I pulled this card out of a dead Netgear WNR854T, >> which is linux based (and GPL compliant) >> >>> Regards, >>> - Sedat - >>> >>> P.S.: BTW, only to clarify it should be "e_n_i" as short-form for >>> /etc/network/interfaces file, but e_n_a sounds more female and nicer >>> :-). >> I caught that, but it wasnt worth "correcting" ;-) >> >> thanks >> Jim > Unfortunately, [1] says not much about debugging. > Anyway, Lennert has some new informations. > Let's see what the experts will say. > > - Sedat - > > [1] http://wireless.kernel.org/en/users/Drivers/mwl8k > ok, as far as i can see for now, it looks like the actual solution is ignoring/rejecting any manual command to set parameters, neither iwconfig nor iw will change any settings. wpa_sup brings the card up and does also WPA2 but nothing else is tuneable thus a connection via 1Mb/s. attaching a tarball from the results of the script which produced 42 files of output.
On Sun, Apr 29, 2012 at 7:34 PM, admin <admin@coldplug.net> wrote: > On 04/29/2012 01:26 AM, Sedat Dilek wrote: >> >> On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<jim.cromie@gmail.com> wrote: >>> >>> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<sedat.dilek@googlemail.com> >>> wrote: >>>> >>>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<jim.cromie@gmail.com> >>>> wrote: >>>>>>> >>>>>>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>>>>>> of course :-). >>> >>> (I had to leave that one..:-) >>> >>> >>> >>>>>> A new tarball from lautriv with same outputs as before, but now tested >>>>>> with Linux-3.4-rc4. >>>>>> >>>>>> - Sedat - >>>>> >>>>> >>>>> heres my logs, using firmware extracted by Sedat's script, >>>>> and the patch on mwl8k.c >>>>> >>>>> bottom-line, it appears to be working. >>>>> >>>>> its contents are a bit more pedantic, and includes data for >>>>> another wifi card (rtl8180 based) also in the box. >>>>> It was obtained by this script: >>>>> >>>>> #!/bin/bash >>>>> >>>>> # dmesg (Linux-3.3.3) >>>>> # e_n_a (/etc/network/interfaces) >>>>> # ifconfig output >>>>> # iwconfig output >>>>> # iw_phy output >>>>> # ps_axu (WPA) output >>>>> >>>>> devs="wlan0 wlan1" >>>>> apmac=00:14:d1:e8:65:0a >>>>> >>>>> loudly () { >>>>> echo "# $@" >>>>> fname=`echo $@ | sed -e 's/ /-/g'` >>>>> $@ 2> $fname-err | tee $fname >>>>> [ $? != 0 ]&& echo non-zero exit on $fname: $? >>>>> [ -s $fname-err ] || rm $fname-err >>>>> } >>>>> >>>>> ( iw --debug event -f> iw-event-f )& >>>>> pid_event=$! >>>>> >>>>> for N in 0 1 ; do >>>>> loudly iw dev wlan$N interface add fish$N type monitor # flags none >>>>> loudly iw dev fish$N set channel 8 >>>>> loudly ifconfig fish$N up >>>>> ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& >>>>> pid_dump_fish$N=$! >>>>> done >>>>> >>>>> loudly iw list >>>>> >>>>> #loudly iwspy >>>>> # gives: Interface doesn't support wireless statistic collection >>>>> >>>>> for dev in $devs ; do >>>>> loudly ifconfig $dev >>>>> loudly iwconfig $dev >>>>> loudly iwlist $dev scan >>>>> loudly iw dev $dev info >>>>> loudly iw dev $dev link >>>>> loudly iw dev $dev scan >>>>> loudly iw dev $dev survey dump >>>>> done >>>>> >>>>> for phy in $phys ; do >>>>> loudly iw phy $phy info >>>>> done >>>>> >>>>> # these are unsupported on wlan0 >>>>> loudly iw dev wlan1 survey dump >>>>> loudly iw dev wlan1 station dump >>>>> loudly iw dev wlan1 station get $apmac >>>>> >>>>> >>>>> for N in 0 1 ; do >>>>> loudly iw dev fish$N del >>>>> done >>>>> >>>>> kill $pid_dump_fish0 $pid_dump_fish0 >>>>> kill $pid_event >>>>> >>>>> dmesg> dmesg >>>>> >>>>> grep -vE '^#|key' /etc/network/interfaces> e_n_a >>>>> >>>>> exit >>>> >>>> Hi Jim, >>>> >>>> thanks for your testing and the nice testcase-script! >>>> >>>> lautriv you wanna run some more tests with Jim's script? >>>> >>>> Jim, how stable/fast/reliable is your WLAN connection? >>>> Suspend/resume tested? >>> >>> I havent tested reliability in any way. >>> in fact, I havent tested any data-xfer per se, >>> will do an iperf test soon. >>> >>> That said, bitrate is quite low, I havent looked at why. >>> >>> jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * >>> iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s >>> iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s >>> iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s >>> iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 >>> MBit/s >>> >>> my laptop is much faster than both cards in the soekris box, to same AP >>> >>> Connected to 00:14:d1:e8:65:0a (on wlan0) >>> SSID: yoduh >>> freq: 2447 >>> RX: 191134302 bytes (2120068 packets) >>> TX: 17440426 bytes (120666 packets) >>> signal: -45 dBm >>> tx bitrate: 54.0 MBit/s >>> >>> bss flags: >>> dtim period: 0 >>> beacon int: 100 >>> >>> >>> If you all have some suggestions on this, Id like to hear them. >>> And of course, any other testing you'd like too. >>> >>> >>>> Hope this helps to get native Linux support for 8361p. >>> >>> hear hear. >>> FWIW, I pulled this card out of a dead Netgear WNR854T, >>> which is linux based (and GPL compliant) >>> >>>> Regards, >>>> - Sedat - >>>> >>>> P.S.: BTW, only to clarify it should be "e_n_i" as short-form for >>>> /etc/network/interfaces file, but e_n_a sounds more female and nicer >>>> :-). >>> >>> I caught that, but it wasnt worth "correcting" ;-) >>> >>> thanks >>> Jim >> >> Unfortunately, [1] says not much about debugging. >> Anyway, Lennert has some new informations. >> Let's see what the experts will say. >> >> - Sedat - >> >> [1] http://wireless.kernel.org/en/users/Drivers/mwl8k >> > > ok, as far as i can see for now, it looks like the actual solution is > ignoring/rejecting any manual command to set parameters, neither iwconfig > nor iw will change any settings. wpa_sup brings the card up and does also > WPA2 but nothing else is tuneable thus a connection via 1Mb/s. > > attaching a tarball from the results of the script which produced 42 files > of output. > Credits for the script go to Jim, not me! - Sedat - -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/29/2012 07:49 PM, Sedat Dilek wrote: > On Sun, Apr 29, 2012 at 7:34 PM, admin<admin@coldplug.net> wrote: >> On 04/29/2012 01:26 AM, Sedat Dilek wrote: >>> On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<jim.cromie@gmail.com> wrote: >>>> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<sedat.dilek@googlemail.com> >>>> wrote: >>>>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<jim.cromie@gmail.com> >>>>> wrote: >>>>>>>> As already pointed out, no Marwell WLAN hardware here. Marvell comics >>>>>>>> of course :-). >>>> (I had to leave that one..:-) >>>> >>>> >>>> >>>>>>> A new tarball from lautriv with same outputs as before, but now tested >>>>>>> with Linux-3.4-rc4. >>>>>>> >>>>>>> - Sedat - >>>>>> >>>>>> heres my logs, using firmware extracted by Sedat's script, >>>>>> and the patch on mwl8k.c >>>>>> >>>>>> bottom-line, it appears to be working. >>>>>> >>>>>> its contents are a bit more pedantic, and includes data for >>>>>> another wifi card (rtl8180 based) also in the box. >>>>>> It was obtained by this script: >>>>>> >>>>>> #!/bin/bash >>>>>> >>>>>> # dmesg (Linux-3.3.3) >>>>>> # e_n_a (/etc/network/interfaces) >>>>>> # ifconfig output >>>>>> # iwconfig output >>>>>> # iw_phy output >>>>>> # ps_axu (WPA) output >>>>>> >>>>>> devs="wlan0 wlan1" >>>>>> apmac=00:14:d1:e8:65:0a >>>>>> >>>>>> loudly () { >>>>>> echo "# $@" >>>>>> fname=`echo $@ | sed -e 's/ /-/g'` >>>>>> $@ 2> $fname-err | tee $fname >>>>>> [ $? != 0 ]&& echo non-zero exit on $fname: $? >>>>>> [ -s $fname-err ] || rm $fname-err >>>>>> } >>>>>> >>>>>> ( iw --debug event -f> iw-event-f )& >>>>>> pid_event=$! >>>>>> >>>>>> for N in 0 1 ; do >>>>>> loudly iw dev wlan$N interface add fish$N type monitor # flags none >>>>>> loudly iw dev fish$N set channel 8 >>>>>> loudly ifconfig fish$N up >>>>>> ( tcpdump -i fish$N -s 65000 -p -U -w fish$N.dump )& >>>>>> pid_dump_fish$N=$! >>>>>> done >>>>>> >>>>>> loudly iw list >>>>>> >>>>>> #loudly iwspy >>>>>> # gives: Interface doesn't support wireless statistic collection >>>>>> >>>>>> for dev in $devs ; do >>>>>> loudly ifconfig $dev >>>>>> loudly iwconfig $dev >>>>>> loudly iwlist $dev scan >>>>>> loudly iw dev $dev info >>>>>> loudly iw dev $dev link >>>>>> loudly iw dev $dev scan >>>>>> loudly iw dev $dev survey dump >>>>>> done >>>>>> >>>>>> for phy in $phys ; do >>>>>> loudly iw phy $phy info >>>>>> done >>>>>> >>>>>> # these are unsupported on wlan0 >>>>>> loudly iw dev wlan1 survey dump >>>>>> loudly iw dev wlan1 station dump >>>>>> loudly iw dev wlan1 station get $apmac >>>>>> >>>>>> >>>>>> for N in 0 1 ; do >>>>>> loudly iw dev fish$N del >>>>>> done >>>>>> >>>>>> kill $pid_dump_fish0 $pid_dump_fish0 >>>>>> kill $pid_event >>>>>> >>>>>> dmesg> dmesg >>>>>> >>>>>> grep -vE '^#|key' /etc/network/interfaces> e_n_a >>>>>> >>>>>> exit >>>>> Hi Jim, >>>>> >>>>> thanks for your testing and the nice testcase-script! >>>>> >>>>> lautriv you wanna run some more tests with Jim's script? >>>>> >>>>> Jim, how stable/fast/reliable is your WLAN connection? >>>>> Suspend/resume tested? >>>> I havent tested reliability in any way. >>>> in fact, I havent tested any data-xfer per se, >>>> will do an iperf test soon. >>>> >>>> That said, bitrate is quite low, I havent looked at why. >>>> >>>> jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * >>>> iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s >>>> iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s >>>> iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s >>>> iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 >>>> MBit/s >>>> >>>> my laptop is much faster than both cards in the soekris box, to same AP >>>> >>>> Connected to 00:14:d1:e8:65:0a (on wlan0) >>>> SSID: yoduh >>>> freq: 2447 >>>> RX: 191134302 bytes (2120068 packets) >>>> TX: 17440426 bytes (120666 packets) >>>> signal: -45 dBm >>>> tx bitrate: 54.0 MBit/s >>>> >>>> bss flags: >>>> dtim period: 0 >>>> beacon int: 100 >>>> >>>> >>>> If you all have some suggestions on this, Id like to hear them. >>>> And of course, any other testing you'd like too. >>>> >>>> >>>>> Hope this helps to get native Linux support for 8361p. >>>> hear hear. >>>> FWIW, I pulled this card out of a dead Netgear WNR854T, >>>> which is linux based (and GPL compliant) >>>> >>>>> Regards, >>>>> - Sedat - >>>>> >>>>> P.S.: BTW, only to clarify it should be "e_n_i" as short-form for >>>>> /etc/network/interfaces file, but e_n_a sounds more female and nicer >>>>> :-). >>>> I caught that, but it wasnt worth "correcting" ;-) >>>> >>>> thanks >>>> Jim >>> Unfortunately, [1] says not much about debugging. >>> Anyway, Lennert has some new informations. >>> Let's see what the experts will say. >>> >>> - Sedat - >>> >>> [1] http://wireless.kernel.org/en/users/Drivers/mwl8k >>> >> ok, as far as i can see for now, it looks like the actual solution is >> ignoring/rejecting any manual command to set parameters, neither iwconfig >> nor iw will change any settings. wpa_sup brings the card up and does also >> WPA2 but nothing else is tuneable thus a connection via 1Mb/s. >> >> attaching a tarball from the results of the script which produced 42 files >> of output. >> > Credits for the script go to Jim, not me! > > - Sedat - > So i investigated in a bit further testing, where my router was taken into account too....... Seems the patch/driver/hardware works a bit better than one can see from the output. i changed my router to different setups with a/b/g/n g/n and n only and even the testbox reported always 1Mb/s , my router found the device connected to certain other speeds such as 24/84/120/240 depending on his own rules. When in N-only, the router insisted on AES instead TKIP which may be somewhere defined, however the card itself followed the rule silently ( i held wlan0 up ). speed result was not that magic, gave me an average of 2.2MB/s in mixed mode and 3.6 MB/s in N-only ( where the router showed a connection with 240 Mb/s ) while my signal was always between 96 and 100%. Because this device was made for winblows only, i could imagine they byte-swapped or moved an offset and it may be worth to compare some kind of register-dump right after init with another topdog like 8363. Helmut. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2012 at 11:53:28PM +0200, Sedat Dilek wrote: > >> So, Lennert if you want more testing - What? How? etc. > > > > For one, the output of 'iw phy', please. > > > > Also, does monitor mode work? Do you get plausible channel/rxpower > > values in tcpdump in monitor mode? > > > > Are there any messages in the syslog about failing commands? > > On 1st sight, logs look fine: > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > 00173f3bdde3, STA firmware 2.1.4.25 > > But WLAN connection is not that fast and stable as lautriv reports > (several abnormalities were observed). iwconfig saying "Bit Rate=1 Mb/s" can be safely ignored. If there is a bitrate indication on transmitted packets in tcpdump, then that's bogus too, as rate control is done in hardware. (I.e. if you want to verify the rate at which a packet is transmitted, you'll have to sniff from another machine.) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: > > On 1st sight, logs look fine: > > > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > > 00173f3bdde3, STA firmware 2.1.4.25 > > > > But WLAN connection is not that fast and stable as lautriv reports > > (several abnormalities were observed). > > > > I requested a tarball which includes: > > * dmesg (Linux-3.3.3) > > * e_n_a (/etc/network/interfaces) > > * ifconfig output > > * iwconfig output > > * iw_phy output > > * ps_axu (WPA) output > > > > lautriv will be so kind to be around on #linux-wireless/Freenode the > > next days (UTC+2: German/Swiss local-time). > > Just ping him. > > > > Hope you have fun, together! > > > > - Sedat - > > A new tarball from lautriv with same outputs as before, but now tested > with Linux-3.4-rc4. The output looks good enough for me to ACK adding the PCI ID. Can the firmware being used here be submitted to the linux-firmware git tree? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 28, 2012 at 05:11:06PM -0600, Jim Cromie wrote: > That said, bitrate is quite low, I havent looked at why. > > jimc@chumly:~/projects/lx/wifi/mwl8k-8361p-logs$ grep -i MBit * > iw-dev-wlan0-link: tx bitrate: 11.0 MBit/s > iw-dev-wlan1-link: tx bitrate: 1.0 MBit/s > iw-dev-wlan1-station-dump: tx bitrate: 1.0 MBit/s > iw-dev-wlan1-station-get-00:14:d1:e8:65:0a: tx bitrate: 1.0 MBit/s You can ignore those values, they don't reflect the actual transmittion rate in use. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: > >> > On 1st sight, logs look fine: >> > >> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, >> > 00173f3bdde3, STA firmware 2.1.4.25 >> > >> > But WLAN connection is not that fast and stable as lautriv reports >> > (several abnormalities were observed). >> > >> > I requested a tarball which includes: >> > * dmesg (Linux-3.3.3) >> > * e_n_a (/etc/network/interfaces) >> > * ifconfig output >> > * iwconfig output >> > * iw_phy output >> > * ps_axu (WPA) output >> > >> > lautriv will be so kind to be around on #linux-wireless/Freenode the >> > next days (UTC+2: German/Swiss local-time). >> > Just ping him. >> > >> > Hope you have fun, together! >> > >> > - Sedat - >> >> A new tarball from lautriv with same outputs as before, but now tested >> with Linux-3.4-rc4. [ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ] > The output looks good enough for me to ACK adding the PCI ID. > > Can the firmware being used here be submitted to the linux-firmware > git tree? I can't say much about the firmware [1] inclusion or the procedure of it into linux-firmware [2]. Maybe, Ben can explain the procedure and what has to be considered before inclusion in linux-firmware. The original firmware and helper images were extracted from a Netgear Windows driver [1]. From what I read in the OpenWrt forum posting [3]: You wanted to care for inclusion: "Firmware isn't included in the kernel tree anymore, there's the linux-firmware git tree for that these days. I will contact some people at Marvell to ask whether 8361P firmware can be included there." Some more concerns... Dunno, if [4] is really correct and how to use one and same device-id for 8363 ***and*** 8361P: ... { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, }, ... Curious about a statement from hauke... Adding the device-id in case of 8361P is not enough (see attached patch) I am looking forward to having support for 8361P soon. - Sedat - P.S.: I have re-added Readme and patch as there are new CCs. [1] ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe [2] http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary [3] https://forum.openwrt.org/viewtopic.php?pid=110039#p110039 [4] https://dev.openwrt.org/changeset/21167 ##### HOWTO: Extract the firmware for the mwl8k Linux WLAN driver ##### ### HELP-1: https://forum.openwrt.org/viewtopic.php?pid=103243#p103243 ### HELP-2: https://forum.openwrt.org/viewtopic.php?pid=110004#p110004 ### THREAD: http://marc.info/?t=133551792600004&r=1&w=2 ### Install some tools to inspect file containing firmware blob sudo apt-get install cabextract unshield ### Working directory mkdir mwl8k cd mwl8k ### Download c-file (extract firmware) and Windows setup file (incl. firmware) mkdir files cd files wget -O mrv8k_extract_fw.c 'http://marc.info/?l=linux-wireless&m=126540674419330&q=p3' wget ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe ### Extract firmware blob mkdir .tmp ../firmware cabextract -F Disk1/data*.* -d .tmp wn311t_4_2_setup.exe unshield -g Driver -d .tmp x .tmp/Disk1/data1.cab gcc -o mrv8k_extract_fw mrv8k_extract_fw.c ./mrv8k_extract_fw .tmp/Driver/netmw145.sys mv *.fw ../firmware/ rm -r -f .tmp ### Check MD5SUM and rename firmware/helper image files for 8361P/8363 [ Known MD5SUMS for 8361P ] 48c79b085f7f5a590d3dbc15647e519f *fmimage_8XX0.fw 0fe11f415adbbd5e8ca03641705c4a6c *helper_8XX0.fw cd ../firmware md5sum -b *.fw mv fmimage_8XX0.fw fmimage_8361p.fw mv helper_8XX0.fw helper_8361p.fw mv fmimage_8XX1.fw fmimage_8363.fw mv helper_8XX1.fw helper_8363.fw -dileks // 27-Apr-2012
On Tue, May 01, 2012 at 03:54:49PM +0200, Sedat Dilek wrote: > Some more concerns... > Dunno, if [4] is really correct and how to use one and same device-id > for 8363 ***and*** 8361P: > ... > { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, }, No, you'll have to add a MWL8361P to the enum, and add a mwl8k_device_info table entry for that, and then add the PCI ID table entry with the MWL8361P identifier. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/01/2012 09:54 AM, Sedat Dilek wrote: > --- a/drivers/net/wireless/mwl8k.c > +++ b/drivers/net/wireless/mwl8k.c > @@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work) > } > > enum { > + MWL8361P = 0, > MWL8363 = 0, > MWL8687, > MWL8366, I'm not an expert, but isn't this giving both 8361P and 8363 the same values in the enum? Is that intended? Pat Erley -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 01, 2012 at 09:12:25PM -0400, Pat Erley wrote: > >--- a/drivers/net/wireless/mwl8k.c > >+++ b/drivers/net/wireless/mwl8k.c > >@@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work) > > } > > > > enum { > >+ MWL8361P = 0, > > MWL8363 = 0, > > MWL8687, > > MWL8366, > > I'm not an expert, but isn't this giving both 8361P and 8363 the > same values in the enum? Yeah, this is broken. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/01/2012 03:54 PM, Sedat Dilek wrote: > On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek > <buytenh@wantstofly.org> wrote: >> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: >> >>>> On 1st sight, logs look fine: >>>> >>>> [21:52:52]<lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, >>>> 00173f3bdde3, STA firmware 2.1.4.25 >>>> >>>> But WLAN connection is not that fast and stable as lautriv reports >>>> (several abnormalities were observed). >>>> >>>> I requested a tarball which includes: >>>> * dmesg (Linux-3.3.3) >>>> * e_n_a (/etc/network/interfaces) >>>> * ifconfig output >>>> * iwconfig output >>>> * iw_phy output >>>> * ps_axu (WPA) output >>>> >>>> lautriv will be so kind to be around on #linux-wireless/Freenode the >>>> next days (UTC+2: German/Swiss local-time). >>>> Just ping him. >>>> >>>> Hope you have fun, together! >>>> >>>> - Sedat - >>> >>> A new tarball from lautriv with same outputs as before, but now tested >>> with Linux-3.4-rc4. > > [ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ] > >> The output looks good enough for me to ACK adding the PCI ID. >> >> Can the firmware being used here be submitted to the linux-firmware >> git tree? > > I can't say much about the firmware [1] inclusion or the procedure of > it into linux-firmware [2]. > Maybe, Ben can explain the procedure and what has to be considered > before inclusion in linux-firmware. > The original firmware and helper images were extracted from a Netgear > Windows driver [1]. > > From what I read in the OpenWrt forum posting [3]: You wanted to care > for inclusion: > > "Firmware isn't included in the kernel tree anymore, there's the > linux-firmware git tree for that these days. I will contact some > people at Marvell to ask whether 8361P firmware can be included > there." Basically, all firmware in linux-firmware repository should be accompanied with license information. Also you are signing off the patch to add the firmware to the repository so you are bound to the Developer's Certificate of Origin 1.1 in [1]. Having the firmware extracted from a windows driver does not fall under that statement, unless Marvell is ok with its redistribution. Recently a patch was submitted for a README in the linux-firmware repository about the process. It must be a binary patch. Easiest way is to use 'git format-patch -B'. Gr. AvS [1] http://lxr.linux.no/linux+v3.3.4/Documentation/SubmittingPatches [2] https://lkml.org/lkml/2012/4/21/177 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 2, 2012 at 4:38 AM, Lennert Buytenhek <buytenh@wantstofly.org> wrote: > On Tue, May 01, 2012 at 09:12:25PM -0400, Pat Erley wrote: > >> >--- a/drivers/net/wireless/mwl8k.c >> >+++ b/drivers/net/wireless/mwl8k.c >> >@@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work) >> > } >> > >> > enum { >> >+ MWL8361P = 0, >> > MWL8363 = 0, >> > MWL8687, >> > MWL8366, >> >> I'm not an expert, but isn't this giving both 8361P and 8363 the >> same values in the enum? > > Yeah, this is broken. Before this email, Helmut pointed me to the enum thingie in a private query. As I was busy with OverlayFS the last days, I couldn't give that information back. So, this should be: ... enum { MWL8361P = 0, MWL8363, MWL8687, MWL8366, ... Shall I cook up a new patch with a proper history and documented origin (original patch is from OpenWrt, I refreshed it against upstream)? ...add some Tested-by (Helmut, Jim)... ...send that to linux-wireless ML for a review? - Sedat - -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2012-05-01 at 15:54 +0200, Sedat Dilek wrote: > On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek > <buytenh@wantstofly.org> wrote: > > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: > > > >> > On 1st sight, logs look fine: > >> > > >> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > >> > 00173f3bdde3, STA firmware 2.1.4.25 > >> > > >> > But WLAN connection is not that fast and stable as lautriv reports > >> > (several abnormalities were observed). > >> > > >> > I requested a tarball which includes: > >> > * dmesg (Linux-3.3.3) > >> > * e_n_a (/etc/network/interfaces) > >> > * ifconfig output > >> > * iwconfig output > >> > * iw_phy output > >> > * ps_axu (WPA) output > >> > > >> > lautriv will be so kind to be around on #linux-wireless/Freenode the > >> > next days (UTC+2: German/Swiss local-time). > >> > Just ping him. > >> > > >> > Hope you have fun, together! > >> > > >> > - Sedat - > >> > >> A new tarball from lautriv with same outputs as before, but now tested > >> with Linux-3.4-rc4. > > [ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ] > > > The output looks good enough for me to ACK adding the PCI ID. > > > > Can the firmware being used here be submitted to the linux-firmware > > git tree? > > I can't say much about the firmware [1] inclusion or the procedure of > it into linux-firmware [2]. > Maybe, Ben can explain the procedure and what has to be considered > before inclusion in linux-firmware. > The original firmware and helper images were extracted from a Netgear > Windows driver [1]. [...] Even assuming that the original driver binary is freely redistributable, it's not at all clear that these extracted blobs would be. If there's some difficulty in getting a sensible licence for the firmware, you can consider providing a tool to do this extraction, as has been done for some other drivers whose vendors don't provide the firmware blobs alone. However, as yet, linux-firmware doesn't include any such extraction tools and I would need to discuss such an addition with David (and maybe other distribution maintainers). Hopefully that won't be necessary, though. Ben.
On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote: > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: > > > > On 1st sight, logs look fine: > > > > > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > > > 00173f3bdde3, STA firmware 2.1.4.25 > > > > > > But WLAN connection is not that fast and stable as lautriv reports > > > (several abnormalities were observed). > > > > > > I requested a tarball which includes: > > > * dmesg (Linux-3.3.3) > > > * e_n_a (/etc/network/interfaces) > > > * ifconfig output > > > * iwconfig output > > > * iw_phy output > > > * ps_axu (WPA) output > > > > > > lautriv will be so kind to be around on #linux-wireless/Freenode the > > > next days (UTC+2: German/Swiss local-time). > > > Just ping him. > > > > > > Hope you have fun, together! > > > > > > - Sedat - > > > > A new tarball from lautriv with same outputs as before, but now tested > > with Linux-3.4-rc4. > > The output looks good enough for me to ACK adding the PCI ID. > > Can the firmware being used here be submitted to the linux-firmware > git tree? So Marvell sent John a driver for TopDog a long time ago, which he put up on kernel.org. That driver was reworked by Louis and put up in a git tree, but both were lost to the kernel.org hack. I have git backups of both git trees. I put Louis' cleanup here: http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2 That driver (mrvl_cb82) has the following PCI IDs: static const struct pci_device_id mwl_id_tbl[] __devinitdata = { { PCI_VDEVICE(MARVELL, 0x2a02), 0 }, { PCI_VDEVICE(MARVELL, 0x2a03), 1 }, { PCI_VDEVICE(MARVELL, 0x2a06), 2 }, { PCI_VDEVICE(MARVELL, 0x2a07), 3 }, { PCI_VDEVICE(MARVELL, 0x2a04), 4 }, { PCI_VDEVICE(MARVELL, 0x2a08), 5 }, { PCI_VDEVICE(MARVELL, 0x2a0a), 6 }, { PCI_VDEVICE(MARVELL, 0x2a0b), 7 }, { PCI_VDEVICE(MARVELL, 0x2a0c), 8 }, { 0 } }; and supposedly works for CB82 + CB85. The firmware helper for CB82 looks pretty close to the mwl8k one. The firmware API exposed by mrvl_cb82 looks very close to mwl8k actually. I only checked the HostCmd bits, not the structures, so I would expect a few differences. There are some commands that mwl8k exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the drivers actually use those commands. Hope this helps. Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2012-05-07 at 11:09 -0500, Dan Williams wrote: > On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote: > > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote: > > > > > > On 1st sight, logs look fine: > > > > > > > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4, > > > > 00173f3bdde3, STA firmware 2.1.4.25 > > > > > > > > But WLAN connection is not that fast and stable as lautriv reports > > > > (several abnormalities were observed). > > > > > > > > I requested a tarball which includes: > > > > * dmesg (Linux-3.3.3) > > > > * e_n_a (/etc/network/interfaces) > > > > * ifconfig output > > > > * iwconfig output > > > > * iw_phy output > > > > * ps_axu (WPA) output > > > > > > > > lautriv will be so kind to be around on #linux-wireless/Freenode the > > > > next days (UTC+2: German/Swiss local-time). > > > > Just ping him. > > > > > > > > Hope you have fun, together! > > > > > > > > - Sedat - > > > > > > A new tarball from lautriv with same outputs as before, but now tested > > > with Linux-3.4-rc4. > > > > The output looks good enough for me to ACK adding the PCI ID. > > > > Can the firmware being used here be submitted to the linux-firmware > > git tree? > > So Marvell sent John a driver for TopDog a long time ago, which he put > up on kernel.org. That driver was reworked by Louis and put up in a git > tree, but both were lost to the kernel.org hack. I have git backups of > both git trees. I put Louis' cleanup here: > > http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2 > > That driver (mrvl_cb82) has the following PCI IDs: > > static const struct pci_device_id mwl_id_tbl[] __devinitdata = { > { PCI_VDEVICE(MARVELL, 0x2a02), 0 }, > { PCI_VDEVICE(MARVELL, 0x2a03), 1 }, > { PCI_VDEVICE(MARVELL, 0x2a06), 2 }, > { PCI_VDEVICE(MARVELL, 0x2a07), 3 }, > { PCI_VDEVICE(MARVELL, 0x2a04), 4 }, > { PCI_VDEVICE(MARVELL, 0x2a08), 5 }, > { PCI_VDEVICE(MARVELL, 0x2a0a), 6 }, > { PCI_VDEVICE(MARVELL, 0x2a0b), 7 }, > { PCI_VDEVICE(MARVELL, 0x2a0c), 8 }, > { 0 } > }; > > and supposedly works for CB82 + CB85. The firmware helper for CB82 > looks pretty close to the mwl8k one. > > The firmware API exposed by mrvl_cb82 looks very close to mwl8k > actually. I only checked the HostCmd bits, not the structures, so I > would expect a few differences. There are some commands that mwl8k > exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the > drivers actually use those commands. As for AP mode, the Marvell Extranet does have AP-mode drivers for the 8361 and 8363, but the zipfiles are password-protected and I have no idea what license they are supposed to be under due to that. Thus I cannot get the AP mode firmware for those either to submit to linux-firmware. Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Let me see if the topdog firmware that FreeBSD ships with supports hostap mode. I'm having aggregation issues but I think that's driver side, not firmware side. Adrian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/07/2012 08:26 PM, Adrian Chadd wrote: > Hi, > > Let me see if the topdog firmware that FreeBSD ships with supports hostap mode. > > I'm having aggregation issues but I think that's driver side, not firmware side. > > > > Adrian > i didn't change anything since the manual addition of the patch into 3.4-rc and it looks like only the reported speed is worse, taking the card up with wpa_sup gives me enought speed to transfer audiovisual content without loss or stutter. ( card is on a mythfrontend using DVD-quality streams ). may be comfortable to have certain commands working or using the AP capabilities but at least the gerneric usage is given. Helmut -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c index b48674b..16f0a9a 100644 --- a/drivers/net/wireless/mwl8k.c +++ b/drivers/net/wireless/mwl8k.c @@ -5264,6 +5264,7 @@ MODULE_FIRMWARE("mwl8k/fmimage_8366.fw"); MODULE_FIRMWARE(MWL8K_8366_AP_FW(MWL8K_8366_AP_FW_API)); static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = { + { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, }, { PCI_VDEVICE(MARVELL, 0x2a0a), .driver_data = MWL8363, }, { PCI_VDEVICE(MARVELL, 0x2a0c), .driver_data = MWL8363, }, { PCI_VDEVICE(MARVELL, 0x2a24), .driver_data = MWL8363, },
User lautriv asked for belkin N-1 WLAN device support on IRC. Further informations from lautriv: * marvell 80W8031, card-id 11ab:2a02 * Debian/sid 3.2.x On [1] I found a report by Jim Cromie concerning same PCI device-id: 00:0e.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] (rev 03) Subsystem: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] So, let's add 0x2a02 to PCI device table. [1] http://www.spinics.net/lists/newbies/msg46601.html Cc: stable@vger.kernel.org Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com> --- drivers/net/wireless/mwl8k.c | 1 + 1 file changed, 1 insertion(+)