Bugzilla Bug 142560

See https://bugs.gentoo.org/show_bug.cgi?id=142518#c4 for the details.

I've done some testing and messing around and I think that, basically, there
are three ways of fixing this.

1. Get udev to use modules.conf somehow. I have no idea on how to do this, and
one would still be left with #140067. Also, the current system with the
modules.d entry runs ipw3945d as root.
2. Get udev to start ipw3945d when ipw3945 is loaded, for instance with a
DRIVER rule. The big problem with this is that udev only starts to act if both
the ipw3945 module AND ipw3945d are loaded. If the module is loaded without the
daemon it acts rather strange, possibly causing this behaviour. It is present
in lsmod and shows up in ps -A, yet when I unload it with modprobe -r it says
something about it not being present. Without the daemon, the module acts like
an empty shell. While one could write an udev rule to start the daemon without
any condition, I do not think this would be a great solution.
3. Use an init script. This was apparently also what brix was working on (see
http://dev.gentoo.org/~brix/files/overlay/net-wireless/ipw3945d/). While this
may seem like the best solution I think there is at least one drawback: I guess
the daemon will start to late for RC_PLUG_SERVICES to work.

https://forums.gentoo.org/viewtopic-t-434817-postdays-0-postorder-asc-start-150.html

That guy has a much simpler init script that actually works.

I have ipw3945-1.1.0 and ipw3945d-1.7.22-r2

On boot, there is no connectivity.
There are no errors in dmesg
lsmod indicates ipw3945 is loaded
ps ax shows ipw3945d is running

However, the only way to get connectivity is to follow seemant's suggestion in
http://bugs.gentoo.org/show_bug.cgi?id=142518 and

rmmod ipw3945
modprobe ipw3945

both ip3945 and ipw3945d are recent upgrades, and this is when thing stopped
working.

Am I in the right bug or is this something new?

as noted on the forum thread (page 11), the init script in ipw3945d-1.7.22-r2
works as expected if you remove the --chuid.

starts okay now, but doesn't shut down if you do /etc/init.d/ipw3945 stop.

At my PC when the initial load of the IPW3954 driver succeded, the network will
be up before the ipw3945d script will try to reload the driver. The result is
that the driver is reloaded from an up eth link.

After that I will have to reboot my system to get a working wireless again. :-(

*** Bug 153778 has been marked as a duplicate of this bug. ***

Created an attachment (id=104887) [details]
/etc/init.d/ipw3945d

(In reply to comment #7)
> *** Bug 153778 has been marked as a duplicate of this bug. ***
> 
I found the same problem, but kept noticing an error that stated something
along the lines of an invalid command concerning the checking for a PID file. 
I traced it back to /etc/init.d/ipw3945d, specifically the lines reading:
<ul>
        start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} --
\
                --pid-file=${PIDFILE} ${ARGS}
</ul>

Anyhow, I reverted back to an older /etc/inid.d/ipw3945d file and everything
works perfectly now.  Don't know if this is the solution, but it could help
troubleshoot.  Attached is the file I'm using now.

I just upgraded to ipw3945d-1.7.22-r4 and now ipw3945d won't start. I found out
that the problem is that /var/run/ipw3945d isn't writable by the user ipw3945d.
The ebuild says that it is "Fixing ownership of /var/run/ipw3945d" but it
doesn't seem to work. I manually had to chown /var/run/ipw3945d to ipw3945d.
That fixed the problem for me.

(In reply to comment #9)
> I just upgraded to ipw3945d-1.7.22-r4 and now ipw3945d won't start. I found out
> that the problem is that /var/run/ipw3945d isn't writable by the user ipw3945d.
> The ebuild says that it is "Fixing ownership of /var/run/ipw3945d" but it
> doesn't seem to work. I manually had to chown /var/run/ipw3945d to ipw3945d.
> That fixed the problem for me.

Problem is with fperms / fowners. Looks like they don't behave like they should
do. Fixed now to use chown / chmod.

(In reply to comment #10)
> Problem is with fperms / fowners. Looks like they don't behave like they should
> do. Fixed now to use chown / chmod.

Forgot to mention. Sync up in an hour or so and then remerge the package.

*** Bug 159710 has been marked as a duplicate of this bug. ***