On Wed, 2005-10-12 at 13:03 -0300, Derek Broughton wrote: > > Just some additional comments: In my case, with ifplugd running, I > > cannot even get eth0 down. That is, if I remove the cable, do 'ifconfig > > eth0 down', eth0 is still UP. Only after stopping ifplugd, I can take > > eth0 down. > That seems a little weak. The default setup is supposed to issue 'ifdown > eth0' when it loses the link beat. What value is there to ifplugd if it > doesn't notice your cable is unplugged?
There is a difference between 'ifdown/ifup eth0' and 'ifconfig eth0 down/up'. I think 'ifconfig eth0 up' puts the network card in an 'up' state as far as the kernel concerns, while 'ifup eth0' does everything you tell it to in the /etc/network/interfaces file (such as calling the dhcp client). So, if the device is still down, ifplugd cannot do anything with it. It needs to be up, so ifplugd can 'scan' it (with whatever method you tell it to use). Once the link is detected, ifplugd calls ifup. > Looking at the file list in the package, it would probably only work with > APM suspends. In a perfect world, since the driver module gets removed on It seems so, but it is poorly documented. (I don't blame the ifplugd author, but it seems that the Debian package is 'less than mature'.) > acpi hibernate and reloaded on resume, ifplugd should take the interface > down when it sees the missing link-beat (which would be right after the > initial reloading of the module), and bring it up again on it's own. > Likely there isn't enough up-time between losing the link-beat and getting > it back for ifplugd to notice it's gone - ime, ifplugd is fairly slow to > react. I find that when I unplug the laptop, take it down the hall to the > conference room, and plug it back in, ifplugd works fine. It's when I want > it to react within 20 or 30 seconds (which is about the observed time it > experiences between hibernate & resume) that it gets confused. ifplugd may not notice a missing link at all. It's like falling to sleep and waking up at a different place. If you don't know you were sleeping, you're pretty confused when you open your eyes in a different environment. This also happens to the network config. So, the interfaces should be reconfigured after resuming. But more importantly: I don't find ifplugd slow, so that again points at the b44 driver... In my case, it detects (the loss of) the link-beat nearly instantaneously. After that, it waits the specified number of seconds before actually (de)configuring the network device. You mentioned that ifplugd requires mii-tool. AFAIK, that's not correct; you can specify the method of link-beat detection, and one of them is mii-tool. Maybe it's just a matter of configuring ifplugd. I'm not saying it is, I'm only saying it may be. :-) > It's not so much "before", as when I start a shutdown, and then pull the > cable before it gets to shutting down ifplugd. It was actually something > in /etc/init.d/networking (unmount samba shares??) that was preventing > ifplugd from closing the interface. As long as I either shut down with the > cable still connected, or remove the cable far enough in advance to let > ifplugd get the interface down before it gets to ".../networking stop", all > is well. I can imaging that both ifplugd and /etc/init.d/whatever are trying to do things, but I don't see why it freezes your system. I've never seen that behaviour, and I do remove the network cable during shutdown. Koen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
