fwloading USB prism2 devices (Was Re: DLINK DWL-122 on ARM platform not stable, why?)
FeRD <[email protected]> Thu, 28 Sep 2006 07:38:41 -0400
| Newsgroups | gmane.linux.linux-wlan.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1018040357==
Content-Type: multipart/alternative;
boundary="------------080605020604020005080405"
This is a multi-part message in MIME format.
--------------080605020604020005080405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Tiger.Yin wrote:
> The driver version I tried is 0.2.2, 0.2.3 and 0.2.5. Firmware
> information like below:
> ident: nic: id=0x8026 1.0.0
> ident: pri: id=0x15 1.1.3
> ident: sta: id=0x15 1.7.1
> But I couldn't find suitable firmware for my dongle because I found no
> firmware is used for nic id=0x8026. I'm not sure if those firmware
> could used on my dongle?
>
I have both of the devices you mentioned, though my DWL-122 has
succumbed to what I think is a loose internal connection. (Probably from
it falling to the floor one too many times, so that's my fault - it no
longer works under Windows either.) I'm currently writing this mail on a
laptop connected over the MA111 wireless, tho, as I had been meaning to
install and test 0.2.5 anyway. The firmware loading process I remember
from the D-Link is virtually identical to what follows, and I found both
ran well with the latest sta firmware in RAM.
The latest sta firmware that's included with linux-wlan-ng is newer than
what's displayed in your proc output, and seems to ram-load fine on
0x8026 USB devices. With 0.2.5 installed on my Fedora Core 5 box using
the make config / make / make install rules, the ram-load is run via
udev rules on insert of either device, so this process "normally" is
automatic (for those with udev support, at least). The results of the
load show up in dmesg output:
[immediately after device is physically inserted into USB port]
----dmesg----
usb 1-1: new full speed USB device using uhci_hcd and address 4
usb 1-1: configuration #1 chosen from 1 choice
PDA Read from 0x007f0000 in EXTDS space.
PDA Read from 0x007f0000 in EXTDS space.
Writing 4096 bytes to ram @0x7e2ffe
Writing 4096 bytes to ram @0x7e3ffe
Writing 4096 bytes to ram @0x7e4ffe
Writing 4096 bytes to ram @0x7e5ffe
Writing 4096 bytes to ram @0x7e6ffe
Writing 4096 bytes to ram @0x7e7ffe
Writing 4096 bytes to ram @0x7e8ffe
Writing 4096 bytes to ram @0x7e9ffe
Writing 4096 bytes to ram @0x7eaffe
Writing 4096 bytes to ram @0x7ebffe
Writing 4096 bytes to ram @0x7ecffe
Writing 4096 bytes to ram @0x7edffe
Writing 3010 bytes to ram @0x7eeffe
Writing 416 bytes to ram @0x7efc20
Writing 16 bytes to ram @0x7efdd0
Writing 4044 bytes to ram @0x7f0800
Writing 3288 bytes to ram @0x7fe000
hfa384x_usbctlx_complete_sync: CTLX[1] error: state(Request failed)
hfa384x_drvr_start: cmd_initialize() failed, result=-5
prism2sta_ifstate: hfa384x_drvr_start() failed,result=-5
----dmesg----
The last lines there seem to be a quirk in the MA111 (at least the one
I'm using) -- the error either indicates or results in it failing to
"come to life" properly after it's fwloaded and re-enabled by the driver
scripts, which I found can be fixed by disabling and re-enabling it
again by hand. If you decide to update the firmware on the MA111, you
may have to issue additional "wlanctl-ng wlan0 lnxreq_ifstate
ifstate=disable" and then "... ifstate=enable" commands afterwards to
bring it to life. I don't know if there's a way to script the process so
that it succeeds. (But if so please let us know, I don't mind having to
hand-enable so I've never experimented with mods to the automation
scripts. Maybe a short sleep between the prism2dl and the enable would
work.)
Since I'm guessing with an ARM platform and a 2.6.10 kernel version,
udev isn't in the picture (plus the driver install should've set things
up if it was), it's easiest to do the firmware load by hand, at least
initially. I followed along with the /etc/wlan/shared script to make
sure I did the right steps, and loaded my MA111 with the latest STA
1.8.3 the same way it does, since it seems to work well for me when udev
fwloads via /etc/wlan/shared.
/etc/wlan/shared.prism2 contains a function prism2_fwload() which maps
(on lines 82-83) NIC type 0x8026 to the "prism2_ru.hex" firmware file,
and then loads it with the following commands (minus the sudo for root
privileges, of course):
% sudo /sbin/wlanctl-ng wlan0 lnxreq_ifstate ifstate=fwload
message=lnxreq_ifstate
ifstate=fwload
resultcode=success
% sudo /sbin/prism2dl -r /etc/wlan/prism2_ru.hex wlan0
Reading S-record file /etc/wlan/prism2_ru.hex...
NIC ID: 0x8026 v1.0.0
MFI ID: 0x1 v1 1->1
CFI ID: 0x2 v2 1->1
PRI ID: 0x3 v1 1->4
Version: ID 0x1f 1.8.3
Compat: Role 0 Id 0x4 v3 1->15
Compat: Role 0x1 Id 0x1 v1 1->1
Compat: Role 0x1 Id 0x2 v2 1->1
Compat: Role 0x1 Id 0x3 v1 4->4
Seq: 0
Platform: ID 0x800a 1.0.0
Platform: ID 0x800f 1.0.0
Platform: ID 0x8010 1.0.0
Platform: ID 0x8011 1.0.0
Platform: ID 0x801e 1.0.0
Platform: ID 0x801f 1.0.0
Platform: ID 0x8020 1.0.0
Platform: ID 0x8025 1.0.0
Platform: ID 0x8026 1.0.0
Platform: ID 0x8027 1.0.0
prism2dl: warning: Failed to find PDR for plugrec 0x0406.
prism2dl: warning: Failed to find PDR for plugrec 0x0302.
prism2dl: warning: Failed to find PDR for plugrec 0x0414.
prism2dl: finished.
The failed PDR warnings seem to be harmless (like I said, my MA111
functions with 1.8.3 firmware loaded), and /proc/net/p80211/wlan0/nsd
now shows 0.0.0 for all versions, which is "correct" until I re-enable
the device using:
% sudo wlanctl-ng wlan0 lnxreq_ifstate ifstate=disable
message=lnxreq_ifstate
ifstate=disable
resultcode=success
% sudo wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
message=lnxreq_ifstate
ifstate=enable
resultcode=success
(Again, the disable prior to enable may be my paranoia and unnecessary.
I also tend to issue a disable before "ifstate=fwload". The /etc/wlan
scripts see ifstate as a tristate, and move into any state from either
other state... I make no claim to superior knowledge -- in fact I assume
the script developers' understanding is better than mine -- how it
should best be done. I just got into the habit of not going between
fwload and enable directly while fiddling with this MA111, and I can't
say if anything is really affected by the extra steps. YMMV.)
...After this, dmesg reports the proper hardware setup and iwconfig sees
that the interface is ready for config:
----dmesg----
ident: nic h/w: id=0x8026 1.0.0
ident: pri f/w: id=0x15 1.1.3
ident: sta f/w: id=0x1f 1.8.3
MFI:SUP:role=0x00:id=0x01:var=0x01:b/t=1/1
CFI:SUP:role=0x00:id=0x02:var=0x02:b/t=1/1
PRI:SUP:role=0x00:id=0x03:var=0x01:b/t=1/4
STA:SUP:role=0x00:id=0x04:var=0x01:b/t=1/15
PRI-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
STA-CFI:ACT:role=0x01:id=0x02:var=0x02:b/t=1/1
STA-MFI:ACT:role=0x01:id=0x01:var=0x01:b/t=1/1
Prism2 card SN: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
----dmesg----
% iwconfig wlan0
Warning: Driver for device wlan0 has been compiled with version 20
of Wireless Extension, while this program supports up to version 19.
Some things may be broken...
wlan0 IEEE 802.11-DS ESSID:off/any
Mode:Auto Channel:0 Access Point: Not-Associated
Bit Rate:2 Mb/s Tx-Power:18 dBm
Retry min limit:8 RTS thr:off Fragment thr:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Good luck!
-FeRD
> I tried WEP with "sharedkey", but the result is the same. So will you
> please give me some idea on firmware updating? Thanks a lot!
>
>
> On 9/21/06, Solomon Peachy <[email protected]> wrote:
>
>> On Thu, Sep 21, 2006 at 04:59:42PM +0800, Tiger.Yin wrote:
>>
>>> The dlink dwl-122 dongle i used on my ARM(XScale270) platform seemed
>>> not stable, the linux is 2.6.10. USB driver used OHCI mode.
>>>
>> What driver version? What firmware version?
>>
>>
>>> Sometime, this error appeared:
>>> skb_p80211_to_ether: OTHER frame too large (-4 > 1500)
>>>
>> This is interesting.
>>
>>
>>> 2. Opensystem with WEP(64bits)
>>> When i set WEP(64bits) on AP, the dongle also could connect to the AP,
>>> and i could see the dongle's information on AP's trace. But even i set
>>> IP address and route of the dongle, no host could i ping to. Some
>>> error info like this:
>>> ... ...
>>> message=lnxreq_autojoin
>>> ssid='mobot'
>>> authtype=opensystem
>>> resultcode=success
>>> /usr/lib # linkstatus=CONNECTED
>>>
>> Are you sure you don't need 'authtype=sharedkey'?
>>
>> Is the WEP key known to be identical/correct?
>>
>> Finally, despite many heroic efforts from many contributors
>> (Especially Chris Rankin), prism2 USB hardware is inherently
>> flaky. Newer firmawre helps a lot, as do newer driver revs.
>>
>> - Solomon
>> --
>> Solomon Peachy [email protected]
>> AbsoluteValue Systems http://www.linux-wlan.com
>> 721-D North Drive +1 (321) 259-0737 (office)
>> Melbourne, FL 32934 +1 (321) 259-0286 (fax)
>>
>>
>>
>>
> _______________________________________________
> Linux-wlan-user mailing list
> [email protected]
> http://lists.linux-wlan.com/mailman/listinfo/linux-wlan-user
>
>
--------------080605020604020005080405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-05.tampabay.rr.com id k8SBf0Zc028638
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"=
>
<title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Tiger.Yin wrote:
<blockquote
cite=3D"[email protected]"
type=3D"cite">
<pre wrap=3D"">The driver version I tried is 0.2.2, 0.2.3 and 0.2.5. Fi=
rmware
information like below:
ident: nic: id=3D0x8026 1.0.0
ident: pri: id=3D0x15 1.1.3
ident: sta: id=3D0x15 1.7.1
But I couldn't find suitable firmware for my dongle because I found no
firmware is used for nic id=3D0x8026. I'm not sure if those firmware
could used on my dongle?
</pre>
</blockquote>
I have both of the devices you mentioned, though my DWL-122 has
succumbed to what I think is a loose internal connection. (Probably
from it falling to the floor one too many times, so that's my fault -
it no longer works under Windows either.) I'm currently writing this
mail on a laptop connected over the MA111 wireless, tho, as I had been
meaning to install and test 0.2.5 anyway. The firmware loading process
I remember from the D-Link is virtually identical to what follows, and
I found both ran well with the latest sta firmware in RAM.<br>
<br>
The latest sta firmware
that's included with linux-wlan-ng is newer than what's displayed in
your proc output, and seems to ram-load fine on 0x8026 USB devices.
With 0.2.5 installed on my Fedora Core 5 box using the make config /
make / make install rules, the ram-load is run via udev rules on insert
of either device, so this process "normally" is automatic (for those
with udev support, at least). The results of the load show up in dmesg
output:<br>
<br>
[immediately after device is physically inserted into USB port]<br>
----dmesg----<br>
<tt>usb 1-1: new full speed USB device using uhci_hcd and address 4<br>
usb 1-1: configuration #1 chosen from 1 choice<br>
PDA Read from 0x007f0000 in EXTDS space.<br>
PDA Read from 0x007f0000 in EXTDS space.<br>
Writing 4096 bytes to ram @0x7e2ffe<br>
Writing 4096 bytes to ram @0x7e3ffe<br>
Writing 4096 bytes to ram @0x7e4ffe<br>
Writing 4096 bytes to ram @0x7e5ffe<br>
Writing 4096 bytes to ram @0x7e6ffe<br>
Writing 4096 bytes to ram @0x7e7ffe<br>
Writing 4096 bytes to ram @0x7e8ffe<br>
Writing 4096 bytes to ram @0x7e9ffe<br>
Writing 4096 bytes to ram @0x7eaffe<br>
Writing 4096 bytes to ram @0x7ebffe<br>
Writing 4096 bytes to ram @0x7ecffe<br>
Writing 4096 bytes to ram @0x7edffe<br>
Writing 3010 bytes to ram @0x7eeffe<br>
Writing 416 bytes to ram @0x7efc20<br>
Writing 16 bytes to ram @0x7efdd0<br>
Writing 4044 bytes to ram @0x7f0800<br>
Writing 3288 bytes to ram @0x7fe000<br>
hfa384x_usbctlx_complete_sync: CTLX[1] error: state(Request failed)<br>
hfa384x_drvr_start: cmd_initialize() failed, result=3D-5<br>
prism2sta_ifstate: hfa384x_drvr_start() failed,result=3D-5<br>
</tt>----dmesg----<tt><br>
<br>
</tt>The last lines there seem to be a quirk in the MA111 (at least the
one I'm using) -- the error either indicates or results in it failing
to "come to life" properly after it's fwloaded and re-enabled by the
driver scripts, which I found can be fixed by disabling and re-enabling
it again by hand. If you decide to update the firmware on the MA111,
you may have to issue additional "wlanctl-ng wlan0 lnxreq_ifstate
ifstate=3Ddisable" and then "... ifstate=3Denable" commands afterwards to
bring it to life. I don't know if there's a way to script the process
so that it succeeds. (But if so please let us know, I don't mind having
to hand-enable so I've never experimented with mods to the automation
scripts. Maybe a short sleep between the prism2dl and the enable would
work.)<br>
<br>
Since I'm guessing with an ARM platform and a 2.6.10 kernel version,
udev isn't in the picture (plus the driver install should've set things
up if it was), it's easiest to do the firmware load by hand, at least
initially. I followed along with the /etc/wlan/shared script to make
sure I did the right steps, and loaded my MA111 with the latest STA
1.8.3 the same way it does, since it seems to work well for me when
udev fwloads via /etc/wlan/shared.<br>
<br>
/etc/wlan/shared.prism2 contains a function prism2_fwload() which maps
(on lines 82-83) NIC type 0x8026 to the "prism2_ru.hex" firmware file,
and then loads it with the following commands (minus the sudo for root
privileges, of course):<br>
<tt><br>
% sudo /sbin/wlanctl-ng wlan0 lnxreq_ifstate ifstate=3Dfwload<br>
message=3Dlnxreq_ifstate<br>
=C2=A0 ifstate=3Dfwload<br>
=C2=A0 resultcode=3Dsuccess<br>
<br>
% sudo /sbin/prism2dl -r /etc/wlan/prism2_ru.hex wlan0<br>
Reading S-record file /etc/wlan/prism2_ru.hex...<br>
NIC ID: 0x8026 v1.0.0<br>
MFI ID: 0x1 v1 1->1<br>
CFI ID: 0x2 v2 1->1<br>
PRI ID: 0x3 v1 1->4<br>
Version:=C2=A0 ID 0x1f 1.8.3<br>
Compat: Role 0 Id 0x4 v3 1->15<br>
Compat: Role 0x1 Id 0x1 v1 1->1<br>
Compat: Role 0x1 Id 0x2 v2 1->1<br>
Compat: Role 0x1 Id 0x3 v1 4->4<br>
Seq: 0<br>
Platform:=C2=A0 ID 0x800a 1.0.0<br>
Platform:=C2=A0 ID 0x800f 1.0.0<br>
Platform:=C2=A0 ID 0x8010 1.0.0<br>
Platform:=C2=A0 ID 0x8011 1.0.0<br>
Platform:=C2=A0 ID 0x801e 1.0.0<br>
Platform:=C2=A0 ID 0x801f 1.0.0<br>
Platform:=C2=A0 ID 0x8020 1.0.0<br>
Platform:=C2=A0 ID 0x8025 1.0.0<br>
Platform:=C2=A0 ID 0x8026 1.0.0<br>
Platform:=C2=A0 ID 0x8027 1.0.0<br>
prism2dl: warning: Failed to find PDR for plugrec 0x0406.<br>
prism2dl: warning: Failed to find PDR for plugrec 0x0302.<br>
prism2dl: warning: Failed to find PDR for plugrec 0x0414.<br>
prism2dl: finished.</tt><br>
<br>
The failed PDR warnings seem to be harmless (like I said, my MA111
functions with 1.8.3 firmware loaded), and /proc/net/p80211/wlan0/nsd
now shows 0.0.0 for all versions, which is "correct" until I re-enable
the device using:<br>
<tt><br>
% sudo wlanctl-ng wlan0 lnxreq_ifstate ifstate=3Ddisable<br>
message=3Dlnxreq_ifstate<br>
=C2=A0 ifstate=3Ddisable<br>
=C2=A0 resultcode=3Dsuccess<br>
% sudo wlanctl-ng wlan0 lnxreq_ifstate ifstate=3Denable<br>
message=3Dlnxreq_ifstate<br>
=C2=A0 ifstate=3Denable<br>
=C2=A0 resultcode=3Dsuccess<br>
<br>
</tt>(Again, the disable prior to enable may be my paranoia and
unnecessary. I also tend to issue a disable before "ifstate=3Dfwload".
The /etc/wlan scripts see ifstate as a tristate, and move into any
state from either other state... I make no claim to superior knowledge
-- in fact I assume the script developers' understanding is better than
mine -- how it should best be done. I just got into the habit of not
going between fwload and enable directly while fiddling with this
MA111, and I can't say if anything is really affected by the extra
steps. YMMV.)<br>
<br>
...After this, dmesg reports the proper hardware setup and iwconfig
sees that the interface is ready for config:<tt><br>
<br>
</tt>----dmesg----<tt><br>
ident: nic h/w: id=3D0x8026 1.0.0<br>
ident: pri f/w: id=3D0x15 1.1.3<br>
ident: sta f/w: id=3D0x1f 1.8.3<br>
MFI:SUP:role=3D0x00:id=3D0x01:var=3D0x01:b/t=3D1/1<br>
CFI:SUP:role=3D0x00:id=3D0x02:var=3D0x02:b/t=3D1/1<br>
PRI:SUP:role=3D0x00:id=3D0x03:var=3D0x01:b/t=3D1/4<br>
STA:SUP:role=3D0x00:id=3D0x04:var=3D0x01:b/t=3D1/15<br>
PRI-CFI:ACT:role=3D0x01:id=3D0x02:var=3D0x02:b/t=3D1/1<br>
STA-CFI:ACT:role=3D0x01:id=3D0x02:var=3D0x02:b/t=3D1/1<br>
STA-MFI:ACT:role=3D0x01:id=3D0x01:var=3D0x01:b/t=3D1/1<br>
Prism2 card SN: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00<br>
</tt>----dmesg----<tt><br>
<br>
</tt><tt>% iwconfig wlan0<br>
Warning: Driver for device wlan0 has been compiled with version 20<br>
of Wireless Extension, while this program supports up to version 19.<br>
Some things may be broken...<br>
<br>
wlan0=C2=A0=C2=A0=C2=A0=C2=A0 IEEE 802.11-DS=C2=A0 ESSID:off/any<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mode:Auto=C2=A0 Ch=
annel:0=C2=A0 Access Point: Not-Associated<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bit Rate:2 Mb/s=C2=
=A0=C2=A0 Tx-Power:18 dBm<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Retry min limit:8=C2=
=A0=C2=A0 RTS thr:off=C2=A0=C2=A0 Fragment thr:off<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Link Quality:0=C2=A0=
Signal level:0=C2=A0 Noise level:0<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rx invalid nwid:0=C2=
=A0 Rx invalid crypt:0=C2=A0 Rx invalid frag:0<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tx excessive retri=
es:0=C2=A0 Invalid misc:0=C2=A0=C2=A0 Missed beacon:0<br>
</tt><br>
<br>
Good luck!<br>
<br>
=C2=A0 -FeRD<br>
<blockquote
cite=3D"[email protected]"
type=3D"cite">
<pre wrap=3D"">I tried WEP with "sharedkey", but the result is the same=
. So will you
please give me some idea on firmware updating? Thanks a lot!
On 9/21/06, Solomon Peachy <a class=3D"moz-txt-link-rfc2396E" href=3D"mai=
lto:[email protected]"><[email protected]></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On Thu, Sep 21, 2006 at 04:59:42PM +0800, Tiger.Yin wr=
ote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">The dlink dwl-122 dongle i used on my ARM(XScale270)=
platform seemed
not stable, the linux is 2.6.10. USB driver used OHCI mode.
</pre>
</blockquote>
<pre wrap=3D"">What driver version? What firmware version?
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Sometime, this error appeared:
skb_p80211_to_ether: OTHER frame too large (-4 > 1500)
</pre>
</blockquote>
<pre wrap=3D"">This is interesting.
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">2. Opensystem with WEP(64bits)
When i set WEP(64bits) on AP, the dongle also could connect to the AP,
and i could see the dongle's information on AP's trace. But even i set
IP address and route of the dongle, no host could i ping to. Some
error info like this:
... ...
message=3Dlnxreq_autojoin
ssid=3D'mobot'
authtype=3Dopensystem
resultcode=3Dsuccess
/usr/lib # linkstatus=3DCONNECTED
</pre>
</blockquote>
<pre wrap=3D"">Are you sure you don't need 'authtype=3Dsharedkey'?
Is the WEP key known to be identical/correct?
Finally, despite many heroic efforts from many contributors
(Especially Chris Rankin), prism2 USB hardware is inherently
flaky. Newer firmawre helps a lot, as do newer driver revs.
- Solomon
--
Solomon Peachy <a class=3D"moz-txt-link-abbreviate=
d" href=3D"mailto:[email protected]">[email protected]</a>
AbsoluteValue Systems <a class=3D"moz-txt-link-freetext" =
href=3D"http://www.linux-wlan.com">http://www.linux-wlan.com</a>
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
</pre>
</blockquote>
<pre wrap=3D""><!---->_______________________________________________
Linux-wlan-user mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Linux-wlan-user@list=
s.linux-wlan.com">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://lists.linux-wlan.com/ma=
ilman/listinfo/linux-wlan-user">http://lists.linux-wlan.com/mailman/listi=
nfo/linux-wlan-user</a>
</pre>
</blockquote>
</body>
</html>
--------------080605020604020005080405--
--===============1018040357==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
_______________________________________________
Linux-wlan-user mailing list
[email protected]
http://lists.linux-wlan.com/mailman/listinfo/linux-wlan-user
--===============1018040357==--