Bug 149780

Have you set the 'GATEWAYDEV' variable in /etc/sysconfig/network
or the 'GATEWAY' variable in /etc/sysconfig/network-scripts/ifcfg-eth? ?

Yes, GATEWAY is set correctly in ifcfg-ethX.
I tried to downgrade of dhclient package and it has solved the problem.
After upgrading dhclient package the problem occurs again.

Aha - you must not set GATEWAY in ifcfg-ethN if you want the default
gateway to be configured by DHCP on ethN . 
With this release of DHCP, we fixed handling of the GATEWAY and 
GATEWAYDEV variables in the dhclient-script, as follows:
 GATEWAYDEV: If set in /etc/sysconfig/network, and DHCP is being used,
             then ONLY the "$GATEWAYDEV" interface will set the
             default route.
 GATEWAY:    If set in /etc/sysconfig/network-scripts/ifcfg-ethN, then
             when DHCP is used to configure ethN, the routers option
             received from DHCP is ignored; only if the new_ip_address
             received from DHCP is on the same subnet as the GATEWAY
             router using the subnet received from DHCP, then the 
             $GATEWAY variable becomes the gateway of the default
             route.

Before, the GATEWAY and GATEWAYDEV values were ignored by DHCP; this
was a problem for users who expected their settings to override values
received from DHCP.

Removing the GATEWAY setting from ifcfg-ethN or ensuring it is on the
same subnet as the address you receive from DHCP should fix the 
problem. What was your GATEWAY setting ?

I never edit manually this... only with system-config-network

root@notemg:~# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=notemg.house
root@notemg:~# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
DHCP_HOSTNAME=notemg.house
USERCTL=no
PEERDNS=yes
IPV6INIT=no
IPADDR=10.1.1.100
NETMASK=255.0.0.0
GATEWAY=10.1.1.1

Aha - this explains it. Remove the GATEWAY setting from ifcfg-eth0
and the new dhclient-script will work fine.

system-config-network should NOT be setting the GATEWAY variable for
DHCP interfaces. 

I'm moving this bug to system-config-network .

(In reply to comment #5)
> Aha - this explains it. Remove the GATEWAY setting from ifcfg-eth0
> and the new dhclient-script will work fine.

I comment this lines and work.

> system-config-network should NOT be setting the GATEWAY variable for
> DHCP interfaces. 
> 
> I'm moving this bug to system-config-network .

I think that system-config-network have change this. But if user edit network
options with system-config-network this update broken your network. Final users
they will not know to arrange this.

The "GATEWAY" variable in ifcfg-ethX should never be set by
system-config-network if BOOTPROTO=dhcp .

dhclient-script now correctly interprets "GATEWAY" as overriding the
"routers" option received from DHCP, and will check if GATEWAY is on
the same subnet as the new_ip_address with the new_subnet_mask
received from DHCP - if it is, the "$GATEWAY" value is used as the
gateway of the new default route - if not, no default route is set by
the DHCP session for that interface, permitting a DHCP session for
another interface to set the default route.

*** Bug 149816 has been marked as a duplicate of this bug. ***

Not very useful when you often have to switch from STATIC IP to DHCP client
(laptop users for example), you will have to manualy remove the GATEWAY
statement every time you switch back to DHCP client mode :-((

I will fix this in s-c-network, if it is the case.

(In reply to comment #11)
> I will fix this in s-c-network, if it is the case.
It could rewrite the ifcfg-ethx EVERYTIME a change is opered with
system-config-network (for example switch to/from DHCP to/from STATIC) to ensure
the OLD settings (IPADDR, NETMASK, GATEWAY etc...) are correct and not left with
the previous values...

it worked correctly with the dhclient-scpript coming from version 3.0.1-30_FC3
an I tried to overwrite the dhclient-scpript version 3.0.1-30_FC3 on the one
from the version 3.0.1-40_FC3 and it worked again even if the statement GATEWAY
was kept in ifcfg-eth0 file of my config...
Maybe a diff of the 2 files could find the reason why it doesn't work anymore
with the new version of dhclient-scpript...

RE: comment #13: yes, the dhclient-script from 3.0.1-30_FC3 did not
honor the $GATEWAY or $GATEWAYDEV settings. The new dhclient-script
from 3.0.1-40_FC3 does. With $GATEWAY in ifcfg-ethX, only the 
interface whose new subnet matches GATEWAY will set GATEWAY as the
default route gateway; otherwise, a default route is not set. This
is to enable the user to override DHCP "routers" options when multiple
interfaces are being configured with DHCP. 

*** Bug 149908 has been marked as a duplicate of this bug. ***

I had the same problem: $GATEWAY was set and BOOTPROTO=dhcp, in
the ifcfg-eth0 file generated by system-config-network.  This GUI
keeps static routing data around even if you change to DHCP, which
seems reasonable for users switching between static/DHCP often.

In my case, the gateway given by DHCP should have been set,
ignoring $GATEWAY.  Perhaps an explicit option $IGNORE_DHCP_GATEWAY
should be added to distinguish between the case where $GATEWAY is simply
left-over configuration data from a previous static routing, and
the case where it should actually override DHCP.

Finally, I find it odd that a gateway issued by DHCP is discarded
WITHOUT any other gateway being added, in the case where $GATEWAY
has an unreachable IP address, for instance if it is not in the
subnet indicated by DHCP (e.g., DHCP says gateway is 234.234.234.1,
and $GATEWAY=192.168.1.1).

How about extending

	if [ "$routerSubnet" = "$mySubnet" ]; then
	   ip route replace default via $GATEWAY dev $interface 
	fi;

with an else case 

	for router in $new_routers; do
	    add_default_gateway $router && break;
	done

to ensure that at least one default gateway is added?

dhcp-3.0.2-6, now in FC4, provides the 'DHCLIENT_IGNORE_GATEWAY' flag in 
/etc/sysconfig/network, which when set to 'yes' will cause dhclient to ignore
any GATEWAY setting and configure the default gateway from the dhcp "routers"
option as normal. 

RE: Comment #16: "I find it odd that a gateway issued by DHCP is discarded
WITHOUT any other gateway being added" :
The whole point of making dhclient honor the $GATEWAY setting is that 
multiple dhclient sessions can each get a "routers" option, but only
the one session that obtains an ip address and netmask that is 
on the same subnet as $GATEWAY will set the default route .

Is there an updated s-c-n dialog that includes a checkbox to influence
'DHCLIENT_IGNORE_GATEWAY' so I don't need to manually change this in
/etc/sysconfig/network after using s-c-n as described in comment 10?  Having to
make a network setting in two places is a real pain.  s-c-n should let me setup
everything necessary to successfully switch between static and dynamic ip's on
my laptop.

I the behaviour of s-c-n is to grey out settings that are not apropriate
anymore, e.g. IP address and default gateway, these are - OF COURSE - to
be "greyed out" in the config file as well, which means they shall be
*COMMENTED OUT*, so if this is for static configuration:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=192.168.1.64
USERCTL=no
PEERDNS=yes
GATEWAY=192.168.1.1
IPV6INIT=no

Editing this with s-c-n to use DHCP and saving the file shall result
in:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
#NETMASK=255.255.255.0
#IPADDR=192.168.1.64
USERCTL=no
PEERDNS=yes
#GATEWAY=192.168.1.1
IPV6INIT=no

easy, yes? Commenting out like this preserves the information without
the dhclient calling script using it and the problem is solved. Now please
just make s-c-n do this and I will be very pleased.

(This bug broke two important installations for me BTW.)

I would like to raise the severity of this bug to "high" for the following
reason:

If you have ever, ever used static IP settings for an interface, s-c-n will
leave the GATEWAY setting behind. When the system is upgraded, the interface
will just stop routing on next restart and the system becomes unusable for
most non-tech-savvy users. Thus the update from 3.0.1-30_FC3 to 
3.0.1-40_FC3 effectively destroys every installation where a static
gateway has been used in the past.

The way it should have worked would have the s-c-n RPM package comment out the
GATEWAY (atleast) row of any network scripts upon installation, so that
simply installing the RPM will not break the system.

Bug is still in s-c-n in FC4 - see 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163062 
 
But I'd argue that this is still a dhclient bug. As s-c-n in FC4 is still 
setting both DHCP and GATEWAY=x.x.x.x (even though the static IP settings are 
greyed out), dhclient is wrong to assume that GATEWAY=x.x.x.x is meant to 
override the DHCP-supplied gateway. People in the future are going to be 
upgrading and hitting this bug still... 

Hum.. the situation seems to have been reversed in FC5t1, it doesn't set default
gateway unless I manually add GATEWAY into ifcfg-eth0 (GATEWAYDEV=eth0 in
sysconfig/network doesn't help). Reverting back to FC4 dhclient cures it.

(In reply to comment #19)
> I the behaviour of s-c-n is to grey out settings that are not apropriate
> anymore, e.g. IP address and default gateway, these are - OF COURSE - to
> be "greyed out" in the config file as well, which means they shall be
> *COMMENTED OUT*, so if this is for static configuration:
> 
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> TYPE=Ethernet
> NETMASK=255.255.255.0
> IPADDR=192.168.1.64
> USERCTL=no
> PEERDNS=yes
> GATEWAY=192.168.1.1
> IPV6INIT=no
> 
> Editing this with s-c-n to use DHCP and saving the file shall result
> in:
> 
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> TYPE=Ethernet
> #NETMASK=255.255.255.0
> #IPADDR=192.168.1.64
> USERCTL=no
> PEERDNS=yes
> #GATEWAY=192.168.1.1
> IPV6INIT=no
> 
> easy, yes? Commenting out like this preserves the information without
> the dhclient calling script using it and the problem is solved. Now please
> just make s-c-n do this and I will be very pleased.
> 
> (This bug broke two important installations for me BTW.)

Sounds like the smartest solution.

The networking configuration scripts are already very complex. Adding this
change is so much more elegant than introducing other variables (i.e. levels of
complexity)!

Hmph, after updating to dhclient-3.0.2-26.FC4 I no longer get a default route
with FC4 either unless I manually add GATEWAY=<ip> to the configuration, same as
FC5test1 in comment #22 :(

RE: Comment #24 and Comment #22: 
It sounds like there is some issue with the 'routers' option your dhcp server
is sending.
Do you have $GATEWAYDEV set in any /etc/sysconfig/network{,-scripts/ifcfg*} ?
If so, remove this setting or comment it out - dhclient-3.0.2-26.FC4 should
set the default route OK with no GATEWAY or GATEWAYDEV settings.
You should not need to set GATEWAY or GATEWAYDEV in order to set the default 
route with dhcp .
Please send me your /var/lib/dhcp/dhclient-*.leases file . 
Can you ping the IP addresses in the $routers option ?
When you run dhclient-3.0.2-26.FC4 , are there any 'unreachable' router 
messages in the log ? ie: 'grep unreachable /var/log/messages' ?
After you run dhclient-3.0.2-26.FC4, what is the output of 'ip route' ?

[root@weasel ~]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
[root@weasel ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:11:D8:8D:C4:53
ONBOOT=yes
TYPE=Ethernet
-> no gateway settings

[root@weasel ~]# grep unreachable /var/log/messages*
-> nothing there

[root@weasel ~]# /sbin/ip route
192.168.255.0/24 dev eth0  proto kernel  scope link  src 192.168.255.3
169.254.0.0/16 dev eth0  scope link
-> no default route

[root@weasel ~]# cat /var/lib/dhcp/dhclient-eth0.leases
lease {
  interface "eth0";
  fixed-address 192.168.255.3;
  server-name "";
  option subnet-mask 255.255.255.0;
  option routers 192.168.255.1;
  option dhcp-lease-time 259200;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.255.1;
  option dhcp-server-identifier 192.168.255.1;
  option dhcp-renewal-time 129600;
  option dhcp-rebinding-time 226800;
  option host-name "dhcppc1";
  renew 4 2005/12/22 04:00:09;
  rebind 5 2005/12/23 08:33:18;
  expire 5 2005/12/23 17:33:18;
}
lease {
  interface "eth0";
  fixed-address 192.168.255.3;
  server-name "";
  option subnet-mask 255.255.255.0;
  option dhcp-lease-time 259200;
  option routers 192.168.255.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.255.1;
  option domain-name-servers 192.168.255.1;
  option dhcp-renewal-time 129600;
  option dhcp-rebinding-time 226800;
  option host-name "dhcppc1";
  renew 3 2005/12/21 22:15:30;
  rebind 5 2005/12/23 08:34:27;
  expire 5 2005/12/23 17:34:27;
}
[root@weasel ~]#

-> seems ok to me. In any case that used to work just fine with dhclient prior
to this update. 

Like I said, I need to *add* the supposedly forbidden GATEWAY entry to make it
work again:
[root@weasel ~]# echo GATEWAY=192.168.255.1 >> /etc/sysconfig/network
[root@weasel ~]# /sbin/ifdown eth0
[root@weasel ~]# /sbin/ifup eth0

Determining IP information for eth0... done.
[root@weasel ~]# /sbin/ip route
192.168.255.0/24 dev eth0  proto kernel  scope link  src 192.168.255.3
169.254.0.0/16 dev eth0  scope link
default via 192.168.255.1 dev eth0

Oh, in case you wonder about the "weasel" hostname: I had that as hostname set
in /etc/sysconfig/network when booting but removed it to see if it (being
unresolvable outside /etc/hosts) made any difference - it didn't.

RE: Comment #24, Comment #26: this is a separate bug - please see bug 176270.

It seems this bug is still in S-C-N FC5. As I read the discussion here, it seems like it isn't getting resolved 
because there's disagreement about whether it should be fixed in S-C-N or dhclient. To be honest, I doubt 
most users care. What they will care about is that there is a known, unfixed, and undocumented bug. In 
fact, it doesn't seem to even be very google-able - I only found this thread after hours of googling, and 
after suddenly guessing what the problem was and deciding to enter a buzilla report. If you can't agree - 
soon - on what the right solution is, please at least treat it as a UI problem in S-C-N for the moment, and 
_don't_ grey out the default gateway when dhcp is chosen - at least, that way people will know what they 
have to do to fix it. In the meantime, I'll put a somewhat google-able thread up on fedoraforum with a 
pointer here, so people can find it.

Same here on FC5. No DHCP provided default gw is set. (SUSE 10 is fine, so it's
an FC only problem, it'd seem.)

Aa a consequence, at least NTP time synchronisation isn't working automatically.
Don't know what other components aren't working by default.

Thanks

I agree that this bug should be elevated to high priority, since it can disable
your network with no obvious workaround. We should also set it to FC5 instead of
3, since that's the version most people are going to care about. Any chance the
s-c-n/dhclient deadlock is going to be resolved soon and someone will actually
fix this?

*** Bug 169113 has been marked as a duplicate of this bug. ***

*** Bug 167593 has been marked as a duplicate of this bug. ***

*** Bug 163062 has been marked as a duplicate of this bug. ***

*** Bug 162902 has been marked as a duplicate of this bug. ***

*** Bug 162553 has been marked as a duplicate of this bug. ***

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

This bug is still prenent is FC5, so someone with the proper privileges should
change the version field to FC5 and reopen it.

moving to FC5 as per comment #38.

(clearing needinfo bit. sorry for the spam.)

Urg. I'm hitting a bugzilla bug where the needinfo checkbox doesn't always work.
Again, sorry for the bugspam.

*** Bug 169526 has been marked as a duplicate of this bug. ***