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: [email protected]
Signed-off-by: Sedat Dilek <[email protected]>
---
drivers/net/wireless/mwl8k.c | 1 +
1 file changed, 1 insertion(+)
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, },
--
1.7.9.5
[dropped lkml from cc]
On Sat, Apr 28, 2012 at 4:25 PM, Sedat Dilek <[email protected]> wrote:
> On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek
> <[email protected]> wrote:
>> On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek
>> <[email protected]> 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 <[email protected]>
>>>> 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 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.
On Fri, Apr 27, 2012 at 11:14 AM, Lennert Buytenhek
<[email protected]> 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 -
On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek <[email protected]> wrote:
> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <[email protected]> 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
On Fri, Apr 27, 2012 at 11:40 AM, Lennert Buytenhek
<[email protected]> 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 -
On Fri, Apr 27, 2012 at 12:17 PM, Lennert Buytenhek
<[email protected]> 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 -
On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <[email protected]> wrote:
> [dropped lkml from cc]
>
> On Sat, Apr 28, 2012 at 4:25 PM, Sedat Dilek <[email protected]> wrote:
>> On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek
>> <[email protected]> wrote:
>>> On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek
>>> <[email protected]> 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 <[email protected]>
>>>>> 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
:-).
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.
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.
On Fri, Apr 27, 2012 at 11:53 PM, Sedat Dilek
<[email protected]> wrote:
> On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek
> <[email protected]> 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 <[email protected]>
>>> 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 -
On Sun, Apr 29, 2012 at 7:34 PM, admin <[email protected]> wrote:
> On 04/29/2012 01:26 AM, Sedat Dilek wrote:
>>
>> On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<[email protected]> wrote:
>>>
>>> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<[email protected]>
>>> wrote:
>>>>
>>>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<[email protected]>
>>>> 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 -
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 <[email protected]>
> 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
On Fri, Apr 27, 2012 at 12:57 PM, Sedat Dilek
<[email protected]> wrote:
> On Fri, Apr 27, 2012 at 12:17 PM, Lennert Buytenhek
> <[email protected]> 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 <[email protected]>
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 04/29/2012 07:49 PM, Sedat Dilek wrote:
> On Sun, Apr 29, 2012 at 7:34 PM, admin<[email protected]> wrote:
>> On 04/29/2012 01:26 AM, Sedat Dilek wrote:
>>> On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<[email protected]> wrote:
>>>> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<[email protected]>
>>>> wrote:
>>>>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<[email protected]>
>>>>> 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.
On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie <[email protected]> wrote:
> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek <[email protected]> wrote:
>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie <[email protected]> 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
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.
On Fri, Apr 27, 2012 at 11:58 AM, Lennert Buytenhek
<[email protected]> 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
On Fri, Apr 27, 2012 at 11:46 AM, Lennert Buytenhek
<[email protected]> 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 -
On Fri, Apr 27, 2012 at 8:58 PM, Lennert Buytenhek
<[email protected]> 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 <[email protected]>
>> 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: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.
On 04/29/2012 01:26 AM, Sedat Dilek wrote:
> On Sun, Apr 29, 2012 at 1:11 AM, Jim Cromie<[email protected]> wrote:
>> On Sat, Apr 28, 2012 at 4:49 PM, Sedat Dilek<[email protected]> wrote:
>>> On Sun, Apr 29, 2012 at 12:36 AM, Jim Cromie<[email protected]> 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 Tue, 2012-05-01 at 15:54 +0200, Sedat Dilek wrote:
> On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
> <[email protected]> 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.
--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
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
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.
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.)
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
On Wed, May 2, 2012 at 4:38 AM, Lennert Buytenhek
<[email protected]> 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 -
On 05/01/2012 03:54 PM, Sedat Dilek wrote:
> On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
> <[email protected]> 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
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
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.
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.
On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
<[email protected]> 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
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
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
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?