Ticket #1243 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

WEP and WPA not working with experimental madwifi-hal-0.9.30.10 r2249

Reported by: dpevp Assigned to:
Priority: minor Milestone:
Component: madwifi: other Version: madwifi-hal-0.9.30.10 branch
Keywords: Cc: daniel@dilmun.ls.fi.upm.es
Patch is attached: 0 Pending:

Description

I've tested this experimental version of madwifi and seems to work fine without encryption. The problem comes when I try to use WEP or WPA using wpa_supplicant. The problem is: 

# wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i ath0 -Dmadwifi 
Trying to associate with 00:0f:3d:b2:13:a6 (SSID='MyWEPNet' freq=2412 MHz)
ioctl[IEEE80211_IOCTL_SETMLME]: Invalid argument
Association request to the driver failed
Associated with 00:0f:3d:b2:13:a6
CTRL-EVENT-CONNECTED - Connection to 00:0f:3d:b2:13:a6 completed (auth) [id=0 id_str=]

My wireless card is: 

02:00.0 Network controller: Atheros Communications, Inc. AR5418 802.11a/b/g/n Wireless PCI Express Adapter (rev 01)

Although it seems to be connected I'm not able to get an IP using dhcp.

I don't know if WEP or WPA encryption is supposed to work yet in this version. If not, feel free to close de ticket.

Thanks for your work in this version.

Attachments

messages.bz2 (10.7 kB) - added by code_wiz on 04/03/07 09:56:48.

Change History

03/30/07 19:57:25 changed by strasak@bubakov.net

Here WEP works - without WPA supplicant tho

03/31/07 12:27:13 changed by kelmo

That is insufficient information to infer that WPA is not working, WPA2-PSK CCMP is working for me here with wpa_supplicant 0.6-20070324 snapshot using WEXT ioctl's and HAL branch 0.9.30.10 r2449.

Try using -Dwext option instead of -Dmadwifi.

03/31/07 12:28:04 changed by kelmo

Err, 2249, not 2449.

04/01/07 18:08:42 changed by toelke@in.tum.de

Here neither works. I just checked out wpa_supplicant from git and still get the cycle: 

# ./wpa_supplicant -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0
Trying to associate with SSID 'discworld'
Associated with 00:15:0c:ac:eb:66
WPA: Key negotiation completed with 00:15:0c:ac:eb:66 [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:15:0c:ac:eb:66 completed (auth) [id=0 id_str=]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Trying to associate with SSID 'discworld'
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with SSID 'discworld'
Associated with 00:15:0c:ac:eb:66
WPA: Key negotiation completed with 00:15:0c:ac:eb:66 [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:15:0c:ac:eb:66 completed (reauth) [id=0 id_str=]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
...

With WEP I try: 

iwconfig wlan0 essid discworld channel 4   mode managed key 11111111111111
111111111111 enc on

and get: 

wlan0     IEEE 802.11g  ESSID:"discworld"  Nickname:""
          Mode:Managed  Frequency:2.427 GHz  Access Point: 00:15:0C:AC:EB:66   
          Bit Rate:36 Mb/s   Tx-Power:14 dBm   Sensitivity=0/3  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:1111-1111-1111-1111-1111-1111-11   Security mode:restricted
          Power Management:off
          Link Quality=58/94  Signal level=-38 dBm  Noise level=-96 dBm
          Rx invalid nwid:69  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

With rising "invalid nwid". And no data are getting across.

I have a: 

2:00.0 Network controller: Atheros Communications, Inc. Unknown device 0024 (rev 01)

I hope I could help to bring this to an conclusion!

Happy Sunday, Philipp

04/03/07 09:56:48 changed by code_wiz

  • attachment messages.bz2 added.

04/03/07 10:00:46 changed by code_wiz

Here we go again.

I turned on the full debugging info and can present you a filtered messages file (atached to this ticket). I captured the frames from another machine and only saw probes, authentication and assosiaction, no data frames. In the messages file try to search for 'FAIL'. Maybe this helps.

Hardware used was the AR5418 found in a macbook pro.

I removed most of the beacons in the file (since here is much traffic) and hope no to have removed some important stuff.

If you need further info, please let me know.

Cheers,

code_wiz

04/05/07 03:19:58 changed by ajs

I have a Core 2 Duo Macbook here with this wireless chipset and I also find that WEP does not work correctly with the latest snapshot of this branch. Unencrypted connections work fine.

What can be done to debug this further?

04/05/07 09:19:18 changed by code_wiz

With ath_debug you can turn on lots of debugging output to your syslog (as I have done). The maybe a look at the source code helps. Normally it would when there were no binary hal.

Cheers,

code_wiz

04/05/07 10:31:05 changed by mrenzmann

@code_wiz: Do you have any reason to believe that this problem is caused by the HAL? If so, please provide them. Otherwise you should stop waving a red herring.

@ajs: As code_wiz pointed out, you might want to use the 80211debug and/or athdebug tools to enable specific debugging messages which might give further information or confirm what code_wiz saw on his system. DevDocs/AthDebug explains how these tools are used.

(follow-up: ↓ 15 ) 04/05/07 13:41:19 changed by code_wiz

@mrenzmann: I yet did not have the time to look into the code, so my first guess was in fact the hal, since the support for AR5418 is new and the older version works fine on my AR5212. Since this is a new branch and ideally all code should have been merged from the older version, it was somehow closer to me to blame the hal than a bug in the code around the hal.

I would really appreciate someone with more experience of the madwifi driver internals took a look at the messages file posted by me. If I would get a pointer where to look in the code, I could do that but proof-reading the whole code is simply not possible for me due to limited time.

Cheers,

code_wiz

04/05/07 21:06:09 changed by ajs

Okay, I'm not very experienced with debugging such things, but I enabled maximum debug with both tools and then grabbed between the time the driver was inserted, to the point of association with the WEP STA, and then for a while during the DHCP failure (when no packets went through the NIC).

The log is extremely large and verbose, but it is available from here. The AP associated with had the ESSID "SCS".

04/05/07 21:06:47 changed by anonymous

From here:

devzero.co.uk/~alistair/kern.log.gz

04/06/07 00:11:42 changed by code_wiz

I took a closer look into the dumps:

Apr 1 18:00:54 localhost 08 41 3a 01 00 11 95 0a 2b 1e 00 19 e3 d6 d3 fb Apr 1 18:00:54 localhost ff ff ff ff ff ff 50 00 05 69 70 00 aa aa 03 00 Apr 1 18:00:54 localhost 00 00 08 06 00 01 08 00 06 04 00 01 00 19 e3 d6 Apr 1 18:00:54 localhost d3 fb c0 a8 b2 16 00 00 00 00 00 00 c0 a8 b2 01

When disassembling this correctly, I get: 0841 ---> 0100 0001 0000 1000 Version 00 Type 10 Subtype 0000 (Type + Subtype --> Data/Data) To DS WEP

00 11 95 0a 2b 1e = Address 1 00 19 e3 d6 d3 fb = Address 2 ff ff ff ff ff ff = Address 3 Sequence Control 50 00 <data> CRC c0 a8 b2 01

This seems to be correct so far (I did not check the crc's correctness).

From what I see in the source code, the macro ath_hal_txprocdesc returns HAL_OK and sets ts_status to a value != 0: Apr 1 18:00:54 localhost T (ffff8100a2123f00 0) a2123fc0 bb38fc3c 411d0048 00000040 000b0000 0000001b 00000000 00000000 !

This is indicated by the exclamation mark.

The macro mentioned above calls the hal function pointer ah_procTxDesc which lies somewhere in the hal binaries.

@mrenzmann: Please excuse me one more time for pointing at the hal with this. From what I see, a good-looking packet is given to the hal and it returns an error status and does not transmit the packet over the air. But again, I may be completely wrong, since I could not check every single flags set in the structures given to the hal.

Cheers,

code_wiz

04/06/07 22:10:26 changed by ammulder

I am using an "IBM 802.11abgn" ThinkPad? card that appears to be the same as the MacBook Pro card discussed here. I'm using openSUSE 10.x, with KDE, NetworkManager, and KNetworkManager. I tried building and installing the driver from the r2249 release tarball.

I only have access to WEP/WPA networks at work, and I cannot connect. The first time, iwconfig said the mode was either 802.11a or 802.11Ta and it never associated with the access point. Then I tried "iwpriv ath0 set 3" and tried again and iwconfig showed that it linked up with the access point, but it never gets an IP address and eventually NetworkManager says the connection failed. "ifconfig" shows packets sent and received, but also 1 TX packet error and 1 TX packet dropped per attempt.

I've tried an 802.11b AP with WEP-128 and an Apple Airport Extreme N with WPA and WPA2 (I tried TKIP, AES-CCMP, and Auto for the WPA2 protocol). I wasn't able to connect to any of them.

I'm not sure what to do to troubleshoot further.

04/10/07 01:04:14 changed by anonymous

I find that even with encryption disabled, associating can be quite flaky. I have 802.11g equipment that is rate limited to 11M (to force b auto-neg) and the driver seems to think about it, sometimes for minutes at a time, before associating.

This branch of the driver is definitely busted.

(in reply to: ↑ 9 ) 04/10/07 07:36:05 changed by mrenzmann

Replying to code_wiz:

Since this is a new branch and ideally all code should have been merged from the older version, it was somehow closer to me to blame the hal than a bug in the code around the hal.

The FreeBSD driver seems to have seen quite some changes that we didn't import yet, and it might well be that we missed something important in the new branch. I just don't want to see the HAL being blamed just "because it's closed source and we can't look into it". If you blame the HAL, please at least have a good reason. I think that you now have provided some (in your review of the dumps from devzero.co.uk).

04/10/07 19:39:08 changed by turbo@bayour.com

I've just tried madwifi-hal-0.9.30.10 (revision 2270), but it won't work here. When loading the ath_pci module, all I get is:

Apr 10 18:37:56 turbo-laptop2 kernel: [ 635.372000] ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Apr 10 18:37:56 turbo-laptop2 kernel: [ 635.384000] wlan: 0.8.4.2 (svn r2270) Apr 10 18:37:56 turbo-laptop2 kernel: [ 635.388000] ath_pci: 0.9.4.5 (svn r2270)

And no ath? or wifi? interface is created...

(follow-up: ↓ 20 ) 04/10/07 21:17:47 changed by code_wiz

@turbo@bayour.com:

You loaded the wrong driver. Your hal version is 0.9.18.0.

Cheers,

code_wiz

04/10/07 23:20:48 changed by Sven

Apple MacBook Pro: Connection with encryption does not work, without it does... I'm using the NetworkManager on Ubuntu Edgy with wpa_supplicant and GNOME, Linux kernel is 2.6.19.1... Do you need any further information?

04/11/07 00:59:04 changed by ajs

@mrenzmann:

I apologise for the verbosity of the logs, if you would like me to re-run with more specific options, please let me know.

(in reply to: ↑ 17 ; follow-up: ↓ 21 ) 04/12/07 18:58:47 changed by anonymous

Replying to code_wiz:

You loaded the wrong driver. Your hal version is 0.9.18.0.

So how do I install 0.9.30.10!? No matter how I do, I can't seem to get a 0.9.30.10 version. I 'make' in the 'madwifi-hal-0.9.30.10' directory followed by a 'make install'. Still get 0.9.18.0!

(in reply to: ↑ 20 ; follow-up: ↓ 22 ) 04/12/07 19:20:48 changed by anonymous

Replying to anonymous:

Replying to code_wiz:

You loaded the wrong driver. Your hal version is 0.9.18.0.

So how do I install 0.9.30.10!?

Never mind. I checked out the code again, and this time I load the correct one:

Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.280000] ath_hal: 0.9.30.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133) Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.288000] wlan: 0.8.4.2 (svn r2257) Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.292000] ath_pci: 0.9.4.5 (svn r2257) Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.292000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11 Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.292000] PCI: Setting latency timer of device 0000:02:00.0 to 64 Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] ath_rate_sample: 1.2 (svn r2257) Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: H/W encryption support: WEP AES AES_CCM TKIP Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: mac 12.10 phy 8.1 radio 12.0 Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 1 for WME_AC_BE traffic Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 0 for WME_AC_BK traffic Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 2 for WME_AC_VI traffic Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 3 for WME_AC_VO traffic Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 8 for CAB traffic Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.436000] wifi0: Use hw queue 9 for beacons Apr 12 18:12:39 turbo-laptop2 kernel: [ 1176.448000] wifi0: Atheros 5418: mem=0x50100000, irq=11 Apr 12 18:19:33 turbo-laptop2 NetworkManager: <debug info>I[1176398373.480394] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/net_00_19_e3_08_f6_82'). Apr 12 18:19:33 turbo-laptop2 NetworkManager: <debug info>I[1176398373.504796] nm_hal_device_added (): New device added (hal udi is /org/freedesktop/Hal/devices/net_00_19_e3_08_f6_82_0').

I have yet to do any testing on it though... I'll let you know if it works... Thanx!

(in reply to: ↑ 21 ) 04/12/07 20:23:50 changed by turbo@bayour.com

Replying to anonymous:

Replying to anonymous:

Replying to code_wiz:

You loaded the wrong driver. Your hal version is 0.9.18.0.

So how do I install 0.9.30.10!?

I have yet to do any testing on it though... I'll let you know if it works... Thanx!

Some quick tests showed that I can connect two laptops (ad-hoc mode) without any encryption what so ever, but not to the company AP (which uses encryption, although I don't know what type etc): 

root@turbo-laptop2:~# wpa_supplicant -w -Dmadwifi -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
Trying to associate with 00:18:b9:2a:b8:10 (SSID='<ESSID>' freq=2452 MHz)
ioctl[IEEE80211_IOCTL_SETMLME]: Invalid argument
Association request to the driver failed
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with 00:18:b9:2a:b8:10 (SSID='<ESSID>' freq=2452 MHz)
ioctl[IEEE80211_IOCTL_SETMLME]: Invalid argument
Association request to the driver failed
Associated with 00:18:b9:2a:b8:10
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
CTRL-EVENT-CONNECTED - Connection to 00:18:b9:2a:b8:10 completed (auth) [id=0 id_str=wlan0-work]

Using '-Dwext' don't work at all: 

root@turbo-laptop2:~# wpa_supplicant -w -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
Trying to associate with 00:18:b9:2a:ad:00 (SSID='<ESSID>' freq=2472 MHz)
Trying to associate with 00:18:b9:2a:b8:10 (SSID='<ESSID>' freq=2452 MHz)
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with 00:18:b9:2a:b8:10 (SSID='<ESSID>' freq=2452 MHz)
Authentication with 00:00:00:00:00:00 timed out.
CTRL-EVENT-TERMINATING - signal 2 received

Third time I run wpa_supplicant, I get this: 

root@turbo-laptop2:~# wpa_supplicant -w -Dmadwifi -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
Associated with 00:18:b9:2a:b8:10
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
CTRL-EVENT-CONNECTED - Connection to 00:18:b9:2a:b8:10 completed (auth) [id=0 id_str=wlan0-sapo]

Although the first wpa_supplicant line seems to work (albeit some 'Invalid argument's and that OpenSSL complains about the TLS handshake etc), I can't get an IP address (DHCP)... 

root@turbo-laptop2:~# dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit <dhcp page>

wifi0: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/wlan0/00:19:e3:08:f6:82
Sending on   LPF/wlan0/00:19:e3:08:f6:82
Sending on   Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
No DHCPOFFERS received.

What is a little 'strange' is the 'wifi0' interface.. I can't seem to use it for anything. 

root@turbo-laptop2:~# iwconfig wifi0
wifi0     no wireless extensions.
root@turbo-laptop2:~# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"<ESSID>"  Nickname:""
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:18:B9:2A:B8:10   
          Bit Rate:54 Mb/s   Tx-Power:11 dBm   Sensitivity=0/3  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:AAAA-BBBB-CCCC-DDDD-EEEE-FFFF-GG [4]   Security mode:restricted
          Power Management:off
          Link Quality=59/94  Signal level=-37 dBm  Noise level=-96 dBm
          Rx invalid nwid:2800  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

If anyone need me to run the driver in debug mode, just ask and I'll be happy to appy. This is a lot better/more important for me than going through NDISWrapper....

04/17/07 12:45:53 changed by anonymous

I am now at revision 2279. Any news on WEP/WPA/WPA2?

04/17/07 18:52:05 changed by anonymous

does not seem like anyone is making any headway on this

04/17/07 22:40:49 changed by toelke@in.tum.de

The problem seems to be in the hal -- and nobody (apart from one person, whose name I can't recall) can debug and change the hal. So we're all stuck until Sam(???) gets the time to tackle this problem...

So the best course of action is to be patient.

04/18/07 11:29:54 changed by turbo@bayour.com

I DON'T WANT TO BE PATIENT, I WANT IT NOW, NOW!! :). Sorry, I had to say it, I've been listening to my kids a little to much :)

Any news from Sam then?

04/19/07 18:40:21 changed by anonymous

this issue should be fixed as soon as possible. come on, guys! ;)

04/21/07 04:08:30 changed by Kvetch

I am not sure if this is worth noting in this ticket but when using something like aircrack-ng to inject packets the device stops and I lose all signals in kismet or airodump. You have to patch the madwifi drivers with the aircrack-ng patch so I am not sure where the issues lies but everything works as normal until I inject packets. I am using the 2279 rev.. If there are further details you would like please let me know and I would be happy to post them.

(in reply to: ↑ description ) 04/26/07 20:36:37 changed by anonymous

waiting, too...

04/28/07 03:28:09 changed by anonymous

Shut up already. They are working on it. If you don't like it, install ndiswrapper.

04/28/07 11:50:47 changed by Rudi <bugfinder@t-online.de>

ndiswrapper does not really help unless you are runnning 32bit. Or has anyone seen a working 64bit-XP driver for these cards ?

But besides all these "I'm impatient" issues ... what is the real status here ? Up to now I only saw hints that the HAL may be causing the problem, but no confirmation. The rest of the driver code could be causing the problem as well, or has this been ruled out already and I misread the comments ?

04/29/07 00:11:39 changed by tanner dot postert at gmail dot com

i'm getting the same issue "Association request to the driver failed" using edgy 2.6.17-11-generic. the strange thing is, it has been working fine until today. it worked fine to connect at home, using wpa with -Dmadwifi, and it worked fine at work connecting with wep using the network manager, and it has worked back and forth at each for a few days, now, all the sudden, it just doesn't work.

04/30/07 13:34:16 changed by anonymous

there's a new hal on people.freebsd.org/~sam/

apparently, updating (read: replacing) the hal in r2257 with this one is enough to get WEP encryption to work. not well tested, though, it seems to work.

04/30/07 18:47:02 changed by kbenton

Anyone had any luck with that with WPA? i've given it a quick crack and tried the usual but nothing seemed to be different. Can still get unencrypted working fine.

04/30/07 20:21:48 changed by strasak@bubakov.net

take a look at #1001 , WPA should work according to that

05/01/07 00:41:56 changed by anonymous

No go with WPA here (thinkpad t41 with a 5212 on 2.6.20). I simply took the r2257 branch and used the 0.9.30.13-hal as a replacement for the 0.9.30.10 in r2257. (maybe that was wrong?)

05/01/07 11:14:11 changed by turbo@bayour.com

That's exactly how I did it and it worked for me. Did you 'make clean' and then '[r]emove' the old drivers when you installed the new made ones? And 'rmmod' all drivers found with: lsmod | egrep 'ath|wlan' ? Check 'dmesg' when you load the 'ath_pci' driver again (there is absolutly no need for a reboot if you make sure to remove all the right drivers - see the lsmod command line example).

05/01/07 11:34:59 changed by Rudi <bugfinder@t-online.de>

yes, works here as well, THANKS to everyone that helped! (setup MacBookPro? using WPA-PSK)

BTW: r2257 is a revision, not the branch. Are you sure you used the branch "branches/madwifi-hal-0.9.30.10" instead of "trunk" ?

05/01/07 12:12:41 changed by anonymous

It does work with madwifi-hal-0.9.30.10 r2257 but not with current one (23xx).

With current I can get associated with the AP (128bit WEP encryption) but cannot send/receive any packets. Capturing traffic on Wifi0 device with Ethereal reveals a reserved protocol error so no packets go to the air. Any ideas? Should I open a ticket?

(follow-up: ↓ 42 ) 05/01/07 12:16:59 changed by anonymous

No Wifi0 is only used as control interface, to create ath interface (to be short), so you have to start ethereal on ath interface instead of wifi0.

05/01/07 15:13:11 changed by pic0

I confirm that WEP (128 bits) / WPA-PSK / WPA2-PSK DO work (at least with TKIP/AES, I have no CCMP network to test).

(in reply to: ↑ 40 ) 05/01/07 15:28:02 changed by anonymous

Replying to anonymous:

No Wifi0 is only used as control interface, to create ath interface (to be short), so you have to start ethereal on ath interface instead of wifi0.

Replying to anonymous:

No Wifi0 is only used as control interface, to create ath interface (to be short), so you have > to start ethereal on ath interface instead of wifi0.

I know what's Wifi0 interface for (some kind of generic interface where other virtual interfaces are created from) and there's no problem in capturing traffic from that interface apart from seeing all the traffic that travels over the air in RAW mode (Ethereal might complain about incorrect 802.11 headers but if you take a deeper look you'll see higher lever headers and other stuff), but that's not the point of the question.

The impotant thing is that with madwifi-hal-0.9.30.10 current SVN version (r23xx) and the new published HAL you can get associated with an AP (I've tried using 128 bits WEP key) but no packets will come out of your interface, but If you use madwifi-hal-0.0.30 r2257 and the new HAL everything works well.

I think someone from Madwifi should take a look at it and patch the r23xx versions. Should I open a new ticket?

05/01/07 18:48:55 changed by mentor

The latest change to branches/madwifi-hal-0.9.30.10 is at r2257. This branch contains changes that port the driver to the new HAL interface (API/ABI). If you are trying to drop a new HAL into trunk/; that won't work.

05/02/07 10:41:17 changed by dpevp

With the new branch 0.9.30.13 open networks, WEP encrypted networks and WPA 1 works fine for me. I reported this ticket and it seems to work now, so I suggest to close this ticket as fixed and report new issues in new tickets (this one is too long).

Thanks for your work.

05/02/07 14:00:27 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

Thanks

Fixed in branches/madwifi-hal-0.9.30.13