This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
I removed all the parts(e.g.: Hostapd Support) which are not relevant for
wpa_supplicant (client/managed mode).
now, you can connect to your WLAN with:
wpa_supplicant -Dwext -c{WPA_CONF} -i{WPA_ETH} -dd
This code is just for review & testers...
so only a pre-signed-off for now. ;)
Pre- Signed-off-by: Christian Lamparter [off-list ref]
---
diffstat:
isl_ioctl.c | 1560
+++++++++++++++++++++----------------------------------
isl_ioctl.h | 6
isl_oid.h | 99 ++-
islpci_dev.c | 1
islpci_hotplug.c | 11
islpci_mgt.h | 4
oid_mgt.c | 48 +
oid_mgt.h | 2
8 files changed, 724 insertions(+), 1007 deletions(-)
On Tue, 3 Oct 2006 14:57:33 +0200, chunkeey@web.de wrote:
This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
I removed all the parts(e.g.: Hostapd Support) which are not relevant for
wpa_supplicant (client/managed mode).
Are you proposing a patch that removes AP support from the driver or did
I understand it wrong?
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
From: Dan Williams <hidden> Date: 2006-10-04 11:38:14
On Wed, 2006-10-04 at 12:38 +0200, Jiri Benc wrote:
On Tue, 3 Oct 2006 14:57:33 +0200, chunkeey@web.de wrote:
quoted
This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
I removed all the parts(e.g.: Hostapd Support) which are not relevant for
wpa_supplicant (client/managed mode).
Are you proposing a patch that removes AP support from the driver or did
I understand it wrong?
I believe it adds the support back in, just using standard WE ioctls
like ENCODEEXT and AUTH rather than the custom HostAP ones... which
brings up the question whether the hostapd driver for wext (is there
such a thing?) works well enough.
Dan
On Wed, 4 Oct 2006 13:40 +0200 dcbw@redhat.com wrote:
On Wed, 2006-10-04 at 12:38 +0200, Jiri Benc wrote:
quoted
On Tue, 3 Oct 2006 14:57:33 +0200, chunkeey@web.de wrote:
quoted
This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
I removed all the parts(e.g.: Hostapd Support) which are not relevant
for wpa_supplicant (client/managed mode).
Are you proposing a patch that removes AP support from the driver or did
I understand it wrong?
I believe it adds the support back in, just using standard WE ioctls
like ENCODEEXT and AUTH rather than the custom HostAP ones... which
brings up the question whether the hostapd driver for wext (is there
such a thing?) works well enough.
Dan
the AP code never worked. And the hostapd-ioctl interface was designed
for prism2/2.5/3 cards, but not for "fullmac" prism54.
Because the "fullmac" prism54 card does everything(mac-, key- and
station-management) in the firmware and the hostapd_param struct
does neither support the necessary mlme requests/responses (Authentication &
Association frames) nor a param to handle the EAP filter for the stations.
(I wrote a "patch" HostAPD support, but with it's own
firmwareap_param struct and some other hacky things, but it works well.
I can post a diff too, but "be" warned! ;) )
(BTW, hostapd's backend for prism54 uses a "proprietary" interface -
PIMFOR -, which never made it into the kernel.)
Chr.
On Wed, Oct 04, 2006 at 04:12:26PM +0200, chunkeey@web.de wrote:
the AP code never worked. And the hostapd-ioctl interface was designed
for prism2/2.5/3 cards, but not for "fullmac" prism54.
What do you mean by never working? I have seen fullmac Prism54
completing WPA authentication with hostapd.. This was using the
driver_prism54.c in hostapd, not the Host AP driver interface.
(BTW, hostapd's backend for prism54 uses a "proprietary" interface -
PIMFOR -, which never made it into the kernel.)
But it worked in the external driver. So yes, saying that the version in
kernel tree never worked in AP mode would probably be valid.
And as far as the WEXT interface in hostapd is concerned, no, there is
no such thing yet.
--
Jouni Malinen PGP id EFC895FA
On Wed, Oct 04, 2006 at 04:12:26PM +0200, chunkeey@web.de wrote:
quoted
the AP code never worked. And the hostapd-ioctl interface was designed
for prism2/2.5/3 cards, but not for "fullmac" prism54.
What do you mean by never working? I have seen fullmac Prism54
completing WPA authentication with hostapd.. This was using the
driver_prism54.c in hostapd, not the Host AP driver interface.
quoted
(BTW, hostapd's backend for prism54 uses a "proprietary" interface -
PIMFOR -, which never made it into the kernel.)
But it worked in the external driver. So yes, saying that the version in
kernel tree never worked in AP mode would probably be valid.
ok, sorry my fault, I should have put it this was:
it was never woking for ME, linmax, roland warsow, ...
and I tried alot of things. (patches, how-tos, ask the maintainer, etc. )
But i only saw "Oops" or "mgt: queue full" ...
the PIMFOR-Interface is a direct "tunnel" to the hardware.
And guess what? it's very "crashy" .. (e.g "set/get the generic elements" does
a very good job. ;) )
And as far as the WEXT interface in hostapd is concerned, no, there is
no such thing yet.
that's correct.
WEXT is not going anywhere anymore, but maybe cfg80211?
Chr
From: John W. Linville <hidden> Date: 2006-10-17 21:33:10
On Tue, Oct 03, 2006 at 02:57:33PM +0200, chunkeey@web.de wrote:
This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
I removed all the parts(e.g.: Hostapd Support) which are not relevant for
wpa_supplicant (client/managed mode).
now, you can connect to your WLAN with:
wpa_supplicant -Dwext -c{WPA_CONF} -i{WPA_ETH} -dd
This code is just for review & testers...
so only a pre-signed-off for now. ;)
Pre- Signed-off-by: Christian Lamparter [off-list ref]
I apologize for the late response.
I was going to include this patch in my pending branch, but I can't
get it to apply. The rejects are a bit big for me to hand-resolve.
Please review the patch posting procedures documented here:
http://linux.yyz.us/patch-format.html
Feel free to resubmit the patch, based of the current wireless-2.6 tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
you can connect to your WLAN with:
wpa_supplicant -Dwext -c{WPA_CONF} -i{WPA_ETH}
Signed-off-by: Christian Lamparter <redacted>
off-topic:
Can someone please check my changelog for spelling "errors"?
From: Luis R. Rodriguez <hidden> Date: 2006-10-30 20:17:55
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.
Luis
From: Dan Williams <hidden> Date: 2006-10-30 20:32:11
On Sun, 2006-10-29 at 14:35 +0200, chunkeey@web.de wrote:
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
you can connect to your WLAN with:
wpa_supplicant -Dwext -c{WPA_CONF} -i{WPA_ETH}
Signed-off-by: Christian Lamparter <redacted>
off-topic:
Can someone please check my changelog for spelling "errors"?
What git tree or kernel source version is this patch based off? It
doesn't appear to be based off 2.6.18, 2.6.19-rc3, or wireless-dev. I
wanted to test it out with a WPA access point and see if there are
regressions...
Thanks,
Dan
From: Dan Williams <hidden> Date: 2006-10-31 16:04:33
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
Dan
Luis
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
quoted
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac prism54
cards. I removed all parts which are not relevant for wpa_supplicant
(managed mode).
This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
Dan
Dan, the patch was made for this git-tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
BTW, here's a little update:
removes (all) duplicated constants and some "home-grown" definitions
Oh, is there a "#definition" for 40Bit-WEP keys? I only found one for 104Bit
and one for SCM.
Christian
From: Dan Williams <hidden> Date: 2006-11-03 14:48:02
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
quoted
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
So my prism54 fullmac card appears to be broken, since it refuses to
associate with anything at all, even unencrypted access points. It
doesn't throw any errors at all, and it appears to be operating
correctly other than not associating.
Is there any way to get more information out of the firmware about what
it's doing?
Dan
Dan
quoted
Luis
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Luis R. Rodriguez <hidden> Date: 2006-11-03 16:06:54
On 11/3/06, Dan Williams [off-list ref] wrote:
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
quoted
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
quoted
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
So my prism54 fullmac card appears to be broken, since it refuses to
associate with anything at all, even unencrypted access points. It
doesn't throw any errors at all, and it appears to be operating
correctly other than not associating.
chunkeey, I figured your patch was well tested as you had it sitting
there for a while I gotta find a fullmac working card (most of them
broke while debugging) to debug.
Is there any way to get more information out of the firmware about what
it's doing?
The driver supports prism54_get_oid and prism54_set_u32. The list of
OIDs available are on isl_oid.h on oid_num_t enum. Just an FYI you if
you need to access the *EX OIDs you just need to be in extended mode.
Also for WPA you need to be in extended mode. To say the least last
the driver was pretty unstable in extended mode last I used worked on
it. Dan do you get any funky mgt timeouts on your ring buffer?
Anything useful there?
Luis
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
quoted
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
quoted
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac
prism54 cards. I removed all parts which are not relevant for
wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the
patch is breaking compatiblity with 2.4 but then again I'm tired of
having to keep this compat work up too and soon, after d80211 full
force push it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
So my prism54 fullmac card appears to be broken, since it refuses to
associate with anything at all, even unencrypted access points. It
doesn't throw any errors at all, and it appears to be operating
correctly other than not associating.
chunkeey, I figured your patch was well tested as you had it sitting
there for a while I gotta find a fullmac working card (most of them
broke while debugging) to debug.
well, it was already tested by:
Maxi, Dan S., Gabriel, C and "me".
"The best configuration is: WPA2 with TKIP!"
quoted
Is there any way to get more information out of the firmware about what
it's doing?
The driver supports prism54_get_oid and prism54_set_u32. The list of
OIDs available are on isl_oid.h on oid_num_t enum. Just an FYI you if
you need to access the *EX OIDs you just need to be in extended mode.
Also for WPA you need to be in extended mode. To say the least last
the driver was pretty unstable in extended mode last I used worked on
it. Dan do you get any funky mgt timeouts on your ring buffer?
Anything useful there?
Luis
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
OT: I don't know if my last mail made it to the mailing-list. I haven't
seen it on the inet archieves, so here's a "resend".
Christian
From: Luis R. Rodriguez <hidden> Date: 2006-11-03 18:41:47
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
Am Freitag, 3. November 2006 17:06 schrieben Sie:
quoted
On 11/3/06, Dan Williams [off-list ref] wrote:
quoted
On Tue, 2006-10-31 at 11:05 -0500, Dan Williams wrote:
quoted
On Mon, 2006-10-30 at 15:17 -0500, Luis R. Rodriguez wrote:
quoted
On 10/29/06, chunkeey@web.de [off-list ref] wrote:
quoted
This patch completes WPA/RSN with TKIP support for all fullmac
prism54 cards. I removed all parts which are not relevant for
wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the
patch is breaking compatiblity with 2.4 but then again I'm tired of
having to keep this compat work up too and soon, after d80211 full
force push it may not be possible. So I ACK it.
I'd like to test it a bit first with my fullmac card before it gets
committed/added... But it's great to get some movement on this
card/driver!
So my prism54 fullmac card appears to be broken, since it refuses to
associate with anything at all, even unencrypted access points. It
doesn't throw any errors at all, and it appears to be operating
correctly other than not associating.
chunkeey, I figured your patch was well tested as you had it sitting
there for a while I gotta find a fullmac working card (most of them
broke while debugging) to debug.
well, it was already tested by:
Maxi, Dan S., Gabriel, C and "me".
"The best configuration is: WPA2 with TKIP!"
quoted
quoted
Is there any way to get more information out of the firmware about what
it's doing?
The driver supports prism54_get_oid and prism54_set_u32. The list of
OIDs available are on isl_oid.h on oid_num_t enum. Just an FYI you if
you need to access the *EX OIDs you just need to be in extended mode.
Also for WPA you need to be in extended mode. To say the least last
the driver was pretty unstable in extended mode last I used worked on
it. Dan do you get any funky mgt timeouts on your ring buffer?
Anything useful there?
Luis
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Luis
From: John W. Linville <hidden> Date: 2006-11-08 00:54:17
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
--
John W. Linville
linville@tuxdriver.com
Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
quoted
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
no replies.
Seems like it works for just fine for everybody. ;)
Christian
From: Luis R. Rodriguez <hidden> Date: 2006-11-09 23:16:08
On 11/9/06, chunkeey@web.de [off-list ref] wrote:
Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
quoted
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
quoted
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
no replies.
Seems like it works for just fine for everybody. ;)
I found a card, I just need time to test it. Dan didn't you say you
ran into issues with the patch on your card?
Luis
From: Luis R. Rodriguez <hidden> Date: 2006-11-09 23:16:29
On 11/9/06, Luis R. Rodriguez [off-list ref] wrote:
On 11/9/06, chunkeey@web.de [off-list ref] wrote:
quoted
Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
quoted
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
quoted
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
no replies.
Seems like it works for just fine for everybody. ;)
I found a card, I just need time to test it. Dan didn't you say you
ran into issues with the patch on your card?
Luis
From: Dan Williams <hidden> Date: 2006-11-10 14:40:48
On Thu, 2006-11-09 at 18:16 -0500, Luis R. Rodriguez wrote:
On 11/9/06, Luis R. Rodriguez [off-list ref] wrote:
quoted
On 11/9/06, chunkeey@web.de [off-list ref] wrote:
quoted
Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
quoted
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
quoted
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
no replies.
Seems like it works for just fine for everybody. ;)
I found a card, I just need time to test it. Dan didn't you say you
ran into issues with the patch on your card?
No, more that my card doesn't successfully associate at all even
_without_ the patch on unencrypted or WEP APs; I just can't test it,
since my card seems to be broken...
Dan
On Friday 10 November 2006 09:42, Dan Williams wrote:
On Thu, 2006-11-09 at 18:16 -0500, Luis R. Rodriguez wrote:
quoted
On 11/9/06, Luis R. Rodriguez [off-list ref] wrote:
quoted
On 11/9/06, chunkeey@web.de [off-list ref] wrote:
quoted
Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
quoted
On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote:
quoted
On 11/3/06, chunkeey@web.de [off-list ref] wrote:
quoted
yes, especially mgt_commit_list caused alot headaches, until I removed
DOT11_OID_PSM from the cache list.
Now, I can "hammer" it with ping -f for hours.
nice, perhaps that's been the culprit all along... going to dig to see
if I find a fullmac prism card. Will like to get this merged in.
Any resolution on this?
no replies.
Seems like it works for just fine for everybody. ;)
I found a card, I just need time to test it. Dan didn't you say you
ran into issues with the patch on your card?
No, more that my card doesn't successfully associate at all even
_without_ the patch on unencrypted or WEP APs; I just can't test it,
since my card seems to be broken...
FWIW I applied the patch to tonight pull form Linus's tree and my card
stopped associating with my AP (WEP128, Shared key). It only associated
with my neighbour router which is running without encryption.
--
Dmitry
Am Freitag, 17. November 2006 06:42 schrieben Sie:
quoted
No, more that my card doesn't successfully associate at all even
_without_ the patch on unencrypted or WEP APs; I just can't test it,
since my card seems to be broken...
FWIW I applied the patch to tonight pull form Linus's tree and my card
stopped associating with my AP (WEP128, Shared key). It only associated
with my neighbour router which is running without encryption.
can you please describe your setup? I tested WEP ("restricted") with a Netgear
WGT624 and a normal linux AP and haven't seen any problems so far.
for debugging:
dmesg & iwevent output would be nice...
but I'll accept a short "sniffer" extract too. ;)
(it would be really good, if you can provide a package dump form a working
setup with the old driver too!)
Christian
On 11/17/06, chunkeey@web.de [off-list ref] wrote:
Am Freitag, 17. November 2006 06:42 schrieben Sie:
quoted
quoted
No, more that my card doesn't successfully associate at all even
_without_ the patch on unencrypted or WEP APs; I just can't test it,
since my card seems to be broken...
FWIW I applied the patch to tonight pull form Linus's tree and my card
stopped associating with my AP (WEP128, Shared key). It only associated
with my neighbour router which is running without encryption.
can you please describe your setup? I tested WEP ("restricted") with a Netgear
WGT624 and a normal linux AP and haven't seen any problems so far.
The card is WG511 talking to netgear WGR614 router. I am using WEP128
with shared keys. Router is set to be "g" only. The OS is Fedora Core
3 (I swear I will upgrade :) ), just recompiled wireless tools from
sources in FC6.
for debugging:
dmesg & iwevent output would be nice...
Will do when I get home.
but I'll accept a short "sniffer" extract too. ;)
(it would be really good, if you can provide a package dump form a working
setup with the old driver too!)
You'd have to tell me exactly what you want me to do.
The reason for me trying the patch is that the card locks up
frequently (the amber transmission light turns on stays this way).
--
Dmitry
The card is WG511 talking to netgear WGR614 router. I am using WEP128
with shared keys. Router is set to be "g" only. The OS is Fedora Core
3 (I swear I will upgrade :) ), just recompiled wireless tools from
sources in FC6.
quoted
for debugging:
dmesg & iwevent output would be nice...
Will do when I get home.
quoted
but I'll accept a short "sniffer" extract too. ;)
(it would be really good, if you can provide a package dump form a
working setup with the old driver too!)
You'd have to tell me exactly what you want me to do.
just the Management Frames (MLME):
Beacon, Authentication and Association Responses/Requests Frames
you can capture these frames with an extra sniffer card (in monitor mode)
just run tcpdump, wireshark(ethereal), kismet, ...
The reason for me trying the patch is that the card locks up
frequently (the amber transmission light turns on stays this way).
Do you get any fancy "mgt timeout ..." or something in dmesg, when
the cards locks up? (include one, if you can, maybe syslog "saved" one)
On 11/17/06, chunkeey@web.de [off-list ref] wrote:
quoted
The reason for me trying the patch is that the card locks up
frequently (the amber transmission light turns on stays this way).
Do you get any fancy "mgt timeout ..." or something in dmesg, when
the cards locks up? (include one, if you can, maybe syslog "saved" one)
I think I saw these before (with earlier kernels, can't tell you
exactly when it stopped as I don't pay much attention to versions - I
work off tip of Linus's tree and pull often) but now it looks like it
simply locks up. Maybe I don't wait long enough - I just simply eject
and inster the card back when I see it locked up.
--
Dmitry
On 11/17/06, Dmitry Torokhov [off-list ref] wrote:
On 11/17/06, chunkeey@web.de [off-list ref] wrote:
quoted
quoted
The reason for me trying the patch is that the card locks up
frequently (the amber transmission light turns on stays this way).
Do you get any fancy "mgt timeout ..." or something in dmesg, when
the cards locks up? (include one, if you can, maybe syslog "saved" one)
I think I saw these before (with earlier kernels, can't tell you
exactly when it stopped as I don't pay much attention to versions - I
work off tip of Linus's tree and pull often) but now it looks like it
simply locks up. Maybe I don't wait long enough - I just simply eject
and inster the card back when I see it locked up.
Btw, it usually locks up under heavyish load. I.e. if I just ssh into
my devel box and code in vi it will stay jsut fine for hours. But
FTPing stuff over quite often locks it up.
--
Dmitry
Btw, it usually locks up under heavyish load. I.e. if I just ssh into
my devel box and code in vi it will stay jsut fine for hours. But
FTPing stuff over quite often locks it up.
k, I've seen this phenomenon too, but on my a PCI card.
Alright, when you come home, you should check the syslogs for these
kind of "timeout" messages.
On Friday 17 November 2006 15:53, chunkeey@web.de wrote:
quoted
The card is WG511 talking to netgear WGR614 router. I am using WEP128
with shared keys. Router is set to be "g" only. The OS is Fedora Core
3 (I swear I will upgrade :) ), just recompiled wireless tools from
sources in FC6.
quoted
for debugging:
dmesg & iwevent output would be nice...
Will do when I get home.
quoted
but I'll accept a short "sniffer" extract too. ;)
(it would be really good, if you can provide a package dump form a
working setup with the old driver too!)
You'd have to tell me exactly what you want me to do.
just the Management Frames (MLME):
Beacon, Authentication and Association Responses/Requests Frames
you can capture these frames with an extra sniffer card (in monitor mode)
just run tcpdump, wireshark(ethereal), kismet, ...
OK, i'll try installing kismet on another laptop. For now that's what I have
from iwevent:
[root@core ~]# cat iwevents.bad
21:30:52.185823 eth1 Set Mode:Managed
21:30:52.226100 eth1 Set ESSID:"ALCT76_68b"
21:30:54.505039 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:30:56.300128 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:30:58.095251 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:11.413225 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:13.207322 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:15.003497 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:16.798687 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:18.593844 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:31.911710 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:33.705200 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:35.501650 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:37.296756 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:39.091866 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:52.409596 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
21:31:54.203281 eth1 Custom driver event:Authenticate request to 00:0f:b5:5b:fe:3a [00 0D 0002]
[root@core ~]# cat iwevents.good
21:50:50.575630 eth1 Set Mode:Managed
21:50:50.604998 eth1 Set Encryption key:****-****-****-****-****-****-** Security mode:restricted
21:50:50.616502 eth1 Set ESSID:"ALCT76_68b"
21:50:52.880361 eth1 Custom driver event:Authenticate request to 00:0F:B5:5B:FE:3A : ACCEPTED (00)
21:50:52.882638 eth1 Custom driver event:Associate request to 00:0F:B5:5B:FE:3A : ACCEPTED (00)
21:50:52.883625 eth1 New Access Point/Cell address:00:0F:B5:5B:FE:3A
quoted
The reason for me trying the patch is that the card locks up
frequently (the amber transmission light turns on stays this way).
Do you get any fancy "mgt timeout ..." or something in dmesg, when
the cards locks up? (include one, if you can, maybe syslog "saved" one)
No, just netdev watchdog bitches:
Nov 16 23:15:30 core kernel: [164606.712000] NETDEV WATCHDOG: eth1: transmit timed out
Nov 16 23:15:30 core kernel: [164606.712000] eth1: tx_timeout, scheduling a reset
Nov 16 23:15:30 core kernel: [164606.712000] eth1: resetting device...
Nov 16 23:15:30 core kernel: [164606.712000] eth1: uploading firmware...
Nov 16 23:15:31 core kernel: [164606.996000] eth1: firmware version: 1.0.4.3
Nov 16 23:15:31 core kernel: [164606.996000] eth1: firmware upload complete
Nov 16 23:15:31 core kernel: [164607.232000] eth1: interface reset complete
--
Dmitry
Am Samstag, 18. November 2006 05:27 schrieben Sie:
OK, i'll try installing kismet on another laptop. For now that's what I
have from iwevent:
[root@core ~]# cat iwevents.bad
21:30:52.185823 eth1 Set Mode:Managed
where's Set Encryption key:****-****-****-****-****-****-** Security
mode:restricted ? was the key set?
21:30:52.226100 eth1 Set ESSID:"ALCT76_68b"
21:30:54.505039 eth1 Authenticate request to XY [00 0D 0002]
21:30:56.300128 eth1 Authenticate request to XY [00 0D 0002]
ok, the error code is 0D (=unsupported Authentication Algorithm).
[root@core ~]# cat iwevents.good
21:50:50.575630 eth1 Set Mode:Managed
21:50:50.604998 eth1 Set Encryption
key:****-****-****-****-****-****-** Security mode:restricted
21:50:50.616502 eth1 Set ESSID:"ALCT76_68b"
21:50:52.880361 eth1 Authenticate request to XY : [00 00 0002]
21:50:52.882638 eth1 Associate request to XY : [00 00 0002]
21:50:52.883625 eth1 New Access Point/Cell address:XY
are your wireless-tools( iwconfig, iwevent, iwlist...) up to date? they've to
be atleast Version 21!
but there's still something you can try:
go to drivers/net/wireless/prism54/isl_ioctl.c
and change in "prism54_set_auth_alg" function (somewhere at line 1040)
next to "if (flag & IW_ENCODE_RESTRICTED) {"
authen = DOT11_AUTH_SK;
to
authen = DOT11_AUTH_BOTH;
recompile; test; report ;)
No, just netdev watchdog bitches:
Nov 16 23:15:30 core kernel: [164606.712000] NETDEV WATCHDOG: eth1:
transmit timed out Nov 16 23:15:30 core kernel: [164606.712000] eth1:
tx_timeout, scheduling a reset Nov 16 23:15:30 core kernel: [164606.712000]
eth1: resetting device... Nov 16 23:15:30 core kernel: [164606.712000]
eth1: uploading firmware... Nov 16 23:15:31 core kernel: [164606.996000]
eth1: firmware version: 1.0.4.3 Nov 16 23:15:31 core kernel:
[164606.996000] eth1: firmware upload complete Nov 16 23:15:31 core kernel:
[164607.232000] eth1: interface reset complete
On Saturday 18 November 2006 05:18, chunkeey@web.de wrote:
Am Samstag, 18. November 2006 05:27 schrieben Sie:
quoted
OK, i'll try installing kismet on another laptop. For now that's what I
have from iwevent:
[root@core ~]# cat iwevents.bad
21:30:52.185823 eth1 Set Mode:Managed
where's Set Encryption key:****-****-****-****-****-****-** Security
mode:restricted ? was the key set?
quoted
21:30:52.226100 eth1 Set ESSID:"ALCT76_68b"
21:30:54.505039 eth1 Authenticate request to XY [00 0D 0002]
21:30:56.300128 eth1 Authenticate request to XY [00 0D 0002]
ok, the error code is 0D (=unsupported Authentication Algorithm).
quoted
[root@core ~]# cat iwevents.good
21:50:50.575630 eth1 Set Mode:Managed
21:50:50.604998 eth1 Set Encryption
key:****-****-****-****-****-****-** Security mode:restricted
21:50:50.616502 eth1 Set ESSID:"ALCT76_68b"
21:50:52.880361 eth1 Authenticate request to XY : [00 00 0002]
21:50:52.882638 eth1 Associate request to XY : [00 00 0002]
21:50:52.883625 eth1 New Access Point/Cell address:XY
are your wireless-tools( iwconfig, iwevent, iwlist...) up to date? they've to
be atleast Version 21!
Hmm, something funky is going on with my hotplug scripts - if I rerun
ifup eth1 after inserting the card it associates just fine. Sorry for
the false alarm, the drivers seems to be working fine.
Still not sure why old driver does not need second "ifup"...
--
Dmitry
Hmm, something funky is going on with my hotplug scripts - if I rerun
ifup eth1 after inserting the card it associates just fine. Sorry for
the false alarm, the drivers seems to be working fine.
Still not sure why old driver does not need second "ifup"...
old drivers? which one? the svn? 2.6.18?
Since, the card doesn't associate with WPA protected wlans automaticlly,
but what about WEP or unprotected wlans?
It would be nice if someone can capture the MLME frames and look
if the card does the right thing.