On 06/14/2012 10:21 AM, Camaleón wrote:

...

> Not a corner case at all, it was just me who was a bit dense O:-)
> 
> Your setup is crystal-clear now and I guess is used by many road-warrior-
> alike users.
>

I suppose so, but most places do use DHCP. I just have some clients who
are stuck with whole networks of fixed IP addresses.

>> As I said, I could just have Wicd (if it will cooperate) switch in an
>> appropriate /etc/network/interfaces file when it runs, but that seems
>> like a clumsy way to handle this.
> 
> Well, if I were using WICD or Network-Manager (or a another application 
> to manage the network configuration settings) I would avoid messing up 
> things with the plain "/etc/network/interfaces" file. 
> 
> Generally speaking, there are two main options for managing the network: 
> old stuff (ifup) and the new set utilities (n-m, wicd, etc...) and both 
> have to interactuate nicely which is not always the case :-P
> 

That's for sure. As I said, the idea of scripting the swapping of
/etc/network/interfaces all the time seems like a less-than-ideal way to
handle this.

> - If using "/etc/network/interfaces" with a dynamic IP setup, you can 
> configure a secondary fall-back setting in the event your system can't 
> get the settings from DHCP server (this is done from dhcp-client and you 
> can define time-out intervals, IP settings, and all that stuff).
> 
> - If using WICD (or N-M) you have to control this from WICD provided 
> tools which, to be sincere, I don't know what they are nor how they 
> look :-) but there has to be some kind of control panel, applet or GUI 
> client where you can define the options for the wired card and the rest 
> of the parameters related to DHCP.
> 
> What I would like to know is whether WICD reads (or feeds) from "/etc/
> dhcp/dhclient.conf" file because if so, you can start tweaking this and 
> play with the values.
> 

I experimented by uncommenting the "timeout=60;" line in
/etc/dhcp/dhclient.conf and changing the value to 10. On a reboot, the
"configuring interface" timeout was definitely reduced, but not quite to
10 seconds. The problem was that the "configuring MTA" line still took
the full 60 seconds to time out, which was exactly what I'd expected it
to do. So far my reading of the exim4 man pages hasn't led me to any
ideas as to how to reduce that timeout.

> Now (and back to your problem), what's your system exactly doing at 
> booting? Yes, we know there's a delay when setting up the network but if 
> you boot as usual, what happens? Your system finally boots, you login and 
> what are your current network settings? Are they fine or your eth0 card 
> is not configured with the correct data and goes to a zeroconf setup 
> (169.254.0.x)?
> 

All networking functions upon coming up to desktop are fine. The IP
address is exactly what's set in Wicd.

> I ask this to have an idea on where to put the focus in either a) long 
> delay -timeout- but NIC settings are finally okay or b) long delay -
> timeout- with NIC settings unconfigured.
> 

Yup, it's definitely choice "a". Everything works, but the boot process
is slow. And, as I said, I can speed up the "configuring interface" part
of the boot, but the "configuring MTA" part still takes 60 seconds.

The interesting thing is that, if I hit <Ctrl>+<C> when the "configuring
interface" prompt is displayed, the system proceeds rapidly through the
rest of the process at a normal pace, with no delay at "configuring MTA".

I'm not quite sure what the downside of using <Ctrl>+<C> might be. I can
see in htop that exim4 is running after the boot process finishes, so at
least it's not interfering with the actual launching of that process.

This is really a minor issue since it only causes a minor inconvenience.
I'm just investigating it because the present situation represents a
substantive change in behavior on this system. It's obvious that
something about the way Wicd works with networking has changed since the
netscript package was upgraded some days ago.

Many thanks,
Gilbert


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fda1a45.9020...@comcast.net

Reply via email to