iwl3945 doesn't support ad-hoc networks

Bug #201597 reported by ?????????
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-meta (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: linux-image

Dell XPS-M1330 laptop with an Intel 3945abg wireless card

Trying to connect using Network Manager applet to an AdHoc 802.11b network. The scan works and I can see the network, if I choose it from the applet, I'm asked for the wep key but the connection fails and I just keep repeatedly getting asked for the wep key again.

This happened under both Gutsy (with the restricted driver) and Hardy Alpha 6 with the mac80211 driver.

Revision history for this message
Hidde Verstoep (hiddeverstoep) wrote :

I can confirm this bug. I've been using Gutsy, Hardy Alpha 5,6 and Beta. Same behaviour.

Revision history for this message
Barteq (barteqpl) wrote : Re: iwl3945 doesn't support ad-hoc networks [change package hint to nework-manager]

Same on iwl4965 1.2.0 driver. There is a problem not in linux-image but in Network manager itself. It doesn't set mode ad-hoc. While connecting iwconfig iwl0 shows managed only. After turning off network manager, and manually configuration it worked fine.

If you want please make a little test.

Turn off wireless network in netowork manager. Then open shell and write as follows:

sudo iwconfig wlan0 mode ad-hoc
sudo iwconfig wlan0 essid "SSID_of_your_net"
sudo iwconfig key s:plaintextpassword_5_or_13_chars
sudo ifconfig wlan0 up
sudo dhclient wlan0

^ this works fine on iwl4965 so should work under 3965 too. If it works for you that means that there is no bug in wifi driver only NM.

I'm running cutting edge Hardy beta (2.6.24-12-server kernel) with network-manager version 0.6.6-0ubuntu4

Revision history for this message
????????? (jeb-jdwilkins) wrote :

I can confirm the above behaviour with an iwl3945. Interestingly it didn't with the sequence above, i had to bring the interface up, then run the iwconfig commands for it to work.

I guess this confirms the problems to do with network manager.

Revision history for this message
Hidde Verstoep (hiddeverstoep) wrote :

I ran the same procedure again. Now with iwevent running in a terminal. I can see "Set Mode:Managed" appearing on the screen when NM tries to connect, so I guess NM sets the wrong mode when trying to connect.

Revision history for this message
emil_p8 (emile-visual) wrote :

Same problem on a Thinkpad with Kubuntu Hardy Final and iwl4965. I'm able to connect manually, but then I experience random network-related hangups: the machine doesn't even respond to sysRq sequences and has its Caps Lock LED flashing.

Basically, i have to paste each time this sequence:
sudo ifconfig wlan0 down&&sudo iwconfig wlan0 mode ad-hoc&&sudo ifconfig wlan0 up&&sudo iwconfig wlan0 essid winet&&sudo iwconfig wlan0 key XXX &&sudo route add default gw 192.168.0.1
since on boot it seems iwlwifi ignores the ad-hoc mode set in /etc/network/interfaces

Revision history for this message
krom (krom) wrote :

confirm this bug.
Dell Inspiron 1525
iwl3945 driver v. 1.2.25 from backports

Revision history for this message
Mathieu Leplatre (mathieu.leplatre) wrote :

I confirm this bug.

Using ifdown & ifup as emil_p8 suggested, it solves the "Device or resource busy" error.

But then it never connects.
I have exactly the problems described in this Fedora bug :
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1489

I do everything with command-line using the attached script.

Cells are almost never the same even if mode/channel/frequency/essid/passwd are the same on both computers.

After many tries, once I succeed to have same cell, it never connects and iwconfig is missing information (Bitrate, Tx-power) and Link Quality:0 Signal level:0 Noise level:0

Revision history for this message
emil_p8 (emile-visual) wrote :

I solved more or less my problem by putting the target ad-hoc wifi card in access point emulation mode (its my gateway, and has to run Windows so I had to use the proprietary module instead of the standard windows control which has no option for this mode). However, Network Manager still has trouble setting the key and/or getting an IP; definitely, this piece of software seems totally useless for me with at least 3 different setups & wifi cards. In command-line mode everything is OK.

Revision history for this message
Jefferson Martins de Oliveira (jeffersonjbj) wrote :

I have same problem:

jefferson@jeffersonlaptop:~$ sudo iwconfig wlan0 mode ad-hoc
Error for wireless request "Set Mode" (8B06) :
    SET failed on device wlan0 ; Device or resource busy.

jefferson@jeffersonlaptop:~$ uname -a
Linux jeffersonlaptop 2.6.24-17-rt #1 SMP PREEMPT RT Thu May 1 16:23:33 UTC 2008 i686 GNU/Linux

jefferson@jeffersonlaptop:~$ dmesg | grep iwl
[ 48.377513] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.0
[ 48.377523] iwl3945: Copyright(c) 2003-2007 Intel Corporation
[ 48.590601] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[ 51.916901] iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
[ 51.919390] wmaster0: Selected rate control algorithm 'iwl-3945-rs'

Revision history for this message
Psy[H[] (vovik-wfa) wrote :

Confirmed on Asus A8Sr, Intel PRO/Wireless 3945ABG, Hardy, latest updates...

Revision history for this message
Jefferson Martins de Oliveira (jeffersonjbj) wrote :
Revision history for this message
Mathieu Leplatre (mathieu.leplatre) wrote :

I did.

As excepted, ad-hoc works perfectly with ipw3945.

(attached script, see above, works smoothly as it did with Gutsy).

Revision history for this message
Psy[H[] (vovik-wfa) wrote :

After recent update no error messages appear. Haven't tried real connection yet, but it seems working now (at least it does every command in my ad-hoc script without errors now)

Revision history for this message
Psy[H[] (vovik-wfa) wrote :

...nope. I was wrong.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.