# ipw3945 wireless drivers

## rmh3093

Since there is no thread about this I figured I would start one. Anyone that buys a notebook with the new Intel Centrino Core Duo will have an IPW3945 wireless card. Intel's site says drivers will be available Q1 2006. The sourceforge project the ipw3945 drivers was just registered at the beginning of the month. Here is a link to the sourceforge project for those that are interested:

http://sourceforge.net/projects/ipw3945/

----------

## moscwolf

i'm waiting also

if anyone needs more information or beta-tester - post it   :Laughing: 

i have some more problems on my inspiron, but most import is the wireless-connection.

(: 0c:00.0 Network controller: Intel Corporation Unknown device 4222 (rev 02)  :Smile: 

i have tried the way to patch the kernel to be able to work with 16k stacks and got the card activated while using ndiswrapper with the w39n51.inf from intel, but that was not totalay working - it only seems to be  :Wink: 

but the ap never get locked withe the card .. and it was very unstable and sometimes the maschine completly freezes - so i have paused testing that way  :Sad: 

here is lspci output, mabe needful   :Question: 

```

Gentoo linux # lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)

00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03)

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)

00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01)

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01)

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01)

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01)

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01)

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)

01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0098 (rev a1)

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832

03:01.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)

03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)

03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)

03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)

0c:00.0 Network controller: Intel Corporation Unknown device 4222 (rev 02)

```

----------

## VinzC

Eagerly waiting for the drivers too... I have a Dell Inspiron 9400 with an nVidia 7800 Go. Fortunately only WiFi and the SD card reader do not work.

----------

## trautenberg

Hey,

I have got the same problem with my wireless card on my Dell Inspiron 9400, which I got two weeks ago. I also tried to patch the kernel, but trying to insert the module gave me an error, that the ndiswrapper.ko is of invalid format. It was independent on whether or not the SMP was on. 

I haven't yet tried to make SD card reader to work. Moreover i have troubles with screen resolution and audio control. Unfortunately I have bought a crapy graphic card - Intel Media Accelerator 900 Graphics.  I cannot force it to work properly with xorg using VESA.  It stretches the display as its natural resolution is 1440x900 which is unreachable for me...   :Shocked:   Anyway, did somebody of you managed to get xorg with 1440x900 working, please post your xorg.conf?

The problem with sound I have seems to be general for all users of Intel HDA... When I plug in the headphones the sound is still coming also through the internal speakers of the laptop. This is really bad, if I want to listen to music while working at the office without annoying my colleges...   :Sad:   Has somebody solved this problem???

----------

## moscwolf

unfortunatly or not i have another grphic-card in my 9400, i choosed the 7800 go, which work fine with the nvidia-driver

for my audio i have choosen the way over alsa-driver ( type into /etc/make.conf "ALSA_CARDS="hda-intel" - emerge alsa-driver and execute alsaconf)

i got sound, but not from the subwoofer.   :Confused: 

----------

## VinzC

Please bear with the original poster. This thread should talk about Wireless NIC 3945 drivers and issues. For more general questions and support on the Dell Inspiron 9400, use the dedicated i9k4 thread instead.

----------

## VinzC

Hi people.

I've just created and tested my own ebuilds for ipw3945.

Preliminary notes

Intel Licences

The driver is a set of three packages from Intel: the driver module, the microcode and a regulatory daemon. Only the driver module is GPL'd. The other two are Intel-specific licenses. Hence the presence of two Intel licenses in the tarball. These licenses are provided with Intel's packages, which we can find at sourceforge.

My ebuilds do reference these licenses. Hence they must exist in /usr/portage/licenses before the ebuilds are used. They're included in the tarball and will therefore be extracted to the required directory.

Unofficial ebuilds

Since these are not official ebuilds they will be placed in a portage overlay directory. In my example I'll assume the portage overlay resides in /usr/local/portage/. See Gentoo Wiki on how to create and use third-party ebuilds with portage overlays.

Install Instructions

Download and extract the tarball from the above link:

```
# cd

wget http://www.teledisnet.be/web/vca08867/linux/ipw3945/ipw3945-ebuildset.tar.bz2

tar -xjvf ipw3945-ebuildset.tar.bz2 -C /
```

You will have a new portage overlay directory and two license files:

```
# ls -lR /usr/local/portage/net-wireless/

/usr/local/portage/net-wireless/:

total 0

drwxr-xr-x  3 root root 136 fév 25 19:06 ipw3945

drwxr-xr-x  3 root root 136 fév 26 12:43 ipw3945d

drwxr-xr-x  3 root root 144 fév 25 11:17 ipw3945-firmware

/usr/local/portage/net-wireless/ipw3945:

total 8

drwxr-xr-x  2 root root      88 fév 25 19:06 files

-rw-r--r--  1 root root    1971 fév 26 12:50 ipw3945-0.0.69.ebuild

-rw-rw-r--  1 root portage  132 fév 26 12:54 Manifest

/usr/local/portage/net-wireless/ipw3945/files:

total 4

-rw-rw-r--  1 root portage 63 fév 26 12:54 digest-ipw3945-0.0.69

/usr/local/portage/net-wireless/ipw3945d:

total 8

drwxr-xr-x  2 root root     88 fév 26 12:43 files

-rw-r--r--  1 root root    492 fév 26 13:39 ipw3945d-0.7.16.ebuild

-rw-rw-r--  1 root portage 133 fév 26 13:39 Manifest

/usr/local/portage/net-wireless/ipw3945d/files:

total 4

-rw-rw-r--  1 root portage 63 fév 26 13:39 digest-ipw3945d-0.7.16

/usr/local/portage/net-wireless/ipw3945-firmware:

total 8

drwxr-xr-x  2 root root     96 fév 25 11:17 files

-rw-r--r--  1 root root    605 fév 25 12:15 ipw3945-firmware-1.13.ebuild

-rw-rw-r--  1 root portage 145 fév 25 12:15 Manifest

/usr/local/portage/net-wireless/ipw3945-firmware/files:

total 4

-rw-rw-r--  1 root portage 66 fév 25 12:15 digest-ipw3945-firmware-1.13
```

```
# ls -l /usr/portage/licenses/ | egrep 'Intel-bin|ipw3945'

-rw-r--r--  1 root root   2109 fév 26 12:25 Intel-bin

-rwxr-xr-x  1 root root   2109 fév 25 10:56 ipw3945-fw
```

Now you can search portage for the new ebuilds:

```
# emerge -s ipw3945

Searching...

[ Results for search key : ipw3945 ]

[ Applications found : 3 ]

*  net-wireless/ipw3945 [ Masked ]

      Latest version available: 0.0.69

      Latest version installed: 0.0.69

      Size of downloaded files: 155 kB

      Homepage:    http://ipw3945.sourceforge.net

      Description: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux

      License:     GPL-2

*  net-wireless/ipw3945-firmware [ Masked ]

      Latest version available: 1.13

      Latest version installed: 1.13

      Size of downloaded files: 59 kB

      Homepage:    http://ipw3945.sourceforge.net

      Description: Microcode for the Intel PRO/Wireless 3945ABG Network Connection Adapter

      License:     ipw3945-fw

*  net-wireless/ipw3945d [ Masked ]

      Latest version available: 0.7.16

      Latest version installed: 0.7.16

      Size of downloaded files: 55 kB

      Homepage:    http://ipw3945.sourceforge.net

      Description: Intel PRO/Wireless 3945ABG Network Connection Regulatory Daemon

      License:     Intel-bin
```

Unmask them so that you can use them; you will also have to unmask ieee80211-1.1.11 and later since it is a dependency of Intel driver:

```
# grep net-wireless /etc/portage/package.keywords

>=net-wireless/ieee80211-1.1.11 ~x86

=net-wireless/ipw3945d-0.7.16 ~x86

net-wireless/ipw3945-firmware ~x86

net-wireless/ipw3945 ~x86
```

Note: if you are using a recent kernel you'll have to remove ieee802.11 built-in support. Do so by running the following command:

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

If you don't do that now portage will prompt you with an error message when you install ieee80211:

```
Your kernel source contains an incompatible version of the

ieee80211 subsystem, which needs to be removed before

ieee80211-1.1.12 can be installed. This can be accomplished by running:

  # /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux

Please note that this will make it impossible to use some of the

in-kernel IEEE 802.11 wireless LAN drivers (eg. orinoco).
```

Now emerge ipw3945. It will bring down or update packages ipw3945d, ipw3945-firmware and ieee80211:

```
# emerge -av ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild  N    ] net-wireless/ieee80211-1.1.12  -debug 65 kB

[ebuild  N    ] net-wireless/ipw3945-firmware-1.13  60 kB [1]

[ebuild  N    ] net-wireless/ipw3945d-0.7.16  56 kB [1]

[ebuild  N    ] net-wireless/ipw3945-0.0.69  156 kB [1]

Total size of downloads: 337 kB

Portage overlays:

 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No]
```

Post Installation Instructions

The regulatory daemon is responsible for lighting the LED and activating the wireless adapter. You must run it after you load the driver:

```
# modprobe ipw3945

# /sbin/ipw3945d # The wireless LED is put on, the card activated and the initscript launched
```

As I already had my /etc/conf.d/net configuration file prepared I didn't have anything to do - I copied my system from another laptop, a Dell Inspiron 6000, which I already had configured for wireless. Refer to Gentoo Wireless Guide otherwise.

Intel documentation says there is a way to automatically run the daemon while loading the driver.

 *Intel's ipw3945 Install wrote:*   

> 3.  AUTOMATIC DAEMON LOADING VIA MODPROBE
> 
> -----------------------------------------------
> 
> There are some typical steps that are fairly generic in order 
> ...

 

I appended the following lines to /etc/modules.d/ipw3945

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet

remove ipw3945  /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945
```

Loading the module automatically runs the daemon. Run modprobe -r ipw3945 to unload the deamon.

Using the RF-Kill switch only requires to restart /etc/init.d/net.eth1 when the wireless interface is back On. Another cool feature is that the WiFi led blinks rapidly while the interface is acquiring its IP address.

I tested the driver on my system and it's running fine ever since. Here are my main packages:Gentoo Sources 2.6.15-r5

udev-079-r1

baselayout-1.12.0_pre16-r3 (~x86)

bash-3.1_p14 or above (~x86)

netplug-1.2.9-r1 or aboveNote: baselayout 1.12 now requires bash >=3.1. And since netplug requires baselayout >=1.12... This has the main advantage not requiring any net script to be added to any runlevel again. baselayout 1.12.xx now attempts to start network init scripts as soon as the corresponding module is loaded.

How do I upgrade the driver?

To upgrade driver 0.0.69 to version 0.0.70 (released March 2nd):

```
cd /usr/local/portage/net-wireless/ipw3945

cp ipw3945-0.0.69.ebuild ipw3945-0.0.70.ebuild

ebuild ipw3945-0.0.70.ebuild digest

emerge -av ipw3945
```

Hope this will help. Comments welcome  :Cool:  .

Status

I've had to downgrade baselayout to version 1.11.14-r6 after I upgraded my system a couple of days ago. Note this implies adding net.eth1 to the default runlevel for it doesn't start automatically anymore once module ipw3945 is loaded - unlike 1.12.0xxx series .

Added the Driver upgrade section.

Upgraded again to baselayout 1.12 series and upgraded bash to 3.1.

----------

## rmh3093

i have not tried your e-build but I do have ipw3945 working with 2.6.16-rc4-mm2, thanks for beating me to ebuild, i will try it out!

/etc/modules.d/ipw3945

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet

remove ipw3945  /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945

```

^^^--- this works great by the way, i recommend it

----------

## VinzC

 *rmh3093 wrote:*   

> i have not tried your e-build but I do have ipw3945 working with 2.6.16-rc4-mm2, thanks for beating me to ebuild, i will try it out!

 

It was a real pleasure  :Wink:  . So Andrew Morton sources include built-in support for ipw3945?

/etc/modules.d/ipw3945

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet

remove ipw3945  /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945
```

I have tried it too. It works at least when loading the module while rmmod ipw3945 produces an error message saying the module is in use. But in turn the RF-Kill switch works without unloading the module. You just have to restart the init script when the wireless is enabled again.

----------

## rmh3093

 *VinzC wrote:*   

>  *rmh3093 wrote:*   i have not tried your e-build but I do have ipw3945 working with 2.6.16-rc4-mm2, thanks for beating me to ebuild, i will try it out! 
> 
> It was a real pleasure  . So Andrew Morton sources include built-in support for ipw3945?
> 
> /etc/modules.d/ipw3945
> ...

 

you have to remove the module with 'modprobe -r ipw3945"

and no -mm sources doesnt have support yet, i copied the source from ieee80211 and ipw3945 into the kernel and adjusted the Kconfig and Makefile so that I could compile it with the kernel, for some reason ieee80211 wont emerge on my system

----------

## echalon

I'm not sure why, but I had to create an init script to manually delete the /var/run/ipw3945d.pid file at shutdown or else it would not start up automatically with the automatic modprobe at boot.

Thanks for your work!

----------

## VinzC

 *echalon wrote:*   

> I'm not sure why, but I had to create an init script to manually delete the /var/run/ipw3945d.pid file at shutdown or else it would not start up automatically with the automatic modprobe at boot.

 

Wierd. You could perhaps use /etc/init.d/local.stop to wipe the file out after the driver is removed.

 *echalon wrote:*   

> Thanks for your work!

 

It's my very first, big contribution and I have submited three ebuilds to Gentoo Bugzilla. I'm glad I could help.

----------

## djtreble

Thanks for all your help VinzC, I'm slowly getting there with my 6400.

Has anyone got wpa working with this card?

I'm getting

 *Quote:*   

> 
> 
>  * Starting eth1
> 
>  *   Starting wpa_supplicant on eth1 ...
> ...

 

Using the ipw driver in /etc/conf.d/net

```
wpa_supplicant_eth1="-Dipw"
```

Also tried the "-Dext" driver, without any joy.

My driver is loaded, my demon is started and the led is flashing.

Any ideas? 

Thanks

Dan

----------

## VinzC

As per Intel requirements, use the latest version of wireless-tools - you might have to unmask it. You might have to use an unmasked version of wpa supplicant as well.

----------

## djtreble

Solved it, I was trying -Dext instead of -Dwext.

-Dwext works like a charm. Thank you.

P.S. There is a new version of the driver out  :Smile: 

----------

## AlexSuslov

Hi!

I can't connect by IPW3945ABG to wifi AP.

lspci 

03:00.0 Network controller: Intel Corporation Unknown device 4222 (rev 02)

I use my old working  wpa_supplicant.conf

But

wpa_supplicant -w -i eth2 -c /etc/wpa_supplicant.conf -Dwext

say only

ioctl[SIOCGIWSCAN]: Resource temporarily unavailable

what's the problem?

----------

## rmh3093

VinzC: I still haven't been able to try your ebuild since I cant emerge ieee80211 but I was poking around and notice that the default Makefile comments out support for monitor mode and qos support. It an easy tweak for people using the ebuild, maybe you wanted to include it as a use flag option or something.

Anyway, I hate using ebuilds for kernel drivers so I made a patch for the 2.6 kernel series which adds IPW3945 support. There are config options to add support for QoS and promiscuous mode.  :Smile: 

```
eth1      Available private ioctls :

          set_power        (8BE0) : set   1 int   & get   0

          get_power        (8BE1) : set   0       & get  80 char

          set_mode         (8BE2) : set   1 int   & get   0

          get_mode         (8BE3) : set   0       & get  80 char

          set_preamble     (8BE4) : set   1 int   & get   0

          get_preamble     (8BE5) : set   0       & get  16 char

          reset            (8BE7) : set   0 int   & get   0

          monitor          (8BE6) : set   2 int   & get   0

```

Here is the kernel patch: ipw3945-0.0.70.patch.bz2

* This patch applies cleanly against 2.6.15 and 2.6.16-rc5-mm2 so it should work with everything else. The IEEE80211 support in these kernels seems to be sufficient.

To apply this patch to your current kernel source:

```
cd /usr/src/linux

bzcat <path_to>/ipw3945-0.0.70.patch.bz2 | patch -p1

```

----------

## AlexSuslov

genkernel --menuconfig  all

some erors

In file included from drivers/net/wireless/ipw3945.c:68:

drivers/net/wireless/ipw3945.h:1991: error: field `action' has incomplete type

  CC [M]  drivers/usb/input/xpad.o

drivers/net/wireless/ipw3945.c: In function `ipw_add_power_capability':

drivers/net/wireless/ipw3945.c:3192: warning: implicit declaration of function `ieee80211_get_channel'

drivers/net/wireless/ipw3945.c:3192: warning: initialization makes pointer from integer without a cast

drivers/net/wireless/ipw3945.c: In function `ipw_add_supported_channels':

drivers/net/wireless/ipw3945.c:3222: warning: implicit declaration of function `ieee80211_get_channel_flags'

drivers/net/wireless/ipw3945.c: In function `ipw_best_network':

drivers/net/wireless/ipw3945.c:7090: error: `NETWORK_HAS_IBSS_DFS' undeclared (first use in this function)

drivers/net/wireless/ipw3945.c:7090: error: (Each undeclared identifier is reported only once

drivers/net/wireless/ipw3945.c:7090: error: for each function it appears in.)

drivers/net/wireless/ipw3945.c:7099: error: `NETWORK_HAS_POWER_CONSTRAINT' undeclared (first use in this function)

drivers/net/wireless/ipw3945.c:7108: error: `NETWORK_HAS_TPC_REPORT' undeclared (first use in this function)

drivers/net/wireless/ipw3945.c: In function `ipw_handle_reply_rx':

drivers/net/wireless/ipw3945.c:9820: error: unknown field `tsf' specified in initializer

drivers/net/wireless/ipw3945.c:9821: error: unknown field `beacon_time' specified in initializer

drivers/net/wireless/ipw3945.c:9821: warning: excess elements in struct initializer

drivers/net/wireless/ipw3945.c:9821: warning: (near initialization for `stats')

drivers/net/wireless/ipw3945.c: In function `ipw_build_tx_cmd_hwcrypto':

drivers/net/wireless/ipw3945.c:13227: error: too many arguments to function

drivers/net/wireless/ipw3945.c: In function `ipw_pci_probe':

drivers/net/wireless/ipw3945.c:14734: warning: assignment from incompatible pointer type

make[3]: *** [drivers/net/wireless/ipw3945.o] Error 1

make[2]: *** [drivers/net/wireless] Error 2

make[1]: *** [drivers/net] Error 2

----------

## AlexSuslov

iwpriv eth2

eth2      Available private ioctls :

          set_power        (8BE0) : set   1 int   & get   0

          get_power        (8BE1) : set   0       & get  80 char

          set_mode         (8BE2) : set   1 int   & get   0

          get_mode         (8BE3) : set   0       & get  80 char

          set_preamble     (8BE4) : set   1 int   & get   0

          get_preamble     (8BE5) : set   0       & get  16 char

          reset            (8BE7) : set   0 int   & get   0

----------

## VinzC

 *rmh3093 wrote:*   

> VinzC: I still haven't been able to try your ebuild since I cant emerge ieee80211 but I was poking around and notice that the default Makefile comments out support for monitor mode and qos support. It an easy tweak for people using the ebuild, maybe you wanted to include it as a use flag option or something.

 

I'm sorry, I'm not sure I understand everything  :Embarassed:  . What Makefile are you talking about? The Makefile for ebuild >=ieee80211-1.1.11?

 *rmh3093 wrote:*   

> Anyway, I hate using ebuilds for kernel drivers so I made a patch for the 2.6 kernel series which adds IPW3945 support. There are config options to add support for QoS and promiscuous mode. 
> 
> ```
> eth1      Available private ioctls :
> 
> ...

 

A big thanks indeed. Note you don't seem to have any problems compiling the driver while using the kernel built-in ieee80211 support. Is the kernel module of the latest version (>=1.1.11) - I mean does the built-in ieee80211 meet ipw3945 requirements? BTW how do you check a kernel module's version?

Also I suppose you adjusted ipw3945 source files to use the built-in ieee80211? When I compiled the module using the ebuild I first tried skipping the ieee80211 module to see if the kernel one was enough. Compillation failed as I saw there were references to the include branch in /usr/include (instead of the usual /usr/src/linux/include for kernel modules) so I suppose you fixed that too?

----------

## rmh3093

VinzC: when installing ieee80211, after i remove the old headers and then the ebuild extracts the source ,appllies the patches then just before it builds the ieee80211 modules the build fails and it complains about missing files. When i try to do the install manually (i extract the ieee80211 bz2 file to a tmp dir and run the install) after i type 'make' all the files in the working dir dissapear, i dont know where they go but that is what is keeping from using he ieee80211 outside of the kernel tree

----------

## djtreble

One out of three times the /sbin/ipw3945d --quiet fails to start, the module however loads fine.

I increased the sleep to 1.0, but that hasn't fixed it.

Is it just me?

----------

## rmh3093

 *djtreble wrote:*   

> One out of three times the /sbin/ipw3945d --quiet fails to start, the module however loads fine.
> 
> I increased the sleep to 1.0, but that hasn't fixed it.
> 
> Is it just me?

 

actually when I first started using this module I had no problems getting ipw3945d to start via the entry in /etc/modules.d/ipw3945 but now it never starts, when my computer is done booting I can see ipw3945 is loaded.... weird.... i dont know what chould be causing this one

----------

## rmh3093

for those having problems getting the ipw3945d started at boot using /etc/modules.d/ipw3945 I made an rc script to start and stop the daemon

/etc/init.d/ipw3945d

```
#!/sbin/runscript

depend() {

  need bootmisc localmount

  after modules coldplug hotplug

  before net

}

checkconfig() {

  if !(test -d /sys/bus/pci/drivers/ipw3945); then

    eerror "Could not find Intel PRO/Wireless 3945ABG Network Connection"

    eerror "Load the 'ipw3945' module"

    return 1

  fi

}

start() {

  checkconfig || return 1

  ebegin "Starting ipw3945d"

    /sbin/ipw3945d --quiet

  eend $? "Error loading ipw3945d"

}

stop() {

  ebegin "Stopping ipw3945d"

    /sbin/ipw3945d --kill

  eend $? "Error loading ipw3945d"

}

```

----------

## Jobbe

 *Quote:*   

> Hey,
> 
> am I missing something? When I try to emerge ipw3945, emerge fails to find the packages on the server. Any ideas?
> 
> Sorry if this is too obvious.
> ...

 

EDIT:

Now it works, I reinstalled the archive and ran emerge again.

Well, it doesn't work. gzip: stdin not in gzip format when trying to install ipw3945-ucode-1.13.tgz (apparently in ipw3945-firmware)Last edited by Jobbe on Wed Mar 08, 2006 2:29 pm; edited 2 times in total

----------

## djtreble

rmh3093: that inut script works like a charm, thank you.

I added 

```
before net
```

because it was trying to start after my net.eth1.

This script should go in the ebuild.

----------

## rmh3093

Ok people here are some new ebuilds for people to play with.... Thanks again VinzC for starting this project.

New

svn to make updates easier

requires in-kernel IEEE80211 subsystem

corrected paths so downloads dont fail

ditched the license

ipw3945d includes rc-script

useflags for QoS and RFmon

Setup

```
echo 'PORTDIR_OVERLAY="/usr/local/ipw3945_ebuilds $PORTDIR_OVERLAY"' >> /etc/make.conf

cd /usr/local

svn co http://opensvn.csie.org/rmh3093/ipw3945_ebuilds

```

Install

```
USE="monitor qos" emerge ipw3945
```

 *Quote:*   

> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> [ebuild  N    ] net-wireless/ipw3945d-0.7.16-r1  0 kB [1]
> ...

 

Post-Install

```
rc-update add ipw3945d boot
```

Kismet

Kismet dosen't support the ipw3945 yet but it does support the ipw2200 which uses radiotap, the same headers the ipw3945 for monitor mode so kistmet can be setup like this

 *Quote:*   

> source=ipw2200,eth1,ipw3945

 

----------

## djtreble

 *Quote:*   

> 
> 
> ```
> echo 'PORTDIR_OVERLAY="/usr/local/ipw3945_ebuilds $PORTDIR_OVERLAY"' > /etc/make.conf
> ```
> ...

 

That wants to be a >> .

*sob* why didn't I see that, why didn't I back up my make.conf!

That'll teach me for copying and pasting!

[EDIT] Thank god I made this post https://forums.gentoo.org/viewtopic-t-438454-highlight-.html all my make.conf in there! Phew!

----------

## rmh3093

 *djtreble wrote:*   

>  *Quote:*   
> 
> ```
> echo 'PORTDIR_OVERLAY="/usr/local/ipw3945_ebuilds $PORTDIR_OVERLAY"' > /etc/make.conf
> ```
> ...

 

OMG dude im sooooooo sorrry about that!! My fault, that should be...... thats what happens when I stay up all night playing with Gentoo.

----------

## Jobbe

I keep on getting this error:

```
 * Preparing ipw3945 module

mkdir -p /var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/tmp/.tmp_versions

cp /lib/modules/2.6.15-gentoo-r1jentoo/net/ieee80211/.tmp_versions/*.mod /var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/tmp/.tmp_versions

cp: Call by stat for ,,/lib/modules/2.6.15-gentoo-r1jentoo/net/ieee80211/.tmp_versions/*.mod" not possible: file or directory not found

make: [modules] error 1 (ignored)

make -C /lib/modules/2.6.15-gentoo-r1jentoo/build M=/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70 MODVERDIR=/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/tmp/.tmp_versions modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r1'

  CC [M]  /var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.o

In file included from /var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:68:

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.h:1991: error: field »action« has incomplete type

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_add_power_capability':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:3192: warning: implicit declaration of function »ieee80211_get_channel«

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:3192: warning: initialisation creates pointer of integer without type conversion

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_add_supported_channels':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:3222: warning: implicit declaration of function »ieee80211_get_channel_flags«

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_best_network':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:7090: error: »NETWORK_HAS_IBSS_DFS« not declared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:7090: error: (each undeclared variable is only listed once

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:7090: error: for each function it exists in) 

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:7099: error: »NETWORK_HAS_POWER_CONSTRAINT« not declared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:7108: error: »NETWORK_HAS_TPC_REPORT« not declared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_handle_reply_rx':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:9820: error:  unknown field »tsf« listed in initialisation

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:9821: error:  unknown fiel »beacon_time« listed in initialisation

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:9821: warning: element-error in struct initialisation

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:9821: warning: (next to initialisation of »stats«)

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_build_tx_cmd_hwcrypto':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:13227: error: too many arguments for function

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_pci_probe':

/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.c:14734: warning: incompatible pointer type

make[2]: *** [/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70/ipw3945.o] error 1

make[1]: *** [_module_/var/tmp/portage/ipw3945-0.0.70-r1/work/ipw3945-0.0.70] error 2

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r1'

make: *** [modules] error 2

!!! ERROR: net-wireless/ipw3945-0.0.70-r1 failed.

Call stack:

  ebuild.sh, line 1933:   Called dyn_compile

  ebuild.sh, line 971:   Called src_compile

  ipw3945-0.0.70-r1.ebuild, line 55:   Called linux-mod_src_compile

```

The actual error messages were German, I translated them. Thus, they might be pretty akward to you, but they should convey the point...

(Kernel) module ieee80211 is installed, I did an svn up before compiling, I don't know what's wrong. But as nobody else seems to have this problem I'm guessing it's got something to do with a missing ibrary or so? Might be completely wrong, though  :Very Happy: 

----------

## VinzC

@Jobbe:

Make sure you disabled built-in support for IEEE80211 in your kernel and have run

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

You also must install ieee80211-1.1.11 or later.

----------

## Jobbe

Oh I thought I had to build it into the kernel because of

 *rmh3093 wrote:*   

> 
> 
> [*]requires in-kernel IEEE80211 subsystem
> 
> 

 

I'll try disabling it.

EDIT: definately doesn't work:

```
 * Checking for suitable kernel configuration options:

 *   ipw3945-0.0.70 requires IEEE80211 support (CONFIG_IEEE80211).

```

plus loads of errors, mostly related to undeklared symbols (IEEE80211of course) etc...

Any ideas? Should I try compiling a more recent kernel? Mine is based on 2006.0 gentoo-sources, so 2.6 something..

EDIT: Uh, I just took a look at the project homepage on sourceforge and apparently you need 2.6.13 but I had 2.6.12.

 :Rolling Eyes: 

I'll emerge a newer version and try this later on....

----------

## VinzC

 *Jobbe wrote:*   

> EDIT: Uh, I just took a look at the project homepage on sourceforge and apparently you need 2.6.13 but I had 2.6.12.

 

Ah, sure... You should use the same (or later) package versions as we did. So if something goes wrong you know the packages you selected are not the source of the problem. Otherwise the conditions in which you are making your tests are different from the ones we met.

First get a recent kernel and even a masked (~x86). You can chose a masked Gentoo Source tree like I did (2.6.15-r5 or -r7 now).

Next there are two distinct ways to have ipw3945 working: either built-in using rmh3093's patch or using external ebuilds - which my howto is for. rmh3093's patch requires you to use built-in ieee80211 headers (hence you should use the most recent kernel, should it be unmasked).

With my set of ebuilds the kernel built-in headers for ieee80211 must be removed and replaced by the official ebuilds. Otherwise you will probably get errors about missing #defines or so. If you want to keep your 2.6.12 kernel, then you should consider the ebuild patchset instead.

Whether you chose the former or the latter way you must carefully meet the prerequisites we have posted.

----------

## Serph

Hi, I originally removed IEEE80211 from the kernel. How can I add it back in? I'd really like to try rmh3093's ebuilds.

Thanks!

----------

## Jobbe

It's in 'networking'.

VinzC thanks for your reply. I'll tell y'all later how I'm doing ^^

----------

## Jobbe

Allright, this is for rmh3093's ebuilds:

I can't get them to compile. I upgraded to the most recent gentoo-sources in portage I could find (2.6.15-r7), ieee80211 support is enabled (tried both in-kernel and as a module), still, ipw3945 will not compile, failing with the error messages I posted above.

I guess I'll try VinzC's aproach now...

EDIT:

Weehaa, it worked. Thanks for the work & help :]

----------

## djtreble

Just to add my 2c.

I couldn't get rmh3093's ebuild to work with my built in kernel headers even though vanilla linux-2.6.16-rc6 has version 1.1.17 of ieee80211 I _think_

The first error was an undeclared ieee80211_action structure, if I remember correctly.

I convinced myself that in kernel 1.1.17 wasn't new enough and went back to VinzC .70 ebuild with rmh3093's init script. This is working fine.

----------

## rmh3093

i think the error i was getting with IEEE80211 in portage had to do with -mm sources so in the next revision of the ebuild I will check your kernel version.... if you are using -mm sources it will use the inkernel ieee80211 if not it will ask for the version in portage... i bet this would fix your problems...... sorry guys for causing some problems, i cant use a non -mm kernel with out my system crashing

----------

## Jobbe

No need to be sorry at all  :Smile: 

I'd be happy to test your ebuild once it's updated.

----------

## VinzC

 *Serph wrote:*   

> Hi, I originally removed IEEE80211 from the kernel. How can I add it back in?

 

For now the only way I know is re-emerge your kernel sources.

----------

## Jobbe

After a bit of using the driver I'm really happy. It works, although almost every other time I have to do the modprobe/dhcp calls by hand. I have no idea why, possibly the driver is just a little immature. But even if I have to do this, it still works like a charm afterwards. Thanks for the help&work guys!

----------

## VinzC

Hmmm... strange. It doesn't happen on my system and I must admit I never had to restart the network connection in a week of daily usage.

Have you run the regulatory daemon? Have you also tuned the module configuration file to run the daemon as soon as the module is loaded?

----------

## Jobbe

Yeah that's what I did. It _is_strange especially considering that if I do the worx by hand there never is a problem. I have to unload the daemon (it's obviously started yet the module can't be loaded - weird) and then modprobe ipw3945 again.

----------

## VinzC

 *Jobbe wrote:*   

> Yeah that's what I did. It _is_strange especially considering that if I do the worx by hand there never is a problem. I have to unload the daemon (it's obviously started yet the module can't be loaded - weird) and then modprobe ipw3945 again.

 

Aha... so I think it is a configuration issue. If you can run the whole process manually and the driver works properly until the machine is powered off then what you experience is likely to be a configuration issue. First thing to check is baselayout version and wireless-tools package version that you have.

However I'm not sure I understand: it seems the deamon is active before the module is loaded, is that right? In that case I suspect you have an init script that launches the deamon before the network is active. On my machine there are enough services that start between pci coldplug and net.eth1 (apache, mysql plus other stuff that take time) hence the driver module can initialize quietly. It might be different on your machine.

----------

## Jobbe

Uh no I do the following:

modules.autoload.conf: ipw3945

...

...

...

runlevel default: net.eth1

The daemon is loaded by the module, I set it up the way you showed on the first page of this thread.

----------

## VinzC

Then I'm afraid I have no idea  :Sad: .

----------

## Jobbe

Yeah well it's not too annoying... 

Kinda weird though, I noticed that sometimes not even eth0 (e1000 intel adapter) is found and sometimes the system seems to confuse the both of them...

I don't know what's wrong, but it does work most of the time, so, I don't really care  :Wink: 

----------

## Sejam

 *VinzC wrote:*   

> 
> 
> Next there are two distinct ways to have ipw3945 working: either built-in using rmh3093's patch or using external ebuilds - which my howto is for. rmh3093's patch requires you to use built-in ieee80211 headers (hence you should use the most recent kernel, should it be unmasked).
> 
> 

 

How's it going VinzC, looks like we'll be working together again, my E1705 just showed up.

Anyways,  trying to follow the pure ebuild path, I could never get the ipw3945 to compile correctly.  This was attempted with many different configurations with kernels 2.6.15-gentoo-r1 and 2.6.16-gentoo.  Both of them I also tried with built in ieee80211 built in / modules and also trying with the ~x86 version of ieee80211.  Each time I tried again I rebuild the sources.  During the ebuild of ieee80211, I would remove the headers with the command above.

In the end, I ended up using the kernel patch on the 2.6.16-rc6-mm2 kernel.  I built the ipw3945 as modules and the ieee80211 into the kernel.  Just a note that I had the ieee80211 not emerged (I unmerged ieee80211 before emerging mm-sources).  Once that was done, I then used the ipw3945_ebuilds specified above.  Difference is, I only emerged ipw3945-firmware and ipw3945d (since the driver was built through the kernel patch, I did not need the ipw3945 ebuild).

With that configuration, I was able to get everything working great.  I haven't had it working long enough to test to make sure that the connection remains stable.  My Wireless LED does not stay on, but flashes with wireless activity (which I personally like a lot better anyways).

On a side note, the 2.6.16-rc6-mm2 does have some nice features added to it already, like the sd reader and a cpu scheduler just for multi-core systems.

----------

## rmh3093

 *Sejam wrote:*   

>  *VinzC wrote:*   
> 
> Next there are two distinct ways to have ipw3945 working: either built-in using rmh3093's patch or using external ebuilds - which my howto is for. rmh3093's patch requires you to use built-in ieee80211 headers (hence you should use the most recent kernel, should it be unmasked).
> 
>  
> ...

 

yay, someone else who will be using -mm sources with me

----------

## Sejam

For those of you that previously owned the Inspiron 6000 which had the Intel 2200, have you noticed a decrease in range with the 3945?  Didn't realize it last night, but I'm not able to get as good as a signal as I did with the 2200 in my house.

----------

## VinzC

 *Sejam wrote:*   

> How's it going VinzC, looks like we'll be working together again, my E1705 just showed up.

 

Oh great  :Smile:  . Glad you made up your mind. I was away a couple of days so couldn't answer immediately.

 *Sejam wrote:*   

> Anyways,  trying to follow the pure ebuild path, I could never get the ipw3945 to compile correctly.  This was attempted with many different configurations with kernels 2.6.15-gentoo-r1 and 2.6.16-gentoo.  Both of them I also tried with built in ieee80211 built in / modules and also trying with the ~x86 version of ieee80211.  Each time I tried again I rebuild the sources.  During the ebuild of ieee80211, I would remove the headers with the command above.

 

Aha. That is wierd. I'm going to check it out with a new kernel source tree, see if it happens too.

 *Sejam wrote:*   

> In the end, I ended up using the kernel patch on the 2.6.16-rc6-mm2 kernel.  I built the ipw3945 as modules and the ieee80211 into the kernel.  Just a note that I had the ieee80211 not emerged (I unmerged ieee80211 before emerging mm-sources).  Once that was done, I then used the ipw3945_ebuilds specified above.  Difference is, I only emerged ipw3945-firmware and ipw3945d (since the driver was built through the kernel patch, I did not need the ipw3945 ebuild).
> 
> With that configuration, I was able to get everything working great.  I haven't had it working long enough to test to make sure that the connection remains stable.  My Wireless LED does not stay on, but flashes with wireless activity (which I personally like a lot better anyways).
> 
> On a side note, the 2.6.16-rc6-mm2 does have some nice features added to it already, like the sd reader and a cpu scheduler just for multi-core systems.

 

If that works with that source tree I might as well try it too. Note my WiFi LED flashes sometimes only. It might vary from time to time but I can see it flash rapidly or slowlier. I don't know what it's depending on but there is a flashing description in the driver manual IIRC.

If the LED is flashing slowly and is off most of the flashing cycle then it is initializing the driver. When it flashes on/off with equal periods then the network script is starting.

----------

## VinzC

 *Sejam wrote:*   

> For those of you that previously owned the Inspiron 6000 which had the Intel 2200, have you noticed a decrease in range with the 3945?  Didn't realize it last night, but I'm not able to get as good as a signal as I did with the 2200 in my house.

 

No, I didn't. I'm using a Belkin 54g Access Point and the signal is excellent all the time. I'll check bigger distances. However I experienced my first WiFi disconnection at work last week. I had to unload/reload the driver module and things were back on. I'll watch it out.

----------

## Sejam

 *VinzC wrote:*   

>  *Sejam wrote:*   For those of you that previously owned the Inspiron 6000 which had the Intel 2200, have you noticed a decrease in range with the 3945?  Didn't realize it last night, but I'm not able to get as good as a signal as I did with the 2200 in my house. 
> 
> No, I didn't. I'm using a Belkin 54g Access Point and the signal is excellent all the time. I'll check bigger distances. However I experienced my first WiFi disconnection at work last week. I had to unload/reload the driver module and things were back on. I'll watch it out.

 

The distances was pretty far, I should mention.  I'm using the LinkSys Wireless G Wireless Access Point.  It's in the basement of our house and I'm in our bedroom which is on the second floor.  My wifes computer won't reach that high and neither will the E1705 too well (off and on), but the 6000 never had an issue up there.

----------

## VinzC

With my access point I can go up to the third floor and the signal is still good. The floors (traditional) are all made of wood, not of concrete. Belkin has a technology for passing through tough walls and floors made of concrete. You might consider it for your wife's computer  :Wink:  .

----------

## sprognak

Followed VinzC's instructions.

```
 modprobe ipw3495

FATAL: Module ipw3495 not found.
```

Everything appeared to work until the point I typed modprobe.  Is there something I should do between the emerge -av ipw3495 and the modprobe?[/quote][/code]

*edit* please feel free to suggest the obvious.  I've been playing with Gentoo for about 4 days now so am at a pretty novice level.  I figured the best way to learn was to dive right on in  :Smile: 

----------

## VinzC

 *sprognak wrote:*   

> Followed VinzC's instructions.
> 
> ```
>  modprobe ipw3495
> 
> ...

 

Did you get any error message while compiling ipw3945? Did you recently upgrade your kernel sources? What's your current kernel (run uname -r)? Have you removed your kernel's bult-in support for ieee80211 by running shell script /usr/portage/net-wireless/ieee80211/files/remove-old?

You must reinstall the driver each time you install a new kernel source tree, for instance. module-rebuild list and module-rebuild rebuild does help you know what modules need to be reinstalled.

----------

## moumou

Version 0.0.73 is out ! I would have updated the svn, but I don't know how to do it :/

I also found why the ebuilds wouldn't work with ieee80211 from portage. It's because it doesn't find the ieee80211.h in /lib/modules/`uname -r`/include. In fact they are in /usr/include. I just added IEEE80211_INCLUDEDIR=/usr/include (if I remember clearly) to the ebuild, in front of the function that compiles the module, and it worked flawlessly  :Smile: 

----------

## sprognak

 *VinzC wrote:*   

>  *sprognak wrote:*   Followed VinzC's instructions.
> 
> ```
>  modprobe ipw3495
> 
> ...

 

No error when compiling, a few warnings.  Is there a way I can force a recompile so I can post a dump?

It's a fresh install of 2.6.15-gentoo-r5 from the LiveCD.  I've removed ieee80211 with the script, followed your post down to the modprobe.  I've triped a emerge --sync and emerge --update --deep world

Here's the result from module-rebuild:

```
gloin ~ # module-rebuild list

** Packages which I will emerge are:

        =net-wireless/ipw3945-0.0.69

        =net-wireless/ieee80211-1.1.13

gloin ~ # emerge ipw3495

Calculating dependencies

emerge: there are no ebuilds to satisfy "ipw3495".

gloin ~ # module-rebuild rebuild

** Preparing to merge modules:

** Packages which I will emerge are:

        =net-wireless/ipw3945-0.0.69

        =net-wireless/ieee80211-1.1.13

5 4 3 2 1

Calculating dependencies

emerge: there are no ebuilds to satisfy "=net-wireless/ipw3945-0.0.69".

gloin ~ #
```

I'm guessing that means I still have something to do, but I'm not quite sure what...

----------

## sprognak

Just tried following the steps again from the start yet now I get:

```
gloin ipw3945 # /usr/portage/net-wireless/ieee80211/files/remove-old

bash: /usr/portage/net-wireless/ieee80211/files/remove-old: Permission denied

gloin ipw3945 #
```

Is this because it's gone already or did I break something?

And this may help diagnosing:

```
gloin downloads # slocate ipw3945

/var/db/pkg/net-wireless/ipw3945-firmware-1.13

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/ipw3945-firmware-1.13.ebuild

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/ASFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CATEGORY

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CBUILD

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CC

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CHOST

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CTARGET

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CXX

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CXXFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/DEPEND

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/EXTRA_ECONF

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/EXTRA_EINSTALL

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/EXTRA_MAKE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/FEATURES

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/INHERITED

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/IUSE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/PKGUSE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/LDFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/LIBCFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/LIBCXXFLAGS

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/LICENSE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/PDEPEND

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/PF

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/PROVIDE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/RDEPEND

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/RESTRICT

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/SLOT

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/USE

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/EAPI

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/NEEDED

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/environment.bz2

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/COUNTER

/var/db/pkg/net-wireless/ipw3945-firmware-1.13/CONTENTS

/var/db/pkg/net-wireless/ipw3945d-0.7.16

/var/db/pkg/net-wireless/ipw3945d-0.7.16/ipw3945d-0.7.16.ebuild

/var/db/pkg/net-wireless/ipw3945d-0.7.16/ASFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CATEGORY

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CBUILD

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CC

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CHOST

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CTARGET

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CXX

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CXXFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/DEPEND

/var/db/pkg/net-wireless/ipw3945d-0.7.16/EXTRA_ECONF

/var/db/pkg/net-wireless/ipw3945d-0.7.16/EXTRA_EINSTALL

/var/db/pkg/net-wireless/ipw3945d-0.7.16/EXTRA_MAKE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/FEATURES

/var/db/pkg/net-wireless/ipw3945d-0.7.16/INHERITED

/var/db/pkg/net-wireless/ipw3945d-0.7.16/IUSE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/PKGUSE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/LDFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/LIBCFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/LIBCXXFLAGS

/var/db/pkg/net-wireless/ipw3945d-0.7.16/LICENSE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/PDEPEND

/var/db/pkg/net-wireless/ipw3945d-0.7.16/PF

/var/db/pkg/net-wireless/ipw3945d-0.7.16/PROVIDE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/RDEPEND

/var/db/pkg/net-wireless/ipw3945d-0.7.16/RESTRICT

/var/db/pkg/net-wireless/ipw3945d-0.7.16/SLOT

/var/db/pkg/net-wireless/ipw3945d-0.7.16/USE

/var/db/pkg/net-wireless/ipw3945d-0.7.16/EAPI

/var/db/pkg/net-wireless/ipw3945d-0.7.16/NEEDED

/var/db/pkg/net-wireless/ipw3945d-0.7.16/environment.bz2

/var/db/pkg/net-wireless/ipw3945d-0.7.16/COUNTER

/var/db/pkg/net-wireless/ipw3945d-0.7.16/CONTENTS

/var/db/pkg/net-wireless/ipw3945-0.0.69

/var/db/pkg/net-wireless/ipw3945-0.0.69/ipw3945-0.0.69.ebuild

/var/db/pkg/net-wireless/ipw3945-0.0.69/ASFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/CATEGORY

/var/db/pkg/net-wireless/ipw3945-0.0.69/CBUILD

/var/db/pkg/net-wireless/ipw3945-0.0.69/CC

/var/db/pkg/net-wireless/ipw3945-0.0.69/CFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/CHOST

/var/db/pkg/net-wireless/ipw3945-0.0.69/CTARGET

/var/db/pkg/net-wireless/ipw3945-0.0.69/CXX

/var/db/pkg/net-wireless/ipw3945-0.0.69/CXXFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/DEPEND

/var/db/pkg/net-wireless/ipw3945-0.0.69/EXTRA_ECONF

/var/db/pkg/net-wireless/ipw3945-0.0.69/EXTRA_EINSTALL

/var/db/pkg/net-wireless/ipw3945-0.0.69/EXTRA_MAKE

/var/db/pkg/net-wireless/ipw3945-0.0.69/FEATURES

/var/db/pkg/net-wireless/ipw3945-0.0.69/INHERITED

/var/db/pkg/net-wireless/ipw3945-0.0.69/IUSE

/var/db/pkg/net-wireless/ipw3945-0.0.69/PKGUSE

/var/db/pkg/net-wireless/ipw3945-0.0.69/LDFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/LIBCFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/LIBCXXFLAGS

/var/db/pkg/net-wireless/ipw3945-0.0.69/LICENSE

/var/db/pkg/net-wireless/ipw3945-0.0.69/PDEPEND

/var/db/pkg/net-wireless/ipw3945-0.0.69/PF

/var/db/pkg/net-wireless/ipw3945-0.0.69/PROVIDE

/var/db/pkg/net-wireless/ipw3945-0.0.69/RDEPEND

/var/db/pkg/net-wireless/ipw3945-0.0.69/RESTRICT

/var/db/pkg/net-wireless/ipw3945-0.0.69/SLOT

/var/db/pkg/net-wireless/ipw3945-0.0.69/USE

/var/db/pkg/net-wireless/ipw3945-0.0.69/EAPI

/var/db/pkg/net-wireless/ipw3945-0.0.69/NEEDED

/var/db/pkg/net-wireless/ipw3945-0.0.69/environment.bz2

/var/db/pkg/net-wireless/ipw3945-0.0.69/COUNTER

/var/db/pkg/net-wireless/ipw3945-0.0.69/CONTENTS

/var/cache/edb/dep/usr/local/portage/net-wireless/ipw3945-0.0.70

/usr/share/doc/ipw3945d-0.7.16

/usr/share/doc/ipw3945d-0.7.16/README.ipw3945d.gz

/usr/share/doc/ipw3945-0.0.69

/usr/share/doc/ipw3945-0.0.69/README.ipw3945.gz

/usr/share/doc/ipw3945-0.0.69/CHANGES.gz

/usr/share/doc/ipw3945-0.0.69/ISSUES.gz

/usr/local/portage/net-wireless/ipw3945d

/usr/local/portage/net-wireless/ipw3945d/ipw3945d-0.7.16.ebuild

/usr/local/portage/net-wireless/ipw3945d/Manifest

/usr/local/portage/net-wireless/ipw3945d/files

/usr/local/portage/net-wireless/ipw3945d/files/digest-ipw3945d-0.7.16

/usr/local/portage/net-wireless/ipw3945-firmware

/usr/local/portage/net-wireless/ipw3945-firmware/Manifest

/usr/local/portage/net-wireless/ipw3945-firmware/files

/usr/local/portage/net-wireless/ipw3945-firmware/files/digest-ipw3945-firmware-1.13

/usr/local/portage/net-wireless/ipw3945-firmware/ipw3945-firmware-1.13.ebuild

/usr/local/portage/net-wireless/ipw3945

/usr/local/portage/net-wireless/ipw3945/Manifest

/usr/local/portage/net-wireless/ipw3945/files

/usr/local/portage/net-wireless/ipw3945/files/digest-ipw3945-0.0.69

/usr/local/portage/net-wireless/ipw3945/files/digest-ipw3945-0.0.70

/usr/local/portage/net-wireless/ipw3945/ipw3945-0.0.69.ebuild

/usr/local/portage/net-wireless/ipw3945/ipw3945-0.0.70.ebuild

/usr/portage/distfiles/ipw3945-ucode-1.13.tgz

/usr/portage/distfiles/ipw3945d-0.7.16.tgz

/usr/portage/distfiles/ipw3945-0.0.69.tgz

/usr/portage/distfiles/ipw3945-0.0.70.tgz

/usr/src/linux-2.6.15-gentoo-r1/drivers/net/wireless/ipw3945.c

/usr/src/linux-2.6.15-gentoo-r1/drivers/net/wireless/ipw3945.h

/usr/src/linux-2.6.15-gentoo-r1/drivers/net/wireless/ipw3945_daemon.h

/usr/src/linux-2.6.15-gentoo-r1/drivers/net/wireless/Kconfig.ipw3945

/usr/src/linux-2.6.15-gentoo-r1/ipw3945-ebuildset.tar.bz2

/etc/modules.d/ipw3945

/lib/firmware/ipw3945.ucode

/lib/firmware/ipw3945-1.13-LICENSE

/lib/modules/2.6.15-gentoo-r1/net/wireless/ipw3945.ko

/sbin/ipw3945d

/root/downloads/ipw3945-ucode-1.13.gz

/root/downloads/ipw3945d-1.7.18.gz

/root/downloads/ipw3945-0.0.71.tar

/root/downloads/ipw3945-0.0.71

/root/downloads/ipw3945-0.0.71/load

/root/downloads/ipw3945-0.0.71/Makefile

/root/downloads/ipw3945-0.0.71/ISSUES

/root/downloads/ipw3945-0.0.71/FILES

/root/downloads/ipw3945-0.0.71/LICENSE

/root/downloads/ipw3945-0.0.71/dvals

/root/downloads/ipw3945-0.0.71/sim_rx.c

/root/downloads/ipw3945-0.0.71/remove-old

/root/downloads/ipw3945-0.0.71/ipw3945_daemon.h

/root/downloads/ipw3945-0.0.71/config

/root/downloads/ipw3945-0.0.71/LICENSE.BSD

/root/downloads/ipw3945-0.0.71/LICENSE.GPL

/root/downloads/ipw3945-0.0.71/GIT_SHA1

/root/downloads/ipw3945-0.0.71/status

/root/downloads/ipw3945-0.0.71/unload

/root/downloads/ipw3945-0.0.71/INSTALL

/root/downloads/ipw3945-0.0.71/CHANGES

/root/downloads/ipw3945-0.0.71/in-tree

/root/downloads/ipw3945-0.0.71/in-tree/Kconfig.ipw3945

/root/downloads/ipw3945-0.0.71/ipw3945.c

/root/downloads/ipw3945-0.0.71/ipw3945.h

/root/downloads/ipw3945-0.0.71/README.ipw3945

/root/downloads/ipw3945-0.0.70.patch.bz2

/root/usr/local/portage/net-wireless/ipw3945d

/root/usr/local/portage/net-wireless/ipw3945d/ipw3945d-0.7.16.ebuild

/root/usr/local/portage/net-wireless/ipw3945d/Manifest

/root/usr/local/portage/net-wireless/ipw3945d/files

/root/usr/local/portage/net-wireless/ipw3945d/files/digest-ipw3945d-0.7.16

/root/usr/local/portage/net-wireless/ipw3945-firmware

/root/usr/local/portage/net-wireless/ipw3945-firmware/Manifest

/root/usr/local/portage/net-wireless/ipw3945-firmware/files

/root/usr/local/portage/net-wireless/ipw3945-firmware/files/digest-ipw3945-firmware-1.13

/root/usr/local/portage/net-wireless/ipw3945-firmware/ipw3945-firmware-1.13.ebuild

/root/usr/local/portage/net-wireless/ipw3945

/root/usr/local/portage/net-wireless/ipw3945/Manifest

/root/usr/local/portage/net-wireless/ipw3945/files

/root/usr/local/portage/net-wireless/ipw3945/files/digest-ipw3945-0.0.69

/root/usr/local/portage/net-wireless/ipw3945/ipw3945-0.0.69.ebuild

/root/usr/portage/licenses/ipw3945-fw

/root/ipw3945-ebuildset.tar.bz2
```

----------

## moumou

 *sprognak wrote:*   

> Just tried following the steps again from the start yet now I get:
> 
> ```
> gloin ipw3945 # /usr/portage/net-wireless/ieee80211/files/remove-old
> 
> ...

 

The remove-old script is not chmod-ed +x, you need to run

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

----------

## sprognak

Run the script, no change.

Tried a genkernel --menuconfig all and selected ieee.....

Ran the remove script again, it removed it.

Still no change on modprobe and I am no longer able to emerge -av ipw3945.

Redownloaded the bz2 file as VinC says at the start and unzipped to back to the areas.  Run an emerge --regen and tried to search for (emerge -s) ipw3945 - nothing found....

It's vanished!!!

----------

## nemectic

My only net access is wireless, so I can't connect to the net from gentoo to get these drivers, is there a way I can copy them to cd and then just make them in gentoo?

H

----------

## sprognak

 *rmh3093 wrote:*   

> Ok people here are some new ebuilds for people to play with.... Thanks again VinzC for starting this project.
> 
> New
> 
> svn to make updates easier
> ...

 

Just tried this method on a brand new livecd 2006.0 install of Gentoo.  I have emerge --sync'ed, emerge gentoo-source and then followed the aboves.  On the emerge - this is what happened...

```
gloin local # USE="monitor qos" emerge ipw3945

Calculating dependencies ...done!

>>> emerge (1 of 3) net-wireless/ipw3945d-0.7.16-r1 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/ipw3945d-0.7.16.tgz

--21:13:55--  http://distfiles.gentoo.org/distfiles/ipw3945d-0.7.16.tgz

           => `/usr/portage/distfiles/ipw3945d-0.7.16.tgz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:13:55 ERROR 404: Not Found.

>>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945d-0.7.16.tgz

--21:13:55--  http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945d-0.7.16.tgz

           => `/usr/portage/distfiles/ipw3945d-0.7.16.tgz'

Resolving distro.ibiblio.org... 152.2.210.109

Connecting to distro.ibiblio.org|152.2.210.109|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:14:01 ERROR 404: Not Found.

>>> Downloading http://bughost.org/ipw3945/ipw3945d-0.7.16.tgz

--21:14:01--  http://bughost.org/ipw3945/ipw3945d-0.7.16.tgz

           => `/usr/portage/distfiles/ipw3945d-0.7.16.tgz'

Resolving bughost.org... 198.76.39.147

Connecting to bughost.org|198.76.39.147|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 57,270 (56K) [application/x-gzip]

100%[===================================>] 57,270        78.95K/s

21:14:03 (78.69 KB/s) - `/usr/portage/distfiles/ipw3945d-0.7.16.tgz' saved [57270/57270]

>>> md5 files   ;-) ipw3945d-0.7.16-r1.ebuild

>>> md5 files   ;-) files/ipw3945d

>>> md5 files   ;-) files/digest-ipw3945d-0.7.16-r1

>>> md5 files   ;-) files/digest-ipw3945d-0.7.16

>>> md5 src_uri ;-) ipw3945d-0.7.16.tgz

>>> Unpacking source...

>>> Unpacking ipw3945d-0.7.16.tgz to /var/tmp/portage/ipw3945d-0.7.16-r1/work

>>> Source unpacked.

>>> Test phase [not enabled]: net-wireless/ipw3945d-0.7.16-r1

>>> Install ipw3945d-0.7.16-r1 into /var/tmp/portage/ipw3945d-0.7.16-r1/image/ category net-wireless

man:

prepallstrip:

strip: i686-pc-linux-gnu-strip --strip-unneeded

   sbin/ipw3945d

>>> Completed installing ipw3945d-0.7.16-r1 into /var/tmp/portage/ipw3945d-0.7.16-r1/image/

>>> Merging net-wireless/ipw3945d-0.7.16-r1 to /

--- /sbin/

>>> /sbin/ipw3945d

--- /usr/

--- /usr/share/

--- /usr/share/doc/

>>> /usr/share/doc/ipw3945d-0.7.16-r1/

>>> /usr/share/doc/ipw3945d-0.7.16-r1/README.ipw3945d.gz

--- /etc/

--- /etc/init.d/

>>> /etc/init.d/ipw3945d

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ipw3945d-0.7.16-r1 merged.

>>> clean: No packages selected for removal.

>>> emerge (2 of 3) net-wireless/ipw3945-firmware-1.13-r1 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/ipw3945-ucode-1.13.tgz

--21:14:08--  http://distfiles.gentoo.org/distfiles/ipw3945-ucode-1.13.tgz

           => `/usr/portage/distfiles/ipw3945-ucode-1.13.tgz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:14:08 ERROR 404: Not Found.

>>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-ucode-1.13.tgz

--21:14:08--  http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-ucode-1.13.tgz

           => `/usr/portage/distfiles/ipw3945-ucode-1.13.tgz'

Resolving distro.ibiblio.org... 152.2.210.109

Connecting to distro.ibiblio.org|152.2.210.109|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:14:09 ERROR 404: Not Found.

>>> Downloading http://bughost.org/ipw3945/ipw3945-ucode-1.13.tgz

--21:14:09--  http://bughost.org/ipw3945/ipw3945-ucode-1.13.tgz

           => `/usr/portage/distfiles/ipw3945-ucode-1.13.tgz'

Resolving bughost.org... 198.76.39.147

Connecting to bughost.org|198.76.39.147|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 61,175 (60K) [application/x-gzip]

100%[===================================>] 61,175        96.87K/s

21:14:10 (96.67 KB/s) - `/usr/portage/distfiles/ipw3945-ucode-1.13.tgz' saved [61175/61175]

>>> md5 files   ;-) ipw3945-firmware-1.13-r1.ebuild

>>> md5 files   ;-) files/digest-ipw3945-firmware-1.13-r1

>>> md5 files   ;-) files/digest-ipw3945-firmware-1.13

>>> md5 src_uri ;-) ipw3945-ucode-1.13.tgz

>>> Unpacking source...

>>> Unpacking ipw3945-ucode-1.13.tgz to /var/tmp/portage/ipw3945-firmware-1.13-r1/work

>>> Source unpacked.

>>> Test phase [not enabled]: net-wireless/ipw3945-firmware-1.13-r1

>>> Install ipw3945-firmware-1.13-r1 into /var/tmp/portage/ipw3945-firmware-1.13-r1/image/ category net-wireless

man:

prepallstrip:

>>> Completed installing ipw3945-firmware-1.13-r1 into /var/tmp/portage/ipw3945-firmware-1.13-r1/image/

>>> Merging net-wireless/ipw3945-firmware-1.13-r1 to /

--- /lib/

>>> /lib/firmware/

>>> /lib/firmware/ipw3945.ucode

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ipw3945-firmware-1.13-r1 merged.

>>> clean: No packages selected for removal.

>>> emerge (3 of 3) net-wireless/ipw3945-0.0.70-r2 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/ipw3945-0.0.70.tgz

--21:14:14--  http://distfiles.gentoo.org/distfiles/ipw3945-0.0.70.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.70.tgz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:14:15 ERROR 404: Not Found.

>>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-0.0.70.tgz

--21:14:15--  http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-0.0.70.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.70.tgz'

Resolving distro.ibiblio.org... 152.2.210.109

Connecting to distro.ibiblio.org|152.2.210.109|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

21:14:16 ERROR 404: Not Found.

>>> Downloading http://easynews.dl.sourceforge.net/sourceforge/ipw3945/ipw3945-0.0.70.tgz

--21:14:16--  http://easynews.dl.sourceforge.net/sourceforge/ipw3945/ipw3945-0.0.70.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.70.tgz'

Resolving easynews.dl.sourceforge.net... 69.16.168.245

Connecting to easynews.dl.sourceforge.net|69.16.168.245|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 159,106 (155K) [application/x-tar]

100%[===================================>] 159,106       92.09K/s

21:14:18 (91.87 KB/s) - `/usr/portage/distfiles/ipw3945-0.0.70.tgz' saved [159106/159106]

>>> md5 files   ;-) ipw3945-0.0.70-r2.ebuild

>>> md5 files   ;-) files/enable-monitor_mode.patch

>>> md5 files   ;-) files/remove-check_inc.patch

>>> md5 files   ;-) files/digest-ipw3945-0.0.70

>>> md5 files   ;-) files/digest-ipw3945-0.0.70-r1

>>> md5 files   ;-) files/digest-ipw3945-0.0.70-r2

>>> md5 files   ;-) files/ipw3945-0.0.70-associate_timeout.patch

>>> md5 files   ;-) files/enable-qos.patch

>>> md5 src_uri ;-) ipw3945-0.0.70.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Could not find a usable .config in the kernel source directory.

 * Please ensure that /usr/src/linux points to a configured set of Linux sources.

 * If you are using KBUILD_OUTPUT, please set the environment var so that

 * it points to the necessary object directory so that it might find .config.

!!! ERROR: net-wireless/ipw3945-0.0.70-r2 failed.

!!! Function linux-info_pkg_setup, Line 537, Exitcode 1

!!! Unable to calculate Linux Kernel version

!!! If you need support, post the topmost build error, NOT this status message.
```

----------

## sprognak

Update:

1.Just cd'ed to /usr/src/linux and ran make menuconfig

added ieee802.11 support under networking

and under device drivers - network device - non hamradio

then exited and saved the config

2.  make oldconfig

3.  make modules_prepare

Now I get:

```

 ERROR: ieee80211.h not found in '/lib/modules/2.6.15-gentoo-r5/include'.

 You need to install the ieee80211 subsystem from http://ieee80211.sf.net

 and point this build to the location where you installed those sources, eg.:

 % make IEEE80211_INC=/usr/src/ieee80211/

 will look for ieee80211.h in /usr/src/ieee80211/net/

make: *** [check_inc] Error 1

!!! ERROR: net-wireless/ipw3945-0.0.70-r2 failed.

!!! Function linux-mod_src_compile, Line 509, Exitcode 2

!!! Unable to make                                   all.

!!! If you need support, post the topmost build error, NOT this status message.
```

----------

## VinzC

 *moumou wrote:*   

> Version 0.0.73 is out ! I would have updated the svn, but I don't know how to do it :/
> 
> I also found why the ebuilds wouldn't work with ieee80211 from portage. It's because it doesn't find the ieee80211.h in /lib/modules/`uname -r`/include. In fact they are in /usr/include. I just added IEEE80211_INCLUDEDIR=/usr/include (if I remember clearly) to the ebuild, in front of the function that compiles the module, and it worked flawlessly 

 

Ah, that's interresting: do you mean you can now use kernel built-in ieee80211 drivers and not the ones from portage anymore? Could you please post your modified ebuild so I can update mine accordingly?

Thanks a lot for the info.

----------

## VinzC

 *nemectic wrote:*   

> My only net access is wireless, so I can't connect to the net from gentoo to get these drivers, is there a way I can copy them to cd and then just make them in gentoo?

 

Do you have a USB data storage key? If not you can download my ebuild set and the tarballs from sourceforge then burn them on a CDROM. The tarballs must go into /usr/portage/distfiles. Then extract the ebuild into their overlay directory.

----------

## sprognak

Following rmh's ebuild, I get:

```
 * Preparing ipw3945 module

 ERROR: ieee80211.h not found in '/lib/modules/2.6.15-gentoo-r7/include'.

 You need to install the ieee80211 subsystem from http://ieee80211.sf.net

 and point this build to the location where you installed those sources, eg.:

 % make IEEE80211_INC=/usr/src/ieee80211/

 will look for ieee80211.h in /usr/src/ieee80211/net/

make: *** [check_inc] Error 1

!!! ERROR: net-wireless/ipw3945-0.0.70-r2 failed.

!!! Function linux-mod_src_compile, Line 509, Exitcode 2

!!! Unable to make                                   all.

!!! If you need support, post the topmost build error, NOT this status message.
```

locate ieee80211.h shows the file in 

```
/usr/src/linux-2.6.15-gentoo-r7/include/net/ieee80211.h

/usr/src/linux-2.6.15-gentoo-r7/include/config/ieee80211.h
```

I am using kernel 2.6.15-r7 now which I installed yesterday with the ieee80211 stuff.

If I symlink /usr/src/linux-2.6.15-gentoo/r7/include to /lib/modules/2.6.15-gentoo-r7/include it starts to work then bombs out with this:

```
gloin downloads # USE="monitor qos" emerge -v ipw3945

Calculating dependencies ...done!

>>> emerge (1 of 1) net-wireless/ipw3945-0.0.70-r2 to /

>>> md5 files   ;-) ipw3945-0.0.70-r2.ebuild

>>> md5 files   ;-) files/enable-monitor_mode.patch

>>> md5 files   ;-) files/remove-check_inc.patch

>>> md5 files   ;-) files/digest-ipw3945-0.0.70

>>> md5 files   ;-) files/digest-ipw3945-0.0.70-r1

>>> md5 files   ;-) files/digest-ipw3945-0.0.70-r2

>>> md5 files   ;-) files/ipw3945-0.0.70-associate_timeout.patch

>>> md5 files   ;-) files/enable-qos.patch

>>> md5 src_uri ;-) ipw3945-0.0.70.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.15-gentoo-r7

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ipw3945-0.0.70.tgz to /var/tmp/portage/ipw3945-0.0.70-r2/work

 * Applying enable-qos.patch ...                                          [ ok ] * Applying enable-monitor_mode.patch ...                                 [ ok ]>>> Source unpacked.

 * Preparing ipw3945 module

mkdir -p /var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/tmp/.tmp_versions

cp /lib/modules/2.6.15-gentoo-r7/net/ieee80211/.tmp_versions/*.mod /var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/tmp/.tmp_versions

cp: cannot stat `/lib/modules/2.6.15-gentoo-r7/net/ieee80211/.tmp_versions/*.mod': No such file or directory

make: [modules] Error 1 (ignored)

make -C /lib/modules/2.6.15-gentoo-r7/build M=/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70 MODVERDIR=/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/tmp/.tmp_versions modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'

  CC [M]  /var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.o

In file included from /var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:68:

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.h:1991: error: field `action' has incomplete type

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_add_power_capability':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:3192: warning: implicit declaration of function `ieee80211_get_channel'

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:3192: warning: initialization makes pointer from integer without a cast

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_add_supported_channels':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:3222: warning: implicit declaration of function `ieee80211_get_channel_flags'

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_best_network':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:7090: error: `NETWORK_HAS_IBSS_DFS' undeclared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:7090: error: (Each undeclared identifier is reported only once

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:7090: error: for each function it appears in.)

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:7099: error: `NETWORK_HAS_POWER_CONSTRAINT' undeclared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:7108: error: `NETWORK_HAS_TPC_REPORT' undeclared (first use in this function)

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_handle_reply_rx':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:9820: error: unknown field `tsf' specified in initializer

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:9821: error: unknown field `beacon_time' specified in initializer

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:9821: warning: excess elements in struct initializer

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:9821: warning: (near initialization for `stats')

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_build_tx_cmd_hwcrypto':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:13227: error: too many arguments to function

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c: In function `ipw_pci_probe':

/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.c:14734: warning: assignment from incompatible pointer type

make[2]: *** [/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70/ipw3945.o] Error 1

make[1]: *** [_module_/var/tmp/portage/ipw3945-0.0.70-r2/work/ipw3945-0.0.70] Error 2

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'

make: *** [modules] Error 2

!!! ERROR: net-wireless/ipw3945-0.0.70-r2 failed.

!!! Function linux-mod_src_compile, Line 509, Exitcode 2

!!! Unable to make                                   all.

!!! If you need support, post the topmost build error, NOT this status message
```

I've now been banging away at this for some time.  If anyone has any advice please let me know.  I'm sure it's something simple....

----------

## VinzC

@sprognak:

I suggest you wiped out your current kernel tree (of course booting from a previous one that worked) and redo all the steps I mentionned to the letter. I'm sure something was messed up in the way. If you follow my howto to the letter no extra steps are required and if you have the slightest little error message again, please post.

So boot up with a previously working kernel, unmerge your latest kernel tree and rm -r it to be sure. Then emerge it again and follow the howto. I've done the same steps with Gentoo Sources 2.6.15-r7 and it worked like a charm.

Note: /usr/src/linux must point to the kernel tree you are compiling against. You'll also be required to compile it once before you can add ipw3945 drivers.

----------

## nemectic

 *Quote:*   

> Do you have a USB data storage key? If not you can download my ebuild set and the tarballs from sourceforge then burn them on a CDROM. The tarballs must go into /usr/portage/distfiles. Then extract the ebuild into their overlay directory.

 

I have a USB key, ill give it a go as soon as I manage to get this damned GUI installer working, cheers for the help

H

----------

## sprognak

 *VinzC wrote:*   

> @sprognak:
> 
> I suggest you wiped out your current kernel tree (of course booting from a previous one that worked) and redo all the steps I mentionned to the letter. I'm sure something was messed up in the way. If you follow my howto to the letter no extra steps are required and if you have the slightest little error message again, please post.
> 
> So boot up with a previously working kernel, unmerge your latest kernel tree and rm -r it to be sure. Then emerge it again and follow the howto. I've done the same steps with Gentoo Sources 2.6.15-r7 and it worked like a charm.
> ...

 

```
gloin linux # emerge -av ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild  N    ] net-wireless/ieee80211-1.1.13  -debug 65 kB

[ebuild     UD] net-wireless/ipw3945d-0.7.16 [0.7.16-r1] 0 kB [1]

[ebuild  N    ] net-wireless/wireless-tools-28_pre14  -multicall +nls 234 kB

[ebuild     UD] net-wireless/ipw3945-firmware-1.13 [1.13-r1] 0 kB [1]

[ebuild  N    ] net-wireless/ipw3945-0.0.69  155 kB [1]

Total size of downloads: 455 kB

Portage overlays:

 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No] Yes

>>> emerge (1 of 5) net-wireless/ieee80211-1.1.13 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/ieee80211-1.1.13.tgz

--13:02:53--  http://distfiles.gentoo.org/distfiles/ieee80211-1.1.13.tgz

           => `/usr/portage/distfiles/ieee80211-1.1.13.tgz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

13:02:54 ERROR 404: Not Found.

>>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ieee80211-1.1.13.tgz

--13:02:54--  http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ieee80211-1.1.13.tgz

           => `/usr/portage/distfiles/ieee80211-1.1.13.tgz'

Resolving distro.ibiblio.org... 152.2.210.109

Connecting to distro.ibiblio.org|152.2.210.109|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

13:02:54 ERROR 404: Not Found.

>>> Downloading http://ovh.dl.sourceforge.net/sourceforge/ieee80211/ieee80211-1.1.13.tgz

--13:02:54--  http://ovh.dl.sourceforge.net/sourceforge/ieee80211/ieee80211-1.1.13.tgz

           => `/usr/portage/distfiles/ieee80211-1.1.13.tgz'

Resolving ovh.dl.sourceforge.net... 213.186.33.91

Connecting to ovh.dl.sourceforge.net|213.186.33.91|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 67,289 (66K) [application/x-gzip]

100%[====================================>] 67,289       220.47K/s

13:02:55 (220.34 KB/s) - `/usr/portage/distfiles/ieee80211-1.1.13.tgz' saved [67289/67289]

>>> md5 files   ;-) ieee80211-1.1.9.ebuild

>>> md5 files   ;-) ieee80211-1.1.6.ebuild

>>> md5 files   ;-) ieee80211-1.1.8.ebuild

>>> md5 files   ;-) ieee80211-1.1.7.ebuild

>>> md5 files   ;-) ieee80211-1.1.12-r1.ebuild

>>> md5 files   ;-) ieee80211-1.1.11.ebuild

>>> md5 files   ;-) ieee80211-1.1.12.ebuild

>>> md5 files   ;-) ieee80211-1.1.13.ebuild

>>> md5 files   ;-) files/digest-ieee80211-1.1.8

>>> md5 files   ;-) files/digest-ieee80211-1.1.6

>>> md5 files   ;-) files/ieee80211-1.1.8-nocast.patch

>>> md5 files   ;-) files/digest-ieee80211-1.1.9

>>> md5 files   ;-) files/digest-ieee80211-1.1.7

>>> md5 files   ;-) files/remove-old

>>> md5 files   ;-) files/digest-ieee80211-1.1.12-r1

>>> md5 files   ;-) files/digest-ieee80211-1.1.11

>>> md5 files   ;-) files/digest-ieee80211-1.1.12

>>> md5 files   ;-) files/ieee80211-1.1.12-qos.patch

>>> md5 files   ;-) files/digest-ieee80211-1.1.13

>>> md5 files   ;-) files/ieee80211-1.1.12-tkip-qos-new.patch

>>> md5 src_uri ;-) ieee80211-1.1.13.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.15-gentoo-r7

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ieee80211-1.1.13.tgz to /var/tmp/portage/ieee80211-1.1.13/work

>>> Source unpacked.

 * Preparing ieee80211 module

make -C /usr/src/linux M=/var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13 modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'

  WARNING: Symbol version dump /usr/src/linux-2.6.15-gentoo-r7/Module.symvers

           is missing; modules will have no dependencies and modversions.

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_module.o

/bin/sh: scripts/genksyms/genksyms: No such file or directory

make[2]: *** [/var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_module.o] Error 1

make[1]: *** [_module_/var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13] Error 2

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'

make: *** [modules] Error 2

!!! ERROR: net-wireless/ieee80211-1.1.13 failed.

!!! Function linux-mod_src_compile, Line 509, Exitcode 2

!!! Unable to make                                  KSRC=/usr/src/linux KSRC_OUTPUT=/usr/src/linux modules.

!!! If you need support, post the topmost build error, NOT this status message.
```

 :Confused: 

----------

## VinzC

What are these -r1 suffixes? Have you renamed the ebuilds in your overlay directory? You don't have to rename them as ebuilds in the overlay take precedece over portage. So you can simply copy the ebuilds into the overlay directory and emerge.

I also advise you to unmerge everything that relates to ipw3945 and restart all over again. The only one case you have to rename an ebuild is when an upgrade version is available from CVS or Sourceforge, like I did with ipw3945.ebuild.

----------

## sprognak

Think I just got it...  will post if successful

----------

## sprognak

Well I think I'm closer...

I rebooted to r5, unmerged r7, rm -r on the r7 source dir.  Then I re-emerged r7

Checked the src/linux symlink was now going to r7, then did a genkernel --menuconfig all.

Then I checked the time/datestamp on the /boot kernel image to make sure it updated and rebooted into the new kernel.

Followed your instructions to the letter and got further:

```
gloin ~ # emerge -av ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild  N    ] net-wireless/ieee80211-1.1.13  -debug 0 kB

[ebuild     UD] net-wireless/ipw3945d-0.7.16 [0.7.16-r1] 0 kB [1]

[ebuild  N    ] net-wireless/wireless-tools-28_pre14  -multicall +nls 234 kB

[ebuild     UD] net-wireless/ipw3945-firmware-1.13 [1.13-r1] 0 kB [1]

[ebuild  N    ] net-wireless/ipw3945-0.0.69  155 kB [1]

Total size of downloads: 389 kB

Portage overlays:

 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No] y

>>> emerge (1 of 5) net-wireless/ieee80211-1.1.13 to /

>>> md5 files   ;-) ieee80211-1.1.9.ebuild

>>> md5 files   ;-) ieee80211-1.1.6.ebuild

>>> md5 files   ;-) ieee80211-1.1.8.ebuild

>>> md5 files   ;-) ieee80211-1.1.7.ebuild

>>> md5 files   ;-) ieee80211-1.1.12-r1.ebuild

>>> md5 files   ;-) ieee80211-1.1.11.ebuild

>>> md5 files   ;-) ieee80211-1.1.12.ebuild

>>> md5 files   ;-) ieee80211-1.1.13.ebuild

>>> md5 files   ;-) files/digest-ieee80211-1.1.8

>>> md5 files   ;-) files/digest-ieee80211-1.1.6

>>> md5 files   ;-) files/ieee80211-1.1.8-nocast.patch

>>> md5 files   ;-) files/digest-ieee80211-1.1.9

>>> md5 files   ;-) files/digest-ieee80211-1.1.7

>>> md5 files   ;-) files/remove-old

>>> md5 files   ;-) files/digest-ieee80211-1.1.12-r1

>>> md5 files   ;-) files/digest-ieee80211-1.1.11

>>> md5 files   ;-) files/digest-ieee80211-1.1.12

>>> md5 files   ;-) files/ieee80211-1.1.12-qos.patch

>>> md5 files   ;-) files/digest-ieee80211-1.1.13

>>> md5 files   ;-) files/ieee80211-1.1.12-tkip-qos-new.patch

>>> md5 src_uri ;-) ieee80211-1.1.13.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.15-gentoo-r7

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ieee80211-1.1.13.tgz to /var/tmp/portage/ieee80211-1.1.13/work

>>> Source unpacked.

 * Preparing ieee80211 module

make -C /usr/src/linux M=/var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13 modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_module.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_tx.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_rx.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_wx.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_geo.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_wep.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_ccmp.o

  CC [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_tkip.o

  Building modules, stage 2.

  MODPOST

  CC      /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211.mod.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211.ko

  CC      /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt.mod.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt.ko

  CC      /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_ccmp.mod.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_ccmp.ko

  CC      /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_tkip.mod.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_tkip.ko

  CC      /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_wep.mod.o

  LD [M]  /var/tmp/portage/ieee80211-1.1.13/work/ieee80211-1.1.13/ieee80211_crypt_wep.ko

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'

>>> Test phase [not enabled]: net-wireless/ieee80211-1.1.13

>>> Install ieee80211-1.1.13 into /var/tmp/portage/ieee80211-1.1.13/image/ category net-wireless

 * Installing ieee80211 module

 * Installing ieee80211_crypt module

 * Installing ieee80211_crypt_wep module

 * Installing ieee80211_crypt_ccmp module

 * Installing ieee80211_crypt_tkip module

man:

prepallstrip:

>>> Completed installing ieee80211-1.1.13 into /var/tmp/portage/ieee80211-1.1.13/image/

>>> Merging net-wireless/ieee80211-1.1.13 to /

--- /lib/

--- /lib/modules/

--- /lib/modules/2.6.15-gentoo-r7/

>>> /lib/modules/2.6.15-gentoo-r7/net/

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211.ko

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211_crypt.ko

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211_crypt_wep.ko

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211_crypt_ccmp.ko

>>> /lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211_crypt_tkip.ko

--- /usr/

--- /usr/include/

--- /usr/include/net/

>>> /usr/include/net/ieee80211.h

>>> /usr/include/net/ieee80211_crypt.h

>>> /usr/include/net/ieee80211_radiotap.h

--- /usr/share/

--- /usr/share/doc/

>>> /usr/share/doc/ieee80211-1.1.13/

>>> /usr/share/doc/ieee80211-1.1.13/CHANGES.gz

 * Updating module dependencies for 2.6.15-gentoo-r7 ...                                                                            [ ok ] * Adding module to moduledb.

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ieee80211-1.1.13 merged.

>>> clean: No packages selected for removal.

>>> emerge (2 of 5) net-wireless/ipw3945d-0.7.16 to /

>>> md5 files   ;-) ipw3945d-0.7.16.ebuild

>>> md5 files   ;-) files/digest-ipw3945d-0.7.16

>>> md5 src_uri ;-) ipw3945d-0.7.16.tgz

>>> Unpacking source...

>>> Unpacking ipw3945d-0.7.16.tgz to /var/tmp/portage/ipw3945d-0.7.16/work

>>> Source unpacked.

>>> Test phase [not enabled]: net-wireless/ipw3945d-0.7.16

>>> Install ipw3945d-0.7.16 into /var/tmp/portage/ipw3945d-0.7.16/image/ category net-wireless

man:

prepallstrip:

strip: i686-pc-linux-gnu-strip --strip-unneeded

   sbin/ipw3945d

>>> Completed installing ipw3945d-0.7.16 into /var/tmp/portage/ipw3945d-0.7.16/image/

>>> Merging net-wireless/ipw3945d-0.7.16 to /

--- /sbin/

>>> /sbin/ipw3945d

--- /usr/

--- /usr/share/

--- /usr/share/doc/

>>> /usr/share/doc/ipw3945d-0.7.16/

>>> /usr/share/doc/ipw3945d-0.7.16/README.ipw3945d.gz

>>> net-wireless/ipw3945d-0.7.16 merged.

 net-wireless/ipw3945d

    selected: 0.7.16-r1

   protected: 0.7.16

     omitted: none

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...

>>> (Control-C to abort)...

>>> Unmerging in: 5 4 3 2 1

>>> Unmerging net-wireless/ipw3945d-0.7.16-r1...

No package files given... Grabbing a set.

<<<        obj /usr/share/doc/ipw3945d-0.7.16-r1/README.ipw3945d.gz

--- !mtime obj /sbin/ipw3945d

--- cfgpro obj /etc/init.d/ipw3945d

--- cfgpro dir /etc/init.d

<<<        dir /usr/share/doc/ipw3945d-0.7.16-r1

--- !empty dir /usr/share/doc

--- !empty dir /usr/share

--- !empty dir /usr

--- !empty dir /sbin

--- !empty dir /etc

>>> Regenerating /etc/ld.so.cache...

>>> emerge (3 of 5) net-wireless/wireless-tools-28_pre14 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/wireless_tools.28.pre14.tar.gz

--13:44:50--  http://distfiles.gentoo.org/distfiles/wireless_tools.28.pre14.tar.gz

           => `/usr/portage/distfiles/wireless_tools.28.pre14.tar.gz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 240,275 (235K) [application/x-gzip]

100%[==============================================================================================>] 240,275      202.04K/s

13:44:52 (201.44 KB/s) - `/usr/portage/distfiles/wireless_tools.28.pre14.tar.gz' saved [240275/240275]

>>> md5 files   ;-) wireless-tools-28_pre10.ebuild

>>> md5 files   ;-) wireless-tools-28_pre11.ebuild

>>> md5 files   ;-) wireless-tools-27-r1.ebuild

>>> md5 files   ;-) wireless-tools-28_pre13.ebuild

>>> md5 files   ;-) wireless-tools-28_pre12.ebuild

>>> md5 files   ;-) wireless-tools-28_pre14.ebuild

>>> md5 files   ;-) wireless-tools-28_pre15.ebuild

>>> md5 files   ;-) wireless-tools-28_pre16.ebuild

>>> md5 files   ;-) files/digest-wireless-tools-28_pre12

>>> md5 files   ;-) files/digest-wireless-tools-27-r1

>>> md5 files   ;-) files/digest-wireless-tools-28_pre10

>>> md5 files   ;-) files/digest-wireless-tools-28_pre11

>>> md5 files   ;-) files/digest-wireless-tools-28_pre13

>>> md5 files   ;-) files/digest-wireless-tools-28_pre14

>>> md5 files   ;-) files/digest-wireless-tools-28_pre15

>>> md5 files   ;-) files/digest-wireless-tools-28_pre16

>>> md5 src_uri ;-) wireless_tools.28.pre14.tar.gz

>>> Unpacking source...

>>> Unpacking wireless_tools.28.pre14.tar.gz to /var/tmp/portage/wireless-tools-28_pre14/work

>>> Source unpacked.

cp wireless.19.h wireless.h

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -fPIC -c -o iwlib.so iwlib.c

i686-pc-linux-gnu-gcc -shared -o libiw.so.28 -Wl,-soname,libiw.so.28  -lm -lc iwlib.so

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwconfig.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwconfig iwconfig.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwlist.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwlist iwlist.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwpriv.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwpriv iwpriv.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwspy.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwspy iwspy.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwgetid.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwgetid iwgetid.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c iwevent.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o iwevent iwevent.o libiw.so.28 -lm

i686-pc-linux-gnu-gcc -march=pentium-m -O2 -pipe -MMD    -c ifrename.c

i686-pc-linux-gnu-gcc   -march=pentium-m -O2 -pipe -MMD    -o ifrename ifrename.o libiw.so.28 -lm

>>> Test phase [not enabled]: net-wireless/wireless-tools-28_pre14

>>> Install wireless-tools-28_pre14 into /var/tmp/portage/wireless-tools-28_pre14/image/ category net-wireless

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//lib/

install -m 755 libiw.so.28 /var/tmp/portage/wireless-tools-28_pre14/image//lib/

ln -sfn libiw.so.28 /var/tmp/portage/wireless-tools-28_pre14/image//lib//libiw.so

*** Don't forget to add /var/tmp/portage/wireless-tools-28_pre14/image//lib/ to /etc/ld.so.conf, and run ldconfig as root. ***

#@ldconfig || echo "*** Could not run ldconfig ! ***"

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//sbin/

install -m 755 iwconfig iwlist iwpriv iwspy iwgetid iwevent ifrename /var/tmp/portage/wireless-tools-28_pre14/image//sbin/

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//usr/include

install -m 644 iwlib.h /var/tmp/portage/wireless-tools-28_pre14/image//usr/include

install -m 644 wireless.h /var/tmp/portage/wireless-tools-28_pre14/image//usr/include

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man8/

install -m 644 iwconfig.8 iwlist.8 iwpriv.8 iwspy.8 iwgetid.8 iwevent.8 ifrename.8 /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man8/

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man7/

install -m 644 wireless.7 /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man7/

install -m 755 -d /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man5/

install -m 644 iftab.5 /var/tmp/portage/wireless-tools-28_pre14/image//usr/share/man/man5/

man:

gzipping man page: iwconfig.8

gzipping man page: iwlist.8

gzipping man page: iwpriv.8

gzipping man page: iwspy.8

gzipping man page: iwgetid.8

gzipping man page: iwevent.8

gzipping man page: ifrename.8

gzipping man page: wireless.7

gzipping man page: iftab.5

gzipping man page: iftab.5

gzipping man page: wireless.7

gzipping man page: ifrename.8

gzipping man page: iwconfig.8

gzipping man page: iwevent.8

gzipping man page: iwgetid.8

gzipping man page: iwlist.8

gzipping man page: iwpriv.8

gzipping man page: iwspy.8

gzipping man page: iftab.5

gzipping man page: wireless.7

gzipping man page: ifrename.8

gzipping man page: iwconfig.8

gzipping man page: iwevent.8

gzipping man page: iwgetid.8

gzipping man page: iwlist.8

gzipping man page: iwpriv.8

gzipping man page: iwspy.8

prepallstrip:

strip: i686-pc-linux-gnu-strip --strip-unneeded

   lib/libiw.so.28

   sbin/iwconfig

   sbin/iwlist

   sbin/iwpriv

   sbin/iwspy

   sbin/iwgetid

   sbin/iwevent

   sbin/ifrename

making executable: /lib/libiw.so.28

>>> Completed installing wireless-tools-28_pre14 into /var/tmp/portage/wireless-tools-28_pre14/image/

>>> Merging net-wireless/wireless-tools-28_pre14 to /

--- /lib/

>>> /lib/libiw.so.28

>>> /lib/libiw.so -> libiw.so.28

--- /sbin/

>>> /sbin/iwconfig

>>> /sbin/iwlist

>>> /sbin/iwpriv

>>> /sbin/iwspy

>>> /sbin/iwgetid

>>> /sbin/iwevent

>>> /sbin/ifrename

--- /usr/

--- /usr/include/

>>> /usr/include/iwlib.h

>>> /usr/include/wireless.h

--- /usr/share/

--- /usr/share/man/

--- /usr/share/man/man8/

>>> /usr/share/man/man8/iwlist.8.gz

>>> /usr/share/man/man8/iwspy.8.gz

>>> /usr/share/man/man8/iwgetid.8.gz

>>> /usr/share/man/man8/iwevent.8.gz

>>> /usr/share/man/man8/ifrename.8.gz

>>> /usr/share/man/man8/iwconfig.8.gz

>>> /usr/share/man/man8/iwpriv.8.gz

--- /usr/share/man/man7/

>>> /usr/share/man/man7/wireless.7.gz

--- /usr/share/man/man5/

>>> /usr/share/man/man5/iftab.5.gz

--- /usr/share/man/fr/

--- /usr/share/man/fr/man5/

>>> /usr/share/man/fr/man5/iftab.5.gz

>>> /usr/share/man/fr/man7/

>>> /usr/share/man/fr/man7/wireless.7.gz

--- /usr/share/man/fr/man8/

>>> /usr/share/man/fr/man8/iwevent.8.gz

>>> /usr/share/man/fr/man8/iwgetid.8.gz

>>> /usr/share/man/fr/man8/iwlist.8.gz

>>> /usr/share/man/fr/man8/iwpriv.8.gz

>>> /usr/share/man/fr/man8/iwspy.8.gz

>>> /usr/share/man/fr/man8/ifrename.8.gz

>>> /usr/share/man/fr/man8/iwconfig.8.gz

--- /usr/share/man/cs/

--- /usr/share/man/cs/man5/

>>> /usr/share/man/cs/man5/iftab.5.gz

>>> /usr/share/man/cs/man7/

>>> /usr/share/man/cs/man7/wireless.7.gz

--- /usr/share/man/cs/man8/

>>> /usr/share/man/cs/man8/iwevent.8.gz

>>> /usr/share/man/cs/man8/iwgetid.8.gz

>>> /usr/share/man/cs/man8/iwlist.8.gz

>>> /usr/share/man/cs/man8/iwpriv.8.gz

>>> /usr/share/man/cs/man8/iwspy.8.gz

>>> /usr/share/man/cs/man8/ifrename.8.gz

>>> /usr/share/man/cs/man8/iwconfig.8.gz

--- /usr/share/doc/

>>> /usr/share/doc/wireless-tools-28_pre14/

>>> /usr/share/doc/wireless-tools-28_pre14/README.fr.gz

>>> /usr/share/doc/wireless-tools-28_pre14/CHANGELOG.h.gz

>>> /usr/share/doc/wireless-tools-28_pre14/HOTPLUG.txt.gz

>>> /usr/share/doc/wireless-tools-28_pre14/DISTRIBUTIONS.txt.gz

>>> /usr/share/doc/wireless-tools-28_pre14/PCMCIA.txt.gz

>>> /usr/share/doc/wireless-tools-28_pre14/IFRENAME-VS-XXX.txt.gz

>>> /usr/share/doc/wireless-tools-28_pre14/README.gz

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/wireless-tools-28_pre14 merged.

>>> clean: No packages selected for removal.

>>> emerge (4 of 5) net-wireless/ipw3945-firmware-1.13 to /

>>> md5 files   ;-) ipw3945-firmware-1.13.ebuild

>>> md5 files   ;-) files/digest-ipw3945-firmware-1.13

>>> md5 src_uri ;-) ipw3945-ucode-1.13.tgz

>>> Unpacking source...

>>> Unpacking ipw3945-ucode-1.13.tgz to /var/tmp/portage/ipw3945-firmware-1.13/work

>>> Source unpacked.

>>> Test phase [not enabled]: net-wireless/ipw3945-firmware-1.13

>>> Install ipw3945-firmware-1.13 into /var/tmp/portage/ipw3945-firmware-1.13/image/ category net-wireless

man:

prepallstrip:

>>> Completed installing ipw3945-firmware-1.13 into /var/tmp/portage/ipw3945-firmware-1.13/image/

>>> Merging net-wireless/ipw3945-firmware-1.13 to /

--- /lib/

--- /lib/firmware/

>>> /lib/firmware/ipw3945.ucode

>>> /lib/firmware/ipw3945-1.13-LICENSE

>>> net-wireless/ipw3945-firmware-1.13 merged.

 net-wireless/ipw3945-firmware

    selected: 1.13-r1

   protected: 1.13

     omitted: none

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...

>>> (Control-C to abort)...

>>> Unmerging in: 5 4 3 2 1

>>> Unmerging net-wireless/ipw3945-firmware-1.13-r1...

No package files given... Grabbing a set.

--- !mtime obj /lib/firmware/ipw3945.ucode

--- !empty dir /lib/firmware

--- !empty dir /lib

>>> Regenerating /etc/ld.so.cache...

>>> emerge (5 of 5) net-wireless/ipw3945-0.0.69 to /

>>> Downloading http://distfiles.gentoo.org/distfiles/ipw3945-0.0.69.tgz

--13:45:14--  http://distfiles.gentoo.org/distfiles/ipw3945-0.0.69.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.69.tgz'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

13:45:14 ERROR 404: Not Found.

>>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-0.0.69.tgz

--13:45:14--  http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/ipw3945-0.0.69.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.69.tgz'

Resolving distro.ibiblio.org... 152.2.210.109

Connecting to distro.ibiblio.org|152.2.210.109|:80... connected.

HTTP request sent, awaiting response... 404 Not Found

13:45:15 ERROR 404: Not Found.

>>> Downloading http://osdn.dl.sourceforge.net/sourceforge/ipw3945/ipw3945-0.0.69.tgz

--13:45:15--  http://osdn.dl.sourceforge.net/sourceforge/ipw3945/ipw3945-0.0.69.tgz

           => `/usr/portage/distfiles/ipw3945-0.0.69.tgz'

Resolving osdn.dl.sourceforge.net... 66.35.250.221

Connecting to osdn.dl.sourceforge.net|66.35.250.221|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 158,799 (155K) [application/x-tar-gz]

100%[==============================================================================================>] 158,799       54.67K/s

13:45:19 (54.54 KB/s) - `/usr/portage/distfiles/ipw3945-0.0.69.tgz' saved [158799/158799]

>>> md5 files   ;-) ipw3945-0.0.69.ebuild

>>> md5 files   ;-) files/digest-ipw3945-0.0.69

>>> md5 src_uri ;-) ipw3945-0.0.69.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.15-gentoo-r7

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ipw3945-0.0.69.tgz to /var/tmp/portage/ipw3945-0.0.69/work

>>> Source unpacked.

 *

 * You may safely ignore any errors from compilation that contain

 * warnings about undefined references to the ieee80211 subsystem.

 *

 * Preparing ipw3945 module

mkdir -p /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions

cp /usr/include/*.mod /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions

cp: cannot stat `/usr/include/*.mod': No such file or directory

make: [modules] Error 1 (ignored)

make -C /usr/src/linux M=/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69 MODVERDIR=/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'

  CC [M]  /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.o

  Building modules, stage 2.

  MODPOST

*** Warning: "ieee80211_get_channel_flags" [/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko] undefined!

*** Warning: "ieee80211_get_channel" [/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko] undefined!

  CC      /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.mod.o

  LD [M]  /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'

>>> Test phase [not enabled]: net-wireless/ipw3945-0.0.69

>>> Install ipw3945-0.0.69 into /var/tmp/portage/ipw3945-0.0.69/image/ category net-wireless

 * Installing ipw3945 module

 * Preparing file for modules.d ...                                                                                                 [ ok ]man:

prepallstrip:

>>> Completed installing ipw3945-0.0.69 into /var/tmp/portage/ipw3945-0.0.69/image/

>>> Merging net-wireless/ipw3945-0.0.69 to /

--- /lib/

--- /lib/modules/

--- /lib/modules/2.6.15-gentoo-r7/

--- /lib/modules/2.6.15-gentoo-r7/net/

>>> /lib/modules/2.6.15-gentoo-r7/net/wireless/

>>> /lib/modules/2.6.15-gentoo-r7/net/wireless/ipw3945.ko

--- /etc/

--- /etc/modules.d/

>>> /etc/modules.d/ipw3945

--- /usr/

--- /usr/share/

--- /usr/share/doc/

>>> /usr/share/doc/ipw3945-0.0.69/

>>> /usr/share/doc/ipw3945-0.0.69/README.ipw3945.gz

>>> /usr/share/doc/ipw3945-0.0.69/CHANGES.gz

>>> /usr/share/doc/ipw3945-0.0.69/ISSUES.gz

 * Updating module dependencies for 2.6.15-gentoo-r7 ...                                                                            [ ok ] * Adding module to moduledb.

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ipw3945-0.0.69 merged.

>>> Recording net-wireless/ipw3945 in "world" favorites file...

>>> clean: No packages selected for removal.

>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 19 config files in /etc need updating.

 * Type emerge --help config to learn how to update config files.

gloin ~ # modprobe ipw3945

WARNING: Error inserting ieee80211 (/lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211.ko): Unknown symbol in module, or unknown parameter (see dmesg)

FATAL: Error inserting ipw3945 (/lib/modules/2.6.15-gentoo-r7/net/wireless/ipw3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)

gloin ~ #
```

dmesg shows:

```
ieee80211_crypt: registered algorithm 'NULL'

ieee80211: disagrees about version of symbol ieee80211_get_crypto_ops

ieee80211: Unknown symbol ieee80211_get_crypto_ops

ieee80211: disagrees about version of symbol ieee80211_crypt_deinit_entries

ieee80211: Unknown symbol ieee80211_crypt_deinit_entries

ieee80211: disagrees about version of symbol ieee80211_crypt_delayed_deinit

ieee80211: Unknown symbol ieee80211_crypt_delayed_deinit

ieee80211: disagrees about version of symbol ieee80211_crypt_quiescing

ieee80211: Unknown symbol ieee80211_crypt_quiescing

ipw3945: Unknown symbol ieee80211_get_channel

ipw3945: Unknown symbol ieee80211_get_channel_flags
```

----------

## VinzC

Hmmm... It looks like ieee80211 has not been linked correctly. Have you run 

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

 before you emerged the package from portage?

First try to remove ipw3945 (only that one) and ieee80211. Next run 

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

 and emerge both again. Note wireless tools must be present before all packages are merged but at least you've gone one step further. When I compiled ieee80211 I got a couple of warnings. So I'm surprised you didn't get any.

----------

## sprognak

Yep, I ran the script to kill the old stuff from the kernel before the emerge of ipw3945.  This is becoming very frustrating...

----------

## sprognak

Just tried emerge -av ipw3945 again and it let me.

```
gloin ~ # emerge -av ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-wireless/ipw3945-0.0.69  0 kB [1]

Total size of downloads: 0 kB

Portage overlays:

 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No] yes

>>> emerge (1 of 1) net-wireless/ipw3945-0.0.69 to /

>>> md5 files   ;-) ipw3945-0.0.69.ebuild

>>> md5 files   ;-) files/digest-ipw3945-0.0.69

>>> md5 src_uri ;-) ipw3945-0.0.69.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.15-gentoo-r7

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ipw3945-0.0.69.tgz to /var/tmp/portage/ipw3945-0.0.69/work

>>> Source unpacked.

 *

 * You may safely ignore any errors from compilation that contain

 * warnings about undefined references to the ieee80211 subsystem.

 *

 * Preparing ipw3945 module

mkdir -p /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions

cp /usr/include/*.mod /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions

cp: cannot stat `/usr/include/*.mod': No such file or directory

make: [modules] Error 1 (ignored)

make -C /usr/src/linux M=/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69 MODVERDIR=/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions modules

make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'

  CC [M]  /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.o

  Building modules, stage 2.

  MODPOST

*** Warning: "ieee80211_get_channel_flags" [/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko] undefined!

*** Warning: "ieee80211_get_channel" [/var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko] undefined!

  CC      /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.mod.o

  LD [M]  /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/ipw3945.ko

make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'

>>> Test phase [not enabled]: net-wireless/ipw3945-0.0.69

>>> Install ipw3945-0.0.69 into /var/tmp/portage/ipw3945-0.0.69/image/ category net-wireless

 * Installing ipw3945 module

 * Preparing file for modules.d ...                                       [ ok ]man:

prepallstrip:

>>> Completed installing ipw3945-0.0.69 into /var/tmp/portage/ipw3945-0.0.69/image/

>>> Merging net-wireless/ipw3945-0.0.69 to /

--- /lib/

--- /lib/modules/

--- /lib/modules/2.6.15-gentoo-r7/

--- /lib/modules/2.6.15-gentoo-r7/net/

--- /lib/modules/2.6.15-gentoo-r7/net/wireless/

>>> /lib/modules/2.6.15-gentoo-r7/net/wireless/ipw3945.ko

--- /etc/

--- /etc/modules.d/

>>> /etc/modules.d/ipw3945

--- /usr/

--- /usr/share/

--- /usr/share/doc/

--- /usr/share/doc/ipw3945-0.0.69/

>>> /usr/share/doc/ipw3945-0.0.69/README.ipw3945.gz

>>> /usr/share/doc/ipw3945-0.0.69/CHANGES.gz

>>> /usr/share/doc/ipw3945-0.0.69/ISSUES.gz

>>> Safely unmerging already-installed instance...

--- !mtime obj /usr/share/doc/ipw3945-0.0.69/README.ipw3945.gz

--- !mtime obj /usr/share/doc/ipw3945-0.0.69/ISSUES.gz

--- !mtime obj /usr/share/doc/ipw3945-0.0.69/CHANGES.gz

--- cfgpro obj /lib/modules/2.6.15-gentoo-r7/net/wireless/ipw3945.ko

--- cfgpro dir /lib/modules/2.6.15-gentoo-r7/net/wireless

--- cfgpro dir /lib/modules/2.6.15-gentoo-r7/net

--- cfgpro dir /lib/modules/2.6.15-gentoo-r7

--- cfgpro obj /etc/modules.d/ipw3945

--- cfgpro dir /etc/modules.d

--- !empty dir /usr/share/doc/ipw3945-0.0.69

--- !empty dir /usr/share/doc

--- !empty dir /usr/share

--- !empty dir /usr

--- !empty dir /lib/modules

--- !empty dir /lib

--- !empty dir /etc

 * Removing net-wireless/ipw3945-0.0.69 from moduledb.

>>> original instance of package unmerged safely.

 * Updating module dependencies for 2.6.15-gentoo-r7 ...                  [ ok ] * Adding module to moduledb.

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ipw3945-0.0.69 merged.

>>> clean: No packages selected for removal.

>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 19 config files in /etc need updating.

 * Type emerge --help config to learn how to update config files
```

If I type emerge -av ipw3945 again it does the same....  Something isn't working properly on the emerge...

----------

## sprognak

```
cp /usr/include/*.mod /var/tmp/portage/ipw3945-0.0.69/work/ipw3945-0.0.69/tmp/.tmp_versions

cp: cannot stat `/usr/include/*.mod': No such file or directory

make: [modules] Error 1 (ignored)
```

Could this be a problem?

----------

## VinzC

I think I've got that kind of thing once. IIRC I just unmerged ieee80211 and re-emerged it again. Then the same with ipw3945.

----------

## sprognak

unmerged ipw3945, then ieee80211, ran script to clean kernel version - nothing found.

remerged ipw3945 - it selected ieee80211 and remerged - same problem.

unmerged ipw3945, then ieee80211, remerged 80211 then 3945 - same problem

unmerged ieee80211, remerged 80211, unmerged ipw3945, remerged ipw3945 - same problem...

*edit*  I'm pretty convinced everything is coming down properly, but the ipw3945 is not for some reason, it seems to start at that dir copy error...

*edit again*  Ok, the error is identical if I remove ipw3945 to if I have ipw3945 emerged, which would indicate it is ipw3945 not emerging properly....

----------

## sprognak

VinzC, what do you have in /usr/include/*.mod?

----------

## sprognak

Wait a sec, I had the same error of these mod files not being found by rmh's ebuild earlier.

I've since moved his ebuild out, removed it from the make.conf list and done a clean kernel rebuild (unmerge and remerge) but could something be hanging over?  How do I check?

----------

## sprognak

Ok well this appears to be a dead end...

I have unmerged everything, purged the modules and rerun make modules_install to clean things up.

I followed the ipw3945 sourceforge website with all latest versions, installed ieee80211.  No error messages all the way through....

Except on the trial of ./load debug=0 it bombs out with:

```
gloin ipw3945-0.0.73 # ./load debug=0

ERROR: Module ieee80211 does not exist in /proc/modules

Unloaded: ieee80211 ieee80211_crypt

FATAL: Error inserting ieee80211 (/lib/modules/2.6.15-gentoo-r7/net/ieee80211/ieee80211.ko): Unknown symbol in module, or unknown parameter (see dmesg)

insmod: error inserting './ipw3945.ko': -1 Unknown symbol in module

Load failed.

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.18

2006-04-02 16:39:37: ERROR: opening /sys/bus/pci/drivers/ipw3945:

No such file or directory (2)

2006-04-02 16:39:37: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

gloin ipw3945-0.0.73 #
```

and dmesg says:

```
ieee80211_crypt: unregistered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: disagrees about version of symbol ieee80211_get_crypto_ops

ieee80211: Unknown symbol ieee80211_get_crypto_ops

ieee80211: disagrees about version of symbol ieee80211_crypt_deinit_entries

ieee80211: Unknown symbol ieee80211_crypt_deinit_entries

ieee80211: disagrees about version of symbol ieee80211_crypt_delayed_deinit

ieee80211: Unknown symbol ieee80211_crypt_delayed_deinit

ieee80211: disagrees about version of symbol ieee80211_crypt_quiescing

ieee80211: Unknown symbol ieee80211_crypt_quiescing

ipw3945: disagrees about version of symbol ieee80211_wx_get_encodeext

ipw3945: Unknown symbol ieee80211_wx_get_encodeext

ipw3945: disagrees about version of symbol ieee80211_wx_set_encode

ipw3945: Unknown symbol ieee80211_wx_set_encode

ipw3945: disagrees about version of symbol ieee80211_wx_get_encode

ipw3945: Unknown symbol ieee80211_wx_get_encode

ipw3945: disagrees about version of symbol ieee80211_txb_free

ipw3945: Unknown symbol ieee80211_txb_free

ipw3945: disagrees about version of symbol ieee80211_wx_set_encodeext

ipw3945: Unknown symbol ieee80211_wx_set_encodeext

ipw3945: disagrees about version of symbol ieee80211_wx_get_scan

ipw3945: Unknown symbol ieee80211_wx_get_scan

ipw3945: disagrees about version of symbol ieee80211_freq_to_channel

ipw3945: Unknown symbol ieee80211_freq_to_channel

ipw3945: disagrees about version of symbol ieee80211_set_geo

ipw3945: Unknown symbol ieee80211_set_geo

ipw3945: disagrees about version of symbol ieee80211_rx

ipw3945: Unknown symbol ieee80211_rx

ipw3945: Unknown symbol ieee80211_get_channel

ipw3945: disagrees about version of symbol ieee80211_channel_to_index

ipw3945: Unknown symbol ieee80211_channel_to_index

ipw3945: disagrees about version of symbol ieee80211_rx_mgt

ipw3945: Unknown symbol ieee80211_rx_mgt

ipw3945: disagrees about version of symbol ieee80211_get_geo

ipw3945: Unknown symbol ieee80211_get_geo

ipw3945: disagrees about version of symbol free_ieee80211

ipw3945: Unknown symbol free_ieee80211

ipw3945: disagrees about version of symbol ieee80211_tx_frame

ipw3945: Unknown symbol ieee80211_tx_frame

ipw3945: disagrees about version of symbol ieee80211_is_valid_channel

ipw3945: Unknown symbol ieee80211_is_valid_channel

ipw3945: Unknown symbol ieee80211_get_channel_flags

ipw3945: disagrees about version of symbol alloc_ieee80211

ipw3945: Unknown symbol alloc_ieee80211
```

----------

## VinzC

First have you got these questions while running the remove-old script?

```
# /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux

Checking in /usr/src/linux/ for ieee80211 components...

/usr/src/linux/include/config/ieee80211.h

Above files found.  Remove? [y],n

#undef CONFIG_IEEE80211

Above definitions found.  Comment out? [y], n
```

Use the default answers (Y). You also MUST unselect ieee80211 support in your kernel beforehand. Sorry to repeat this but just in case.

I'm currently checking all the steps I indicated and re-emerging ieee80211. I'll be back once I've done everything once again.

----------

## VinzC

 *sprognak wrote:*   

> VinzC, what do you have in /usr/include/*.mod?

 

```
# ls -l /usr/include/*.mod

ls: /usr/include/*.mod: No such file or directory
```

EDIT: Well, that all worked. No warning while compiling ieee80211  :Rolling Eyes:  .

```
# emerge -av ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-wireless/ipw3945-0.0.70  0 kB [1]

Total size of downloads: 0 kB

Portage overlays:

 [1] /usr/local/portage

Do you want me to merge these packages? [Yes/No]

>>> emerge (1 of 1) net-wireless/ipw3945-0.0.70 to /

>>> md5 files   ;-) ipw3945-0.0.69.ebuild

>>> md5 files   ;-) ipw3945-0.0.70.ebuild

>>> md5 files   ;-) files/digest-ipw3945-0.0.69

>>> md5 files   ;-) files/digest-ipw3945-0.0.70

>>> md5 src_uri ;-) ipw3945-0.0.70.tgz

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.16-gentoo-r1

 * Checking for suitable kernel configuration options:

>>> Unpacking source...

>>> Unpacking ipw3945-0.0.70.tgz to /var/tmp/portage/ipw3945-0.0.70/work

>>> Source unpacked.

 *

 * You may safely ignore any errors from compilation that contain

 * warnings about undefined references to the ieee80211 subsystem.

 *

 * Preparing ipw3945 module

mkdir -p /var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/tmp/.tmp_versions

cp /usr/include/*.mod /var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/tmp/.tmp_versions

cp: cannot stat `/usr/include/*.mod': No such file or directory

make: [modules] Error 1 (ignored)

make -C /usr/src/linux M=/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70 MODVERDIR=/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/tmp/.tmp_versions modules

make[1]: Entering directory `/usr/src/linux-2.6.16-gentoo-r1'

  CC [M]  /var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.o

  Building modules, stage 2.

  MODPOST

*** Warning: "free_ieee80211" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "alloc_ieee80211" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_wx_get_encodeext" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_wx_set_encodeext" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_wx_get_encode" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_wx_set_encode" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_wx_get_scan" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_freq_to_channel" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_rx" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_rx_mgt" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_channel_to_index" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "escape_essid" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_txb_free" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_is_valid_channel" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_set_geo" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_tx_frame" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_get_channel_flags" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_get_channel" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

*** Warning: "ieee80211_get_geo" [/var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko] undefined!

  CC      /var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.mod.o

  LD [M]  /var/tmp/portage/ipw3945-0.0.70/work/ipw3945-0.0.70/ipw3945.ko

make[1]: Leaving directory `/usr/src/linux-2.6.16-gentoo-r1'

>>> Test phase [not enabled]: net-wireless/ipw3945-0.0.70

>>> Install ipw3945-0.0.70 into /var/tmp/portage/ipw3945-0.0.70/image/ category net-wireless

 * Installing ipw3945 module

 * Preparing file for modules.d ...                                       [ ok ]

man:

prepallstrip:

>>> Completed installing ipw3945-0.0.70 into /var/tmp/portage/ipw3945-0.0.70/image/

>>> Merging net-wireless/ipw3945-0.0.70 to /

--- /etc/

--- /etc/modules.d/

>>> /etc/modules.d/ipw3945

--- /lib/

--- /lib/modules/

--- /lib/modules/2.6.16-gentoo-r1/

--- /lib/modules/2.6.16-gentoo-r1/net/

--- /lib/modules/2.6.16-gentoo-r1/net/wireless/

>>> /lib/modules/2.6.16-gentoo-r1/net/wireless/ipw3945.ko

--- /usr/

--- /usr/share/

--- /usr/share/doc/

--- /usr/share/doc/ipw3945-0.0.70/

>>> /usr/share/doc/ipw3945-0.0.70/ISSUES.gz

>>> /usr/share/doc/ipw3945-0.0.70/README.ipw3945.gz

>>> /usr/share/doc/ipw3945-0.0.70/CHANGES.gz

>>> Safely unmerging already-installed instance...

--- !mtime obj /usr/share/doc/ipw3945-0.0.70/README.ipw3945.gz

--- !mtime obj /usr/share/doc/ipw3945-0.0.70/ISSUES.gz

--- !mtime obj /usr/share/doc/ipw3945-0.0.70/CHANGES.gz

--- cfgpro obj /lib/modules/2.6.16-gentoo-r1/net/wireless/ipw3945.ko

--- cfgpro dir /lib/modules/2.6.16-gentoo-r1/net/wireless

--- cfgpro dir /lib/modules/2.6.16-gentoo-r1/net

--- cfgpro dir /lib/modules/2.6.16-gentoo-r1

--- cfgpro obj /etc/modules.d/ipw3945

--- cfgpro dir /etc/modules.d

--- !empty dir /usr/share/doc/ipw3945-0.0.70

--- !empty dir /usr/share/doc

--- !empty dir /usr/share

--- !empty dir /usr

--- !empty dir /lib/modules

--- !empty dir /lib

--- !empty dir /etc

 * Removing net-wireless/ipw3945-0.0.70 from moduledb.

>>> original instance of package unmerged safely.

 * Updating module dependencies for 2.6.16-gentoo-r1 ...                  [ ok ]

 * Adding module to moduledb.

>>> Regenerating /etc/ld.so.cache...

>>> net-wireless/ipw3945-0.0.70 merged.

>>> clean: No packages selected for removal.

>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.
```

See the warnings? You get them because ieee80211 binaries are not included in ipw3945 temporary tree while compiling. Hence it's referencing unknown symbols at link time. But it doesn't harm.

Note I have ipw3945 version 0.0.70. Just copy-rename the ebuild. That's all.

EDIT: just in case...

```
# cat $(equery w ipw3945)

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# Author: VinzC (vcadet@hotmail.com)

inherit linux-mod

# The following works with both pre-releases and releases

S=${WORKDIR}/${P}

IEEE80211_VERSION="1.1.11"

FW_VERSION="1.13"

IPWD_VERSION="0.7.16"

DESCRIPTION="Intel(R) PRO/Wireless 3945 Network Connection driver for Linux"

HOMEPAGE="http://ipw3945.sourceforge.net"

SRC_URI="http://osdn.dl.sourceforge.net/sourceforge/${PN}/${P}.tgz"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~x86"

IUSE=""

DEPEND=">=net-wireless/ieee80211-${IEEE80211_VERSION}"

RDEPEND="${DEPEND}

                =net-wireless/ipw3945d-${IPWD_VERSION}

                =net-wireless/ipw3945-firmware-${FW_VERSION}

                net-wireless/wireless-tools"

BUILD_TARGETS="all"

MODULE_NAMES="ipw3945(net/wireless:)"

MODULESD_IPW3945_DOCS="README.ipw3945"

CONFIG_CHECK="NET_RADIO FW_LOADER"

ERROR_NET_RADIO="${P} requires support for Wireless LAN drivers (non-hamradio) & Wireless Extensions (CONFIG_NET_RADIO)."

ERROR_FW_LOADER="${P} requires Hotplug firmware loading support (CONFIG_FW_LOADER)."

pkg_setup() {

        linux-mod_pkg_setup

        if kernel_is 2 4; then

                die "${P} does not support building against kernel 2.4.x"

        fi

        BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

}

src_compile() {

        einfo

        einfo "You may safely ignore any errors from compilation that contain"

        einfo "warnings about undefined references to the ieee80211 subsystem."

        einfo

        linux-mod_src_compile

}

src_install() {

        linux-mod_src_install

        dodoc CHANGES ISSUES

}

pkg_postinst() {

        linux-mod_pkg_postinst

        if [ -f /lib/modules/${KV_FULL}/net/${PN}.ko ]; then

                einfo

                einfo "Modules from an earlier installation detected. You will need to manually"

                einfo "remove those modules by running the following commands:"

                einfo "  # rm -f /lib/modules/${KV_FULL}/net/${PN}.ko"

                einfo "  # rm -f /lib/modules/${KV_FULL}/net/ieee80211*.ko"

                einfo "  # depmod -a"

                einfo

        fi

}
```

----------

## sprognak

Solved it!

I unmerged everything (again), updated the kernel to 2.6.16-r1 with kernel ieee80211set to modular (can't be removed from menuconfig) and ran the remove script.

Then I downloaded the latest source from sourceforge and did a full manual build.

After a little tinkering, it works quite nicely!

Just playing with the init.d scripts to set my Wireless details up for bootup.

Thanks for all the help though!

btw, I must confess, yesterday in a heated rage I wiped everything and put Debian back.  After 30 minutes I got sick of being able to 'fine tune' debian to the same extent and reinstalled Gentoo.

It's suprisingly addictive this stuff....

----------

## VinzC

Glad you found a way to make it work. Never give up. That's the lesson  :Smile:  .

Keep cool man.

----------

## sprognak

Ok, it's getting picked up at boot but it's not getting any further.

I have to su to root, then iwconfig .......settings.......

then ifconfig eth1 up

then dhcpd eth1

then it works fine.  How can I get this to happen automatically?

----------

## VinzC

 *sprognak wrote:*   

> Ok, it's getting picked up at boot but it's not getting any further.
> 
> I have to su to root, then iwconfig .......settings.......
> 
> then ifconfig eth1 up
> ...

 

What version of baselayout do you have? You should have 1.12 series. Version 1.12.0_pre16 requires bash 3.1.xx and you'll have to unmask them (by ~ARCH in /etc/portage/keywords). You also should have udev version 070-r1 or above as stated in my howto.

----------

## sprognak

Ok, I just thought I was beginning to understand a few things then that flew right over my head.

Could you explain that in simpler terms please?

----------

## moumou

 *VinzC wrote:*   

>  *moumou wrote:*   Version 0.0.73 is out ! I would have updated the svn, but I don't know how to do it :/
> 
> I also found why the ebuilds wouldn't work with ieee80211 from portage. It's because it doesn't find the ieee80211.h in /lib/modules/`uname -r`/include. In fact they are in /usr/include. I just added IEEE80211_INCLUDEDIR=/usr/include (if I remember clearly) to the ebuild, in front of the function that compiles the module, and it worked flawlessly  
> 
> Ah, that's interresting: do you mean you can now use kernel built-in ieee80211 drivers and not the ones from portage anymore? Could you please post your modified ebuild so I can update mine accordingly?
> ...

 

What I meant is that rmh's ebuilds on gentoo-sources don't work (at least for me), because it doesn't work with the kernel ieee80211 system, and it doesn't find the ieee80211.h file when you install ieee80211 from portage. So I modified rmh's ebuild like this (diff-style) :

```
 src_compile() {

-        linux-mod_src_compile

+        IEEE80211_INC=/usr/include linux-mod_src_compile

         

         einfo

 }
```

However I don't know how it works with your ebuilds, VinzC.

----------

## VinzC

Ah, Ok. I misunderstood. But I'd try that trick to have ipw3945 use the built-in ieee80211.

----------

## chi-z

I'm in the same boat you were in. I'm getting all of the same errors you reported previously and was curious other than updating to a 2.6.16 kernel was there anything else you did to resolve the issue? I'm hoping I don't have to build a new kernel(currently running 2.6.15-r1). I tried manually installing the 0.0.73 driver version and the exact error still occurs when I try to modprobe ipw3945, as it also occurs when changing the ebuild to install .73(Unknown symbol in module... error. and then dmesg reports unknown symbols with : ieee80211_(get_geo|tx_frame|is_valid_channel) and free_ieee80211 and a bunch more "ieee80211_*" symbol errors).

Thanks

 *sprognak wrote:*   

> Solved it!
> 
> I unmerged everything (again), updated the kernel to 2.6.16-r1 with kernel ieee80211set to modular (can't be removed from menuconfig) and ran the remove script.
> 
> Then I downloaded the latest source from sourceforge and did a full manual build.
> ...

 

----------

## VinzC

I definitely believe this is due to ipw3945 not being (correctly) linked against the right ieee80211 binaries. I don't know how exactly this issue can be solved but I'm convinced this is the reason why you get "unknown symbol" messages while loading the module.

----------

## VinzC

After further investigations, I've had troubles with driver 0.0.72 and above. Loading the driver makes the WiFi led flash forever (or a rather long time) and the wireless network isn't established. I have no problem at all with and up to ipw3945-0.0.71.

----------

## firebeard

what about linux driver 1.0.0 on intel site? ipw3945-linux-1.0.0.tgz

[url]http://downloadfinder.intel.com/scripts-df-external/detail_desc.aspx?strstate=live&productid=1783&dwnldid=10315&agr=y&lang=eng&prdmap=1783

[/url]

how can one make it available for ebuild and on sourceforge?

I only find 0.0.74 on sourceforge.

(sorry - total newbie at work...)

----------

## quat

 *firebeard wrote:*   

> what about linux driver 1.0.0 on intel site?

 

 :Smile:  if you download it and check the changelog it seems that its 0.0.69 version, so the number 1.0.0 is at least strane

@VinzC: i did succesfully emerge your ebuilds (good job) with versions:

        o  ieee80211-1.1.13

        o  ipw3945-0.0.73 (and even  0.0.74)

        o  ipw3945-firmware-1.13

        o  ipw3945d-0.7.16

and it works  :Smile:  i would like to write flawlessly but it's not. of course this not a problem of ebuilds but the driver itself.

i'm just loosing connnection with my AP and get the errors in logs about errors in decoding algorithms during authorization (i'm using WPA). BTW this behavior is a known bug.

the solution is not very "nice" but works: simply reload the driver.

ps. i'm using vanilla kernel 2.16.16 with the newest ACPI patches and i'm running  ~x86

----------

## firebeard

Hi,

thanks for the fabulous ebuilds first!

usually i don't need wireless so I want to deactivate it.

but all fails:

0) ipw3945d --kill

1) /etc/init.d/net.eth1 stop

2) modprobe -r ipw3945 || rmmod -f ipw3945

even after compiling a new kernel and rebooting

lsmod still shows the module [permanent] and it's dependencies.

it's like magic???

how can I get rid of the module and load and unload it at will?

----------

## Sejam

 *firebeard wrote:*   

> Hi,
> 
> thanks for the fabulous ebuilds first!
> 
> usually i don't need wireless so I want to deactivate it.
> ...

 

I've used rmmod myself and that works.  I really don't do that too much though.  If I want to turn the wireless off, I just use Fn-F2 and mine turns off.

----------

## VinzC

You can also put the module name in /etc/hotplug/blacklist if you don't need it for a long time. Remember however once the module name is there you must remove it manually from the file if you want to use the module again. The Fn+F2 key combo is more elegant in this case as the BIOS remembers the state of your WiFi, i.e. the RF-Switch state survives a reboot.

----------

## VinzC

 *quat wrote:*   

>  *firebeard wrote:*   what about linux driver 1.0.0 on intel site? 
> 
>  if you download it and check the changelog it seems that its 0.0.69 version, so the number 1.0.0 is at least strane

 

Interresting...

 *quat wrote:*   

> @VinzC: i did succesfully emerge your ebuilds (good job) with versions:
> 
>         o  ieee80211-1.1.13
> 
>         o  ipw3945-0.0.73 (and even  0.0.74)
> ...

 

Thanks a lot  :Smile: . When I tried version 0.0.73 the driver had troubles finding an access point to associate with. Glad to hear it worked for you.

 *quat wrote:*   

> I would like to write flawlessly but it's not. of course this not a problem of ebuilds but the driver itself.
> 
> i'm just loosing connnection with my AP and get the errors in logs about errors in decoding algorithms during authorization (i'm using WPA). BTW this behavior is a known bug.
> 
> the solution is not very "nice" but works: simply reload the driver.
> ...

 

Now I'm using Gentoo Sources and I experience connection drops only from time to time (2-3 a week at most). So I wonder if Gentoo Sources are responsible for bringing more stability. Have you tried version 0.0.71?

Note I'm using the stable x86 branch and only ~x86 packages when absolutely necessary (e.g. baselayout and bash). Maybe the instability you experience is due to the ~x86 branch itself.

----------

## HomerJ

I tried following the steps here, and can't for the life of me associate with my AP.

I get the driver loaded, the wifi light blinks really really fast, but I never manage to connect to my AP.

iwconfig shows the proper accesspoint name, but is says "unassociated".

All of that works fine in windows so I know my router is setup right.

Has anyone seen this while configuring your card?

----------

## VinzC

 *HomerJ wrote:*   

> I tried following the steps here, and can't for the life of me associate with my AP.
> 
> I get the driver loaded, the wifi light blinks really really fast, but I never manage to connect to my AP.
> 
> iwconfig shows the proper accesspoint name, but is says "unassociated".
> ...

 

See my post. Are you using driver version 0.0.72 or above?

----------

## HomerJ

I was, but after reading your reply, I went and tried 0.0.71, and still the same problem.  Man this thing is driving me nuts!

----------

## VinzC

ipw3945 is now in portage, version 0.0.74. Just one package is renamed: ipw3945-firmware (my naming convention) is renamed to ipw3945-ucode. Be sure to remove ipw3945-firmware before installing the drivers from portage!

It looks like version 0.0.74 needs a new version of the regulatory daemon. I'm testing it right now and I'm back if successful  :Smile: .

Brb...   :Arrow: 

(BTW today is a great day for updating stuff: XFCE4, Firefox, nvidia, kernel, alsa, wireless, baselayout, wireless, samba, mysql,...)

EDIT: it seems to work properly. I've installed the new regulatory daemon, the new driver, the microcode and the new ieee802.11 headers and it works. The only thing is now the WiFi LED blinks (i.e. like when scanning for wireless networks) but the wireless network is functional.

----------

## HomerJ

I'm glad it all works for you.  Are you using wpa or wep?  I think I can get wep going no problem, but wpa just won't...  I guess the problem might be with wpa_supplicant and not the driver.

It sucks to be me, as it's the only thing left preventing me to wipe XP and settle into gentoo...

----------

## soLaRiS tHe SuN

I had exactly the same symptoms as HomerJ (no association with ap and wireless led blinking fast) and I spent ages figuring out what's going wrong here. I tried everything (combinations of different versions of ipw3945, ipw3945d and ieee80211, etc.). After hours of wasted time and going nuts a couple of times I started to realize that I didn't add the new adapter's MAC address to the accesspoint's MAC ACL  :Very Happy: . Oh well, now it works like a charm!

----------

## HomerJ

This is where having a working dual boot into windows is handy.  I can at least test my sanity and go to windows to make sure it works there.  I am 100% confident the access point and card are working fine.  I'll try to rebuild everything from scratch tonight.  I really want to run gentoo on this laptop (Inspiron 6400/e1505).

EDIT:

I give up.  I tried every version, 2 or 3 different kernel sources, different baselayouts,  wpa_supplicant, wireless tools, you name it.  It just won't associate.  Off to another distro I guess, if only to prove myself I can do it.

EDIT2:

Wow, kubuntu didn't even finish the install without crapping out!!!  I'm back, I hope a fresh start will fix things up.

----------

## soLaRiS tHe SuN

Doesn't wpa_supplicant give you a specific error? Also try with increased debugging verbosity. These logs should actually show what is going wrong.

----------

## VinzC

 *HomerJ wrote:*   

> I'm glad it all works for you.  Are you using wpa or wep?  I think I can get wep going no problem, but wpa just won't...  I guess the problem might be with wpa_supplicant and not the driver.
> 
> It sucks to be me, as it's the only thing left preventing me to wipe XP and settle into gentoo...

 

I'm using WEP. To say the truth I don't even know what WPA is for  :Embarassed:  . Does it also handle WEP keys of encrypted wireless networks?

EDIT: Ok, now I know; I saw a link to a WiFi HOWTO on Gentoo Wiki in another thread. So the answer is "yes, it does".

----------

## soLaRiS tHe SuN

VincZ, is it you who maintains this ebuild? I noticed that the sed expression which modifies the Makefile doesn't work properly (space missing). So you can't build it with monitor mode etc. Fixed version here:

[1] http://sts.synflood.de/dump/ebuilds/ipw3945-0.0.74.ebuild

----------

## VinzC

 *soLaRiS tHe SuN wrote:*   

> VincZ, is it you who maintains this ebuild? I noticed that the sed expression which modifies the Makefile doesn't work properly (space missing). So you can't build it with monitor mode etc. Fixed version here:
> 
> [1] http://sts.synflood.de/dump/ebuilds/ipw3945-0.0.74.ebuild

 

No, I don't. You should therefore file a bug at Gentoo bugzilla.

----------

## HomerJ

 *soLaRiS tHe SuN wrote:*   

> Doesn't wpa_supplicant give you a specific error? Also try with increased debugging verbosity. These logs should actually show what is going wrong.

 

Not too sure how to debug this.  I can use wpa_cli to connect to wpa_supplicant, and from there I see:

<2>Trying to associate with MAC:ADDRESS:OF:MY:ACCESS:POINT (SSID='ssid' freq=0 MHz)

and then something to the effect that authentication with 00:00:00:00:00:00 failed.

Not sure why I have all 0s everywhere.  

For the record, I have reformatted, and started from scratch last night and I'm back to square 1. ;-(

----------

## widi

Hi all,

after 2days of trying, i did it. The module loads and the daemon starts up; but whats that:

```
 zeitdieb ~ # modprobe ipw3945 

2006-04-19 19:02:27: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

FATAL: Error running install command for ipw3945
```

dmesg shows

```
ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: ipw3945.ucode load failed: Reason -2

ipw3945: Could not read microcode: -2

ACPI: PCI interrupt for device 0000:05:00.0 disabled

ipw3945: probe of 0000:05:00.0 failed with error -2

```

does anybody know what's happing here?

or better know how to fix it?

here some infos:

hardware: 

Acer TravelMate 4202 WLMi

software

2.6.15-gentoo-r1

udev-079-r1

baselayout-1.11.14-r8

hotplug-20040923-r1

ieee80211-1.1.13

ipw3945-0.0.74

ipw3945-ucode-1.13

ipw3945d-1.7.18

many thanks in advance

----------

## HomerJ

Ok, so I scrapped my plans of using WPA and have gone back to WEP.  I can now associate ok with the the AP, but any attempt to use the connection results in not being able to connect.

(I can't ping any hosts, including the accesspoint itself).  If I log-in to the accesspoint from another PC, the AP thinks I'm connected and lists my Gentoo box as an associated client, which is good.

Since DHCP was always timing out, I've setup my ip, my gateway, etc manually.  It's got to be something I'm missing, and I'm losing patience!  The same happens with 3 different APs: 1 WRT54GS, 1 MN-700 running OpenWRT, and 1 D-Link DI-784.

Can someone who has it working post their /etc/conf.d/wireless, /etc/conf.d/net and /etc/wpa_supplicant.conf files for one DESPERATE gentoo addict?

----------

## Sejam

 *HomerJ wrote:*   

> Ok, so I scrapped my plans of using WPA and have gone back to WEP.  I can now associate ok with the the AP, but any attempt to use the connection results in not being able to connect.
> 
> (I can't ping any hosts, including the accesspoint itself).  If I log-in to the accesspoint from another PC, the AP thinks I'm connected and lists my Gentoo box as an associated client, which is good.
> 
> Since DHCP was always timing out, I've setup my ip, my gateway, etc manually.  It's got to be something I'm missing, and I'm losing patience!  The same happens with 3 different APs: 1 WRT54GS, 1 MN-700 running OpenWRT, and 1 D-Link DI-784.
> ...

 

If you scrapped WPA, then are you still using wpa_supplicant?  For WEP you do not need wpa_supplicant.conf.  I have version .94, using 64-bit wep and I'm able to connect just fine.  My net is the default blank list and the wireless has only my network id with the wep key.  My wireless is the WRT54G running OpenWRT.

----------

## VinzC

 *widi wrote:*   

> ...
> 
> dmesg shows
> 
> ```
> ...

 

Does the following command report the same output?

```
# ls -l /lib/firmware/

total 116

-rw-r--r-- 1 root root   2109 Apr 18 13:23 LICENSE.ipw3945-ucode

-rw-r--r-- 1 root root 111572 Apr 18 13:23 ipw3945.ucode
```

----------

## HomerJ

 *Sejam wrote:*   

> 
> 
> If you scrapped WPA, then are you still using wpa_supplicant?  For WEP you do not need wpa_supplicant.conf.  I have version .94, using 64-bit wep and I'm able to connect just fine.  My net is the default blank list and the wireless has only my network id with the wep key.  My wireless is the WRT54G running OpenWRT.

 

I'm starting to wonder if wpa_supplicant was not at fault all that time.  I finally managed yesterday to connect with iwconfig plain and simple to 64bit wep.  I then tried to do the same using wpa_supplicant and it worked for about 30 minutes, I even got WPA to work for a bit.  Bit it keeps dropping every few minutes, and takes forever to reconnect.  

Everything was rock solid overnight with iwconfig and wep, I emerged X, kde, and openoffice without problems. 

Ah well, good enough!

Oh!  It seems that in my case, I need to modprobe ieee80211_crypt_wep before I can get things working.  Was this the case for any of you?  If I don't modprobe this, the card associates to the AP, but I can't ping, get an ip through dhcp, etc.  I have never seen any mention of having to do this so I'm wondering why I have to do this.

----------

## VinzC

 *HomerJ wrote:*   

> Oh!  It seems that in my case, I need to modprobe ieee80211_crypt_wep before I can get things working.  Was this the case for any of you?  If I don't modprobe this, the card associates to the AP, but I can't ping, get an ip through dhcp, etc.  I have never seen any mention of having to do this so I'm wondering why I have to do this.

 

Which version of baselayout do you have?

----------

## HomerJ

 *VinzC wrote:*   

>  *HomerJ wrote:*   Oh!  It seems that in my case, I need to modprobe ieee80211_crypt_wep before I can get things working.  Was this the case for any of you?  If I don't modprobe this, the card associates to the AP, but I can't ping, get an ip through dhcp, etc.  I have never seen any mention of having to do this so I'm wondering why I have to do this. 
> 
> Which version of baselayout do you have?

 

Whatever is stable as of yesterday.  Packages db says "baselayout-1.11.14-r8"

----------

## VinzC

I have baselayout-1.12.0_pre17-r2 and it works rather well. Maybe you should consider upgrading. You'll be required to upgrade bash too but it's ok.

----------

## widi

 *VinzC wrote:*   

> 
> 
> Does the following command report the same output?
> 
> ```
> ...

 

yes. here's the output

```
# ls -l /lib/firmware/

total 120

-rw-r--r--  1 root root   2109 Apr 19 19:01 LICENSE.ipw3945-ucode

-rw-r--r--  1 root root 111572 Apr 19 19:01 ipw3945.ucode

```

As you can see they have the same byte-count.

I used the ebuilds from the portage-tree, but i don't think that this should be a problem.

----------

## gr0g

I'm experiencing the exact same problem. What's funny is that I had the non-ebuild version of ipw3945-0.0.73 working for over a month. I did an "emerge -u world" and suddenly I'm getting this problem. I have a feeling its happening because of the updated udev. 

 *widi wrote:*   

>  *VinzC wrote:*   
> 
> Does the following command report the same output?
> 
> ```
> ...

 

----------

## widi

hmm, i don't know what will happen if I just up/downgrade my udev-version

is it worth a try??

----------

## gr0g

 *widi wrote:*   

> hmm, i don't know what will happen if I just up/downgrade my udev-version
> 
> is it worth a try??

 

I don't know yet, I haven't tried it myself. I was asking here in hopes that someone else had tried. I enable "Generic Core verbose debugging" and it seems like hotplugging can't load the firmware. It seems to not know what the firmare directory is anymore. This is very annoying...

----------

## echalon

For all those who did a world upgrade... I have found that I can use version 0.0.74, but only with iee80211 version 1.1.12. using version 1.1.13 gives me the problem with iwconfig reporting "unassociated" for everything. 1.1.12 works fine, but now I can't do any further upgrades because 1.1.13 is a dependancy.

----------

## HomerJ

Somebody kick me, and kick me hard.  I mean HARD.

My system was so freshly installed, I didn't take the time to "emerge -u --deep world".

My reasoning was that I didn't need to spend time to install anything unless I could get the network to work.  After all, I wouldn't be wasting my time with gentoo unless I could get the network up and running.

Well DUH!!!  :Embarassed:   :Embarassed:   :Embarassed:   :Rolling Eyes:   This means I was running with the stage3 version of all the packages.  Whatever that is, my system just compiled updated for 2 hours to bring it up to date... and guess what.

Everything works now.  Kick me, and kick me hard!  I can't believe I spent the week on this.  Sorry for wasting your time.  That's what I get for installing gentoo while babysitting a 10 month old and a 4 year old.

----------

## VinzC

 *echalon wrote:*   

> For all those who did a world upgrade... I have found that I can use version 0.0.74, but only with iee80211 version 1.1.12. using version 1.1.13 gives me the problem with iwconfig reporting "unassociated" for everything. 1.1.12 works fine, but now I can't do any further upgrades because 1.1.13 is a dependancy.

 

It may be on your system only for I have successfully installed ieee80211-1.1.13 and it works. Now I have identified what makes the WiFi led blink: the led starts blinking (scanning, I think) when XDM starts. If I don't start X the led remains still.

----------

## VinzC

 *HomerJ wrote:*   

> My system was so freshly installed, I didn't take the time to "emerge -u --deep world".
> 
> ...
> 
> Everything works now.  Kick me, and kick me hard!  I can't believe I spent the week on this.  Sorry for wasting your time.  That's what I get for installing gentoo while babysitting a 10 month old and a 4 year old.

 

Don't blame it on these little creatures  :Wink:  . Now you know Gentoo emerge -u is there for a reason...

----------

## widi

solved my problem.

the problem was, that the initscript of hotplug didn't told the kernel where to find the hotplug binary (/proc/sys/kernel/hotplug was empty).

so i made the following:

```
zeitdieb ~ # which hotplug

/sbin/hotplug

zeitdieb ~ #  echo -n "/sbin/hotplug" >  /proc/sys/kernel/hotplug 

zeitdieb ~ # modprobe ipw3945

```

and dmesg shows:

```
eee80211_crypt: unregistered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, 1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 0.0.74

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 19 (level, low) -> IRQ 193

PCI: Setting latency timer of device 0000:05:00.0 to 64

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
```

iwconfig:

```
eth1      IEEE 802.11g  ESSID:"SomeNet"  Nickname:"SomeNick"

          Mode:Managed  Frequency:2.437 GHz  Access Point: DE:AD:BE:EF:00:00

          Bit Rate:36 Mb/s   Tx-Power:15 dBm   

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality=65/100  Signal level=-66 dBm  Noise level=-67 dBm

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:1   Missed beacon:0
```

So finally, it works    :Laughing: 

The only thing left is to make a script and add it to my rc   :Wink: 

----------

## gr0g

 *widi wrote:*   

> So finally, it works   :lol:
> 
> The only thing left is to make a script and add it to my rc  :wink:

 

I had the same problem and discovered all I needed to do was an etc-update. Rebooted and it seems to be fine again...

----------

## asiobob

Greetings,

I just saw this thread after I got the wifi working. For those who have problems you have hope because of the following

1. I have a Dell insprion 6400, "dual core centrino" wth IPW3945

2. I connect to an access point AGES away from my location with a weak signal

3. I need WPA Enterprise to authenticate, i,e EAP-TTLS

I installed ipw3945, I ran the script that removed the old ieee80211 from the kernel as I was told to do. Then the newer ieee80211 was installed along with everything else I needed.

For WPA you need CRC32 support in the kernel, as well as AES cipher. as mentioned in http://ipw3945.sourceforge.net/README.ipw3945

I have a ~x86 version of baselayout (1.12.0_pre17-r3). I installed the last ~arch version of wpa_supplicant and my config for that is pretty much

```

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

eapol_version=1

ap_scan=1

fast_reauth=1

network={

        ssid="YOURSSID"

        key_mgmt=WPA-EAP

        eap=TTLS

        anonymous_identity="anonymous"

        identity="USERNAME"

        password="YOURSECRET"

        priority=2

        phase2="auth=PAP"

}
```

Thats right! I authenticate with a username/password not a shared key.

I configured /etc/init.d/net to suit, just follow the comments! *BUT* here is the thing that got me. the same readme file I refer to says for newer kernels use the -Dext option (driver option) for wpa supplicant and for older ones use -Dipw 

The latter spewed errors on teh screen, the former was "driver not supported". After some googling I discover it's meant to me -Dwext (note the w) and then when I start eth1 BINGO! it works! Authenticated and have been given and IP etc...

----------

## HomerJ

Is this in 11a or 11g mode?  I still can't get the 11a mode to work.  11g works fine.  I'm starting to wonder if the problem is not the AP itself.

----------

## mjelkins

I've been following the postings with great interest - trying and failing.. and now have  success.

I have an Acer TravelMate 8204WLMi with Built-in 3945 wireless (A/B/G)

In order to install - I did the following..

emerge  mm-sources  (new Kernel)  ** Don't use **

sh /usr/portage/net-wireless/ieee80211/files/remove-old

emerge ieee80211 (a few times!!)

emerge ipw3945 (also copied the ebuild a few days earlier)

rc-update add ipw3945d boot (this installs modules and runs a daemon)

I then got stuck.

iwconfig showed the module installed and looking healthy.

```

# iwconfig

eth1      unassociated  ESSID:"posix"

          Mode:Managed  Frequency=2.427 GHz  Access Point: 00:02:6F:21:E2:42

          Bit Rate:0 kb/s   Tx-Power:16 dBm

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:8   Missed beacon:0

```

Question was: How do I get my Wireless to become "associated" ??

Seems that something in 2.6.17 is broken. Moved back to 2.6.15 and everything is OK   :Confused: Last edited by mjelkins on Tue Apr 25, 2006 4:03 pm; edited 2 times in total

----------

## asiobob

 *HomerJ wrote:*   

> Is this in 11a or 11g mode?  I still can't get the 11a mode to work.  11g works fine.  I'm starting to wonder if the problem is not the AP itself.

 

if you were referring to my post, its 11g

----------

## zidour

Hi everyone,

first thanks for your great work.

Now to my problem:

I have installed ipw3945 and everything worked instantly. The only problem is, that I can't manage to start the ipw3945d daemon at boot. If i boot normally, then modprobe ipw3945, everything works fine. 

Then if i put "ipw3945" into /etc/modules.autoload.d/kernel-2.6, the module is loaded at boot, but the daemon is not started (if I modprobe the module by hand, the daemon IS started automatically and if I modporbe -r the module by hand, the daemon IS stopped automatically).

I think I am just missing somthing obvious...

This is my /etc/modules.d/ipw3945d (the lines were added by the ebuild I guess):

```

install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /sbin/ipw3945d --quiet

remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945

```

Versions I am using:

```

[ebuild   R   ] net-wireless/ipw3945-1.0.1  USE="-debug" 0 kB

[ebuild   R   ] net-wireless/ipw3945d-1.7.18  0 kB

[ebuild   R   ] net-wireless/ipw3945-ucode-1.13  0 kB

```

This is the tail of my /etc/modules.conf:

```

### modules-update: start processing /etc/modules.d/ipw3945

# modules.d configuration file for IPW3945

# For more information please read:

#    README.ipw3945

# Configurable module parameters

# ------------------------------

# antenna:      select antenna (1=Main, 2=Aux, default 0 [both])

# disable:      manually disable the radio (default 0 [radio on])

# associate:    auto associate when scanning (default 0 off)

# auto_create:  auto create adhoc network (default 1 on)

# led:  enable led control (default 1 on)

# channel:      channel to limit associate to (default 0 [ANY])

# rtap_iface:   create the rtap interface (1 - create, default 0)

# mode: network mode (0=BSS,1=IBSS,2=Monitor)

### modules-update: end processing /etc/modules.d/ipw3945

### modules-update: start processing /etc/modules.d/ipw3945d

install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /sbin/ipw3945d --quiet

remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945

### modules-update: end processing /etc/modules.d/ipw3945d

```

I am using standard configuration, no custom init scripts...

----------

## VinzC

Zidour, what's your version of baselayout, coldplug and hotplug?

----------

## zidour

Here it is:

```

~ # esearch -c coldplug hotplug baselayout

[ N] sys-apps/coldplug (20040920):  coldplug init.d program to load modules at bootime

[ I] sys-apps/hotplug (20040923-r2):  USB and PCI hotplug scripts

[ I] sys-apps/baselayout (1.12.0_pre18):  Filesystem baselayout and init scripts

```

i.e. coldplug is not installed. As far as I know it is deprecated anyway...

Thanks, VinzC!

----------

## VinzC

 *zidour wrote:*   

> Here it is:
> 
> ```
> 
> ~ # esearch -c coldplug hotplug baselayout
> ...

 

The packages I have are less recent though  :Rolling Eyes:  ... Have you run etc-update, modules-update, all that stuff?

EDIT: how about your udev version?

----------

## VinzC

 *zidour wrote:*   

> Then if i put "ipw3945" into /etc/modules.autoload.d/kernel-2.6, the module is loaded at boot, but the daemon is not started (if I modprobe the module by hand, the daemon IS started automatically and if I modporbe -r the module by hand, the daemon IS stopped automatically).

 

My /etc/modules.autoload.d/kernel-2.6 file only contains evdev, which fixes a problem with the touchpad. Try removing ipw3945 and putting evdev there. The latter must be compiled as a module, of course (you'd have bet  :Wink:  ).

----------

## zidour

Thanks for your suggestions....

I am running ~x86 architecture, so I have a quite recent udev...

```

radegast2 martin # esearch -c udev

[ I] sys-fs/udev (090):  Linux dynamic and persistent device naming support (aka userspace devfs)

```

I am quite sure that etc-update and modules-update is not the problem here.

I also tried removing ipw3945 from modules.autoload - did not work.

What I forgot is that I edited /etc/conf.d/rc file:

```

# Dynamic /dev managers can trigger coldplug events which cause services to

# start before we are ready for them. If this happens, we can defer these

# services to start in the boot runlevel. If you don't want this then set

# RC_COLDPLUG to no.

# For more fine grained control you can list full service names to allow

# them to coldplug and prefix them with ! so they don't coldplug.

# Example - RC_COLDPLUG="net.wlan !net.*"

# This allows net.wlan and any service not matching net.* to coldplug.

RC_COLDPLUG="no"

```

The problem is that if RC_COLDPLUG is set to "yes" (default), init scripts try to bring eth0 up even if net.eth0 is not in any runlevel.

I solved this problem by setting it to "no".

I must admit that I don't understand the consequences of this setting completely, so I thought resetting RC_COLDPLUG back to "yes" might help.

But it did not...

Still, ipw3945 gets loaded (supposedly by udev), but the daemon is not run.

If I rmmod and modprobe ipw3945 again, everything starts working again...

----------

## zidour

Well, I was looking around a bit and this is what I have found:

1) ipw3945 is inserted when udev is started. This is done at boot by "/lib/rcscripts/addons/udev-start.sh". Unfortunately I don't know what mechanism udev uses for inserting modules (is it possible that it is just insmoding instead of modprobing?). Anyway, when the module is inserted by udev, the daemon is not started.

2) An obvious resolution to my problem is to prevent udev from inserting ipw3945 module and modprobe it later (I think that just writing ipw3945 into /etc/modules.autoload.d/kernel-2.6 should work). However, I have no idea how to tell udev not to load ipw3945.

Blacklisting ipw3945 in /etc/hotplug/blacklist does not work.

May be it has something to do with this bug: https://bugs.gentoo.org/show_bug.cgi?id=130766.

It seems to me that udev is to blame...

----------

## HomerJ

What prevents you from letting the module load by itself, and start the daemon in local.start or with a custom init.d script?

I had the same problem, but it automagically fixed itself on my 6th attempt to intall gentoo!

----------

## zidour

You are right, nothing...

But it would be nicer and cleaner if it worked as it is supposed to work... anyway, I think starting the daemon somewhere in local.start will do it for now...

 *Quote:*   

> 
> 
> I had the same problem, but it automagically fixed itself on my 6th attempt to intall gentoo!
> 
> 

 

Unfortunately I am not that patient  :)

----------

## LD

I'm having issues with range. I was able to get to my couch before with Windows on this thing. I can't get past my work desk now with wireless connectivity. Any one else having issues with this?  Is there a setting I missed?

----------

## VinzC

 *LD wrote:*   

> I'm having issues with range. I was able to get to my couch before with Windows on this thing. I can't get past my work desk now with wireless connectivity. Any one else having issues with this?  Is there a setting I missed?

 

Maybe the big refrigerator in the middle of the path?  :Wink: 

----------

## Trev

Hello,

I have been banging my head against this wall for sometime now.  The problem I was getting was all modules would load but I couldn't associate to the AP using WPA.

Updating baselayout to the latest stable solved the problem.  Here is the list of relevant packages:

[I--] [  ] net-wireless/ipw3945-1.0.1 (0)

[I--] [  ] net-wireless/ipw3945-ucode-1.13 (0)

[I--] [  ] net-wireless/ipw3945d-1.7.18 (0)

[I--] [  ] net-wireless/ieee80211-1.1.13-r1 (0)

[I--] [  ] sys-kernel/gentoo-sources-2.6.16-r3 (2.6.16-r3)

[I--] [  ] sys-apps/baselayout-1.11.14-r8 (0)

A few notes:

-You must run the remove-old script to remove the in-kernel 80211 stack

-You must have (as a module or compiled in) support for michael_mic and arc4 crypto types (you may need aes as well)

For me the last piece was to upgrade baselayout from 1.11.14-r4 to 1.11.14-r8.  I hope this helps.  The other posts here have been helpful.  Thanks a lot

----------

## sashak

 *zidour wrote:*   

> Well, I was looking around a bit and this is what I have found:
> 
> 1) ipw3945 is inserted when udev is started. This is done at boot by "/lib/rcscripts/addons/udev-start.sh". Unfortunately I don't know what mechanism udev uses for inserting modules (is it possible that it is just insmoding instead of modprobing?). Anyway, when the module is inserted by udev, the daemon is not started.
> 
> 

 

In my case the daemon is started, but fails - /var fs is readonly at this moment and ipw3945d cannot write /var/run/ipw3945d.pid file. (actually you may see this when replacing 'ipw3945d --quiet' by ipw3945d > /dev/ipwd.log 2>&1 in /etc/modprobe.conf ). Unfortunatly ipw3945d is binary-only and after looking at 'strings ipw3945d' I cannot see obviuos way to reconfig the daemon itself. However such ugly workaround should help:

```

mv /var/run/ipw3945d.pid /dev

ln -s /dev/ipw3945d.pid /var/run/

```

Good luck.

----------

## zidour

To sashak:

OK, this sounds logical...

I will give it a try when I get home.

----------

## TrevorCampbell

 *zidour wrote:*   

> To sashak:
> 
> OK, this sounds logical...
> 
> I will give it a try when I get home.

 

I have the same problem, but the driver says it loads OK..  I get no errors in the ipwd.log using the above hack.  Also the driver loads after the root file system is remonted as readwrite.

I usually 

```
# rmmod ipw3945 

# modprobe ipw3945
```

and then all works, but it is a PITA to do each time.

----------

## VinzC

@TrevorCampbell

First you should use modprobe -r instead of rmmod. I had also such troubles with ipw3945 but the latest version from portage (1.0.2) seemed to fix these (you'll probably have to unmask them using ~ARCH).

----------

## TrevorCampbell

 *VinzC wrote:*   

> @TrevorCampbell
> 
> First you should use modprobe -r instead of rmmod. I had also such troubles with ipw3945 but the latest version from portage (1.0.2) seemed to fix these (you'll probably have to unmask them using ~ARCH).

 

I seem to have the latest 

```
# ACCEPT_KEWORDS="~x86" emerge -pv ipw3945

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-wireless/ipw3945-1.0.3  -debug 0 kB
```

----------

## Jobbe

Having given up on trying to get gentoo working correctly I decided I had to give it one more shot and threw out Win again. 

So I installed ipw3945 from portage, did 'modules-update' as the installer

instructed me to do and also added 'ipw3945' to /etc/modules.autoload.d/kernel-2.6.

```
cat /usr/src/linux/.config|grep IEE80211

# CONFIG_IEEE80211 is not set
```

During boot, loading of ipw3945 fails.

This is the end of dmesg:

```
ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, 1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.0.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 16

PCI: Setting latency timer of device 0000:03:00.0 to 64

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

Real Time Clock Driver v1.12ac

```

So my kernel set the tainted flag. I read this might have something to do with software

beeing proprietary, but where's the connection to ieee80211?

Well, the thing is, after boot eth1 (my wlan interface) doesn't exist. ipw3945d

does not run either. When start the regulatory daemon manually, the interface pops up and everything works just fine.

Any ideas?

lspci:

```
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)

00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller (rev 01)

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network

Connection (rev 02)

09:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)

09:09.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09)

09:09.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)

09:09.3 System peripheral: Ricoh Co Ltd Unknown device 0843

09:09.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 09)

09:09.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 04)

```

----------

## VinzC

@Jobbe: Have you installed ieee80211 from portage?

----------

## Jobbe

Yeah, that's what I did. I also removed the inkernel stuff with this somewhat lengthy command"/bin/.. ... remove-old ... ..", if you know what I mean.

----------

## Jobbe

Allright guys, I managed to fix it, although this seems like a rather ugly workaround. Anyway, here is what I did:

-removed ipw3945 from /etc/modules.autoload.d/kernel-2.6

-created /etc/init.d/ipw3945

```

#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

start() {

   modprobe ipw3945

}

stop() {

   ipw3945d --kill

   sleep 0.5

   modprobe -r ipw3945

}

```

-made sure this file was executable: chmod +x /etc/init.d/ipw3945

-added it to default runlevel: rc-update add ipw3945 default

And boom, it worked. Weeeehaaa  :Smile: 

----------

## VinzC

Ah I see: ipw3945 must not be in /etc/modules.autoload.d/kernel-2.6 otherwise coldplug/hotplug won't have any chance to trigger the mechanism that makes the daemon run automatically when the module is inserted. That file must be used only with modules that coldplug/hotplug do not succeed in loading or that are loaded incorrectly (e.g. 8139too and 8139cp).

On my laptop that file is almost empty - there is only evdev. coldplug takes care of inserting ipw3945 module when scanning PCI for hotplug devices. Then the daemon is run thanks to the insert/remove instructions in /etc/modules.d/ipw3945.

----------

## Jobbe

Oh, so my little script is useless? Lol. At least it looked like it was working, I guess that's enough. Give me praise.   :Laughing: 

Thanks for making things a little clearer  :Wink: 

edit: I tried not using my little script thus leaving everything to coldplug - it doesn't work. So my script is back on duty and I'm happy :]

----------

## VinzC

This is yet something I don't understand. It works as mentionned by Intel only for a couple of people if I track down the comments that have been posted. Not that I don't trust what they say but I'm really curious as to know what could prevent the daemon from loading...

Maybe one hint: on my machine there are a lot of services that take time to start: MySQL, Apache, XDM, ntp, hald, cups, ssh... Maybe giving some time for the daemon to start is key, I'm not sure. But I already noticed WiFi takes quite a moment to start and I couldn't get rid of some errors until I added a few time-consuming services to my default runlevel.

Something that I find very strange is that the WiFi led starts blinking (i.e. like when scanning WiFi networks) as soon as XDM starts. If I remove XDM from the default runlevel the WiFi led remains still. It starts blinking when I start X again. So there must be an interaction between X and the WiFi led I think - even if it sounds crazy. So I also think that might be another hint as to why many of us can't succeed in having the regulatory daemon automatically start.

----------

## pinky99

Hi all,

so i have a question concerning the ieee80211 software:

As far as I understand from the READMEs and the previous posts, the ieee80211 stack delivered by kernel 2.6.16 has not a sufficient version of this stack, and you have to install it separately.

So at what kernel is a sufficient version included, maybe in 2.6.17?

Has anybody tried that? 

I really don't like installing additional kernel modules on its own, because I have to think about them and also reinstall it everytime I change to a new kernel.

So at this state I don't desparately need wireless network, and I therefore would wait until it is included in the normal kernel. But if someone points me, that it's already in 2.6.17mm I would go for that, though I couldn't find any hints about the used 80211 versions in the different kernel versions...

Thanks in advance,

Maximilian

----------

## VinzC

 *pinky99 wrote:*   

> So at this state I don't desparately need wireless network, and I therefore would wait until it is included in the normal kernel.

 

IMHO you might have to wait very long for ipw3945 isn't just like a modified ipw2200. See the proprietary daemon from Intel. The complete package depends on that proprietary binary, which doesn't comply with the GPL. Unless devs have reversed engineered that binary I don't expect any kernel built-in feature for that card before long. But I might be wrong.

I personnally don't like the concept of a "regulatory" daemon. As if there were anything a kernel module couldn't do... Such a binary is good for Intel to keep control on their chip but not for Linux. Ok, what about nVidia or ATI then? But we still have the choice (GPL'ed or proprietary drivers) in the latter case. In the former we don't.

So - coming back to your question - feel (hem) free to use the module from portage anyway. That's what all of us do at the moment and I don't think we all change our kernel that often. So it's not (yet) a pain in the ***. Just don't forget to patch for SD-Card reader - which will in turn be included in 2.6.17.

----------

## Jobbe

Hm doesn't anybody want to do some rev-eng and write a nice little GPL'd module that works like a charm and makes our lives easier?   :Rolling Eyes: 

Nah, but to be honest, I think if the driver works well enough for most people there won't be a really _free_ version too soon...

----------

## bigmauler

a new version is out. It is supposed to be a bug fix.

----------

## bigmauler

I often run into this after using the web for a little while...

Output of dmesg:

```
ipw3945: Microcode SW error detected.  Restarting.

ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000 ser 0x00030000

ipw3945: Can't stop Rx DMA.

ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

ipw3945: Microcode SW error detected.  Restarting.

ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000 ser 0x00030000

ipw3945: Can't stop Rx DMA.

ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

ipw3945: Microcode SW error detected.  Restarting.

ipw3945: Error Reply type 0x000000FF cmd DAEMON (0x10) seq 0x040D ser 0x00030000

ipw3945: Error sending cmd #08 to daemon: time out after 500ms.

ipw3945: Can't stop Rx DMA.

ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

ipw3945: Microcode SW error detected.  Restarting.

ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000 ser 0x00030000

ipw3945: Can't stop Rx DMA.

ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

ipw3945: Microcode SW error detected.  Restarting.

ipw3945: Error Reply type 0x000000FF cmd TX (0x1C) seq 0x0000 ser 0x00050000

ipw3945: Can't stop Rx DMA.

```

Has anyone run into this? Solutions?

----------

## max2k5

 *VinzC wrote:*   

>  *pinky99 wrote:*   So at this state I don't desparately need wireless network, and I therefore would wait until it is included in the normal kernel. 
> 
> IMHO you might have to wait very long for ipw3945 isn't just like a modified ipw2200. See the proprietary daemon from Intel. The complete package depends on that proprietary binary, which doesn't comply with the GPL. Unless devs have reversed engineered that binary I don't expect any kernel built-in feature for that card before long. But I might be wrong.
> 
> 

 

Hmm, okay, I see. But if at least just the 80211-stack was of the right version in the kernel, I wouldn't have to patch the kernel as I have to do now to install the latest (not in kernel included) version of the 80211.

BTW, did anyone try the windows drivers via ndisloader, ndiswrapper or linuxant?

max

----------

## VinzC

 *max2k5 wrote:*   

> BTW, did anyone try the windows drivers via ndisloader, ndiswrapper or linuxant?

 

Forget about it...

P.S.: I tried ndiswrapper with my Centrino Duo (it's mentionned you have to turn off SMP in your kernel configuration). It didn't work.

----------

## VinzC

 *bigmauler wrote:*   

> I often run into this after using the web for a little while...
> 
> Output of dmesg:
> 
> ```
> ...

 

I also experience such sort of messages. Before that I got kernel module panics instead. Now all I get at worst is a more or less long hanging period. The computer doesn't respond and seems locked up for a short while and then unfreezes by itself. Everytime I looked at the log there was such a message.

Note however my laptop froze for a very long period (more than I could bear) yesterday evening. I had to forcibly turn it off.

----------

## pinky99

 *VinzC wrote:*   

>  *max2k5 wrote:*   BTW, did anyone try the windows drivers via ndisloader, ndiswrapper or linuxant? 
> 
> Forget about it...
> 
> P.S.: I tried ndiswrapper with my Centrino Duo (it's mentionned you have to turn off SMP in your kernel configuration). It didn't work.

 

Actually I tried it today (ndiswrapper-1.15, with W39N51.SYS windows driver) on my Core Duo Thinkpad (SMP, x86, 2.6.16-r7), and it compiled well, and even loaded without a problem!

I just haven't tried to connect to an AP, but I will try that tonight and I'll inform you.

max

----------

## VinzC

Thanks pinky99. I don't need ndiswrapper anymore for ipw3945 works as expected but I'm sure it'll help others.

----------

## dmartinsca

I've just moved from x86 to ~x86 and ipw3945d has stopped loading on boot. This update included moving from <udev-089 to udev-090 so I had to remove coldplug as udev(i think?) now includes the same features. I added !net.* to RC_PLUG_SERVICES so that the startup scripts for eth0 and eth1 are not started when the modules are loaded. I get no output from ipw3945d so it seems it's not being run at boot even though the module is loaded automagically.

----------

## rhill

blame udev's retarded 'hey let's load every module we find whether the user wants us to or not' mentality.  it loads the module but doesn't start the daemon.

here's a bit of a workaround:

```
# cat /etc/conf.d/local.start 

/sbin/modprobe --ignore-install ipw3945; sleep 0.5; /sbin/ipw3945d --quiet
```

```
# cat /etc/conf.d/local.stop

/sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945
```

```
# cat /etc/conf.d/net

# ethernet (eth0)

config_eth0=( "dhcp" )

dhcpcd_eth0=( "-t 15" )

# wireless (eth1)

modules=( "iwconfig" )

config_eth1=( "dhcp" )

key_dirtyepic=( "s:************** enc open" )

dhcpcd_eth1=( "-t 20" )

preup() {

   case ${IFACE} in

   "eth0" )

      if ethtool ${IFACE} | grep -q 'Link detected: no'; then

         ewarn "No link on ${IFACE}, aborting configuration"

         return 1

      fi

   ;;

   "*" )

      return 0

   ;;

   esac

}
```

```
# cat /etc/conf.d/rc | grep "PLUG" | grep -v "#"

RC_HOTPLUG="yes"

RC_COLDPLUG="yes"

RC_PLUG_SERVICES=""
```

the preup bit is needed to get the interface automatically configured by /etc/conf.d/net.  otherwise you'll have eth1 present but not enabled.  it also keeps eth0 from trying to get an address from DHCP when there's no cable plugged in.   you'll need to emerge ethtool for it all to work.

----------

## VinzC

 *dirtyepic wrote:*   

> blame udev's retarded 'hey let's load every module we find whether the user wants us to or not' mentality.  it loads the module but doesn't start the daemon.

 

So if udev can be responsible for the daemon not to start while on my machine the driver loads fine and the daemon activates itself normally then I have a good version of udev, right?

----------

## agnitio

I've had the same problem on my Asus A6J. My solution was a simple init-script that started the daemon:

/etc/init.d/ipw3945d:

```

#!/sbin/runscript

depend() {

        before net

}

start() {

        ebegin "Starting ipw3945d"

        start-stop-daemon --start --quiet --exec /sbin/ipw3945d

        eend $?

}

stop() {

        ebegin "Stopping ipw3945d"

        start-stop-daemon --stop --quiet --pidfile /var/run/ipw3945d.pid

        eend $?

}

```

I'm not sure I got the depend part right though because it seems it does not start until after my network interfaces, although it's early enough to make stuff work.

----------

## YourDoom123

I'm running an Acer 5672WLMi that uses the intel 3945a/b/g wifi card

The problem:

The driver installs fine... ie, emerge finishes w/o any problems. But, when I try to do a modprobe ipw3945, it spits out a bunch of errors, which I will do my best to type out here (different machine):

```

WARNING: Error inserting ieee80211_crypt (/lib/modules/2.6.17-rc2/net/ieee80211/ieee80211_crypt.ko): Invalid module format

WARNING: Error inserting ieee80211 (/lib/modules/2.6.17-rc2/net/ieee80211/ieee80211.ko): Invalid module format

WARNING: Error inserting ieee80211_crypt (/lib/modules/2.6.17-rc2/net/ieee80211/ieee80211_crypt.ko): Invalid module format

WARNING: Error inserting ieee80211 (/lib/modules/2.6.17-rc2/net/ieee80211/ieee80211.ko): Invalid module format

FATAL: Error inserting ipw3945 (/lib/modules/2.6.17-rc2/net/wireless/ipw3945.ko): Invalid module format

2006-06-04 00:25:12: ERROR: opening /sys/bus/pci/drivers/ipw3945:

No such file or directory (2)

2006-06-04 00:25:12: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

FATAL: Error running install command for ipw3945

```

my kernel is actually 2.6.17-rc3-no2, but modprobe kept looking for the 2.6.17-rc2 folder, so i created a link to the actual folder, and that fixed my initial problems. Running modules-update yielded the addition of the second set of errors (everything starting with the first 2006). I really need to get my wireless up and running. It's pretty much essential. If I can't, I have to bite the bullet, and switch distros. I love gentoo, and would hate to have to do that, but I've been struggling with this for weeks. Any help is appreciated.

----------

## VinzC

@YourDoom123: Did you switch GCC recently?

----------

## YourDoom123

damn... and i thought tht went bug free...

no, i didn't switch gcc (this is a fresh install), but i am using gcc 4.2. Someone give me confirmation that this is the problem before i switch it, cause it means hours of recompiling...

EDIT: i should have done it from the start: keep both gcc 4.2 and 4.1.1 installed to switch between when things broke... duh! im such an idiot sometimes...

EDIT: I'm trying another recompile, but the first one did nothing. I get the exact same errors. Any new ideas?

----------

## YourDoom123

yep... no joy. again, any help is apreciated..

----------

## VinzC

Since GCC 4.x is currently either masked or unstable, I'd recommend at least trying with the latest stable version, 3.4.6-r1.

----------

## YourDoom123

wait what? gcc 4.1 made is in portage now. Its no longer masked, at least, I don't think so. I'll try 3.4.6, but idk...

----------

## dmartinsca

gcc-3.4.6-r1 is the latest stable version, 4.1.0-r1 and 4.1.1 are both in testing for x86

----------

## th1nk3r

Works for me in my Asus A6J with:

- gentoo-sources-2.6.16-r9

- gcc-4.1.1

- baselayout-1.12.0-r1

- ieee80211-1.1.13-r1

- ipw3945-1.0.5

- ipw3945d-1.7.18

- ipw3945-ucode-1.13

There is only a bug with the wifi led. When connect to the AP, the wifi led starts blinking very fast and only stops if I disconnect the wifi. Anybody knows how to stop the blinking?

Thanks

----------

## antoine_

Hi

I have a laptop with an Intel 3945 card.

I installed the drivers, as said in this thread. It worked. Now, I can load the module :

```

mini_syrt linux # modprobe ipw3945

mini_syrt linux # lsmod

Module                  Size  Used by

ipw3945               124584  -

[...]

```

I also launch the daemon :

```

mini_syrt linux # ipw3945d

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.18

Intel PRO/Wireless 3945ABG Network Connection found at:

 /sys/bus/pci/drivers/ipw3945/0000:02:00.0

Daemon launched as pid 27775.  Exiting.

```

But iwconfig does not show me any wireless interface :

```

mini_syrt linux # iwconfig

eth0      no wireless extensions.

lo        no wireless extensions.

sit0      no wireless extensions.

ip6tnl0   no wireless extensions.

```

I have no idea about what to do. Any hints ?

Thanks !

----------

## dmartinsca

Is eth0 your wireless card? I would guess not. Try ifconfig eth1 up - normally this is handled by /etc/init.d/net.*

----------

## viniciusferrao

 *agnitio wrote:*   

> I've had the same problem on my Asus A6J. My solution was a simple init-script that started the daemon:
> 
> /etc/init.d/ipw3945d:
> 
> ```
> ...

 

I'm using your script, and this works perfectly!

----------

## gtranche

hi,

first, sorry for my poor english.

i have some problems with my ipw3945

i can load the module,

the daemon start perfectly

but with my netgear router, i have after 10 15 minutes a disconnection

and in my dmesg i have this:

ipw3945: Error sending cmd #08 to daemon: time out after 500ms.

i have to reboot my computer to have this worked.

On another router ( livebox ) i do not have any problem.

I have tested the 1.0.3 and the 1.0.5 driver

any one have an idea?

thanks

----------

## Aesthetics

excuse me, it's possible to load ipw3945d at boot?

because i must launch ipw3945d always in console when i want to use wireless

----------

## VinzC

 *Aesthetics wrote:*   

> excuse me, it's possible to load ipw3945d at boot?
> 
> because i must launch ipw3945d always in console when i want to use wireless

 

Sure. Make sure /etc/modules.d/ipw3945d says:

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet

remove ipw3945  /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945
```

However it seems many people see it doesn't always work. It does on my laptop so you might give it a try. Just make sure you have the latest version of wireless-tools, baselayout, udev and kernel.

----------

## Aesthetics

i've test it and it doesn't work  :Sad: 

----------

## VinzC

So see viniciusferrao's above post.

----------

## VinzC

I have a big freeze when I close the lid if both the following conditions are true:

WiFi is active

the current console is in graphics mode (Xorg)If I switch to a text console and close the lid the laptop doesn't hang. If I disable the WiFi (Fn+F2) the laptop doesn't freeze either. If I enable WiFi and switch to XOrg and close the lid the computer freezes and the screen remains black when reopened. I must power off the computer.

I have a Dell Inspiron 9400, Xorg-7.0-r1, ipw3945-1.0.5, ipw3945-ucode-1.13 and ipw3945d-1.7.18. Did anyone run into the same trouble?

----------

## VinzC

For your information

I found an unexpected file in /etc/modules.d/: ipw3945d (mind the ending d). Its content is as follows:

```
# cat /etc/modules.d/ipw3945d

install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /sbin/ipw3945d --quiet

remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945
```

It looks like portage's ipw3945 (not my ebuild) does put that file there to address Intel's recommendations on loading the regulatory daemon automatically:

```
# equery b ipw3945d

[ Searching for file(s) ipw3945d in *... ]

net-wireless/ipw3945d-1.7.18 (/etc/modules.d/ipw3945d)

net-wireless/ipw3945d-1.7.18 (/sbin/ipw3945d)
```

To all people who reported the daemon doesn't automatically load at boot

... ignore the line where you're told to add the above lines to /etc/modules.d/ipw3945. Don't change that file and use the defaults instead. After a couple of tests, it turns out the daemon is responsible for bringing up the interface when pressing Fn+F2 (aka the RF-Kill switch) to turn WiFi back on. The module doesn't load automatically when WiFi comes back on if the regulatory deamon is not running.

----------

## Stormblazer

Working great with an HP Pavillion dv5000, even the wifi on/off switch works.

My only complaint is that if the wifi switch was set to off on boot, and i try to load the daemon, and I'm in range of an encrypted network, the keyboard stops responding completely.

----------

## iplayfast

Fn-F2 starts the led doing a slow flash (once a second)  but my computer seems locked up.

After rebooting...

lsmod shows

eth1394 

ipw3945

ohci1394

ifconfig shows eth0 eth1 and lo

eth1 (the wireless) shows 

Link encap:UNSPEC

running /sbin/ipw3945d

looks happy

ifconfig shows no change

iwconfig shows 

lo             no wireless extensions.

eth0         no wireless extensions.

eth1         no wireless extensions.

dmesg shows (at the end)

ipw3945: Radio Frequency Kill Switch is On:

Kill switch must be turned off for wireless networking to work.

Any ideas?

----------

## agnitio

My ipw3945 recently stopped working. I updated to the latest version 1.1.0_pre2 and also the latest ipw3945d. Now my computer hard freezes whenever ipw3945d is loaded. I tried downgrading both the driver and the daemon but the error persists, wich suggests that there is something else causing the problem. Probably after my last sync/update. Has anyone else been having problems with the driver recently?

As of now I can't get any debug info. /var/log/messages remains untouched and since the computer freezes entirely I can't read dmesg. I don't have a clue what to do.

----------

## iplayfast

If you go on the site and get their drivers manually you can get newer versions which don't hang your system. I can't get it to work (never have) but at least your system won't hang.

----------

## VinzC

 *agnitio wrote:*   

> My ipw3945 recently stopped working. I updated to the latest version 1.1.0_pre2 and also the latest ipw3945d. Now my computer hard freezes whenever ipw3945d is loaded. I tried downgrading both the driver and the daemon but the error persists, wich suggests that there is something else causing the problem. Probably after my last sync/update. Has anyone else been having problems with the driver recently?

 

Since the drivers are in portage I always used the stable versions and experienced no problems of this kind. Here's what I have now:

```
$ equery l ipw

[ Searching for package 'ipw' in all categories among: ]

 * installed packages

[I--] [  ] net-wireless/ipw3945-1.0.5 (0)

[I--] [  ] net-wireless/ipw3945-ucode-1.13 (0)

[I--] [  ] net-wireless/ipw3945d-1.7.18 (0)
```

```
$ equery l baselayout

[ Searching for package 'baselayout' in all categories among: ]

 * installed packages

[I--] [ ~] sys-apps/baselayout-1.12.1 (0)
```

```
$ equery l wireless

[ Searching for package 'wireless' in all categories among: ]

 * installed packages

[I--] [  ] net-wireless/wireless-tools-28 (0)
```

----------

## emitrax

I did too have problems loading the ipw3945 after an update of the system. The problem was due to hotplug , so I fixed the problem by running the following command as someone suggested in this thread

```

echo `which hotplug` > /proc/sys/kernel/hotplug
```

The module now load no problems, but no new interface is created. I get the following from the kernel

```
[4299079.094000] ipw3945: Radio Frequency Kill Switch is On:

[4299079.094000] Kill switch must be turned off for wireless networking to work.

```

Thanks in advance for your help

emitrax

----------

## VinzC

 *iplayfast wrote:*   

> ipw3945: Radio Frequency Kill Switch is On:
> 
> Kill switch must be turned off for wireless networking to work.

 

 *emitrax wrote:*   

> [4299079.094000] ipw3945: Radio Frequency Kill Switch is On:
> 
> [4299079.094000] Kill switch must be turned off for wireless networking to work.

 

And then there were two...  :Rolling Eyes: 

On my laptop:

```
# cat /proc/sys/kernel/hotplug

# which hotplug

/sbin/hotplug
```

BTW: what version of udev do you both use? I'm running udev-079-r2 (I have masked udev-087*).

----------

## emitrax

udev 087-r1

I don't know where to put the echo command to fix hotplug. I tried in the start script of the ipw3945 script that somebody suggest, but I'm looking for a better solution.

I still don't know how to disable the "kill switch" in order to make the card working.

EDIT: Problem solved. After I set some of the special keys with gnome keyshorcuts, fn+F2 starts working. May it be a coincidence?

Thanks for your help.

----------

## VinzC

 *emitrax wrote:*   

> udev 087-r1

 

If you can bear the UDEV warning message at boot, it's Ok.

 *emitrax wrote:*   

> I don't know where to put the echo command to fix hotplug. I tried in the start script of the ipw3945 script that somebody suggest, but I'm looking for a better solution.

 

Well I don't know either for I never had to fix hotplug. About the init script, yes, it should be not required. The daemon should load automagically. The only explanation that makes sense is that Intel prerequisites are not met with at least one of these packages: wireless-tools, kernel sources and version, ieee80211 version, baselayout.

 *emitrax wrote:*   

> I still don't know how to disable the "kill switch" in order to make the card working.
> 
> EDIT: Problem solved. After I set some of the special keys with gnome keyshorcuts, fn+F2 starts working. May it be a coincidence?
> 
> Thanks for your help.

 

The fixes that I saw with Google were to disable the Kill-Switch using the BIOS. I never had to do such manipulation on my Dell i9k4. I'm glad it works for you now.

----------

## inode77

 *antoine_ wrote:*   

> Hi
> 
> I have a laptop with an Intel 3945 card.
> 
> I installed the drivers, as said in this thread. It worked. Now, I can load the module :
> ...

 

Check if you've got wireless support enabled in your kernel.

```
CONFIG_NET_WIRELESS=y
```

----------

## coplaniuk

 *Stormblazer wrote:*   

> Working great with an HP Pavillion dv5000, even the wifi on/off switch works.
> 
> My only complaint is that if the wifi switch was set to off on boot, and i try to load the daemon, and I'm in range of an encrypted network, the keyboard stops responding completely.

 

Just got that laptop...and I'm going to start installing Gentoo tonight from LiveCD.  Any tips for getting the wireless to work?  I figure I'll have to install using my Ethernet connection.

----------

## coplaniuk

Hey guys...I got the driver working, got the scripts working.  I am able to connect to the hub...but I can't ping anything.  Any ideas how to troubleshoot?

----------

## VinzC

You should first check you have an IP address:

```
ifconfig
```

----------

## coplaniuk

I do.  But would it matter if I assigned it through /etc/conf.d/net (see this post).

Here's the output of ifconfig (formatting is off because I'm typing manually):

```

eth1

Link encap:Ethernet HWaddr 00:13:02:6C:4C:9A

inet addr: 192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:466 errors:78 dropped:236 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:77500 (75.6 Kb) TX bytes:48 (48.0 b)

Interrupt:18 Base address 0xc000 Memory:52000000-52000fff

```

And the output of iwconfig:

```

eth1

IEEE 802.11b ESSID:"beacon"

Mode:Managed  Frequency2.452 GHz  Access Point:  00:0D:88:28:C4:66

Bit Rate:11 Mb/s   Tx-Power:15 dBm

Retry limit:15  RTS thr:off  Fragment thr:off

Encryption key:off

Power Management:off

Link Quality=92/100  Signal level=-41 dBm  Noise level=-42 dBm

RX invalid nwid:0  Rx invalid crypt:154  Rx invalid frag:0

Tx excessive retries:0  Invalid misc:12  Missed beacon:0

```

I did just notice one peculiar error in dmesg however:

```

ipw3945:  Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945:  Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

ieee80211_crypt:  registered algorithm 'WEP'

ieee80211_crypt_wep:  could not allocate crypto API arc4

```

Anything else I can post to help?

----------

## coplaniuk

Anyone got any ideas?

----------

## Bonkie

Im having trouble on new install [Dell inspiron 6400]:

```
# modprobe ipw3945

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.22

2006-08-01 23:20:38: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection
```

dmesg:

```
ieee80211_crypt: unregistered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, 1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.0-pre2dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation
```

```
# ls -l /lib/firmware/

total 116

-rw-r--r-- 1 root root   2109 Aug  1 15:56 LICENSE.ipw3945-ucode

-rw-r--r-- 1 root root 111572 Aug  1 15:56 ipw3945.ucode
```

All ebuilds latest ~x86 versions from portage

As I dont get an error message, I have no clue where the problem might lie ...

tried some suggestions from this thread, but so far nothing helped   :Mad: 

Anyone ?

never mind ...   :Rolling Eyes:  the wifi was disabled in BIOS   :Embarassed:  now the daemon starts already   :Exclamation: 

----------

## Simplimus

Hi, Im using that ipw3945 for my laptop and it works fine in Ubuntu but when I installed Gentoo I ran into troubles. The driver itself works well, however I cannot set any passwords for the card.

```
flabellarius mk # iwconfig eth1 key s:einganzdummes

Error for wireless request "Set Encode" (8B2A) :

    SET failed on device eth1 ; Operation not supported.

```

Does anyone have any ideas on that? When emerging the driver I had to run some weird skript so that some 80211network stuff would be emerged. Might this be a kernel-issue? Im using the 2.6.17-r4. Did I forget some encryption in the kernel? I added all the encryptions this thing asked me for. Thx for your help.

My lspci just to be sure

```
flabellarius mk # lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

05:04.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)

05:06.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832

05:06.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)

05:06.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)

05:06.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)

05:06.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)
```

----------

## pzpz

I'm having the same exact ssue as Simplimus...

...with x86 and ~x86 versions of {ieee80211, ipw3945, ipw3945d, ipw3945-ucode}

My kernel is build with only CONFIG_NET_RADIO.

Any ideas?

----------

## Boomer

Simplimus and pzpz,

I've been having the same problem with:

```
Error for wireless request "Set Encode" (8B2A) :

    SET failed on device eth1 ; Operation not supported
```

So, I decided to go the easy way and eliminate WEP (temporarily). 

This is what I did to get it going. I'll mention that I too had problems getting ipw3945d to launch automatically, so I added the rc-script posted earlier.

```

sudo iwconfig eth1 txpower auto

sudo ifconfig eth1 up

sudo iwconfig eth1 essid MYNETWORK

sudo dhcpcd eth1

```

BAM! Works! Obviously the problem is now in my wireless configuration files or how the encryption is handled, but NOT with ipw3945 stuff.

emitrax, I think the first line will solve your problem with the kill switch.

I'll also note that the FN-F2 key combination also works now.

----------

## jetsaredim

I just got my driver working tonight, but it seems like its losing packets somewhere.  I'm only getting a transfer rate when downloading packages of about 20-35K/sec when other notebooks on the same wan get 180K/sec for the same packages.  Any thoughts?

----------

## neXyon

Hi,

I'm near an access point with WPA-PSK enabled and I'd like to use it, but wpa_supplicant shows an error which confuses me and I've tried EVERYTHING I could think to fix the problem ... no chance  :Sad: 

So I hope someone is able to help me here!

```
# wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant.conf

Trying to associate with MAC:ADDRESS:OF:THE:ACCESS:POINT (SSID='WLAN' freq=0 MHz)

Associated with MAC:ADDRESS:OF:THE:ACCESS:POINT

ioctl[SIOCSIWENCODEEXT]: Invalid argument

WPA: Failed to set PTK to the driver.

Authentication with MAC:ADDRESS:OF:THE:ACCESS:POINT timed out.
```

Does anyone know how to fix that problem?

Regards,

neXyon

----------

## VinzC

neXyon,

It looks like you have somewhere in your config files something like xxx=MAC:ADDRESS:OF:THE:ACCESS:POINT. Maybe in /etc/wpa_supplicant.conf.

----------

## neXyon

VinzC: no, I don't have that in my wpa_supplicant.conf and anywhere else...

The error

WPA: Failed to set PTK to the driver.

tells me that it is unable to set the thing what is called "pairwise" in the configuration file.

The access point uses TKIP and even if I configure it to CCMP it doesn't work.

My configuration is that simple:

```
ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=wheel

update_config=1

network={

   ssid="SSID"

   psk="PSK"

   priority=5

}
```

As it seems unable to set the encryption I built all Crypto stuff in the kernel, but it doesn't want to work...

[EDIT]

Finally got it.

It's a shade I even don't want to tell you the problem  :Embarassed: 

Anyway I don't mind if you laught about me because I cannot hear you  :Very Happy: 

The problem was, that the module ieee80211_crypt_tkip was not loaded I noticed that while I was trying out to compile the crypt stuff as modules and run ls -R /lib/modules.

However, I will maybe write an ipw3945 entry in the gentoo-wiki if I get the time to.

[/EDIT]

----------

## Antek Grzymala

Well, looks like I have another problem with the card. It has been running perfectly until now (with wpa_supplicant in many different networks both WEP and WPA-PSK), now - the introduction of baselayout-1.12.4-r2 breaks my system in a major way (please see the screenshot):

http://chopin.edu.pl/~antoni/kernel_oops.jpg

What happens is that trying to stop the net.eth1 service (eth1 is my ipw3945) gives my system a kernel panic. Don't be fooled by the "process metalog" string in the panic dump. The process mentioned is entirely random and could be "ksoftirqd/1" just as well as any other.

Reverting back to baselayout 1.12.1 fixes mysteriously the problem. This happens both on current stable ipw3945* packages and keyword-masked as well. I tried various 2.6.17.* vanilla kernels as well, no difference.

Any ideas?

[a]

----------

## VinzC

I don't have that problem but I'm running baselayout 1.12.1... So I'm a bit reluctant on testing later versions  :Confused:  .

----------

## Antek Grzymala

 *VinzC wrote:*   

> I don't have that problem but I'm running baselayout 1.12.1... So I'm a bit reluctant on testing later versions :? .

 

Unfortunately, later version (the one that breaks-my-gentoo) has gone into stable. So you have to go to some lenghts to *not* test it.

----------

## beatryder

I have been having a similar problem with my system.

I have a D620. And I get a kernel oops or panic when I shut down.

I will try and post a picture if I can.

----------

## beatryder

Here is a picture I took of the screen.

http://www.neucode.org/gallery/v/screenshots/hpim0551.jpg.html

----------

## Antek Grzymala

 *beatryder wrote:*   

> I have been having a similar problem with my system.
> 
> I have a D620. And I get a kernel oops or panic when I shut down.
> 
> 

 

Did reverting back to 1.12.1 solve your problem?

[a]

----------

## Antek Grzymala

 *Antek Grzymala wrote:*   

>  *beatryder wrote:*   I have been having a similar problem with my system.
> 
> I have a D620. And I get a kernel oops or panic when I shut down.
> 
>  
> ...

 

On a quick note: 1.12.4-r3 which went into portage still crashes my system.

----------

## baygins

I wanted to enable monitor and wiretap mode on and have looked at the documentation of the driver.  It says, 

```
CONFIG_IPW3945_MONITOR
```

 and 

```
CONFIG_IPW3945_PROMISCUOUS
```

 should be enabled.

I tried 

```
CONFIG_IPW3945_MONITOR=y emerge ipw3945
```

 but a subsequent 

```
modprobe ipw3945 mode=2
```

does not work. 

After doing a 

```
cat /sys/bus/pci/drivers/ipw3945/module/parameters/mode
```

 I get a 

```
0
```

 which I assume means the mode change command did not go through.

Any ideas how I could convince the emerge/compile process to respect the CONFIG flags referred to in Intel's build instructions?

Thank you,

--selim

----------

## Antek Grzymala

 *Antek Grzymala wrote:*   

> Well, looks like I have another problem with the card. It has been running perfectly until now (with wpa_supplicant in many different networks both WEP and WPA-PSK), now - the introduction of baselayout-1.12.4-r2 breaks my system in a major way (please see the screenshot):
> 
> http://chopin.edu.pl/~antoni/kernel_oops.jpg
> 
> ...
> ...

 

OK, I filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=143887

[a]

----------

## jetsaredim

I have a D620 also.  I'm running baselayout-1.2.4-r3.  I'm not crashing or anything, but I have horrible throughput.  I have another notebook on the same wlan that gets 180J/sec and the D620 only gets 20K/sec.

----------

## beatryder

There is a fix for this issue in the above report.

----------

## VinzC

 *Antek Grzymala wrote:*   

> OK, I filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=143887
> 
> [a]

 

Are you using an init script to run the regulatory daemon, ipw3945d? (Saw it reading the bug report comments.)

----------

## beatryder

As you read in the bug report I am using it yes.

----------

## Antek Grzymala

 *VinzC wrote:*   

>  *Antek Grzymala wrote:*   OK, I filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=143887
> 
> [a] 
> 
> Are you using an init script to run the regulatory daemon, ipw3945d? (Saw it reading the bug report comments.)

 

Nope. I understand the proposed fix requires this hack, but then, in my opinion, this should be fixed system-wide in baselayout, ipw3945d, and what not.

Therefore the bug should stay open till this is fixed properly.

----------

## VinzC

I believe an init script for loading the daemon could cause troubles in certain circumstances. Antek Grzymala, does your laptop successfully load the daemon when the module is loaded using the insert/remove instructions (in the module config file)?

----------

## Boomer

FINALLY! 

I solved my problems by adding ipw3945d to the depend() function in /etc/init.d/net.lo as in :

```

depend() {

   need localmount ipw3945d

   after bootmisc hostname

   use isapnp isdn pcmcia usb wlan

   (the rest of the script is here ...)

```

Now it works like a charm at boot.

----------

## trautenberg

thanks VinzC. I got it working!!! I only cannot recompile the kernel anymore. After I removed all the old files, recompiling the kernel gives me an error

```
make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.s', needed by `net/ieee80211/ieee80211_module.o'.  Stop.

make[1]: *** [net/ieee80211] Error 2

make: *** [net] Error 2

```

  Anyway, it seems that it does not matter and the wifi is working fine now. Thanks once again I did not even hope it will finally go.

----------

## VinzC

@trautenberg,

Run the following command again [answering "yes" throughout] and recompile; the error message should go way:

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

----------

## ONEEYEMAN

Hi, guys,

Thank you for this thread. It is very helpful.

I am just trying to install the wireless support for my Dell Wireless 1390 802.11g Mini-Card. I got the system up and running, and now, according to the following link, part "7. KERNEL REQUIREMENTS - Configuration" I have to set some aditional stuff.

I am using the latest stable kernel (2.6.17-r4-gentoo-sources), and my question is:

According to his part, I have to enable "Library routines -> CRC32 functions" as a module. However, when I looked at this option with "menuconfig", it's not accessible, I can't turn it on. When I looked at the help part, I can see that it depend on some huge list of options. Can someboy shed a light for me what I have to turn on for that to be accessible?

Also, do I have to use "modules" when configuring the kernel, or I can compile the "module" support in the kernel?

And, as far as I understood from this thread, all I will need to do afterwards, is:

1. Re-compile the kernel.

2. Load additional modules.

3. Reboot into the new kernel.

4. "emerge ipw3945".

Anything I missed?

Thank you.

----------

## VinzC

 *ONEEYEMAN wrote:*   

> I am using the latest stable kernel (2.6.17-r4-gentoo-sources), and my question is:
> 
> According to his part, I have to enable "Library routines -> CRC32 functions" as a module. However, when I looked at this option with "menuconfig", it's not accessible, I can't turn it on. When I looked at the help part, I can see that it depend on some huge list of options. Can someboy shed a light for me what I have to turn on for that to be accessible?

 

This is what I have:

```
$ zgrep CRC /proc/config.gz

CONFIG_CRYPTO_CRC32C=y

CONFIG_CRC_CCITT=m

CONFIG_CRC16=m

CONFIG_CRC32=y

CONFIG_LIBCRC32C=y
```

I never bothered with CRC32 kernel options because I think they're enabled by default when you select "certain" options (don't ask which though). I just had the choice with CRC16. So the question whether a module or built-in does not apply for I don't have the choice either.

 *ONEEYEMAN wrote:*   

> And, as far as I understood from this thread, all I will need to do afterwards, is:
> 
> 1. Re-compile the kernel.
> 
> 2. Load additional modules.
> ...

 

What do you mean by afterwards?

To get things clear, here are the two possible situations:

Install a new kernel

Change an existing kernel configuration

When you compile a new kernel, here are the steps (I'll skip the traditional steps to cd into the directory, make the symlink aso):

Eventually copy an existing configuration and run make oldconfig.

First compile your kernel for it'll create some files belonging to ieee80211 module; they are to be removed later.

Run /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux

Emerge ieee80211 and additional kernel modules like svgalib, nvidia; this may be accomplished by running module-rebuild rebuild.

Then follow these steps in either case:

Optionally make changes in you kernel config

Recompile and install your kernel w/ modulesIf you don't find module-rebuild on your system, simply emerge module-rebuild. This script takes care of all the "external" kernel modules that you installed using portage.

```
module-rebuild list    # Lists all the modules that should be re-emerged
```

```
module-rebuild rebuild    # Re-emerges all the required modules
```

Follow 1 through 6 for a new kernel or 5-6 only for changing an existing kernel. I personnally usually carry the same kernel configuration across kernels and updates are made automatically or interactively as needed when running make oldconfig. Hence my /etc/modules.autoload.d/kernel-2.6 doesn't change very often (e.g. not even once a year).

----------

## ONEEYEMAN

 *VinzC wrote:*   

> 
> 
>  *ONEEYEMAN wrote:*   
> 
> I am using the latest stable kernel (2.6.17-r4-gentoo-sources), and my question is:
> ...

 

Well, this option is disabled for me. It just showing couple of dashes. So, I don't know if it will be selected or not.

When you look at help for this item, you will see a big list of dependancies. So, I wonder, if I missed something to check, in order to enable this option... Besides there are some other options that said needs to be compiled as a modules...

 *VinzC wrote:*   

> 
> 
>  *ONEEYEMAN wrote:*   
> 
> And, as far as I understood from this thread, all I will need to do afterwards, is:
> ...

 

After I will be done with "make menuconfig". But here I already have the answer....   :Smile: 

Thank you.

----------

## ONEEYEMAN

OK,

The config option "CONFIG_CRC32" says following in the "Help" section of 2.6.17-r4-gentoo-sources:

```

Selected by: PCMCIA && PCCARD || BT_BNEP && NET && BT && BT_L2CAP || IEEE80211_CRYPT_WEP && NET && IEEE80211 || SIGMATEL_FIR && NET && IRDA && USB && EXPERIMENTAL || TUN && NET || ARM_AM79C961A && NET && !UML && NET_ETHERNET && ARM && ARCH_EBSA110 || ARM_ETHERH && NET && !UML && NET_ETHERNET && ARM && ARCH_ACORN || MACE && NET && !UML && NET_ETHERNET && PPC_PMAC && PPC32 || BMAC && NET && !UML && NET_ETHERNET && PPC_PMAC && PPC32 || OAKNET && NET && !UML && NET_ETHERNET && PPC && BROKEN || A2605 && NET && !UML && NET_ETHERNET && ZORRO || HYRA && NET && !UML && NET_EHERNET && ZORRO || ZORRO8390 && NET && !UML && NET_ETHERNET && ZORRO && ......

```

I found PCCARD options, however, I can't find PCMCIA. Can someboy, please direct me to this option?

Or I shoud follow the 3rd condition - IEEE80211_CRYPT_WEP && NET && IEEE80211?

Thank you.

----------

## VinzC

Given the numerous conditions that make CONFIG_CRC32 selected I'd say that you don't have to worry. CONFIG_CRC32 *will*be selected for you whenever you select, in the kernel configuration, the appropriate options that depend on CRC32. In fact there are quite a few options in the kernel that are selected automatically using the same mechanism. This is the case with CRC32.

So don't worry at all why you can't select it. I couldn't either and the system is working properly. Trust the makers of menuconfig for having things done automatically for you. Of course Intel has some recommendations but I didn't have to compile CRC32 as a module - for I simply had no choice. And it's working perfectly even though. So - I repeat - don't worry. Just tick (or emerge) the drivers for your hardware, compile and that's it  :Cool:  .

As a final note, this is what I have in Library routines:

```
<M> CRC-CCITT functions

<M> CRC16 functions

--- CRC32 functions

--- CRC32c (Castagnoli, et al) Cyclic Redundancy-Check
```

This is also what I have on any Gentoo Linux system I ever configured. Whether it is a laptop or a desktop.

----------

## MrWolf

Hello all,

Up until tonight I thought I was connecting to my access point , well iwconfig was telling me it was connected to my access point but I  was in the same boat as a lot of people, very confused as to why I could not actually get any network connectivity.

Here is how I fixed my issue:

After a lot of playing around I discovered that my access points channel number was 13 I manually tried to specify that on the cli using:

```
iwconfig eth1 channel 13
```

returns:

```
Error for wireless request "Set Frequency" (8B04) : SET Failed on device eth1; Invalid argument. 
```

After reading the message closely I decided to read up on which arguments are were valid: channels 1 - 10.

I sucessfully changed to channel 9 so I did the same for my AP rebooted it used iwlist to make sure the changes had taken affect:

```
iwlist eth1 scan
```

 and saw that my AP's channel was now 9 then issued: 

```
iwconfig eth1 essid <insert essid here>
```

Gave my interface and appropriate IP and Gateway and I was online via 802.11g!

This is actually documented in the readme however I did overlook it until I actually solved my problem if you need to see a list of supported 

channels it does mention using the iwlist freq command to get a list of usable channels.

My AP has channel 12 and 13 was just unlucky[/bug] I went for channel 13 so basically if you are having simular problems just make sure you are using a channel on your access point which is supported by iwconfig.

Hope it helps!

----------

## ONEEYEMAN

Thank you for the reply, VinzC.

Given that when upgraing the kernel, you are talking about ieee80211, do I need to select this options in my kernel?

 *VinzC wrote:*   

> 
> 
> First compile your kernel for it'll create some files belonging to ieee80211 module; they are to be removed later. 
> 
> Run /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux 
> ...

 

Thank you.

----------

## VinzC

No, you don't need kernel ieee802.11 support. However compiling the kernel first will strangely enough create a bunch of files that you need to remove *after* the first compile. Otherwise you'd get a warning when emerging ieee80211 and would be required to run the remove-all script again to proceed.

----------

## ONEEYEMAN

 *VinzC wrote:*   

> 
> 
> No, you don't need kernel ieee802.11 support. However compiling the kernel first will strangely enough create a bunch of files that you need to remove *after* the first compile. Otherwise you'd get a warning when emerging ieee80211 and would be required to run the remove-all script again to proceed.

 

Even hough I am not upgraing the kernel, and doing it on the fresh new install?

Thank you.

----------

## VinzC

The reason is both (kernel and portage) versions are mutually exclusive. So use one, remove the other. Note, in cases I was a little unclear, you don't need to run the remove-all script *every* time you recompile your kernel but right after the first time you compiled it.

----------

## ONEEYEMAN

 *VinzC wrote:*   

> 
> 
> The reason is both (kernel and portage) versions are mutually exclusive. So use one, remove the other. Note, in cases I was a little unclear, you don't need to run the remove-all script *every* time you recompile your kernel but right after the first time you compiled it.
> 
> 

 

You mean after

emerge <gentoo-sources>

right?

Thank you.

----------

## okapi

Hi Forum,

I browsed thru the forum but did find any similar bug. But then again the thread is already quite lenghty.

I tried to install ipw3945 on my system. It builds fine and the module loads but only when the hardware kill switch is on.

The moment that I put the kill switch to off the system hard freezes.

My kernel is gentoo-sources-2.6.17-r4 with my own config. 

I even tried with a genkernel vanilla config.  

I tried with almost any version of ieee80211, ipw3945, ipw3945d and ipw3945-ucode with exactly the same result.

As a fallback method, I tried to manually patch the kernel but the compile stops with a IEEE80211_VERSION not defined error.

My system is a Toshiba A100 SK9: Intel T2500 Centrino Core Duo 2.0GHz.

Did someone encountered a similar problem.

----------

## beatryder

 *VinzC wrote:*   

> The reason is both (kernel and portage) versions are mutually exclusive. So use one, remove the other. Note, in cases I was a little unclear, you don't need to run the remove-all script *every* time you recompile your kernel but right after the first time you compiled it.

 

You are close to correct. If you change your kernel config, and the recompile, you will have to remove the files again.

----------

## ONEEYEMAN

Thank you beatrider.

----------

## VinzC

 *beatryder wrote:*   

> You are close to correct. If you change your kernel config, and the recompile, you will have to remove the files again.

 

Hmmm... I never had to in such cases though...

----------

## VinzC

 *ONEEYEMAN wrote:*   

> You mean after
> 
> emerge <gentoo-sources>
> 
> right?
> ...

 

No.

I meant after:

```
emerge gentoo-sources && compile kernel
```

----------

## adlaiff6

I just started having a problem with the card in my Dell Inspiron E1505.  It was working perfectly before, then I started messing around with ACPI and did something to make it so that I have to hit Fn+F2 (the wireless switch) to get it working, which was no problem for a while.

Last night, I tried to connect to a hotel's wireless router.  No page would fully load (although they would start), while I could connect to IRC servers, not even a MOTD would show, and IMs were very very slow and unreliable.  Today I tried using the wireless connection again, and it messed up even worse.  I eventually figured out that if both ipw3945d was started, and the Fn+F2 switch was telling the card to be on, the computer would become unresponsive (as the WiFi LED blinked slowly).  Strangely, by "unresponsive" I mean that, while the computer would continue to run (if ipw3945d were started in the boot sequence, it would continue booting and end at the login prompt), and even the cursor would blink, but no input would be received, including background things like switching consoles, and I had to hard-reset to do anything.  The computer works fine other than that, it's just that if I start ipw3945d and turn the card on, it goes catatonic on me.

----------

## Drone1

I'm at a dead end on this one folks. Have read this entire thread and call no joy.

New Thinkpad T60P. Am running:

- 2.6.17.9

- gcc-3.4.4 (i386 for some reason; should be i686 as is make.conf... ??)

- ~x86

Did the normal modularize IEEE80211 in kernel ( kernel does not allow exclusion; modularize or build-in). Ran the 

'/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux' command and prompts for 'y/n' and then to comment out all 'CONFIG_IEEE80211' options in config, 'y/n'. Say yes to both....

Emerge ieee80211 which completes fine. Then try and emerge ipw3945; ipw3945d and ipw3945-ucode were previously emerged. My attempt to emerge ipw3945 produces this:

```

>> Emerging (1 of 1) net-wireless/ipw3945-1.1.0 to /

 * ipw3945-1.1.0.tgz MD5 ;-) ...                                                                                                   [ ok ]

 * ipw3945-1.1.0.tgz RMD160 ;-) ...                                                                                                [ ok ]

 * ipw3945-1.1.0.tgz SHA1 ;-) ...                                                                                                  [ ok ]

 * ipw3945-1.1.0.tgz SHA256 ;-) ...                                                                                                [ ok ]

 * ipw3945-1.1.0.tgz size ;-) ...                                                                                                  [ ok ]

 * checking ebuild checksums ;-) ...                                                                                               [ ok ]

 * checking auxfile checksums ;-) ...                                                                                              [ ok ]

 * checking miscfile checksums ;-) ...                                                                                             [ ok ]

 * checking ipw3945-1.1.0.tgz ;-) ...                                                                                              [ ok ]

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     2.6.17.9

 * Checking for suitable kernel configuration options...                                                                           [ ok ]

>>> Unpacking source...

>>> Unpacking ipw3945-1.1.0.tgz to /var/tmp/portage/ipw3945-1.1.0/work

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/ipw3945-1.1.0/work/ipw3945-1.1.0 ...

 * Preparing ipw3945 module

 WARNING: Your kernel contains ieee80211 symbol definitions and you

 are not using the kernel's default ieee80211 subsystem.  (Perhaps you

 used the out-of-tree ieee80211 subsystem's 'make install' or have

 provided a path to the ieee80211 subsystem via IEEE80211_INC.)

 If you wish to use the out-of-tree ieee80211 subsystem then it is

 recommended to use that projects' "make patch_kernel" facility

 and rebuild your kernel to update the Module symbol version information.

 Failure to do this may result in build warnings and unexpected

 behavior when running modules which rely on the ieee80211 subsystem.

make -C /usr/src/linux M=/var/tmp/portage/ipw3945-1.1.0/work/ipw3945-1.1.0  modules

 Aborting the build.  You can force the build to continue by adding:

        IEEE80211_IGNORE_DUPLICATE=y

 to your make command line.

make: *** [check_inc] Error 1

make: *** Waiting for unfinished jobs....

make[1]: Entering directory `/usr/src/linux-2.6.17.9'

  CC [M]  /var/tmp/portage/ipw3945-1.1.0/work/ipw3945-1.1.0/ipw3945.o

  Building modules, stage 2.

  MODPOST

  CC      /var/tmp/portage/ipw3945-1.1.0/work/ipw3945-1.1.0/ipw3945.mod.o

  LD [M]  /var/tmp/portage/ipw3945-1.1.0/work/ipw3945-1.1.0/ipw3945.ko

make[1]: Leaving directory `/usr/src/linux-2.6.17.9'

!!! ERROR: net-wireless/ipw3945-1.1.0 failed.

Call stack:

  ebuild.sh, line 1543:   Called dyn_compile

  ebuild.sh, line 938:   Called src_compile

  ipw3945-1.1.0.ebuild, line 74:   Called linux-mod_src_compile

  linux-mod.eclass, line 469:   Called die

!!! Unable to make  KSRC=/usr/src/linux KSRC_OUTPUT=/usr/src/linux IEEE80211_INC=/usr/include all.

!!! If you need support, post the topmost build error, and the call stack if relevant.

```

Here are the other package versions currently installed:

- ieee80211-1.1.13-r1

- ipw3945-ucode-1.13

- ipw3945d-1.7.22-r1

I can't seem to identify why this driver is failing since ieee80211 is modularized in the kernel, subsequently removed from the kenel directory, and the ieee80211 ebuild is installed in its place. 

What am I missing here???

----------

## beatryder

you have to NOT select anything to do with ieee80211 in the kernel.

----------

## Drone1

 *Quote:*   

> 
> 
> you have to NOT select anything to do with ieee80211 in the kernel
> 
> 

 

Yea, unfortunately you missed the part where I stated:

 *Quote:*   

> 
> 
> ( kernel does not allow exclusion; modularize or build-in)
> 
> 

 

For some reason, if you enable Networking Support(CONFIG_NET), CONFIG_IEEE80211 requires choice. Either <M> or <*>. If I try to manually comment out in the .config, upon 'make', it REQUIRES 1 of the above choices or fails to compile.

I'm running 2.6.17.9, dl'd from kernel.org. 

Which kernel version are you running????

EDIT!!!!!!!!

Figured it out. Had the ipw220 driver modularized which required a choice on IEEE80211.

My bad.

Will reconfig and recompile and proceed through steps, which I feel will be successful.

----------

## frederik

Has anyone got Suspend2 to work with ipw3945? I could not find anything on this. And on my notebook this module makes it impossible to resume.

Another thing is: I have a hard wired switch to turn off wireless. When switching it of and on sometimes the device eth0 does not exist anymore, sometimes my system totally hangs and sometimes when trying modprobe i get an error message that the wireless-radio was killed. Any tips?

Thank you!

Frederik

----------

## beatryder

It works just fine for me.

----------

## pacho2

 *frederik wrote:*   

> Has anyone got Suspend2 to work with ipw3945? I could not find anything on this. And on my notebook this module makes it impossible to resume.
> 
> Another thing is: I have a hard wired switch to turn off wireless. When switching it of and on sometimes the device eth0 does not exist anymore, sometimes my system totally hangs and sometimes when trying modprobe i get an error message that the wireless-radio was killed. Any tips?
> 
> Thank you!
> ...

 

It works fine for me  :Wink: 

----------

## VinzC

Geez  :Smile:  would anyone be so kind as to post his/her suspend2 configuration file? I'm curious about trying it. Also indicate your video card - I have an nVidia; I presume this won't be problematic...

----------

## beatryder

Hmm, I retract my prior statement.

I have had some trouble. It seems intermittent however. I have a solution though. I have written two scripts, one which I run before hibernate and one after.

```

#!/bin/bash

/etc/init.d/net.eth1 stop && /etc/init.d/ipw3945d stop && modprobe -r ipw3945

```

```

#!/bin/bash

modprobe ipw3945 && /etc/init.d/ipw3945d start && /etc/init.d/net.eth1 start

```

----------

## frederik

Thank you. I have it working now too. Btw: Using baslayout 1.12 I don't even need the net.eth0 service to be started. It just works.

And you don't need to create a script. You can simply insert

```
OnSuspend 20 modprobe -r ipw3945
```

into hibernate.conf.

And the module loads normal upon resume...

----------

## Sakrilegio

Hi!

I'm a proud user of a sony vaio sz2m/b, I'm having problems with ipw3945, it hangs up my computer when I try to load it leaving no traces nor log messages. It used to work 8 hours ago but stopped working don't know why. I suspect that it has been after a newuse update I performed, but I'm not sure, and the only thing I've seen that could affect the module is that it involved changing module-init-tools to it's 3.2.2-r1 version.

I've tried both versions ok the module (1.05 and 1.1.0) with it's respective dependences.

Thanks in advance   :Smile: 

----------

## pacho2

 *VinzC wrote:*   

> Geez  would anyone be so kind as to post his/her suspend2 configuration file? I'm curious about trying it. Also indicate your video card - I have an nVidia; I presume this won't be problematic...

 

I also have a nvidia video card (7300). This is my configuration:

/etc/hibernate/blacklisted-modules:

#

# WARNING: No attempt is made to preserve this file upon upgrades.

#          The file format may also change between hibernate script versions.

#          It is recommended that you enter any modules you wish to unload

#          into hibernate.conf.

#

# The syntax of each line in this file is "module name [...]" where [...] is

# a sequence of minimum/maximum kernel version pairs that the module is

# incompatible with. For example:

#     usb-ehci 2.4.0 2.4.25 2.6.0 2.6.2

# (would indicate that usb-ehci was incompatible in 2.4 until 2.4.25, and in

# 2.6 until 2.6.2 - example only!)

#

# A module without any versions is always considered unsuspendable.

#

# If a line is prefixed with an '@' sign, then the versions are interpreted

# as the module version (as reported by modinfo) instead of the kernel version.

# Unversioned modules (modules with no version: line shown in modinfo) are

# always unloaded if listed, regardless of the version range.

#

# This format has some limitations - it does not take into account Software

# Suspend 2 versions (which may include driver updates).

#

# nvidia

acx100

acx_pci

hsfmodem

prism54

bcm4400         2.6.0   2.6.99

emu10k1         2.4.0   2.4.99  2.6.0   2.6.99

forcedeth       2.4.0   2.4.99  2.6.0   2.6.99

@ipw2100        0.0     1.0.2

@ipw2200        0.0     0.20

natsemi         2.6.0   2.6.99

psmouse         2.6.0   2.6.99

rt2400          2.4.0   2.4.99  2.6.0   2.6.99

ehci_hcd        2.6.0   2.6.14

usb-ohci        2.4.0   2.4.99

usb-uhci        2.4.0   2.4.99

snd_ens1370     2.6.0   2.6.99

snd_ens1371     2.6.0   2.6.99

snd_maestro3    2.6.0   2.6.99

snd_bt_sco      2.6.0   2.6.99

en1370          2.6.0   2.6.99

en1371          2.6.0   2.6.99

via_agp         2.6.0   2.6.8

via_rhine       2.6.0   2.6.99

i8042           2.6.10  2.6.99

intel_mch_agp   2.6.0   2.6.99

rt2500          2.6.0   2.6.99

button          2.6.9   2.6.99

speedstep_smi   2.6.12  2.6.99

@ndiswrapper    0.10    0.11

[/code]

/etc/hibernate/common.conf

```

# Configuration options common for suspending to disk or RAM.

# Options are not case sensitive.

#

# See hibernate.conf(5) for help on the configuration items.

##############################################################################

### Some global settings

##############################################################################

Verbosity 1

LogFile /var/log/hibernate.log

# LogVerbosity 3

# LogTimestamp yes

# AlwaysForce yes

# AlwaysKill yes

HibernateVT 11

Distribution gentoo

# XDisplay :0

##############################################################################

### Scriptlets

###   Scriptlets provide support for doing all sorts of things before and after

###   suspending. The defaults settings here should work for most people, but

###   you may wish to edit these to taste. Consult "hibernate -h" for help on

###   the configuration settings.

##############################################################################

### bootsplash

## If you use bootsplash, also enabling SwitchToTextMode is recommended if

## you use X, otherwise you may end up with a garbled X display.

# Bootsplash on

# BootsplashConfig /etc/bootsplash/default/config/bootsplash-1024x768.cfg

### clock

SaveClock restore-only

### devices

# IncompatibleDevices /dev/dsp /dev/video*

### diskcache

# DisableWriteCacheOn /dev/hda

### fbsplash (enable SwitchToTextMode if you use this)

# FBSplash on

# FBSplashTheme /etc/splash/suspend2

### filesystems

# Unmount /nfsshare /windows /mnt/sambaserver

# UnmountFSTypes smbfs nfs

# UnmountGraceTime 1

# Mount /windows

### grub

# ChangeGrubMenu yes

# GrubMenuFile /boot/grub/menu.lst

# AlternateGrubMenuFile /boot/grub/menu-suspended.lst

# BackupGrubMenuFile /boot/grub/menu.lst.hibernate.bak

### hardware_tweaks

# IbmAcpi yes

# Runi915resolution yes

FullSpeedCPU yes

### lilo

# EnsureLILOResumes yes

### lock (generally you only want one of the following options)

# LockConsoleAs root

LockXScreenSaver no

LockGnomeScreenSaver no

# LockKDE yes

# LockXLock yes

# LockXAutoLock yes

### misclaunch

# OnSuspend 20 echo "Going into suspend!"

# OnResume 20 echo "Going back alive!"

### modules

# UnloadAllModules yes

# UnloadBlacklistedModules yes

# LoadModules auto

# LoadModulesFromFile /etc/modules

### modules-gentoo

GentooModulesAutoload yes

### network

# DownInterfaces eth0

# UpInterfaces auto

### pause_audio

# MuteAudio yes

# PauseAudio yes

### pcmcia

# EjectCards yes

### programs

# IncompatiblePrograms xmms

### services

# RestartServices vixie-cron

# StopServices vixie-cron

# StartServices vixie-cron

### vbetool

# EnableVbetool yes

# RestoreVbeStateFrom /var/lib/vbetool/vbestate

# VbetoolPost yes

# RestoreVCSAData yes

### xhacks

SwitchToTextMode yes

UseDummyXServer yes

# DummyXServerConfig xorg-dummy.conf

### xstatus

## This can be set to gnome, kde or x:

XStatus gnome

# XmessageDisable yes

# XSuspendText Preparing to suspend...

# XResumeText Resuming from suspend...

## When using XStatus x, and you have xosd installed:

# XosdSettings --font '-misc-fixed-medium-r-semicondensed--*-120-*-*-c-*-*-*' --colour=Green --shadow 1 --pos bottom --align center --offset 50

```

...disc.conf

```

# This file is used when suspending to disk using the swsusp functionality in

# the vanilla kernel. Add any configuration options specific to suspend-to-disk

# to this file. Ordering is not crucial, and options are not case-sensitive.

#

# See hibernate.conf(5) for help on the configuration items.

UseSysfsPowerState disk

Include common.conf

```

...hibernate.conf

```

# hibernate.conf is split into separate configuration files.

#

# Each file is tried in the order below, until an available suspend

# method is found.

#

# Options specific to a particular suspend method should be placed in the

# appropriate configuration file (suspend2.conf, ususpend.conf, disk.conf

# or ram.conf).

# Options common to all suspend methods should be placed in common.conf.

#

# See hibernate.conf(5) for help on the configuration items.

TryMethod suspend2.conf

TryMethod ususpend.conf

TryMethod disk.conf

TryMethod ram.conf

```

ram.conf (doesn't work for me)

```

# This file is used when suspending to RAM. Add any configuration options

# specific to suspend-to-RAM to this file. Ordering is not crucial, and options

# are not case-sensitive.

#

# See hibernate.conf(5) for help on the configuration items.

UseSysfsPowerState mem

# The following vbetool settings help with > 50% of laptops.

EnableVbetool no

VbetoolPost no

# Users with a Radeon graphics card may need to enable this line for

# suspend-to-ram, and install the radeontool program available from

# http://fdd.com/software/radeon/ or your distribution's package.

#

# RadeonTool yes

Include common.conf

# OnResume 19 cpufreq-set -d 996.000MHz -g ondemand

# OnResume 18 cpufreq-set -c 1 -d 996.000MHz -g ondemand

# OnResume 02 chvt 7

```

suspend2.conf

```

# Example suspend2.conf file.

#

# See hibernate.conf(5) for help on the configuration items.

#

# NOTE: Suspend2 is an improved version of suspend-to-disk which currently

#       requires patching your kernel. For more information, see www.suspend2.net

#

#       If you do not wish to patch your kernel but still be able to suspend to

#       disk, see disk.conf instead.

### suspend2 (for Software Suspend 2)

UseSuspend2 yes

# Reboot no

EnableEscape yes

DefaultConsoleLevel 1

Compressor lzf

Encryptor none

# ImageSizeLimit 200

## useful for initrd usage:

# SuspendDevice swap:/dev/hda2

## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff

# PowerdownMethod 5

## Any other /proc/software_suspend setting can be set like so:

ProcSetting expected_compression 20

## Or traditionally like this:

# Suspend2AllSettings 0 0 2056 65535 5

## Or even from the results of hibernate --save-settings with this:

# Suspend2AllSettingsFile /etc/hibernate/suspend-settings.conf

## For filewriter:

# FilewriterLocation /suspend_file 1000

# VerifyFilewriterResume2 yes

## Specify a userui like this:

Compressor lzf

Encryptor none

# ImageSizeLimit 200

## useful for initrd usage:

# SuspendDevice swap:/dev/hda2

## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff

# PowerdownMethod 5

## Any other /proc/software_suspend setting can be set like so:

ProcSetting expected_compression 20

## Or traditionally like this:

# Suspend2AllSettings 0 0 2056 65535 5

## Or even from the results of hibernate --save-settings with this:

# Suspend2AllSettingsFile /etc/hibernate/suspend-settings.conf

## For filewriter:

# FilewriterLocation /suspend_file 1000

# VerifyFilewriterResume2 yes

## Specify a userui like this:

ProcSetting userui_program /sbin/suspend2ui_fbsplash

# ProcSetting userui_program /sbin/suspend2ui_text

# Scale CPU to full speed to make sure we suspend as fast as possible.

# FullSpeedCPU yes

Include common.conf

### misclaunch

# OnSuspend 20 echo "Going into suspend!"

# OnResume 20 echo "Going back alive!"

# OnSuspend 87 /etc/init.d/vixie-cron stop

OnResume 14 cpufreq-set -d 996.000MHz -g ondemand

OnResume 12 cpufreq-set -c 1 -d 996.000MHz -g ondemand

# OnResume 01 /etc/init.d/vixie.cron start

```

ususpend.conf

```

# This file is used when suspending to disk using the uswsusp functionality in

# the kernel. You will require the s2disk binary to be installed - this can be

# downloaded from http://suspend.sourceforge.net/ .

# Add any configuration options specific to ususpend to this file. Ordering is

# not crucial, and options are not case-sensitive.

#

# See hibernate.conf(5) for help on the configuration items.

UseUSuspend yes

Include common.conf

```

----------

## Sakrilegio

Well, I managed to solve the problem but I still don't know why loading the ipw3945 module caused my pc to freeze.

I updated the ebuild ieee80211from 1.1.13-r1 to 1.1.14 unmasking the package and magically the module loaded without any system hang up.

Hope this helps sbdy.[/list]

----------

## VinzC

Thanks a lot, pacho2. I'll try that.

----------

## VinzC

Is it just me? I'm now using wpa_supplicant and I notice that it is harder to connect to WEP networks, i.e. the WiFi led blinks and blinks and blinks but the association doesn't take place. I must restart the network (modprobe -r ipw3945; sleep 3s; modprobe ipw3945) several times till it connects successfully.

Did anyone experience this, too? When I was using just iwconfig connecting to WEP networks was faster.

----------

## pacho2

 *VinzC wrote:*   

> Is it just me? I'm now using wpa_supplicant and I notice that it is harder to connect to WEP networks, i.e. the WiFi led blinks and blinks and blinks but the association doesn't take place. I must restart the network (modprobe -r ipw3945; sleep 3s; modprobe ipw3945) several times till it connects successfully.
> 
> Did anyone experience this, too? When I was using just iwconfig connecting to WEP networks was faster.

 

I am using iwconfig  :Sad:  without problems.

----------

## VinzC

 *pacho2 wrote:*   

> I am using iwconfig  without problems.

 

Sure, this is what I expect. Did you try wpa_supplicant?

----------

## el3ktro

I hope someone can help me. I tried to get WLAN working with the ipw3945 driver from x86, and it worked without encryption (well most of the time at least). Well I want&need to get encryption working, so I decided to upgrade to the newest ieee80211, ipw3945d and ipw3945 from ~x86. The module loads fine, the daemon also works fine, I don't get any errors, but there's no eth1 anymore. When I try "ifconfig eth1 up" (which always worked with the previous version) I get an error hat "no device could be found". net.eth1 also won't start.

Doyou have any ideas? I might turn back to x86 if I somehow get WEP and/or WPA working, but this never worked for me.

Tom

----------

## kar1181

Yeah the update broke it for me too.

It worked previousl, but I had to have my own 'init' script to make it work (the one suggested in this forum).

Now it just doesn't work at all with the installed init script or mine.

----------

## VinzC

 *el3ktro wrote:*   

> I hope someone can help me. I tried to get WLAN working with the ipw3945 driver from x86, and it worked without encryption (well most of the time at least). Well I want&need to get encryption working, so I decided to upgrade to the newest ieee80211, ipw3945d and ipw3945 from ~x86. The module loads fine, the daemon also works fine, I don't get any errors, but there's no eth1 anymore. When I try "ifconfig eth1 up" (which always worked with the previous version) I get an error hat "no device could be found". net.eth1 also won't start.
> 
> Doyou have any ideas? I might turn back to x86 if I somehow get WEP and/or WPA working, but this never worked for me.
> 
> Tom

 

To find which name your Wireless card has been give you might want to search log messages for ipw3945 or wireless:

```
dmesg | egrep -i 'wireless|eth|ipw3945'
```

----------

## mjelkins

 *kar1181 wrote:*   

> Yeah the update broke it for me too.
> 
> It worked previousl, but I had to have my own 'init' script to make it work (the one suggested in this forum).
> 
> Now it just doesn't work at all with the installed init script or mine.

 

I agree - about two days ago, I did an emerge --sync, and emerge -uNDv world - both using the wireless (eth1), rebooted (some time later) and then no more wireless (or eth1 device)..

I do remember an etc-update changing one of the ipw3945 startup scripts... and am hoping that there will be a fix or emerge reversal soon.

(Beginning to feel stupid having to use a UTP connection after bragging to people about my built-in wireless being so good)

----------

## Fran

Yep, something broke my eth1 too. I think it's the new init script. I haven't tried reverting to the old script that someone posted in this thread some time ago (that worked great), but if I use the deprecated method (modules.d/ipw3945d) everything works ok, even with the last ipw3945d. Well, I have to modprobe -r ipw3945 && modprobe ipw3945 at startup so ipw3945d is started, but at least I have wifi.

----------

## zidour

 *Fran wrote:*   

> Yep, something broke my eth1 too. I think it's the new init script. I haven't tried reverting to the old script that someone posted in this thread some time ago (that worked great), but if I use the deprecated method (modules.d/ipw3945d) everything works ok, even with the last ipw3945d. Well, I have to modprobe -r ipw3945 && modprobe ipw3945 at startup so ipw3945d is started, but at least I have wifi.

 

It's definitely the new init script. Have a look at it:

```

#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-wireless/ipw3945d/files/ipw3945d-init.d,v 1.1 2006/09/05 19:37:59 phreak Exp $

PIDFILE=/var/run/ipw3945d/ipw3945d.pid

depend() {

        before net

}

start() {

        ebegin "Starting ipw3945d"

        start-stop-daemon --start --exec /sbin/ipw3945d --chuid ipw3945d:ipw3945d \

                --pidfile ${PIDFILE} -- \

                --pid-file=${PIDFILE} ${ARGS}

        eend ${?}

}

stop() {

        ebegin "Stopping ipw3945d"

        start-stop-daemon --stop --exec /sbin/ipw3945 --pidfile ${PIDFILE}

        eend ${?}

}

```

As you can see, the ipw3945d daemon is now being run with privileges of the ipw3945d user. Let's see what we get if we execute that line of code ourselves:

```

# sudo -u ipw3945d /sbin/ipw3945d --pid-file=/var/run/ipw3945d/ipw3945d.pid --timeout=0 --quiet

2006-09-08 14:18:26: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

#

```

However, if we run it as root, everything is OK:

```

# /sbin/ipw3945d --pid-file=/var/run/ipw3945d/ipw3945d.pid --timeout=0 --quiet

#

```

So the workaround is to run ipw3945d as root. I am not sure about possible security consequences though.

----------

## Fran

Yeah, you're right. Removing the chuid option from ipw3945d solves the problem.

----------

## kar1181

Removing the chuid  fixed it for me too. Good spot!

----------

## phreak_

thanks a lot boys. ipw3945d-1.7.22-r3 has that fix included and thus should work. Feel free to prod me if it ain't workin'.   :Rolling Eyes: 

----------

## VinzC

 *VinzC wrote:*   

> Is it just me? I'm now using wpa_supplicant and I notice that it is harder to connect to WEP networks, i.e. the WiFi led blinks and blinks and blinks but the association doesn't take place. I must restart the network (modprobe -r ipw3945; sleep 3s; modprobe ipw3945) several times till it connects successfully.
> 
> Did anyone experience this, too? When I was using just iwconfig connecting to WEP networks was faster.

 

After a couple of days I found what causes that trouble. At work we have a linksys WiFi router which seems to behave strangely: almost no PC is using it. It seems to have almost no WiFi client and almost every PC is using its backup.

I removed the entry from /etc/wpa_supplicant.conf that corresponds to the problematic router and the problem went away.

----------

## Omegaice

I just tryed installing the drivers on my new inspiron 6400 and when i modprobe the driver it says that there is a fatal error inserting ipw3945 due to an unknown symbol in the module and it tells me to check dmesg. Dmesg tells me that the unknown symbol is release_firmware and request _firmware. Any ideas why?

Versions:

ipw3945-1.1.0

ipw3945d-1..22-r3

ipw3945-ucode-1.13

ieee80211-1.1.14-r1 (also tryed 1.1.13)

----------

## rhill

is the version of the kernel you built against (the one /usr/src/linux points to) the same as the version you're currently running?

also, are the kernel and module compiled with the same GCC version?  (although i think the error you get when they're not is different)

----------

## rhill

scratch that.  you probably don't have firmware loading compiled into your kernel.

Device Drivers --> General Driver Options --> Userspace firmware loading support

----------

## Omegaice

Right well i managed to get it to compile and i can modprobe all of the modules without errors but now if i modprobe ipw3945 it doesnt do anything, no device is detected at all and i know that the fn f2 (dell inspiron 6400 keybind for disbling/enabling wireless) hasnt disabled it and i know that the deamon is running, any help would be appreciated.

Edit1: I got it working now, seems ccache was to blame

Edit2: nevermind after 1 restart it completly stoped working again. The driver detects the card according to dmesg, the deamon loads and detects it but the led doesnt light and iwconfig doesnt show the device, the only error dmesg gives is "ipw3945: Error sending LEDS_CMD: timeout after 500ms." This is getting annoying.Last edited by Omegaice on Wed Sep 13, 2006 2:45 pm; edited 1 time in total

----------

## plug_n_play

i have some similar problems with it too.

it used to work ~90% of the time (usually when it didn't, i had just rebooted from windows, and all that i needed to do was modprobe -r ipw3945; sleep 2; modprobe ipw3945).  now it never works.

all the modules are loaded (ipw3945 is loaded from modules.autoload.d, i wasn't before, but now it doesn't get loaded unless its in there) and all the ieee module are loaded.  ipw395d runs and detects the card (i haven't add the init script to any runlevel, but it loads anyway) but then all that happens is that the wifi led blinks aout once every 2 seconds.  modprobe -r and modprobe'ing ipw3945 does'nt change anything - it just starts blinking again.

the only way i can connect is to use iwconfig essid, key ;ifconfig eth1 up; dhcpcd eth1.

seems like wpa_supplicant is no longer doing anything.

help!

----------

## dwn

I too have noticed some very odd behavior in respect to this wireless card. One thing that I did notice with my laptop is if I manually modprobe the module it seems to work everytime. If I add ipw3945 to /etc/modules.autoload.d/kernel-2.6 it will only work half the time. So, what I did to fix this is to add: 

```
modprobe ipw3945
```

to the end of /etc/conf.d/local.start. If you check the /etc/init.d/local, it will be the last init script to be run. I honestly have no clue what ipw3945 depends on order to make this work, but seems to do the job.

----------

## VinzC

 *Omegaice wrote:*   

> Edit1: I got it working now, seems ccache was to blame

 

That's interresting...

 *Omegaice wrote:*   

> Edit2: nevermind after 1 restart it completly stoped working again. The driver detects the card according to dmesg, the deamon loads and detects it but the led doesnt light and iwconfig doesnt show the device, the only error dmesg gives is "ipw3945: Error sending LEDS_CMD: timeout after 500ms." This is getting annoying.

 

I once have had something similar. Until I noticed one of our access points was the culprit: almost none of our PC's was using it. I cleaned the access point by restoring factory defaults and re-did its setup again. Now it works and my laptop catches the (once failing) access point.

----------

## VinzC

 *plug_n_play wrote:*   

> all the modules are loaded (ipw3945 is loaded from modules.autoload.d, i wasn't before, but now it doesn't get loaded unless its in there) and all the ieee module are loaded.  ipw395d runs and detects the card (i haven't add the init script to any runlevel, but it loads anyway) but then all that happens is that the wifi led blinks aout once every 2 seconds.  modprobe -r and modprobe'ing ipw3945 does'nt change anything - it just starts blinking again.

 

As I already mentionned I too see the WiFi led blink as soon as X starts. However it flashes a little faster than yours (say 4 times a second). The wireless network is yet functionnal.

 *plug_n_play wrote:*   

> the only way i can connect is to use iwconfig essid, key ;ifconfig eth1 up; dhcpcd eth1.
> 
> seems like wpa_supplicant is no longer doing anything.

 

Given previous remarks and notifications, I'd advise you to check the following points:

Make sure your kernel, modules, system packages plus packages ipw3945 and ieee80211 are compiled with the same version of GCC. You might have to clear the cache beforehand.

Make sure file /etc/modules.d/ipw3945d exists and lists the insert/remove lines

Make sure no other file in /etc/modules.d does the same (the same instructions are commented out in /etc/modules.d/ipw3945

What version of baselayout are you using?

Here are a couple of checks:

```
$ grep ipw3945d /etc/modules.d/*

/etc/modules.d/ipw3945:# install ipw3945 /sbin/modprobe --ignore-install ipw3945

/etc/modules.d/ipw3945:# remove ipw3945  /sbin/ipw3945d --kill; /sbin/modprobe -

/etc/modules.d/ipw3945d:install ipw3945 /sbin/modprobe --ignore-install ipw3945;

/etc/modules.d/ipw3945d:remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r
```

```
$ equery -q l ipw3945

[I--] [  ] net-wireless/ipw3945-1.0.5 (0)

[I--] [  ] net-wireless/ipw3945-ucode-1.13 (0)

[I--] [  ] net-wireless/ipw3945d-1.7.18 (0)
```

```
$ equery -q l ieee

[I--] [  ] net-wireless/ieee80211-1.1.13-r1 (0)
```

```
$ equery -q l wireless

[I--] [  ] net-wireless/wireless-tools-28 (0)
```

```
$ uname -r

2.6.17-gentoo-r4
```

----------

## okapi

After a lot of test and reading I found out what was going on.

It seems that the crash was caused by the ipw3945 daemon itself.

This daemon is responsible to check that you don't overdrive the frequency tuner with a modified version of the driver. (thanks to the FCC   :Wink:  )

It does that by doing a series of CRC check and cryptographic sum.

It seems that having the kernel crypto api in modules even though all the required modules are loaded, dicomfort ipw3945d in some way and he just ungracefully crashes the system.

I resolved my problem by staticly compiling the crypto modules into the kernel and reverted in the ieee80211 and ipw3945 ebuild.

Hope that this will help other people in this situation.

 *okapi wrote:*   

> Hi Forum,
> 
> I browsed thru the forum but did find any similar bug. But then again the thread is already quite lenghty.
> 
> I tried to install ipw3945 on my system. It builds fine and the module loads but only when the hardware kill switch is on.
> ...

 

----------

## mijenix

Hi

I think, the new version of ipw3945 driver, will not load the ipw3945d when modprobe ipw3045 will executed.

Now you have to run "/etc/init.d/ipw3945d start" and then modprobe ipw3945. 

That's what I do, and it works.

----------

## morbus

Mmh, I got some problems too.

If I run the /etc/init.d/net.wlan0 script the first time, It won't start (device wlan0 does not exist). if I rerun the script then everything works fine. Could it be that the wlan card needs some time to intialize?

I'm using the  ~x86 versions of the drivers; the rest of the system (including baselayou, udev etc.) is x86

Cheers,

Momsen

----------

## anz

Hello,

I have a MSI S262 (centrino dual core). The hell started after updating the kernel from:

2.6.17-gentoo-r4 to 2.6.17-gentoo-r8

After rebooting with the new kernel nearly all error messages described above appeared (f.e. during booting a

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.)

 - and wpa_supplicant did not work ...

After adding ipw3945 to the file /etc/hotplug/blacklist,

emerging 

 *Quote:*   

> net-wireless/ipw3945-1.1.0-r1
> 
> net-wireless/ipw3945d-1.7.22-r3

 

and a

```
rc-update -a ipw3945d default
```

After that rebooting, inserting following modules (a big thanks to okapi)

```
modprobe ieee80211_crypt_wep

modprobe ieee80211_crypt_tkip

modprobe ieee80211_crypt_ccmp
```

switching on the wlan device (pressing the button) and AFTER that a

```
modprobe ipw3945
```

 (maybe  before a: /etc/init.d/ipw3945d restart)

wpa_supplicant worked again:

```
wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant.conf
```

... strange ... strange ...

----------

## Sagi

Good evening,

I just bought a MSI Megabook s262, with a intel 3945ABG wlan chip and tried to install the drivers as described in: http://gentoo-wiki.com/HARDWARE_ipw3945 (which matches this topic on most points)

I have gotten the error stating that I missed some stuff in my kernel, so I recompiled it with the necessary options. When I tried to re-emerge I got the following output:

```
# emerge -av ipw3945

These are the packages that would be merged, in order:

Calculating dependencies \

!!! All ebuilds that could satisfy ">=net-wireless/ipw3945-ucode-1.13" have been masked.

!!! One of the following masked packages is required to complete your request:

- net-wireless/ipw3945-ucode-1.13 (masked by: missing keyword)

For more information, see MASKED PACKAGES section in the emerge man page or 

refer to the Gentoo Handbook.

(dependency required by "net-wireless/ipw3945-1.1.0-r1" [ebuild])
```

So I put the following in /etc/portage/package.keywords:

```
# cat /etc/portage/package.keywords 

<snip>

net-wireless/ipw3945 ~*

net-wireless/ipw3945d ~*

net-wireless/ipw3945-ucode -* ~*
```

and /etc/portage/package.unmask:

```
# cat /etc/portage/package.unmask   

<snip>

net-wireless/ipw3945

net-wireless/ipw3945d

net-wireless/ipw3945-ucode
```

I have no clue on what to do, normally I do not have any problems using the /etc/portage/package.* files and this problem seems to occur only with this package. Could someone point out what I am doing wrong?

Thanks in advance!

----------

## VinzC

@Sagi:

```
# emerge -av ipw3945

These are the packages that would be merged, in order:

Calculating dependencies \

!!! All ebuilds that could satisfy ">=net-wireless/ipw3945-ucode-1.13" have been masked.

!!! One of the following masked packages is required to complete your request:

- net-wireless/ipw3945-ucode-1.13 (masked by: missing keyword)

For more information, see MASKED PACKAGES section in the emerge man page or 

refer to the Gentoo Handbook.

(dependency required by "net-wireless/ipw3945-1.1.0-r1" [ebuild])
```

The missing keyword stuff suggests you are running Gentoo on a computer which doesn't have an Intel CPU...  :Rolling Eyes:  Have you chosen the right Gentoo target platform tarball?

----------

## pacho2

 *VinzC wrote:*   

> 
> 
> ```
> $ grep ipw3945d /etc/modules.d/*
> 
> ...

 

When ipw3945d init script is installed and running, /etc/modules.d/ipw3945 can (and should) have all this lines commented. 

Saludos

----------

## beatryder

Has anyone noticed that the ieee80211 keeps upgrading and then downgrading on successive emerge -Du world's?

----------

## Sagi

 *VinzC wrote:*   

> @Sagi:
> 
> ```
> # emerge -av ipw3945
> 
> ...

 

Well I do have an Intel cpu, a new core 2 duo (merom, T7200). I picked arch amd64 with march nocona, because most people on these forums thought that to be the best choice for this platform. I haven't got any problems with software in combination with this arch/march sofar, so it seems strange to me that this package starts complaining.

Any ideas?

----------

## beatryder

You could manuall edit the ebuild, and add the right keyword

----------

## VinzC

 *Sagi wrote:*   

> Well I do have an Intel cpu, a new core 2 duo (merom, T7200). I picked arch amd64 with march nocona, because most people on these forums thought that to be the best choice for this platform. I haven't got any problems with software in combination with this arch/march sofar, so it seems strange to me that this package starts complaining.
> 
> Any ideas?

 

Ah, I see now. I have picked the x86 branch but recompiled using -march=prescott once there was a GCC version that could (3.4.x). Never had a problem with ipw3945 since it's targetting the x86 branch only. But I have a Core Duo, not a Core 2 Duo - big difference indeed.

As suggested you should add the ~amd64 keyword to a custom ebuild script that you'd typically put in a portage overlay so that your changes are not overwritten each time you --sync your portage tree. However you'll be mostly testing this package with that architecture.

What puzzles me most is the binary (closed-source) daemon that is x86-only. Will it run natively on a 64-bit platform? I think you might need to tweak your custom ebuild to use 32-bit emulation for the driver to run.

----------

## Sagi

 *VinzC wrote:*   

> 
> 
> As suggested you should add the ~amd64 keyword to a custom ebuild script that you'd typically put in a portage overlay so that your changes are not overwritten each time you --sync your portage tree. However you'll be mostly testing this package with that architecture.
> 
> What puzzles me most is the binary (closed-source) daemon that is x86-only. Will it run natively on a 64-bit platform? I think you might need to tweak your custom ebuild to use 32-bit emulation for the driver to run.

 

I've just mailed the contactperson at intel, which is mentioned at the contact page of the ipw3945.sf.net project, I hope to hear from him what Intels plans are considering a 64-bit version of their drivers (they released this new processor themselves, so I guess they will support it in the future).

I will try to test the driver tonight, I haven't got the slightest idea how to create an overlay, but I presume there are docs about it available, so that shouldn't be too much of a problem. I'll report back here as soon as I have found something of interest.

Thanks for your suggestions so far, you are really helping me!

(oh, do tell me if I make spelling/grammar mistakes, as you've probably noticed already I am not a native speaker. I can only improve my english if someone points me at my mistakes  :Wink: )

----------

## VinzC

 *Sagi wrote:*   

> (oh, do tell me if I make spelling/grammar mistakes, as you've probably noticed already I am not a native speaker. I can only improve my english if someone points me at my mistakes )

 

Nothing wrong about your spelling and grammar - but I'm neither a native speaker  :Wink:  .

As for portage overlays, they're... overly simple. All you have to do is create the directory structure under /usr/local/portage (typically), copy and change the ebuild by adding the required keyword (amd64) and compute the digest. Next emerge and that's it. Don't forget to add the directive about overlays in make.conf.

----------

## Sagi

 *Sagi wrote:*   

> 
> 
> I will try to test the driver tonight, I haven't got the slightest idea how to create an overlay, but I presume there are docs about it available, so that shouldn't be too much of a problem. I'll report back here as soon as I have found something of interest.

 

Well that proved to be easy, I just succesfully emerged my own custom ebuild in an overlay (simply add amd64 to keywords) and it seems to works sofar. I cannot test the connection just yet because I have to configure some encryption stuff (campusnetwork), but I have not encountered a single error and the card seems properly detected.

Thanks for your explanation VinzC  :Smile: 

more to follow as soon as I get to do a bit more testing

----------

## rmh3093

I just wanted to report that I was finally able to get wpa/wpa2 working on this card. The trick was to build IEEE80211 support into the kernel and build the ipw3945 module externally. I did not use any portage ebuilds. I also had to tweak /etc/init.d/ipw3945d and /etc/conf.d/net so that the daemon starts gets started before wpa_supplicant tries to start the interface.

```
#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-wireless/ipw3945d/files/ipw3945d-init.d,v 1.2 2006/09/09 07:53:40 phreak Exp $

PIDFILE=/var/run/ipw3945d/ipw3945d.pid

depend() {

        before net

}

start() {

        ebegin "Starting ipw3945d"

        start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \

                --pid-file=${PIDFILE} ${ARGS}

        sleep 2

        eend ${?}

}

stop() {

        ebegin "Stopping ipw3945d"

        start-stop-daemon --stop --exec /sbin/ipw3945 --pidfile ${PIDFILE}

        eend ${?}

}

```

```
# This blank configuration will automatically use DHCP for any net.*

# scripts in /etc/init.d.  To create a more complete configuration,

# please review /etc/conf.d/net.example and save your configuration

# in /etc/conf.d/net (this file :]!).

RC_NEED_wlan="ipw3945d"

modules=( "wpa_supplicant" )

wpa_supplicant_wlan="-Dwext -w"

associate_timeout_wlan=60

```

I think that if the ipw3945 module can used with the in-kernel ieee80211 code then we should either modify the ebuild to allow us to choose or create a kernel patch to build the ipw3945 module into the kernel. I actually would prefer the later and would put forth the effort if there are other people that could use this.

----------

## beatryder

I like the idea of the external modules for both the ipw3945 and iee80211. Makes upgrading them easier. Also, you are aware that they both build off code that is in the kernel right? The only thing is that you cannot build them statically.

Personally I like the idea of a module as it allows me to easily control whcih interface gets which name (yes I know there are ways to rename them) but it also allows me to completely shut off the card.

just my 2cents: It doesn't make sense to me to build the driver statically.

----------

## VinzC

 *rmh3093 wrote:*   

> I just wanted to report that I was finally able to get wpa/wpa2 working on this card. The trick was to build IEEE80211 support into the kernel and build the ipw3945 module externally. I did not use any portage ebuilds.

 

Great  :Smile: . So you worked upon packages supplied by Intel, didn't you? Did you do any patching to let Intel ipw3945 module use kernel built-in ieee80211? I'm interrested in your method for I simply find running the remove-old script boring...

 *rmh3093 wrote:*   

> I think that if the ipw3945 module can used with the in-kernel ieee80211 code then we should either modify the ebuild to allow us to choose or create a kernel patch to build the ipw3945 module into the kernel. I actually would prefer the later and would put forth the effort if there are other people that could use this.

 

I don't think this is going to happen upstream as long as there is a proprietary (aka closed-source) binary daemon.

----------

## rmh3093

 *VinzC wrote:*   

>  *rmh3093 wrote:*   I just wanted to report that I was finally able to get wpa/wpa2 working on this card. The trick was to build IEEE80211 support into the kernel and build the ipw3945 module externally. I did not use any portage ebuilds. 
> 
> Great . So you worked upon packages supplied by Intel, didn't you? Did you do any patching to let Intel ipw3945 module use kernel built-in ieee80211? I'm interrested in your method for I simply find running the remove-old script boring...
> 
>  *rmh3093 wrote:*   I think that if the ipw3945 module can used with the in-kernel ieee80211 code then we should either modify the ebuild to allow us to choose or create a kernel patch to build the ipw3945 module into the kernel. I actually would prefer the later and would put forth the effort if there are other people that could use this. 
> ...

 

yeah the remove-old script sucks.... I didnt do any special patching. I used the latest gentoo-sources as my kernel with ieee80211 built in. I used the tar file in /usr/portage/distfiles for the source of the latest ipw3945 driver. I did tweak the Makefile; I uncommented the radiotap and promisc mode options and I set debug=n

the ipw3945 module built cleanly... you have to type 'make install_for_testing' to install the modules 'make install'  it says to use the load/unload scripts.

----------

## gleb

Hi, I have read this thread and managed to compile and installed ieee80211 and ipw3945 drivers, however when i am trying to start network with /etc/init.d/net.eth1 start I am getting the following error

```

localhost ~ # /etc/init.d/net.eth1 start

 * Starting eth1

 *   Starting wpa_supplicant on eth1 ...

/lib/rcscripts/sh/rc-daemon.sh: line 229: 17280 Segmentation fault      /sbin/start-stop-daemon '--start' '--exec' '/sbin/wpa_supplicant' '--pidfile' '/var/run/wpa_supplicant-eth1.pid' '--' '-Dwext' '-c/etc/wpa_supplicant.conf' '-W' '-B' '-ieth1' '-P/var/run/wpa_supplicant-eth1.pid'                               [ !! ]

```

what's wrong? please help!Last edited by gleb on Thu Sep 21, 2006 12:18 pm; edited 1 time in total

----------

## Sagi

 *Sagi wrote:*   

> more to follow as soon as I get to do a bit more testing

 

I'm replying using the wireless facilities on our campus, iow. the ipw3945 works on ~amd64, even in a 64 environment  :Very Happy: 

Thanks for your help people, couldn't have fixed this without you.

Should I submit a bug ticket asking to mark it stable?

----------

## VinzC

@gleb,

As there are ways of possible reasons this is a little too short so as to have the slightest idea on what's going wrong on your system. Remember we don't know what you know and we must have the most complete information on what you did exactly.

For instance:

did you upgrade GCC to version 4.1? If yes, did you follow the upgrade guide?

What is your architecture, x86, AMD64?

Please post the results of emerge --info so we can have a better idea.

----------

## VinzC

 *Sagi wrote:*   

> Thanks for your help people, couldn't have fixed this without you.

 

Glad it works for you  :Smile:  .

 *Sagi wrote:*   

> Should I submit a bug ticket asking to mark it stable?

 

Well you could always submit the modified ebuild to bugs.gentoo.org , that's a good idea. This is what I did when I wrote the ebuild when it didn't exist yet.

----------

## gleb

Hi VinzC,

thanks for you help!

Here is the info (I have x86):

```

localhost ~ # emerge --info

!!! Invalid PORTDIR_OVERLAY (not a dir): '/root/catalyst/overlays/portage'

!!! Invalid PORTDIR_OVERLAY (not a dir): '/root/catalyst/overlays/portage'

Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686)

=================================================================

System uname: 2.6.17-gentoo-r8 i686 Genuine Intel(R) CPU           T2400  @ 1.83GHz

Gentoo Base System version 1.12.5

Last Sync: Wed, 20 Sep 2006 05:30:01 +0000

ccache version 2.3 [enabled]

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: 1.2.11-r1

dev-lang/python:     2.4.3-r1

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     2.3

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.13-r3

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r1

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=i686 -O2 -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-march=i686 -O2 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

LINGUAS=""

MAKEOPTS=""

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY=""

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="X alsa arts avi berkdb bitmap-fonts cairo cdr cli crypt cups dbus dlloader dri dvd dvdr eds elibc_glibc emboss encode esd fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux ldap libg++ mad mikmod mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810 video_cards_imstt video_cards_mga video_cards_neomagic video_cards_nsc video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo vorbis wifi win32codecs x86 xml xorg xv zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

GCC: I have gcc4.1.1, but I didn't followed any manual, just typed 

```

emerge --update --deep --newuse world

```

I suppose Gentoo updated everything correctly. Could I check this somehow?

PS: I'm new to Gentoo so probably something was done incorrectly. 

Basically I have one question: after I removed old sources of ieee80211 from kernel should I rebuild it?

----------

## Sagi

 *VinzC wrote:*   

> Well you could always submit the modified ebuild to bugs.gentoo.org , that's a good idea. This is what I did when I wrote the ebuild when it didn't exist yet.

 

The only modification I made was adding the ~amd64 keyword to the ebuild, it was that simple . All the other work did go into configuring wpa_supplicant to work with our campusnetwork.

There seems to be some guide for archtesters to request a dev to stabilize a build, maybe I should follow those guidelines and add a bugzilla-report. Does the bug which you used to add the ebuild still exist? In that case I can mention that is works on amd64 with a core 2 duo merom processor (which shouldn't be supported out-of-the-box I guess).

----------

## VinzC

 *Sagi wrote:*   

> Does the bug which you used to add the ebuild still exist?

 

I don't think so. It looks like it has been closed for I don't find it back on Gentoo bugzilla...

----------

## VinzC

 *gleb wrote:*   

> 
> 
> ```
> 
> localhost ~ # emerge --info
> ...

 

You should fix this first even if it doesn't prevent ipw3945 from working.

 *gleb wrote:*   

> GCC: I have gcc4.1.1, but I didn't followed any manual, just typed
> 
> ```
> emerge --update --deep --newuse world
> ```
> ...

 

You should also run emerge -ave ipw3945 at least then recompile your kernel using GCC 4.1. Things should work better afterwards. Note the devs advise recompiling everything (emerge -ave world) but the former command is the strict minimum. I usually start with emerge -ave system when I come to using a new GCC version - but I don't stick to the upgrade guide to the letter  :Wink:  .

----------

## Sagi

 *VinzC wrote:*   

>  *Sagi wrote:*   Does the bug which you used to add the ebuild still exist? 
> 
> I don't think so. It looks like it has been closed for I don't find it back on Gentoo bugzilla...

 

hmm, maybe you, as author should propose that it will be marked stable, I can reply with my personal experience / emerge --info

----------

## VinzC

 *VinzC wrote:*   

>  *Sagi wrote:*   Does the bug which you used to add the ebuild still exist? 
> 
> I don't think so. It looks like it has been closed for I don't find it back on Gentoo bugzilla...

 

 *Sagi wrote:*   

> hmm, maybe you, as author should propose that it will be marked stable, I can reply with my personal experience / emerge --info

 

Not that I don't want to do it but it is best if you provide your own input since you have the hardware, which you can make further tests on.

----------

## gleb

VinzC, thanks: everything works now!

----------

## VinzC

 *gleb wrote:*   

> VinzC, thanks: everything works now!

 

Glad it works for you.  :Smile: 

----------

## VinzC

 *rmh3093 wrote:*   

> I just wanted to report that I was finally able to get wpa/wpa2 working on this card. The trick was to build IEEE80211 support into the kernel and build the ipw3945 module externally. I did not use any portage ebuilds. 

 

Hehe I was curious about trying what you said and I now can provide a patch for ipw3945 ebuild so that it links against built-in ieee80211 kernel module. And it works because this is how I'm writing this post - Ok, nothing forces you to believe me, does it  :Wink:  .

Here it is - please, please, please: mind the tabs when copying patches...

```
# cat ~/ipw3945-ebuild.diff

diff -Nau old/net-wireless/ipw3945/ipw3945-1.0.5.ebuild new/net-wireless/ipw3945/ipw3945-1.0.5.ebuild

--- old/net-wireless/ipw3945/ipw3945-1.0.5.ebuild   2006-06-05 15:36:11.000000000 +0200

+++ new/net-wireless/ipw3945/ipw3945-1.0.5.ebuild   2006-09-25 22:50:59.000000000 +0200

@@ -17,20 +17,19 @@

 KEYWORDS="x86"

 IUSE="debug"

-DEPEND=">=net-wireless/ieee80211-${IEEE80211_VERSION}

-               sys-apps/sed"

-RDEPEND=">=net-wireless/ieee80211-${IEEE80211_VERSION}

-               >=net-wireless/ipw3945-ucode-${UCODE_VERSION}

-               >=net-wireless/ipw3945d-${DAEMON_VERSION}"

+DEPEND="sys-apps/sed"

+RDEPEND=">=net-wireless/ipw3945-ucode-${UCODE_VERSION}

+       >=net-wireless/ipw3945d-${DAEMON_VERSION}"

 BUILD_TARGETS="all"

 MODULE_NAMES="ipw3945(net/wireless:)"

 MODULESD_IPW3945_DOCS="README.ipw3945"

-CONFIG_CHECK="NET_RADIO FW_LOADER !IPW3945"

+CONFIG_CHECK="NET_RADIO FW_LOADER IEEE80211 !IPW3945"

 ERROR_NET_RADIO="${P} requires support for Wireless LAN drivers (non-hamradio) & Wireless Extensions (CONFIG_NET_RADIO)."

 ERROR_FW_LOADER="${P} requires Hotplug firmware loading support (CONFIG_FW_LOADER)."

-ERROR_IPW3945="${P} requires the in-kernel version of the IPW3945 driver to be disabled (CONFIG_IPW3945)"

+ERROR_IEEE80211="${P} requires built-in IEEE 802.11 support (CONFIG_IEEE80211)."

+ERROR_IPW3945="${P} requires the in-kernel version of the IPW3945 driver to be disabled (CONFIG_IPW3945)."

 pkg_setup() {

        linux-mod_pkg_setup

@@ -39,18 +38,9 @@

                die "${P} does not support building against kernel 2.4.x"

        fi

-       if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]]; then

-               eerror

-               eerror "Looks like you forgot to remerge net-wireless/ieee80211 after"

-               eerror "upgrading your kernel."

-               eerror

-               eerror "Hint: use sys-kernel/module-rebuild for keeping track of which"

-               eerror "modules needs to be remerged after a kernel upgrade."

-               eerror

-               die "${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} not found"

-       fi

-

-       BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

+       # Eliminated dependency on portage ieee80211 module. Find

+       # include files directly from kernel.

+       BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/src/linux/include"

 }

 src_unpack() {

```

How do you apply this patch?

You should have an overlay directory in which you must copy ipw3945-1.0.5-ebuild and other accompanying files. On my laptop it's in /usr/local/overlays/portage/net-wireless/ipw3945/. Next cd to your portage overlay and apply the patch:

```
# cd /usr/local/overlays/portage/net-wireless/

# patch -p1 < ~/ipw3945-ebuild.diff
```

Compute the digest and emerge. No more need to run the remove-old script nor to emerge ieee80211. Neat and shiny  :Smile:  .

Last note: to copy the patch quote this post and select the [code] text. You'll get the tabs where needed. You should also be familiar with creating and using portage overlays.

EDIT: I added the check for CONFIG_IEEE80211 in the patch for completeness.

----------

## rene80

HI guys,

I am reading this thread with full interest since I have a really strange problem with my intel wireless card (ipw3945). I have applied all the necessary steps as described in the Gentoo Handbook/WIKI. However, until now, I have not found a feasible solution.

The main problem is that the firmware can not be loaded:

```

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: ipw3945.ucode load failed: Reason -2

ipw3945: Could not read microcode: -2

ipw3945: probe of 0000:0b:00.0 failed with error -2

```

It seems to be a problem with the UDEV because when I remove udev from my system, the wireless card can be loaded (although I do not get a connection, at least the LEDS are working). 

I tried to run the fireware.sh script in the UDEV directory but get a nasty error:

```

udev firmware loader misses sysfs directory

```

Is someone aware of this problem? Please let me know.

----------

## par4noia

 *VinzC wrote:*   

>  *rmh3093 wrote:*   I just wanted to report that I was finally able to get wpa/wpa2 working on this card. The trick was to build IEEE80211 support into the kernel and build the ipw3945 module externally. I did not use any portage ebuilds.  
> 
> Hehe I was curious about trying what you said and I now can provide a patch for ipw3945 ebuild so that it links against built-in ieee80211 kernel module. And it works because this is how I'm writing this post - Ok, nothing forces you to believe me, does it  .
> 
> Here it is - please, please, please: mind the tabs when copying patches...
> ...

 

Can one still follow the How To posted in the wiki and expect the same results?

----------

## VinzC

 *par4noia wrote:*   

> Can one still follow the How To posted in the wiki and expect the same results?

 

Are you talking about the Wiki on creating overlays for third party eebuilds?

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   Can one still follow the How To posted in the wiki and expect the same results? 
> 
> Are you talking about the Wiki on creating overlays for third party eebuilds?

 

No, the one for the IPW3945...This one HERE

----------

## rmh3093

while the wiki is an excellent source of information, it must be taken cum grano salis. that is one persons howto in using the ipw3945 wireless card, from first hand experience, wpa/wpa2 does not work  with ieee80211 as modules so I would say you will get better results with this guide   :Wink: 

----------

## VinzC

Note I got WPA/TKIP successfully working with both (recent) ieee80211 from portage and kernel built-in modules. I did not try WPA2 yet.

The Wiki diverts a little from Intel's guide in that it suggests running the daemon from an init script, which is only a workaround. The init script is only there when the daemon doesn't run automatically using the module file.

I'd say first try using the module file (/etc/modules.d/ipw3945d, which portage installs by default). Normally things should work without further tweaking because portage installs the required instructions in the module (configuration) file so that the daemon runs as soon as ipw3945 is loaded into memory. Only if that doesn't work [insist a little then] use the init script.

----------

## rene80

I was just wondering if someone has a solution (or a least an idea) concerning the problem I have described a couple of posts above.

I am working for two days on this nasty firmware problem, but I do not make any progress ...

My system is a Dell Inspiron 6400 laptop.

My main system attributes:

```

Portage 2.1.2_pre1-r3 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.18-gentoo i686)

```

I'm usuing the following releases of the ipw3945:

ipw3945d: 1.7.22-r3

ipw-ucode: 1.13

ipw3945: 1.1.0-r1

----------

## rene80

Hmm, there seems to be more problems with the udev/ipw3945

See this thread for example

Anyways, my solution is just to install udev-094. This seems to work on my laptop!

```
USE="x86" emerge =udev-094
```

----------

## unz

Confirmed! i'm on ~x86 and all 100s udev's versions break ipw3945 [going back to 098 does the trick]

----------

## rene80

Udev-098 is not working over here ....

----------

## rmh3093

 *VinzC wrote:*   

> Note I got WPA/TKIP successfully working with both (recent) ieee80211 from portage and kernel built-in modules. I did not try WPA2 yet.
> 
> 

 

hmmm... cause when I use modules, I can never get a complete authentication, it dies when it starts to exchange keys (once the ieee80211_ccmp module gets called)

the init script I think it the best option.... because then you can add the line below to your net config guaranteeing the daemon gets started before the wireless device trys to start.

```

RC_NEED_wlan="ipw3945d"

```

i dont really like the radio interface shutting down automatically when I stop the wireless card via the net init scripts.

----------

## madisonicus

 *Sakrilegio wrote:*   

> Well, I managed to solve the problem but I still don't know why loading the ipw3945 module caused my pc to freeze.
> 
> I updated the ebuild ieee80211from 1.1.13-r1 to 1.1.14 unmasking the package and magically the module loaded without any system hang up.
> 
> Hope this helps sbdy.[/list]

 

Whenever the ipw3945d daemon started up I was freezing too.  Downgraded from net-wireless/ieee80211-1.2.15 to 1.1.13-r1 and it's working fine again.

Very frustrating problem since there's no output to any logs that I could tell.  Even starting ipw3945d with logging on didn't produce anything.  Also, I wouldn't have thought to look at the ieee80211 driver for a problem that sure looked like it was ipw3945d's fault.

Thanks.

----------

## VinzC

 *rene80 wrote:*   

> Anyways, my solution is just to install udev-094. This seems to work on my laptop!

 

 *unz wrote:*   

> Confirmed! i'm on ~x86 and all 100s udev's versions break ipw3945 [going back to 098 does the trick]

 

I for myself have stuck to udev-079 and don't think I'll upgrade that early  :Wink:  . I have even package.mask'ed udev-087*...

----------

## VinzC

 *rmh3093 wrote:*   

> the init script I think it the best option.... because then you can add the line below to your net config guaranteeing the daemon gets started before the wireless device trys to start.
> 
> ```
> 
> RC_NEED_wlan="ipw3945d"
> ...

 

That's Gentoo  :Smile:  ...

----------

## VinzC

 *rmh3093 wrote:*   

> hmmm... cause when I use modules, I can never get a complete authentication, it dies when it starts to exchange keys (once the ieee80211_ccmp module gets called)

 

Too bad the daemon is plain proprietary... We could have had the beginning of an idea of what could go wrong in there...

----------

## par4noia

I had to emerge ipw3945d, because there was no /etc/init.d/ipw3945d..But then my wireless LED started to blink endlessly and it hanged...I'll try the solution posted a few posts above...

----------

## pacho2

 *VinzC wrote:*   

>  *rene80 wrote:*   Anyways, my solution is just to install udev-094. This seems to work on my laptop! 
> 
>  *unz wrote:*   Confirmed! i'm on ~x86 and all 100s udev's versions break ipw3945 [going back to 098 does the trick] 
> 
> I for myself have stuck to udev-079 and don't think I'll upgrade that early  . I have even package.mask'ed udev-087*...

 

I am using udev 100-r2 without any problems with ipw3945 (from testing)

----------

## Mickael

Hello,

something seems to be wrong,

i've installed your ebuild inside my overlay, but when i do :emerge -va ipw3945, the answer is :

```
 emerge -av ipw3945

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] net-wireless/ieee80211-1.1.13-r1  USE="-debug" 0 kB

[ebuild  N    ] net-wireless/ipw3945d-1.7.22-r3

[ebuild  N    ] net-wireless/ipw3945-ucode-1.13  59 kB

[ebuild  N    ] net-wireless/ipw3945-1.1.0-r1  USE="-debug" 0 kB

Total size of downloads: 59 kB

Would you like to merge these packages? [Yes/No]

```

Your ebuild seems not be taken into account  :Confused:   Where is the problem?

PS : I'm full~x86 on a DELL inspiron 6400.

----------

## wodan

Hi,

I have some problems regarding the behaviour of the net.eth1 (linked to net.lo) init script for my ipw3945. Everything works fine when started up initially. But when I restart the script, some strange things happen:

```

 * Stopping eth1

 *   Bringing down eth1

 *     Shutting down eth1 ...                              [ ok ]

 *     Stopping wpa_cli on eth1 ...                        [ ok ]

 *     Stopping wpa_supplicant on eth1 ...                 [ ok ]

 * Starting eth1

 *   Wireless radio has been killed for interface eth1

 *   wpa_supplicant will launch, but not associate until

 *   wireles radio is re-enabled for interface eth1

...

```

It seems, that the rf kill switch got magically activated, the output of 

/sys/bus/pci/drivers/ipw3945/0000\:0c\:00.0/rf_kill

/sys/class/net/eth1/device/rf_kill

indicate a "software kill switch" (value 1). Initially the output was 0. My notebook has a hardware kill switch which shows up as 2, but I am not touching it at the moment.

So why does "/etc/init.d/net.eth1 stop" kill my wireless card. I can reactivate it by issueing

```

/etc/init.d/net.eth1 stop

echo 0 > /sys/class/net/eth1/device/rf_kill

/etc/init.d/net.eth1 start

```

but this can't be the correct solution.

Can somebody reproduce this? The net.lo script is far too complex to find the culprit, at least for me.

Versions:

ipw3945-1.1.0-r1

ipw3945d-1.7.22-r3

baselayout-1.12.5

ieee80211-1.1.13-r1

----------

## VinzC

 *MickTux wrote:*   

> Your ebuild seems not be taken into account   Where is the problem?
> 
> PS : I'm full~x86 on a DELL inspiron 6400.

 

Your /etc/make.conf might not have PORTDIR_OVERLAY properly set. It must be a comma-separated list of directories if there are more than one. For instance, if you have installed your modified copy of ipw3945 in /usr/local/portage/net-wireless/ipw3945 then PORTDIR_OVERLAY should be:

```
PORTDIR_OVERLAY=/usr/local/portage
```

or look like

```
PORTDIR_OVERLAY="... /usr/local/portage ..."
```

----------

## VinzC

 *wodan wrote:*   

> ipw3945-1.1.0-r1
> 
> ipw3945d-1.7.22-r3

 

Are you running the unstable/testing versions of ipw3945? If yes you should try to use the stable versions.

----------

## Mickael

Ok : 

```
PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentopia"

```

----------

## VinzC

 *MickTux wrote:*   

> Ok : 
> 
> ```
> PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentopia"
> 
> ...

 

Then have you edited the same ebuild (version) as the one that pops in the emerge list - i.e. ipw3945-1.1.0-r1.ebuild?

If yes then you must change the patch accordingly since it patches only the 1.0.5 version. For example:

```
# cat ~/ipw3945-ebuild.diff

diff -Nau old/net-wireless/ipw3945/ipw3945-1.0.5.ebuild new/net-wireless/ipw3945/ipw3945-1.0.5.ebuild

--- old/net-wireless/ipw3945/ipw3945-1.0.5.ebuild   2006-06-05 15:36:11.000000000 +0200

+++ new/net-wireless/ipw3945/ipw3945-1.0.5.ebuild   2006-09-25 22:50:59.000000000 +0200

...
```

becomes

```
# cat ~/ipw3945-ebuild.diff

diff -Nau old/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild new/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild

--- old/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild   2006-06-05 15:36:11.000000000 +0200

+++ new/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild   2006-09-25 22:50:59.000000000 +0200

...
```

----------

## Mickael

 :Laughing:  NO :

```
ls /usr/local/portage/net-wireless/ipw3945/

files  ipw3945-0.0.69.ebuild  Manifest

```

Have you got the good version?

----------

## VinzC

 *MickTux wrote:*   

> Have youo got the good version?

 

You have it  :Wink: 

```
cp /usr/portage/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild /usr/local/portage/net-wireless/ipw3945/

cd /usr/local/portage

patch -p1 < ~/ipw3945-ebuild.diff

ebuild /usr/local/portage/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild digest

emerge -pv ipw3945
```

Remember to edit the patch before you use it.

----------

## wodan

 *VinzC wrote:*   

> Are you running the unstable/testing versions of ipw3945? If yes you should try to use the stable versions.

 

Yes, I did. Now I have downgraded to 

ipw3945-1.0.5

ipw3945d-1.7.18

Unfortunatly, it doesn't change anything. 

When you stop your wireless interface, what does 

```
cat /sys/class/net/eth1/device/rf_kill
```

output? Which baselayout do you use?

----------

## VinzC

 *wodan wrote:*   

> When you stop your wireless interface, what does 
> 
> ```
> cat /sys/class/net/eth1/device/rf_kill
> ```
> ...

 

Sure.

```
# /etc/init.d/net.eth1 stop

...
```

----------

## VinzC

Hell... Never kill your network interface while posting!  :Laughing: 

Hem... Kidding...

```
# /etc/init.d/net.eth1 stop

 * Stopping apache2 ...                                                   [ ok ]

 * Unmounting network filesystems ...                                     [ ok ]

 * Stopping ntpd ...                                                      [ ok ]

 * Stopping sshd ...                                                      [ ok ]

 * Stopping eth1

 *   Bringing down eth1

 *     Stopping dhcpcd on eth1 ...                                        [ ok ]

 *     Shutting down eth1 ...                                             [ ok ]

 *     Stopping wpa_cli on eth1 ...                                       [ ok ]

 *     Stopping wpa_supplicant on eth1 ...                                [ ok ]

$ cat /sys/class/net/eth1/device/rf_kill

1
```

With the RF_KILL switch on:

```
$ cat /sys/class/net/eth1/device/rf_kill

2
```

While the interface is up:

```
$ cat /sys/class/net/eth1/device/rf_kill

0
```

Note I had to 

```
modprobe -r ipw3945; sleep 3s; modprobe ipw3945
```

to restart the wireless network properly otherwise it never got associated:

```
# /etc/init.d/net.eth1 start

 * Starting eth1

 *   Wireless radio has been killed for interface eth1

 *   wpa_supplicant will launch, but not associate until

 *   wireles radio is re-enabled for interface eth1

 *   Starting wpa_supplicant on eth1 ...

ioctl[SIOCSIWMODE]: Resource temporarily unavailable

Could not configure driver to use managed mode

ioctl[SIOCGIWRANGE]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 7 value 0x1 - ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Resource temporarily unavailable                                                                               [ ok ]th param 5 value 0x1 -

 *   Starting wpa_cli on eth1 ...                                         [ ok ]

 *     Backgrounding ...
```

... Ugly...

----------

## wodan

 *VinzC wrote:*   

> 
> 
> Note I had to 
> 
> ```
> ...

 

That is exactly the behaviour I described. Instead of reloading your ipw3945 module you can echo 0 to /sys/class/net/eth1/device/rf_kill, but both are pretty ugly hacks. 

Can somebody else verify that this is intended behaviour, or should we file a bug?

----------

## rmh3093

i have this problem too, below is a cleaner solution, im posting all files involved just incase people have different or modified versions......

start and stop your ipw3945 interface like this "/etc/init.d/ipw3945 start"

```
modules=( "wpa_supplicant" )

wpa_supplicant_wlan="-Dwext"

associate_timeout_wlan=60
```

```
depend() {

        need ipw3945d

}

start() {

        ebegin "Starting ipw3945"

        echo 0 > /sys/class/net/${IPW3945}/device/rf_kill

        sleep 1

        /etc/init.d/net.${IPW3945} start

        eend ${?}

}

stop() {

        ebegin "Stopping ipw3945"

        echo 1 > /sys/class/net/${IPW3945}/device/rf_kill

        /etc/init.d/net.${IPW3945} stop

        eend ${?}

}
```

```
IPW3945="wlan"

```

```
PIDFILE=/var/run/ipw3945d/ipw3945d.pid

depend() {

        before net

}

start() {

        ebegin "Starting ipw3945d"

        start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \

                --pid-file=${PIDFILE} ${ARGS}

        sleep 2

        eend ${?}

}

stop() {

        ebegin "Stopping ipw3945d"

        start-stop-daemon --stop --exec /sbin/ipw3945 --pidfile ${PIDFILE}

        eend ${?}

}
```

```
ARGS="--timeout=-1 --quiet"

```

```
 ~ # /etc/init.d/ipw3945 restart

 * Stopping ipw3945 ...

 * Stopping wlan

 *   Bringing down wlan

 *     Stopping dhcpcd on wlan ...                                                     [ ok ]

 *     Shutting down wlan ...                                                          [ ok ]

 *     Stopping wpa_cli on wlan ...                                                    [ ok ]

 *     Stopping wpa_supplicant on wlan ...                                             [ ok ]

 * Starting ipw3945 ...

 * Starting wlan

 *   Starting wpa_supplicant on wlan ...                                               [ ok ]

 *   Starting wpa_cli on wlan ...                                                      [ ok ]

 *     wlan connected to "chronic54" at 00:90:4C:91:00:03

 *   wlan configured with address 10.69.1.107/24

 ~ #

```

----------

## VinzC

 *VinzC wrote:*   

> Note I had to 
> 
> ```
> modprobe -r ipw3945; sleep 3s; modprobe ipw3945
> ```
> ...

 

 *wodan wrote:*   

> That is exactly the behaviour I described. Instead of reloading your ipw3945 module you can echo 0 to /sys/class/net/eth1/device/rf_kill, but both are pretty ugly hacks. 
> 
> Can somebody else verify that this is intended behaviour, or should we file a bug?

 

I'd like to add that I never stop the WiFi using the init script. I use the RF_KILL switch (Dell's Fn+F2) instead. Doing this doesn't seem to bring all these problems for the deamon restarts the link and reconnects automatically. At least I never experienced the problem you described until I read your post  :Wink: .

Using the RF switch is enough for me though.

----------

## wodan

 *rmh3093 wrote:*   

> 
> 
> ```
> depend() {
> 
> ...

 

This will probably only work on your setup, because you hardcoded the path to your rf_kill file. How about using 

```

depend() {

        need ipw3945d

}

start() {

        ebegin "Starting ipw3945"

        echo 0 > /sys/class/net/${IPW3945}/device/rf_kill

        sleep 1

        /etc/init.d/net.${IPW3945} start

}

stop() {

        ebegin "Stopping ipw3945"

        echo 1 > /sys/class/net/${IPW3945}/device/rf_kill

        /etc/init.d/net.${IPW3945} stop

}

```

But still, this doesn't answer the question why the kill switch gets activated in the first place.

----------

## rmh3093

[quote="wodan"] *rmh3093 wrote:*   

> 
> 
> ```
> depend() {
> 
> ...

 

This will probably only work on your setup, because you hardcoded the path to your rf_kill file. How about using 

```

depend() {

        need ipw3945d

}

start() {

        ebegin "Starting ipw3945"

        echo 0 > /sys/class/net/${IPW3945}/device/rf_kill

        sleep 1

        /etc/init.d/net.${IPW3945} start

}

stop() {

        ebegin "Stopping ipw3945"

        echo 1 > /sys/class/net/${IPW3945}/device/rf_kill

        /etc/init.d/net.${IPW3945} stop

}

```

yeah thats how I should have had it... good catch, I have no idea why it dose that, my guess is that its a default option of the driver as I can not find it in any rc scripts, but maybe it hidden in the userland in a place I dont know about

----------

## wodan

 *rmh3093 wrote:*   

> 
> 
> yeah thats how I should have had it... good catch, I have no idea why it dose that, my guess is that its a default option of the driver as I can not find it in any rc scripts, but maybe it hidden in the userland in a place I dont know about

 

But thanks for the script. It works like net.eth1 is supposed to work, thank you very much. 

Oh, you should put "eend $?" at the end of start() and stop() to be more verbose and to support runscripts internal state mechanism.

----------

## par4noia

Okay, so I followed the Wiki entry for the IPW3945...At a certain stage, when emerge ieee80211, it said that the emerge would probably fail and to use some command 

```
/bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
```

But now, everytime I try to recompile my kernel I get an error, due to those missing files...

Any ideas?

----------

## clockwork06

So I have a problem with ipw3945 or perhaps the issue is with my wpa_supplicant config, or my lack of wireless knowledge.

I use wpa_supplicant with two networks primarily (home & work) and my home network is golden (wpa2) however at work we use static WEP, and I never assosiate. Here is my wpa_supplicant config:

```

network={

        ssid="work"

        key_mgmt=NONE

        wep_key0=$hexversionofkey

        priority=5

        wep_tx_keyidx=0

        auth_alg=SHARED

}

network={

        ssid="home"

        proto=WPA2

        key_mgmt=WPA-PSK

        priority=5

        psk=$wpakey

        pairwise=CCMP

        group=CCMP

}

```

Can annyone tell me how to configure the WEP stuff through iwconfig ? I will try that and verify if its an actual issue with wpa_supplicant or not. One thing that seems wierd is when I use wpa_gui and look at the work AP it doesnt display the WEP key, for home it doesnt show the psk either.

----------

## beatryder

 *clockwork06 wrote:*   

> So I have a problem with ipw3945 or perhaps the issue is with my wpa_supplicant config, or my lack of wireless knowledge.
> 
> I use wpa_supplicant with two networks primarily (home & work) and my home network is golden (wpa2) however at work we use static WEP, and I never assosiate. Here is my wpa_supplicant config:
> 
> ```
> ...

 

Sure:

```

man iwconfig

```

if that does not help, then you can try this:

```

iwconfig eth1 essid "<your ssid here>" key <your key here>

```

if you have an ascii key

```

iwconfig eth1 essid "<your ssid here>" key s:<your key here>

```

----------

## rmh3093

 *par4noia wrote:*   

> Okay, so I followed the Wiki entry for the IPW3945...At a certain stage, when emerge ieee80211, it said that the emerge would probably fail and to use some command 
> 
> ```
> /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
> ```
> ...

 

just another reason why some of us are using the in kernel ieee80211 and a modified ipw3945 ebuild which dose not depend on the portage ieee80211 support

----------

## rmh3093

 *clockwork06 wrote:*   

> So I have a problem with ipw3945 or perhaps the issue is with my wpa_supplicant config, or my lack of wireless knowledge.
> 
> I use wpa_supplicant with two networks primarily (home & work) and my home network is golden (wpa2) however at work we use static WEP, and I never assosiate. Here is my wpa_supplicant config:
> 
> ```
> ...

 

i know you are asking about iwconfig, but I would use wpa_supplicant for both connections.

if you add "update_config=1" to wpa_supplicant.conf wpa_gui can modify the config file and it work very nicely.

I wasnt quite sure if you could connect with WPA2 or WEP or neither so here is how your config should look (or at least one to try):

```
ctrl_interface=/var/run/wpa_supplicant

update_config=1

#WPA2

network={

        ssid="home"

        psk="your_key_here"

        proto=RSN

        key_mgmt=WPA-PSK

        pairwise=CCMP

}

#WEP

network={

        ssid="work"

        key_mgmt=NONE

        wep_key0="your_key_here"

}

```

----------

## clockwork06

My home network is working ok. (wpa2) I'll give the config a shot at the office tomorrow. Thanks a bunch.

----------

## VinzC

 *rmh3093 wrote:*   

> 
> 
> ```
> ...
> 
> ...

 

With wpa_supplicant.conf your wep key must not be surrounded with quotes. I once had the problem with WPA supplicant not associating with WEP access points until I looked at the error messages. WEP keys were truncated and the start quote was part of the key that was said invalid. Hence I removed the quotes and now I can successfully connect to WEP and WPA access points as well.

----------

## rmh3093

wpa_gui puts quotes around my keys and they all work fine.... hmm  :Question: 

edit: i am fairly sure psk and ssid should be in quotes, look at the man page for wpa_supplicant.conf

----------

## clockwork06

I didnt use quotes. its just the hex key. Here is the debug output from wpa_supplicant:

```
Trying to associate with $CORRECTAPMAC (SSID='Work' freq=0 MHz)

Cancelling scan request

WPA: clearing own WPA/RSN IE

Automatic auth_alg selection: 0x1

WPA: clearing AP WPA IE

WPA: clearing AP RSN IE

WPA: clearing own WPA/RSN IE

No keys have been configured - skip key clearing

wpa_driver_wext_set_key: alg=1 key_idx=0 set_tx=1 seq_len=0 key_len=13

ioctl[SIOCSIWENCODEEXT]: Invalid argument

Driver did not support SIOCSIWENCODEEXT

wpa_driver_wext_set_drop_unencrypted

State: SCANNING -> ASSOCIATING

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)

WEXT: Operstate: linkmode=-1, operstate=5

wpa_driver_wext_associate

Setting authentication timeout: 10 sec 0 usec

EAPOL: External notification - portControl=ForceAuthorized

RTM_NEWLINK: operstate=0 ifi_flags=0x1002 ()

Wireless event: cmd=0x8b06 len=8

RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])

RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added

RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])

RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added

RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])

Wireless event: cmd=0x8b06 len=8

RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])

Wireless event: cmd=0x8b1a len=16

CTRL-EVENT-TERMINATING - signal 2 received

Removing interface eth1

State: ASSOCIATING -> DISCONNECTED

wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)

WEXT: Operstate: linkmode=-1, operstate=5

wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0

wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0

EAPOL: External notification - portEnabled=0

EAPOL: External notification - portValid=0

wpa_driver_wext_set_wpa

wpa_driver_wext_set_drop_unencrypted

wpa_driver_wext_set_countermeasures

No keys have been configured - skip key clearing

WEXT: Operstate: linkmode=0, operstate=6

Cancelling scan request

```

"No keys have been configured - skip key clearing" -- that seems like its not setting the key. That would be a problem. Is there anyway I can do this manually ? Just to eliminate any wpa_supplicant related issues.

----------

## rmh3093

did you try with quotes? its really weird that WPA is working for you and not WEP, usually its the other way around

----------

## clockwork06

Using quotes around the wep key I get the following error:

Line 18: Too long WEP key 0 ' "$WEPKEY '.

Obviously something is wrong. Does anyone have a working static WEP config for ipw3945 that they could share ?

How would I do this manually ?

Is anything other than ipw3945 & wpa_supplicant needed for this ?

----------

## VinzC

WPA/PSK values must be in quotes. WEP keys must not be in quotes.

EDIT: can wpa_supplicant.conf contain shell variables? Is it a source'd script?

 *Quote:*   

> Too long WEP key

 

is the error message I got when I used quotes for WEP keys.

----------

## par4noia

 *rmh3093 wrote:*   

>  *par4noia wrote:*   Okay, so I followed the Wiki entry for the IPW3945...At a certain stage, when emerge ieee80211, it said that the emerge would probably fail and to use some command 
> 
> ```
> /bin/sh /usr/portage/net-wireless/ieee80211/files/remove-old /usr/src/linux
> ```
> ...

 

Well, the Wiki has never failed me, but this time it did...

How can I revert this now? I mean, I want to have in kernel ieee80211..

----------

## VinzC

 *par4noia wrote:*   

> How can I revert this now? I mean, I want to have in kernel ieee80211..

 

Simple. First backup your /usr/src/linux/.config file and clean your kernel (make clean). Restore your config file and run make oldconfig.

Next compile your kernel with ieee80211 selected as a module or built-in. Finally follow the guide I wrote on page 13. Note: install the stable ipw3945 for the patch I wrote applies to ipw3945-1.0.5 series, not to the masked ones.

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   How can I revert this now? I mean, I want to have in kernel ieee80211.. 
> 
> Simple. First backup your /usr/src/linux/.config file and clean your kernel (make clean). Restore your config file and run make oldconfig.
> 
> Next compile your kernel with ieee80211 selected as a module or built-in. Finally follow the guide I wrote on page 13. Note: install the stable ipw3945 for the patch I wrote applies to ipw3945-1.0.5 series, not to the masked ones.

 

Well, after doing what you said, I'm still getting this error

 *Quote:*   

> make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.o', needed by `net/ieee80211/ieee80211.o'.  Stop.
> 
> make[1]: *** [net/ieee80211] Error 2
> 
> make: *** [net] Error 2
> ...

 

----------

## par4noia

Well, never mind, I got this to work...I was just doing something silly  :Razz: 

----------

## VinzC

 *par4noia wrote:*   

> Well, never mind, I got this to work...I was just doing something silly 

 

Maybe I forgot to tell you to unmerge ieee80211 for it can mess up with the kernel module. BTW what was that something silly that you were doing? (It might spare time to those who would make the same mistake.)  :Wink: 

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   Well, never mind, I got this to work...I was just doing something silly  
> 
> Maybe I forgot to tell you to unmerge ieee80211 for it can mess up with the kernel module. BTW what was that something silly that you were doing? (It might spare time to those who would make the same mistake.) 

 

I missread your post, so all I was doing was backing up .config and then make clean..lol

Anyway, now that I have built-in ieee80211 again, all I need to do is apply your patch to the ipw3945 ebuild? I still need the ipw3945d daemon right?

----------

## par4noia

I'm now having some trouble applying your patch..

 *Quote:*   

> immega portage # patch -p1 < ~/ipw3945-ebuild.diff
> 
> patching file net-wireless/ipw3945/ipw3945-1.0.5.ebuild
> 
> Hunk #1 FAILED at 17.
> ...

 

----------

## VinzC

 *par4noia wrote:*   

> I'm now having some trouble applying your patch..

 

Did you create the patch by copying/pasting from my post directly or did you quote the post and copy the text between the [code] blocks?

----------

## VinzC

Important note

With 2.6.18 series you must use portage's ieee80211 for the ieee802.11 API has changed in the kernel. Hence the modified ipw3945 ebuild doesn't apply to the 2.6.18 series.

----------

## faible

 :Arrow: 

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   I'm now having some trouble applying your patch.. 
> 
> Did you create the patch by copying/pasting from my post directly or did you quote the post and copy the text between the [code] blocks?

 

I quoted your text and copy the code...But anyway, I don't think I need to apply the patch now, as I'm upgrading to 2.6.18...

----------

## rmh3093

 *VinzC wrote:*   

> Important note
> 
> With 2.6.18 series you must use portage's ieee80211 for the ieee802.11 API has changed in the kernel. Hence the modified ipw3945 ebuild doesn't apply to the 2.6.18 series.

 

HA! That is not true exactly, I compiled it against  2.6.18. I did have to change the ieee80211 api version to "2" in 'include/net/ieee80211.h'

or change the ipw3945 module code and take out the lines that check for an api=1

----------

## VinzC

 *rmh3093 wrote:*   

> HA! That is not true exactly, I compiled it. 2.6.18 did change the ieee80211 api version to "2" in 'include/net/ieee80211.h'

 

Hmmm... Cool  :Smile:  I suppose then all you had to do is edit that file and change the #define value (I'm not in front of my Gentoo machine right now)?

----------

## Lloeki

 *Quote:*   

> But now, everytime I try to recompile my kernel I get an error, due to those missing files... 

 

probably zd1211 usb wireless dongle support failing to build. try to remove it via menu config under usb support -> networking devices (or stg like that)

 *Quote:*   

> just another reason why some of us are using the in kernel ieee80211 and a modified ipw3945 ebuild which dose not depend on the portage ieee80211 support

 

it would be great if a ieee80211_kernel useflag was to be set to allow just that...

----------

## rmh3093

 *Quote:*   

>  *Quote:*   just another reason why some of us are using the in kernel ieee80211 and a modified ipw3945 ebuild which dose not depend on the portage ieee80211 support 
> 
> it would be great if a ieee80211_kernel useflag was to be set to allow just that...

 

thats what I have been saying

```
--- ipw3945-1.1.0-r1.ebuild.orig   2006-10-04 18:10:11.000000000 -0400

+++ ipw3945-1.1.0-r1.ebuild   2006-10-04 18:13:25.000000000 -0400

@@ -18,9 +18,9 @@

 SLOT="0"

 KEYWORDS="~x86"

 

-IUSE="debug"

-DEPEND="=net-wireless/ieee80211-${IEEE80211_VERSION}"

-RDEPEND="=net-wireless/ieee80211-${IEEE80211_VERSION}

+IUSE="debug ieee80211_kernel"

+DEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})"

+RDEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})

       >=net-wireless/ipw3945-ucode-${UCODE_VERSION}

       >=net-wireless/ipw3945d-${DAEMON_VERSION}"

 

@@ -40,7 +40,7 @@

       die "${P} does not support building against kernel 2.4.x"

    fi

 

-   if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]]; then

+   if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]] && use !ieee80211_kernel; then

       eerror

       eerror "Looks like you forgot to remerge net-wireless/ieee80211 after"

       eerror "upgrading your kernel."

```

----------

## rmh3093

Here is a diff of a tweaked version of the ipw3945-1.1.0-r1 ebuild and the actual modified ebuild for you non-patchers   :Wink: . It has a use flag to support building against the in-kernel ieee80211 subsystem and it also supports 2.6.18 kernels.

```
--- ipw3945-1.1.0-r1.ebuild.orig   2006-10-04 18:10:11.000000000 -0400

+++ ipw3945-1.1.0-r1.ebuild   2006-10-04 18:35:51.000000000 -0400

@@ -18,9 +18,9 @@

 SLOT="0"

 KEYWORDS="~x86"

 

-IUSE="debug"

-DEPEND="=net-wireless/ieee80211-${IEEE80211_VERSION}"

-RDEPEND="=net-wireless/ieee80211-${IEEE80211_VERSION}

+IUSE="debug ieee80211_kernel"

+DEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})"

+RDEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})

       >=net-wireless/ipw3945-ucode-${UCODE_VERSION}

       >=net-wireless/ipw3945d-${DAEMON_VERSION}"

 

@@ -40,7 +40,7 @@

       die "${P} does not support building against kernel 2.4.x"

    fi

 

-   if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]]; then

+   if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]] && use !ieee80211_kernel; then

       eerror

       eerror "Looks like you forgot to remerge net-wireless/ieee80211 after"

       eerror "upgrading your kernel."

@@ -51,7 +51,11 @@

       die "${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} not found"

    fi

 

-   BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

+   if kernel_is ge 2 6 18; then

+      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_IGNORE_DUPLICATE=y"

+   else

+      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

+   fi

 }

 

 src_unpack() {

@@ -66,6 +70,10 @@

       -e "s:^# \(CONFIG_IPW3945_PROMISCUOUS\)=.*:\1=y:" \

       "${S}"/Makefile || die

 

+   if kernel_is ge 2 6 18 && use ieee80211_kernel; then

+      sed -i -e "s:^\(   EXTRA_CFLAGS += -DIEEE80211_API_VERSION\)=.*:\1=2:" "${S}"/Makefile || die

+   fi

+

    use debug && debug="y"

    sed -i -e "s:^\(CONFIG_IPW3945_DEBUG\)=.*:\1=${debug}:" "${S}"/Makefile || die

 }

```

```
# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-wireless/ipw3945/ipw3945-1.1.0-r1.ebuild,v 1.1 2006/09/16 06:21:27 phreak Exp $

inherit linux-mod

S=${WORKDIR}/${P/_pre/-pre}

IEEE80211_VERSION="1.1.13-r1"

UCODE_VERSION="1.13"

DAEMON_VERSION="1.7.22"

DESCRIPTION="Driver for the Intel PRO/Wireless 3945ABG miniPCI express adapter"

HOMEPAGE="http://ipw3945.sourceforge.net/"

SRC_URI="mirror://sourceforge/${PN}/${P/_pre/-pre}.tgz"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~x86"

IUSE="debug ieee80211_kernel"

DEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})"

RDEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})

      >=net-wireless/ipw3945-ucode-${UCODE_VERSION}

      >=net-wireless/ipw3945d-${DAEMON_VERSION}"

BUILD_TARGETS="all"

MODULE_NAMES="ipw3945(net/wireless:)"

MODULESD_IPW3945_DOCS="README.ipw3945"

CONFIG_CHECK="NET_RADIO FW_LOADER !IPW3945"

ERROR_NET_RADIO="${P} requires support for Wireless LAN drivers (non-hamradio) & Wireless Extensions (CONFIG_NET_RADIO)."

ERROR_FW_LOADER="${P} requires Hotplug firmware loading support (CONFIG_FW_LOADER)."

ERROR_IPW3945="${P} requires the in-kernel version of the IPW3945 driver to be disabled (CONFIG_IPW3945)"

pkg_setup() {

   linux-mod_pkg_setup

   if kernel_is 2 4; then

      die "${P} does not support building against kernel 2.4.x"

   fi

   if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]] && use !ieee80211_kernel; then

      eerror

      eerror "Looks like you forgot to remerge net-wireless/ieee80211 after"

      eerror "upgrading your kernel."

      eerror

      eerror "Hint: use sys-kernel/module-rebuild for keeping track of which"

      eerror "modules needs to be remerged after a kernel upgrade."

      eerror

      die "${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} not found"

   fi

   if kernel_is ge 2 6 18; then

      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_IGNORE_DUPLICATE=y"

   else

      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

   fi

}

src_unpack() {

   local debug="n"

   unpack ${A}

   sed -i \

      -e "s:^#\(CONFIG_IPW3945_QOS\)=.*:\1=y:" \

      -e "s:^# \(CONFIG_IPW3945_MONITOR\)=.*:\1=y:" \

      -e "s:^# \(CONFIG_IEEE80211_RADIOTAP\)=.*:\1=y:" \

      -e "s:^# \(CONFIG_IPW3945_PROMISCUOUS\)=.*:\1=y:" \

      "${S}"/Makefile || die

   if kernel_is ge 2 6 18 && use ieee80211_kernel; then

      sed -i -e "s:^\(   EXTRA_CFLAGS += -DIEEE80211_API_VERSION\)=.*:\1=2:" "${S}"/Makefile || die

   fi

   use debug && debug="y"

   sed -i -e "s:^\(CONFIG_IPW3945_DEBUG\)=.*:\1=${debug}:" "${S}"/Makefile || die

}

src_compile() {

   linux-mod_src_compile

   einfo

   einfo "You may safely ignore any warnings from above compilation about"

   einfo "undefined references to the ieee80211 subsystem."

   einfo

}

src_install() {

   linux-mod_src_install

   dodoc CHANGES ISSUES

}

```

----------

## alanokeefe

Hi all

I have a new Dell Precision M65 notebook, (2GHz Core 2, 2GB RAM, 15.4" WUXGA+ display    :Very Happy:  )

After a bit of fiddling, I have it pretty much all working correctly under gentoo, including ifplugd automatically bringing up either the ethernet or the wireless if they are connect/available.  

I have one problem, however, the wireless card seems to lose it's association with my access point, (DWL-900AP+), after around 15-30 minutes, and despite a lot of flickering, never seems to get it back, even if I turn it off and on with the hardware switch.

The only message in dmesg or /var/log/messages is:

ipw3945: Detected geography ABG (13 802.11bg channels, 4 802.11a channels)

Once it loses association, this message is written over and over in the log.

I am running:

Kernel:  2.6.17-gentoo-r7 #4 SMP

ipw3945:  

plebII ~ # equery list ipw3945

[ Searching for package 'ipw3945' in all categories among: ]

 * installed packages

[I--] [ ~] net-wireless/ipw3945-1.1.0-r1 (0)

[I--] [  ] net-wireless/ipw3945-ucode-1.13 (0)

[I--] [ ~] net-wireless/ipw3945d-1.7.22-r3 (0)

plebII ~ # equery list ieee80211

[ Searching for package 'ieee80211' in all categories among: ]

 * installed packages

[I--] [  ] net-wireless/ieee80211-1.1.13-r1 (0)

Any help appreciated.

Thanks

Alan

----------

## par4noia

I'm trying to use the built-in ieee80211, but when I try to emerge the ipw3945 ebuild it trys to emerge ieee80211 ebuild from portage (which will fail cause I have it built-in)...

What am I doing wrong?

----------

## Fran

Mmm... I'm having a problem with the built-in ieee80211 in kernel 2.6.19-rc1. Everything compiles fine, but I have no network. dmesg shows:

```
ieee80211_crypt: registered algorithm 'WEP'

ieee80211_crypt_wep: could not allocate crypto API arc4

eth1: could not initialize WEP: load module ieee80211_crypt_wep
```

And yes, I have enabled (built-in, not module) "ARC4 cipher algorithm" inside "Cryptographic API".

Anyone else with this problem?

----------

## Dumble

For ipw3945, you must not use the built-in ieee80211 but the one provided externally by this ebuild.

----------

## Fran

 *Dumble wrote:*   

> For ipw3945, you must not use the built-in ieee80211 but the one provided externally by this ebuild.

 

It works ok with kernel 2.6.18, there is a modified ebuild above.

----------

## rmh3093

 *Fran wrote:*   

>  *Dumble wrote:*   For ipw3945, you must not use the built-in ieee80211 but the one provided externally by this ebuild. 
> 
> It works ok with kernel 2.6.18, there is a modified ebuild above.

 

Cool, so people have tested that ebuild and it does work. I submitted a message to bugs.gentoo.org with the above fixes, maybe we will see them in portage soon.

----------

## Dumble

 *Fran wrote:*   

>  *Dumble wrote:*   For ipw3945, you must not use the built-in ieee80211 but the one provided externally by this ebuild. 
> 
> It works ok with kernel 2.6.18, there is a modified ebuild above.

 

I did not knew. Thanks for the information !

----------

## VinzC

 *alanokeefe wrote:*   

> ... including ifplugd automatically bringing up either the ethernet or the wireless if they are connect/available.

 

I'd use netplug instead. IIRC netplug is Gentoo's recommended way.

 *alanokeefe wrote:*   

> I have one problem, however, the wireless card seems to lose it's association with my access point, (DWL-900AP+), after around 15-30 minutes, and despite a lot of flickering, never seems to get it back, even if I turn it off and on with the hardware switch.

 

Are you using WPA supplicant? I've had something similar once I switched to wpa_supplicant. It was as hard as hell to connect to a WiFi network. Only lately did I sync and an updated version of wpa_supplicant (stable branch) made the problem disappear.

 *alanokeefe wrote:*   

> I am running:
> 
> Kernel:  2.6.17-gentoo-r7 #4 SMP
> 
> ipw3945:  
> ...

 

I'd recommend using stable packages at first. Only if loading the module doesn't run the daemon then you can consider using the ~x86 branch.

----------

## VinzC

 *par4noia wrote:*   

> I'm trying to use the built-in ieee80211, but when I try to emerge the ipw3945 ebuild it trys to emerge ieee80211 ebuild from portage (which will fail cause I have it built-in)...
> 
> What am I doing wrong?

 

Are you using rmh3093's ipw3945 ebuild?

----------

## Lloeki

rmh3903, I had an issue with your ebuild:

```
if kernel_is ge 2 6 18 && use ieee80211_kernel; then

      sed -i -e "s:^\(   EXTRA_CFLAGS += -DIEEE80211_API_VERSION\)=.*:\1=2:" "${S}"/Makefile || die

   fi 
```

with your expression, sed missed the line because of an incorrect number of spaces, so I changed it to:

```
if kernel_is ge 2 6 18 && use ieee80211_kernel; then

      sed -i -e "s:^\(.*EXTRA_CFLAGS += -DIEEE80211_API_VERSION\)=.*:\1=2:" "${S}"/Makefile || die

   fi 
```

and it worked  :Smile: 

----------

## rmh3093

your syntax looks much better  :Smile:  thanks.... the corrections will updated on bugs.gentoo.org asap

EDIT: https://bugs.gentoo.org/show_bug.cgi?id=150291

----------

## VinzC

And why not

```
if kernel_is ge 2 6 18 && use ieee80211_kernel; then

      sed -i -e "s:^\([[:space:]]*EXTRA_CFLAGS += -DIEEE80211_API_VERSION\)=[[:digit:]]*:\1=2:" "${S}"/Makefile || die

   fi 
```

?

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   I'm trying to use the built-in ieee80211, but when I try to emerge the ipw3945 ebuild it trys to emerge ieee80211 ebuild from portage (which will fail cause I have it built-in)...
> 
> What am I doing wrong? 
> 
> Are you using rmh3093's ipw3945 ebuild?

 

Yea, I used the one he posted a few posts above...

----------

## Lloeki

 *Quote:*   

> And why not
> 
> Code:(snip)?

 

because I didn't know if there were tabs or whatever chars... and because I'm not that good at sed  :Wink: 

 *Quote:*   

> Yea, I used the one he posted a few posts above...

 

but did you set the use flag correctly?

----------

## par4noia

 *Lloeki wrote:*   

> 
> 
>  *Quote:*   Yea, I used the one he posted a few posts above... 
> 
> but did you set the use flag correctly?

 

Stupid me!! Thanks  :Wink: 

----------

## Lloeki

I regularly encounter some connection drops while downloading or transferring large amounts of data.

a quick google search led me to this page. I exhibit exact same messages in dmesg:

```
TKIP: ICV error detected: STA=00:04:0e:7e:7a:58

TKIP: ICV error detected: STA=00:04:0e:7e:7a:58

TKIP: ICV error detected: STA=00:04:0e:7e:7a:58

TKIP: ICV error detected: STA=00:04:0e:7e:7a:58

N/A: Michael MIC verification failed for MSDU from 00:04:0e:7e:7a:58 keyidx=0

wlan: MSDU decryption/MIC verification failed (SA=00:04:0e:7e:7a:58 keyidx=0)
```

so I decided to go for the patch, since I favor kernel rather than ieee80211 ebuild.

the patch applies cleanly against suspend2 2.6.18:

```
# cd /usr/src/linux/

# cd net/ieee80211/

# patch ieee80211_crypt_tkip.c /home/lloeki/download/ieee80211-1.1.14-tkip.patch

patching file ieee80211_crypt_tkip.c

Hunk #1 succeeded at 52 (offset -1 lines).

Hunk #2 succeeded at 87 (offset -1 lines).

Hunk #3 succeeded at 119 (offset -1 lines).

Hunk #4 succeeded at 136 (offset -1 lines).

Hunk #5 succeeded at 375 (offset -1 lines).

Hunk #6 succeeded at 458 (offset -13 lines).

Hunk #7 succeeded at 496 (offset -13 lines).

Hunk #8 succeeded at 513 (offset -13 lines).

Hunk #9 succeeded at 574 (offset -13 lines).

Hunk #10 succeeded at 612 (offset -37 lines).

Hunk #11 succeeded at 642 (offset -37 lines).

```

EDIT: it applies just the same against 2.6.17

I have recompiled the kernel without a hitch, and will report results after some testing.

EDIT: for now, all seems well. downloading some big torrent or scp'ing some big file was guaranteed to make it go boom, but now it seems rock solid.

EDIT: the bug also affects WEP in certain conditions

----------

## VinzC

I also "suffered" from disconnections when downloading MP3's from my server. Reconnecting was often painful. Now I've upgraded wpa_supplicant to version 0.5.4 the problem doesn't happen anymore. I'm also using 2.6.17-suspend2-r6 but 2.6.17 series should work as well. Note I'm also using only stable ipw3945 packages (yes, I know, I've already said that  :Wink:  ).

----------

## Lloeki

this patch definitely fixed my issues  :Smile:  the bug was occuring on both my gf's laptop (asus w7j) and on mine (dell m1210).

symptoms were sudden connection loss while transferring serious amounts of data like huge concurrent downloads, bittorrent, scp'ing big files, or even 'emerge suspend2-sources' over ssh (it generates lots of output in a very short amount of time). at this point, 'dmesg | grep -e TKIP -e N/A' will show significant information (see patch page). if you have not set an associate timeout (you really shouldn't anyway), reconnection is automatic after some minutes. 

note that at the beginning only one pc was 'fixed', and the other one hit the wall, seemingly bringing the whole wlan down. once I fixed both, things were cleared.

the bug has been fully identified as being in the ieee80211 subsystem, and has been fixed upstream. real solution is to update to latest ieee80211 (which fixes wep, wpa, and others), or to use patch (which fixes only wpa tkip).

----------

## rmh3093

has anyone tried my ebuild with the 2.6.19-rc1

----------

## ArtX

I have the acer 5672wmli and also here there are this wireless device and I don't meet a problems to install the drivers.

My only problem is to configure this to start on boot automatic.

I have a lan wi-fi at home not protect because I think is not necessary and I don't use wpa_supplicant.

when I start gentoo for connect me to the internet I utiliza this steps:

 *Quote:*   

> 
> 
> iwconfig eth2 essid "MY_NAME_NETWORK"
> 
> ifconfgi eth2 my_IP
> ...

 

you can help me for configure this network for start automatic at boot please? I tryed to follow the gentoo-wiki but I don't understend?

what is the function of wpa_supplicant? it's only for the wi-fi with acces key or it's olso for wi-fi without the key?

another question: can I read the boot output when linux is running, because is too fast and I can't read all?

thank you

----------

## unz

 *ArtX wrote:*   

> 
> 
> another question: can I read the boot output when linux is running, because is too fast and I can't read all?
> 
> thank you

 

```
dmesg

*or*

cat /var/log/messeges

```

----------

## alanokeefe

Hi there

I have installed wpa_supplicant and it seems to be stable now, not sure why, as I'm not using WPA.

As it's working, I'm not going to down-grade to stable versions, hopefully stable will catch up to me   :Wink: 

Thanks for your help.

 *VinzC wrote:*   

>  *alanokeefe wrote:*   ... including ifplugd automatically bringing up either the ethernet or the wireless if they are connect/available. 
> 
> I'd use netplug instead. IIRC netplug is Gentoo's recommended way.
> 
>  *alanokeefe wrote:*   I have one problem, however, the wireless card seems to lose it's association with my access point, (DWL-900AP+), after around 15-30 minutes, and despite a lot of flickering, never seems to get it back, even if I turn it off and on with the hardware switch. 
> ...

 

----------

## Lloeki

from phoronix, drag said:

 *Quote:*   

> They did that with OpenBSD driver's for Intel's newer wifi stuff. Intel released code for the wifi kernel portion, but stuck the binary portion in user space. So it was fine according to the Linux kernel developers. The OBSD developer setup Linux and wrote a program to intercept calls to that binary. that way he was able to figure out to write OBSD drivers without having to actually violate the license by examining the intel binary directly.

 

wow. could we see OBSD's ipw3945d ported to linux someday?

----------

## VinzC

 *Lloeki wrote:*   

> ...
> 
> wow. could we see OBSD's ipw3945d ported to linux someday?

 

Yes, I hope so too... And why not include the daemon into the kernel once for all and stop tinkering with init scripts, custom module launch instructions aso?...  :Rolling Eyes: 

----------

## Lloeki

more info. this seems highly interesting.

 *Quote:*   

> Porting wpi
> 
> When asked the likelihood that the wpi driver would be ported to Linux, Damien thought that this was unlikely. "I doubt the Linux community will ever leverage this work since Intel is developing a 802.11 layer for the Linux kernel," he said, "Linux kernel developers probably can't afford to upset Intel." 

 

Seeing how kernel maintainers hate blobs, I don't think this one quote is really relevant.

----------

## zidour

First of all, it has been a long time since I was reading this forum. I tried to search for some relevant posts but I did not find anything. I am sorry if any of the following questions were already answered.

OK, what's the problem?

Some time ago I noticed that the ipw3945 module (or may be one of its friends, be it ieee80211 or ipw3945d daemon) behaves somehow strange. Unfortunately I am not sure when exactly this happened. May be it was some kind of package upgrade or kernel upgrade. I don't know. I was a little bit busy at that time so there was no time to investigate the problem.

1) Sometimes when the computer was booting, it suddenly froze when entering X. The workaround was to acrivate the Radio kill switch. I know this has already been discussed and the issue has probably disappeared but it seems to me that noone knows what exactly was the problem.

2)

 *beatryder wrote:*   

> Has anyone noticed that the ieee80211 keeps upgrading and then downgrading on successive emerge -Du world's?

 

Yes, I have. Are we the only two people experiencing this?

3) Sometimes when my computer boots, there is a process called "ipw3945/0" eating 100% CPU. If I stop the ipw3945d daemon and try to unload the ipw3945 module, the process just stays there and nothing happens. Sometimes if I reboot the computer, the problem disappears, but basically there is a 50% chance this issue appears when the computer is switched on or restarted. I am running full ~x86 so I tried different versions of ipw3945, iee80211, etc., but sooner or later the problem appeared again. 

My emerge --info:

```

~ $ emerge --info

Portage 2.1.2_pre2-r9 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.18-gentoo i686)

=================================================================

System uname: 2.6.18-gentoo i686 Genuine Intel(R) CPU           T2300  @ 1.66GHz

Gentoo Base System version 1.12.5

Last Sync: Thu, 12 Oct 2006 09:30:01 +0000

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: 1.3.7, 2.0.30

dev-lang/python:     2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.18.1

sys-devel/autoconf:  2.13, 2.60

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.17

sys-devel/gcc-config: 1.3.13-r4

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r1

ACCEPT_KEYWORDS="x86 ~x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=pentium-m -pipe -msse3 -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-O2 -march=pentium-m -pipe -msse3 -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="--alphabetical"

FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://gentoo.supp.name ftp://ftp.sh.cvut.cz/MIRRORS/gentoo http://cudlug.cudenver.edu/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo"

LINGUAS="en cs"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="x86 X aac acpi alsa amr berkdb bitmap-fonts blas bluetooth bzip2 cairo cdr cli crypt css dbus divx dlloader dri dvd dvdr dvdread eds elibc_glibc emboss encode exif fam ffmpeg firefox flac fortran gdbm gif glitz gmedia gpm gstreamer gtk hal hdf5 imagemagick input_devices_keyboard input_devices_mouse isdnlog java jpeg jpeg2k kde kdeenablefinal kernel_linux libg++ linguas_cs linguas_en mad mikmod mjpeg mmx mozsvg mp3 mpeg mpi musepack ncurses nls nptl nptlonly nsplugin ogg opengl pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline real realmedia reflection samba sdl session smp spell spl sse sse2 ssl svg tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_i810 video_cards_vesa vorbis win32codecs wma wmf wmp x264 xml xorg xscreensaver xv xvid zlib"

Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

Thanks for any clues.

----------

## VinzC

 *Lloeki wrote:*   

> ...
> 
> Seeing how kernel maintainers hate blobs, I don't think this one quote is really relevant.

 

I don't know if I wasn't clear but I was only talking about the "reverse-engineered" daemon. That 's the one I wish it could be included in the kernel, not the proprietary one, of course.

----------

## VinzC

 *zidour wrote:*   

> 
> 
> ```
> ~ $ emerge --info
> 
> ...

 

Do *not* run full "testing" branch on a laptop. Use stable packages as much as you can. Use only testing when absolutely necessary.

Also, try removing the -msse3 flag (I assume you're running GCC 4.1). There are issues with customizations made by users so the best is to keep safe CLAGS.

I know the daemon is proprietary software but I've read that advice too many times not to tell it myself.

----------

## Lloeki

 *Quote:*   

> I don't know if I wasn't clear

 

maybe it's me which wasn't clear. what I meant is that seeing how kernel guys advocate for opensource, the current driver is unlikely to be included, and if someone ports wpi to linux, they'll certainly be glad to include it, regardless on intel's PoV.

----------

## Fran

Hum, ipw3945 doesn't compile with 2.6.19-rc2. Including config.h was deprecated in 2.6.19-rc1:

```
make[1]: Entering directory `/usr/src/linux-2.6.19-rc1'

  CC [M]  /var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.o

In file included from /var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.h:32,

                 from /var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.c:68:

include/linux/config.h:6:2: warning: #warning Including config.h is deprecated.

  Building modules, stage 2.
```

But it compiled anyway. However, config.h has been removed in 2.6.19-rc2:

```
make[1]: Entering directory `/usr/src/linux-2.6.19-rc2'

  CC [M]  /var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.o

In file included from /var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.c:68:

/var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.h:32:26: error: linux/config.h: No such file or directory

/var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.c: In function ipw_pci_probe:

/var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.c:16355: warning: passing argument 2 of request_irq from incompatible pointer type

make[2]: *** [/var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0/ipw3945.o] Error 1

make[1]: *** [_module_/var/tmp/portage/net-wireless/ipw3945-1.1.0-r1/work/ipw3945-1.1.0] Error 2

make[1]: Leaving directory `/usr/src/linux-2.6.19-rc2'

make: *** [modules] Error 2
```

Well, for now I've copied the old config.h in include/linux and it compiles, but the warning about passing argument 2 of request_irq from incompatible pointer type remains. I haven't tested the module, but it seems that this warning is quite serious.

(edit) Yep, the definition of request_irq has changed from:

```
extern int request_irq(unsigned int,

                       irqreturn_t (*handler)(int, void *, struct pt_regs *),

                       unsigned long, const char *, void *);

```

to

```
typedef irqreturn_t (*irq_handler_t)(int, void *);

extern int request_irq(unsigned int, irq_handler_t handler,

                       unsigned long, const char *, void *);

```

This patch solves it:

```
--- ipw3945.c   2006-10-14 13:32:15.000000000 +0200

+++ ipw3945.c   2006-10-14 13:39:35.000000000 +0200

@@ -15112,7 +15112,7 @@

        .get_eeprom = ipw_ethtool_get_eeprom,

 };

-static irqreturn_t ipw_isr(int irq, void *data, struct pt_regs *regs)

+static irqreturn_t ipw_isr(int irq, void *data)

 {

        struct ipw_priv *priv = data;

        u32 inta, inta_mask;

```

But the card is unable to connect to the AP. The led blinks for some seconds and then stops, unable to establish the connection, like it happened in 2.6.19-rc1. Maybe the last ieee802 stack is incompatible with the driver.

----------

## rmh3093

hmmm, thanks for you work so far debugging the driver in .19.... i will take a look at this later tonight

----------

## Mickael

 *VinzC wrote:*   

>  *zidour wrote:*   
> 
> ```
> ~ $ emerge --info
> 
> ...

 

Why?

----------

## beatryder

 *MickTux wrote:*   

>  *VinzC wrote:*    *zidour wrote:*   
> 
> ```
> ~ $ emerge --info
> 
> ...

 

Yeah Why? I have had to run a ton of ~x86 software on my laptop just to get it all working properly.

----------

## rmh3093

 *beatryder wrote:*   

>  *MickTux wrote:*    *VinzC wrote:*    *zidour wrote:*   
> 
> ```
> ~ $ emerge --info
> 
> ...

 

yeah i always have too new of hardware  :Wink:  so running ~x86/~amd64 is almost necessary to get a functional machine

----------

## wswartzendruber

Eh, I've always run ACCEPT_KEYWORDS="~x86"  The only time I don't do that is for production servers.

----------

## VinzC

 *VinzC wrote:*   

> Do *not* run full "testing" branch on a laptop. Use stable packages as much as you can. Use only testing when absolutely necessary.

 

 *MickTux wrote:*   

> Why?

 

Because it's the best way for your system to get borked. It's Gentoo, not me.  :Smile: 

----------

## rmh3093

 *VinzC wrote:*   

> Because it's the best way for your system to get borked

 

naa im pretty sure downgrading glibc takes the cake

----------

## Noven

Regarding the ieee80211 upgrade / downgrade issue: yes, this happens unless you remove ieee80211 from the world file. The issue is that the latest version is 1.2.15, so obviously emerge -u wants to update it. However ipw3945 doesn't actually work with it. It has a hard-coded dependency to 1.1.3-r1. So, when it comes time to ipw3945 to update, it downgrades ieee80211 to the version it needs. To avoid this issue emerge ieee80211 with --one-shot and/or manually remove it from the world database, and attempt to live with the fact that one of your programs is *not* the latest version (I'm getting counselling myself  :Smile: 

----------

## rmh3093

 *Noven wrote:*   

> Regarding the ieee80211 upgrade / downgrade issue: yes, this happens unless you remove ieee80211 from the world file. The issue is that the latest version is 1.2.15, so obviously emerge -u wants to update it. However ipw3945 doesn't actually work with it. It has a hard-coded dependency to 1.1.3-r1. So, when it comes time to ipw3945 to update, it downgrades ieee80211 to the version it needs. To avoid this issue emerge ieee80211 with --one-shot and/or manually remove it from the world database, and attempt to live with the fact that one of your programs is *not* the latest version (I'm getting counselling myself 

 

if you dont have any other drivers that depend ieee80211-1.2.15 then:

```
echo '=net-wireless/ieee80211-1.2.15' >> /etc/portage/package.mask
```

----------

## smadasam

Even after I have these lines my package.keywords....

```

>=net-wireless/ieee80211-1.1.11 ~x86

=net-wireless/ipw3945d-0.7.16 ~x86

net-wireless/ipw3945-firmware ~x86

net-wireless/ipw3945 ~x86
```

...I still can't emerge those packages.  What am I doing wrong?

----------

## Lloeki

rmh3093, 

I recently had some problem again with your ebuild. 

I emerged beyond3 sources (which is a 2.6.17) and emerging ipw3945 failed. two points to note:

- sed could not open '/usr/includenet/ieee80211/somefile.h'. it's not a typo, there was some slash lacking. I added slash to IEEE80211_INC in the kernel version BUILD_PARMS test case. that did not fix it, since the file does not exists. aren't those files placed there when you emerge ieee80211? it seems some test case for that is lacking here.

- I then effectively disabled the test-case and replaced it completely with the 2.6.18 case, effectively making BUILD_PARMS the same for 2.6.17 and 2.6.18. things worked, since the important stuff (api version) has a test case later.

I suppose the test case should then be:

```
if [ -d /usr/include/net/ieee80211 ]; then

      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include/"

   else

      BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_IGNORE_DUPLICATE=y"

   fi

```

further tests, notably of use flag should be added.

----------

## beatryder

I am too lazy to search this thread, but has anyone managed to get ipw3945 working with the mm-sources. I can't compile the ieee80211 modules because I get an access violation.

----------

## lex82

I have a little problem: If I use the stable ipw3945 in portage sometimes connection breaks. With the last version (ipw3945-1.1.0) everything works as it should... can I suggest making stable the new version?

I own a HP Compaq nx7400 (Centrino Core Duo 1.66GHz).

----------

## par4noia

I'm using 2.6.18 kernel and the ebuild provided by rmh3093 (thnks a lot for it!), but I'm having two problems...

The first one is kinda weird...I have ipw3945 on modules.autoload.d, but I can only get my card to work if the loading fails during boot time...If I don't get a "Failed to load ipw3945" the card doesn't work! I've tried to remove it from modules.autoload.d, but then I also don't have the card to work...Anyone knows why?

Secondly, I can't get ieee802.11 to be built-in the kernel, only as modules...I want to have it built-in because it's the only way to have WEP encryption support I think?

Any ideas?

----------

## VinzC

 *lex82 wrote:*   

> I have a little problem: If I use the stable ipw3945 in portage sometimes connection breaks. With the last version (ipw3945-1.1.0) everything works as it should... can I suggest making stable the new version?
> 
> I own a HP Compaq nx7400 (Centrino Core Duo 1.66GHz).

 

I presume you can notify the devs that "it works for me". I'm not sure they'll mark it stable on the results of a single try however. Anyway it's good to let them know as that's the kind of feedback they appreciate.

----------

## VinzC

 *par4noia wrote:*   

> Secondly, I can't get ieee802.11 to be built-in the kernel, only as modules...I want to have it built-in because it's the only way to have WEP encryption support I think?
> 
> Any ideas?

 

Do you mean [kernel] built-in vs portage module-only?

----------

## lex82

Well, the main problem is gone (falling connection) but audio and video streams last about 5 minutes or even less! Even X-Chat disconnect every 3-5 minutes...  :Sad: 

Any idea?

----------

## par4noia

 *VinzC wrote:*   

>  *par4noia wrote:*   Secondly, I can't get ieee802.11 to be built-in the kernel, only as modules...I want to have it built-in because it's the only way to have WEP encryption support I think?
> 
> Any ideas? 
> 
> Do you mean [kernel] built-in vs portage module-only?

 

No, I mean buil-in like [*] vs [M]...

----------

## par4noia

 *par4noia wrote:*   

>  *VinzC wrote:*    *par4noia wrote:*   Secondly, I can't get ieee802.11 to be built-in the kernel, only as modules...I want to have it built-in because it's the only way to have WEP encryption support I think?
> 
> Any ideas? 
> 
> Do you mean [kernel] built-in vs portage module-only? 
> ...

 

BTW, this is the error when I try to do something like: iwconfig eth1 essid "WLAN" enc open

```
immega ~ # iwconfig eth1 essid "WLAN" enc open

Error for wireless request "Set Encode" (8B2A) :

    SET failed on device eth1 ; Operation not supported.

```

----------

## VinzC

 *par4noia wrote:*   

>  *VinzC wrote:*    *par4noia wrote:*   Secondly, I can't get ieee802.11 to be built-in the kernel, only as modules...I want to have it built-in because it's the only way to have WEP encryption support I think?
> 
> Any ideas? 
> 
> Do you mean [kernel] built-in vs portage module-only? 
> ...

 

Ok. Then no, you don't need the driver to be built-in. WEP works even when ieee driver is a module as it does for me ever since I'm using it.

```
# iwconfig eth1 essid "WLAN" enc open

Error for wireless request "Set Encode" (8B2A) :

    SET failed on device eth1 ; Operation not supported.
```

Have you tried this?

```
iwconfig eth1 essid "WLAN"
```

----------

## beatryder

 *beatryder wrote:*   

> I am too lazy to search this thread, but has anyone managed to get ipw3945 working with the mm-sources. I can't compile the ieee80211 modules because I get an access violation.

 

Any word on this?

----------

## VinzC

 *beatryder wrote:*   

>  *beatryder wrote:*   I am too lazy to search this thread, but has anyone managed to get ipw3945 working with the mm-sources. I can't compile the ieee80211 modules because I get an access violation. 
> 
> Any word on this?

 

You're lazy  :Wink:  .

rmh3093 is still - I think - using mm-sources since the beginning of his thread...

----------

## par4noia

 *VinzC wrote:*   

> 
> 
> Have you tried this?
> 
> ```
> ...

 

Yea, it works that way...But will I get encryption? I'm trying to join the essid "WLAN" and use encryption without authentication (at least that's what the how-to for wireless on my University says)..

----------

## VinzC

 *par4noia wrote:*   

>  *VinzC wrote:*   
> 
> Have you tried this?
> 
> ```
> ...

 

If you want encryption iwconfig requires another argument for passing the WEP key to associate with an access point. I think it is "key". So the full syntax should be:

```
iwconfig eth1 essid "WLAN" key hex_key
```

 or

```
iwconfig eth1 essid "WLAN" key "s:key as a string"
```

I'm typing that from memory as I'm currently using wpa_supplicant instead.

----------

## madisonicus

 *VinzC wrote:*   

>  *par4noia wrote:*    *VinzC wrote:*   
> 
> Have you tried this?
> 
> ```
> ...

 

I had wackiness with encryption too until I started using wpa_supplicant.  The wpa_gui "scan" feature is great for set up.

----------

## gabriel_

hey guys,

need help with encryption modules for ipw3945. 

When I try this:

modprobe ieee80211_crypt_tkip ieee80211_crypt_ccmp

I get this:

FATAL: Error inserting ieee80211_crypt_tkip (/lib/modules/2.6.17-gentoo-r8/net/ieee80211/ieee80211_crypt_tkip.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Any idea how to solve this??

----------

## Lloeki

do two separate modprobes instead of one. the way you did it, modprobe takes  ieee80211_crypt_ccmp as a parameter of ieee80211_crypt_tkip

----------

## madisonicus

 *gabriel_ wrote:*   

> hey guys,
> 
> need help with encryption modules for ipw3945. 
> 
> When I try this:
> ...

 

I get that error when my /usr/src/linux points to the wrong sources for the kernel I'm using.  If it is pointing to the wrong ones, then fix it and re-emerge the modules.

-m

----------

## Lloeki

the error here is clearly due to the fact that you can't modprobe two modules at once. modprobe'ing has nothing to do with a bad /usr/src/linux symlink.

----------

## VinzC

 *Lloeki wrote:*   

> modprobe'ing has nothing to do with a bad /usr/src/linux symlink.

 

That's true. The error comes from something else (modprobe'ing two modules at once in this case); for instance there is no /usr/src on live CD's but still they can modprobe the required drivers. Directory /usr/src fate is for compilation only. Actual module files are posted in /lib/modules/<kernel version>.

 *madisonicus wrote:*   

> If it is pointing to the wrong ones, then fix it and re-emerge the modules.

 

The reason why it did work is that the ebuild gathered the current kernel version by looking at the symlink under /usr/src and then posted the compiled modules to /lib/modules/<kernel version>, which is the actual location for modules.

----------

## VinzC

 *gabriel_ wrote:*   

> ...
> 
> When I try this:
> 
> modprobe ieee80211_crypt_tkip ieee80211_crypt_ccmp
> ...

 

Try that:

```
for MODULE in ieee80211_crypt_tkip ieee80211_crypt_ccmp; do modprobe $MODULE; done
```

----------

## zidour

 *VinzC wrote:*   

>  *zidour wrote:*   
> 
> ```
> ~ $ emerge --info
> 
> ...

 

Well, VinzC, in my opinion running full testing branch is the only option to get every single piece of hardware in my computer running... My package.keywords file just grew to big... And as for the CFLAGS, these are copied almost exactly as presented at gentoo-wiki (http://gentoo-wiki.com/Safe_Cflags#Intel_Core_Solo.2FDuo_.28Yonah.29). Anyway, I don't mind if something breaks from time to time. However, if something breaks, I can usually find tons of posts dealing with the same issue and resolve it quickly... But not this time. That's why I felt so frustrated...

Anyway, the first two problems are not a big deal, I can live with that. The third one is what troubles me (brief summary: when starting the /etc/init.d/ipw3945d script, the ipw3945 process takes 100% of CPU and cannot be killed, the wifi does not work, of course). I don't know if it has anything to do with the packages from the "testing" branch or with the cflags I am using. But I know that it was working before so I tried several older ipw3945 drivers and packages. Did not help. So I tried an older kernel, and... it works again. So I will stick to the 2.6.17 kernel for now. Any kernel starting with 2.6.18 did not work for me. Anyone has the same problem?

----------

## VinzC

@zidour,

Well I also run "testing" packages and my keyword file is quite big too but at least system packages and most of the whole world is stable. You might be experiencing instability due to system packages being compiled from ~ARCH indeed. So my advice is still valid IMHO. There are too many threads dealing with that to ignore that kind of advice from many Gentoo developers.

You haven't run into trouble yet but things will turn bad for instance if just GCC (or bash or python) gets borked. And things like this are deemed to happen in the ~ARCH world.

----------

## ygor

Hi,

I have sucessfuly installed the ipw3945 drivers and the 80211_crypt_XXXX drivers on my notebook.

But there is a huge problem which I havent been able to solve yet...

When I modprobe the driver and start the daemon ipw394d at /etc/init.d, I get the following messages @ /var/log/messages:

```

Oct 28 21:04:23 zenary ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.0mpr

Oct 28 21:04:23 zenary ipw3945: Copyright(c) 2003-2006 Intel Corporation

Oct 28 21:04:23 zenary ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17

Oct 28 21:04:23 zenary PCI: Setting latency timer of device 0000:03:00.0 to 64

Oct 28 21:04:23 zenary ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

Oct 28 21:04:50 zenary ipw3945: Radio Frequency Kill Switch is On:

Oct 28 21:04:50 zenary Kill switch must be turned off for wireless networking to work.

```

As you can see it is something related to the wireless kill switch of the notebook... so, I pressed the push button of the wireless switch and it simply does nothing... no led, no nothing, just generate a invalid key code at dmesg....

The bluetooth button works Ok, but wireless dont...  :Sad: 

Ok, so Ive tryed to do the things manually at: /sys/bus/pci/drivers/ipw3945/0000:03:00.0/

Inside this directory there is a file called rf_kill which is responsible for modifying the wireless status to active....

when i get a cat rf_kill on the file, it returns me the value: 2, which by the researches that i did, signifyes that my wireless card is hardware locked....

So, what can I do???

Anybody with a Acer Aspire 5672WLMi Laptop did suceed with the wireless????

Here comes my lspci output:

```

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)

00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03)

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)

00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)

01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

04:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express (rev 21)

0a:09.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller

0a:09.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller

0a:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)

```

Thanks,

Yg

----------

## VinzC

Tried this https://forums.gentoo.org/viewtopic-p-3610154-highlight-ipw3945+rfkill.html#3610154 ?

----------

## zidour

And now for something completely different:

I was just reading an announcement for the OpenBSD 4.0 which also included the following statement:

 *Quote:*   

> 
> 
> New binary blob free wpi(4) driver for Intel PRO/Wireless 3945ABG IEEE 802.11a/b/g wireless.
> 
> 

 

this seemed very interesting so I kept reading further...

 *Quote:*   

> 
> 
> The driver needs at least version 1.13 of the following firmware file, which is loaded when an interface is brought up:
> 
>            /etc/firmware/wpi-ucode
> ...

 

At first I was not sure what exactly is the advantage over the Linux drivers, so I took a look at the ipw3945 packages in the portage. In Linux we have the ipw3945 driver (open source, right?), then the firmware (some kind of BLOB, but necessary due to FCC regulations) and the ipw3945d daemon (I thought it was open source, but it is not! Big surprise for me :) This is probably the main difference to wpi driver). 

Anyway, are you interested in porting this driver to Linux? This OpenBSD "we hate every blob" activity sounds very interesting and promising to me...

----------

## Lloeki

old news. read page 16 :p

FYI: ipw3945 is opensource but is merely a wrapper to ipw3945d blob, which is 95% of the 'real' driver. ipw3945-ucode is the firmware.

wpi is a black-box (rev-engineering technique not involving disassembly, thus compliant to the license) opensource implementation of ipw3945d, merged with an ipw3945 BSD implementation. thus it is a 100% opensource driver. unless instrumentizing the hardware, there's no chance to see an opensource firmware as per the current license, so that's the best we can get.

----------

## Wojtek_

Hi!

I have a problem with ipw3945 modules - it is loaded only during every second boot. I didn't have this problem with emission-sources but when I switched to gentoo-sources I can only use wireless after every second boot. I am using gentoo-sources-2.6.18 and have 80211 and ipw3945 from portage.

cheers

wojtek

----------

## VinzC

Have you tried recompiling udev?

----------

## Lloeki

Wojtek_, does it looks like this ?

----------

## VinzC

May I suggest you both used <udev-080. I have udev-079-r2 and I wouldn't upgrade since I'm more than quite satisfied with it.

----------

## Wojtek_

Ok, I'll try to switch to earlier version of udev (I am currently using 087). However, I find it really strange that emission-sources worked properly with the latest version of udev and when I want to use gentoo-sources I have to downgrade it...

----------

## beatryder

 *Wojtek_ wrote:*   

> Ok, I'll try to switch to earlier version of udev (I am currently using 087). However, I find it really strange that emission-sources worked properly with the latest version of udev and when I want to use gentoo-sources I have to downgrade it...

 

You may also want to try the masked version of the drivers now. They apparently fixed a fair bit.

----------

## Wojtek_

Downgrading udev din't help at all - still the same bug.

----------

## beatryder

Has anyone noticed that their card disconnects and reconnects when switching from X to a VT and then back to X?

----------

## VinzC

 *Wojtek_ wrote:*   

> Ok, I'll try to switch to earlier version of udev (I am currently using 087). However, I find it really strange that emission-sources worked properly with the latest version of udev and when I want to use gentoo-sources I have to downgrade it...

 

Consider the following: it works for me and maybe for others. Anyway it's worth the try, isn't it?  :Smile: 

----------

## VinzC

 *beatryder wrote:*   

> Has anyone noticed that their card disconnects and reconnects when switching from X to a VT and then back to X?

 

It doesn't seem to happen on my laptop. What are the symptoms/error messages?

----------

## beatryder

 *VinzC wrote:*   

>  *beatryder wrote:*   Has anyone noticed that their card disconnects and reconnects when switching from X to a VT and then back to X? 
> 
> It doesn't seem to happen on my laptop. What are the symptoms/error messages?

 

It doesn't give me any error's at all actually, it just goes down, and comes back up right away.

----------

## VinzC

 *beatryder wrote:*   

> It doesn't give me any error's at all actually, it just goes down, and comes back up right away.

 

What is the indication it goes down? Do you see the classical message about the geography? Or does the LED stop blinking and turn black (hence the association process takes place again)?

I could explain this due to the non 100% hardware nature of the card; like WinModems ipw3945 has an analog converter that is driven by the CPU (hence consumes much more CPU than other cards). So if the CPU goes too busy for some reason, the card can temporarily disconnect.

----------

## beatryder

 *VinzC wrote:*   

>  *beatryder wrote:*   It doesn't give me any error's at all actually, it just goes down, and comes back up right away. 
> 
> What is the indication it goes down? Do you see the classical message about the geography? Or does the LED stop blinking and turn black (hence the association process takes place again)?
> 
> I could explain this due to the non 100% hardware nature of the card; like WinModems ipw3945 has an analog converter that is driven by the CPU (hence consumes much more CPU than other cards). So if the CPU goes too busy for some reason, the card can temporarily disconnect.

 

That does make a bit of sense, but any how here is the log output:

 *tail /var/log/messages wrote:*   

> Nov  5 22:03:51 Osiris wpa_cli: interface eth1 DISCONNECTED
> 
> Nov  5 22:03:52 Osiris dhcpcd[9205]: terminating on signal 15
> 
> Nov  5 22:03:53 Osiris wpa_cli: interface eth1 CONNECTED
> ...

 

This is the exact same output I get when the card initializes.

This is the output when I switch the rf on and off:Nov  5 22:08:16 Osiris ipw3945: Radio Frequency Kill Switch is On:

 *Quote:*   

> Nov  5 22:08:16 Osiris Kill switch must be turned off for wireless networking to work.
> 
> Nov  5 22:08:16 Osiris atkbd.c: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
> 
> Nov  5 22:08:16 Osiris atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known.
> ...

 

----------

## Lloeki

 *Quote:*   

> I could explain this due to the non 100% hardware nature of the card; like WinModems ipw3945 has an analog converter that is driven by the CPU (hence consumes much more CPU than other cards). So if the CPU goes too busy for some reason, the card can temporarily disconnect.

 

I find that hard to believe, esp. since we download some microcode onto the board, there certainly must be some microcontroller/microcpu which performs that (and esp. that one which is highly time critical) operation onto the card. please give more details, I'm interested.

and although I agree the cpu is needed for (at least) things like wpa_supplicant, I have never seen my ipw3945 card disconnect on high cpu load (e.g 2*make -j3 on a dual core system, plus a good load of myself using the laptop). linux is just damn good at scheduling things.

----------

## VinzC

 *Quote:*   

> I could explain this due to the non 100% hardware nature of the card; like WinModems ipw3945 has an analog converter that is driven by the CPU (hence consumes much more CPU than other cards). So if the CPU goes too busy for some reason, the card can temporarily disconnect.

 

 *Lloeki wrote:*   

> I find that hard to believe, esp. since we download some microcode onto the board, there certainly must be some microcontroller/microcpu which performs that (and esp. that one which is highly time critical) operation onto the card. please give more details, I'm interested.

 

It's just an article I happened to find somewhere on the internet. If I find it back I'll post the URL here. It compared the ipw3945 chip against WinModems - or at least similarities in both technologies.

----------

## VinzC

I found the article back. It's in fact a note that was posted on LinuxFR (DLFP, Da Linux French Page), initially about the Trusted Computing Platform Alliance (TCPA/TPM). As the post is pretty long I'll quote just the mentionned text in French and will make a translation as accurately as possible.

 *http://linuxfr.org/2006/08/06/21170.html wrote:*   

> PS:
> 
> Je finirai par un petit troll relatif à certaines contre-vérités que j'ai lues récemment ici à propos d'Intel (qui ne doit plus paraître si blanc que ça à propos du libre après cette dépêche) : la plupart des portables que je cite dans ma liste, en plus de contenir une puce TPM, sont équipés d'un puce wifi Intel PRO/Wireless 3945ABG, la carte wifi utilisée sur la plateforme Centrino Duo. Même si Intel est assez généreux avec le libre dans les précédents pilotes qu'il a fournis (ipw2100/2200 : pilote libre + firmware propriétaire), le nouveau pilote nécessite, en plus du firmware propriétaire, un démon propriétaire, qui tournera donc bien sur votre machine, et pas sur la carte wifi ! (cf. http://ipw3945.sourceforge.net/#requirements ) En plus, la nécessité d'utiliser la pile 802.11 software montre que c'est une puce "SoftMAC", qui n'est donc qu'un vulgaire convertisseur analogique/numérique obligeant le processeur central à faire tout le boulot, comme pour les WinModems. Tout ça pour économiser quelques dollars de plus (après avoir économisé en enlevant la flash de ses cartes wifi, obligeant l'utilisateur à charger le firmware non-libre depuis son OS, au boot).

 

Here's the text, translated.

 *Quote:*   

> I'll end with a little troll around some counter-truths I recently read here about Intel (who must not look that clear anymore with Open Source after this post): most laptops in my  list - besides a TPM chip - are also equipped with an Intel PRO/Wireless 3945ABG WiFi chip, the one used on Intel Centrino Duo platform. Even if Intel is pretty generous towards Open Source with previous drivers (i.e. ipw2100/2200 : free driver + proprietary firmware) the new driver requires a proprietary daemon (in spite of the proprietary firmware), which will indeed run on your machine, not on the card (cf. http://ipw3945.sourceforge.net/#requirements ). Besides the need for a software 802.11 stack shows it's a "SoftMAC" chip, which is nothing but an ordinary analog/digital converter that forces the CPU to do all the job - more or less like WinModems. All that fuss to just spare a couple of dollars more (after sparing some by removing the flash chip from WiFi cards and requiring the user to load its non-free firmware [from the OS] at boot).

 

----------

## Lloeki

Interesting analysis, but this seems pretty much speculation. I won't deny that there is certainly some part of truth but it seems a bit harsh. there are a few things that seem mixed up in a whole ranting bag:

- persistent vs volatile storage: well that's just a matter of microseconds once in a boot to upload some few KB. would he prefer busting the card on a bad flash upgrade? to me, having volatile storage for the microcode is really safer.

- daemon role: the guy who build bsd's wpi was saying that all in all the daemon's role was fairly minimal. that was part of his success in blackboxing it.

- generic hardware design: pulling things from hardware to 'software' is not necessarily a bad thing. note that I put software in between quotes, as I understand software not necessarily run on the cpu, but on some microcontroller. absically every usb device does just that already. Generally speaking this allows for hardware to be more generic, and have some greater  adaptation ability. In fact I find it rather good for open-source, as we can see things like the 802.11 generic stack or even opensource firmwares to exist. If it were hardware all that rather 'high level' stuff would be set in stone, whereas the way it is now, only the lowest OSI network layer(s) is(are) 'hardware-coded', allowing for open compliance to future standards.

- running things on the cpu: well, in the end, what's bad with that? we have plenty of bogomips already :p after all, all that winmodems were needing is a generic (alsa) part and a specific driver. the generic part is just some usual implementation of some algorithm (mostly an audio codec), and the driver is, well, a driver, which cost to build is the same even if it was 100% hardware. In the end, I prefer having some trusty open-source software than some flakey hardware.

all that argumentation made in the article, and the fact that it's compared to softmodems, makes me just thing that it's not really the design that's in cause, but the driver's blobiness, and it just takes the softmodems design parallel and their bad reputation as an excuse to shout it loud.

all in all, my ipw3945 now works well (issues I had were not related to it but certainly to udev), and I just wish the wpi driver to be ported soon (had I the knowledge, I'd do it myself)

----------

## VinzC

 *Lloeki wrote:*   

> running things on the cpu: well, in the end, what's bad with that? we have plenty of bogomips already :p after all, all that winmodems were needing is a generic (alsa) part and a specific driver

 

Just to argue a little on that, I don't quite agree with you. Similarily developer lambda could also say why care since we have plenty of RAM for our program so let's not care about sparing bytes here and there. Having plenty of resources doesn't mean things don't need to be conceived in a way that each hardware part does the job it has been designed for. I mean a CPU, unlike microcontrollers, is for computing and a network card is for controlling and taking care of the network trafic.

Modern graphics card, as an example, now all take care of graphics acceleration and do the whole of graphics tasks. Because the CPU was too much involved in graphics processes different types of activities have now been separated, been dedicated to distinct processors. Hence IMHO the CPU should not be involved in networking operations belonging to the physical layer. Neither should it be involved in performing a modem's job (I never liked WinModems much either).

I'm more for the idea "each thing has its place and there's a place for everything". Bringing hardware tasks to the software is (was) typically meant for microcontrollers. Note I wonder if it's still true given the lower cost of dedicated VLSI nowadays.

----------

## Lloeki

 *Quote:*   

> I'm more for the idea "each thing has its place and there's a place for everything".

 

I too agree with this philosophy, but things are not strictly black or white. going farther in your thinking, then the network card should have its own hardware firewall... while this is interesting design (and has been done before, e.g  in some ibm laptops), this leads to having more drivers and less control.

oh, and when I say running things on the cpu, I don't mean wasting its resource with badly designed software  :Wink: 

whatever, the debate of microelectronics vs software is as old as computers themselves, and still raging today in hardware design teams themselves (and it was in the engineer school I learnt). but to me, the good solution is a balance between both, balance biased by the original problem (constraints in a personal computer are not the same than in a router, a server, a car or a plane).

----------

## VinzC

 *Quote:*   

> I'm more for the idea "each thing has its place and there's a place for everything".

 

 *Lloeki wrote:*   

> I too agree with this philosophy, but things are not strictly black or white. going farther in your thinking, then the network card should have its own hardware firewall...

 

Certainly not. The NIC is at the hardware level. (OSI level 1?) The firewall is some levels higher, hence should not be part of the card, mostly for dependency reasons. (I.e. one card with a firewall, another without, change the card to change the firewall...)

But I see and understand your point hereafter.

EDIT: not ISO but OSI...

----------

## Lloeki

 *Quote:*   

> The NIC is at the hardware level. (ISO level 1?)

 

some precisions:

it's not ISO (like standards) but OSI, which is a reference model, not a standard.

simplified, this gives:

layer 1 is phy. that is, modulation and such. things you could see with an oscilloscope  :Smile: 

layer 2 is data link (e.g 802.11 stack, ethernet). this is generally what MAC refers to (in fact this layer is usually split in MAC and LLC layers), thus the @ name for ethernet cards is 'MAC address'.

layers 3/4/5+ is network (eg ip)/transport (eg tcp/udp)/application. 

we were debating how to map hardware/software boundaries on that model. 1 is necessarily implemented in the card, either pure hardware or microcontrolled. 3+ usually takes place on the cpu. so we were asking if layer 2 should be on the card. looking at kernel drivers will give some clues at which NICs have it implemented as hardware and which ones have it as software.

----------

## VinzC

 *Lloeki wrote:*   

>  *Quote:*   The NIC is at the hardware level. (ISO level 1?) 
> 
> some precisions:
> 
> it's not ISO (like standards) but OSI...

 

Sorry, my mistake... I have been too much involved in ISO tasks - being audited recently - at work these days  :Smile:  . Of course it's OSI. Please bear with me: I've studied electronics (as an engineer) - ok, more than 10 years ago but it hasn't changed that much since then, has it?  :Wink: 

EDIT: Ok, let's close it. I meant "my philosophy" was certainly not intending to put a firewall into a network card. First for the reasons I explained (i.e. different OSI levels plus the convenience brought by having a software firewall) and next for those you explained. I was just trying to say you were wrong interpreting that way what you called "my philosophy".

----------

## VinzC

@beatryder:

I don't experience disconnects like you do but in a different situation: when the wireless card is under heavy load. What I find strange is that I was test-saving a partition using partimage through the network and the card disconnected immediately as I clicked on a hyperlink in firefox. I did that twice to be sure but that was it.

I saw the WiFi led turn off then blink again like when it's searching for a wireless access point to associate with. Actually it was. And only when I left partimage finish its job and did not use the network for something else on my laptop the link was stable.

I also sometimes experience disconnects when I load MP3 files (e.g. using Kaffeine) from a remote Samba share on the same network. Go figure...

----------

## Lloeki

 *Quote:*   

> Go figure...

 

which ieee80211 are you using? there is a bug that affects (at least) wpa and wep connections. dmesg gives some evidence about it (grep it for MIC and/or TKIP). I made some post about it and its solution earlier in this thread on another.   IIRC ieee80211-1.1.13 and below are affected (if you use the ebuild). if you use the kernel one, kernels <=2.6.18 are affected for sure (dunno upper).

EDIT: it's on page 16

EDIT: precisely, >=ieee80211-1.2.15 has the bug fixed

----------

## beatryder

 *Lloeki wrote:*   

>  *Quote:*   Go figure... 
> 
> which ieee80211 are you using? there is a bug that affects (at least) wpa and wep connections. dmesg gives some evidence about it (grep it for MIC and/or TKIP). I made some post about it and its solution earlier in this thread on another.   IIRC ieee80211-1.1.13 and below are affected (if you use the ebuild). if you use the kernel one, kernels <=2.6.18 are affected for sure (dunno upper).
> 
> EDIT: it's on page 16
> ...

 

I am aware of the bug, but I was not getting an error related to those things. I have since updated to the latest drivers and ieee stack, and all appears well now. Thanks for your help guys!

----------

## VinzC

 *Lloeki wrote:*   

> which ieee80211 are you using? there is a bug that affects (at least) wpa and wep connections. dmesg gives some evidence about it (grep it for MIC and/or TKIP). I made some post about it and its solution earlier in this thread on another.   IIRC ieee80211-1.1.13 and below are affected (if you use the ebuild). if you use the kernel one, kernels <=2.6.18 are affected for sure (dunno upper).
> 
> EDIT: it's on page 16
> 
> EDIT: precisely, >=ieee80211-1.2.15 has the bug fixed

 

Right, I forgot about your post on that issue. At that time switching to 2.6.17 seemed to fix it but I recon it still occurs. I'm still using the latest 2.6.17* kernel series, currently 2.6.17-gentoo-r8 and its ieee80211 stack, with my version of the modified ipw3945 ebuild. I'll apply the patch you mentionned. Thanks for reminding it  :Smile:  .

----------

## koneo

Hello everybody,

although I just registered, I found this forum very helpful for all my gentoo-related troubles for the last years.

But this time, the problem couldn't be solved by myself even if reading through the oddest threads - if I missed the right one please let me know.

I installed a 2006.1 stage 3/1 Gentoo on a IBM/Lenovo x60s following the farmezonen-guide.

But the command:

```
rc-update add ipw3945d default
```

is answered by:

 *Quote:*   

> * rc-update: 'etc/init.d/ipw3945d' not found; aborting

 

After some googling, I found a detailed ipw3945-related entry in the Gentoo-wiki

But the command:

```
modprobe ipw3945
```

is answered by:

 *Quote:*   

> FATAL: Module ipw3945 not found.
> 
> ERROR: opening /sys/bus/pci/drivers/ipw3945: No such file or directory (2)
> 
> ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection
> ...

 

Since this is the second "Not found"-message, I decided to look after it:

```
modules-update
```

-> no message recieved.

```
lsmod | grep ipw3945
```

-> no entry, just as I thought.

```
dmesg | grep ipw3945
```

-> no entry, neither.

```
emerge -va net-wireless/ipw3945
```

-> asks me to *R*-emerge the package, which tells me, that it is already emerged.

```
ls /sbin/ipw*
```

-> just ipw3945d can be found.

I googled some more and found no good clue. To be honest, I have no clue how to "load" a module or how to get a better system-made error-description.

If you have a hint about all that, please let me know.

----------

## Lloeki

modules are placed in /lib/modules/ subdirs, do a 'find /lib/modules | grep ipw' and it will tell you if/where the module is installed

as you'll notice from /lib/modules content, modules are built (ate least) once for each kernel, thus if you changed or upgraded kernel you have to remerge   module-related ebuilds. if you have lots of them, there is a tool to help you in that case: module-rebuild (it's in portage, so just 'emerge module-rebuild' and start 'module-rebuild' for some help).

concerning the rc-script, maybe you are using some version which doesn't have it (it is only present in later versions), so the step is not needed.

----------

## yinrunning

I have posted another thread about this > no satisfaction.  Sorry to muck up the forumspace.  But with so many people reporting success using these packages, I've gotta believe that if I just keeping banging my head against it I'll eventually find the problem.

My situation is just about exactly the same as koneo's.  The message that I've come to loath is:

```

ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection 

```

I've tried up- and down-grading udev, ieee stack, the ipw* packages, all with no success.  I think I've ready just about every damn page of this thread at least twice.  I am of the belief that udev is the culprit, but don't know where to go from there.  It seems to be handling everything else just fine.  Why fail on this one piece of hardware?

I really really want for wireless to work on this box.  Right now I'm stuck with Windows anywhere I don't have a hard-line connection, and that grinds my gears but good.   :Smile: 

Any advice is much appreciated.

----------

## VinzC

 *yinrunning wrote:*   

> My situation is just about exactly the same as koneo's.  The message that I've come to loath is:
> 
> ```
> ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection
> ```
> ...

 

Do you have just that message or - like koneo - do you also get the same error messages when modprobing ipw3935 (especially the one saying FATAL: Module ipw3945 not found? Just in case, post the results of lspci.

----------

## ats2

Well, could somebody sum it all up because I'm quite lost here: most of the time I get a "network device doesn't exist" thhat ifconfig eth1 can't solve , or if I can bring it up with ifconfig I get no association with iwconfig. So I'd like to know :

- which drivers are actually working with which kernel options (for WPA) ?

- what do you set in rc-update default ? ipw3945d ? net.eth1 ?

- How do you get wpa_supplicant to work without those IOCTL errors ?

BTW I'm using a d602 laptop.

Thanks in advance for any help  :Smile: 

PS : my former ipw2100 was working flawlessly, so I just replace the wext driver by ipw in wpa_supplicant.conf. Is this right ?

----------

## rmh3093

 *koneo wrote:*   

> Hello everybody,
> 
> although I just registered, I found this forum very helpful for all my gentoo-related troubles for the last years.
> 
> But this time, the problem couldn't be solved by myself even if reading through the oddest threads - if I missed the right one please let me know.
> ...

 

you have to emerge ipw3945 and ipw3945d, you must have messed up your portage directory or something.... emrege --sync and try emerge ipw3945 again

----------

## Lloeki

 *Quote:*   

> 
> 
> - which drivers are actually working with which kernel options (for WPA) ?
> 
> 

 

I use:

net-wireless/ipw3945d-1.7.22-r3

net-wireless/ipw3945-1.1.0-r2  USE="ieee80211_kernel"

gentoo-sources-2.6.18-r1

net-wireless/wpa_supplicant-0.5.4

sys-apps/baselayout-1.12.6

sys-fs/udev-098

 *Quote:*   

> 
> 
> - what do you set in rc-update default ? ipw3945d ? net.eth1 ? 

 

as soon as I start /etc/init.d/ipw3945d, net.wlan0 (I renamed ifaces with udev) starts automagically (whcih in turn starts wpa_supplicant, provided you set things up correctly in /etc/conf.d/net). IIRC this useful behavior is controlled with RC_COLDPLUG/RC_HOTPLUG of recent baselayout /etc/conf.d/rc. therefore I reckon you should only put ipw3945d to start up.

 *Quote:*   

> PS : my former ipw2100 was working flawlessly, so I just replace the wext driver by ipw in wpa_supplicant.conf. Is this right ?

 

you should use wext with a ipw3945, ipw is for old ipw2200 drivers

 *Quote:*   

> How do you get wpa_supplicant to work without those IOCTL errors ? 

 that should be taken care of by the above

----------

## Bluespear

Hello,

I haven't looked on the whole topic, but I haven't found answers in the forum.

Is it possible to have ipw3945 device working under x86_64 (Core 2 Duo) ?

Do I need to run ndiswrapper ?

Thanks  :Wink: 

----------

## VinzC

 *Bluespear wrote:*   

> Hello,
> 
> I haven't looked on the whole topic, but I haven't found answers in the forum.
> 
> Is it possible to have ipw3945 device working under x86_64 (Core 2 Duo) ?
> ...

 

Searching the forum with ipw3945 amd64 gives the following results:

https://forums.gentoo.org/viewtopic-p-3650823-highlight-ipw3945+amd64.html#3650823

https://forums.gentoo.org/viewtopic-p-3593170-highlight-ipw3945+amd64.html#3593170

https://forums.gentoo.org/viewtopic-p-3586372-highlight-ipw3945+amd64.html#3586372

https://forums.gentoo.org/viewtopic-p-3586301-highlight-ipw3945+amd64.html#3586301

https://forums.gentoo.org/viewtopic-p-3586139-highlight-ipw3945+amd64.html#3586139

Searching the forum with ipw3945 x86_64 also gives these ones:

https://forums.gentoo.org/viewtopic-p-3653393-highlight-ipw3945+x8664.html#3653393

https://forums.gentoo.org/viewtopic-p-3650823-highlight-ipw3945+x8664.html#3650823

Sagi (in this thread) has succeeded in building ipw3945 for Core2 duo by using the AMD64 branch. Take a look over there and tell us if it worked for you.

----------

## edit_21

Evening all!

I am also suffering under amd64 running on a core 2 duo.

I have tried everything that has been posted up to now but still cant raise the wifi.

Have even tried not using ipw3945d as many people have mentioned which helps and gives me this line now in dmesg:

```
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

ADDRCONF(NETDEV_UP): eth1: link is not ready
```

The usual /etc/init.d/net.eth1 restart fails to restart it. Any idea's   :Rolling Eyes: 

Thanks

Edit_21

Too many machines, too little time.

----------

## VinzC

ipw1945d shouldn't be bypassed because it is the actual driver code.

----------

## edit_21

VinzC Thanks

Still getting ADDRCONF(NETDEV_UP): eth1: link is not ready , Can anyone shed some light on this for me.

Thanks

Edit_21

Too many machines, too little time.

----------

## zaai

My Inspiron 9400 also suffers the kernel panic on shutdown, using wpa_supplicant and baselayout-1.12.6. That bug report is closed a bit prematurely. Adding RC_NEED="ipw3945d" to /etc/conf.d/net.eth1 has no effect.

----------

## VinzC

 *edit_21 wrote:*   

> VinzC Thanks
> 
> Still getting ADDRCONF(NETDEV_UP): eth1: link is not ready , Can anyone shed some light on this for me.
> 
> Thanks

 

You could try Ubuntu edgy install/live CD. I tried it on my laptop and ipw3945 worked quite normally - but it's a x86, I recon. However I guess it's the same with the AMD64 branch so you might want to try it out and check what's going on and what the differences are. Just copy and use your wpa_supplicant.conf.

----------

## edit_21

Yeah I have tryed Ubuntu and it worked right out of the box, suffered with loosng signal a few times but worked more than i have been able to do in gentoo.

Im just using ieee3945_crypt_wep atm not supplicant but will try that later on.

Thanks 

Edit_21 

Too many machines, too little time.

----------

## Dumble

 *zaai wrote:*   

> My Inspiron 9400 also suffers the kernel panic on shutdown, using wpa_supplicant and baselayout-1.12.6. That bug report is closed a bit prematurely. Adding RC_NEED="ipw3945d" to /etc/conf.d/net.eth1 has no effect.

 

I put those lines in my /etc/conf.d/net :

```
preup(){

        if test "X${IFACE}" = "Xeth1"; then

                modprobe ipw3945

                sleep 1

                /etc/init.d/ipw3945d start

                einfo "Waiting while loading ipw3945d daemon..."

                sleep 5

        fi

}

postdown(){

        if test "X${IFACE}" = "Xeth1"; then

                /etc/init.d/ipw3945d stop

                modprobe -r ipw3945

        fi

}

```

It works perfectly

----------

## VinzC

Hi again.

I'm pleased  :Twisted Evil:  to announce my laptop now hangs when it comes to loading ipw3945 module with kernel 2.6.17-gentoo-r8, which *never* happened before. I've been trying to solve another problem by giving a try to new udev-103. As it brought even more problems and didn't fix anything I switched back to udev-079-r2.

But now I'm stuck and my PC always freezes after coldplug loads ipw3945. I have absolutely no idea why it hangs now nor what makes it hang now and never before... Anyone got a hint as to where to look first?

----------

## Dumble

It seems the driver doesn't work with 2.6.19 kernel. Am I wrong ?

----------

## edit_21

Im also suffering locks after updating the latest ieee80211. Now on boot, ipw3945 is not being used according to lsmod, even if i modprobe it again after rmmod, it just sits there. if i try and /etc/init.d/ipw3945d start (without the ipw3945 module showing in lsmod) it also sits there used by nothing else. If i start it with the ipw3945 in lsmod it locks the box up. It didnt do this before i updated ieee80211 and always showed that ipw3945 was being used.

Im using:

udev-087-r1

ieee80211-1.2.15 (just updated, not tested yet)

ipw3945-1.1.2

ipw3945d-1.7.22-r3

edit_21

----------

## rmh3093

 *edit_21 wrote:*   

> Im also suffering locks after updating the latest ieee80211. Now on boot, ipw3945 is not being used according to lsmod, even if i modprobe it again after rmmod, it just sits there. if i try and /etc/init.d/ipw3945d start (without the ipw3945 module showing in lsmod) it also sits there used by nothing else. If i start it with the ipw3945 in lsmod it locks the box up. It didnt do this before i updated ieee80211 and always showed that ipw3945 was being used.
> 
> Im using:
> 
> udev-087-r1
> ...

 

don't worry, be happy, use in-kernel ieee80211 and in-kernel ipw3945

http://www.rit.edu/~rmh3093/ipw3945-1.1.2_for_2.6.17.patch (for <=2.6.17 kernels)

http://www.rit.edu/~rmh3093/ipw3945-1.1.2_for_2.6.18.patch (for 2.6.18 kernels)

----------

## zaai

 *Dumble wrote:*   

> 
> 
> I put those lines in my /etc/conf.d/net :
> 
> ...
> ...

 

Thanks dumble, that worked!. I had to make 2 changes to get it to work:

1. Instead of using postdown, I had to use the function predown().

2. Had to put a sleep between stopping ipw3945d and removing the module

My /etc/conf.d/net script now looks like:

```
preup(){

        if test "X${IFACE}" = "Xeth1"; then

                modprobe ipw3945

                /etc/init.d/ipw3945d start

                einfo "Waiting while loading ipw3945d daemon..."

        fi

}

predown(){

        if test "X${IFACE}" = "Xeth1"; then

                /etc/init.d/ipw3945d stop

                sleep 1

                modprobe -r ipw3945

        fi

}

```

----------

## zaai

I've read that ieee80211-1.2.15 is not stable. I've had lockups too that were fixed by switching back to ieee80211-1.1.13-r1.

This didn't immediately work until I deleted all modules and reinstalled them. This is a bit of a pain because all packages that update kernel modules have to be rebuild.  'module-rebuild' is your friend.

----------

## edit_21

Ok after the updates im back stable again. im still getting the eth1: link not ready line in dmesg but if i do a iwlist scanninig soon as i have modprobed i can recieve a list of access points, i can do this for about 20 seconds untill it just returnes me the eth1: no scan results. It has been sugested that this may be an apci issue locking down the wifi card. Any idea's.

rmh3093 did you patch your kernel, if so what was the results.

Edit_21

core 2 duo amd64

----------

## rmh3093

yeah i have tested it on both 2.6.17 and 2.6.18 and they both work....

i think i have a 2.6.19 patch also

http://www.rit.edu/~rmh3093/ipw3945-1.1.2_for_2.6.19.patch

----------

## VinzC

Update

rmh3093, I did use your ipw3945 patch for kernel 2.6.18 and the drivers compiles without errors. Thank you very much for the work.

I'm still having the same issue, both with Ubuntu and Gentoo: wpa_supplicant doesn't seem to connect to any network, wether using WEP or WPA. First it doesn't associate at all with WPA networks. It also absolutely wants to connect to WEP-encrypted networks even if I set the preference to WPA. Finally even if it associates with WEP networks the interface never receives its IP address.

I've tried the same configuration with Ubuntu. The same configuration once worked (before I had all my problems) but now it doesn't and I have absolutely no idea where to look at. At best I get the driver search forever...

The wired ethernet adapter still works great however  :Twisted Evil:  . And, oh, yes: under Windows everything works normally, of course (to put the lid on it). At the very least the WiFi card isn't out of order.

----------

## edit_21

I also patched my kernel last night, Thanks rmh3093 but alas im also getting the same issues I had before, I will be looking deeply into acpi to see if thats powering down stuff it shouldnt be.

Im most likely also going to update to 2.6.19 today and remove the kernel patch and try installing ipw3945 etc with ~x86 keywords. Will report back later

Oh and yes it all works fine over in MS   :Rolling Eyes: 

Edit_21

Core 2 Duo Acer 5633

----------

## rmh3093

 *VinzC wrote:*   

> Update
> 
> rmh3093, I did use your ipw3945 patch for kernel 2.6.18 and the drivers compiles without errors. Thank you very much for the work.
> 
> I'm still having the same issue, both with Ubuntu and Gentoo: wpa_supplicant doesn't seem to connect to any network, wether using WEP or WPA. First it doesn't associate at all with WPA networks. It also absolutely wants to connect to WEP-encrypted networks even if I set the preference to WPA. Finally even if it associates with WEP networks the interface never receives its IP address.
> ...

 

is ieee80211 built into the kernel or are they modules.... I can ONLY connect to encrypted access points when ieee80211 is completely in the kernel

----------

## logics

 *rmh3093 wrote:*   

> don't worry, be happy, use in-kernel ieee80211 and in-kernel ipw3945
> 
> http://www.rit.edu/~rmh3093/ipw3945-1.1.2_for_2.6.17.patch (for <=2.6.17 kernels)
> 
> http://www.rit.edu/~rmh3093/ipw3945-1.1.2_for_2.6.18.patch (for 2.6.18 kernels)

 

For those interested (not sure if this thread covered it already; searching for 'patch_kernel' didn't uncover any hits), from within the ipw3945 tarball directory (if you pulled from http://ipw3945.sf.net) you can also run:

```
make patch_kernel
```

If you're experiencing build problems with the latest kernel versions, you also might want to use the GIT tree.  If you don't have git and cogito already, emerge cogito:

```
emerge -av cogito
```

Once you have cogito, you can perform the following:

```
cg-clone rsync://bughost.org/repos/ipw3945.git/

cd ipw3945

make patch_kernel
```

You can then configure and build your kernel to include the ipw3945 module directly.

James

----------

## VinzC

 *rmh3093 wrote:*   

> is ieee80211 built into the kernel or are they modules.... I can ONLY connect to encrypted access points when ieee80211 is completely in the kernel

 

It's in the kernel. but in fact I've found what was wrong: I have probably forgotten to select IEEE_CRYPT_TKIP and IEEE_CRYPT_WEP too. It's in the same page in Networking:

```
<M>   Generic IEEE 802.11 Networking Stack

[ ]     Enable full debugging output (NEW)

<M>     IEEE 802.11 WEP encryption (802.1x)

<M>     IEEE 802.11i CCMP support

<M>     IEEE 802.11i TKIP encryption
```

Now I've added these options and WPA connects succesfully to WEP/WPA access points. I think I didn't check these options once a long ago but the crypt modules got carried along - maybe because package ieee80211 drops its own ones there and they don't get removed when unmerging the package.

Since I've just had to whipe out my whole kernel source tree to fix the freeze I was experiencing I discovered only now the required crypt options hadn't been enabled for quite a long time. And since I carry my kernel config from kernel to kernel... You can imagine.

----------

## rmh3093

 *logics wrote:*   

> 
> 
> ```
> make patch_kernel
> ```
> ...

 

that command dosent work completely because leaves a bunch of extraneous code in ipw3945.c relating to IEEE80211_API_VERSION which you need to take out for it to compile, which is why I made the patches

----------

## zalun

I had the same problem - I updated udev to 103 and now I have no wireless.

The patched kernel module compiles perfectly, but unfortunately I can't put the system to work.  Even if I compile it into kernel.

dmesg says

```

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, git-1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.0.5mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ACPI: PCI Interrupt 0000:0b:00.0[A] -> GSI 16 (level, low) -> IRQ 16

PCI: Setting latency timer of device 0000:0b:00.0 to 64

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

```

but iwlist scan:

```

iwlist scan

lo        Interface doesn't support scanning.

eth0      Interface doesn't support scanning.

```

in log one can find:

```

Dec  2 20:23:46 localhost ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.2r

Dec  2 20:23:46 localhost ipw3945: Copyright(c) 2003-2006 Intel Corporation

Dec  2 20:23:46 localhost ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

```

help

----------

## VinzC

With udev-103 the daemon is not run automatically upon insertion of module ipw3945. Hence your best bet is to downgrade udev. As usual (and ever since I've upgraded udev, just to see) I've stuck to udev-079. That one version has never failed and is the most stable to me. Each time I use another version of udev problems arise.

----------

## zalun

Dio you have he knowledge then how o easy downgrade udev (as it shows a lot of errors after downgrade) ....

Piotr

----------

## raid517

Hi, I can't seem to get the ipw3945d daemon to start up on boot. I followed the instructions as posted on this thread (and others)

To get things going first I did:

```
ifconfig eth1 192.168.1.102 broadcast 192.168.1.255 netmask 255.255.255.0 up
```

```
iwconfig eth1 key s:mywepkey essid myessid
```

then 

```
ifconfig eth1 up
```

then:

```
iwconfig eth1 enc restricted
```

```
iwconfig

lo        no wireless extensions.

eth0      no wireless extensions.

eth1      unassociated  ESSID:"MYNET"

          Mode:Managed  Frequency=2.462 GHz  Access Point: 00:14:C1:19:0F:0C

          Bit Rate:0 kb/s   Tx-Power:16 dBm

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:6562-6XXE-656C-6XX6-656E-7XX6-37   Security mode:open

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:9   Missed beacon:0

```

So I decided to manually repeat the process I did before in my first forum post:

First I did: 

```
iwconfig
```

Then I did 

```
ifconfig eth1 192.168.1.102 broadcast 192.168.1.255 netmask 255.255.255.0 up 
```

```
iwconfig eth1 key s:mywepkey essid myessid
```

then 

```
ifconfig eth1 up
```

then:

```
iwconfig eth1 enc restricted
```

To be clear what appears to be happening to some extent is that the ipw3945d - regulatory daemon is not being automatically started on boot. (although this still doesn't explain why most of my settings aren't being retained on reboot).

I wasn't sure to be honest what typing ipw3945d on the CLI actually did, I just picked this up from reading around in various forum posts - but apparently it's function is to start the ipw3945d daemon.

So the first thing I need to do is to get the ipw3945d to start reliably when my computer starts. Any tips on how I might do this? I tried ading it to the default run level and this is what happened:

```
rc-update add ipw3945d default

 * ipw3945d already installed in runlevel 'default'; skipping
```

But as I said this appears to be insufficient to start it reliably.

If the ipw3945d daemon was running and I tried to start it from the command line, this is the message I should get:

```
ipw3945d

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.22

2006-12-03 01:07:05: ERROR: ipw3945d already running.  If ipw3945d is not running then you

need to remove '/var/run/ipw3945d.pid' and try again.

localhost jebus197 #
```

But as I said typing it manually is what actually appears to start it - and the command itself executes without complaint.  

I would really like to find a way to get the ipw3945d daemon to start reliably after each reboot.

Also if I could find a way to ensure my settings were retained after a reboot (WEP key ESSID, IP address, default gateway and so on, this would be a great help. My wireless does work - but I would simply like to find a way to not have to maually start the daemon and to not have to enter all my details again after each reboot.

If anyone can offer any assistance in this regard it would be greatly appreciated.

----------

## Lloeki

FWIW, you should not start 'ipw3945d', but '/etc/init.d/ipw3945d' with arguments start/stop/restart.

----------

## raid517

OK, but how do I get it to start up automatically on boot?

----------

## madisonicus

 *raid517 wrote:*   

> OK, but how do I get it to start up automatically on boot?

 Did you try... 

```
# rc-update add ipw3945d default
```

----------

## raid517

Yeah... like I said it doesn't work. I still have to start it from the command line after every reboot.

----------

## VinzC

 *zalun wrote:*   

> Dio you have he knowledge then how o easy downgrade udev (as it shows a lot of errors after downgrade)

 

Just emerge =udev-nnn (with nnn being the version you want) and run dispatch-conf. It worked for me when I downgraded from 103 to 079-r2.

----------

## VinzC

 *raid517 wrote:*   

> Yeah... like I said it doesn't work. I still have to start it from the command line after every reboot.

 

First make sure (when you boot your computer) ipw3945d is not running:

```
ps -C ipw3945d u
```

or

```
pidof ipw3945d
```

If the latter commands give you a process ID then the daemon is already running.

If the daemon is running you have another problem, which doesn't relate to the daemon. It depends on what's in /etc/conf.d/net and possibly /etc/conf.d/wireless. (Note the latter is deprecated.)

As a check here's my config:

gentoo-sources-2.18-r3 patched with rmh3093 ipw3945

kernel ieee80211/wep/tkip stack

ipw3945-ucode-1.13

ipw3945d-1.7.18

udev-079-r2

baselayout-1.12.6

coldplug-20040920-r1

hotplug-20040923-r2

hotplug-base-20040401

netplug-1.2.9-r3

ipw3945d should be running automatically upon insertion of ipw3945 thanks to this file:

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /sbin/ipw3945d --quiet

remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945
```

----------

## VinzC

Hi again. Did anyone try bridging both ethernet adapters? I did try but I must have done something wrong. My main concern is about how long it takes for the bridge to establish - I did a successful bridging on a server and I noticed it takes quite a long time for the bridge to start.

Most services that rely on at least one physical network card might not start as soon as usual. Moreover I expect to do something more with WPA supplicant as it seems to require a bridging-specific parameter, -b. So it might be not as straightforward as I expected.

Please post your comments at will.

----------

## rmh3093

yeah tried once and failed miserably.... but it might be easier with now that I know a little more about wpa_supllicant and wpa_cli, maybe do something like

```
ifconfig eth0 0.0.0.0

wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf -bbr0 -Bw

brctl addif br0 eth0

ifconfig br0 up

wpa_cli -ibr0 -B
```

that usually bring up my interface really fast and you can get an IP address, which you will have to give up before before you bridge to your ethernet port, but the once you add eth0 and eth1 to br0 you can take the IP you were given from eth1 and give it to br0 (and the default gw of course) and things should be bridged.... I might play around with this a little later and make sure this works

----------

## rmh3093

actually this works:

```
modprobe ipw3945

ipw3945d

ifconfig eth0 up

brctrl addbr br0

brctrl addif br0 eth0

brctrl addif br0 eth1

wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant/wpa_supplicant.conf -bbr0 -BW

wpa_cli -ieth1 -B

dhcpcd br0
```

----------

## VinzC

Great, thanks. Do you think it can fit Gentoo's /etc/conf.d/net configurations?

----------

## rmh3093

 *VinzC wrote:*   

> Great, thanks. Do you think it can fit Gentoo's /etc/conf.d/net configurations?

 

yeah remember /etc/conf.d/net is just a script so it should work if you things in that order

----------

## VinzC

 *rmh3093 wrote:*   

> remember /etc/conf.d/net is just a script so it should work if you things in that order

 

Right but I'd have preferred sticking to the pure Gentoo net config, i.e. writing only configuration instructions in /etc/conf.d/net. Such a script best fits /etc/conf.d/local.start IMHO. I'll do some tests again for I've just made some (more) unsuccessful manual attempts using the sequence of instructions you gave.

I'd like to keep the daemon running automatically when ipw3945 is inserted and, obviously, it is the case. I might have made a mistake sequencing the bridge/wlan/interface setup. I think this sequence will require tweaking a little the net config file, e.g. preventing netplug from messing up with all this. If I've understood, wpa_supplicant is responsible for bringing the bridge interface br0 up, is that right?

----------

## rmh3093

no i mean you should be able to use gentoo style init syntax, it still need to be in that order in conf.d/net

does this work?

```
bridge_br0="eth0 eth1"

config_eth0=( "null" )

config_eth1=( "null" )

modules=( "wpa_supplicant" )

wpa_supplicant_wlan="-Dwext -bbr0 -W"

associate_timeout_wlan=60

config_br0=( "dhcp" )
```

----------

## rmh3093

 *VinzC wrote:*   

> I'd like to keep the daemon running automatically when ipw3945 is inserted and, obviously, it is the case. I might have made a mistake sequencing the bridge/wlan/interface setup. I think this sequence will require tweaking a little the net config file, e.g. preventing netplug from messing up with all this. If I've understood, wpa_supplicant is responsible for bringing the bridge interface br0 up, is that right?

 

no wpa_supplicant is not responsible for bringing up the bridge, wpa_supplicant is only for associating,you can create the bridge device (br0) at any time, once your wired and wireless interfaces (eth0+eth1) are visible to your system you can, add them to your bridge (they must not have addresses though, or be associated), now the "-bbr0" option for wpa_supplicant lets it get the frames it needs from the bridge deivce so that I can scan and associate with AP's (since eth1 is not behind br0), once the ap is associated you should be able to get an address on the bridge device

----------

## VinzC

 *rmh3093 wrote:*   

> no i mean you should be able to use gentoo style init syntax, it still need to be in that order in conf.d/net
> 
> does this work?
> 
> ```
> ...

 

I'll try that. I did all that stuff manually only so I'm going to repeat it the above way. However shouldn't it be wpa_supplicant_eth1 instead of wpa_supplicant_wlan? Or even wpa_supplicant_br0 given what you posted just above? Or even wpa_supplicant alone?

----------

## VinzC

The following seems to work

```
config_eth0=( "null" )

config_eth1=( "null" )

bridge_br0="eth0 eth1"

brctl_br0=( "stp on" )

config_br0=( "dhcp" )

modules=( "!iwconfig" "!plug" "wpa_supplicant" )

wpa_supplicant="-c/etc/wpa_supplicant/minimal.conf -Dwext -bbr0 -W"

preferred_aps=( "olympe" "ap003" "inabata" "ProcessIT" "pit" )

associate_order="preferredonly"

associate_timeout=60
```

*but*It's damn soooo looooooong (it takes br0 up to 1:10 min to start!

I've tried to have that damn thing uinderstand I want my own config file (argument -c) for wpa_supplicant instead of the default one but it persists not to hear what I say...

Except these little annoyances it works. I just wonder if it's possible to start br0 a little bit faster...

See the progress (mind the timing):

```
Dec  6 20:14:28 solo eth0: Broadcom 4400 10/100BaseT Ethernet 00:14:22:ec:bb:07

Dec  6 20:14:30 solo device eth0 entered promiscuous mode

Dec  6 20:14:30 solo device eth1 entered promiscuous mode

Dec  6 20:14:30 solo br0: port 2(eth1) entering listening state

Dec  6 20:14:30 solo rc-scripts: ERROR:  net.br0 is already starting.

Dec  6 20:14:30 solo dhcpcd[10515]: MAC address = 00:13:02:0c:48:a8

Dec  6 20:14:45 solo br0: port 2(eth1) entering learning state

Dec  6 20:15:00 solo br0: topology change detected, propagating

Dec  6 20:15:00 solo br0: port 2(eth1) entering forwarding state

Dec  6 20:15:30 solo dhcpcd[10515]: verified 192.168.45.163 address is not in use

Dec  6 20:15:30 solo dhcpcd[10515]: your IP address = 192.168.45.163

Dec  6 20:15:40 solo ntpd[10854]: Listening on interface br0, 192.168.45.163#123 Enabled

Dec  6 20:15:56 solo ntpd[10921]: Listening on interface br0, 192.168.45.163#123 Enabled
```

I also wonder why I get "rc-scripts: ERROR:  net.br0 is already starting" since I disabled netplug and just added /etc/init.d/net.br0 to the default runlevel (otherwise the bridge didn't start).

EDIT: Well, no it doesn't quite work :'( . After a short while, my WiFi led starts blinking like if it were disconnected. I then see such messages in the event log:

```
Dec  6 20:27:59 solo br0: port 2(eth1) entering listening state

Dec  6 20:28:03 solo br0: port 2(eth1) entering disabled state

Dec  6 20:28:08 solo br0: port 2(eth1) entering listening state

Dec  6 20:28:12 solo br0: port 2(eth1) entering disabled state

Dec  6 20:28:17 solo br0: port 2(eth1) entering listening state

Dec  6 20:28:21 solo br0: port 2(eth1) entering disabled state

Dec  6 20:28:27 solo br0: port 2(eth1) entering listening state

Dec  6 20:28:31 solo br0: port 2(eth1) entering disabled state

Dec  6 20:28:36 solo br0: port 2(eth1) entering listening state

Dec  6 20:28:40 solo br0: port 2(eth1) entering disabled state
```

----------

## Hadriel

seems that i have to join the talk about ipw3945

i did a fresh stage1 install, kernel 2.6.19-gentoo-r1 runs. the problem is that wlan doesnt work at all. i was used to run this ieee80211 script do remove the header files from the kernel source, then emerge ipw3945 and wireless-tools. apart from having some problems with emerging ieee80211 (linux/config.h was missing, so i simply did a "touch" on it. worked afterwards), i cant seem to get wlan (neither wep nor wpa) to work.

ok, lets begin:

modprobe ipw3945: works, sometimes i have an eth1, sometimes not.

when i have it, wireless-tools seems to behave strangely. when doing "iwconfig eth1 essid "wgwlan", he sets the essid to "wgwla". no typo, he misses the "n"). dunno why.

furthermore, doing "iwconfig eth1 key s:mykey" results in a "error for wireless request "set encode": set failed on device eth1: operation not supported." i simply dont know what he wants to say!

so if you can help me, i would be REALLY relieved (since i never had such a nasty gentoo installation...).

thx in advance!

----------

## rmh3093

 *VinzC wrote:*   

> The following seems to work
> 
> ```
> config_eth0=( "null" )
> 
> ...

 

yeah i dont know why its taking so long, try getting rid of that associate timeout option, im not using sysvinit anymore.... einit actually, and make init scripts and starting network interfaces is so easy and customizable, I havent tried doing this with the gentoo scripts that was just a guess actually, im glad it worked though, when I use the command line to start everyting it start instantly

i did forget you need this:

RC_NEED_br0="net.eth0 net.eth1"

put that before the config_br0

----------

## rmh3093

 *Hadriel wrote:*   

> seems that i have to join the talk about ipw3945
> 
> i did a fresh stage1 install, kernel 2.6.19-gentoo-r1 runs. the problem is that wlan doesnt work at all. i was used to run this ieee80211 script do remove the header files from the kernel source, then emerge ipw3945 and wireless-tools. apart from having some problems with emerging ieee80211 (linux/config.h was missing, so i simply did a "touch" on it. worked afterwards), i cant seem to get wlan (neither wep nor wpa) to work.
> 
> ok, lets begin:
> ...

 

did you try my kernel patch for 2.6.19 kernels.... you need to unemerge ieee80211 and ipw3945 if you are going to, but I've tried it and it works for me.... you know how to patch a kernel right?

----------

## Hadriel

heh not really. but i guess i will find out now  :Wink: 

lets see if this works.

edit:patched the kernel and compiled it with ieee80211 as well as ipw3945 as modules.

i can modprobe ipw3945 now, but after emerging ipw3945d (do i still need it? what does it do anyway?), modprobe ipw3945 results in "could not find intel blabla Network connection

FATAL: error running install command for ipw3945

after getting the ipw3945.ucode file, a modprobe results in a complete system freeze.

----------

## rmh3093

yes you still need ipw3945d, if you are using an older version of udev the i think the modprobe script works properly and starts ipw3945d when you modprobe ipw3945, if that dosent work for you then use the ipw3945d init script or start it manually

if you have ipw3945d and ipw3945-ucode installed you should be fine

----------

## Hadriel

ok, i'll do another run. emerging 2.6.19, doing your patch update, building all as modules, emerge ipw3945d and ipw3945-ucode. 

i'll let you know if it works

ok, did everything of the above. 

modprobe ipw3945 works, but iwconfig still tells me that "set" is not supported. i checked out dmesg, which tells me "eth1: could not initialize WEP: load module ieee80211_crypt_wep". so i modprobe'd it as well. still the same iwconfig problem, but a new dmesg message: "ieee80211_crypt_wep: could not allocate crypto API arc4"

the thing is, i have both ieee80211_crypt_wep built as a module as well as arc4 algorithm built in in the kernel. any ideas?

----------

## rmh3093

its safe to build all of ieee80211 into the kernel, you shouldnt need to remove them for any reason, that should enable any crypto modules you need, still leave ipw3945 as a module....

use wpa_supplicant if you are using any sort of encryption, it will make your life easier

----------

## Hadriel

i'll try and build the ieee80211 into the kernel as soon as i am back home. too bad i have nearly no experience with wpa_supplicant. i never got it to work. even wep didnt work, and when i tried it yesterday, it told me that TPK or something couldnt be initialized (dont know the exact message, i'll post it later). 

is there an extensive howto on wpa_supplicant? the router is set to wpa-psk, and for encryption, i can choose TKIP (whatever it is), AES and TKIP+AES (i hope i dont mix things up here...).

thx so far for your help, i hope i will get this goddamn wlan to work. never had so many problems with it :/

----------

## Lloeki

wpa_supplicant is easy as pie to get running.

/etc/wpa_supplicant/wpa_supplicant.conf :

```

#stuff I set, not necessary

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=wheel

eapol_version=1

ap_scan=1

fast_reauth=1

# for a WPA ap

network={

        ssid="My_WPA_AP"

        psk="My_B1g_s3Cr3T_PSK"

}

# for an open ap

network={

        ssid="My_open_AP"

        key_mgmt=NONE

}

```

dunno for WEP, but it should be just as easy.

/etc/conf.d/net :

```

modules=( "wpa_supplicant"  )

config_wlan0="dhcpcd"

wpa_supplicant_wlan0="-Dwext"

```

----------

## hug0

Anyone with such problems!?

https://forums.gentoo.org/viewtopic-t-521712-highlight-ipw3945.html

*help*

Florian

----------

## rmh3093

wpa_gui makes configuring the networks really easy, but NetworkManager supports wpa_supplicant now which I have actually switched to... sooo nice

----------

## VinzC

 *Hadriel wrote:*   

> after getting the ipw3945.ucode file, a modprobe results in a complete system freeze.

 

I've experienced deadly lockups too. I've had to remove my kernel source tree entirely as well as all its installed modules in /lib/modules/<kernel-version>. I re-emerged the kernel source tree, patched it with rmh3093's ipw3945 patch and recompiled. I have no ipw3945 nor ieee80211 from portage anymore.

Here's a script to clean a source tree deeply:

```
if [ ! -d /usr/src/linux-$1 ]; then

        echo "Directory /usr/src/linux-$1 was not found."

        exit 1

fi

# Clean modules and everything

echo Cleaning source tree...

cd /usr/src/linux-$1 && make mrproper && cd ..

# Un-merge sources

PKG=$(equery b /usr/src/linux-$1 | gawk '{ print $1 }' | head -n 1)

emerge -vC $PKG

# Exit if package was not removed

[ $? -ne 0 -o -d /var/db/pkg/$PKG ] && exit 0

# Remove directory if it still exists

echo Removing remaining source tree objects...

[ -d /usr/src/linux-$1 ] && rm -r /usr/src/linux-$1

# Remove library modules if any

echo Removing remaining kernel modules...

[ -d /lib/modules/$1 ] && rm -r /lib/modules/$1
```

----------

## Hadriel

@VinzC

that is no longer the problem. i redid all the stuff and it now compiles, loads and wont crash anymore.

@Lloeki

when using wpa_supplicant, my .conf looks nearly the same as yours. when doing #wpa_supplicant -w -Dwext -ieth1 -c/etc/wpa_supplicant.conf,

i get

Trying to associate with <mac address of the router>

Associated with <mac address>

ioctl[SIOCSIWENCODEEXT]: Invalid argument

WPA: Failed to set PTK to the driver

i still believe that the combination 2.6.19+ ipw3945 is really messed up. it was so easy with 2.6.13 and ipw3945. and now it took me 10+hours and i am not finished yet...

when trying wep with iwconfig, i do #iwconfig eth1 key s:mywepkey

i get a not supported, as well as the known

could not initialize WEP: Load module ieee80211_crypt_wep

so still a no go for wlan here...

edit: got wep to work! i made ieee80211 built into the kernel. now i cant properly set the key with iwconfig. only flaw is that modprobe ipw3945 complains that he cant load the modules ieee80211*.ko. he doesnt need them anyway, so...how do i get rid of these messages? next task will be to make wpa_supplicant work.

again, thx for the help so far!  :Smile: 

edit2: got rid of the stupid messages. wep now works perfectly!

i still wonder why it has become so difficult to get it to work...new kernel? new ipw3945 driver?

----------

## rmh3093

VinzC: id you try adding that RC_DEPEND option.... did you get the bridge working with sysvinit+gentooscripts?

 *Hadriel wrote:*   

> edit2: got rid of the stupid messages. wep now works perfectly!
> 
> i still wonder why it has become so difficult to get it to work...new kernel? new ipw3945 driver?

 

Hadriel: when ever you mix around and play with portage and kernel modules things can get messy durring the transition, when ever you have issues like that blasting out /lib/modules gets rid of all those stale modules

----------

## zalun

I've reinstalled gentoo   :Embarassed:   after upgrading udev. My further problems are described here: https://forums.gentoo.org/viewtopic-t-522759-highlight-ipw3945+ucode.html

Right now I try with stuff compiled into the kernel. 

I unmerged the ieee82011. and emerged netplug to get closer to the VinzC's conf

No luck. Here's the debug:

```

localhost ~ # uname -a

Linux localhost 2.6.18-gentoo-r3 #3 SMP Fri Dec 8 07:43:37 GMT 2006 i686 Genuine Intel(R) CPU           T2050  @ 1.60GHz GenuineIntel GNU/Linux

localhost ~ # dmesg | grep ipw

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.2

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: ipw3945.ucode load failed: Reason -2

ipw3945: Could not read microcode: -2

ipw3945: probe of 0000:0b:00.0 failed with error -2

kobject_add failed for ipw3945 with -EEXIST, don't try to register things with the same name in the same directory.

localhost ~ # dmesg | grep ieee

ieee80211: 802.11 data/management/control stack, git-1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ieee80211_crypt: registered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'WEP'

ieee80211_crypt: registered algorithm 'CCMP'

ieee80211_crypt: registered algorithm 'TKIP'

ieee80211_crypt: exports duplicate symbol ieee80211_crypt_deinit_entries (owned by kernel)

ieee80211: exports duplicate symbol alloc_ieee80211 (owned by kernel)

```

----------

## Hadriel

@zalun

he complains about the microcode not being found. check /lib/firmware if an ipw3945.ucode file exists.

if not, you have to emerge ipw3945-ucode.

furthermore, did you use rmh3093's kernel patch? if so, did you correctly built the ipw3945 thing as a module? if not, do so, else he cant find the microcode (i tested this already).

@rmh3093

in my last gentoo installation, i did a normal stage1 approach, emerged ipw3945, modprobed the module and everything went just fine. this time, i had to use your patch. without your patch, my wlan wouldnt cooperate. thats what i meant with "why it has become so difficult". 

anyway, thanks for your kernel patch!

----------

## zalun

the problem is that it freezes at coldplug when compiled as a module (the wifi lamp is blinking).

just to mention:

 * udev 0.87-r1

 * localhost linux # ls -l /lib/firmware/ -rw-r--r-- 1 root root 111572 Dec  8 05:31 ipw3945.ucode

----------

## Fran

 *Hadriel wrote:*   

> edit2: got rid of the stupid messages. wep now works perfectly!
> 
> i still wonder why it has become so difficult to get it to work...new kernel? new ipw3945 driver?

 

With a 2.6.19 kernel? I still haven't been able to connect to the AP with the 2.6.19 kernel. I can compile the driver with the patch I posted some pages ago, and it loads fine, but the led keeps blinking without connecting.

----------

## Hadriel

@zalun

i believe when upw3945 compiled into the kernel, you cant get it to work. he simply wont find the microcode (dont ask me why  :Smile:  ). 

i had this freezing thing, too. i deleted all modules and did a fresh emerge of gentoo-sources (2.6.19). patched the kernel, built in ieee80211 (no modules, ALL built in!), built ipw3945 as a module, (re-)emerged ipw3945d and ipw3945-ucode, rebooted, modprobe'd ipw3945 and it worked.

@Fran

yup, 2.6.19 kernel. i use WEP and iwconfig tho, didnt try wpa_supplicant yet. whats your dmesg output when trying to connect?

----------

## Fran

 *Hadriel wrote:*   

> @Fran
> 
> yup, 2.6.19 kernel. i use WEP and iwconfig tho, didnt try wpa_supplicant yet. whats your dmesg output when trying to connect?

 

The usual:

```
ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, git-1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.0mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

ieee80211_crypt: registered algorithm 'WEP'
```

And I'm also using iwconfig:

```
essid_eth1="reyuonv"

channel_eth1="13"

key_reyuonv="801AF40D136E47BA5D439EDEB6 enc open"

```

It simply won't connect, as if the key was wrong (it isn't, it works with 2.6.18). Maybe it's because I don't broadcast the essid in the AP? (I had to broadcast it for wpa_supplicant to work, maybe it's required in 2.6.19....) Or maybe I have to built the ieee stack in the kernel (not as modules). I'll try both.

----------

## Fran

I tried broadcasting the essid, but it still doesn't connect. So I compiled the ieee80211 stack built-in the kernel, instead of as modules, and when I try to load the ipw3945 module I get a bunch of Unknown symbol errors:

```
Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_wx_get_encodeext

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_wx_set_encode

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_wx_get_encode

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_txb_free

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_wx_set_encodeext

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_wx_get_scan

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol escape_essid

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_freq_to_channel

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_set_geo

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_rx

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_get_channel

Dec  8 11:44:12 localhost kernel: ipw3945: Unknown symbol ieee80211_channel_to_index

....

```

 :Confused: 

Are you using the patch that I posted some pages ago? Are you sure you are using the 2.6.19 in-kernel ieee stack?

(edit) Nevermind, I forgot to copy the new compiled kernel to /boot   :Embarassed: 

(edit2) Nope, still no luck. I've tried without encription, with wep/iwconfig, wep/wpa_supplicant and wpa/wpa_supplicant, with ieee80211 as modules and builtin, and with and without essid broadcast. I can't connect in 2.6.19.

----------

## rmh3093

coldplug is garbarge.... why dose anyone need to use that crap.... i doubt anyone has a system so low on memory can they actually need to save memory by not building modules into the kernel, the only things you should leave as modules are things that need firmware like wireless drivers and drivers that like to break suspending (usb,video)........... just add ipw3945 to /etc/modules.autoload.d/ instead of coldplug and you the init script to start the daemon, I have been at udev103 with out a problem, my system does not freeze

----------

## zalun

 *rmh3093 wrote:*   

> coldplug is garbarge.... 

 

Thanks man.

I've got it finally working. There is a need to be careful with module stuff at the moment, but for that price I've got quicker boot process and working wifi, so - priceless.

zalun

----------

## VinzC

 *rmh3093 wrote:*   

> VinzC: id you try adding that RC_DEPEND option.... did you get the bridge working with sysvinit+gentooscripts?

 

Not yet as I've been focusing on something else for the last couple of days. I'll try the RC_DEPEND option soon and post the results.

----------

## Hadriel

@rmh3093

when i put ipw3945 into modules.autoload.d, i get errors that he couldnt load the module (manually modprobing works...).

----------

## celticsoul

 *sashak wrote:*   

>  *zidour wrote:*   Well, I was looking around a bit and this is what I have found:
> 
> 1) ipw3945 is inserted when udev is started. This is done at boot by "/lib/rcscripts/addons/udev-start.sh". Unfortunately I don't know what mechanism udev uses for inserting modules (is it possible that it is just insmoding instead of modprobing?). Anyway, when the module is inserted by udev, the daemon is not started.
> 
>  
> ...

 

I have the same problem, after upgrading to udev-103, my solution is to put --pid-file=/dev/ipw3945.pid next to --quiet in ipw3945

So my /etc/modules.d/ipw3945 looks like:

```

install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet --pid-file=/dev/ipw3945.pid

remove ipw3945 /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945

```

And then run "modules-update"

Thanks sashak for pointing out this. and until someone find a better solution.

----------

## Fran

The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP.

----------

## lex82

 *Fran wrote:*   

> The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP.

 

When are they supposed to be marked as stable (kernel 2.6.19.1 and ipw3945 1.1.3)? I have a lot of connections problem and I don't want to break my work laptop system...

----------

## Fran

 *lex82 wrote:*   

>  *Fran wrote:*   The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP. 
> 
> When are they supposed to be marked as stable (kernel 2.6.19.1 and ipw3945 1.1.3)? I have a lot of connections problem and I don't want to break my work laptop system...

 

You can't break your system by installing a new kernel (just leave the old kernel in /boot and you can always boot it from grub) and a new ipw3945 (it's a module; the old module remains at /lib/modules/<old-kernel-version>/ and will be automatically used when booting the old kernel). So unmask it and try  :Wink: 

----------

## rmh3093

 *Fran wrote:*   

> The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP.

 

cool... i supposed its time for me to make new kernel patches for version 1.1.3

----------

## rituko_a

 *rmh3093 wrote:*   

>  *Fran wrote:*   The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP. 
> 
> cool... i supposed its time for me to make new kernel patches for version 1.1.3

 

I hope you're planning to do that before next year, so that some of us could thank you much more while being away from their wires =)

Thanks in advance, and... merry christmas =)

 *Fran wrote:*   

> The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP.

 

Here it doesn't even compile, maybe I've missed something, because this thread is too long.

```
 WARNING: Your kernel contains ieee80211 symbol definitions and you

are not using the kernel's default ieee80211 subsystem.  (Perhaps you

used the out-of-tree ieee80211 subsystem's 'make install' or have

provided a path to the ieee80211 subsystem via IEEE80211_INC.)

..........
```

suspend2-sources-2.6.19-r1, ipw3945-1.1.3 from portage, everything is built-in into kernel, instead of ipw3945 drivers.

Then it fails with such errors:

```
/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c:4416:20: error: operator '>=' has no left operand

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c: In function âipw_start_associationâ:

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c:4427: error: too few arguments to function âieee80211_tx_frameâ

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c:4902:20: error: operator '>=' has no left operand

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c: In function âipw_bg_daemon_cmdâ:

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c:4909: error: too few arguments to function âieee80211_tx_frameâ

/var/tmp/portage/net-wireless/ipw3945-1.1.3/work/ipw3945-1.1.3/ipw3945.c:9380:20: error: operator '>=' has no left operand

...
```

and lots of similar stuff

----------

## rmh3093

 *rituko_a wrote:*   

>  *rmh3093 wrote:*    *Fran wrote:*   The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP. 
> 
> cool... i supposed its time for me to make new kernel patches for version 1.1.3 
> 
> I hope you're planning to do that before next year, so that some of us could thank you much more while being away from their wires =)
> ...

 

http://www.rit.edu/~rmh3093/ipw3945-1.1.3_for_2.6.19.patch

sorry it took me so long to make the updated patch.... i've been playing with other things gentoo  :Wink: 

----------

## Fran

 *rituko_a wrote:*   

>  *Fran wrote:*   The 1.1.3 version of ipw3945 works great with 2.6.19.1 and builtin ieee80211. No more need of config.h or patches, and now it succesfully connects to the AP. 
> 
> Here it doesn't even compile, maybe I've missed something, because this thread is too long.
> 
> ```
> ...

 

Hmm, strange. The only thing I did was changing /usr/src/linux-2.6.19.1/scripts/Kbuild.include to avoid the sandbox violation. I didn't do anything else. The ebuild I used was the same as the portage version with this differences:

```
franjva@dell /usr/local/overlays/portage/net-wireless/ipw3945 $ diff /usr/portage/net-wireless/ipw3945/ipw3945-1.1.3.ebuild .

21,23c21,23

< IUSE="debug"

< DEPEND=">=net-wireless/ieee80211-${IEEE80211_VERSION}"

< RDEPEND=">=net-wireless/ieee80211-${IEEE80211_VERSION}

---

> IUSE="debug ieee80211_kernel"

> DEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})"

> RDEPEND="!ieee80211_kernel? (=net-wireless/ieee80211-${IEEE80211_VERSION})

43c43

<       if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]]; then

---

>       if [[ ! -f ${ROOT}/lib/modules/${KV_FULL}/net/ieee80211/ieee80211.${KV_OBJ} ]] && use !ieee80211_kernel; then

54c54,58

<       BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

---

>       if kernel_is ge 2 6 18; then

>               BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_IGNORE_DUPLICATE=y"

>       else

>               BUILD_PARAMS="KSRC=${KV_DIR} KSRC_OUTPUT=${KV_OUT_DIR} IEEE80211_INC=/usr/include"

>       fi

```

That's all. No patches, no copying config.h from an older kernel, nothing. Everything compiled and loaded fine.

----------

## rmh3093

has anyone played with a 2.6.20-rc* kernel yet? im pretty sure the drivers are going to need to be tweaked to work with 2.6.20

----------

## lex82

IMHO it's not the kernel that should be adapted for ipw3945 module but the opposite. The ipw3945 driver developers should work with the vanilla kernel and release a module that compiles against it. IEEE 802.11 stack support is in kernel since some times ago....

----------

## rmh3093

 *lex82 wrote:*   

> IMHO it's not the kernel that should be adapted for ipw3945 module but the opposite. The ipw3945 driver developers should work with the vanilla kernel and release a module that compiles against it. IEEE 802.11 stack support is in kernel since some times ago....

 

??? what are you arguing... that is exactly what the ipw3945 devs do.... 2.6.20 isnt out so there is no fixed ipw3945 driver

.... so like I said, I will patch the driver to make it work untill 1.1.4 comes out or a patch is posted on the sourceforge site to fix the 1.1.3 driver properly....

...there are a bunch of changes in 2.6.20, this compiles but give off a $shit load of warnings (against 2.6.20-rc1-mm1, against 2.6.20-rc1-git7 i didnt see the warnings) ... i will try and clean it more up more soon, here is the testing version http://www.rit.edu/~rmh3093/ipw3945-1.1.3_for_2.6.20.patch

----------

## Hanoc

I'm having some related problem but I don't see the solution reading the last pages of this thread... I know the solution is there but I fail to see it because I get lost in the gibberish.

I'm kind of newbie in wirless stuff (and in almost anything related to gentoo) and I could really use some directions...

if anyone can please look at https://forums.gentoo.org/viewtopic-p-3802350.html and lend me a hand I would be very grateful.

Thanks!

----------

## rmh3093

 *Hanoc wrote:*   

> I'm having some related problem but I don't see the solution reading the last pages of this thread... I know the solution is there but I fail to see it because I get lost in the gibberish.
> 
> I'm kind of newbie in wirless stuff (and in almost anything related to gentoo) and I could really use some directions...
> 
> if anyone can please look at https://forums.gentoo.org/viewtopic-p-3802350.html and lend me a hand I would be very grateful.
> ...

 

did you ever finish the interrupted "emerge world"? did you remember to run "etc-update" after? try "emerge -C ipw3945 ipw3945d ipw3945-ucode", then "emerge -uDN world", reboot, then reinstall your drivers

----------

## Hanoc

I did finish the emerge world and I did all the steps you point out unless the emerge -C. I just reemerged with no prior Unmerge.

Anyway, I've just did that, and followed step by step the guide another time...

Now, emerging the packages says something different... wich seemed good...

```
# emerge -av ieee80211 ipw3945 wireless-tools wpa_supplicant

Calculating dependencies... done!

[ebuild   R   ] net-wireless/ieee80211-1.2.15  USE="-debug" 0 kB 

[ebuild  N    ] net-wireless/ipw3945d-1.7.22-r4  0 kB 

[ebuild  N    ] net-wireless/ipw3945-ucode-1.13  0 kB 

[ebuild   R   ] net-wireless/wireless-tools-29_pre10  USE="nls -multicall" 0 kB 

[ebuild   R   ] net-wireless/wpa_supplicant-0.5.6  USE="dbus madwifi qt3 readline ssl -gsm -qt4" 0 kB 

[ebuild  N    ] net-wireless/ipw3945-1.1.3  USE="-debug" 0 kB 

```

but my wirleess card is still missing from iwconfing and I get this when I try to start ipw3945:

```
# /etc/init.d/ipw3945d restart

 * Stopping ipw3945d ...                                                                                   [ ok ]

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory  
```

Any ideas? any logs you want me to post?

EDIT: I have some output that may be interesting:

```
# dmesg | grep ipw

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.2mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: ipw3945.ucode load failed: Reason -2

ipw3945: Could not read microcode: -2

ipw3945: probe of 0000:03:00.0 failed with error -2

```

and

```

# dmesg | grep iee 

ieee1394: Initialized config rom entry `ip1394'

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, 1.2.15

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ieee1394: Host added: ID:BUS[0-00:1023]  GUID[000ae40600162006]

ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)

ieee1394: sbp2: Try serialize_io=0 for better performance

ieee80211_crypt: registered algorithm 'WEP'

ieee80211_crypt: registered algorithm 'TKIP'

ieee80211_crypt: registered algorithm 'CCMP'

```

----------

## rmh3093

 *Hanoc wrote:*   

> I did finish the emerge world and I did all the steps you point out unless the emerge -C. I just reemerged with no prior Unmerge.
> 
> Anyway, I've just did that, and followed step by step the guide another time...
> 
> Now, emerging the packages says something different... wich seemed good...
> ...

 

your issue i think is right in this post, i see when you try to emerge ipw3945 from portage it trys to install version 1.1.3 but i noticed the output from your kernel says the version 1.1.2 is loaded (probably because you didnt 'emerge -C ipw3945' like I   said  :Wink: .... you must have module cruft in /lib/modules

try this for what ever kernel version you are running:

```
rm -rf /lib/modules/<current_kernel>

cd /usr/src/linux

make && make install && make modules_install

emerge ipw3945
```

then reboot and see what happens

----------

## Hanoc

I did emerge -C but I think that yesterday I forgot the "modules_install" step.

Anyway... I just deleted by hand the stuff under "rm -rf /lib/modules/2.6.18*" and after the modules install and the emerge ipw13945 I have nothing on it.

If I try to start eth2 I get:

```
network interface does not exist
```

and I still get the:

```

# /etc/init.d/ipw3945d restart

 * Stopping ipw3945d ...                                                                                   [ ok ]

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory 
```

I also did "modules-update" and nothing happened.

Thanks for your patience rmh3093

EDIT: as a side effect I've lost my sound because It says it can load the alsa driver, wich is obvious since there is no module under the /lib/modules folders...

this makes me think that for some reason the modules did not compile or install correctly

EDIT: ok, I'm not compiling the kernel I think I'm compiling.

uname -a says 2.6.18 but my symlink points to 2.6.19.

I'll try to fix it and post something later.

----------

## Hanoc

I recompiled the right modules but I still get the same errors mentioned above (except for the sound part wich is obiously solved).

the contens of lib/modules/kernel are:

```
root@strelka:/lib/modules/2.6.18-gentoo-r3# ls -1

build

kernel

modules.alias

modules.ccwmap

modules.dep

modules.ieee1394map

modules.inputmap

modules.isapnpmap

modules.ofmap

modules.pcimap

modules.seriomap

modules.symbols

modules.usbmap

source

```

----------

## Hanoc

I just did everything from the start again and now I get the original problem I had:

```
root@strelka:~# /etc/init.d/net.eth2 restart

 * Stopping eth2

 *   Bringing down eth2

 *     Shutting down eth2 ...                                                                              [ ok ]

 *     Stopping wpa_cli on eth2 ...                                                                        [ ok ]

 *     Stopping wpa_supplicant on eth2 ...                                                                 [ ok ]

 * Starting eth2

 *   Wireless radio has been killed for interface eth2

 *   wpa_supplicant will launch, but not associate until

 *   wireles radio is re-enabled for interface eth2

 *   Starting wpa_supplicant on eth2 ...

ioctl[SIOCSIWMODE]: Resource temporarily unavailable

Could not configure driver to use managed mode

ioctl[SIOCGIWRANGE]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 7 value 0x1 - ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Resource temporarily unavailable                                [ ok ]th param 5 value 0x1 - 

 *   Starting wpa_cli on eth2 ...                                                                          [ ok ]

 *     Backgrounding ...

```

My wireless led is blinking again... I see eth2 in iwconfigeth0      no wireless extensions.

```

eth0      no wireless extensions.

lo        no wireless extensions.

eth1      no wireless extensions.

sit0      no wireless extensions.

eth2      IEEE 802.11g  ESSID:"home�"  

          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:18:84:12:29:62   

          Bit Rate:54 Mb/s   Tx-Power:15 dBm   

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:C606-1609-EB53-A9F9-7FA9-D5A6-DD01-AD22-EC8C-78F1-0269-B7AF-E7F3-4C34-0270-8F4A   Security mode:open

          Power Management:off

          Link Quality=99/100  Signal level=-24 dBm  Noise level=-24 dBm

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:84   Missed beacon:0

```

but I still get the nasty error stated above and I'm not able to connect neither to get wpa_supplicant working:

```

root@strelka:/home/hanoc# wpa_cli 

wpa_cli v0.5.6

Copyright (c) 2004-2006, Jouni Malinen <jkmaline@cc.hut.fi> and contributors

This program is free software. You can distribute it and/or modify it

under the terms of the GNU General Public License version 2.

WPA: No SSID info found (msg 1 of 4).

Alternatively, this software may be distributed under the terms of the

BSD license. See README and COPYING for more details.

Could not connect to wpa_supplicant - re-trying

```

Anyway... the wpa_supplicant part should go somwhere else... what worries me most is the ioctl[SIOCSIWMODE]: Resource temporarily unavailable part.

Thanks for your help and sorry about the flooding... I hope something on this would ring someone a bell  :Smile: 

----------

## rmh3093

 *Hanoc wrote:*   

> I just did everything from the start again and now I get the original problem I had:
> 
> ```
> root@strelka:~# /etc/init.d/net.eth2 restart
> 
> ...

 

do you see that message about "WPA: No SSID info found (msg 1 of 4)."..... does your wireless card work if you dont use wpa_supplicant.... my guess is that your wpa_supplicant.conf is empty or ill-formed, have your tried wpa_supplicant from a command line instead of using the gentoo scripts...

```
wpa_supplicant -Dwext -ieth2 -c/etc/wpa_supplicant/wpa_supplicant.conf -Bw

wpa_cli -B -ieth2

dhcpcd eth2
```

----------

## Hanoc

I had tried something similar.. anyway I'll post the output on exactly this one:

```

root@strelka:/home/hanoc# wpa_supplicant -Dwext -ieth2 -c/etc/wpa_supplicant/wpa_supplicant.conf -Bw 

root@strelka:/home/hanoc# wpa_cli -B -ieth2 

wpa_cli v0.5.6

Copyright (c) 2004-2006, Jouni Malinen <jkmaline@cc.hut.fi> and contributors

This program is free software. You can distribute it and/or modify it

under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the

BSD license. See README and COPYING for more details.

Could not connect to wpa_supplicant - re-trying

```

The problem is that trying to get everything working without wpa_supplicant doesn't work either.

I get the following:

```

root@strelka:/var/run/ipw3945d# iwlist eth2 scanning

eth2      Scan completed :

          Cell 01 - Address: 00:18:84:12:29:61

                    ESSID:"FON_AP"

                    Protocol:IEEE 802.11bg

                    Mode:Master

                    Channel:1

                    Encryption key:off

                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s

                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s

                              48 Mb/s; 54 Mb/s

                    Quality=98/100  Signal level=-26 dBm  Noise level=-26 dBm

                    Extra: Last beacon: 1720ms ago

          Cell 02 - Address: 00:18:84:12:29:62

                    ESSID:"home"

                    Protocol:IEEE 802.11bg

                    Mode:Master

                    Channel:1

                    Encryption key:on

                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s

                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s

                              48 Mb/s; 54 Mb/s

                    Quality=97/100  Signal level=-26 dBm  Noise level=-28 dBm

                    IE: WPA Version 1

                        Group Cipher : WEP-40

                        Pairwise Ciphers (2) : TKIP WEP-40

                        Authentication Suites (1) : PSK

                    IE: IEEE 802.11i/WPA2 Version 1

                        Group Cipher : WEP-40

                        Pairwise Ciphers (2) : TKIP WEP-40

                        Authentication Suites (1) : PSK

                    Extra: Last beacon: 1720ms ago

          Cell 03 - Address: 00:0F:3D:A7:D7:50

                    ESSID:"orbita"

                    Protocol:IEEE 802.11bg

                    Mode:Master

                    Channel:6

                    Encryption key:on

                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s

                              11 Mb/s; 12 Mb/s; 18 Mb/s; 22 Mb/s; 24 Mb/s

                              36 Mb/s; 48 Mb/s; 54 Mb/s

                    Quality=97/100  Signal level=-28 dBm  Noise level=-28 dBm

                    IE: WPA Version 1

                        Group Cipher : WEP-40

                        Pairwise Ciphers (1) : WEP-40

                        Authentication Suites (1) : PSK

                    Extra: Last beacon: 1670ms ago

root@strelka:/var/run/ipw3945d# iwconfig eth2 essid  "FON_AP"

root@strelka:/var/run/ipw3945d# iwconfig 

eth0      no wireless extensions.

lo        no wireless extensions.

eth1      no wireless extensions.

sit0      no wireless extensions.

eth2      unassociated  ESSID:"FON_AP"  

          Mode:Managed  Frequency=nan kHz  Access Point: Not-Associated   

          Bit Rate:0 kb/s   Tx-Power:16 dBm   

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:122   Missed beacon:0

```

And it continues to be unassociated forever.

I also followed this thread

https://forums.gentoo.org/viewtopic.php?p=3803854

without succes.

Thanks all for your help... I'll keep trying.

EDIT:

I've let the wireless conection to keep trying to connect for a while and I've noticed that I get an incredibly high amount of Invalid misc packets:

```

eth0      no wireless extensions.

lo        no wireless extensions.

eth1      no wireless extensions.

sit0      no wireless extensions.

eth2      unassociated  ESSID:"FON_APB"  

          Mode:Managed  Frequency=nan kHz  Access Point: Not-Associated   

          Bit Rate:0 kb/s   Tx-Power:16 dBm   

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:13E6-C706-38B0-4246-EEFE-153D-D821-EABE-390B-613F-2114-4AF2-36B8-BBF3-FC48-FD02   Security mode:open

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:809   Missed beacon:0

```

Also note that it has retrieved some kind of encryption key... but I can't connect.

Also curious that the essid changed between "FON_AP" and "FON_APB" without me touching anything.

Strange, very strange.

----------

## LD

I'm having some odd errors right now. I'm using the 802.11 stack outside the kernel with the driver. For some reason it stopped working resently.

Dmesg shows that the driver is installed and a connection is found.

```
tennyson linux # dmesg | grep ipw

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
```

but when I run ipw3945d by itself I get:

```
 ipw3945d

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.22

2006-12-29 08:26:59: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

```

Not sure where to go from here.

----------

## rmh3093

 *LD wrote:*   

> I'm having some odd errors right now. I'm using the 802.11 stack outside the kernel with the driver. For some reason it stopped working resently.
> 
> Dmesg shows that the driver is installed and a connection is found.
> 
> ```
> ...

 

recompile your ipw3945 driver

----------

## LD

Done that three times. Still no good. Tried recompiling the kernel, the 802.11 stack, the ipw3945 driver, ucode, and daemon. Nothing.

----------

## fbcyborg

Hi all! 

I recently crashed my wi-fi system. I don't know the reason, but now it still not working. 

I'm having trouble since I was trying to fix some problems about pcmcia card reader.

In fact, every time I was booting my notebook cardmgr was saying: 

```
cardmgr [some_number]: bla bla bla... Function not implemented
```

To fix that problem I read I had to remove pcmcia-cs and ioctl module (obsolete) from kernel.

BTW: Before I begun to fix pcmcia problem, wifi worked for me. I had both pcmcia-cs and ioctl module built in in the kernel.

I don't know why, but now my wifi seems to be functional (iwlist eth1 scan, shows me right results) even though it doesn't associate with any AP.

I'm using wpa_supplicant & wpa_gui to make connections. It "always" worked for me.

This is what happens when I restart my eth1 interface by initscript:

```
# /etc/init.d/net.eth1 restart

 * Stopping eth1

 *   Bringing down eth1

 *     Shutting down eth1 ...                                                                                                          [ ok ]

 *     Stopping wpa_cli on eth1 ...                                                                                                    [ ok ]

 *     Stopping wpa_supplicant on eth1 ...                                                                                             [ ok ]

 * 'modprobe yenta_socket' failed

 * Trying alternative PCIC driver: i82365

 * Starting pcmcia ...

cardmgr[12111]: no pcmcia driver in /proc/devices

 * cardmgr failed to start.  Make sure that you have PCMCIA

 * modules built or support compiled into the kernel                      
```

I don't understand WHY PCMCIA should be called. I don't have a pcmcia-wifi card. It's a built-in one. In the specific it's :

```
Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
```

I also done one more time procedure described here, but without positive results.

I don't know why, but it seems I should solve pcmcia problems before I'm be able to use wifi card again.

Please help me to find where's the problem, I don't have more ideas.

I also saw a strange fact: wi-fi connection was recently working for a moment. After a reboot, bad situation came back.

bye!

EDIT: downgrading to udev-087-r1 and re-upgrading udev up to 103 version it seems to be working again. I'm really mystified!!!!!!! O_O   :Shocked: 

----------

## rmh3093

 *LD wrote:*   

> Done that three times. Still no good. Tried recompiling the kernel, the 802.11 stack, the ipw3945 driver, ucode, and daemon. Nothing.

 

i just went though this issue today actually, took me hours to get my wireless card working again, i think it has to do with the ipw3945 daemon. i unmerged "ipw3945,ipw3945d & ipw3945-ucode", i then did a "rm -rf  /lib/modules/*", i then switched over to my kernel source dir and did a "make install && make modules_install", rebooted. after the computer rebooted i installed ipw3945d and ipw3945-ucode (because i use the in-tree kernel module), once i started the daemon my card was working again....

i have no idea why it stopped working today, but this is how I fixed it.... before I did these steps i tried multiple times just reinstalling the firmware or the module with no luck i had to purge everything  and it finally worked

----------

## fbcyborg

Hi!

My card, instead, came back to go on strike again. It seems it is taking joke of me... 

I'm very furious. Mainly I haveo to solve pcmcia card problem. If not, I'm not be able to get wifi card (built in) working.

Nobody knows how to solve 

```
cardmgr : no pcmcia driver in /proc/devices
```

 *rmh3093 wrote:*   

>  i think it has to do with the ipw3945 daemon. i unmerged "ipw3945,ipw3945d & ipw3945-ucode", i then did a "rm -rf /lib/modules/*", i then switched over to my kernel source dir and did a "make install && make modules_install", rebooted. after the computer rebooted i installed ipw3945d and ipw3945-ucode (because i use the in-tree kernel module), once i started the daemon my card was working again.... 

 

It didn't worked for me..

I also used "module-rebuild" tool to be sure I wasn't forgetting any module to compile for my kernel, but nothing works for me. It's a real banter

Now I have the following problem at boot:

```

* Starting ipw3945d ...

* `modprobe yenta_socket` failed ...

/sbin/start-stop-daemon: stat /sbin/cardmgr: No such file or directory (no such file or directory)

* cardmgr failed to start. Make sure that you have PCMCIA 

* built or support compiled into the kernel
```

It's so strange because, yenta_socket is "built-in" into the kernel (not as module) .. I also don't understand why pcmcia should be functional to get my built in wifi card!!!!!!!!! It's absurd!

----------

## rmh3093

 *fbcyborg wrote:*   

> Hi!
> 
> My card, instead, came back to go on strike again. It seems it is taking joke of me... 
> 
> I'm very furious. Mainly I haveo to solve pcmcia card problem. If not, I'm not be able to get wifi card (built in) working.
> ...

 

why is cardmrg running? that is deprecated and its functions have been moved into the kernel, should shouldnt need pcmcia-cs

----------

## lex82

 *rmh3093 wrote:*   

> why is cardmrg running? that is deprecated and its functions have been moved into the kernel, should shouldnt need pcmcia-cs

 

Ehm... the gentoo's handbook says you need pcmcia-cs to use PCMCIA devices... maybe someone should really update those docs!   :Wink: 

----------

## fbcyborg

Hi! 

I removed pcmcia-cs as well.

cardmgr isn't now present on my system, in fact when I try to start net.eth1:

```
# /etc/init.d/net.eth1 restart

* Stopping eth1

 *   Bringing down eth1

 *     Shutting down eth1 ...                                                                                 [ ok ]

 *     Stopping wpa_cli on eth1 ...                                                                         [ ok ]

 *     Stopping wpa_supplicant on eth1 ...                                                             [ ok ]

 * 'modprobe yenta_socket' failed

 * Trying alternative PCIC driver: i82365

 * Starting pcmcia ...

/sbin/start-stop-daemon: stat /sbin/cardmgr: No such file or directory (No such file or directory)

 * cardmgr failed to start.  Make sure that you have PCMCIA

 * modules built or support compiled into the kernel                                                         [ !! ]

```

yenta_socket is not compiled as module. It's built-in.

Now I'm still trying to understand and to fix that pcmcia problem.

Do you think pcmcia should be on any runlevel??? my rc-update show, shows this:

pcmcia |         boot

----------

## lex82

You ought to remove it from your boot runlevel. Just give "rc-update del pcmcia boot".

----------

## fbcyborg

Thank you very much. 

Now I don't have any more error message on pcmcia (I hope to be able to use pcmcia card reader now).

My wi-fi connection is still not working.

Now I have the following errors, on net.eth1 restart:

```
# /etc/init.d/net.eth1 restart

 * Stopping eth1

 *   Bringing down eth1

 *     Shutting down eth1 ...                                                                                                      [ ok ]

 *     Stopping wpa_cli on eth1 ...                                                                                             [ ok ]

 *     Stopping wpa_supplicant on eth1 ...                                                                                [ ok ]

 * Starting eth1

 *   Starting wpa_supplicant on eth1 ...

ioctl[SIOCSIWMODE]: Resource temporarily unavailable

Could not configure driver to use managed mode

ioctl[SIOCGIWRANGE]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 7 value 0x1 - ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Resource temporarily unavailable                              [ ok ]th param 5 value 0x1 -

 *   Starting wpa_cli on eth1 ...                                                                                                      [ ok ]

 *     Backgrounding ...

```

I read a previous post reporting the same error, but I'm not be able to solve that problem.

EDIT1: I don't know how it's possible, but it's now working again!!!!! I'm very amazed.

EDIT2: WOOOOW!!! Now I can't use my wifi card again!!!! But it's impossible!!! O_O

it seems it isn't able to associate to an Access point. It is still trying to do that.

----------

## par4noia

Hello all!

I'm trying to emerge ipw3945 ebuild with my 2.6.19-r2 kernel...The ebuild version I'm trying to merge is 1.1.3.

The thing is, when I try to do the emerge, it tries to also merge ieee80211...But I want to use the in-kernel ieee80211..

Is there anything I'm missing?

Thanks in advance!

----------

## par4noia

Okay, so I used rmh3093's patch to 2.6.19 kernel and emerged ipw3945-ucode and ipw3945d...

Everything went fine, but when I try to modprobe ipw3945 I get the following error:

```
immega ~ # modprobe ipw3945

FATAL: Error inserting ipw3945 (/lib/modules/2.6.19-gentoo-r2/kernel/drivers/net/wireless/ipw3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)

 * WARNING:  ipw3945d has already been started.

```

What am I doing wrong?[/code]

----------

## Mickael

Just to say thank you rmh3093 for your patch. It 's worked very well with the 2.6.19-suspend2-r1. But for me, it was impossible to use the built in ieee80211, probably due to the fact that just before to apply your path, I emerged the ieee80211 and I applied the command which remove the modules inside the 2.6.19-suspend2-r1....

Thank you very much, and happy new year everybody  :Wink: 

----------

## fbcyborg

Hello, 

what should I do when I get this error message?

```
# iwconfig eth1 mode Master

Error for wireless request "Set Mode" (8B06) :

    SET failed on device eth1 ; Invalid argument.
```

----------

## Mickael

 *fbcyborg wrote:*   

> Hello, 
> 
> what should I do when I get this error message?
> 
> ```
> ...

 

hello, have you got an error inside /var/log/dmesg and/or message about ieee80211 and/or ipw3945...?

----------

## fbcyborg

These are the only messages I found on dmesg.

```
# dmesg |grep ieee80211

ieee80211_crypt: registered algorithm 'NULL'

ieee80211: 802.11 data/management/control stack, 1.2.15

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ieee80211_crypt: registered algorithm 'CCMP'

ieee80211_crypt: registered algorithm 'TKIP'

ieee80211_crypt: registered algorithm 'WEP'

```

```
# dmesg |grep ipw3945

ipw3945: no version for "ieee80211_wx_get_encodeext" found: kernel tainted.

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

```

----------

## Mickael

Are you sure your card supports master mode?

Read this, this is just an exemple.

EDIT : ipw3945: "no version for "ieee80211_wx_get_encodeext" found"

EDIT 2 : I 'have got this error too, but wifi works and i used the managed mode....

EDIT 3 : I found that  *Quote:*   

> 5.3.4. iwconfig mode
> 
> See iwconfig man page for general description.  
> 
> Current modes supported: Ad-Hoc and Managed (Auto)
> ...

  here : http://ipw3945.sourceforge.net/README.ipw3945

----------

## fbcyborg

Thank you.. I read all your links..

My Access Point is in Master Mode... (I don't know how can I change that Mode).

I think that in the past it was in Managed Mode. 

Using windows I have no problem.

The strange fact is that I could use my card until until 1 week before Christmas.

I don't know if it is the real problem, but it may be that Access point's Master Mode is the problem.

I think I can't set my eth1 in Managed mode... Why should it works??? Required mode is Master...

I hope I can change Operational Mode in my access point configuration, even though I already checked in it, but I didn't find any specific section.

----------

## VinzC

We have Linksys routers which are all configured in "master" mode. My laptop works perfectly with these - although I'm using rmh3093's patch for 2.6.18 series. As far as I can see mode Master is the AP access mode, which stands for "Access Point only", not "Bridge" nor "Ad-hoc". You could always try changing your router's access mode to make sure. Usually all you have to do is connect the router management interface with any web browser and change the settings there.

EDIT: It all means that even if your wireless access point is in master mode your wireless card may still work in managed mode without any problem. This is what I have.

----------

## rmh3093

for anyone having issues with the hardware kill switch not working..... i booted with the kernel options 'noapic nolapic' that seems to reset what ever stuck state the card gets into

----------

## rmh3093

New Driver Version: 1.2.0

Kernel Patch: http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.19.patch

Compat. Kernels: 2.6.19, 2.6.20-rc*, 2.6.20-rc*-mm*

----------

## VinzC

Man, you seem to be quite prolific!  :Wink:  Not even had time to test your previous patches there is a new one already...

----------

## Waninkoko

ipw3945 1.2.0 works really well. With older drivers I were having problems with slowdowns. Now my connection works fine  :Smile: 

----------

## fbcyborg

 *Waninkoko wrote:*   

> ipw3945 1.2.0 works really well. With older drivers I were having problems with slowdowns. Now my connection works fine 

 

I'm waiting for the portage release... now we're only up to 1.1.3 version.

----------

## Waninkoko

Damn! Bad news  :Sad:  I still have slowdowns. I'm very tired of this (the only solution to this is install udev-087 and coldplug). I'm gonna try ndiswrapper.

----------

## fbcyborg

I still have trouble only with wpa_supplicant. If i try to connect to an open AP (without encryption) I can get access to Internet, using wireless-tools.

----------

## Waninkoko

My problem is solved! Removing iptables from kernel  :Razz: 

----------

## RushPL

 *rmh3093 wrote:*   

> New Driver Version: 1.2.0
> 
> Kernel Patch: http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.19.patch
> 
> Compat. Kernels: 2.6.19, 2.6.20-rc*, 2.6.20-rc*-mm*

 

Ok,if this is 1.2, why does it say 1.1.3 in the included readme ? Ok, just in case it really is 1.2, should I unmerge my current ipw3945-1.1.3 ? Isn't it a dependency on ipw3945d ? Hope it's not a stupid problem, I haven't been really following this topic as a whole ...

Cheers.

----------

## fbcyborg

@Waninkoko: was your problem the same of mine?

I only have problem with wpa supplicant.. I doesn't work as before... I can't connect to a wpa protected w-lan.

----------

## Lloeki

with portage's 1.7.22-r4, ipw3945d init script always fails. starting it manually shows that it can't find pci connection, (whatever module version I use). ipw3945d 1.7.22-r3 always works. fwiw, I also fiddled with initscript hotplugging, but it does not change a thing.

----------

## Waninkoko

 *fbcyborg wrote:*   

> @Waninkoko: was your problem the same of mine?
> 
> I only have problem with wpa supplicant.. I doesn't work as before... I can't connect to a wpa protected w-lan.

 

My problem is that I have slowdowns when downloading files. The download starts fine and after some minutes it slowdowns to 100kb/s  :Sad: 

I thought that yesterday I resolved my problem but it appeared again  :Sad: 

----------

## rmh3093

 *RushPL wrote:*   

>  *rmh3093 wrote:*   New Driver Version: 1.2.0
> 
> Kernel Patch: http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.19.patch
> 
> Compat. Kernels: 2.6.19, 2.6.20-rc*, 2.6.20-rc*-mm* 
> ...

 

because I was lazy creating my patch and I only updated the ipw3945.c ipw3945.h & ipw3945_daemon.h

EDIT: i updated the ipw3945-1.2.0_for_2.6.19.patch to include the correct readme

----------

## rmh3093

 *Lloeki wrote:*   

> with portage's 1.7.22-r4, ipw3945d init script always fails. starting it manually shows that it can't find pci connection, (whatever module version I use). ipw3945d 1.7.22-r3 always works. fwiw, I also fiddled with initscript hotplugging, but it does not change a thing.

 

are you saying that when you modprobe the driver and then start ipw3945d that the daemon errors out because it cant find something /sys/bus/pci link? or does the daemon start but you get no wireless device? if its the latter try booting your computer with the kernel args 'noapic nolapic' once and see if that fixes your card

can you 'cat /sys/bus/pci/drivers/ipw3945/0*/rf_kill' ??? or does it say resource temporarily available?

----------

## Lloeki

 *Quote:*   

> [... I] modprobe the driver and then start ipw3945d [... then] the daemon errors out because it cant find something /sys/bus/pci link

 

I'll check rf_kill sysfs entry later on (with -r3 it's readable and returns 0)

EDIT: booting with 'noapic nolapic' does not change a thing (either once booted, or after reboot), but I wasn't exepecting it to change anything, since it was working in the first place with -r3. rf_kill is unavailable unless ipw3945d is started (whatever the version). reverted to -r3, and it's all fine: it started without a hitch, and rf_kill is readable.

----------

## rmh3093

 *Lloeki wrote:*   

>  *Quote:*   [... I] modprobe the driver and then start ipw3945d [... then] the daemon errors out because it cant find something /sys/bus/pci link 
> 
> I'll check rf_kill sysfs entry later on (with -r3 it's readable and returns 0)
> 
> EDIT: booting with 'noapic nolapic' does not change a thing (either once booted, or after reboot), but I wasn't exepecting it to change anything, since it was working in the first place with -r3. rf_kill is unavailable unless ipw3945d is started (whatever the version). reverted to -r3, and it's all fine: it started without a hitch, and rf_kill is readable.

 

see sometimes I start the daemon manually so the init script is pissing me off because of the permissions it sets... i unemerged the daemon and reinstalled it with out the ebuild and that stopped most of the other errors i've had with starting the daemon

----------

## Lloeki

well, the -r4 init script (obviously) says [!!], while the -r3 says [ok], but fails to result in anything useful (no led blink, no wlan0). after that (with -r3), trying to start ipw3945d results in pci connection error. then, rmmod ipw3945 && modprobe ipw3945 && ipw3945d works. I think it has to do with the permissions set here in the init script:

```
chown ipw3945d /sys/bus/pci/drivers/ipw3945/00*/cmd

chmod a-w,u+rw /sys/bus/pci/drivers/ipw3945/00*/cmd
```

EDIT: bingo! commented them, then, -r3 init script worked.

```
$ ls -l /sbin/ipw3945d 

-rwxr-xr-x 1 root root 74272 2007-01-07 15:14 /sbin/ipw3945d
```

hmm. I'll go check some more things.

----------

## rmh3093

 *Lloeki wrote:*   

> well, the -r4 init script (obviously) says [!!], while the -r3 says [ok], but fails to result in anything useful (no led blink, no wlan0). after that (with -r3), trying to start ipw3945d results in pci connection error. then, rmmod ipw3945 && modprobe ipw3945 && ipw3945d works. I think it has to do with the permissions set here in the init script:
> 
> ```
> chown ipw3945d /sys/bus/pci/drivers/ipw3945/00*/cmd
> 
> ...

 

yeah why they threw those permission things in there idk, the init script worked fine without them

----------

## Lloeki

oh, and 

```
$ ls -l /sys/bus/pci/drivers/ipw3945/00*/cmd 

-rw------- 1 root root 4096 2007-01-07 15:41 /sys/bus/pci/drivers/ipw3945/0000:0c:00.0/cmd

```

so it's the chown line...

well, I think it's because that way, you can start ipw3945d as non-root, and such, some suspected bug (like special packet forgery or whatever, we can't know, it's a blob afterall) in, it won't get root permission.

I think it's why -r4 sets suid permission on /sbin/ipw3945d... there's still some work to do there.

EDIT: I tried setting some suid things, altering permissions here and there, but no way: ipw3945d not root => ipw3945d fails (one time it even seemed it worked, but led never came up, and somehow it was not in process list). so I'll just have it starting as root, and care less about possible security issue.

----------

## Wojtek_

Could you please take a look at this thread:

https://forums.gentoo.org/viewtopic-t-530097-highlight-.html

cheers

Wojtek

----------

## rmh3093

 *Waninkoko wrote:*   

>  *fbcyborg wrote:*   @Waninkoko: was your problem the same of mine?
> 
> I only have problem with wpa supplicant.. I doesn't work as before... I can't connect to a wpa protected w-lan. 
> 
> My problem is that I have slowdowns when downloading files. The download starts fine and after some minutes it slowdowns to 100kb/s 
> ...

 

are you sure this isnt your ISPws fault? have you tried inter-LAN transfers?   do you have HPET and RTC enabled in your kernel? are you having IRQ conflicts? are there any errors in dmesg?

----------

## czarker

Sorry for bugging once more but I'm totally confused. I've got FSC laptop with 'kill switch on' situation, but my switching buttons (I've got on [Fn]+[F10] combination and a dedicated out-of-keyboard key) have no effect except for reporting errors to dmesg (unknown key code 0xd6).

Any ideas?

----------

## rmh3093

 *czarker wrote:*   

> Sorry for bugging once more but I'm totally confused. I've got FSC laptop with 'kill switch on' situation, but my switching buttons (I've got on [Fn]+[F10] combination and a dedicated out-of-keyboard key) have no effect except for reporting errors to dmesg (unknown key code 0xd6).
> 
> Any ideas?

 

i read somewhere that if you turn on the software kill switch and then toggle the hardware kill switch that the wireless card will not come back on... or that is one way to cause the "kill switch on" issue, another way i have found is by improper shutdowns (holding down the power button till the computer shuts down, or shutting down during boot)...

here are the possible outputs from "cat /sys/bus/pci/drivers/ipw3945/0*/rf_kill"

0 = no kill switch enabled (card should be working/visible to system, shows up with iwconfig)

1 = software kill switch enabled

2 = hardware kill switch enabled

3 = both kill switches enabled ( 1 + 2 = 3  :Wink:  )

the hardware switches are SUPPOSED to generate acpi events as well as proper keycodes but we all know that dosent happen all of time time, most of the time the key codes aren't recognized but the acpi events are still sent properly, you dont have to worry about the unknown keycode message, that has nothing to do with why the switch dosent work right... i think the hardware is suck

the ipw3945 first came out with the duo core laptops so I would assume most of us using the ipw3945 have smp enabled in our kernel which auto enables IOAPIC for better balancing of IRQs..... i am pretty sure the "rf kill switch" bug is a result of hung hardware in the ipw3945 somewhere, booting into windows once usually clears up the problem... but i also found booting linux once with 'noapic nolapic' also does the trick, i hope it works for you

----------

## czarker

 *rmh3093 wrote:*   

> here are the possible outputs from "cat /sys/bus/pci/drivers/ipw3945/0*/rf_kill"
> 
> 0 = no kill switch enabled (card should be working/visible to system, shows up with iwconfig)
> 
> 1 = software kill switch enabled
> ...

 When I tried "cat /sys/bus/pci/drivers/ipw3945/0*/rf_kill", I've got "resource not avaliable". Trying to "echo 0 > /sys/bus/pci/drivers/ipw3945/0*/rf_kill" kills the tty, while every next try to "cat /sys/bus/pci/drivers/ipw3945/0*/rf_kill" gives 0.

Still no new ethX devices appear.

 *rmh3093 wrote:*   

> but i also found booting linux once with 'noapic nolapic' also does the trick, i hope it works for you

 No effect, unfortunately.

Thank You.

----------

## axs

Somewhat off-topic, but somewhat related to the drivers -- Has anyone gotten ipw3945 to work nicely with netplug and rc?

Here's what i mean by 'nicely': (assume net.eth0 is wired, net.eth1 is ipw3945)

 - when net.eth0 is netplug-backgrounded, and net.eth1 is brought up by ipw3945d, the services that 'use net' are started

 - when the rf kill switch is flicked to turn off wireless radio, net.eth1 is brought down (and the services that 'use net' are stopped if net.eth0 is still down) and vice-versa (when wireless radio is enabled, net.eth1 should be started or at least restarted)

 - and possibly also, when net.eth0 is brought up then net.eth1/ipw3945d is taken down.

I've noticed that starting/stopping net.eth1 on my system is rather unreliable, and that the best method seems to be unloading ipw3945d -- however that technically isn't an interface and so the net scripts don't seem to work with it very well.

Does anyone know how to adjust the functionality of rc or ipw3945d to get this type of functionality?  I know somewhere something is telling net.eth1 to start when ipw3945d first starts, but i can't find where that is nor how i could adjust that behaviour..

----------

## rmh3093

 *axs wrote:*   

> Somewhat off-topic, but somewhat related to the drivers -- Has anyone gotten ipw3945 to work nicely with netplug and rc?
> 
> Here's what i mean by 'nicely': (assume net.eth0 is wired, net.eth1 is ipw3945)
> 
>  - when net.eth0 is netplug-backgrounded, and net.eth1 is brought up by ipw3945d, the services that 'use net' are started
> ...

 

i used to be a strict gentoo initscript fan but I have recently moved over to network manager and am loving it.... if you arent planning on doing anything too fancy right now with your wireless card (eg. bonding, bridging) then NetworkManger works great, it does just what you want... it defaults to using wireless and when you plug in a network cable it trys to connect to the wired... i havent had any issues with the ipw3945d or the kill switch using NetworkManager

----------

## Hanoc

hi,

I haven't solved my problem yet so I was looking forward to this new relase of the driver to see if it get solved by itself...

unfortunatelly it hasn't but I think I'm lost and messed up.

I don't want to distract you with problems that are already solved... but I can't get things clear reading this thread... so I have a plead to made...

is this documentation valid still?

http://gentoo-wiki.com/HARDWARE_ipw3945

I think it isn't because  ieee80211 requires some modules not to be load nor present in the kernel and ipw3945 requires them.

I can post output of both things but I think it won't be necessary because maybe it's a known thing that this configuration does not work

I think I'm working with excluding packages here... so if anyone can point me in the right direction or even update de wiki (if it's outdated of course) I'll start the process from the beginning and then bother you with my problems if necessary.

Thanks!

----------

## axs

Hanoc, what versions of the packages are you using, and what kernel?  from the Changelog it seems that ipw3945-1.1.3-r1 and above now uses in-kernel ieee80211, and so the stuff on the wiki would not be valid wrt. that part...

----------

## Hanoc

ok... as I suspected the wiki is outdated in my case:

 *Quote:*   

> # emerge -av ipw3945 ipw3945d
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> ...

 

I use 1.1.3-r1.

And if it uses the inkernel drivers it makes so much sense.

I had trouble anyway... but trying to fix them I broken the inkernel modules... so I'll everything from the start and post the results.

Thanks.

----------

## Hanoc

I'm not able to compile the ieee8 drivers in the kernel with the following options in my config file:

```
# grep  ieee8 .config -i

CONFIG_IEEE80211=y

CONFIG_IEEE80211_DEBUG=y

CONFIG_IEEE80211_CRYPT_WEP=y

CONFIG_IEEE80211_CRYPT_CCMP=y

CONFIG_IEEE80211_CRYPT_TKIP=y
```

I get that error:

```
make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.o', needed by `net/ieee80211/ieee80211.o'.  Stop.

make[1]: *** [net/ieee80211] Error 2

make: *** [net] Error 2

```

I know this is not exactly the place where this should go... but I can't move forward if I can't compile the drivers into the module provided that ipw3945 request them to be there.

Trying to compile them as modules encountered exactly the same error... wich puzzles me a little:

here's the code:

```

root@strelka:/usr/src/linux# grep  ieee8 .config -i

CONFIG_IEEE80211=m

CONFIG_IEEE80211_DEBUG=y

CONFIG_IEEE80211_CRYPT_WEP=m

CONFIG_IEEE80211_CRYPT_CCMP=m

CONFIG_IEEE80211_CRYPT_TKIP=m

# CONFIG_IEEE80211_SOFTMAC is not set

root@strelka:/usr/src/linux# make all

scripts/kconfig/conf -s arch/i386/Kconfig

  CHK     include/linux/version.h

  CHK     include/linux/utsrelease.h

  CHK     include/linux/compile.h

  GZIP    kernel/config_data.gz

  IKCFG   kernel/config_data.h

  CC      kernel/configs.o

  LD      kernel/built-in.o

make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.o', needed by `net/ieee80211/ieee80211.o'.  Stop.

make[1]: *** [net/ieee80211] Error 2

make: *** [net] Error 2

```

I hope the information I'm providing is the correct one.... if it isn't I'll post whatever is needed gladly!

thanks!

----------

## holycow

I've been trying to upgrade ipw3945d to 1.7.22-r4 (from 1.7.22-r3) and I'm getting a sandbox access denied error from the ebuild attempting to chmod the /sbin/ipw3945d binary. I've searched bugszilla and the forums and didn't see any references to this.

Here's a partial output of my attempted emerge:

```

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/net-wireless/ipw3945d-1.7.22-r4/work/ipw3945d-1.7.22 ...

>>> Source compiled.

>>> Test phase [not enabled]: net-wireless/ipw3945d-1.7.22-r4

>>> Install ipw3945d-1.7.22-r4 into /var/tmp/portage/net-wireless/ipw3945d-1.7.22-r4/image/ category net-wireless

ACCESS DENIED  chmod:     /sbin/ipw3945d

chmod: changing permissions of `/sbin/ipw3945d': Permission denied

>>> Completed installing ipw3945d-1.7.22-r4 into /var/tmp/portage/net-wireless/ipw3945d-1.7.22-r4/image/

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------

LOG FILE = "/var/log/sandbox/sandbox-net-wireless_-_ipw3945d-1.7.22-r4-15911.log"

chmod:     /sbin/ipw3945d

--------------------------------------------------------------------------------

```

I am running the emerge as root, btw.

----------

## jekyll

 *holycow wrote:*   

> I've been trying to upgrade ipw3945d to 1.7.22-r4 (from 1.7.22-r3) and I'm getting a sandbox access denied error from the ebuild attempting to chmod the /sbin/ipw3945d binary. I've searched bugszilla and the forums and didn't see any references to this.
> 
> Here's a partial output of my attempted emerge:
> 
> ```
> ...

 

If you uninstall it first with emerge -C ipw3945d, then install (emerge ipw3945d), no violation takes place.

-jekyll

----------

## jekyll

 *Hanoc wrote:*   

> I'm not able to compile the ieee8 drivers in the kernel with the following options in my config file:
> 
> ```
> # grep  ieee8 .config -i
> 
> ...

 

If you installed a version of ipw3945 prior to version 1.1.3-r2, then emerge instructed you to manually remove the generic ieee80211 code in the kernel (in order to emerge the package ieee80211).  If you are upgrading to 1.1.3-r2, the package ieee80211 is no longer needed, and the generic 80211 kernel sources are used instead.  Emerge the kernel sources again (emerge gentoo-sources) and then you can compile the ieee80211 modules (or built in).

-jekyll

----------

## jtp755

i was gonna start another thread to clear up some things but why when i know the answers are here somewhere and hopefully someone will reply with them.

i am running gentoo-sources-2.6.19-r3 with ieee80211 compiled in the kernel staticlly (not as modules). i have emerged ipw3945d-1.7.22-r4, ipw3945-ucode-1.13,and ipw3945-1.1.3-r2. Im basically getting no where. eth1 isnt getting created. where should i start? after the above i know can cat /sys/bus/pci/ipw3945/00*/rf_kill but i get Resource Temporarily Unavailable.

[edit] So i was tryin everything i have read AGAIN and i was like i know its a permissions issue. I tired emerging ipw3945d-1.77.2-r4 again and forgot about the Sandbox violation and it stops on chmodding /sbin/ipw3945d so i was like screw it...it cant hurt anything and i did chmod 777 /sbin/ipw3945d and hit my hotkeys for the wireless and boom...working wireless with WEP association and all. So any ideas on what to do to fix it now?

----------

## jekyll

 *jtp755 wrote:*   

> i was gonna start another thread to clear up some things but why when i know the answers are here somewhere and hopefully someone will reply with them.
> 
> i am running gentoo-sources-2.6.19-r3 with ieee80211 compiled in the kernel staticlly (not as modules). i have emerged ipw3945d-1.7.22-r4, ipw3945-ucode-1.13,and ipw3945-1.1.3-r2. Im basically getting no where. eth1 isnt getting created. where should i start? after the above i know can cat /sys/bus/pci/ipw3945/00*/rf_kill but i get Resource Temporarily Unavailable.
> 
> [edit] So i was tryin everything i have read AGAIN and i was like i know its a permissions issue. I tired emerging ipw3945d-1.77.2-r4 again and forgot about the Sandbox violation and it stops on chmodding /sbin/ipw3945d so i was like screw it...it cant hurt anything and i did chmod 777 /sbin/ipw3945d and hit my hotkeys for the wireless and boom...working wireless with WEP association and all. So any ideas on what to do to fix it now?

 

Read the thread https://forums.gentoo.org/viewtopic-t-530426.html.  It may solve your problem.  I have exactly the same stuff installed that you have and mine works after deleting two lines from /etc/init.d/ipw3945d (and adding a sleep line).

-jekyll

----------

## jtp755

thanks for that link...i had forgotten about it...i had tried it before but things were really messed up so it didnt affect it. 

It did fix my problem though. The only thing i dont like is it takes a lil while about a min or so to start the wireless but i think that has to do with the sleep thing. but it works so its all good!

Did you change anything in /etc/conf.d/ipw3945d?

Will downgrading udev-103 to the latest 087 version make a difference? with 103 my dvdrw wont play cds/dvds or anything correctly.

----------

## beatryder

 *jtp755 wrote:*   

> thanks for that link...i had forgotten about it...i had tried it before but things were really messed up so it didnt affect it. 
> 
> It did fix my problem though. The only thing i dont like is it takes a lil while about a min or so to start the wireless but i think that has to do with the sleep thing. but it works so its all good!
> 
> Did you change anything in /etc/conf.d/ipw3945d?
> ...

 

I would try 

```
emerge -C ipw3945d && emerge ipe3945d
```

 That worked for me. I don't have the the sleep 0.5 in my init script either.

----------

## jtp755

im not messing with my wireless drivers  :Razz:  ... they are working so im not touching them. the problem with the dvd was because when i recompiled my kernel i forgot to recompile my ati-drivers (smart me) and it wasnt loading fglrx and i recompiled them and restarted Xorg and boom it works great. thanks for all the help tho...ill keep a check on here to see how the drivers are going..

----------

## fbcyborg

I solved all my problems downgrading to stable packages:

```
[ebuild     UD] net-wireless/ieee80211-1.1.13-r1 [1.2.15] USE="-debug" 0 kB

[ebuild     UD] net-wireless/ipw3945-1.1.0-r1 [1.1.3] USE="-debug" 191 kB 
```

have a look here.

There's a lot of masked packages.

----------

## par4noia

Okay, so this is kinda strange...

Everything was working fine with 2.6.29-r2 kernel, including WPA...But I recently did a emerge world, and it installed a lot of things, including kernel 2.6.19-r3, and now WPA doesn't work!

It connects to the right AP, and I get an encryption key. So far so good, but then I lose the connection...And I can't get an IP..

any ideas?

----------

## par4noia

Okay, I just got it working!  :Very Happy: 

Also, with 2.6.19-r4 kernel I wasn't even getting an Encryption Key...So that might be a problem with either the kernel, or with the patch, cause I used rmh3093's 1.2.0 patch for that, and now I'm using 1.1.2 again.

----------

## Wojtek_

Each time I try to emerge ipw3945-1.2.0 I get:

```

* Checking for suitable kernel configuration options...

 *   ipw3945-1.2.0 requires support for Generic IEEE 802.11 Networking Stack (CONFIG_IEEE80211).

 *   CONFIG_IEEE80211_CRYPT_CCMP:        is not set when it should be.

 *   CONFIG_IEEE80211_CRYPT_TKIP:        is not set when it should be.

 * Please check to make sure these options are set correctly.

 * Failure to do so may cause unexpected problems.

 * Once you have satisfied these options, please try merging

 * this package again.

!!! ERROR: net-wireless/ipw3945-1.2.0 failed.

Call stack:

  ebuild.sh, line 1629:   Called dyn_setup

  ebuild.sh, line 701:   Called qa_call 'pkg_setup'

  ebuild.sh, line 38:   Called pkg_setup

  ipw3945-1.2.0.ebuild, line 39:   Called linux-mod_pkg_setup

  linux-mod.eclass, line 458:   Called linux-info_pkg_setup

  linux-info.eclass, line 572:   Called check_extra_config

  linux-info.eclass, line 471:   Called die

!!! Incorrect kernel configuration options

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/net-wireless/ipw3945-1.2.0/temp/build.log'.

```

Has anyone encountered anything similar?

Cheers,

Wojtek

----------

## Hanoc

I've got exactly the same error trying to emerge the 1.2.0 version.

Unfortunatelly I switched to ubuntu because of my inhability to get the wifi working... I have the gentoo system instaled so If you think we can work something out I'll try to boot into it.

I wish you (us) good luck!

----------

## beatryder

I am having issues with the new drivers as well. For some reason I have to remove and reinsert the module every time i boot in order to get it to work right...

----------

## Lloeki

argh.

for no apparent reason, I now get TKIP replays randomly, forcing wpa_supplicant to reassociate.

it seems to happen once in a while, maybe when the card went idling and a tcp connection suddently pops in.

my gf's lappy+ipw3945 doesn't suffer from this.

upgraded both microcode and module to latest, plus kernel to 2.6.19, but same behavior.

I'd try to disable some form of powermanagement for the card, and see if it helps. anyone know where I could change that?

----------

## VinzC

 *Lloeki wrote:*   

> upgraded both microcode and module to latest, plus kernel to 2.6.19, but same behavior.

 

I tried to apply TKIP patch (as I always did with previous kernels) but almost all hunks failed. So I guessed the patch was already applied somehow - but I didn't check any further.

```
diff -urp old/net/ieee80211/ieee80211_crypt_tkip.c new/net/ieee80211/ieee80211_crypt_tkip.c

--- old/net/ieee80211/ieee80211_crypt_tkip.c   2006-06-12 14:08:02.000000000 +0800

+++ new/net/ieee80211/ieee80211_crypt_tkip.c   2006-08-02 13:44:29.000000000 +0800

@@ -53,8 +53,10 @@ struct ieee80211_tkip_data {

 

    int key_idx;

 

-   struct crypto_tfm *tfm_arc4;

-   struct crypto_tfm *tfm_michael;

+   struct crypto_tfm *tx_tfm_arc4;

+   struct crypto_tfm *tx_tfm_michael;

+   struct crypto_tfm *rx_tfm_arc4;

+   struct crypto_tfm *rx_tfm_michael;

 

    /* scratch buffers for virt_to_page() (crypto API) */

    u8 rx_hdr[16], tx_hdr[16];

@@ -86,15 +88,29 @@ static void *ieee80211_tkip_init(int key

 

    priv->key_idx = key_idx;

 

-   priv->tfm_arc4 = crypto_alloc_tfm("arc4", 0);

-   if (priv->tfm_arc4 == NULL) {

+   priv->tx_tfm_arc4 = crypto_alloc_tfm("arc4", 0);

+   if (priv->tx_tfm_arc4 == NULL) {

       printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "

              "crypto API arc4\n");

       goto fail;

    }

 

-   priv->tfm_michael = crypto_alloc_tfm("michael_mic", 0);

-   if (priv->tfm_michael == NULL) {

+   priv->tx_tfm_michael = crypto_alloc_tfm("michael_mic", 0);

+   if (priv->tx_tfm_michael == NULL) {

+      printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "

+             "crypto API michael_mic\n");

+      goto fail;

+   }

+

+   priv->rx_tfm_arc4 = crypto_alloc_tfm("arc4", 0);

+   if (priv->rx_tfm_arc4 == NULL) {

+      printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "

+             "crypto API arc4\n");

+      goto fail;

+   }

+

+   priv->rx_tfm_michael = crypto_alloc_tfm("michael_mic", 0);

+   if (priv->rx_tfm_michael == NULL) {

       printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "

              "crypto API michael_mic\n");

       goto fail;

@@ -104,10 +120,14 @@ static void *ieee80211_tkip_init(int key

 

       fail:

    if (priv) {

-      if (priv->tfm_michael)

-         crypto_free_tfm(priv->tfm_michael);

-      if (priv->tfm_arc4)

-         crypto_free_tfm(priv->tfm_arc4);

+      if (priv->tx_tfm_michael)

+         crypto_free_tfm(priv->tx_tfm_michael);

+      if (priv->tx_tfm_arc4)

+         crypto_free_tfm(priv->tx_tfm_arc4);

+      if (priv->rx_tfm_michael)

+         crypto_free_tfm(priv->rx_tfm_michael);

+      if (priv->rx_tfm_arc4)

+         crypto_free_tfm(priv->rx_tfm_arc4);

       kfree(priv);

    }

 

@@ -117,10 +137,16 @@ static void *ieee80211_tkip_init(int key

 static void ieee80211_tkip_deinit(void *priv)

 {

    struct ieee80211_tkip_data *_priv = priv;

-   if (_priv && _priv->tfm_michael)

-      crypto_free_tfm(_priv->tfm_michael);

-   if (_priv && _priv->tfm_arc4)

-      crypto_free_tfm(_priv->tfm_arc4);

+   if (_priv) {

+      if (_priv->tx_tfm_michael)

+         crypto_free_tfm(_priv->tx_tfm_michael);

+      if (_priv->tx_tfm_arc4)

+         crypto_free_tfm(_priv->tx_tfm_arc4);

+      if (_priv->rx_tfm_michael)

+         crypto_free_tfm(_priv->rx_tfm_michael);

+      if (_priv->rx_tfm_arc4)

+         crypto_free_tfm(_priv->rx_tfm_arc4);

+   }

    kfree(priv);

 }

 

@@ -352,11 +378,11 @@ static int ieee80211_tkip_encrypt(struct

    icv[2] = crc >> 16;

    icv[3] = crc >> 24;

 

-   crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16);

+   crypto_cipher_setkey(tkey->tx_tfm_arc4, rc4key, 16);

    sg.page = virt_to_page(pos);

    sg.offset = offset_in_page(pos);

    sg.length = len + 4;

-   crypto_cipher_encrypt(tkey->tfm_arc4, &sg, &sg, len + 4);

+   crypto_cipher_encrypt(tkey->tx_tfm_arc4, &sg, &sg, len + 4);

 

    return 0;

 }

@@ -447,11 +473,11 @@ static int ieee80211_tkip_decrypt(struct

 

    plen = skb->len - hdr_len - 12;

 

-   crypto_cipher_setkey(tkey->tfm_arc4, rc4key, 16);

+   crypto_cipher_setkey(tkey->rx_tfm_arc4, rc4key, 16);

    sg.page = virt_to_page(pos);

    sg.offset = offset_in_page(pos);

    sg.length = plen + 4;

-   crypto_cipher_decrypt(tkey->tfm_arc4, &sg, &sg, plen + 4);

+   crypto_cipher_decrypt(tkey->rx_tfm_arc4, &sg, &sg, plen + 4);

 

    crc = ~crc32_le(~0, pos, plen);

    icv[0] = crc;

@@ -485,12 +511,12 @@ static int ieee80211_tkip_decrypt(struct

    return keyidx;

 }

 

-static int michael_mic(struct ieee80211_tkip_data *tkey, u8 * key, u8 * hdr,

+static int michael_mic(struct crypto_tfm *tfm_michael, u8 * key, u8 * hdr,

              u8 * data, size_t data_len, u8 * mic)

 {

    struct scatterlist sg[2];

 

-   if (tkey->tfm_michael == NULL) {

+   if (tfm_michael == NULL) {

       printk(KERN_WARNING "michael_mic: tfm_michael == NULL\n");

       return -1;

    }

@@ -502,10 +528,10 @@ static int michael_mic(struct ieee80211_

    sg[1].offset = offset_in_page(data);

    sg[1].length = data_len;

 

-   crypto_digest_init(tkey->tfm_michael);

-   crypto_digest_setkey(tkey->tfm_michael, key, 8);

-   crypto_digest_update(tkey->tfm_michael, sg, 2);

-   crypto_digest_final(tkey->tfm_michael, mic);

+   crypto_digest_init(tfm_michael);

+   crypto_digest_setkey(tfm_michael, key, 8);

+   crypto_digest_update(tfm_michael, sg, 2);

+   crypto_digest_final(tfm_michael, mic);

 

    return 0;

 }

@@ -563,7 +589,7 @@ static int ieee80211_michael_mic_add(str

 

    michael_mic_hdr(skb, tkey->tx_hdr);

    pos = skb_put(skb, 8);

-   if (michael_mic(tkey, &tkey->key[16], tkey->tx_hdr,

+   if (michael_mic(tkey->tx_tfm_michael, &tkey->key[16], tkey->tx_hdr,

          skb->data + hdr_len, skb->len - 8 - hdr_len, pos))

       return -1;

 

@@ -625,7 +651,7 @@ static int ieee80211_michael_mic_verify(

       return -1;

 

    michael_mic_hdr(skb, tkey->rx_hdr);

-   if (michael_mic(tkey, &tkey->key[24], tkey->rx_hdr,

+   if (michael_mic(tkey->rx_tfm_michael, &tkey->key[24], tkey->rx_hdr,

          skb->data + hdr_len, skb->len - 8 - hdr_len, mic))

       return -1;

    if (memcmp(mic, skb->data + skb->len - 8, 8) != 0) {

@@ -655,14 +681,18 @@ static int ieee80211_tkip_set_key(void *

 {

    struct ieee80211_tkip_data *tkey = priv;

    int keyidx;

-   struct crypto_tfm *tfm = tkey->tfm_michael;

-   struct crypto_tfm *tfm2 = tkey->tfm_arc4;

+   struct crypto_tfm *tfm = tkey->tx_tfm_michael;

+   struct crypto_tfm *tfm2 = tkey->tx_tfm_arc4;

+   struct crypto_tfm *tfm3 = tkey->rx_tfm_michael;

+   struct crypto_tfm *tfm4 = tkey->rx_tfm_arc4;

 

    keyidx = tkey->key_idx;

    memset(tkey, 0, sizeof(*tkey));

    tkey->key_idx = keyidx;

-   tkey->tfm_michael = tfm;

-   tkey->tfm_arc4 = tfm2;

+   tkey->tx_tfm_michael = tfm;

+   tkey->tx_tfm_arc4 = tfm2;

+   tkey->rx_tfm_michael = tfm3;

+   tkey->rx_tfm_arc4 = tfm4;

    if (len == TKIP_KEY_LEN) {

       memcpy(tkey->key, key, TKIP_KEY_LEN);

       tkey->key_set = 1;

diff -urp old/net/ieee80211/ieee80211_crypt_wep.c new/net/ieee80211/ieee80211_crypt_wep.c

--- old/net/ieee80211/ieee80211_crypt_wep.c   2006-06-12 14:08:02.000000000 +0800

+++ new/net/ieee80211/ieee80211_crypt_wep.c   2006-08-02 11:50:59.000000000 +0800

@@ -33,7 +33,8 @@ struct prism2_wep_data {

    u8 key[WEP_KEY_LEN + 1];

    u8 key_len;

    u8 key_idx;

-   struct crypto_tfm *tfm;

+   struct crypto_tfm *tx_tfm;

+   struct crypto_tfm *rx_tfm;

 };

 

 static void *prism2_wep_init(int keyidx)

@@ -46,13 +47,19 @@ static void *prism2_wep_init(int keyidx)

    memset(priv, 0, sizeof(*priv));

    priv->key_idx = keyidx;

 

-   priv->tfm = crypto_alloc_tfm("arc4", 0);

-   if (priv->tfm == NULL) {

+   priv->tx_tfm = crypto_alloc_tfm("arc4", 0);

+   if (priv->tx_tfm == NULL) {

       printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate "

              "crypto API arc4\n");

       goto fail;

    }

 

+   priv->rx_tfm = crypto_alloc_tfm("arc4", 0);

+   if (priv->rx_tfm == NULL) {

+      printk(KERN_DEBUG "ieee80211_crypt_wep: could not allocate "

+             "crypto API arc4\n");

+      goto fail;

+   }

    /* start WEP IV from a random value */

    get_random_bytes(&priv->iv, 4);

 

@@ -60,8 +67,10 @@ static void *prism2_wep_init(int keyidx)

 

       fail:

    if (priv) {

-      if (priv->tfm)

-         crypto_free_tfm(priv->tfm);

+      if (priv->tx_tfm)

+         crypto_free_tfm(priv->tx_tfm);

+      if (priv->rx_tfm)

+         crypto_free_tfm(priv->rx_tfm);

       kfree(priv);

    }

    return NULL;

@@ -70,8 +79,12 @@ static void *prism2_wep_init(int keyidx)

 static void prism2_wep_deinit(void *priv)

 {

    struct prism2_wep_data *_priv = priv;

-   if (_priv && _priv->tfm)

-      crypto_free_tfm(_priv->tfm);

+   if (_priv) {

+      if (_priv->tx_tfm)

+         crypto_free_tfm(_priv->tx_tfm);

+      if (_priv->rx_tfm)

+         crypto_free_tfm(_priv->rx_tfm);

+   }

    kfree(priv);

 }

 

@@ -153,11 +166,11 @@ static int prism2_wep_encrypt(struct sk_

    icv[2] = crc >> 16;

    icv[3] = crc >> 24;

 

-   crypto_cipher_setkey(wep->tfm, key, klen);

+   crypto_cipher_setkey(wep->tx_tfm, key, klen);

    sg.page = virt_to_page(pos);

    sg.offset = offset_in_page(pos);

    sg.length = len + 4;

-   crypto_cipher_encrypt(wep->tfm, &sg, &sg, len + 4);

+   crypto_cipher_encrypt(wep->tx_tfm, &sg, &sg, len + 4);

 

    return 0;

 }

@@ -196,11 +209,11 @@ static int prism2_wep_decrypt(struct sk_

    /* Apply RC4 to data and compute CRC32 over decrypted data */

    plen = skb->len - hdr_len - 8;

 

-   crypto_cipher_setkey(wep->tfm, key, klen);

+   crypto_cipher_setkey(wep->rx_tfm, key, klen);

    sg.page = virt_to_page(pos);

    sg.offset = offset_in_page(pos);

    sg.length = plen + 4;

-   crypto_cipher_decrypt(wep->tfm, &sg, &sg, plen + 4);

+   crypto_cipher_decrypt(wep->rx_tfm, &sg, &sg, plen + 4);

 

    crc = ~crc32_le(~0, pos, plen);

    icv[0] = crc;
```

I expect the same patch in an up-to-date version. Note I'm using rmh3093's patch for 2.6.19, ipw3945-1.2.0_for_2.6.19.patch.

----------

## fbcyborg

 *Wojtek_ wrote:*   

> Each time I try to emerge ipw3945-1.2.0 I get:
> 
> ```
> 
> * Checking for suitable kernel configuration options...
> ...

 

Hello, 

it's quite simple.

You've to recompile the kernel whit that options built in. Or as alternative, try to emerge ieee80211.

Probably emerge will tell you that you have to manually remove ieee80211 driver from the kernel tree.

The command will be suggested to you.

----------

## VinzC

 *fbcyborg wrote:*   

> You've to recompile the kernel whit that options built in. Or as alternative, try to emerge ieee80211.
> 
> Probably emerge will tell you that you have to manually remove ieee80211 driver from the kernel tree.
> 
> The command will be suggested to you.

 

I'd say if you use rmh3093's patch (hence built-in ipw3945 driver) you should use built-in IEEE802.11 stack. After all that's mainly the reason he made it (I presume). Portage's version introduces unwanted dependencies and nasty actions to the kernel (aka manually rm ieee80211 files each time you tweak your kernel config).

----------

## fbcyborg

I didn't apply any patch. It isn't necessary, in my opinion.

I'm using gentoo-sources.

----------

## schiotz

 *Quote:*   

> I'd say if you use rmh3093's patch (hence built-in ipw3945 driver) you should use built-in IEEE802.11 stack. After all that's mainly the reason he made it (I presume). Portage's version introduces unwanted dependencies and nasty actions to the kernel (aka manually rm ieee80211 files each time you tweak your kernel config).

 

The hard-masked version 1.1.3-r2 use the built-in ieee802.11 stack, much less trouble when recompiling the kernel.  I use this version on my laptop, it works fine (I chose that version because all versions are hardmasked on amd64, so I chose the newest).

/Jakob

----------

## Lloeki

 *Quote:*   

> I tried to apply TKIP patch...

 

yes, 2.6.19 kernel's stack seems to be up to date. my 2.6.18 was patched with the TKIP patch, then I used 1.1.3+portage latest ieee80211 (which is fixed too), but suffered from aforementioned replays. note that those replays are different though: this does not occur on heavy transfers, nor there is any mickael mic digest failing.

 *Quote:*   

> Or as alternative, try to emerge ieee80211. Probably emerge will tell you that you have to manually remove ieee80211 driver from the kernel tree. 
> 
> 

 

not anymore. portage latest ipw3945-1.2.0 does not require any nasty things like before, just get rid of portage 80211 stack, and compile the kernel one. it also compiles just fine against 2.6.19.

I still have to check if those replay troubles are related to my AP, but this seems unlikely since the other laptop does not suffer from it.

----------

## grantonstar

Hi everyone,

I'm trying to get the ipw3945 driver working on kernel 2.6.20.

I have compiled the following into the kernel:

Device Drivers -->

Network device support -->

Wireless LAN (non-hamradio) -->

Wireless LAN drivers (non-hamradio) & Wireless Extensions -->

Wireless Extensions

Networking --->

<*>   Generic IEEE 802.11 Networking Stack 

    [ ]     Enable full debugging output

    <*>     IEEE 802.11 WEP encryption (802.1x)

    <*>     IEEE 802.11i CCMP support

    <*>     IEEE 802.11i TKIP encryption

    < >     Software MAC add-on to the IEEE 802.11 networking stack

(as per the howto)

I get no errors during the compilation process. I then try and do a module-rebuild and get the following warnings:

 * Updating module dependencies for 2.6.20-gentoo ...

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_ccmp.ko needs unknown symbol offset_in_page

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_update

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_final

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_setkey

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_init

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol offset_in_page

WARNING: //lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_wep.ko needs unknown symbol offset_in_page          [ ok ]

Then I do the following (after a reboot)

emerge -av ipw3945 wireless-tools wpa_supplicant

Followed by:

localhost ~ # modprobe ipw3945

WARNING: Error inserting ieee80211_crypt (/lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt.ko): Invalid module format

WARNING: Error inserting ieee80211 (/lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211.ko): Unknown symbol in module, or unknown parameter (see dmesg)

dmesg reports:

ieee80211_crypt: exports duplicate symbol ieee80211_crypt_deinit_entries (owned by kernel)

ieee80211: disagrees about version of symbol ieee80211_get_crypto_ops

ieee80211: Unknown symbol ieee80211_get_crypto_ops

ieee80211: disagrees about version of symbol ieee80211_crypt_deinit_entries

ieee80211: Unknown symbol ieee80211_crypt_deinit_entries

ieee80211: disagrees about version of symbol ieee80211_crypt_delayed_deinit

ieee80211: Unknown symbol ieee80211_crypt_delayed_deinit

ieee80211: disagrees about version of symbol ieee80211_crypt_quiescing

ieee80211: Unknown symbol ieee80211_crypt_quiescing

ieee80211_crypt: exports duplicate symbol ieee80211_crypt_deinit_entries (owned by kernel)

ieee80211: disagrees about version of symbol ieee80211_get_crypto_ops

ieee80211: Unknown symbol ieee80211_get_crypto_ops

ieee80211: disagrees about version of symbol ieee80211_crypt_deinit_entries

ieee80211: Unknown symbol ieee80211_crypt_deinit_entries

ieee80211: disagrees about version of symbol ieee80211_crypt_delayed_deinit

ieee80211: Unknown symbol ieee80211_crypt_delayed_deinit

ieee80211: disagrees about version of symbol ieee80211_crypt_quiescing

ieee80211: Unknown symbol ieee80211_crypt_quiescing

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

I've tried module-rebuild etc and get the same every time.

Any idea on what causes these warnings/errors and what it will have an effect on because it does seem like the hardware is detected?

Thankyou,

grantonstar

----------

## VinzC

@grantonstar,

```
localhost ~ # modprobe ipw3945

WARNING: Error inserting ieee80211_crypt (/lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt.ko): Invalid module format

WARNING: Error inserting ieee80211 (/lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211.ko): Unknown symbol in module, or unknown parameter (see dmesg)
```

Make sure:you compiled your kernel and all your modules with the same version of GCC;

you selected the appropriate CPU features in your kernel configuration;

you're only using safe CFLAGS.

----------

## grantonstar

VinzC,

Thanks for answering my request for help..

In answer to your questions:

    * you compiled your kernel and all your modules with the same version of GCC;

This is definitely the case.

    * you selected the appropriate CPU features in your kernel configuration;

I am using a Core 2 Duo and have selected the Core2 as the architecture and disabled HyperThreading. Other than that, everything is the default.

    * you're only using safe CFLAGS.

I changed my CFLAGS to those recommended for Core 2 Duo as safe on the Gentoo wiki and then did an "emerge -e system && emerge -e system". The kernel has been compiled and recomiled using these same CFLAGS.

I am aware that some people recommend a "emerge -e world && emerge -e world" to recompile all the packages with the new CFLAGS but seen as I only changed the CFLAGS and not the CHOST I was under the impression that this was optional and wouldn't cause these kinds of problems.

Thanks,

grantonstar

----------

## VinzC

 *grantonstar wrote:*   

> [...]
> 
> I am aware that some people recommend a "emerge -e world && emerge -e world" to recompile all the packages with the new CFLAGS but seen as I only changed the CFLAGS and not the CHOST I was under the impression that this was optional and wouldn't cause these kinds of problems.
> 
> Thanks,
> ...

 

Ok, now we're sure your compiler and system is compiled in a consistent way, let's go one step further  :Wink:  . Did you (by chance) just once, emerge portage's ieee80211? It can mess up with the kernel just once installed. So the best action is to clean the whole kernel source tree, rm -r it and redo it all over again (save your .config file beforehand of course). That's what I once had to do because of numerous crashes, random lockups and compilation woes.

You might also want to consider rmh3093 ipw3945 patches for kernels 2.6.19 and 2.6.20. They were discussed on page 24.

----------

## rmh3093

where did this "tkip patch" come from... it its not already in a vanilla or -mm I will keep the patch up to date

----------

## Lloeki

this 'tkip patch' fixed a bug in the 80211 subsystem, I described it earlier (by many pages) in this thread. it happens on heavy data transfers, where you would get lots of tkip replay, ending with a michael mic digest failure. both wep and wpa were affected, but the 'workaround' patch only covered tkip.

the bug is definitely fixed in 80211 >=1.2.15 and appears to be fixed too in kernel >=2.6.19

----------

## VinzC

 *rmh3093 wrote:*   

> where did this "tkip patch" come from... 

 

<search mode="backtracking">

See Lloeki's post (on page 16). He references this page, which has a (well hidden) link to the patch.

</search>

 :Smile: 

----------

## rmh3093

 *Lloeki wrote:*   

> this 'tkip patch' fixed a bug in the 80211 subsystem, I described it earlier (by many pages) in this thread. it happens on heavy data transfers, where you would get lots of tkip replay, ending with a michael mic digest failure. both wep and wpa were affected, but the 'workaround' patch only covered tkip.
> 
> the bug is definitely fixed in 80211 >=1.2.15 and appears to be fixed too in kernel >=2.6.19

 

ahh so this dosent apply to me.... im using a -mm based kernel

----------

## grantonstar

VinzC,

Yes, I had previously tried compiling the 80211 subsystem as a module so I did what you said and wiped away /usr/src/linux and then re-emerged it and compiled again (this time trying with and without the patch you mention).

Unfortunately, I am getting the exact same warnings as before. Looking at the re-compiling of the ipw3945 module it says:

 * Preparing ipw3945 module

 Using ieee80211 subsystem version API v2 from:

        Base: /usr/src/linux/

        Path: /usr/src/linux/include/

 EXTRA_CFLAGS = -I/usr/src/linux/include/ -DIPW3945_COMPAT=2 -g -Wa,-adhlms=check_inc.lst

Which seems to be getting the 80211 subsystem from the correct place (not sure about the GCC flags though). The relevant settings in my make.conf are:

CFLAGS="-march=nocona -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j3"

I just realised I'm getting the same "invalid module format" error with alsa too. I don't think it makes a difference but I am using the 64bit kernel. I'm also using the nvidia drivers without any trouble though this does come up during the compile process:

        echo;                                                           \

        echo "  ERROR: Kernel configuration is invalid.";               \

        echo "         include/linux/autoconf.h or include/config/auto.conf are missing.";      \

        echo "         Run 'make oldconfig && make prepare' on kernel src to fix it.";  \

        echo;                                                           \

        /bin/false)

When I compile the kernel I do: "genkernel --menuconfig --bootloader=grub all" which compiles the kernel and it's modules so I'm really puzzled about the modules failing to load. As stated before I have completed an "emerge -e system && emerge -e system" after I changed my CFLAGS to those recommended for use with Core 2 Duo processors.

grantonstar.

----------

## grantonstar

VinzC,

The alsa modules were fixed by a reboot into the new kernel (should have thought of this before mentioning it).

I'm now getting (from dmesg):

localhost ~ # dmesg | grep ieee80211

ieee80211: 802.11 data/management/control stack, git-1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ieee80211_crypt: registered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'WEP'

ieee80211_crypt: registered algorithm 'CCMP'

ieee80211_crypt: registered algorithm 'TKIP'

ieee80211_crypt: disagrees about version of symbol struct_module

ieee80211: disagrees about version of symbol struct_module

ieee80211_crypt: disagrees about version of symbol struct_module

ieee80211: disagrees about version of symbol struct_module

and 

localhost ~ # dmesg | grep ipw3945

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: Detected geography ABG (13 802.11bg channels, 4 802.11a channels)

Which seems to be one step closer...

From what I can gather the struct_module errors are to do with the kernel modules not being compiled with the most recent kernel so I went to /lib/modules/2.6.20-gentoo/net/ieee80211 and the date stamp on the modules was older than the latest compile of my kernel. Shouldn't genkernel recompile everything like it says it does? In any case I thought I would do it manually via "make modules && make modules_install" but got the following error:

if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  2.6.20-gentoo; fi

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_ccmp.ko needs unknown symbol offset_in_page

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_update

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_final

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_setkey

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol crypto_digest_init

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_tkip.ko needs unknown symbol offset_in_page

WARNING: /lib/modules/2.6.20-gentoo/net/ieee80211/ieee80211_crypt_wep.ko needs unknown symbol offset_in_page

My System.map in /boot is up to date with the latest kernel compile (judging by the datestamp).

Now I'm really confused!  :Smile: 

grantonstar.

----------

## Joebel

Hi All,

I have some weird behaviour after upgrading to 1.2.

For 1.2 I had to unmerge the ieee80.211 package, and recompile the kernel with it's included 802.11-stuff (and of cource re-emerge the ipw3945 ebuilds). That's fine.

Now, when I bootup de the 802.11-stuff loads (show in the dmesg-output), and the ipw3945 module is loaded but once "net.eth1" kicks in (wireless interface, using wpa-supplicant), I get the following:

```
network interface eth1 does not exist
```

As soon as I log in to the machine, there is an eth1 interface, and running "net.eth1" results in a correctly configured and working wireless interface.

Anyone have an idea what's happening? It seems like a timing issue in the startup. Anyone have a clue at how to solve this? The previous setup (older ipw3945, using the ieee801.11 ebuild) didn't have this issue.

--Edit-- 

Seems very similar to the problem posted below : and I use the same versions of the ipw3945 ebuildsLast edited by Joebel on Thu Feb 08, 2007 7:18 am; edited 1 time in total

----------

## beatryder

YES! I am not alone!.

Ever since I upgraded to the 1.2.0 drivers, my wireless interface no longer comes up on boot as it used to.

I get the following error messages in syslog:

```

Feb  7 22:55:40 Osiris ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

Feb  7 22:55:40 Osiris ipw3945: Copyright(c) 2003-2006 Intel Corporation

Feb  7 22:55:40 Osiris ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

Feb  7 22:55:40 Osiris ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)

Feb  7 22:55:41 Osiris rc-scripts: Configuration not set for eth1 - assuming DHCP

Feb  7 22:55:41 Osiris rc-scripts: network interface eth1 does not exist

Feb  7 22:55:41 Osiris rc-scripts: Please verify hardware or kernel module (driver)

Feb  7 22:55:41 Osiris rc-scripts: ERROR:  net.eth1 failed to start

Feb  7 22:55:41 Osiris rc-scripts: WARNING:  net.eth0 has started but is inactive

Feb  7 22:55:41 Osiris rc-scripts: ERROR:  cannot start netmount as net.eth1 could not start

Feb  7 22:55:45 Osiris rc-scripts: Configuration not set for eth0 - assuming DHCP

```

but if I wait until the system has finished booting and restart eth1, it works:

```

/etc/init.d/net.eth1 restart

 * Service net.eth1 starting

 * WARNING:  net.eth1 has started but is inactive

```

At which point the card connects to an AP and all is happy.

Any clues?

```
modules_eth1=( "wpa_supplicant" )

wpa_supplicant_eth1="-Dwext"

dhcpcd_eth1="-t 60 -d "

```

I am also using the following:

```

[ Searching for package 'ipw3945' in all categories among: ]

 * installed packages

[I--] [ ~] net-wireless/ipw3945-1.2.0 (0)

[I--] [ ~] net-wireless/ipw3945-ucode-1.14.2 (0)

[I--] [ ~] net-wireless/ipw3945d-1.7.22-r4 (0)

```

----------

## grantonstar

VinzC,

I fixed my problem! I removed the ieee80211 modules from /lib/modules/ and rebuilt the kernel this time with ieee80211 built into the kernel. 

Now onto getting the network up and running.

Thanks for pointing me in the right direction.

grantonstar

----------

## VinzC

 *grantonstar wrote:*   

> VinzC,
> 
> I fixed my problem! I removed the ieee80211 modules from /lib/modules/ and rebuilt the kernel this time with ieee80211 built into the kernel. 

 

Use make clean, which does it for you  :Smile:  .

 *grantonstar wrote:*   

> Now onto getting the network up and running.
> 
> Thanks for pointing me in the right direction.
> 
> grantonstar

 

Glad to help.

----------

## VinzC

 *beatryder wrote:*   

> YES! I am not alone!.
> 
> Ever since I upgraded to the 1.2.0 drivers, my wireless interface no longer comes up on boot as it used to.
> 
> [...]
> ...

 

You're probably using >=udev-098, aren't you? These versions of udev are pretty buggy IMHO. That's why I'm using an older version - I've switched to udev-087-r1 (with 2.6.19-gentoo-r5) ATM. For instance, udev-103 (stable) still lacks functionalities we had before with coldplug (blacklisting and module insert/remove instructions).

Also note the driver cannot be used until ipw3945d is loaded and has started. Service dependencies might have an impact on how the driver behaves and what you can do with it. So your best bet is to try rmh3093's ipw3945 patch and only portage's ipw3945d-1.7.18 and ipw3945-ucode-1.13. Provided the daemon is loaded upon insertion of ipw3945 your laptop will connect immediately.

Start with a clean kernel source tree to be sure.

----------

## Seron

beatryder, I had the same or very similar problem and solved it by adding a little sleep in /etc/init.d/ipw3945d right before the end of start().

```
start() {

        check

        ebegin "Starting ipw3945d"

        chown ipw3945d /sys/bus/pci/drivers/ipw3945/00*/cmd

        chmod a-w,u+rw /sys/bus/pci/drivers/ipw3945/00*/cmd

        start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \

                --pid-file=${PIDFILE} ${ARGS}

        sleep 0.5   # <--- here

        eend ${?}

}
```

Here's some more info.

----------

## zappala

beatryder, I also had a similar problem with a version of this driver, and I fixed it by removing ipw3945d from the default runlevel and adding it to the boot runlevel instead.  This gave it enough time to startup before net.eth1 started.

----------

## Joebel

 *Seron wrote:*   

> beatryder, I had the same or very similar problem and solved it by adding a little sleep in /etc/init.d/ipw3945d right before the end of start().
> 
> ```
> start() {
> 
> ...

 

Hi, I'm the guy who's having the same problem as beatryder. I read that thread to, and tried this solution. Alas, to no avail.

I even tried "sleep 1.5" --> nothing.

Thanx for the suggestion, though. Very much appreciated.

Joebel

----------

## Joebel

 *zappala wrote:*   

> beatryder, I also had a similar problem with a version of this driver, and I fixed it by removing ipw3945d from the default runlevel and adding it to the boot runlevel instead.  This gave it enough time to startup before net.eth1 started.

 

That was a good idea. Seems that it doesn't work for all systems: it doesn't solve it on my system, unfortunately.

Thanks for the suggestion though.

Joebel

----------

## morbus

So did actually any of you guys try the still highly experimental iwlwifi driver for the ipw3945 chipset? It's developed by Intel and does not require a binay-only daemon (They moved the critical parts to the firmware I think). Nevertheless it requires the devicescape wlan stack which is not yet in the mainline kernel

Link: http://bughost.org/iwlwifi/

----------

## Lloeki

This seems highly interesting. I'll take a look at it once I get some time on my hands.

May I suggest creating a separate thread similar to this one once we get some progress/reports, so that things are not messed up on this thread?

details from planet.gentoo.org:

 *dsd wrote:*   

> 
> 
> The other large topic was the merge of the new wireless stack (d80211) which was donated to the community by Devicescape. The stack has many more features than the current in-kernel ieee80211/softmac stack, and improves consistency between drivers. We are now much closer to getting d80211 merged into mainline Linux, but there are still some significant technical issues to be resolved.
> 
> Before the conference, several people asked me if I could raise issues with the suckiness of Intels ipw3945 driver offering in that it relies on this awkward closed-source userspace daemon. Fortunately Intel have found a way to rewrite their firmware so that the regulatory domain control is no longer at the driver level, therefore a fully open-source driver with no binary userspace part has been developed (iwlwifi). Although Intel have not yet announced it, the source code has been released here. This rewritten driver uses the d80211 stack mentioned above, so its not possible just to compile it against mainline Linux at the moment. The iwlwifi website includes instructions for how to check out the wireless-dev tree where d80211 is being held.

 

and from kerneltrap.org:

 *Quote:*   

> Quick glance at the code shows that iwlwifi is based on ipw3945 driver and is still a bit complex compared to OpenBSD wpi driver.

 

EDIT: d80211 patched and built without issues against kernel suspend2-2.6.19-r1, microcode copied in /lib/firmware, driver compiled seemingly without issues, loading it causes a bad lock (keyboard gets stuck, mouse still moves, after some minutes, things (namely, X) start crashing). conclusion: for now, iwlwifi is HIGHLY UNSAFE to use.

----------

## slackthumbz

Hi, I've been having a strange issue with my ipw3945 lately. I'm able to install and have the ipw3945d starting on boot (had to edit the init script and remove the --pidfile option because the ipw3945d thought that it was being passed to the iface daemon rather than the start-stop daemon and crashed) however I can run Kismet fine and it detects networks but when I try to dhcpcd to a network I always get timeouts. Also when I manually set the essid (iwconfig eth1 essid "Whatever" I've found that then running iwconfig without args shows that the last character is missing from the essid so it would be "Whateve"...

Anyone had anything similar?

----------

## beatryder

 *Joebel wrote:*   

>  *zappala wrote:*   beatryder, I also had a similar problem with a version of this driver, and I fixed it by removing ipw3945d from the default runlevel and adding it to the boot runlevel instead.  This gave it enough time to startup before net.eth1 started. 
> 
> That was a good idea. Seems that it doesn't work for all systems: it doesn't solve it on my system, unfortunately.
> 
> Thanks for the suggestion though.
> ...

 

This solution did not work for me either.

As for the idea of downgrading to <=udev-098 that is not really an option to me. I dont understand why I should downgrade from a *stable* package?

----------

## VinzC

 *beatryder wrote:*   

> I dont understand why I should downgrade from a *stable* package?

 

Not because it is unstable but because its *functionnality* has deeply changed. As I said >=udev-098 is incompatible with coldplug: you have to remove it. Plug and play works in a completely different manner as of udev-098.

----------

## VinzC

 *Lloeki wrote:*   

> This seems highly interesting. I'll take a look at it once I get some time on my hands.
> 
> May I suggest creating a separate thread similar to this one once we get some progress/reports, so that things are not messed up on this thread?

 

Done  :Smile: 

----------

## beatryder

 *VinzC wrote:*   

>  *beatryder wrote:*   I dont understand why I should downgrade from a *stable* package? 
> 
> Not because it is unstable but because its *functionnality* has deeply changed. As I said >=udev-098 is incompatible with coldplug: you have to remove it. Plug and play works in a completely different manner as of udev-098.

 

I don't understand then. I have been using udev <= 098 with the ipw3945-1.1.13 and everything worked just fine. Now it has been removed from portage, and I am hosed.

I understand why you say the older udev is the one that should be used. Surely there has to be a better solution.

----------

## VinzC

To me that's the whole plug'n'play thing that got hosed. I don't understand why udev got released though neither blacklisting nor module insert/remove instructions worked. But that's another story.

I must admit I expect much from einit or whatever comes first.

----------

## sLoDkI

Hi all.

Sorry for complaining about things maybe explained here, but there is lots of posts to go through, so i could miss sth.

I'm trying get my ipw3945 on dell e1405 to work for a few days, but still no success. Could someone take a look? Everytime i compile all stuff (patched or not) when all things gone fine i finally don't have wireless inteface visible/accessible. I've tried solutions with previous kernels - the same. Actually i have 2.6.20 + ipw3945-1.1.3_for_2.6.20.patch with in-kernel ieee80211 stack. My results:

```
[root@inspirebox /usr/src/linux] dmesg | grep ipw

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

[root@inspirebox /usr/src/linux] dmesg | grep ieee

ieee80211: 802.11 data/management/control stack, git-1.1.13

ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

ieee80211_crypt: registered algorithm 'NULL'

ieee80211_crypt: registered algorithm 'WEP'

ieee80211_crypt: registered algorithm 'CCMP'

ieee80211_crypt: registered algorithm 'TKIP'

ieee1394: Host added: ID:BUS[0-00:1023]  GUID[424fc0001805ed41]

[root@inspirebox /usr/src/linux] emerge -av ipw3945d ipw3945-ucode ipw3945 ieee80211

[ebuild   R   ] net-wireless/ipw3945d-1.7.22-r4  0 kB

[ebuild   R   ] net-wireless/ipw3945-ucode-1.14.2  0 kB

[ebuild   R   ] net-wireless/ipw3945-1.2.0  USE="-debug" 0 kB

[ebuild  N    ] net-wireless/ieee80211-1.2.16  USE="-debug" 0 kB

[root@inspirebox /usr/src/linux] /etc/init.d/ipw3945d restart

 * Stopping ipw3945d ...                                                                                                                               [ ok ] 

 * Starting ipw3945d ...

chown: nie ma dostêpu do `/sys/bus/pci/drivers/ipw3945/00*/cmd': Nie ma takiego pliku ani katalogu

chmod: nie ma dostêpu do `/sys/bus/pci/drivers/ipw3945/00*/cmd': Nie ma takiego pliku ani katalogu 

[root@inspirebox /usr/src/linux] lsmod

Module                  Size  Used by

ipw3945               112480  0

i915                   21056  3

ohci1394               31824  0

ieee1394               83892  1 ohci1394

uhci_hcd               20812  0

ehci_hcd               28364  0

[root@inspirebox /usr/src/linux] iwconfig

lo        no wireless extensions.

eth0      no wireless extensions.

[root@inspirebox /usr/src/linux] ls -la /sys/bus/pci/drivers/ipw3945

razem 0

drwxr-xr-x  2 root root    0 lut 12 15:37 .

drwxr-xr-x 17 root root    0 lut  8 21:18 ..

--w-------  1 root root 4096 lut 12 15:37 bind

-rw-r--r--  1 root root 4096 lut 12 15:37 debug_level

lrwxrwxrwx  1 root root    0 lut 12 15:37 module -> ../../../../module/ipw3945

--w-------  1 root root 4096 lut 12 15:37 new_id

--w-------  1 root root 4096 lut 12 15:37 unbind

[root@inspirebox /usr/src/linux] ls -la ..| grep linux

lrwxrwxrwx  1 root root       14 lut  8 14:04 linux -> ./linux-2.6.20

```

There's no /sys/bus/pci/drivers/ipw3945/00*/cmd and no eth* pointing to wifi device.

Some hints i can check?

Actually i don't know which way to choose.. prev. kernels / external ipw / ndsiwrapper / or try to find solution for this one.

I've cleaned out modules, and did other things you've discussed here, the only thing i don't make was the script /etc/init.d/ipw3945d - but i thing it will be a problem when the card runs.

```
[root@inspirebox /usr/src/linux] uname -a

Linux inspirebox 2.6.20 #1 SMP Thu Feb 8 12:00:50 Local time zone must be set--see zic m i686 Intel(R) Core(TM)2 CPU         T5600  @ 1.83GHz GenuineIntel GNU/Linux
```

----------

## sLoDkI

Ok, I realised I have ipw3945-1.2.0 emerged and ipw3945-1.1.3 from kernel, so I've done emerge -C 1.2.0 version, rm -rf /lib/modules/2.6.20/, rebuild and reinstall kernel modules - still no efect: module loaded, no /sys/bus/pci/drivers/ipw3945/00*/cmd files and no wireless interface.

----------

## Lloeki

I can't recall for /sys/.../cmd stuff, but the eth device sure won't show up until ipw3945d is started.

----------

## sLoDkI

I know:) When I coment the chown and chmod lines out in /etc/init.d/ipw3945d - there is no errors while startng it, but (as always) no eth interface available.

----------

## rmh3093

 *sLoDkI wrote:*   

> Ok, I realised I have ipw3945-1.2.0 emerged and ipw3945-1.1.3 from kernel, so I've done emerge -C 1.2.0 version, rm -rf /lib/modules/2.6.20/, rebuild and reinstall kernel modules - still no efect: module loaded, no /sys/bus/pci/drivers/ipw3945/00*/cmd files and no wireless interface.

 

after you modprobe ipw3945 and start the daemon, type lsmod.... if the used by column is 0 for the ipw3945 module then that means there was probably a firmware error... type dmesg and look for any ipw3945 errors, i bet it says it couldnt load the firmware

----------

## beatryder

For all those interested in the older modules

Get them here:

http://neucode.org/gentoo/ipw3945.tar.bz2

----------

## sLoDkI

 *rmh3093 wrote:*   

> after you modprobe ipw3945 and start the daemon, type lsmod.... if the used by column is 0 for the ipw3945 module then that means there was probably a firmware error... type dmesg and look for any ipw3945 errors, i bet it says it couldnt load the firmware

 

The main problem is that there are no errors. Take a look:

```
[root@inspirebox /usr/src/linux] lsmod

Module                  Size  Used by

i915                   21056  3

ohci1394               31824  0

ieee1394               83892  1 ohci1394

ehci_hcd               28364  0

uhci_hcd               20812  0

[root@inspirebox /usr/src/linux] modprobe ipw3945

 * Starting ipw3945d ...                   [OK]

[root@inspirebox /usr/src/linux] /etc/init.d/ipw3945d start

 * WARNING:  ipw3945d has already been started.

[root@inspirebox /usr/src/linux] lsmod | grep ipw

ipw3945               112480  0

[root@inspirebox /usr/src/linux] dmesg | grep ipw

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

[root@inspirebox /usr/src/linux] tail /var/log/messages

Feb 14 10:02:58 inspirebox ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mpr

Feb 14 10:02:58 inspirebox ipw3945: Copyright(c) 2003-2006 Intel Corporation

Feb 14 10:03:25 inspirebox rc-scripts: WARNING:  ipw3945d has already been started.
```

Everytime I modprobe ipw3945 - it automaticly starts ipw3945d daemon. I have commented out the chmod and chown lines in /etc/init.d/ipw3945d beacuse it always says:

```
 [root@inspirebox /usr/src/linux] /etc/init.d/ipw3945d restart

 * Caching service dependencies ...                                                                                        [ ok ] 

 * Stopping ipw3945d ...                                                                                                        [ ok ] 

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory            [ ok ]
```

My daemon script:

```
#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-wireless/ipw3945d/files/ipw3945d-init.d,v 1.4 2006/12/22 10:11:26 phreak Exp $

PIDFILE=/var/run/ipw3945d/ipw3945d.pid

depend() {

   before net

}

check() {

   # Let's check if the pidfile is still present.

   if [ -f "${PIDFILE}" ] ; then

      eerror "The pidfile ($PIDFILE) is still present."

      eerror "Please check that the daemon isn't running!"

      return 1

   fi

}

start() {

   check

   ebegin "Starting ipw3945d"

#  chown ipw3945d /sys/bus/pci/drivers/ipw3945/00*/cmd

#  chmod a-w,u+rw /sys/bus/pci/drivers/ipw3945/00*/cmd

   start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \

      --pid-file=${PIDFILE} ${ARGS}

   sleep 0.5

   eend ${?}

}

stop() {

   ebegin "Stopping ipw3945d"

   start-stop-daemon --stop --exec /sbin/ipw3945d --pidfile ${PIDFILE}

   eend ${?}

}

```

----------

## Joebel

 *beatryder wrote:*   

> For all those interested in the older modules
> 
> Get them here:
> 
> http://neucode.org/gentoo/ipw3945.tar.bz2

 

They work, although when under heavy load (sftp and the likes) the ipw3945 stutters and dies..

Remains weird though: having a completely working network setup--> portage deletes those ebuilds, introduces new ones (now even "stable")--> no working setup.

----------

## beatryder

 *Joebel wrote:*   

>  *beatryder wrote:*   For all those interested in the older modules
> 
> Get them here:
> 
> http://neucode.org/gentoo/ipw3945.tar.bz2 
> ...

 

Yeah, that pissed me off too. I actually have considered changing distros now. The only thing that has kept me around is the fact that I know it won't be much better if I go elsewhere and I know gentoo so well now that it would more work to switch.

----------

## rmh3093

idk why you people have such and issue getting this driver to work...

----------

## Lloeki

 *Quote:*   

> although when under heavy load (sftp and the likes) the ipw3945 stutters and dies.. 

 

look in dmesg for TKIP replays and mickael mic digest failure.

----------

## beatryder

 *rmh3093 wrote:*   

> idk why you people have such and issue getting this driver to work...

 

Neither do we, the only solution posed to me was to downgrade udev, which is obviously not the problem or the old drivers would not work either.

----------

## VinzC

 *sLoDkI wrote:*   

> Everytime I modprobe ipw3945 - it automaticly starts ipw3945d daemon.

 

If you see the daemon run automatically once the module is loaded then you don't need ipw3945d init script because the latter was provided only for those cases where the insert/remove instructions in /etc/modules.d/ipw3945d are ignored by the system. So remove ipw3945d (emerge -C ipw3945d) and install the stable ipw3945 package. (I'd expect troubles running the daemon twice.)

EDIT: As I posted later on , to my knowledge package ipw3945d with the init script is in the ~ARCH branch while the deamon without the init script in in the stable branch. So just emerge the stable ipw3945d.

And don't forget to rc-update -d ipw3945d...

----------

## VinzC

 *Joebel wrote:*   

> They work, although when under heavy load (sftp and the likes) the ipw3945 stutters and dies..
> 
> Remains weird though: having a completely working network setup--> portage deletes those ebuilds, introduces new ones (now even "stable")--> no working setup.

 

 *beatryder wrote:*   

> Yeah, that pissed me off too. I actually have considered changing distros now. The only thing that has kept me around is the fact that I know it won't be much better if I go elsewhere and I know gentoo so well now that it would more work to switch.

 

Rather drastic a solution  :Rolling Eyes:  . Once I ran into such troubles I completely removed the kernel source tree and modules and re-did a fresh and clean compile with teh appropriate patches. Never had a glitch ever since.

----------

## VinzC

 *Joebel wrote:*   

> They work, although when under heavy load (sftp and the likes) the ipw3945 stutters and dies..

 

That's where the TKIP patch (mentioned above) comes at hand...

----------

## beatryder

 *VinzC wrote:*   

>  *sLoDkI wrote:*   Everytime I modprobe ipw3945 - it automaticly starts ipw3945d daemon. 
> 
> If you see the daemon run automatically once the module is loaded then you don't need ipw3945d init script because the latter was provided only for those cases where the insert/remove instructions in /etc/modules.d/ipw3945d are ignored by the system. So remove ipw3945d (emerge -C ipw3945d). I'd expect troubles running the daemon twice.

 

Your post is confusing. You are suggesting that one removes the ipw3945 daemon. If the daemon is not installed how is it going to be started if the daemon itself has been removed from the system? /etc/modules.d/ipw3945d will not do the job either then because the binary will not exist.

If I am not mistaken, a better solution would be to simply remove the init script from any runlevels

```

# rc-update del ipw3945d

```

Perhaps I am not understanding you correctly, could you please clarify?

----------

## beatryder

 *VinzC wrote:*   

>  *Joebel wrote:*   They work, although when under heavy load (sftp and the likes) the ipw3945 stutters and dies..
> 
> Remains weird though: having a completely working network setup--> portage deletes those ebuilds, introduces new ones (now even "stable")--> no working setup. 
> 
>  *beatryder wrote:*   Yeah, that pissed me off too. I actually have considered changing distros now. The only thing that has kept me around is the fact that I know it won't be much better if I go elsewhere and I know gentoo so well now that it would more work to switch. 
> ...

 

That is also a fairly drastic solution  :Razz:  But neverless, I found a solution: portage CVS history :p

----------

## VinzC

You're right my post is confusing. I had in mind that the daemon was part of ipw3945 but it's not. To my knowledge package ipw3945d with the init script is in the ~ARCH branch while the deamon without the init script in in the stable branch. So just emerge the stable ipw3945d.

----------

## beatryder

 *VinzC wrote:*   

> You're right my post is confusing. I had in mind that the daemon was part of ipw3945 but it's not. To my knowledge package ipw3945d with the init script is in the ~ARCH branch while the deamon without the init script in in the stable branch. So just emerge the stable ipw3945d.

 

Perhaps you should check portage. There is no more ~x86 ipw3945 stuff

http://packages.gentoo.org/search/?sstring=ipw3945

----------

## frz

```
* Starting ipw3945d ...

chown: nie ma dostêpu do `/sys/bus/pci/drivers/ipw3945/00*/cmd': Nie ma takiego pliku ani katalogu

chmod: nie ma dostêpu do `/sys/bus/pci/drivers/ipw3945/00*/cmd': Nie ma takiego pliku ani katalogu

```

 Same issue as discussed above

```
localhost src # lsmod

Module                  Size  Used by

ipw3945               198500  0 

localhost src # modprobe ipw3945 

localhost src # dmesg | grep ipw 

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: ipw3945.ucode load failed: Reason -2

ipw3945: Could not read microcode: -2

ipw3945: probe of 0000:0c:00.0 failed with error -2

localhost src # tail /var/log/messages 

Feb 15 03:08:01 localhost ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

Feb 15 03:08:11 localhost ipw3945: ipw3945.ucode load failed: Reason -2

Feb 15 03:08:11 localhost ipw3945: Could not read microcode: -2

Feb 15 03:08:11 localhost ipw3945: probe of 0000:0c:00.0 failed with error -2

Feb 15 03:08:11 localhost rc-scripts: WARNING:  ipw3945d has already been started.

Feb 15 03:10:01 localhost cron[11186]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Feb 15 03:15:25 localhost rc-scripts: WARNING:  ipw3945d has already been started.

Feb 15 03:20:01 localhost cron[13202]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Feb 15 03:30:01 localhost cron[16911]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Feb 15 03:40:01 localhost cron[16942]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

localhost src # 

```

 Kernel is  vanilla 2.6.20 cuz I couldn't manage to make it working proparly with gentoo kernel.... with vanilla eather =_) Any suggestions?

----------

## beatryder

yeah, try 2.6.19 it works for me.

----------

## rmh3093

for people that are commenting out the chown in the ipw3945d init script need to 'chown root /sbin/ipw3945d'

----------

## frz

```
localhost iwlwifi-0.0.7 # chown root /sbin/ipw3945d

localhost iwlwifi-0.0.7 # /etc/init.d/ipw3945d start

 * WARNING:  ipw3945d has already been started.

localhost iwlwifi-0.0.7 # /etc/init.d/ipw3945d restart

 * Stopping ipw3945d ...                                                                                                                               [ ok ]

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory 
```

Btw, trying new iwlwifi

```
localhost iwlwifi-0.0.7 # dmesg | tail

iwlwifi: Intel(R) Wirless Link driver for Linux, 0.0.7

iwlwifi: Copyright(c) 2003-2006 Intel Corporation

ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17

PCI: Setting latency timer of device 0000:0c:00.0 to 64

iwlwifi: Detected Intel PRO/Wireless 3945ABG Network Connection

iwlwifi: iwlwifi-3945.ucode firmware file req failed: Reason -2

iwlwifi: Could not read microcode from disk: -2

iwlwifi: probe of 0000:0c:00.0 failed with error -2

```

 Same error with firmware like with ipw3945....

With kernel 2.6.19 didn't work eather, module loads but... something like previous error in microcode.... The last thing is lspci output, really I don't know what to do... Thinking to change wireless adapter, really...

```
 lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)

Blah-blah-blah....

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
```

----------

## TenPin

So that I don't have to read through the last 28 pages of this marvelous topic, can anyone tell me that they have their ipw3945 card working successfully on 2.6.20 vanilla with wpa_supplicant ?

Thanks in advance.

----------

## madisonicus

 *TenPin wrote:*   

> So that I don't have to read through the last 28 pages of this marvelous topic, can anyone tell me that they have their ipw3945 card working successfully on 2.6.20 vanilla with wpa_supplicant ?
> 
> Thanks in advance.

 Working fine on 2.6.20 Gentoo sources for what that's worth.

----------

## VinzC

 *beatryder wrote:*   

> Perhaps you should check portage. There is no more ~x86 ipw3945 stuff
> 
> http://packages.gentoo.org/search/?sstring=ipw3945

 

Ok, then. Use ipw3945d-1.7.18 (aka my ransom for not going the bleeding-edge way  :Wink:  ).

----------

## sLoDkI

Ok, I emerged gentoo-sources-2.6.20, patched it () emerged stable: ipw3945d and -ucode, and thigs looks similar as before   :Crying or Very sad: 

```
[root@inspirebox /usr/src/linux] lsmod

Module                  Size  Used by

i915                   21056  2

ohci1394               31824  0

ieee1394               83892  1 ohci1394

ehci_hcd               28364  0

uhci_hcd               20812  0

[root@inspirebox /usr/src/linux] modprobe ipw3945 && lsmod | grep ipw

2007-02-15 12:35:55: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

ipw3945               201412  0

[root@inspirebox /usr/src/linux] /etc/init.d/ipw3945d start && lsmod | grep ipw && dmesg | grep ipw

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory                    [ ok ]

ipw3945               201412  0

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.1.3mr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

[root@inspirebox /usr/src/linux] emerge -av ieee80211 ipw3945 ipw3945d ipw3945-ucode

[ebuild  N    ] net-wireless/ieee80211-1.1.13-r1  USE="-debug" 0 kB

[ebuild  N    ] net-wireless/ipw3945-1.2.0  USE="-debug" 0 kB

[ebuild   R   ] net-wireless/ipw3945d-1.7.22-r4  0 kB

[ebuild   R   ] net-wireless/ipw3945-ucode-1.14.2  0 kB
```

Am I doing sth wrong?

----------

## VinzC

 *sLoDkI wrote:*   

> Ok, ... emerged stable: ipw3945d ...
> 
> ...
> 
> [ebuild   R   ] net-wireless/ipw3945d-1.7.22-r4  0 kB
> ...

 

Well, both versions are stable (with and without the ipw3945d init script). You should install ipw3945-1.7.18. Just check the daemon is loaded with ps -fC ipw3945d.

----------

## gerste

Hello. I have a problem I haven't found the exact same way yet in the forum.  Maybe someone can just point me to the correct thread.

After upgrading udev to 1.4 and some days later ipw3945 to 1.2 with ipw3945-ucode-1.4.2 and kernel to 2.6.19 (ieee80211 compiled with kernel as modules, compiled into kernel didn't help), my systems hangs after a while completely. Keyboard is gone. I can close windows in gnome but cannot start new processes, so I say my kernel is dead. I can only hard switch off the system, with all bad things that happen when not unmounting and so on. The only messages I get in /var/log/messages, before messages from the next system start appear, is:

```

Feb 15 21:18:33 wobbler ipw3945: Error sending cmd #07 to daemon: time out after

 500ms.

Feb 15 21:18:35 wobbler ipw3945: Error sending SCAN_ABORT_CMD: time out after 50

0ms.

Feb 15 21:18:35 wobbler ipw3945: Error sending cmd #08 to daemon: time out after

 500ms.

Feb 15 21:18:36 wobbler ipw3945: Error sending ADD_STA: time out after 500ms.

```

Unfortunately I cannot downgrade to 1.1.3 anymore, as it was taken out of portage, when the update came out.

First I thought it happens, when the card goes to sleep and cannot awake again. But it happens also when I'm on AC with full network usage. When I switch off the wireless card by hand (a little switch on the laptop), it didn't happen so far.

----------

## VinzC

@gerste:

As usual, try to whipe out your kernel source tree, apply rmh3093 ipw3945 patches (couple of pages above in this thread) for your kernel and recompile.

----------

## TenPin

I just got ipw3945 to work beautifully. To do this I did the following:

```
emerge --sync

rc-update del ipw3945d

emerge -C coldplug

emerge -C ipw3945 ipw3945d ipw3945-ucode ieee80211

[installed kernel 2.6.20 manually with built in ieee80211 stack then rebooted]

emerge wpa_supplicant

emerge ipw3945 ipw3945d ipw3945-ucode

emerge module-init-tools (this needed updgrading for udev to work properly for me)

modprobe ipw3945

```

First I tested connecting to an unencrypted access point using only iwconfig and dhcpcd. Then I tested connecting to a WPA access point using:

```
#/etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=wheel

eapol_version=1

ap_scan=1

fast_reauth=1

network={

        ssid="Boiler"

        psk="password"

        priority=10

        scan_ssid=1

}

```

```
wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf

```

If you can get the above command to work then the only thing left to do is making your network boot scripts work the way you want.

With this setup I found that the wireless LED on my laptop came on automatically on boot. With my previous setup I had to have an init script that did this:

```
echo 0 > /sys/class/net/eth1/device/rf_kill
```

----------

## gerste

I cleaned my kernel sources. Reemerged everything and build the ieee into the kernel. Afterwards may laptop worked a long time and I was happy that it did. But after 3 hours it hang again.

Does someone know what could cause these communication problems between ipw3945 module and ipw3945d daemon? What are these commands the module wants to trigger and gets timeouts with? Is command #3 the SCAN_ABORT_CMD following in the next line? I still think that it is connected to the device going into sleep mode.

----------

## aka_iG

Might be that I'm a big dumb ass... But I can't even compile my 2.6.20 kernel with Generic IEEE 802.11 Networking Stack enabled.

```
superBock linux # uname --all

Linux superBock 2.6.20-gentoo #3 SMP PREEMPT Sun Feb 18 22:44:52 WET 2007 i686 Genuine Intel(R) CPU           T2300  @ 1.66GHz GenuineIntel GNU/Linux
```

I get the following error:

```
superBock linux # make && make install && make modules && make modules_install

  CHK     include/linux/version.h

  CHK     include/linux/utsrelease.h

  CHK     include/linux/compile.h

dnsdomainname: Unknown host

make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.o', needed by `net/ieee80211/ieee80211.o'.  Stop.

make[1]: *** [net/ieee80211] Error 2

make: *** [net] Error 2
```

Any smart ideas?   :Confused: 

Thanks in advance!

----------

## gerste

Sorry to bother again, but I got a big problem here. The bug I described earlier is now listed on the site hosting the ipw3945 with no solution available. I tried to switch back to 1.0.5 but it doesn't compile anymore.

I would really like to downgrade to 1.1.3-r2 but the ebuilds are gone and even google couldn't help me find one.

Can some give me a link to this ebuild? I would try creating an overlay on my system. The distfiles are still present on my system. I just need the ebuild.

Edit:

As the problem is a communication problem between the kernel module and the daemon, I downgraded the daemon this time to 1.7.18 . The combination of ipw3945d-1.7.18 and ipw3945-1.2.0 seems to work so far. As long as it works this way for me, I think I can live without startup scripts for the daemon and start it by hand when need.

----------

## sLoDkI

 *TenPin wrote:*   

> I just got ipw3945 to work beautifully. To do this I did the following:
> 
> ```
> emerge --sync
> 
> ...

 

You're lucky man! I still can't handle it  :Sad: 

I've done all you post above and:

```
[root@inspirebox /usr/src] uname -a; emerge -av ipw3945 ipw3945d ipw3945-ucode ieee80211

Linux inspirebox 2.6.20 #1 SMP Mon Feb 19 13:39:54 Local time zone must be set--see zic  i686 Intel(R) Core(TM)2 CPU         T5600  @ 1.83GHz GenuineIntel GNU/Linux

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] net-wireless/ipw3945-1.2.0  USE="-debug" 0 kB

[ebuild   R   ] net-wireless/ipw3945d-1.7.22-r4  0 kB

[ebuild   R   ] net-wireless/ipw3945-ucode-1.14.2  0 kB

[ebuild  N    ] net-wireless/ieee80211-1.1.13-r1  USE="-debug" 0 kB

```

```

[root@inspirebox /usr/src] lsmod | grep ipw

[root@inspirebox /usr/src] modprobe ipw3945 

2007-02-19 15:54:20: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

[root@inspirebox /usr/src]  /etc/init.d/ipw3945d start

 * Starting ipw3945d ...

chown: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

chmod: cannot access `/sys/bus/pci/drivers/ipw3945/00*/cmd': No such file or directory

ipw3945d - regulatory daemon

Copyright (C) 2005-2006 Intel Corporation. All rights reserved.

version: 1.7.22

2007-02-19 15:54:20: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection                                                               [ ok ]

[root@inspirebox /usr/src] dmesg| grep ipw | tail -n 5

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

[root@inspirebox /usr/src] lsmod | grep ipw

ipw3945               202148  0

[root@inspirebox /usr/src] iwconfig

lo        no wireless extensions.

eth0      no wireless extensions.

```

 :Question:   :Question:   no idea what to check..  :Sad: 

PS. also tried with ipw3945d-1.7.18 - the same, except:

```
[root@inspirebox /usr/src] /etc/init.d/ipw3945d stop; rmmod ipw3945

 * Stopping ipw3945d ...                                                                                       [ ok ]

[root@inspirebox /usr/src] modprobe ipw3945; tail -n 5 /var/log/messages

2007-02-19 16:05:31: ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection

FATAL: Error running install command for ipw3945

Feb 19 16:02:57 inspirebox ipw3945: Copyright(c) 2003-2006 Intel Corporation

Feb 19 16:03:59 inspirebox ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

Feb 19 16:03:59 inspirebox ipw3945: Copyright(c) 2003-2006 Intel Corporation

Feb 19 16:05:31 inspirebox ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

Feb 19 16:05:31 inspirebox ipw3945: Copyright(c) 2003-2006 Intel Corporation

```

ehh.. why it takes so much time and till no result?!

----------

## svatoboj

 *aka_iG wrote:*   

> Might be that I'm a big dumb ass... But I can't even compile my 2.6.20 kernel with Generic IEEE 802.11 Networking Stack enabled.
> 
> ```
> superBock linux # uname --all
> 
> ...

 

Had the same problem.

First off, unmerge ieee80211 package and use the code included in the kernel source.

Then you ou have to unmerge and emerge your kernel source again ( I use gentoo-sources 2.6.19-r2 ) and remove or backup module directory...

Emerge ipw3945 and ipwd3945d from portage.

Should work fine  :Smile: 

svata

----------

## svatoboj

 *sLoDkI wrote:*   

>  *TenPin wrote:*   I just got ipw3945 to work beautifully. To do this I did the following:
> 
> ```
> emerge --sync
> 
> ...

 

If I'm correct, ipwd doesn't depend on net-wireless/ieee80211 anymore.

```

ragnarok ~ # emerge -pv ipw3945 ipw3945d ipw3945-ucode

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] net-wireless/ipw3945-1.2.0  USE="-debug" 0 kB

[ebuild   R   ] net-wireless/ipw3945d-1.7.22-r4  0 kB

[ebuild   R   ] net-wireless/ipw3945-ucode-1.14.2  0 kB

Total: 3 packages (3 reinstalls), Size of downloads: 0 kB

```

So thus I unmerged ieee80211 and used the one provided by kernel.

```

Linux ragnarok 2.6.19-gentoo-r2 #1 SMP Mon Feb 19 11:16:35 GMT 2007 i686 Genuine Intel(R) CPU           T2300  @ 1.66GHz GenuineIntel GNU/Linux

```

You have to unmerge and emerge your kernel sources as source tree seems to altered to such extent that ipw modules doesn't compile...

Then backup/remove your modules dir...

```
/lib/modules/`uname -r` 
```

and then emerge all ipw stuff. Add ipw3945d to your default run level

```

rc-update add ipw3945d default

```

ipw3945 module gets loaded by udev at startup.

Do not forget reemerge any graphic drivers, alsa drivers as you have brand new kernel installation.

HTH

svata

----------

## VinzC

 *gerste wrote:*   

> I cleaned my kernel sources. Reemerged everything and build the ieee into the kernel. Afterwards may laptop worked a long time and I was happy that it did. But after 3 hours it hang again.
> 
> Does someone know what could cause these communication problems between ipw3945 module and ipw3945d daemon? What are these commands the module wants to trigger and gets timeouts with? Is command #3 the SCAN_ABORT_CMD following in the next line? I still think that it is connected to the device going into sleep mode.

 

Well... sometimes when I boot my laptop with the wireless card disabled it hangs and I have to restart it (Ctrl+Alt+SysReq, B). It happens sometimes and usually it doesn't hang at next boot... Go figure...

----------

## sLoDkI

svatoboj: 

I know  :Smile:  i put there emerge -av ... ieee80211 only for info (that it's not emerged in the system) for those who suggest unemerge it;) I have 2.6.20-gentoo, 2.6.20 from kernel org, 2.6.19-rX.. with/without ipw1.2.0 patches, with or without ieee80211 built-in or emerged, and other combinations tested. I think i've tested combinations of combinations too  :Smile:  but without result:( Wifi still only under win$hit ;/ Everytime i have all things compiled/installed i get the "ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection" error or similar. I REALLY don't know what to do yet.

Regards and many thanks for all those helping each other.

----------

## rmh3093

I think this thread needs to die and become locked... so much has changed in a year since this thread was started, 28 pages of posts must be confusing people new the the ipw3945 because this hardware is not hard to setup and use, people should not be having such a hard time

----------

## beatryder

I agree, it should not be that hard.

That said, it becomes hard when a new version of the drivers comes out, and one that work for many people is simply removed from portage!

I have no idea why, but 1.2.0 does not play nice on my machine and I don't have time to futz with it.

----------

## bmichaelsen

I still cant get this driver to work on my Inspiron 9400:

This is the relevant dmesg output:

On Boot:

```
ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0dmpr

ipw3945: Copyright(c) 2003-2006 Intel Corporation

ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection

ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
```

When starting kismet:

```
device eth1 entered promiscuous mode

ipw3945: Error sending cmd #08 to daemon: time out after 500ms.

ipw3945: Error sending ADD_STA: time out after 500ms.

ipw3945: Error sending cmd #08 to daemon: time out after 500ms.

ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
```

versions:

Linux XXX 2.6.20-gentoo #1 SMP Fri Feb 9 23:01:52 CET 2007 i686 Genuine Intel(R) CPU           T2400  @ 1.83GHz GenuineIntel GNU/Linux

ipw3945-1.2.0

ipw-3945d-1.7.22-r4

ipw3945-ucode-1.14.2

Any help appreciated.

Have Fun,

Björn

----------

## VinzC

 *bmichaelsen wrote:*   

> I still cant get this driver to work on my Inspiron 9400 [...]

 

That's a problem that many of us had. I've got an Inspiron 9400 too (Centrino Duo) also had troubles with the new daemon and firmware but I didn't look any further and reverted to ipw3945-ucode-1.13 and ipw3945d-1.7.18 (without /etc/init.d/ipw3945d). I'm also running udev-087-r1 and rmh3093's kernel patch for ipw3945. Also using kernel built-in ieee802.11 stack. The daemon just auto loads when module ipw3945 is inserted.

----------

## rmh3093

 *VinzC wrote:*   

>  *bmichaelsen wrote:*   I still cant get this driver to work on my Inspiron 9400 [...] 
> 
> That's a problem that many of us had. I've got an Inspiron 9400 too (Centrino Duo) also had troubles with the new daemon and firmware but I didn't look any further and reverted to ipw3945-ucode-1.13 and ipw3945d-1.7.18 (without /etc/init.d/ipw3945d). I'm also running udev-087-r1 and rmh3093's kernel patch for ipw3945. Also using kernel built-in ieee802.11 stack. The daemon just auto loads when module ipw3945 is inserted.

 

can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is... the card in my Acer Travelmate is "8086,1000 rev 02" and I the only issue with the standard ipw3945 drivers (non iwlwifi) is the occasional firmware load error which is fixed by a reboot

...also I am going to start updating http://gentoo-wiki.com/HARDWARE_ipw3945.... us ipw3945 users need to do better at keeping it update

----------

## guru369

[Edit]Solved , Found a good T60 howto and just used his .config

How the hell do I install this driver????

It drives me crazy!!!

See:

```

 Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.19-gentoo-r5/build

 * Found sources for kernel version:

 *     2.6.19-gentoo-r5

 * Checking for suitable kernel configuration options...                                                               [ ok ]

 * net-wireless/ipw3945-1.2.0 does NOT use net-wireless/ieee80211 any more.

 * We are now relying on the in-kernel ieee80211 instead.

 * Please remove net-wireless/ieee80211 using emerge, and remerge

 * your current kernel (2.6.19-gentoo-r5), as it has been altered

 * by net-wireless/ieee80211.

!!! ERROR: net-wireless/ipw3945-1.2.0 failed.

Call stack:

  ebuild.sh, line 1630:   Called dyn_setup

  ebuild.sh, line 702:   Called qa_call 'pkg_setup'

  ebuild.sh, line 38:   Called pkg_setup

  ipw3945-1.2.0.ebuild, line 62:   Called die

!!! Incompatible ieee80211 subsystem detected in 2.6.19-gentoo-r5

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/net-wireless/ipw3945-1.2.0/temp/build.log'.

```

I have already re-emerged my gentoo-sources 2.6.19-r5 3 times enabsled all the ieee80211 subsystem and it still complains!!

Is there any good HowTo??

Please help.

I am using a Thinkpad T60.

Thanks.

Dekel

----------

## VinzC

 *rmh3093 wrote:*   

> [...]
> 
> can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is... the card in my Acer Travelmate is "8086,1000 rev 02" and I the only issue with the standard ipw3945 drivers (non iwlwifi) is the occasional firmware load error which is fixed by a reboot

 

Sorry for being late as I've been busy making this f*** ipw3945 work in bridge mode. I've tried anything I could, no way. I remember you gave a few instructions to run on my computer but everytime I try the bridge port 2 (wireless card) goes flapping between disabled/learning states  :Evil or Very Mad:  .

As for what you asked, here's the info:

```
...

PCI: 0c:00:0: chip 8086,4222 card 8086,1021 rev 02 class 02,80,00 hdr 00

...
```

```
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
```

----------

## rmh3093

 *VinzC wrote:*   

>  *rmh3093 wrote:*   [...]can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is... the card in my Acer Travelmate is "8086,1000 rev 02" and I the only issue with the standard ipw3945 drivers (non iwlwifi) is the occasional firmware load error which is fixed by a reboot 
> 
> Sorry for being late as I've been busy making this f*** ipw3945 work in bridge mode. I've tried anything I could, no way. I remember you gave a few instructions to run on my computer but everytime I try the bridge port 2 (wireless card) goes flapping between disabled/learning states  .
> 
> As for what you asked, here's the info:
> ...

 

awesome... you have a different card as I do.... for anyone that is having issues with their card ( or for those that this is working properly) could you also provide the info above

----------

## VinzC

Aaah, I finally got it!

```
#!/bin/bash

WLAN=eth1

BRIDGE=br0

# Bring up all network but wireless interfaces

ifconfig eth0 up

# ifconfig ${WLAN} up

# Create bridge and bring it up

brctl addbr ${BRIDGE}

brctl stp br0 on

ifconfig ${BRIDGE} up

# Associate with an access point

wpa_supplicant -Dwext -c/etc/wpa_supplicant/minimal.conf -W -B -i${WLAN} -b${BRIDGE} -P/var/run/wpa_supplicant-${WLAN}.pid

wpa_cli -a/etc/wpa_supplicant/wpa_cli.sh -p/var/run/wpa_supplicant -i${WLAN} -P/var/run/wpa_cli-${WLAN}.pid -B

# Add bridge interfaces on the fly

sleep 3s

brctl addif ${BRIDGE} eth0 && brctl addif ${BRIDGE} ${WLAN}

dhcpcd -h $(uname -n) ${BRIDGE}
```

First I must activate and associate the wireless network with an access point *before* I add it to the bridge hence the bridge must be built on-the-fly. Next I must wait a little (3s here, as an example) before I add the wireless interface to the bridge otherwise it flaps between listening/disabled states. I haven't tried any other delay yet. However I wonder why wait. I suspect the wireless card has to settle up completely before it can be added to the bridge.

----------

## bmichaelsen

 *rmh3093 wrote:*   

> 
> 
> can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is... 

 

```
PCI: 0c:00:0: chip 8086,4222 card 8086,1021 rev 02 class 02,80,00 hdr 00

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

        Subsystem: Intel Corporation Unknown device 1021

        Flags: bus master, fast devsel, latency 0, IRQ 17

        Memory at dfcff000 (32-bit, non-prefetchable) [size=4K]

        Capabilities: [c8] Power Management version 2

        Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

        Capabilities: [e0] Express Legacy Endpoint IRQ 0

        Capabilities: [100] Advanced Error Reporting

        Capabilities: [140] Device Serial Number XXX 
```

----------

## rmh3093

 *bmichaelsen wrote:*   

>  *rmh3093 wrote:*   
> 
> can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is...  
> 
> ```
> ...

 

so everyone with version "8086,1021 rev 02" has issues with 1.2.0 correct?

----------

## Lloeki

 *Quote:*   

> PCI: 0c:00:0: chip 8086,4222 card 8086,1021 rev 02 class 02,80,00 hdr 00

 

no problems here. at all.

well, I'm kind of lying, only problem I have is: I mentioned un-idle disassociations issues previously, this seems to be caused by a whacky AP: moved from my freebox (all-in-one box on a french ISP) back to my wrt54gv5+ddwrt for the wireless side, and not a single issue. but that's not relevant to the above problem.

----------

## VinzC

 *rmh3093 wrote:*   

> [...]so everyone with version "8086,1021 rev 02" has issues with 1.2.0 correct?

 

Not quite true since I'm using your patch ipw3945-1.2.0_for_2.6.19.patch and everything is Ok. Just that I didn't use portage latest firmware and daemon because I ran into troubles at that time. With the daemon ( 1.7.18 ) and microcode (1.13) I'm currently using I experienced no troubles at all.

----------

## Joebel

 *rmh3093 wrote:*   

>  *bmichaelsen wrote:*    *rmh3093 wrote:*   
> 
> can you run 'pcitweak -l' and on the line for your ipw3945 card (the one with "0c:00.0"), can you tell me what the "card" vendor and product id is...  
> 
> ```
> ...

 

Can't say about everyone, but I am having lots of problems with 1.2.0, and:

```
PCI: 0c:00:0: chip 8086,4222 card 8086,1021 rev 02 
```

hope this helps

----------

## damage1986

 *bmichaelsen wrote:*   

> I still cant get this driver to work on my Inspiron 9400:
> 
> This is the relevant dmesg output:
> 
> On Boot:
> ...

 

i have exactly the same problem...

could anyone solve it?

----------

## fumoffu

Yep, same here, BUT I only get

```
ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
```

if there is no configuration in /etc/conf.d/net for the device. Otherwise it starts up fine. However, this being the case I am not very flexible and cannot change wlan networks that easily.

----------

## jwaixs

Hello,

I want to emerge ipw3945 on my x60s laptop. So I tried to install it with portage, but I got the following error.

```
 * net-wireless/ipw3945-1.2.0 does NOT use net-wireless/ieee80211 any more.

 * We are now relying on the in-kernel ieee80211 instead.

 * Please remove net-wireless/ieee80211 using emerge, and remerge

 * your current kernel (2.6.19-suspend2-r3), as it has been altered

 * by net-wireless/ieee80211.

!!! ERROR: net-wireless/ipw3945-1.2.0 failed.

Call stack:

  ebuild.sh, line 1630:   Called dyn_setup

  ebuild.sh, line 702:   Called qa_call 'pkg_setup'

  ebuild.sh, line 38:   Called pkg_setup

  ipw3945-1.2.0.ebuild, line 62:   Called die

!!! Incompatible ieee80211 subsystem detected in 2.6.19-suspend2-r3

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/net-wireless/ipw3945-1.2.0/temp/build.log'.

```

So I tried to compile ieee80211 with my kernel but when I start compiling I get this error.

```
  CHK     include/linux/version.h

  CHK     include/linux/utsrelease.h

  CHK     include/linux/compile.h

make[2]: *** No rule to make target `net/ieee80211/ieee80211_module.o', needed by `net/ieee80211/ieee80211.o'.  Stop.

make[1]: *** [net/ieee80211] Error 2

make: *** [net] Error 2

```

Does someone know how to solve this?

Noud[/code]

----------

## VinzC

 *jwaixs wrote:*   

> Does someone know how to solve this?
> 
> Noud

 

emerge -aC ieee80211Clean your entire kernel source tree (along with compiled modules)emerge and compile your kernel source tree againemerge ipw3945

Post your results here.

----------

## nocive

Hi all!

I own a Toshiba laptop P100-400 with ipw3945 adapter.

I've managed to get it working with normal WEP authentication, but not with wpa_supplicant (and I really need it for WPA auth).

I've tryed some of the workarounds presented in this post but with no success.

```

# /etc/init.d/net.eth1 restart

* Stopping eth1

*   Bringing down eth1

*     Stopping dhcpcd on eth1 ...                                                                                                                                         [ ok ]

*     Shutting down eth1 ...                                                                                                                                              [ ok ]

*     Stopping wpa_cli on eth1 ...                                                                                                                                        [ ok ]

*     Stopping wpa_supplicant on eth1 ...                                                                                                                                 [ ok ]

* Starting eth1

*   Starting wpa_supplicant on eth1 ...

ioctl[SIOCSIWMODE]: Resource temporarily unavailable

Could not configure driver to use managed mode

ioctl[SIOCGIWRANGE]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 7 value 0x1 - ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWENCODEEXT]: Resource temporarily unavailable

ioctl[SIOCSIWAUTH]: Resource temporarily unavailable

WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Resource temporarily unavailable                                                                                                [ ok ]th param 5 value 0x1 -

*   Starting wpa_cli on eth1 ...                                                                                                                                          [ ok ]

*     Failed to configure eth1 in the background

```

```

dmesg output:

ipw3945: Error sending LEDS_CMD: time out after 500ms.

ipw3945: Error sending LEDS_CMD: time out after 500ms.

ipw3945: Error sending LEDS_CMD: time out after 500ms.

ipw3945: request scan called when driver not ready.

ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.

ipw3945: Error sending LEDS_CMD: time out after 500ms.

ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

```

```

Versions:

* gentoo-sources-2.6.19-r5

* internal ieee8021x stack

*  net-wireless/ipw3945

      Latest version available: 1.2.0

      Latest version installed: 1.2.0

*  net-wireless/ipw3945-ucode

      Latest version available: 1.14.2

      Latest version installed: 1.14.2

*  net-wireless/ipw3945d

      Latest version available: 1.7.22-r4

      Latest version installed: 1.7.22-r4

*  net-wireless/wpa_supplicant

      Latest version available: 0.5.7

      Latest version installed: 0.5.7

```

```

# lspci | grep "Wireless"

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

```

```

# pcitweak -l 2>&1 | grep " 03.00.0:"

PCI: 03:00:0: chip 8086,4222 card 8086,1041 rev 02 class 02,80,00 hdr 00

```

```

# iwconfig eth1

eth1      unassociated  ESSID:off/any 

          Mode:Managed  Frequency= 2.462 GHz  Access Point: Not-Associated  

          Bit Rate:0 kb/s   Tx-Power:16 dBm  

          Retry limit:15   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:179   Missed beacon:0

```

```

/etc/conf.d/net (extract):

modules_eth1=( "!plug" "wpa_supplicant" )

wpa_supplicant_eth1="-Dwext"

associate_timeout_eth1="60"

```

```

/etc/wpa_supplicant/wpa_supplicant.conf (extract):

(the problem isn't here though, it fails with all types of configurations)

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

update_config=0

eapol_version=1

ap_scan=0

fast_reauth=1

network={

        ssid="XXXXXXXXXX"

        priority=1

        key_mgmt=NONE

        auth_alg=SHARED

        wep_key0="XXXXXXX"

        wep_tx_keyidx=0

}

```

Sorry for the length.

Any help would be greatly appreciated

Best regards,

José Pedro

----------

## beatryder

I have this:

```

RC_NEED_eth1=("ipw3945d")

modules_eth1=( "wpa_supplicant" "dhcpcd" )

wpa_supplicant_eth1="-Dwext"

dhcpcd_eth1="-t 6000 -d "

preup(){

        if [[ ${IFACE} = "eth1" ]]; then

                echo 0 > /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rf_kill

                sleep 3

        fi

        return 0;

}

```

I have removed anything that was not related to my wireless.

----------

## nocive

That didn't solve it!  :Sad: 

Any ideas?

----------

## mijenix

I noticed that my notebook (Lenovo T60) with the intel 3945 wlan card has now a longer time to connect to my AP.

I use WPA-PSK (TKIP) and static IP, nothing changed on the AP. 

Normally it takes about a few seconds. Now it takes about 4 min to connect.

I see the WLAN LED on my Laptop flickers for about 4 min then it can connect.

Any ideas or someone who noticed the same?

----------

## VinzC

Hi all.

Sorry to revive this long thread but I have a problem  :Very Happy: 

I've had to upgrade udev to version 109-r1 for some reason, getting rid of coldplug and being forced to upgrade ipw3945d (otherwise it produced an error when run by udev). I've also patched my 2.6.20-gentoo-r7 kernel with rmh3093 patch for ipw3945 1.2.0 (kernel 2.6.19 and above), used kernel built-in ieee802.11 stack, upgraded to ipw3945d-1.7.22-r4 and ipw3945-ucode-1.14.2. Now I get an error message when the regulatory daemon is run:

```
2007-05-01 20:42:12 ERROR: Could not find Intel PRO/Wireless 3945ABG Network Connection
```

Has anyone found a fix or a workaround?

EDIT: workaround still needed but I applied the following workaround to make the older ipw3945d (version 1.7.18) run by udev. The trick is to delay the actual daemon startup until *after* fstab is processed - otherwise you get an error "Read-only file system (30)". I had to change the install line in /etc/modules.d/ipw3945d to run a shell script that waits till fstab is processed then runs the daemon:

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /usr/local/sbin/ipw3945-ctrl &

remove ipw3945 /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945
```

I then created a shell script, /usr/local/sbin/ipw3945-ctrl, which checks for the presence of directory /var/run - because /var is mounted on a separate filsystem on my laptop:

```
while [[ ! -d /var/run/ ]]; do

        sleep 1s

done

/sbin/ipw3945d --quiet
```

It works like a charm and I don't have to write an init script to run the daemon for it starts much sooner than the boot init scripts anyways. Note: you can give the shell script any name but ipw3945d.

----------

## Il turisto

Sorry but i'm new with this wifi card and I have a kernel panic.

All works, my wifi card detect the network but I can't connect and if I do a /etc/init.d/net.eth1 restart I receive a kernel panic.

Can you help me please?

edit : I'm usinf kernel 20-r7 from gentoo-sources and I'm on amd64 architecture

----------

## Waninkoko

ipw3945-1.2.1 kernel patch: http://kamikaze.waninkoko.info/misc/ipw3945-1.2.1-2.6.21.patch

----------

## alienvenom

what does using the kernel patch give you over the ebuild?

----------

## VinzC

 *alienvenom wrote:*   

> what does using the kernel patch give you?

 

It allows you to skip the driver from portage.

----------

## broadcast

I don't get a network interface after boot. ipw3945 module is loaded, ipw3945d started.

I have to rmmod ipw3945 and modprobe ipw3945 again, then i get eth2.

Any ideas?..

----------

## m@cCo

Hi all.

I've got a problem with the new gentoo-sources 2.6.21 and the ipw3945 driver. When I try to emerge it I get an error saying that the TKIP options isn't enabled in the kernel. The fact is that there's no option for TKIP in the Networking Options of the kernel!

It follows the detailed error:

```
* Checking for suitable kernel configuration options...

 *   ipw3945-1.2.0 requires support for Wireless LAN drivers (non-hamradio) & Wireless Extensions (CONFIG_NET_RADIO).

 *   CONFIG_IEEE80211_CRYPT_TKIP:        is not set when it should be.

 * Please check to make sure these options are set correctly.

 * Failure to do so may cause unexpected problems.

 * Once you have satisfied these options, please try merging

 * this package again.
```

----------

## xerxesmc

it shows up, when u activate Device Drivers -> Network Device support -> Wireless LAN drivers (non-hamradio) & Wireless Extensions

cheers

----------

## m@cCo

 *xerxesmc wrote:*   

> it shows up, when u activate Device Drivers -> Network Device support -> Wireless LAN drivers (non-hamradio) & Wireless Extensions
> 
> cheers

 That's it, thanks!  :Very Happy: 

That eth cable around the room wasn't that pleasant  :Very Happy: 

----------

## VinzC

 *broadcast wrote:*   

> I don't get a network interface after boot. ipw3945 module is loaded, ipw3945d started.
> 
> I have to rmmod ipw3945 and modprobe ipw3945 again, then i get eth2.
> 
> Any ideas?..

 

Two questions at first:

Do you have a separate filesystem for /var?

Is udev loading the driver? If yes you could try to load it manually after your computer has booted. Normally you should get only eth1, no eth2. So first put blacklist ipw3945 in /etc/modules.d/blacklist (>=udev-104, I think) and modprobe the driver manually.

----------

## broadcast

a: No

b: Yes, udev loads the driver. I added blacklist ipw3945 to /etc/modules.d/blacklist but it loads the driver anyway   :Confused:   (udev-104-r12). eth1 is my regular network card (I forgot to say that).

----------

## boffman

I also had problem with this, I have a HP dv9000 laptop (centrino core 2 duo).

```

# lspci | grep Wireless

02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

```

It felt totally impossible to get the wlan card working in 2.6.20 .. And when I installed 2.6.21 and also applied that patch mentioned, it wouldn't boot any longer - saying it couldn't mount /dev/sdb3 as root. But, it still worked with the 2.6.20 kernel..

Some googling indicated that this is some kind of bug coming with 2.6.21 (I recall I read that a possible fix could be switching the code in /usr/src/linux/drivers/message/fusion/ back to the .20 version?)

However, I emerged back to gentoo-sources 2.6.18-rc7 and there it worked straight off. (Or, at least it detected the card and I got my eth2 when running iwconfig.  :Smile: )

I think I'll wait for some newer kernel before I try again..

----------

## VinzC

 *broadcast wrote:*   

> b: Yes, udev loads the driver. I added blacklist ipw3945 to /etc/modules.d/blacklist but it loads the driver anyway    (udev-104-r12). eth1 is my regular network card (I forgot to say that).

 

So you might want to upgrade to >=udev-110 as on my system udev blacklisting works properly.

----------

## broadcast

I upgraded to udev-111-r1. blacklist still doesn't work  :Confused: 

----------

## VinzC

Sorry I mislead you. File blacklist should reside in /etc/modprobe.d/ . I think /etc/modules.d/ will progressively migrate to /etc/modprobe.d/ .

----------

## broadcast

ok. now, udev doesn't load the driver. that's what i get:

after boot: no driver loaded, no eth2.

modprobe: 

```
# modprobe ipw3945

 * Starting ipw3945d ...                                                  [ ok ]
```

still no eth2.

```
# lsmod | grep ipw

ipw3945               171876  0 

ieee80211              23560  1 ipw3945

firmware_class          6784  1 ipw3945
```

rmmod & modprobe again:

```
# rmmod ipw3945

# modprobe ipw3945

 * WARNING:  ipw3945d has already been started.
```

-> now, eth2 exists  :Confused: 

----------

## VinzC

@broadcast:

Ok, that seems fine to me as - IIRC - the daemon creates the interface, not the module (although I have to check that again). Anyways there's one thing I don't catch: why would you want eth2? I've got two remarks however:

You shouldn't use rmmod to unload ipw3945 but modprobe -r as rmmod doesn't execute the remove instructions in /etc/modules.d/ipw3945d. If you use rmmod, ipw3945d will stay in memory although it should be unloaded, hence modprobe -r.

The next time you run modprobe ipw3945 ipw3945d still runs hence the message

 *Quote:*   

> * WARNING:  ipw3945d has already been started.

 

Since ipw3945d was already running and is responsible for creating the device node, you get an eth2. Still I don't know if it was the intended purpose. Anyways it all demonstrates ipw3945/udev are working properly this time.

Please make sure you have a symlink /etc/init.d/net.eth1 pointing to /etc/init.d/net.lo and setup /etc/conf.d/net as appropriate. If you modprobe ipw3945 manually the system should give you an eth1 device.

BTW: are you using wpa_supplicant or iwconfig?

----------

## broadcast

 *VinzC wrote:*   

> @broadcast:
> 
> why would you want eth2?

 

As I said: eth1 is the network card. eth2 is the wireless card.

ipw3945d still doesn't create the eth2-device when it's started/or ipw3945 modprobed. 

Only when it's started and I rmmod & modprobe again. That's the only way/workaround I found to get the device.

----------

## VinzC

But then what about eth0? Have you renamed interfaces?

EDIT: IIRC the default device name, which ipw3945d creates is eth1. If you want some other name, like wlan0, you should create udev rules appropriately. Don't know if it's what you did - if you did.

----------

## broadcast

oh, good question...

```
/etc/init.d/net.eth0 start

 * Caching service dependencies ...                                       [ ok ]

 * Starting eth0

 *   Bringing up eth0

 *     dhcp

 *       network interface eth0 does not exist

 *       Please verify hardware or kernel module (driver)                 [ !! ]

```

```
dmesg | grep eth

eth0: Tigon3 [partno(BCM95789) rev 4201 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:16:d4:1c:84:11

eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]

eth0: dma_rwctrl[76180000] dma_mask[64-bit]

tg3: eth1: Link is up at 100 Mbps, full duplex.

tg3: eth1: Flow control is on for TX and on for RX.

```

```
# lspci | grep Eth

04:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express (rev 21)

```

that should use the module "tg3"

```
# cat /var/log/boot.msg | grep tg3

*   Loading module tg3 ...

  [ ok ]

```

/etc/conf.d/net

```
# lan

config_eth0=( "dhcp" )

dhcpcd_eth0="-t 5"

# wlan

modules_eth1=( "wpa_supplicant" )

wpa_supplicant_eth1="-Dwext"

config_eth1=( "dhcp" )

dhcp_eth1="nontp nonis"
```

confusing

----------

## VinzC

Well, from all I see here, it looks like tg3 creates *two* interfaces, eth0 and eth1... Maybe tg3 is not the right driver? or could it be that you have it loaded by UDEV and by /etc/modules.autoload.d/kernel-2.6?...

What happens if you load tg3 manually? Basically the test procedure is to load modules and start net scripts manually then see what happens in the logs. Start with the wired Ethernet then the wireless adapter.

EDIT: I'm almost convinced your eth0 is renamed somewhere between

 *Quote:*   

> eth0: dma_rwctrl[76180000] dma_mask[64-bit]

  and

 *Quote:*   

> tg3: eth1: Link is up at 100 Mbps, full duplex.

 

Search /etc/udev/rules.d/* for eth1...

----------

## mikkoc

has anyone tried this alternative driver yet?

http://www.intellinuxwireless.org/

----------

## broadcast

 *VinzC wrote:*   

> Search /etc/udev/rules.d/* for eth1...

 

you were right!

```
# PCI device 0x8086:0x4222 (ipw3945)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:02:90:26:53", NAME="eth2"

# PCI device 0x14e4:0x169d (tg3)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:d4:1c:84:11", NAME="eth1"

# Firewire device 00023f688b407201)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:02:3f:68:8b:40:72:01", NAME="eth0"

```

I never touched this file.

now:

```
# PCI device 0x8086:0x4222 (ipw3945)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:02:90:26:53", NAME="eth1"

# PCI device 0x14e4:0x169d (tg3)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:d4:1c:84:11", NAME="eth0"

# Firewire device 00023f688b407201)

# SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:02:3f:68:8b:40:72:01", NAME="eth0"
```

And I just read this in /etc/modprobe.d/blacklist:

 *Quote:*   

> # Autoloading eth1394 most of the time re-orders your network
> 
> # interfaces, and with buggy kernel 2.6.21, udev persistent-net
> 
> # is not able to rename these devices, so you get eth?_rename devices
> ...

 

Udev messed up the network-devices?

Anyway: 

network card -> eth0.  

ipw3945 blacklisted.

modprobe ipw3945 -> no eth1-device

modprobe -r ipw3945; modprobe ipw3945 -> no eth1-device

rmmod ipw3945; modprobe ipw3945 -> eth1 exists

 :Sad: 

----------

## VinzC

 *mikkoc wrote:*   

> has anyone tried this alternative driver yet?
> 
> http://www.intellinuxwireless.org/

 

See ipw3945 alternative: Intel's iwlwifi (experimental).

----------

## VinzC

@broadcast:

This is probably the content of /etc/udev/rules.d/70-persistent-net.rules. On my system too there is such a file which contains the MAC addresses of both my RealTek adapters - it forces 8139too otherwise 8139cp gets loaded. I think that file is created when you install UDEV. Now you should just leave the file as is (in its original state) but comment out each active line in that file.

To see what network devices you have, take a look at /sys/class/net/*. There you should have every one of your network adapters listed, for which there is a driver loaded. Listed interfaces are not necessarily active. Here's an example:

```
drwxr-xr-x 3 root root 0 mai 26 09:15 eth0

drwxr-xr-x 3 root root 0 mai 26 09:15 eth1

drwxr-xr-x 3 root root 0 mai 26 09:15 lo

drwxr-xr-x 3 root root 0 mai 26 09:15 tun0

drwxr-xr-x 3 root root 0 mai 26 09:15 tunl0
```

First, as I said, load the driver of your Ethernet card. Take a look at dmesg to check what device was created (confirm with the above listing) and start the corresponding script. Repeat with your wireless card.

EDIT: Also make sure the daemon ipw3945d is running (after loading the module) with ps -fC ipw3945d. Wait 2-3 seconds before issuing the ps command. If it is then you should have a /sys/class/net/eth1 and a subdirectory called wireless/.

To be sure your Ethernet card is always eth0, you can compile the driver into the kernel and leave any other one as a module - udev always starts afterwards.

----------

## broadcast

```
# ls -l /sys/class/net/

total 0

drwxr-xr-x 4 root root 0 2007-06-17 14:11 eth0

drwxr-xr-x 4 root root 0 2007-06-17 13:37 lo

drwxr-xr-x 4 root root 0 2007-06-17 13:37 tunl0

```

```
# ps -fC ipw3945d

UID        PID  PPID  C STIME TTY          TIME CMD

root      7916     1  0 14:09 pts/1    00:00:00 /sbin/ipw3945d --pid-file=/var/run/ipw3945d/ipw3945d.pid --timeout=-1 --quiet

```

then I activate the wireless-card.

```
# ls -l /sys/class/net/

total 0

drwxr-xr-x 4 root root 0 2007-06-17 14:11 eth0

drwxr-xr-x 4 root root 0 2007-06-17 13:37 lo

drwxr-xr-x 4 root root 0 2007-06-17 13:37 tunl0

```

no device

just for fun:

```
# rmmod ipw3945

# modprobe ipw3945

 * WARNING:  ipw3945d has already been started.

# ls -l /sys/class/net/

total 0

drwxr-xr-x 4 root root 0 2007-06-17 14:11 eth0

drwxr-xr-x 5 root root 0 2007-06-17 14:18 eth1

drwxr-xr-x 4 root root 0 2007-06-17 13:37 lo

drwxr-xr-x 4 root root 0 2007-06-17 13:37 tunl0
```

----------

## VinzC

@broadcast:

Ok, let's make it the hard way then  :Smile: .

I. After booting your computer make sure a) ipw3945d is *not* running (run ps -fC ipw3945d) and b) ipw3945 is *not* loaded (run lsmod | grep ipw3945). If the module is loaded, unload it (you *must* use modprobe -r instead of rmmod) and redo the above tests. If the daemon is running, run ipw3945d --kill. You will now have a clean startup point.

II. Now load ipw3945 module and see what happens:run lsmod | grep ipw3945run ps -fC ipw3945drun dmesg | grep 3945run find /sys/class/net/ -name wirelessEDIT: Wireless interfaces have a sub-directory wireless under /sys/class/net/eth?/. Post the results here.

----------

## Phk

(sorry to disturb this 30-page post, but i'm having a few problems with the iwlwifi driver. Now, i believe i loved ipw3945.. it worked sooo well...  :Smile:   Can i use it on the new 2.6.22 kernel? Please PM-me or post here the patch link... if there is  :Sad:  thanks!)

----------

## VinzC

Hi.

I have a Centrino Duo (Core2 Duo) and I'm still using the good old ipw3945 driver and I'm not sure I'll switch to iwlwifi before it comes (even testing) into portage. Not that I distrust it but I'm still quite busy with some other package tweakings I don't feel like tweaking that one too  :Smile:  - at least it's not yet vital to me.

----------

## Phk

 *VinzC wrote:*   

> Hi.
> 
> I have a Centrino Duo (Core2 Duo) and I'm still using the good old ipw3945 driver and I'm not sure I'll switch to iwlwifi before it comes (even testing) into portage. Not that I distrust it but I'm still quite busy with some other package tweakings I don't feel like tweaking that one too  - at least it's not yet vital to me.

 

And what kernel version do you have? Did you need to patch it ?

Thanks

----------

## rmh3093

 *Phk wrote:*   

>  *VinzC wrote:*   Hi.
> 
> I have a Centrino Duo (Core2 Duo) and I'm still using the good old ipw3945 driver and I'm not sure I'll switch to iwlwifi before it comes (even testing) into portage. Not that I distrust it but I'm still quite busy with some other package tweakings I don't feel like tweaking that one too  - at least it's not yet vital to me. 
> 
> And what kernel version do you have? Did you need to patch it ?
> ...

 

I have a kernel patch for the new iwl3945 driver... it works on any kernel with mac80211 included

----------

## Phk

 *rmh3093 wrote:*   

>  *Phk wrote:*    *VinzC wrote:*   Hi.
> 
> I have a Centrino Duo (Core2 Duo) and I'm still using the good old ipw3945 driver and I'm not sure I'll switch to iwlwifi before it comes (even testing) into portage. Not that I distrust it but I'm still quite busy with some other package tweakings I don't feel like tweaking that one too  - at least it's not yet vital to me. 
> 
> And what kernel version do you have? Did you need to patch it ?
> ...

 

Precisely, i use the latest skunk-sources, so, i use the new iwl3945...

I was asking for a patch to make ipw3945 work with 2.6.22...

IWL is still giving me the problems i told you  :Sad: 

Cheers

----------

## dayul

 *Phk wrote:*   

> 
> 
> Precisely, i use the latest skunk-sources, so, i use the new iwl3945...
> 
> I was asking for a patch to make ipw3945 work with 2.6.22...
> ...

 

Well as far as i am aware i am using ipw3945 with kernel 2.6.22 (ck-sources).  It's working fine for me.

----------

## VinzC

 *VinzC wrote:*   

> Hi.
> 
> I have a Centrino Duo (Core2 Duo) and I'm still using the good old ipw3945 driver and I'm not sure I'll switch to iwlwifi before it comes (even testing) into portage. Not that I distrust it but I'm still quite busy with some other package tweakings I don't feel like tweaking that one too  - at least it's not yet vital to me.

 

 *Phk wrote:*   

> And what kernel version do you have? Did you need to patch it ?
> 
> Thanks

 

Woops! just saw your post  :Sad:  . I'm still sticking to the 2.6.21 series (Gentoo sources). And I'm using rmh3093 version 1.2 patch.

----------

## thelee

sorry to break the flow of this massive thread, but i've been trying to get my 3945 intel wireless card working; been using the gentoo-wiki page and looking for resources online.  I can finally load both ipw3945 and ipw3945d without any error, but my card still isn't being detected; that is, i can't do anything useful (like iwlist eth1 scan), and the output for ifconfig eth1 hasn't actually changed since before installing the driver/daemon.  Any help?  I can put up the output of anything if you need it.

----------

## VinzC

 *thelee wrote:*   

> sorry to break the flow of this massive thread, but i've been trying to get my 3945 intel wireless card working; been using the gentoo-wiki page and looking for resources online.  I can finally load both ipw3945 and ipw3945d without any error, but my card still isn't being detected; that is, i can't do anything useful (like iwlist eth1 scan), and the output for ifconfig eth1 hasn't actually changed since before installing the driver/daemon.  Any help?  I can put up the output of anything if you need it.

 

Downgrade both to ipw3945-ucode-1.14.2 and ipw3945d-1.7.18. EDIT: BTW are you using x86 or x86_64? (My comment was valid for x86_64 in fact.)

----------

## thelee

I use x86.  Why would I need to downgrade if i used x86_64?

Incidentally, I'm a bit confused as to the difference between portage ipw3945, *d, and *-ucode, and the ones I can download from the appropraite places on sourceforge (from ipw3954.sourceforge.net and places)?  I've been thinking of unmerging my portage packages and redownloading the equivalents from the various sf projects, but would this actually make a difference?

----------

## VinzC

 *thelee wrote:*   

> I use x86.  Why would I need to downgrade if i used x86_64?

 

Because I'm now using x86_64 and the latest versions didn't work for me - like for some other people. The kernel module loaded but I got an error message saying an "Intel/Pro Wireless 3945ABG could not be detected". And I did try the latest version on x86_64 only.

So I downgraded both packages and they worked again. I have had to mask the latest version of both packages however since they're marked stable in portage. Note the latest version is easy to recognize: it's the one with the ipw3945d init script.

Conclusion: try downgrading and see if it works  :Smile:  .

 *thelee wrote:*   

> Incidentally, I'm a bit confused as to the difference between portage ipw3945, *d, and *-ucode, and the ones I can download from the appropraite places on sourceforge (from ipw3954.sourceforge.net and places)?  I've been thinking of unmerging my portage packages and redownloading the equivalents from the various sf projects, but would this actually make a difference?

 

They're exactly the same. The versions you find at Sourceforge might be a little more recent than the ones you find in portage, especially if these are changing fast. But ipw3945 is now quite... erm... stable and don't change that much so portage provides you with the exact same versions as on Intel's web site. Except Gentoo dev's have adapted these for Gentoo.

----------

## VinzC

Hi all.

Intel has updated ipw3945 module and daemon for a "better" support of udev. Unfortunately it doesn't always work quite well and either you get an error message saying the hardware is not found or the daemon refuse to run. I've investigated a little on my system as to why the daemon doesn't run when the driver is loaded by udev although it did before.

I first saw the module was correctly loaded by udev but as the root filesystem is read-only when udev loads modules, ipw3945d, which is run almost in the same time, has no chance to create its PID file and aborts, leaving the system with no functional wireless network. If you modprobe -r ipw3945 then modprobe ipw3945 manually, it works. That's the symptom my script wants to fix.

So I came up with this script, which I've been using without any problem for several weeks. It is launched upon inserting module ipw3945. It waits until the root filesystem (or /var in my case) is writable so that the daemon can write its PID file. As things don't necessarily go right on the first try  :Wink:  the script makes several attempts before giving up.

I've checked the script on my laptop, a newer Dell Inspiron 9400 with a Core2 Duo (x86_64) but it should run on x86 as well.

Prerequisites

>=udev-104

=ipw3945d-1.7.18

=ipw3945-ucode-1.14.2

>=gentoo-sources-2.6.21 (2.6.22.* yet to be confirmed)

ipw3945 1.2 - patch from rmh3093 (do not use portage's):

http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.19.patch or

http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.20.patchReminder: You will have to unmerge ipw3945 if you used the module from portage. Patch your kernel tree only after the module is removed. Sometimes you may find it's safer to make mrproper before recompiling your kernel. (Don't forget to save your kernel config beforehand or use zcat /proc/config.gz > /usr/src/linux/.config && make oldconfig afterwards if you didn't.)

The script uses ipw3945 insert/remove instructions to run the daemon as those defined in /etc/modules.d/ipw3945d. I know there are some of you who reported these instructions didn't work so it's not a solution for these cases. My script runs on systems where ipw3945d was actually running automatically *without* using the /etc/init.d/ipw3945d init script hence the versions of ipw3945d I mentioned above.

You can however check if the daemon actually runs when ipw3945 is inserted: first make sure the daemon is not running then do a modprobe ipw3945. You might as well clean out ipw3945 packages and reboot without it so you'll be 100% sure there's no daemon running when you make the tests. (Make sure you have an alternate connection to the Internet or you have the packages actually saved in ${DISTDIR}...)

Then emerge =ipw3945d-1.7.18 =ipw3945-ucode-1.14.2 and modprobe ipw3945. If you see the WiFi LED blinking or lit then the daemon was successfully run. Note you might want to disable wireless network scripts for the test.

You will then need a modified /etc/modules.d/ipw3945d:

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /usr/local/sbin/ipw3945-ctrl

remove ipw3945 /usr/local/sbin/ipw3945-ctrl stop; /sbin/modprobe -r --ignore-remove ipw3945
```

Watch out since it will be overwritten each time you emerge ipw3945d.

Getting started

Put the following script in /usr/local/sbin and edit /etc/modules.d/ipw3945d as indicated above.

```
# This script delays loading ipw3945 until root filesystem becomes mounted

# read/write as the kernel module is now loaded by udev and the daemon wants

# to create a PID file. This script was tested on a system with /var mounted

# from a specific partition.

#

# The script requires udev-104 or above for udev to correctly process module

# insert and remove instructions. File /etc/init.d/modules.d/ipw3945d also

# needs to be changed to run this script instead of /sbin/ipw3945d.

#

# Author: Vince C. (2007)

# Default to "start" command in daemon mode when run with no argument

if [[ -z "$1" ]]; then

        /usr/bin/logger -t ipw3945d "Running in the background"

        $0 start &

        exit 0

fi

CMD=${1:-start}

PIDFILE=/var/run/ipw3945d.pid

# Remove pid file if it exists for it is not deleted

# when the system shuts down.

remove_pid_file() {

        [[ -f ${PIDFILE} ]] && \

        logger -t ipw3945d "Removing PID file" && \

        rm ${PIDFILE} 2>/dev/null

}

case ${CMD} in

        "start")

                # Run daemon as soon as /var/run is present and

                # writeable

                remove_pid_file

                while [[ ! -d /var/run/ ]]; do

                        sleep 1s

                done

                (( TRY=0 ))

                while ! /sbin/ipw3945d --quiet 2>/dev/null && [[ $TRY < 10 ]]; do

                        sleep 0.5s

                        remove_pid_file

                        (( TRY++ ))

                done

                ;;

        "stop")

                if [[ -f ${PIDFILE} ]]; then

                        logger -t ipw3945d "Stopping daemon (PID: $(cat ${PIDFILE}))"

                        /sbin/ipw3945d --kill

                elif ! pidof ipw3945d > /dev/null; then

                        logger -t ipw3945d "killing daemon (PID: $(cat ${PIDFILE}))"

                        killall -9 ipw3945d

                fi

                ;;

esac
```

You should now see the WiFi led blink as soon as / is mounted read/write when you reboot your laptop.

----------

## thelee

 *VinzC wrote:*   

>  *thelee wrote:*   I use x86.  Why would I need to downgrade if i used x86_64? 
> 
> Because I'm now using x86_64 and the latest versions didn't work for me - like for some other people. The kernel module loaded but I got an error message saying an "Intel/Pro Wireless 3945ABG could not be detected". And I did try the latest version on x86_64 only.
> 
> So I downgraded both packages and they worked again. I have had to mask the latest version of both packages however since they're marked stable in portage. Note the latest version is easy to recognize: it's the one with the ipw3945d init script.
> ...

 

Downgrading appeared to do the trick, as after downgrading my daemon and firmware, fixing the config file, and running modules-update, eth2 appeared and my wifi led started to blink in glorious victory.

I do have a question about portage dependencies, as what I originally did was unmerge all ipw3945-related stuff and try to emerge all but the newest versions using a package.mask entry.  However, the older ipw3945 driver wanted to bring in an older ieee80211 module, which I didn't want, and if I tried to emerge the newer ipw3945 driver, it would complain that I had masked a necessary ipw3945d dependency.  What I ended up doing was merging all the new drivers, then specifically downgrading the daemon and microcode, leaving the ipw3945 driver at the newest version.  However, it feels like I should be worried about this direct contravention of portage's dependency tree...  I mean, I'm new to this stuff but it would seem like that dependency on the newer daemon was for a reason...

----------

## VinzC

 *thelee wrote:*   

> I do have a question about portage dependencies, as what I originally did was unmerge all ipw3945-related stuff and try to emerge all but the newest versions using a package.mask entry.  However, the older ipw3945 driver wanted to bring in an older ieee80211 module, which I didn't want, and if I tried to emerge the newer ipw3945 driver, it would complain that I had masked a necessary ipw3945d dependency.  What I ended up doing was merging all the new drivers, then specifically downgrading the daemon and microcode, leaving the ipw3945 driver at the newest version.  However, it feels like I should be worried about this direct contravention of portage's dependency tree...  I mean, I'm new to this stuff but it would seem like that dependency on the newer daemon was for a reason...

 

That's why I (and probably most of us, reading this thread since the very beginning) use rmh3093's patch, which includes ipw3945 driver in the kernel; I don't use portages's but only the daemon and firmware. I don't remember the exact location in this thread where the link to the patch is but I'll try to find it back for you if you want.

Here's a preview of my /etc/portage/package.mask, maybe you'll find it useful:

```
>net-wireless/ipw3945d-1.7.18
```

EDIT: Here they are

http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.19.patch and

http://www.rit.edu/~rmh3093/ipw3945-1.2.0_for_2.6.20.patch

The latter is also valid with 2.6.21 series (I've flawlessly patched gentoo-sources-2.6.21 until -r4 with that one).

Also be sure to use kernel built-in ieee80211 instead of portage's. I forgot to mention that before.

----------

## mamac

Hi,

After emerge -uDN world (and kernel upgrade) my wireless driver was down complaining with the famous "Intel/Pro Wireless 3945ABG could not be detected".

I'm quite surprised that after an "update-modules force" the wireless works again with net-wireless/ipw3945 1.2.0, ipw3945-ucode 1.14.2 and ipw3945d 1.7.22-r4.

Cheers

----------

## rmh3093

you all should be using the iwl3945 drivers now.... they should work fine for everyone, if they dont, then go to #ipw2100 on freenode and they will fix it

----------

## beatryder

 *rmh3093 wrote:*   

> you all should be using the iwl3945 drivers now.... they should work fine for everyone, if they dont, then go to #ipw2100 on freenode and they will fix it

 

Until they *do* work fine for everyone I will be sticking w/ ipw3945. Last time I tried the iwl3945 my wireless LED did not come on.

----------

## VinzC

 *beatryder wrote:*   

> Until they *do* work fine for everyone [...]

 

I'd have said "most of us" instead  :Wink:  ...

----------

## gzaa

hello everyone, I am using this forum frequently and it always helped me without asking something, but ipw3945 just changed that. I simply do not know what to do next. I think I used all the resources (or maybe I simply missed something).

I am running on gentoo 2.6.21-r4. I have a HP nx6310 with intel wireless 3945abg. I managed to emerge ipw3945 and ipw3945d. Now when I make modprobe ipw3945 I get this >>

 *Quote:*   

> 
> 
> shaolin linux # modprobe ipw3945
> 
> FATAL: Error inserting ipw3945 (/lib/modules/2.6.21-gentoo-r4/net/wireless/ipw3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)
> ...

 

dmesg says >>

 *Quote:*   

> 
> 
> ipw3945: Unknown symbol iw_handler_set_spy
> 
> ipw3945: Unknown symbol iw_handler_get_thrspy
> ...

 

I tried to google this, but I didnt find anything helpful. I guess this has something to do with missing modules, but I am lost in this.

here another output >>

 *Quote:*   

> 
> 
> shaolin linux # cat .config | grep IEEE80211
> 
> CONFIG_IEEE80211=y
> ...

 

Hope you guys can help me with this.

----------

## VinzC

 *gzaa wrote:*   

> hello everyone, I am using this forum frequently and it always helped me without asking something, but ipw3945 just changed that. I simply do not know what to do next. I think I used all the resources (or maybe I simply missed something).
> 
> I am running on gentoo 2.6.21-r4. [...]
> 
> Hope you guys can help me with this.

 

Follow these steps, just above.

----------

## rmh3093

 *beatryder wrote:*   

>  *rmh3093 wrote:*   you all should be using the iwl3945 drivers now.... they should work fine for everyone, if they dont, then go to #ipw2100 on freenode and they will fix it 
> 
> Until they *do* work fine for everyone I will be sticking w/ ipw3945. Last time I tried the iwl3945 my wireless LED did not come on.

 

that is just a cosmetic thing, yes the led triggers are not connected yet (as of the version im using which is not the latest though), but wireless functionality should work fine

----------

## beatryder

 *rmh3093 wrote:*   

>  *beatryder wrote:*    *rmh3093 wrote:*   you all should be using the iwl3945 drivers now.... they should work fine for everyone, if they dont, then go to #ipw2100 on freenode and they will fix it 
> 
> Until they *do* work fine for everyone I will be sticking w/ ipw3945. Last time I tried the iwl3945 my wireless LED did not come on. 
> 
> that is just a cosmetic thing, yes the led triggers are not connected yet (as of the version im using which is not the latest though), but wireless functionality should work fine

 

Well, I can appreciate that, but until one of two things happens:

1) They fix the LED (it's only cosmetic I know, but I am superficial and fickle)

2) The Gentoo maintainers of the packages state officially that they are no longer supporting the old method.

I will be honest, I don't mind the regulatory daemon since my wifi has always worked since I first installed it.

----------

## gzaa

 *VinzC wrote:*   

>  *gzaa wrote:*   hello everyone, I am using this forum frequently and it always helped me without asking something, but ipw3945 just changed that. I simply do not know what to do next. I think I used all the resources (or maybe I simply missed something).
> 
> I am running on gentoo 2.6.21-r4. [...]
> 
> Hope you guys can help me with this. 
> ...

 

well, it wasn't necessary after all. I found out I was giving wrong path to the /boot for the freshly compiled image   :Rolling Eyes:  so Unknown symbol in module means that the modules were not compiled for the actual kernel.

----------

## rmh3093

 *beatryder wrote:*   

>  *rmh3093 wrote:*   you all should be using the iwl3945 drivers now.... they should work fine for everyone, if they dont, then go to #ipw2100 on freenode and they will fix it 
> 
> Until they *do* work fine for everyone I will be sticking w/ ipw3945. Last time I tried the iwl3945 my wireless LED did not come on.

 

My LED works!!!!!!!!!!!!! Muuuaaaaaa hahahahahah!!!!!

----------

## swimmer

 *rmh3093 wrote:*   

> My LED works!!!!!!!!!!!!! Muuuaaaaaa hahahahahah!!!!!

 Do you mind sharing with us how you got them working?

Greetz

swimmer

----------

## rmh3093

 *swimmer wrote:*   

>  *rmh3093 wrote:*   My LED works!!!!!!!!!!!!! Muuuaaaaaa hahahahahah!!!!! Do you mind sharing with us how you got them working?
> 
> Greetz
> 
> swimmer

 

im testing out a new patch.... it might be in git soon

----------

## bebobero

I am new to this i have tried iwlwifi and the old ipw3945 but it seems i ccorrupted my installation so i reinstalled and recompiled kernel and emerged gnome can anyone help me install the ipw3945 driver and tell me how to configure it? also it seems that the Wireless switch i have is software based because it is always off!

Please help

Regards,

Bebobero

----------

## mamac

hi,

Can you post the output of 'emerge --info', 'lspci' and 'lsmod'?

Thanks

----------

