Bug 132076

Summary:	missing default route for ippp0
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Hartmut Meyer <hartmut.meyer>
Component:	Network	Assignee:	Christian Zoz <zoz>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	i586
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Hartmut Meyer 2005-11-02 22:11:21 UTC

customer reported (and I was with him on the phone while we verified) that ISDN (not using DoD) was working fine until he decided to add a ethernet device (DHCP).

Since then he was still able to connect to the internet but couldn't reach anything out there.

I checked with him and it turned out that "route -n" still reported the default route being set to eth0 even when he successfully connected to the internet via ISDN.

He reinstalled the machine and this time he had the ethrnet device already configured during the initial setup. ISDN was working fine until he then decided to add a network printer through YaST. After that the same story again: dialin to internet worked fine but default route was stuck to eth0.

We fixed it by editing /etc/sysconfig/network/dhcp and changing DHCLIENT_SET_DEFAULT_ROUTE from yes to no. After next reboot all worked fine (default route would initially not be set but after triggering a dial in, it would then point to ippp0).

Customer reported that he had already reproduced this on a second PC.

I checked with Karsten, but this was news to him. He asked me to open a bug for it and to assign it to the network guys.

Comment 1 Christian Zoz 2005-11-04 13:34:28 UTC

Which interface should when be used to connect to the internet via which gateway?

If the default route is set via eth0 then the gateway must be in the subnet of eth0. So where is the problem? Is eth0 still up while the cable is disconected?

Please attach all config files for network and isdn. Also provide output of ip a and ip r.

Karsten, did you have any idea what is going on here?

Comment 2 Karsten Keil 2005-11-04 14:52:50 UTC

No, but I will try to reproduce it here.

Comment 3 Hartmut Meyer 2005-11-04 15:04:43 UTC

> Which interface should when be used to connect to the internet via which
> gateway?

Internet is accessed through ISDN. Etherenet is only used for the home LAN. Ethernet device is configured via DHCP and this by default also sets the default route. Which is not bad in itself.

> If the default route is set via eth0 then the gateway must be in the subnet of
> eth0. So where is the problem?

The problem is that the default route should be changed to the ISDN device whenever the user dials in to the internet (the YaST2 ISDN configuration defaults to setting the default route to the ipppX device). And this did not happen (it still pointed to eth0 - see original report for the exact circumstances). This only worked after DHCLIENT_SET_DEFAULT_ROUTE in /etc/sysconfig/network/dhcp was changed from yes to no.

> Is eth0 still up while the cable is disconected?

Don't know. The ethernet cable was never disconnected.

> Please attach all config files for network and isdn. Also provide output of ip
> a and ip r.

Sorry. Can't do that. It was the setup of a customer that I had on the phone. I left a message for him and instructions on how to get to our bugzilla ...

Comment 4 Christian Zoz 2005-11-18 13:01:41 UTC

Karsten, who does set the default route for isdn connections?
Did you already manage to reproduce it?

Comment 5 Karsten Keil 2005-11-18 14:59:57 UTC

Yes, but I think here is no bug at all.
We do not overwrite default routes with ipppd in normal cases for being on the safe side. If you want this, you have to specify an other option to ipppd:
deldefaultroute. This allows ipppd to delete a existing default route.
You can add this option to the extra input line in YaST isdn interface setup
Details page or by adding it (global) to /etc/ppp/ioptions.

Comment 6 Christian Zoz 2005-11-18 15:31:15 UTC

Since this is a special case anyway and since NM will do this job soon: ->WONTFIX