Here is our latest "vendor driver" for the old zd1211. We much prefer
the in-kernel zd1211rw driver but I've heard a few users with issues
with some devices. Perhaps this might help a few developers help port
over any changes. I myself have not looked at this yet.
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
Luis
On Tue, Apr 7, 2009 at 6:34 AM, Luis R. Rodriguez
<[email protected]> wrote:
> Not sure, I wanted to get this out to help those who are interested in
> porting changes over (if any) to zd1211rw. If you find nothing useful
> from it please simply disregard it.
It is vaguely relevant in that (1) there are new and old features
which are not in the rw driver yet - e.g. the AP mode, and
3.0 introduces newly antenna diversity, (2) to port changes - either
new-hardware related, or bug-fixes/improvements, they need to be
proven to work-better ... e.g. blindly copying could just copy
mistakes/regressions...
On Tue, Apr 07, 2009 at 12:49:30AM -0700, Hin-Tak Leung wrote:
> On Tue, Apr 7, 2009 at 6:34 AM, Luis R. Rodriguez
> <[email protected]> wrote:
>
> > Not sure, I wanted to get this out to help those who are interested in
> > porting changes over (if any) to zd1211rw. If you find nothing useful
> > from it please simply disregard it.
>
> It is vaguely relevant in that (1) there are new and old features
> which are not in the rw driver yet - e.g. the AP mode, and
> 3.0 introduces newly antenna diversity, (2) to port changes - either
> new-hardware related, or bug-fixes/improvements, they need to be
> proven to work-better ... e.g. blindly copying could just copy
> mistakes/regressions...
Right, that is the idea.
Luis
On Sun, Apr 5, 2009 at 3:44 AM, Hin-Tak Leung <[email protected]> wrote:
> On Sat, Apr 4, 2009 at 5:15 AM, Luis R. Rodriguez
> <[email protected]> wrote:
>> Here is our latest "vendor driver" for the old zd1211. We much prefer
>> the in-kernel zd1211rw driver but I've heard a few users with issues
>> with some devices. Perhaps this might help a few developers help port
>> over any changes. I myself have not looked at this yet.
>>
>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
>
> Somebody reported some problems with the 3.0.0.56 driver in the zd1211
> list a few days ago, and I was wondering where he got it from :-) ...
> anyway, if you see an obvious answer with the regression noted in this
> mail, it might worth either correcting it or something.
>
> http://sourceforge.net/mailarchive/message.php?msg_name=8c675e9b0904010320j18f49dccub37b65b81d254cb4%40mail.gmail.com
>
> I'll certainly have a look at the vendor driver sometime soon - I use
> the AP mode.
>
I have given it a try and even just adding the minimal bits
(enough to cope with David S. Miller's "wext: Emit event stream
entries correctly when compat."
change some 9 months ago) to port beyond 2.6.27(?), the result is a hard lock up
in AP mode of the machine if either 'iwpriv <dev> card_reset' is
issued, or even having a client trying to associate.
Also the message above is a hard crash problem, and seem to relate to
this paragraph
in LinuxUSB_AR2524-3.0.0.56/docs/PortingNotes.txt
-------------------
1. RX_OFFSET = 3 result in a unaligned rx buffer for usb dma.
This is used to ensure the WLAN/ETH/IP Header is 2 bytes aligned.
But it RX_OFFSET=0, These headers are not aligned , we neeed to
do a copy
------------------
May I ask what's the context and origin of the file
"PortingNotes.txt"? it seems to be collection of
some doubts and/or in-coherent thoughts about some changes made, etc.
On Mon, Apr 6, 2009 at 9:20 PM, Hin-Tak Leung <[email protected]> =
wrote:
> On Sun, Apr 5, 2009 at 3:44 AM, Hin-Tak Leung <[email protected]=
> wrote:
>> On Sat, Apr 4, 2009 at 5:15 AM, Luis R. Rodriguez
>> <[email protected]> wrote:
>>> Here is our latest "vendor driver" for the old zd1211. We much pref=
er
>>> the in-kernel zd1211rw driver but I've heard a few users with issue=
s
>>> with some devices. Perhaps this might help a few developers help po=
rt
>>> over any changes. I myself have not looked at this yet.
>>>
>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUS=
B_AR2524-3.0.0.56.tgz
>>
>> Somebody reported some problems with the 3.0.0.56 driver in the zd12=
11
>> list a few days ago, and I was wondering where he got it from :-) ..=
=2E
>> anyway, if you see an obvious answer with the regression noted in th=
is
>> mail, it might worth either correcting it or something.
>>
>> http://sourceforge.net/mailarchive/message.php?msg_name=3D8c675e9b09=
04010320j18f49dccub37b65b81d254cb4%40mail.gmail.com
>>
>> I'll certainly have a look at the vendor driver sometime soon - I us=
e
>> the AP mode.
>>
>
> I have given it a try and even just adding the minimal bits
> (enough to cope with David S. Miller's "wext: Emit event stream
> entries correctly when compat."
> change some 9 months ago) to port beyond 2.6.27(?), the result is a h=
ard lock up
> in AP mode of the machine if either 'iwpriv <dev> card_reset' is
> issued, or even having a client trying to associate.
>
> Also the message above is a hard crash problem, and seem to relate to
> this paragraph
> in LinuxUSB_AR2524-3.0.0.56/docs/PortingNotes.txt
>
> -------------------
> 1. RX_OFFSET =3D 3 result in a unaligned rx buffer for usb dma.
> =C2=A0 This is used to ensure the WLAN/ETH/IP Header is 2 bytes align=
ed.
> =C2=A0 But it RX_OFFSET=3D0, These headers are not aligned , we neeed=
to
> =C2=A0 do a copy
> ------------------
>
> May I ask what's the context and origin of the file
> "PortingNotes.txt"?
Not sure, I wanted to get this out to help those who are interested in
porting changes over (if any) to zd1211rw. If you find nothing useful
from it please simply disregard it.
Luis
On Sat, Apr 4, 2009 at 5:15 AM, Luis R. Rodriguez
<[email protected]> wrote:
> Here is our latest "vendor driver" for the old zd1211. We much prefer
> the in-kernel zd1211rw driver but I've heard a few users with issues
> with some devices. Perhaps this might help a few developers help port
> over any changes. I myself have not looked at this yet.
>
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
Somebody reported some problems with the 3.0.0.56 driver in the zd1211
list a few days ago, and I was wondering where he got it from :-) ...
anyway, if you see an obvious answer with the regression noted in this
mail, it might worth either correcting it or something.
http://sourceforge.net/mailarchive/message.php?msg_name=8c675e9b0904010320j18f49dccub37b65b81d254cb4%40mail.gmail.com
I'll certainly have a look at the vendor driver sometime soon - I use
the AP mode.
On Mon, May 25, 2009 at 8:08 AM, Hin-Tak Leung <[email protected]> wrote:
For 32-bit, it seems to work alright, except for one oop
> in AP mode when a client connects so far (out of a few connects).
I think I found the reason of oops - it is a regression newly
introduced in 3.0.0.56, actually...
Diff below, which probably has some white space problems from
cut-and-paste, but should be obvious...
------------------------------------------------------
>From 7a12176808ba628b80aeadc44bc27a042735387a Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung <[email protected]>
Date: Mon, 25 May 2009 11:43:32 +0100
Subject: [PATCH] fix NULL pointer deference in newly-introduced in 3.0.0.56
Tchal_WaitChalRsp() AsocTimeOut() can be called with arg=NULL
from zd_SendTChalMsg() and zd_SendTAsocMsg() respectively. New to 3.0.0.56
is code to clear frame description, which does not check for NULL input.
Tchal_WaitChalRsp() oops is observed in AP mode when a client tries to connect.
---
ar2524drv/src/zdasocsvc.c | 3 +++
ar2524drv/src/zdauthrsp.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/ar2524drv/src/zdasocsvc.c b/ar2524drv/src/zdasocsvc.c
index 90bba79..780a950 100644
--- a/ar2524drv/src/zdasocsvc.c
+++ b/ar2524drv/src/zdasocsvc.c
@@ -659,6 +659,8 @@ BOOLEAN AsocTimeOut(Signal_t *signal)
}
mRequestFlag |= CONNECT_TOUT_SET;
+ if(signal != NULL)
+ {
if(signal->frmInfo.frmDesc != NULL)
{
freeFdesc(signal->frmInfo.frmDesc);
@@ -666,6 +668,7 @@ BOOLEAN AsocTimeOut(Signal_t *signal)
}
pdot11Obj->ReleaseBuffer(signal->buf);
freeSignal(signal);
+ }
return FALSE;
}
diff --git a/ar2524drv/src/zdauthrsp.c b/ar2524drv/src/zdauthrsp.c
index 081b9bb..27c2bb9 100644
--- a/ar2524drv/src/zdauthrsp.c
+++ b/ar2524drv/src/zdauthrsp.c
@@ -198,6 +198,8 @@ BOOLEAN Tchal_WaitChalRsp(Signal_t *signal)
UpdateStaStatus(&Sta, STATION_STATE_NOT_AUTH, vapId);
AuthRspState = STE_AUTH_RSP_IDLE;
}
+ if(signal != NULL)
+ {
if(signal->frmInfo.frmDesc != NULL)
{
freeFdesc(signal->frmInfo.frmDesc);
@@ -205,6 +207,7 @@ BOOLEAN Tchal_WaitChalRsp(Signal_t *signal)
}
pdot11Obj->ReleaseBuffer(signal->buf);
freeSignal(signal);
+ }
return FALSE;
}
--
1.6.0.6
---------------------------------------------------------
On Tue, May 26, 2009 at 6:30 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Mon, May 25, 2009 at 12:08:05AM -0700, Hin-Tak Leung wrote:
>> This is just a head-up that I have a series of diffs to port the
>> vendor driver forward to current kernels, if anybody wants to have a
>> look, for side-by-side scavenging to the rw driver. (I probably will
>> post them to the sourceforge zd1211-dev list after a little look at
>> that oops)
>
> That's great to hear, feel free to post them to linux-wireless as
> RFC/RFTs.
>
>> BTW, anybody has any idea what else is needed for the rw driver to
>> support AP mode?
>
> Not me.
AFAIK the developers will never accept any AP mode for zd1211 devices,
as it has no multicast buffering feature in the hardware. (The vendor
driver, as well as the Windows driver implements AP mode with a spec
violation to get around the lack of a multicast buffer.)
CCing Johannes, he was the one who initially said that.
>
> ?Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Tue, 2009-05-26 at 21:27 +0200, Gábor Stefanik wrote:
> AFAIK the developers will never accept any AP mode for zd1211 devices,
> as it has no multicast buffering feature in the hardware. (The vendor
> driver, as well as the Windows driver implements AP mode with a spec
> violation to get around the lack of a multicast buffer.)
> CCing Johannes, he was the one who initially said that.
Pretty much exactly it.
johannes
On Tue, May 26, 2009 at 05:19:49PM -0700, Hin-Tak Leung wrote:
> 2009/5/26 Johannes Berg <[email protected]>:
> > On Tue, 2009-05-26 at 21:27 +0200, G?bor Stefanik wrote:
> >
> >> AFAIK the developers will never accept any AP mode for zd1211 devices,
> >> as it has no multicast buffering feature in the hardware. (The vendor
> >> driver, as well as the Windows driver implements AP mode with a spec
> >> violation to get around the lack of a multicast buffer.)
> >> CCing Johannes, he was the one who initially said that.
> >
> > Pretty much exactly it.
>
> I think what I meant is, what else is needed for AP mode from mac80211
> ? Or is it 'never'?
Not going to happen.
Luis
On Tue, Apr 7, 2009 at 5:08 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Tue, Apr 07, 2009 at 12:49:30AM -0700, Hin-Tak Leung wrote:
>> On Tue, Apr 7, 2009 at 6:34 AM, Luis R. Rodriguez
>> <[email protected]> wrote:
>>
>> > Not sure, I wanted to get this out to help those who are interested in
>> > porting changes over (if any) to zd1211rw. If you find nothing useful
>> > from it please simply disregard it.
>>
>> It is vaguely relevant in that (1) there are new and old features
>> which are not in the rw driver yet - e.g. the AP mode, and
>> 3.0 introduces newly antenna diversity, (2) to port changes - either
>> new-hardware related, or bug-fixes/improvements, they need to be
>> proven to work-better ... e.g. blindly copying could just copy
>> mistakes/regressions...
>
> Right, that is the idea.
It has been 6 weeks - I re-visited the code and found a mistake of
mine, and managed to get it to compile against
2.6.29.3-159.fc11.x86_64 and 2.6.28.8 vanila 32-bit . It definitely
does *not* work correctly on x86_64 linux - I get a rather wierd
problem where register-read of the last 16-bit of the mac address from
firmware _apparently_ fails, but it is fed to the next register-read
and the result of the next register-read is received by the
next-next-read, etc. (i.e. the result of a read is received by the
next read). For 32-bit, it seems to work alright, except for one oop
in AP mode when a client connects so far (out of a few connects).
This is just a head-up that I have a series of diffs to port the
vendor driver forward to current kernels, if anybody wants to have a
look, for side-by-side scavenging to the rw driver. (I probably will
post them to the sourceforge zd1211-dev list after a little look at
that oops)
BTW, anybody has any idea what else is needed for the rw driver to
support AP mode?
2009/5/26 Johannes Berg <[email protected]>:
> On Tue, 2009-05-26 at 21:27 +0200, G?bor Stefanik wrote:
>
>> AFAIK the developers will never accept any AP mode for zd1211 devices,
>> as it has no multicast buffering feature in the hardware. (The vendor
>> driver, as well as the Windows driver implements AP mode with a spec
>> violation to get around the lack of a multicast buffer.)
>> CCing Johannes, he was the one who initially said that.
>
> Pretty much exactly it.
I think what I meant is, what else is needed for AP mode from mac80211
? Or is it 'never'?
Hin-Tak
On Tue, May 26, 2009 at 5:30 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Mon, May 25, 2009 at 12:08:05AM -0700, Hin-Tak Leung wrote:
>> This is just a head-up that I have a series of diffs to port the
>> vendor driver forward to current kernels, if anybody wants to have a
>> look, for side-by-side scavenging to the rw driver. (I probably will
>> post them to the sourceforge zd1211-dev list after a little look at
>> that oops)
>
> That's great to hear, feel free to post them to linux-wireless as
> RFC/RFTs.
The patches are somewhat big so I have split them the git way and
uploaded to the sourceforge user area. Here is some extra description
beyond what the header says. I will probably upload a version of this
summary write-up when/if I get some feedback. The fix for the oops I
mentioned earlier is patch 0007. Caveate: The driver is known *not* to
work on 64-bit platform.
----------------------------------------------------------------
http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
0001-wext-Emit-event-stream-entries-correctly-when-compa.patch
0002-Convert-direct-reference-of-netdev-priv-to-netdev_p.patch
0003-adding-Philip-USB-stick-vid-pid.patch
0004-forward-port-of-an-old-patch-from-the-internet.patch
0005-add-delay-for-firmware-loading-bug.patch
0006-fix-compile-error-when-HMAC_DEBUG-is-enbled.patch
0007-fix-NULL-pointer-deference-in-newly-introduced-in-3.patch
0008-removing-two-tedious-messages-which-prints-once-ever.patch
0009-commenting-out-two-informative-messages.patch
0001 - required from about 2.6.27 onwards
0002 - required from about 2.6.29 onwards
0003 - vid/pid of my hardware
0004 - this probably should be splitted up into a few patches; some of
it is just error-checking/recovery, the 'restart URB on timeout' code
path was needed in 2.0 and often triggered when the 2.0 driver was
under stress but seems to be never triggered in 3.0, so it probably
just covers an old bug elsewhere which has since been fixed. I do not
understand the purpose of the interrupt<->bulk transfer change; if
somebody else does, please tell me.
0005 - splitted out from 0004
0006 - it is a bug which is only encountered when HMAC_DEBUG is
enabled (which is not the default) so this patch is not important for
normal usage
0007 - important bug fix for a new bug in 3.0
0008, 0009 - I find these dmesg messages too frequent and not
imformative (0008 is regular every two minutes, 0009 is whenever AP
mode is under stress, but seems to be harmless). 0009 probably should
*not* be applied for debugging AP problems.
Patch set against the older driver - they are not very tidy, but
mostly for historical purposes:
http://htl10.users.sourceforge.net/ZD1211LnxDrv_2_22_0_0_2009May_pathset/
0001-first-working-version-without-usb-speed-override.patch
0002-remove-usb-speed-override.patch
0003-compiler-warnings.patch
0004-compiler-warnings.patch
0005-compiler-warnings.patch
0006-more-compiler-warnings.patch
0007-commit-ccc580571cf0799d0460a085a7632b77753f083e.patch
0008-Convert-direct-reference-of-netdev-priv-to-netdev_p.patch
0009-more-clean.patch
0010-removing-some-debug-messages.patch
0011-more-compiler-warnings.patch
0012-more-compiler-warnings.patch
0013-Possible-fix-for-NULL-pointer-dereference-in-getElem.patch
0001 is tidied up and split into 0003/0004/0005 in 3.0
0002 is something I decide - the driver shouldn't speed based on USB
host speed, but just throttle back on rate. (but seems to trigger the
'restart URB on timeout' code path quite often).
0007 is similiar to 3.0's 0001 ; 0008 is similiar to 3.0's 0002;
0013 is discovered via looking at the 2.0/3.0 difference. It seems to
be a bug fix in 3.0, which is therefore backported.
----------------------------------
On Mon, May 25, 2009 at 12:08:05AM -0700, Hin-Tak Leung wrote:
> This is just a head-up that I have a series of diffs to port the
> vendor driver forward to current kernels, if anybody wants to have a
> look, for side-by-side scavenging to the rw driver. (I probably will
> post them to the sourceforge zd1211-dev list after a little look at
> that oops)
That's great to hear, feel free to post them to linux-wireless as
RFC/RFTs.
> BTW, anybody has any idea what else is needed for the rw driver to
> support AP mode?
Not me.
Luis