Hi Bob,
> > > Running pm-suspend from pm-utils directly also triggers the problem,
> > > so that would seem to excuse gnome-power-manager at least.
> >
> > What's the status of this? Should I look into things a bit?
>
> Well, I guess I should have noticed this a lot earlier, but anyway the
> problem was pm-utils on Fedora 10:
>
> /usr/lib/pm-utils/sleep.d/55NetworkManager:
>
> suspend_nm()
> {
> # Tell NetworkManager to shut down networking
> dbus-send --system \
> --dest=org.freedesktop.NetworkManager \
> /org/freedesktop/NetworkManager \
> org.freedesktop.NetworkManager.sleep
> }
>
> I really don't think this is necessary (g-p-m will also do it if you
> set the proper gconf setting.)
this should not be needed at all. I have systems running wpa_supplicant
and not any of the pm-utils scripts messing with it. During suspend and
later resume it indicates normally just only a new handshake with the AP
or a disconnect if the AP got out of range.
I think Network Manager is perfectly capable of handling state changes
from wpa_supplicant. I really do think that this hack only exists of
some broken drivers from really old kernels or for the 0.6 version of
Network Manager. Remember that Ubuntu's suspend/resume solution used to
be to unload all networking drivers on suspend.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
