Bug 488985

Created attachment 282103 [details]
startup log

Created attachment 282104 [details]
system log

Scott sorry, I tried but don't understand ;-)
On my side static configuration works fine (without reboot needed).

So please attach all relevant screenshots of YaST lan when you change anything.
Attach also /etc/sysconfig/network/* directory, then we see

Created attachment 282496 [details]
self titled

Created attachment 282497 [details]
self titled

Created attachment 282498 [details]
New start-up log

Attach also /etc/sysconfig/network/* directory, then we see

DAM!!! Sorry to have to ask Michael but can you give me the console zip/tar/gzip command to zip up the files and directories you want. I had forgotten that Konquer has had all of its zipping GUI interface removed and it was so simple to create 4 different types of archives. Now we have a very poor GUI achiever to create an achieve.  The Program ArK will zipp files but no directories yet and I assume you want the files in the /etc/sysconfig/network/
as well as its sub-directories. I do not know how ArK deals with root protected file permissions as there in also no native way to run ARK as root.

tar cvzf sysconfig.tgz /etc/sysconfig/network/*

Created attachment 282699 [details]
tar file as requested

Thank you for the tar command - yes I know I should know how to do more things at console ;-)

Tambet, I bet this is networkmanager/netconfig issue.
In /etc/sysconfig/network/config user has NETCONFIG_DNS_STATIC_SERVERS="123.200.191.17 123.200.191.18"

Please follow the instructions from the warning message from comment #4 attachment. It means "if you choose to use NetworkManager, you must use NetworkManager tools to configure the networking". Just as ifup won't use the settings defined in NM, the opposite won't work either.

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

RE- Opened due marking a bug as closed due to dupe requires one of the two to still be valid

QA - Major Bug seems to be inactive in Assignment

In the attached etc/sysconfig/network/config from comment #10,
you've the following setting:

  NETWORKMANAGER="yes"

except of this, there are following netconfig DNS settings:

  NETCONFIG_DNS_POLICY="auto"
  NETCONFIG_DNS_FORWARDER="resolver"
  NETCONFIG_DNS_STATIC_SEARCHLIST="site-010"
  NETCONFIG_DNS_STATIC_SERVERS="123.200.191.17 123.200.191.18"

Note: The netconfig utility will apply the static settings only,
when NetworkManager does not provide anything.

This bug is about static IP via IFUP, but in the config, the
NetworkManager is active not IFUP.

Further,
your static settings (etc/sysconfig/network) are broken:

$ grep ^IPADDR ifcfg-eth0 
IPADDR='192.168.100.10/24'
                ^^^
                 |

                here
$ cat routes
default 192.168.1.1 - - 
                ^
                |
               here

So even you disable NM using NETWORKMANAGER="no" and reboot
(restart network), it will not work.
The gateway (192.168.1.1) is not in the 192.168.100.10/24.

Fix is to change IPADDR="192.168.1.10/24" in ifcfg-eth0 (dhcp
assigns 192.168.1.4/24 to this machine).

Created attachment 309144 [details]
1 of 1 screen shot

I dont open Bugs lightly and this one is reproducible 100%. I would suggest that the log files contain many many tests and the part of the log file you viewed was a previous test.
The static IP is allocated by IFUP, however no DNS Services are available despite them being assigned in IFUP. 
This is so easy to duplicate.
1. Remove ALL DHCP Services from the test PC.
2.Assign both a static IP with IFUP and DNS Servers IP.
3. Open FF - No response.
4. See netstat and ip -r on the test PC
5. See attached.

Re-Opened see Comment #17

I can elaborate on comment #17. With NO DHCP Services running the fault lies in the multiple DNS Server Fields IP Addresses. If you only fill in 1 DNS Server IP ALL will be good and this is a work around.
However if you use the standard of filling in a Primary and Secondary DNS Server Fields IP the IP number get run together making it not possible to address any DNS Server as both IP fields are run together.
Your reproducible testing should revile this as the problem as soon as you provide comment #17 above environment

Removed invalid bug 425434, 489542, 502930 references, because this
bug report is about IFUP, not about the NetworkManager.

When you want static configuration for NetworkManager, please use
the NetworkManager (GUI) tools to configure it.

(In reply to comment #17)
> Created an attachment (id=309144) [details]
> 1 of 1 screen shot
> 
> I dont open Bugs lightly and this one is reproducible 100%. I would suggest
> that the log files contain many many tests and the part of the log file you
> viewed was a previous test.

Then provide consistent problem description, configuration and logs.
It also makes sense in many situation to reset the logs using e.g.:

  logrotate -f /etc/logrotate.conf

and to provide only log from the time the problem occurs. In case of "ifup"
problems the following -- in one line please:

  tar cvzf /tmp/my_config_and_logs.tgz
         /etc/sysconfig/network
         /var/run/netconfig /etc/resolv.conf*
         /var/log/{boot.msg,messages,NetworkManager}

It makes also sense to redirect outputs of e.g.:

  (ip addr show ; ip -4 route show ; ip -6 route show) >/tmp/ip-output.txt

and add the /tmp/ip-output.txt file to the above tar command.

But if the logs provided are not sufficient, you'll be asked for more.


Please read my comment #16 and the suggestions how to fix your _config_.

I don't explain things for fun or because of too much time. But I'll
make an exception now and repeat it again, perhaps it was unclear:

                You have an invalid configuration.

  The IP address of your default gateway -- 192.168.1.1 -- is not inside
  of the IP network of the network card -- 192.168.100.10/24 -- and the
  default route via this gateway can't be applied (see "netstat -r" or
  better, "ip route show" output). Try it manually if you like:

    # ip -f inet addr flush dev eth0
    # ip addr add 192.168.100.10/24 dev eth0
    # ip route add default via 192.168.1.1 dev eth0
    RTNETLINK answers: No such process
    # ip route show

  Because of the missing default route, the name servers _can't_ be
  reached. That is, a "ping 123.200.191.17" by address will not work.

  The DNS configuration in /etc/sysconfig/network/config:

    NETCONFIG_DNS_POLICY="auto"
    NETCONFIG_DNS_FORWARDER="resolver"
    NETCONFIG_DNS_STATIC_SEARCHLIST="site-010"
    NETCONFIG_DNS_STATIC_SERVERS="123.200.191.17 123.200.191.18"

  is completely __correct__.

  But it will be not used because the NetworkManager is active.
  See NETWORKMANAGER=yes in network/config (it will be applied
  only as fallback, when the NetworkManager does not provide any,
  see also documentation in "man 8 netconfig").

  When the NetworkManager is _disabled_, it will result in the
  following /etc/resolv.conf:
    search site-010
    nameserver 123.200.191.17
    nameserver 123.200.191.18
  except you've modified the file by hand. In this case, the
  "netconfig update" will generate /etc/resolv.conf.netconfig
   and inform you about.

(In reply to comment #19)
> I can elaborate on comment #17. With NO DHCP Services running the fault
> lies in
> the multiple DNS Server Fields IP Addresses. If you only fill in 1 DNS Server
> IP ALL will be good and this is a work around.
> However if you use the standard of filling in a Primary and Secondary DNS
> Server Fields IP the IP number get run together making it not possible to
> address any DNS Server as both IP fields are run together.
> Your reproducible testing should revile this as the problem as soon as you
> provide comment #17 above environment

It is completely not a problem to specify two nameservers in yast2.
You mean the resulting configuration
    NETCONFIG_DNS_STATIC_SERVERS="123.200.191.17 123.200.191.18"
right?
This configuration _is_ correct. Don't jump to conclusions too fast.

Re Comment #20 - 

I accept your comment, however I still maintain that IFUP cannot assign a 'workable' static IP when both DNS Server fields are entered.
In the case where both DNS Server fields are entered there is NO valid NETCONFIG DNS Server Field.

The IP/Netmask/Gateway are presented correctly by NETCONFIG, but as both DNS Server IP fields are presented in 1 only NETCONFIG line, the PC IS assigned an IP, but NO DNS SERVERS.

A PC with all the correct manual IP fields is totally useless when the PC has no valid DNS Servers to call upon -Hence the slightly, misleading title.

It gets worse when there are no DHCP Services being on offer on the LAN. IF the manual IP and manual DNS Server Fields are both configured the PC DOES have an IP but NO DNS Servers to reach - Hence again the PC is totally useless.

The workaround is to ONLY ever configure 1 DNS SERVER IP - The the PC is functional, but this conditional workaround in NOT acceptable.

You may leave this closed as INVALID - I am just the messenger!

(In reply to comment #21)
> Re Comment #20 - 
> 
> I accept your comment, however I still maintain that IFUP cannot assign
> a 'workable' static IP when both DNS Server fields are entered.

I don't understand. What does the IP configuration has to do with DNS,
except that DNS needs a correct IP configuration?

IFUP can and will assign a "a 'workable' static IP" when the ip config
is correct, even DNS server settings are incorrect. What will not work
then is DNS, but you can access hosts by IP, e.g.: http://130.57.4.24/

But the another way arround it does not work: when the IP + gateway
are incorrect (http://130.57.4.24/ can't be reached), then DNS will
fail as well because the DNS server IP can't be reached.

Further, netconfig will not apply any static DNS settings by default
(DNS policy "auto", see also "man 8 netconfig") when NetworkManager
is enabled, except the NetworkManager does not provide any DNS servers.

> In the case where both DNS Server fields are entered there is NO
> valid NETCONFIG DNS Server Field.

Sorry, but I don't understand what you mean. Two (maximal 3) DNS
servers are completely OK and work fine -- except the DNS servers
are broken, you set invalid DNS server IPs or the IP configuration
incorrect as in your case.

Let's take your config as example - corrected (only the non-empty
and required settings):

/etc/sysconfig/network/ifcfg-eth0:
BOOTPROTO='static'
STARTMODE='auto'
USERCONTROL='no'
#IPADDR='192.168.100.10/24'
#        ^^^^^^^^^^^^^^^^^
# IP incorrect, default route via 192.168.1.1 can't be set: see
# comment #16 and comment #20.
IPADDR='192.168.1.10/24'
#       ^^^^^^^^^^^^^^^
# corrected based on dhcp logs in comment #2.

/etc/sysconfig/network/routes:
default 192.168.1.1 - -

/etc/sysconfig/network/config:
NETWORKMANAGER="no
# ^^^^^^^^^^^^^^^^
# !!! important !!!
#
# When NetworkManager is active, netconfig in DNS policy "auto"
# is using settings (e.g. DNS) from the NetworkManager only
# (except NetworkManager does not provide anything).
#
NETCONFIG_DNS_POLICY="auto"
NETCONFIG_DNS_FORWARDER="resolver"
NETCONFIG_DNS_STATIC_SEARCHLIST="site-010"
NETCONFIG_DNS_STATIC_SERVERS="123.200.191.17 123.200.191.18"

To apply the settings manually use e.g.:
  netconfig update -v ; rcnetwork restart

They results in following settings in the running system:

# ip-4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 [...]
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0

# ip -4 route show dev eth0
192.168.1.0/24  proto kernel  scope link  src 192.168.1.10
default via 192.168.1.1

# grep -v ^# /etc/resolv.conf
search site-010
nameserver 123.200.191.17
nameserver 123.200.191.18

and all works fine (except you break it e.g. with firewall).

> The IP/Netmask/Gateway are presented correctly by NETCONFIG, but as both DNS
> Server IP fields are presented in 1 only NETCONFIG line, the PC IS assigned
> an IP, but NO DNS SERVERS.

NO, this is definitively wrong.

Netconfig writes each of them separatelly like in the following
lines (simplified):

(
  . /etc/sysconfig/network/config
  if test -n "$NETCONFIG_DNS_STATIC_SEARCHLIST" ; then
     echo "search $NETCONFIG_DNS_STATIC_SEARCHLIST"
  fi
  for ip in $NETCONFIG_DNS_STATIC_SERVERS ; do
    test -n "$ip" && echo "nameserver $ip"
  done
) > /etc/resolv.conf


> A PC with all the correct manual IP fields is totally useless when
> the PC has no valid DNS Servers to call upon -Hence the slightly,
> misleading title.

No, it isn't useless.
You can work using IP's, define all IP<->name mappings in /etc/hosts,
configure to use MDNS, NIS, LDAP, ... instead of DNS when you like.

Further, you can just install & start "bind". The system will use
this local name server automatically when there is no name server
defined in /etc/resolv.conf.

> It gets worse when there are no DHCP Services being on offer on
> the LAN. IF the manual IP and manual DNS Server Fields are both
> configured the PC DOES have an IP but NO DNS Servers to reach
> - Hence again the PC is totally useless.

No, see above.

> The workaround is to ONLY ever configure 1 DNS SERVER IP - The
> the PC is functional, but this conditional workaround in NOT
> acceptable.

This is not a workaround, this is simply crap. Sorry.

> You may leave this closed as INVALID - I am just the messenger!

Of course I keep it closed.
This report is invalid - your problem is very simple:

1) YOUR IP ADDRESS IS WRONG AND THE GATEWAY CAN NOT BE SET.
2) YOU HAVE TO DISABLE NETWORKMANAGER WHEN YOU WANT IFUP.
3) GO TO 1).

(In reply to comment #22)
> /etc/sysconfig/network/config:
> NETWORKMANAGER="no
> # ^^^^^^^^^^^^^^^^
> # !!! important !!!

This has to be
  NETWORKMANAGER="no"
with " at the end of course.

I am happy to leave this bug as invalid although I will leave an end comment of my own.
I do NOT know what Network Manager has to do with this bug which is solely about IFUP.
This bugs log data probably contains many many combinations of NM and IFUP for testing purposes.
This bug is 100% reproducible and perhaps language translation is at fault.
The term "Static IP" used in this bug refers to the user configuration of
IP, Subnet, Gateway and 2 x DNS Server IP's.
To reproduce this bug please follow these simple steps that I have written about adnauseous.
1. Use a test LAN environment that DOES NOT provide ANY DHCP Services.
2. Configure a static IP, Subnet, Gateway and 2 x DNS Server IP's
3. Attempt to communicate with the DNS Servers via a browser - This will fail!

The reason is that when BOTH DNS Server IP's are specified AND
the LAN environment does NOT provide any DHCP Services at all THEN
both DNS Server IP's so specified are taken from the Yast Screen and BOTH IP addresses are set in config as 1 single address.

For Example. 
IF I configure Yast with the DNS Servers of
123.200.191.17 AND 123.200.191.18
the fields that are taken from Yast into the actual config are either run together nor make no sense as the PC, under test conditions, cannot reach ANY DNS Server IP's.

If you CANNOT provide a LAN environment WHERE no DHCP Services are present this test will fail.

Why is this bug a huge problem? ANY secure LAN environment does not provide any DHCP Services and valid IP's are NOT handed out to any PC that connects to a secure LAN.
This lack of DHCP Services being present escapes just about all testing for some unknown reason, perhaps because the lack of experience of developers that have never been exposed to highly secure LAN Environments.

(In reply to comment #24)
> I am happy to leave this bug as invalid although I will leave an end comment of
> my own.
> I do NOT know what Network Manager has to do with this bug which is solely
> about IFUP.

They're mutually exclusive:
  NETWORKMANAGER=yes -->> IFUP == off
  NETWORKMANAGER=no  -->> IFUP == on

> This bugs log data probably contains many many combinations of NM and IFUP for
> testing purposes.

Then reset them with "logrotate -f /etc/logrotate.conf" and provide clean logs.

> This bug is 100% reproducible and perhaps language translation is at fault.
> The term "Static IP" used in this bug refers to the user configuration of
> IP, Subnet, Gateway and 2 x DNS Server IP's.
> To reproduce this bug please follow these simple steps that I have written
> about adnauseous.
> 1. Use a test LAN environment that DOES NOT provide ANY DHCP Services.
> 2. Configure a static IP, Subnet, Gateway and 2 x DNS Server IP's
> 3. Attempt to communicate with the DNS Servers via a browser - This will fail!

No, it generally does not fail.
Except in your case because of invalid gateway( 192.168.1.1) configuration,
that is not inside/member of the directly attached network (192.168.100.0/24,
that is 192.168.100.<1..254> as specified in the IPADDR field).
As effect, the default route, that is required to reach the DNS server IPs
can not be set.

> The reason is that when BOTH DNS Server IP's are specified AND
> the LAN environment does NOT provide any DHCP Services at all THEN
> both DNS Server IP's so specified are taken from the Yast Screen and BOTH IP
> addresses are set in config as 1 single address.

Where? They're written into /etc/resolv.conf in two lines:

nameserver 123.200.191.17
nameserver 123.200.191.18

> For Example. 
> IF I configure Yast with the DNS Servers of
> 123.200.191.17 AND 123.200.191.18
> the fields that are taken from Yast into the actual config are either run
> together nor make no sense as the PC, under test conditions, cannot reach
> ANY DNS Server IP's.

Where are they "run together"?

> If you CANNOT provide a LAN environment WHERE no DHCP Services are present
> this test will fail.
>
> Why is this bug a huge problem? ANY secure LAN environment does not provide
> any DHCP Services and valid IP's are NOT handed out to any PC that connects
> to a secure LAN.
> This lack of DHCP Services being present escapes just about all testing for
> some unknown reason, perhaps because the lack of experience of developers
> that have never been exposed to highly secure LAN Environments.

This bug is neither a huge problem nor closed because of missed test LAN without DHCP server. It is simply a problem we can't solve because the
configuration is not correct and the reporter does not want to accept this.

>No, it generally does not fail.
>Except in your case because of invalid gateway( 192.168.1.1) configuration,
>that is not inside/member of the directly attached network (192.168.100.0/24,
>that is 192.168.100.<1..254> as specified in the IPADDR field).
>As effect, the default route, that is required to reach the DNS server IPs
>can not be set.
The gateway IP and IP address are both inside the configured route of the router of 192.168.1.1/24
>...a LAN that provides NO DHP Services....
A LAN at suse.de that was tested where NO DHCP Services are present can be found in bug
https://bugzilla.novell.com/show_bug.cgi?id=526582

Sorry I hit enter before I finished above.
I publish 3 different routes on the same physical LAN with NO DHCP Services default.
192.168.1.1/24 Default with gateway of 192.168.1.1 *ARP*
192.168.10.1/24 with gateway defined of 192.168.10.1
192.168.100.1/24 with gateway of 192.168.100.1

The default route with gateway of 192.168.1.1 is published on the LAN via ARP Proxy meaning that I could actually use *ANY* gateway IP within the route of 192.168.1.1/24 and it would be valid.
Although I do publish a different gateways per route this is done for cosmetic purposes only in case 1 of my admins forgets the published gateway, not that it matters as I said gateway 192.168.1.1 is published on *ALL* LAN routes both physical or logical.

Whilst the LAN route of 192.168.100.1/24 is really not within the defined private 'black hole' as defined by IANA, it helps my admins not to stuff up *any* IP assignment by maintaining the same subnet.

With hundreds of PC's to manage securely both physical and WIFI, no one can plug any PC into a socket and receive a valid IP etc via DHCP Services. This is why DHCP Services are NOT available as this environment is a secure one that has to be via the nature of the work carried out here.

> I am happy to leave this bug as invalid .....
I surrender, last comment for info only.

P.S With the Enter Button next to the SHFT on the keyboard its easy to hit it in error - I wish we had a secondary 'Confirm Post' dialogue box after hitting 'Enter' in Bugzilla but dont have time to raise a new feature request ;-)