Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1306 (new defect)

Opened 15 years ago

Last modified 14 years ago

Kernel Panic in ADHOC mode with WEP enabled

Reported by: Saurav Kumar Barik <sauravb@aztecsoft.com> Assigned to:
Priority: major Milestone:
Component: madwifi: 802.11 stack Version: v0.9.2
Keywords: Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

I am getting kernel panic while configuring WEP in ADHOC mode.

My setup is:

  • GWIXP425BDT
  • Debian 2.6.18
  • Senao 400mw
  • Madwifi 0.9.2
    • ATH_PCI 0.9.4.5
    • ATH_HAL 0.9.17.2
    • WLAN 0.8.4.2

Steps to reproduce:

  1. wlanconfig ath0 create wlandev wifi0 wlanmode adhoc
  2. iwconfig ath0 essid "adhoc" channel 2
  3. iwconfig ath0 key s:saurav
  4. ifconfig ath0 x.x.x.x up
  5. ping y.y.y.y

Please note that y.y.y.y is the IP address of the peer adhoc vap (already up) with same config. The 5th step is redundant as sometimes at 4th step itself it crashes. But the panic is easily and repeatedly reproducible.

PANIC LOGS (captured from HyperTerminal):

saurav:~# ping y.y.y.y
PING y.y.y.y (x.x.x.x) 56(84) bytes of data.
Unable to handle kernel paging request at virtual address 40098225
pgd = c0004000
[40098225] *pgd=00000000
Internal error: Oops: f3 [#1]
Modules linked in: wlan_wep wlan_scan_sta ipt_TOS xt_physdev ipt_u32
iptable_mangle ixp4xx_wdt xt_tcpudp iptable_filter ip_tables x_tables
wlan_scan_ap bridge llc ath_pci ath_rate_sample wlan ath_hal
CPU: 0
PC is at ieee80211_input+0xf8/0x1760 [wlan]
LR is at 0x400981d9
pc : [<bf03e22c>]    lr : [<400981d9>]    Tainted: P    
sp : c0253e10  ip : 00000044  fp : c0253ea4
r10: 00000000  r9 : c33c8660  r8 : c2d2f000
r7 : ffc0c5a0  r6 : 0000000a  r5 : c2dce280  r4 : c0970020
r3 : 00003e83  r2 : 00000048  r1 : 00000008  r0 : 00000004
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 397F  Table: 032FC000  DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc0252250)
Stack: (0xc0253e10 to 0xc0254000)
3e00:                                     c003c818 c376d260 c0252000 c3322a00
3e20: 00000000 c0253e50 c0253e34 c01ebc80 c01abe78 00000000 000000ff c2dc6000
3e40: 00000005 400981d9 00003e83 0000000c c0253e5c bf0002b0 c002ae40 0370c5d0
3e60: ffc0c5a0 c0253e90 c0253e74 c002a2e0 c0025fa0 ffc0c5d0 c0253ea4 c2d2f000
3e80: c3756280 0000000a ffc0c5a0 00000001 00000048 c33c8660 c0253ef0 c0253ea8
3ea0: bf07a2a0 bf03e140 0230be8b 00000000 c3757820 c36f0000 c35c45a0 c3756000
3ec0: c0252000 00000000 00000000 c02adb64 0000000a c02adb40 00000001 c0252000
3ee0: 0001c7e8 c0253f08 c0253ef4 c003cb98 bf079d14 00000001 c02adb90 c0253f28
3f00: c0253f0c c003c6f0 c003cb24 c0252000 0000001f 10000000 00000002 c0253f3c
3f20: c0253f2c c003c8fc c003c6a0 ffffffff c0253f4c c0253f40 c002074c c003c8c4
3f40: c0253fa4 c0253f50 c001f9d8 c0020714 00000000 000000a0 00000000 60000013
3f60: c0252000 c0020944 c02a8270 c02bdb6c 0001c8b8 690541c1 0001c7e8 c0253fa4
3f80: c0253fa8 c0253f98 c00209f0 c0020988 60000013 ffffffff c0253fc0 c0253fa8
3fa0: c00209f0 c0020950 c0252000 c02a7e1c c0256304 c0253fd4 c0253fc4 c001f048
3fc0: c002099c c02b026c c0253ff4 c0253fd8 c000886c c001f00c c00082e4 c02a8348
3fe0: 0000397d c02a82e4 00000000 c0253ff8 00008030 c000866c 00000000 00000000
Backtrace:
[<bf03e134>] (ieee80211_input+0x0/0x1760 [wlan]) from [<bf07a2a0>] (ath_rx_tasklet+0x598/0x890 [ath_pci])
[<bf079d08>] (ath_rx_tasklet+0x0/0x890 [ath_pci]) from [<c003cb98>] (tasklet_action+0x80/0xc8)
[<c003cb18>] (tasklet_action+0x0/0xc8) from [<c003c6f0>] (__do_softirq+0x5c/0xc8)
 r5 = C02ADB90  r4 = 00000001
[<c003c694>] (__do_softirq+0x0/0xc8) from [<c003c8fc>]
(irq_exit+0x44/0x58)
 r7 = 00000002  r6 = 10000000  r5 = 0000001F  r4 = C0252000
[<c003c8b8>] (irq_exit+0x0/0x58) from [<c002074c>] (asm_do_IRQ+0x44/0x50)
 r4 = FFFFFFFF
[<c0020708>] (asm_do_IRQ+0x0/0x50) from [<c001f9d8>] (__irq_svc+0x38/0x70)
[<c0020944>] (default_idle+0x0/0x4c) from [<c00209f0>] (cpu_idle+0x60/0xac)
[<c0020990>] (cpu_idle+0x0/0xac) from [<c001f048>] (__init_end+0x48/0x50)
 r6 = C0256304  r5 = C02A7E1C  r4 = C0252000
[<c001f000>] (__init_end+0x0/0x50) from [<c000886c>] (start_kernel+0x20c/0x26c)
 r4 = C02B026C
[<c0008660>] (start_kernel+0x0/0x26c) from [<00008030>] (0x8030)
Code: e58530c0 ea000592 e51be060 e5d42001 (e59e304c)
 <0>Kernel panic - not syncing: Aiee, killing interrupt handler!

Change History

05/11/07 16:21:50 changed by mentor

  • reporter changed from mentor to Saurav Kumar Barik <sauravb@aztecsoft.com>.

05/11/07 16:22:31 changed by mentor

Does this occur with madwifi 0.9.3?

05/11/07 16:26:39 changed by mrenzmann

  • description changed.

05/11/07 16:28:16 changed by mrenzmann

Does the crash go away when you don't make use of WEP while keeping the other parameters identical?

(follow-ups: ↓ 6 ↓ 8 ) 05/12/07 01:56:39 changed by mentor

Hang on... Can you use WEP in ad-hoc mode?

(in reply to: ↑ 5 ; follow-up: ↓ 9 ) 05/13/07 09:07:05 changed by mrenzmann

Replying to mentor:

Hang on... Can you use WEP in ad-hoc mode?

Are you asking whether WEP is expected to work with ad-hoc? If so: I think yes (but am not 100% sure). WPA would not work, as the usual "authenticator/supplicant" scheme doesn't apply to IBSS mode. But there is nothing like that for WEP.

(follow-up: ↓ 17 ) 05/14/07 07:41:57 changed by Saurav

I am yet to try with 0.9.3.

Yes, there is no crash when I use normal adhoc setup without WEP.

The WEP feature in adhoc mode is working with some intermittent problems. But I saw there are quite a few tickets open for the WEP problems, but kernel panic is one of its first kind.

(in reply to: ↑ 5 ) 05/14/07 08:57:37 changed by anonymous

Replying to mentor:

Hang on... Can you use WEP in ad-hoc mode?

Yes, this is supposed to work. After all, you just say "use this key do encrypt and decrypt".

(in reply to: ↑ 6 ; follow-up: ↓ 10 ) 05/14/07 09:05:39 changed by anonymous

Replying to mrenzmann:

WPA would not work, as the usual "authenticator/supplicant" scheme doesn't apply to IBSS mode. But there is nothing like that for WEP.

WPA-PSK is supposed to work in IBSS-mode (according to Jouni Mallinen, author of wpa_supplicant), but does not with Madwifi. In WPA-PSK you just set a Pre Shared Key that is supposed to be used to encrypt and decrypt the packets. See the May 2006 hostap mailing list archive and search for a thread with the toppic "wpa-supplicant for adhoc network with more than 2 nodes ?". (sorry, URLs are forbidden in ticket replies).

(in reply to: ↑ 9 ; follow-up: ↓ 11 ) 05/14/07 09:06:35 changed by anonymous

Replying to anonymous:

WPA-PSK

Sorry, make this WPA-NONE, e.g. no key change every so often.

(in reply to: ↑ 10 ) 05/16/07 09:31:39 changed by anonymous

Replying to anonymous:

Replying to anonymous:

WPA-PSK

Sorry, make this WPA-NONE, e.g. no key change every so often.

AFAIK in Adhoc mode only beacon and probe req/resp are exchanged as part of the management frames. Please correct me if I am wrong. But the WPA stuffs by Wpa_Supplicant needs association/auth frames to be exchanged. So I am afraid whether WPA(WPA-NONE) works for MadWiFi in Adhoc mode. I tried to setup WPA-NONE without success.

I am getting following lines as part of the wpa_supplicant logs,
ioctl[IEEE80211_IOCTL_SETOPTIE]: Invalid argument
Association request to the driver failed

These ioctl failures are obvious in Adhoc Mode, I suppose.

05/16/07 09:35:19 changed by Saurav

Last message was posted by me. I am sorry for the confusion.

05/17/07 17:16:07 changed by mentor

Right, as far as the specifications go, the behaviour isn't really defined; however, once a STA join/synchronises with an IBSS, it can setup any authentication/association with any other STA that it wants. However, we currently do not support this.

It shouldn't crash however.

(follow-up: ↓ 15 ) 05/21/07 15:02:33 changed by anonymous

Well, once again I can only point at wpa_supplicant examples that clearly state that WPA encryption with IBSS networks should work and obviously works with other drivers. An example would be the Gentoo documentation "Chapter 4. Wireless Networking":

# IBSS/ad-hoc network with WPA-None/TKIP
network={
  ssid="test adhoc"
  mode=1
  proto=WPA
  key_mgmt=WPA-NONE
  pairwise=NONE
  group=TKIP
  psk="secret passphrase"
}

Or to quote Jouni Mallinen:

Jouni Malinen wrote:
> 
> This would a question to madwifi mailing list.. wpa_supplicant does not
> really do more than just configure a key to the driver in WPA-None mode
> and that's it.. The driver will need to take care of everything else in
> this case. WPA-None mode has enough issues to make it difficult to find
> someone who would be interested in actually using time to mkae it work,
> though.. Adding support for IEEE 802.11i (WPA2) IBSS could be more
> worthwhile target for efforts.
> 

(in reply to: ↑ 14 ) 02/11/08 09:51:26 changed by anonymous

Replying to anonymous:

Well, once again I can only point at wpa_supplicant examples that clearly state that WPA encryption with IBSS networks should work and obviously works with other drivers. An example would be the Gentoo documentation "Chapter 4. Wireless Networking": {{{ # IBSS/ad-hoc network with WPA-None/TKIP network={ ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="secret passphrase" } }}} Or to quote Jouni Mallinen: {{{ Jouni Malinen wrote:

This would a question to madwifi mailing list.. wpa_supplicant does not really do more than just configure a key to the driver in WPA-None mode and that's it.. The driver will need to take care of everything else in this case. WPA-None mode has enough issues to make it difficult to find someone who would be interested in actually using time to mkae it work, though.. Adding support for IEEE 802.11i (WPA2) IBSS could be more worthwhile target for efforts.

}}}

This is salim saay, con you please say why most of the authentication protocols not working on adhoc mode, how can we fix that to work on adhoc mode. best regards

02/11/08 09:53:50 changed by anonymous

i am sorry, i thing i write my request on wrong places, this is my question: This is salim saay, con you please say why most of the authentication protocols not working on adhoc mode, how can we fix that to work on adhoc mode.

best regards

(in reply to: ↑ 7 ) 02/23/08 19:35:23 changed by anonymous

Replying to Saurav:

I am yet to try with 0.9.3. Yes, there is no crash when I use normal adhoc setup without WEP. The WEP feature in adhoc mode is working with some intermittent problems. But I saw there are quite a few tickets open for the WEP problems, but kernel panic is one of its first kind.

WEP is working in ad-hoc mode properly but WPA(PSK) is not working in ad-hoc mode. is some one to reply me why it is not working in ad-hoc mode, and if we want to modify the source code how can find the source code of wpa in OpenWrt?, my E-mail address is salimsaay@gmail.com