Nate Bargmann wrote: > Bob Proulx wrote: > > I assume you have something like this in your /etc/network/interfaces: > > > > allow-hotplug eth0 > > iface eth0 inet dhcp > > My laptop has exactly this stanza along with the lo stanza below in the > desktop's interfaces file. As WiCD is used, I wonder if the eth0 stanza > in necessary at all? If specified then wicd will leave it as specified for ifupdown. If not specified then wicd (or network-manager) will try to handle it. So the answer of configuration is a decision for you. Do you want ifupdown to manage it? Then you must specify it. Do you want wicd to manage it? Then you must not specify it. Note that udev will cache the ethernet address and if you change network devices then udev will assign a different device name and then wicd (or nm) will inherit it. This happens when moving disks from one machine to another machine with a different ethernet address in the hardware. Typical for me and many but unusual for many too. This is the /etc/udev/rules.d/70-persistent-net.rules file. > > If you change that to this does it improve things? > > > > auto eth0 > > iface eth0 inet dhcp > > This stanza is how my desktop is configured along with lo: Using 'auto' is the old way. It sets up for a synchronous configuration at boot time. Using 'allow-hotplug' is the new way. It sets up for an event driven configuration to handle hotplug devices such as usb devices, pcmcia, and so forth. Both work for the most part. But there are corner cases in each. > > I have notice that when used with nis/yp the above avoids an nis > > startup delay. > > So far as I know, I do not use nis/yp. I wasn't suggesting that you were using nis. I was simply pointing that out as a data point where using 'auto' avoids a delay but 'allow-hotplug' has a problem. It was an example only. > I suppose the next step is figuring out how to enable debugging in > Shorewall. Sigh... Start at the /etc/init.d/shorewall level and look there first. It is likely not an issue with the upstream /sbin/shorewall but with the startup script process. I would start debugging like this: sh -x /etc/init.d/shorewall restart Look at the shell trace output and see where the delay is occuring. Bob
Attachment:
signature.asc
Description: Digital signature