Bug 73739

Please show me the content of all /etc/sysconfig/network/ifcfg-* (except lo).

Created attachment 32327 [details]
ethernet ifcfg

Created attachment 32328 [details]
wlan ifcfg

I've verified this again.  in my office all is well.  I unplug, go 
down the hall to a conference room, and plug in.  'beep'.  my interface 
now has a new IP, on a different network from DHCP, but no network  
activity works.  I return to my office, plug in, 'beep'.  Now all is  
well.  So, changing the ip or network seems to be the problem.  

Others have seen this as well, trying to connect to the 
BrainShare wireless network.  Blocker, IMO, as it makes 9.3  
a bit useless on a laptop.  

does it work if you disable the firewall?

You have a LAN device configured with startmode ifplugd and a WLAN device with  
startmode auto. This means that both devices get up when a cable is plugged  
in. This may result in dns resolver and default route settings you don't want 
to have. Use startmode ifplugd with a lower priority for the WLAN device, this 
should give you DNS and default route of the ethernet device whenever a cable 
is plugged in and WLAN connection (if available) with no cable. 

If the problem is not the firewall:
- Does it work if the wlan interface is always down (STARTMODE=manual)?
  If yes, then try to set the wlan interface to STARTMODE=ifplugd with
  IFPLUGD_PRIORITY=10. (You can do that in YaST as well.)
  [[Oh well, "Mid-Air-Collision": thats, what Joe was about in last comment.]]
- For the ethernet interface you have configured a static address additionally 
  to dhcp. Is that intention?
- What is the content of /etc/sysconfig/network/route?
- Please check the basic network settings when it works and when it does not:
  + ip a
  + ip r
  + cat /etc/resolv.conf
  Attach the output of these commands if you don't know if these settigs are   
  correct.

As YaST does not configure both devices with DHCP during installation, this is 
not a blocker IMHO. 

I guess this is following problem (still theory, needs to be verified by bug
reporter):

User configured interface with static ip and default route for network A. Later
he reconfigures to dhcp. Now YaST does
- not remove the static ip from the configuration (bug, this is not what the
  user expects, the ip field in YaST is greyed!!!)
- not remove the static default route (maybe a bug, dhco but static default
  route may make sense)

Now ifup starts dhcp and sets up the static ip (feature!). And it sets up the
static default route (feature!)
Now when he is in network A he has no problem, because the static default route
is correct. But in network B the default route is wrong and it does not work
anymore.

Bart, please check if this is your problem.

If the old static ip were deleted, the setting up the wrong default route would
result in an error when ifup is called (in syslog if YaST does it in backround).
This error is harmless in this case. Even more it leads to a functional network
setup, because dhcpcd will now set the default route. And this error message
would show the user that there is something wrong in his configuration.

In every case, YaST should remove previous static ip when switching to dhcp. And
 maybe also the static default route.

I have no firewall running, and have reproduced it again, so it's not 
firewall. 

Created attachment 32702 [details]
output of 'ip a', ip r', and /etc/resolv.conf

Taking down the wireless interface does not improve the situation.  
 
I've reproduce it a dozen times this morning gathering the info.   
Good exercise walking from my office to the conf. room on the  
other side of the building. :) 

for debugging: 
 - take down the wireless interface 
 - pull out ethernet cable 
 - wait 15 seconds (after 10 seconds the interface should be taken down) 
 - insert ethernet cable 
Does it work now? 

This does not work.  The wireless interface has been down for several 
round trips to the conf. room and back, and it takes 60 seconds to  
walk to the conf. room.  So, what you propose has already been tested 
several times (and I just did it again for completeness).  
 
That's all the feedback I can provide today.  Need to leave for  
BrainShare now.  

OK, the ip a/r output from attachment 32702 [details] shows that the default route is
wrong. Go and check /etc/sysconfig/network/routes. I guess it contains 
  default 137.65.59.254 - -
Bart, please verify that.

Just remove the file /etc/sysconfig/network/routes.
And in ifcfg-eth-id-00:00:39:f8:d5:e2 remove 
  BROADCAST='137.65.59.255'
  IPADDR='137.65.59.141'
  NETMASK='255.255.252.0'
  NETWORK='137.65.56.0'
Then it will work as expected.

the question is: how do those entries get into the configuration? Was this once 
a static setup, changed with "vi" to "dhcp" or did YaST do this? If so, this 
would be a (bad) YaST bug IMO. 

This was very probably a previous static configuration. Then changed with YaST.
I tried that myself today. 100% reproducible. When calling YaST network again
you can even see the static ip address in a greyed field.

YaST had to remove static ip and default route if user switches to dhcp. It
could perhaps ask before removing the default route, because maybe somebody
wants a static default route with dhcp. But at least the static ip address has
to be removed. Then, if dhcp gets addresses from another network, the static
default route would not hurt.

This is something for a YOUpdate. As soon as Bart verifies this i wil assign it
to Martin.

The settings came from YaST.  This is what I did... 
 
- configure wired interface with static IP.  
- enabled SCPM.  
- created Wired static and Wired DHCP profiles.  
- Switched to DHCP profile.  
- Changed wired interface from static to DHCP via YAST.  
 
I can't verify #16 ATM.  

Created attachment 32904 [details]
when my configuration was working

my working configuration before network switch

Created attachment 32905 [details]
after network switch networking broken

 have a similiar problem.  And I always get a 'ip route replace to
169.254.0.0/16 dev ath0' error everytime i switch a network and do an
ifup ath0/eth0 either one but never both at same time.  But i only get
that error once and then you have to reboot to get it.  I also
reinstalled w/ a good network connection at novell and got this for my
routing

(this is working after install)
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
137.65.156.0    *               255.255.252.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         prv-lan-cisco1- 0.0.0.0         UG    0      0        0 eth0

now this is what i get from school 

(this is after a network switch)
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 ath0
10.4.66.0       0.0.0.0         255.255.254.0   U     0      0        0 ath0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         10.4.66.1       0.0.0.0         UG    0      0        0 ath0


I realize these are diferent interfaces but does this routing for the second
look right ??  Does 0.0.0.0 act like *

I also included some more configuration files of before and after 

my attachments are down at the bottom

The attachments from Garrett did not help so much. But coment 19 from Bart shows
what i expected: First configured static then switched to dhcp makes the trouble.

Martin please read coment 18. Remove default route and ip address when switching
from static to dhcp.

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

I am not so sure about removing the default route. Can there be cases whre 
there is a DHCP interface and yet a static default route, perhaps for a 
different interface? 
 
I have tested that when I set a default route that does not match the current 
subnet (in general, any of the subnets I guess) it is not set and DHCP will 
set its own. So it works OK except if the old and new gateways are in the same 
subnet. 

Yes, a static default route that is in another subnet does not harm. But do you
know that before?

If you want individual default route setting for different interfaces you should
use ifroute-*.

You should remove the default route if the user switches to dhcp. If the user
adds a default route later you may add it.

Originally reported for SL 9.3 Beta4.
Moving to make the bug public.

This appears to be fixed in 10.1. What about a fix for 9.3?

No, sorry. If it is not a security bug, the preferred solution is to upgrade to a release where the bug is fixed.

In this case the route bit seems still left to fix.

Reassigning to the new maintainer of yast2-network.

fixed