Re: dhcp trouble

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-12-20 at 16:42 +0900, Shawn wrote:

> I need to use dhcp but it is not working in an new fc6 box.
> 
> I set "automatically obtain DHCP" and "DNS" in system-config-network
> gui, save the file, restart the network via gui /usr/sbin/system-config-
> services, and for good measure stop networking in the network manager
> applet and then restart it (so that I can check updated dhcp info
> through it).

Doing and "ifdown eth0" then "ifup eth0" is usually sufficient to get a
network to try and get an address from a DHCP server.  It sounds like
you might have one of two problems:  Your network's DHCP server has a
problem, your firewall is blocking it.

> The network manager applet shows it is returning an ip address,
> broadcast and subnet mask entries, but not default route, primary dns,
> or secondary dns.

I've commented through the logs below.  The address it gets is a random
one, not one assigned from a server.  It's all peer-to-peer, there is no
gateway, default route, etc.

> The returned values from the same cable plugged into a fc3 box (using
> dchp which works) returns quite different information.  None of the xxx
> values in this fc6 log file match the info in the fc3 box although of
> course being dhcp could have changed [there was a 5 min interval between
> checks on the two systems]

My strong guess, based on it working for FC3 but not FC6, is that your
firewall is getting in the way.

> Both are on eth0 devices.
> 
> Dec 20 15:02:29 localhost NetworkManager: <information> Waking up from sleep. 
> Dec 20 15:02:29 localhost NetworkManager: <information> Deactivating device eth0. 
> Dec 20 15:02:29 localhost avahi-daemon[2563]: Withdrawing address record for xxx on eth0.

Avahi is trying to configure network addresses when there's no DHCP
server on the network.  It's a case of individual PCs co-operating to
each get unique addresses within a certain address range.  If this isn't
what you want, then you can stop that service and leave it stopped.
Likewise for other related services (mDNS, ZeroConf, etc.).

This is the normal DHCP client trying to get an answer from a DHCP
server on the network:

> Dec 20 15:02:31 localhost dhclient: DHCPDISCOVER on eth0 to xxx port 67 interval 3
> Dec 20 15:02:34 localhost dhclient: DHCPDISCOVER on eth0 to xxx port 67 interval 6
> Dec 20 15:02:40 localhost dhclient: DHCPDISCOVER on eth0 to xxx port 67 interval 8
> Dec 20 15:02:48 localhost dhclient: DHCPDISCOVER on eth0 to xxx port 67 interval 15
> Dec 20 15:03:03 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20

Which didn't work, the following section complaining that it took too
long to get an answer (or, in this case, didn't get one), and it's
trying something else to set up an address:

> Dec 20 15:03:16 localhost NetworkManager: <information> Device 'eth0' DHCP transaction took too long (>45s), stopping it. 
> Dec 20 15:03:17 localhost NetworkManager: <information> Activation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled... 
> Dec 20 15:03:17 localhost NetworkManager: <information> DHCP daemon state is now 14 (normal exit) for interface eth0 
> Dec 20 15:03:17 localhost NetworkManager: <information> DHCP daemon state is now 14 (normal exit) for interface eth0 
> Dec 20 15:03:17 localhost NetworkManager: <information> Activation (eth0) Stage 4 of 5 (IP Configure Timeout) started... 
> Dec 20 15:03:17 localhost NetworkManager: <information> No DHCP reply received.  Automatically obtaining IP via Zeroconf.

ZeroConf is the method I outlined previously, of machines on a network
with no server figuring out addresses between themselves (finding an IP
that isn't currently in use, random choosing one, seeing if anything
else responds to that address, then claiming it for itself).  It'll be
one in the 168.254.x.y (link local) address range.
 
> Dec 20 15:03:17 localhost NetworkManager: <information> autoip: Sending probe #0 for IP address 169.254.54.45. 
> Dec 20 15:03:17 localhost NetworkManager: <information> autoip: Waiting for reply... 
> Dec 20 15:03:18 localhost NetworkManager: <information> autoip: Got some data to check for reply packet. 
> Dec 20 15:03:18 localhost NetworkManager: <WARNING>      get_autoip (): autoip: (eth0) recv arp type=2054, op=1,  
> Dec 20 15:03:18 localhost NetworkManager: <WARNING>      get_autoip (): source = xxx,  
> Dec 20 15:03:18 localhost NetworkManager: <WARNING>      get_autoip (): target = xxx  

Here, you can see that it decided to claim 168.254.54.45 for itself.



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux