Bug 156126 - YaST2 network setup makes wrong conclusions when a DSL modem is found on the LAN
Summary: YaST2 network setup makes wrong conclusions when a DSL modem is found on the LAN
Status: RESOLVED WONTFIX
: 171099 (view as bug list)
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Network (show other bugs)
Version: Beta 7
Hardware: Other Other
: P5 - None : Enhancement (vote)
Target Milestone: ---
Assignee: Michal Zugec
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-08 16:38 UTC by Reinhard Max
Modified: 2008-06-25 09:53 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reinhard Max 2006-03-08 16:38:29 UTC
I've been told that the DSL modem I had connected to the Nürnberg development netowork for testing purposes made the network configuration in YaST2 think that the internet connection would go via this DSL modem rather than the local network and DHCP.

I think this is a bug, because there are scenarios when it is wrong to assume that when a DSL modem is visible in the local network, this will be used for the internet connection. Some examples:

1. All machines on a SOHO network and the DSL modem are connected to one hub or switch, but only one machine makes a PPPoE connection and then acts as a router for the others.

2. One of these combined modem/router/switch devices is used, that offers routing and PPPoE passthrough at the same time (I have a Siemens SE515 at home that does this).

So I think when the YaST2 network configuration finds a DSL modem, it should additionally look for a DHCP server that provides a default route, and if it finds one, it should ask the user whether the internet connection will be via DSL or LAN.
Comment 1 Martin Vidner 2006-05-02 14:34:27 UTC
*** Bug 171099 has been marked as a duplicate of this bug. ***
Comment 2 Martin Vidner 2006-05-02 14:39:35 UTC
I like the idea of enhancing the detection by looking at the DHCP server.
Also, I obviously need to make it possible to switch between the two modes. A hyperlink comes to mind, already used for other things in that dialog.

After 10.1 though
Comment 3 Martin Vidner 2006-08-28 11:52:37 UTC
Reassigning to the new maintainer of yast2-network.
Comment 4 Michal Zugec 2007-06-08 10:52:14 UTC
In general :
When we have several devices configured by dhcp and there is global option /etc/sysconfig/network/dhcp.DHCLIENT_SET_DEFAULT_ROUTE='yes' (it's default), all of that devices will write their own default route (and last one win).
It's a little bit similar to network devices names according order of modules loading (now we have udev rule for renaming)

What you want to be implemented is to write DHCLIENT_SET_DEFAULT_ROUTE='no' for each that devices except one you want to be default route (with usable UI).
IMO this is not a bug (it's known dhcpcd issue) - this should be a feature.
Can you write it into fate tool and close this report,please ?

BTW - there is similar one feature request we can split and implement as one - set metric for routes
Comment 5 Reinhard Max 2007-07-03 11:02:58 UTC
Michal, your comment looks unrelated to my original bug report.
Please re-read and feel free to ask if anything is unclear.
Comment 6 Michal Zugec 2007-08-28 14:39:23 UTC
sorry, no time now
postpone after 10.3
Comment 7 Reinhard Max 2007-08-28 15:06:49 UTC
Michal, couldn't you please at least explain how your comment #4 is related to my original bug report?

My original bug report was not about multiple simultaneous DHCP devices, it was about situations when a PPPoE server and a DHCP server can be reached through the same network interface.
Comment 8 Michal Zugec 2007-11-21 07:14:54 UTC
Sorry -  yes, my comment was unrelated.
Changed serverity to enhancement, postponed as LATER, 
Comment 9 Stephan Kulow 2008-06-25 09:36:22 UTC
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Comment 10 Stephan Kulow 2008-06-25 09:38:08 UTC
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Comment 11 Stephan Kulow 2008-06-25 09:42:22 UTC
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Comment 12 Stephan Kulow 2008-06-25 09:53:47 UTC
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED.

In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(