Bug 134886 - Network Manager and Static IP Addresses
Network Manager and Static IP Addresses
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
: Reopened
: 212981 244671 320001 357251 365301 375481 378501 388641 391351 416331 428532 447500 453351 (view as bug list)
Depends On:
Blocks: NMF9Blockers
  Show dependency treegraph
 
Reported: 2004-10-06 19:46 EDT by Jonathan Blandford
Modified: 2013-04-02 00:20 EDT (History)
43 users (show)

See Also:
Fixed In Version: 0.7.0-0.6.9.svn3675.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-09 17:47:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Combined ifcfg-eth? (1.04 KB, text/plain)
2008-04-02 02:35 EDT, Gilboa Davara
no flags Details
ifconfig output (1.77 KB, text/plain)
2008-04-02 02:35 EDT, Gilboa Davara
no flags Details
ifconfig output with NM disabled (1.95 KB, text/plain)
2008-04-02 02:36 EDT, Gilboa Davara
no flags Details
Combined ifcfg-eth? (Fixed) (807 bytes, text/plain)
2008-04-02 02:38 EDT, Gilboa Davara
no flags Details
Files for your request (210.44 KB, application/octet-stream)
2008-05-08 17:11 EDT, BROCKLEHURST ERIC
no flags Details
Chris /var/adm/messages - first boot after install (101.12 KB, text/plain)
2008-05-10 23:16 EDT, Chris Ricker
no flags Details
Chris /etc/sysconfig/network-scripts/ifcfg-eth0 (288 bytes, text/plain)
2008-05-10 23:17 EDT, Chris Ricker
no flags Details
ifcfg-eth0 file as generated by system-config-network (308 bytes, text/plain)
2008-05-13 15:21 EDT, Linus Torvalds
no flags Details
nm-tool output (751 bytes, text/plain)
2008-05-13 18:42 EDT, Linus Torvalds
no flags Details
/var/log/messages network-related stuff (2.99 KB, text/plain)
2008-05-13 21:03 EDT, Linus Torvalds
no flags Details
/var/log/messages with eth0 NM-enabled (3.82 KB, text/plain)
2008-05-13 22:29 EDT, Linus Torvalds
no flags Details
Yet another /var/log/messages file (13.18 KB, text/plain)
2008-05-14 12:53 EDT, Linus Torvalds
no flags Details

  None (edit)
Description Jonathan Blandford 2004-10-06 19:46:17 EDT
Network Manager doesn't know about static IP addresses on ethernet
cards.  It will blindly run dhclient when switching to Wired mode.
Comment 1 Dan Williams 2004-10-12 07:14:53 EDT
Should be fixed in CVS.  Pulls ADDR, GATEWAY, and NETMASK from the
config files using shvar.c and honors those values if the device is
set for BOOTPROTO=none (ie, not dhcp or bootp).
Comment 2 Jesse Keating 2005-12-01 14:06:16 EST
What about BOOTPROTO=static ?  Thats what wound up in my ifcfg-eth0....  NM
didn't seem to use my settings.
Comment 3 Jesse Keating 2005-12-01 14:12:40 EST
Changing my BOOTPROTO didn't help.  Seems there is something else going on.  I
will investigate.
Comment 4 Joel Gibson 2006-05-10 09:53:48 EDT
I am running FC5 and am experiencing the same problem.  I have set ifcfg-eth0
bootproto = none and also tried = static.  Each time I start NetworkManager it
erases my resolv.conf file and also uses DHCP instead.  Is there a way to
configure so that NetworkManager does not erase the resolv.conf file and uses
the static IP settings from the ifcfg-eth0 file?  I am only using NetworkManager
to manage my wireless connection.  I would like to switch between wireless and
wired without the hastle of losing my static IP.
Comment 5 Karel Zak 2006-06-26 06:20:56 EDT
What about PEERDNS=no ? The NetworkManager should be able to use only part of
information from DHCP and it shouldn't touch my resolv.conf if there is PEERDNS=no.
Comment 6 John Thacker 2006-10-29 16:57:24 EST
Changing version to correct version bug was filed against.  (Some were filed
against "test3" when they clearly are for FC3T2, a test for FC3.)
Comment 7 Matthias Clasen 2006-11-26 13:39:39 EST
Updating version according to comment 4.
Dan, is this fixed in FC6/FC7 ?
Comment 8 J. Randall Owens 2006-12-17 19:36:06 EST
Not fixed yet in FC6. Very annoying when I finally had to use the NetworkManager
if I want Gaim to work at all, after years of hand-crafted network
configuration. This box does double duty as a server and workstation, so I need
to give it a static IP, yet I need to use NM if I want to use Gaim. For now, I
can assign it the same IP from the DHCP server; I'm just lucky it was on the
right side of the other static machine's IP so that I can do it as DHCP.
Comment 9 J. Randall Owens 2006-12-18 00:39:31 EST
I should add: Given my lack of experience with the GUI network control tools, I
wouldn't know whether my own problems are more directly related to
NetworkManager or to system-config-network. Since this bug is already open here,
I'm assuming it's NetworkManager for now.
Comment 10 Jesse Keating 2006-12-18 08:41:53 EST
(In reply to comment #8)
> Not fixed yet in FC6. Very annoying when I finally had to use the NetworkManager
> if I want Gaim to work at all, after years of hand-crafted network
> configuration. This box does double duty as a server and workstation, so I need
> to give it a static IP, yet I need to use NM if I want to use Gaim. For now, I
> can assign it the same IP from the DHCP server; I'm just lucky it was on the
> right side of the other static machine's IP so that I can do it as DHCP.

Unless someting has regressed really poorly, I don't see how you need to be
actually using NetworkManager for gaim to function.  If you do, this is clearly
a bug in our build/packaging of gaim and should be filed against gaim.
Comment 11 J. Randall Owens 2006-12-23 21:41:05 EST
(In reply to comment #10)
> (In reply to comment #8)
> Unless someting has regressed really poorly, I don't see how you need to be
> actually using NetworkManager for gaim to function.  If you do, this is clearly
> a bug in our build/packaging of gaim and should be filed against gaim.

It's already filed against Gaim, I think upstream. Apparently, it's a new
"feature" in Gaim. Lessee....
http://sourceforge.net/tracker/index.php?func=detail&aid=1580509&group_id=235&atid=100235
there. It's supposed to autodetect whether you're networked when Gaim is started
so it knows whether to auto-login or not, I gather.
For my part, even though it's Gaim that really made this leap to my attention, I
noticed this behaviour and have been bothered by it for quite a while now,
though I don't know whether the specifics that trouble me most are in the
NetworkManager component or system-config-network; I'm not quite clear where one
begins and the other ends. I certainly find it extra insulting that
system-config-network seems to give you an option whether to use a static IP or
dynamic, but that option is then blindly ignored when NetworkManager is enabled.
That could be considered just a UI flaw in s-c-n, I suppose, if not having the
option is the desired functionality.
Anyway, the main point of my commenting here was just to confirm that the
behaviour is still present in FC6.
Comment 12 Jim Lawrence 2007-11-11 23:07:24 EST
This bug is also evident in FC8   
Comment 13 Dan Williams 2007-11-13 11:50:58 EST
This bug will now be the "NM and static IP bug".  Any bugs related to NM support
of static IP will be duped to this one.

The path forward here is the following.  A system settings service will run
which will collect connections from ifcfg-* files and other places and provide
this information to NetworkManager.  NM will then have the information it needs
to bring up connections (even wireless ones) on boot before a login.
Comment 14 Dan Williams 2007-11-13 11:51:27 EST
*** Bug 357251 has been marked as a duplicate of this bug. ***
Comment 15 Dan Williams 2007-11-13 11:59:02 EST
*** Bug 244671 has been marked as a duplicate of this bug. ***
Comment 16 Dan Williams 2007-11-13 12:02:06 EST
*** Bug 365301 has been marked as a duplicate of this bug. ***
Comment 17 Dan Williams 2007-11-13 12:02:43 EST
*** Bug 375481 has been marked as a duplicate of this bug. ***
Comment 18 Dan Williams 2007-11-13 12:02:52 EST
*** Bug 378501 has been marked as a duplicate of this bug. ***
Comment 19 Jakub 'Livio' Rusinek 2007-11-13 12:07:51 EST
Stupid question: why we just don't take Ubuntu patches [if any]?
Comment 20 Jesse Keating 2007-11-13 13:12:23 EST
Because they don't exist.  Ubuntu is probably using an old version of
NetworkManager and has something done on top of that or not even necessary. 
We're using a newly rewritten NetworkManager.

(I'm removing my personal address from the CC list)
Comment 21 Dan Williams 2007-11-13 14:13:04 EST
*** Bug 320001 has been marked as a duplicate of this bug. ***
Comment 22 Dan Williams 2007-11-13 14:17:00 EST
*** Bug 283301 has been marked as a duplicate of this bug. ***
Comment 23 Dan Williams 2007-11-13 15:18:39 EST
The Ubuntu patches are a short-term hack for 0.6.5 and are not where we want to
be with NM 0.7.
Comment 24 Jakub 'Livio' Rusinek 2007-11-13 15:25:27 EST
If NM will be default starting from F9 static configuration is a must.
Comment 25 Linus Torvalds 2007-11-17 17:39:30 EST
Btw, having now looked at NM at another machine (one where I really do want to
use it, since it's a laptop that gets moved around), and I noticed that the
problem is not at all limited to NM not being able to handle static network setups.

Even with the machine happily doing DHCP, it's broken. Because NM doesn't
actually seem to connect until I log in. So if I want to log in remotely (which
I do want to, for any configuration etc), I'm just screwed.

Maybe there is some NM setup that I've missed, but if so, it's too damn subtle
for me to see.
Comment 26 Jesse Keating 2007-11-17 19:26:05 EST
(In reply to comment #25)
> Btw, having now looked at NM at another machine (one where I really do want to
> use it, since it's a laptop that gets moved around), and I noticed that the
> problem is not at all limited to NM not being able to handle static network
setups.
> 
> Even with the machine happily doing DHCP, it's broken. Because NM doesn't
> actually seem to connect until I log in. So if I want to log in remotely (which
> I do want to, for any configuration etc), I'm just screwed.
> 
> Maybe there is some NM setup that I've missed, but if so, it's too damn subtle
> for me to see.

The infrastructure just isn't quite in place yet for doing network before login
with NM.  The rewrite that Dan did leading up to F8 was the initial leap in that
direction.  Now that we have a new API and somewhat stable backend, we can start
to enable things like system level configurations that get turned on at boot
time vs at login time.  However for now it is known that the network won't come
up until you log in.  Dan says he plans to improve this with updates to F8 over
time.
Comment 27 Couret Charles-Antoine 2007-11-18 13:37:16 EST
I confirm this bug with the version of the F8

The applet takes about 1-2 minutes to say that I wired network and should
j'active manually via  "system-config-network" What I can not conceal is quite
annoying when I know that under Fedora 7 and earlier, no problem at this level.
Moreover, this configuration manager networks sometimes makes me skip the DNS
address previously set, I should fit the activated and then have a network
connection in order.
Comment 28 Dan Williams 2007-11-20 11:10:19 EST
*** Bug 391351 has been marked as a duplicate of this bug. ***
Comment 29 Jakub 'Livio' Rusinek 2007-11-27 11:26:36 EST
More and more CC's but no action...
Comment 30 John 2007-11-28 22:00:58 EST
Is there a workaround until we get an update?

I understand the log in issue...don't like it; but I get it. 

It would seem that we could do some kind of 'ifconfig' or 'ip' command to
temporarily let us have a stable static without having to reset it each time the
machine boots.
Comment 31 Dan Williams 2007-12-03 10:15:15 EST
The workaround is to disable NetworkManager if you want to use static IPs on
interfaces at this time.

@jakub: there certainly _is_ action, that is why the bug is in the Assigned
state.  Please see upstream changelogs here:

http://svn.gnome.org/viewvc/NetworkManager/trunk/ChangeLog?view=log

Anything in the system-settings/ directory listed in that changelog is related
both to enabling static IP support via /etc/sysconfig/network-scripts/* files
and to allowing you to have your network connected before login.
Comment 32 Dan Williams 2007-12-03 11:34:36 EST
*** Bug 388641 has been marked as a duplicate of this bug. ***
Comment 33 Dan Williams 2007-12-09 12:22:47 EST
*** Bug 416331 has been marked as a duplicate of this bug. ***
Comment 34 ghanshyam udhwani 2008-01-07 20:09:19 EST
system-config-network 1.3.99 is disturbed
Comment 35 Jakub 'Livio' Rusinek 2008-01-09 13:18:25 EST
Disturbed? So what? I don't get it.
It doesn't play with NM, or it plays with NM?
Comment 36 Sergio Pascual 2008-01-17 09:40:36 EST
*** Bug 212981 has been marked as a duplicate of this bug. ***
Comment 37 Dan Williams 2008-02-01 16:35:01 EST
*** Bug 428532 has been marked as a duplicate of this bug. ***
Comment 38 Joachim Frieben 2008-03-19 13:13:50 EDT
NetworkManager-0.7.0-0.9.1.svn3476.fc9 now allows to use DHCP based wireless
in addition to a static connection for eth1 to which my printer is connected.
I was only surprised that keys-wlan0 was not used, thus clicking the active
AP in nm-applet did not have any effect. Only after adding a new connection
in nm-applet, I was prompted by for connection details including WEP key.
Wireless is working after completion of this additional step. Moreover, there
is new directory .gconf/system/networking now which was absent before [I
hadn't been using NM lately].
Comment 39 Thomas J. Baker 2008-03-24 09:03:48 EDT
I just reinstalled F9B and was having trouble with NM breaking DNS on a static
setup. Changing the installed ifcfg-eth0 bootproto from none to static made NM
behave properly (and instantly!). So should NM equate bootproto of none to
static or should anaconda(?) properly set bootproto to static?
Comment 40 Thomas J. Baker 2008-03-25 09:54:47 EDT
After updates this morning and rebooting, NM appears to be breaking stuff again.
It keeps rewriting /etc/resolv.conf. /etc/init.d/network was checkconfiged off.
I'm not sure if it's problems with NM or problems with how the config file or
system was set up by anaconda. Is there an explanation of how it is supposed to
work somewhere? At least if I knew that ifcfg-eth0 was set up right, then I
could continue to test NM and fix things by hand after reboots until NM works
correctly.
Comment 41 Dan Williams 2008-03-25 10:48:46 EDT
When NM is running, it will manage /etc/resolv.conf.  NM also starts
nm-system-settings, which will read configuration from your ifcfg-xxx files
(though in the version in F8 and F9-beta it reads from
/etc/sysconfig/networking/profiles/default but that's changed to
/etc/sysconfig/network-scripts/ in svn3475 and later because everyone wants
profiles to die die die).  If you have ifcfg-eth0 set up with a static IP, NM
should respect that configuration and do the right thing with it.
Comment 42 markm 2008-03-25 11:00:15 EDT
instead of playing with a crappy Network Manager (which usually doesn't work),
try wicd http://wicd.sf.net/ - it's just a python script, which does what
Network Manager was designed for, and it actually works. Maybe in Fedora 678
network manager will be usable, but as I can see, nothing actually happens -
since Fedora 3 network manager has all the same bugs and lacks of functionalities.
Comment 43 Jakub 'Livio' Rusinek 2008-03-25 11:10:31 EDT
Marek, NM for basic tasks, like sitting in tray, using DHCP and notifying of
connection state, works well :P .
Comment 44 markm 2008-03-25 11:46:02 EDT
if you're using wired connection - true, but if you're using wireless connection
- not true. Examples:

1. I am using the same laptop at home and at work - I do like to suspend my
laptop on my way home / to work - when I resume, NM cannot connect to any
network, I need to restart NM service and also I need to have cron to overwrite
resolv.conf file, as I prefer to use open dns.

2. Network Manager get disconnected easily (while using iwl3945 driver), then it
cannot restore connection - sometimes restarting NM service helps, other times I
need to restart entire system (!).

3. Network Manager connects to the internet after I log on, very annoying. I
don't want to set up connection per every user (yes, I do have multiple accounts
on my laptop).

4. Network Manager stores passwords in user's keychain - really annoying, as
it's per user setting (see point 3) and keychain doesn't work properly in Fedora
8 (you cannot completely avoid question for a password). 

I could write longer story, but I think all these "features" of Network Manager
are well described in this bugzilla and all them are waiting to be resolved for
couple of versions of Fedora.
Comment 45 Thomas J. Baker 2008-03-25 15:58:45 EDT
OK, so I've got NetworkManager-0.7.0-0.9.1.svn3476.fc9.i386 and a normal
ifcfg-eth0 that was created by system-config-network:

# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:08:74:4f:75:2e
IPADDR=my real ip here
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=my real gateway here
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no

With this setup, the system boots and has a static IP address. Once I log in, I
see that NM applet doesn't think there are any network devices though I can log
in via ssh so eth0 is working. Evolution and Firefox think there's no network
because they depend on NM telling them there is one and when I force them
online, they fail because /etc/resolv.conf is empty again (just a comment that
it's generated by NM and don't edit it).

If NM only parses ifcfg-ethx files, where does it get it's DNS entries?

(And for the naysayers, NM works perfectly on my wired/wireless laptop in a dhcp
environment. This is a different setup, a desktop machine with only a wired
static connection, which is newish territory for NM.)
Comment 46 Dan Williams 2008-03-26 01:14:39 EDT
(In reply to comment #45)
> OK, so I've got NetworkManager-0.7.0-0.9.1.svn3476.fc9.i386 and a normal
> ifcfg-eth0 that was created by system-config-network:
> 
> # Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
> DEVICE=eth0
> BOOTPROTO=static
> HWADDR=00:08:74:4f:75:2e
> IPADDR=my real ip here
> NETMASK=255.255.255.0
> ONBOOT=yes
> GATEWAY=my real gateway here
> TYPE=Ethernet
> USERCTL=no
> PEERDNS=yes
> IPV6INIT=no
> NM_CONTROLLED=no

^^^^^ remove the NM_CONTROLLED=no (make it "yes") and NM will find the
connection.  Or you can check the "Let NetworkManager control this device"
checkbox in system-config-network.

Then add:

DNS1=x.x.x.x
DNS2=x.x.x.x
DNS3=x.x.x.x
SEARCH="lab.foobar.com production.foobar.com"

and NM should pick those up and write both the DNS servers and the search
domains to /etc/resolv.conf.  If NM does not do this when eth0 is the main
active connection, it's a bug.
Comment 47 Thomas J. Baker 2008-03-27 15:57:36 EDT
As expected, setting up ifcfg-eth0 per #46 makes everything work fine. Now the
question, should this bug be reassigned to whatever in
anaconda/system-config-network is writing out the ifcfg-ethx files? That now is
where the bug lies.
Comment 48 Bill Pemberton 2008-03-28 17:19:39 EDT
I just did an install of the F9 beta and it ended up with a trashed network 
connection due to NetworkManager.  I configured a static address during the 
install.  ifcfg-eth0 had the correct static address,  but NetworkManager was 
doing dhcp for eth0.  In addition /etc/resolv.conf was blank even though I 
configured DNS servers in the install.
Comment 49 Dan Williams 2008-03-28 18:12:01 EDT
wfp5p: the version of NM in the beta looks for files in the a different place
(where system-config-network writes them out) instead of where anaconda writes
them out.  That's been corrected if you update to the latest version of NM
(svn3476 or later) from rawhide.
Comment 50 Gilboa Davara 2008-04-01 10:21:59 EDT
(In reply to comment #48)
> I just did an install of the F9 beta and it ended up with a trashed network 
> connection due to NetworkManager.  I configured a static address during the 
> install.  ifcfg-eth0 had the correct static address,  but NetworkManager was 
> doing dhcp for eth0.  In addition /etc/resolv.conf was blank even though I 
> configured DNS servers in the install.

Same here.
4 network devices - all configured as static during the installation. (with eth0
having the default gateway and DNS')
Machine was configured to run head-less. (Remote GUI over SSH only)
Never the less, NM tried to get DHCP address from all interface - ignoring the
static configuration completely.

Haven't tried the latest rawhide, though.

- Gilboa
Comment 51 Dan Williams 2008-04-01 12:38:54 EDT
Gilboa; please try latest rawhide, anything > svn3476 reads the ifcfg files from
the correct place instead of the system-config-network profiles directory.  If
NM can't find your ifcfg files, then it's going to do DHCP on the interfaces by
default.
Comment 52 Gilboa Davara 2008-04-01 17:17:10 EDT
AFAICS svn3476 is the latest build.
Stale mirrors?
Comment 53 Gilboa Davara 2008-04-02 02:34:00 EDT
No go.

NM does read the ifcfg-eth? files, but fails to attach the right ifcfg file to
the right device.
Disabling NM and starting /etc/init.d/network by hand seems to solve the problem.

$ rpm -qa | grep NetworkManager
NetworkManager-vpnc-0.7.0-0.7.7.svn3502.fc9.x86_64
NetworkManager-0.7.0-0.9.1.svn3521.fc9.x86_64
NetworkManager-gnome-0.7.0-0.9.1.svn3521.fc9.x86_64
NetworkManager-glib-0.7.0-0.9.1.svn3521.fc9.x86_64
NetworkManager-openvpn-0.7.0-8.svn3302.fc9.x86_64

Combined ifcfg (generated by F9-Beta anaconda) and ifconfig output attached.

- Gilboa
Comment 54 Gilboa Davara 2008-04-02 02:35:05 EDT
Created attachment 300014 [details]
Combined ifcfg-eth? 

$ cat /etc/sysconfig/network-scripts/ifcfg-* > ifcfg-eth.log
Comment 55 Gilboa Davara 2008-04-02 02:35:40 EDT
Created attachment 300015 [details]
ifconfig output

$ ifconfig > ifconfig.log
Comment 56 Gilboa Davara 2008-04-02 02:36:31 EDT
Created attachment 300016 [details]
ifconfig output with NM disabled
Comment 57 Gilboa Davara 2008-04-02 02:38:29 EDT
Created attachment 300017 [details]
Combined ifcfg-eth? (Fixed)

$ cat /etc/sysconfig/network-scripts/ifcfg-eth? > ifcfg-eth.log
Comment 58 Manuel Salcido 2008-04-17 02:07:11 EDT
This seems like the best thread for my bug report - or my ignorance with this
interface.

Loaded F8 with latest updates.  Must use kernel 2.6.23.1-42.fc8.i686 since
higher level version crashes when I try different NetworkManager configs.

NetworkManager successfully recognizes RaLink RT2561/RT61 802.11g PCI card
NetworkManager successfully finds PCI card MAC Address
Try to set up DHCP settings, won't connect, or become "active".  I tried many
(if not all) different combinations, although I am certain I had the correct
ones (128 WEP, correct passphrase, DHCP on router config, etc.)

Must statically set IP address:
  *** This is where I don't know what I'm doing ***
  Used info. from router?
Address: 76.176.38.27
Subnet mask: 255.255.255.0
Default gateway address: 67.176.38.1

Those are my values at this moment.  Generate:
    "SIOCSIFFLAGS: cannot assign requested address"
 error.  This is where latest kernel version breaks.

But 2.6.23 kernel doesn't hang, it continues booting - I continue learning.  
  1) I open up Network Manager using GUI interface
      a) It asks for password for Token Ring Keys, I enter su password???
      b) it tries to connect, keeps failing.
  2) I open up terminal window, become superuser, type commands:
       >service NetworkManager stop
       >service NetworkManager start
  3)  NetworkManager almost immediately connects to my network

Why???

/etc/sysconfig/network-scripts/ifcfg-lan0 file contents:
DEVICE=wlan0:0
TYPE=Wireless
BOOTPROTO=none
USERCTL=no
PEERDNS=yes
IPV6INIT=no
IPV6_AUTOCONF=no
ESSID=spanky
CHANNEL=7
MODE=Master
RATE=Auto
ONPARENT=yes
NM_CONTROLLED=no
IPADDR=76.176.38.27
DOMAIN=
NETMASK=255.255.255.0
GATEWAY=67.176.38.1

I created two files with the same encryption keys, one called:
   keys-spanky
the other called:
   keys-wlan0

The reason for two files is that it connected after I set up a profile using
DHCP, but I wanted to make sure this was indeed the profile being used.  Network
Manager tried to activate all profiles (because I told it to), but it didn't
connect until I stopped and restarted it.
So.... NetworkManager works for me, YEAHHHHH!!!  But not quite as user-friendly
as I hoped.  Connection information (when I click on Icon)
    IP Address: 192.168.1.103
    Broadcast Address: 192.168.1.255
    Subnet Mask:  255.255.255.0
    Default Route: 192.168.1.1
    Primary DNS:  68.87.85.98
    Secondary DNS:  68.87.69.146
    Hardware Address:  00:1E:E5:95:61:9A

These values are different than what I put in ifcfg-wlan0, so DHCP works???
Am I using NM correctly?  I tried leaving wlan0 alone, because I could get it to
be "Active" with Static IP addresses, and creating a separate profile with DHCP
setting that I would also click on to Activate.  This didn't work....

I hope this helps other people who have given up on NetworkManager working with
their WMP54G Linksys cards ($39.99 at Walmart and Circuit City), from clean boot
this is the fastest solution, no additional installs necessary.

Thanks,

Manuel
Comment 59 Charles R. Anderson 2008-04-21 15:03:28 EDT
RE: Comment #58 Manuel, your GATEWAY must be in the same subnet as the IPADDR. 
Are you sure you didn't flip the first two digits?

76.176.38.27 vs. 67.176.38.1
Comment 60 Josh Cogliati 2008-04-29 19:01:20 EDT
(In reply to comment #48)
> I just did an install of the F9 beta and it ended up with a trashed network 
> connection due to NetworkManager.  I configured a static address during the 
> install.  ifcfg-eth0 had the correct static address,  but NetworkManager was 
> doing dhcp for eth0.  In addition /etc/resolv.conf was blank even though I 
> configured DNS servers in the install.

With F9 Preview, I configured a static address during the install. 
NetworkManager trashed the resolv.conf file.  The address was correct when I
used ifconfig to check it.  
Comment 61 Charles R. Anderson 2008-04-29 19:08:47 EDT
I just saw a fix go by in rawhide (which means not in F9 Preview) in
which Anaconda now writes DNS1, etc. to ifcfg-ethX.  That should
theoretically fix this issue.
Comment 62 Dan Williams 2008-04-30 19:20:33 EDT
If no nameservers are found, NM will write out a message in /etc/resolv.conf
explaining what you need to do as well.  That should help ease the confusion
when people find an empty resolv.conf.  We should probably open specific,
targetted bug reports for further issues that people experience with versions
_after_ svn3623.
Comment 63 Gilboa Davara 2008-05-04 03:25:11 EDT
Network Manager still doesn't honor S-C-N defined static configuration: (Unless
DNS' are defined manually using the method explained in #46)

1. Stop NetworkManager.
2. Stop network.
3. Call S-C-N, define two DNS servers.
4. Check /etc/resolv.conf, DNS servers defined.
4. Reboot.
5. Check /etc/resolv.conf, the following message appears:
# generated by NetworkManager, do not edit!

- Gilboa
Comment 64 Gilboa Davara 2008-05-04 03:30:29 EDT
P.S. All the network devices are defined as NM_CONTROLLED=no.

- Gilboa
Comment 65 Dan Williams 2008-05-04 11:39:38 EDT
Gilboa: what exact version of NetworkManager do you have installed?  Can get
that with 'rpm -qv NetworkManager'.  Please re-try with the latest F9
NetworkManager.  The behavior you report in comment 63 is expected (if you don't
have the DNS defined in the ifcfg file, you will get a blank resolv.conf).  The
behavior you specify in comment 64 seems like a bug so we should try to diagnose
that more.  For the behavior in comment 64, please:

1) service NetworkManager stop
2) killall -TERM nm-system-settings
3) /usr/sbin/nm-system-settings --debug --plugins=ifcfg-fedora

and report the output of (3) here.  Thanks!
Comment 66 David Juran 2008-05-05 10:50:07 EDT
Gilboa: In comment 64, do you mean that you defined all network devices as
NM_CONTROLLED=no or that they showed up that way although you checked the
"Controlled by NetworkManager" clickbox in s-c-n? 
Comment 67 Gilboa Davara 2008-05-05 17:10:03 EDT
Network configuration defined by S-C-N, back when I installed rawhide. (~F-9 Beta)
DNS's were defined using Anaconda - that save inside ifcfg-xxx.
Under S-C-N, all the devices are not marked as controller by NetworkManager,
even-though NM_CONTROLLED=no isn't explicitly set.

$ /usr/sbin/nm-system-settings --debug --plugins=ifcfg-fedora
** Message: Loaded plugins:
** Message:    ifcfg-fedora: (c) 2007 - 2008 Red Hat, Inc.  To report bugs
please use the NetworkManager mailing list.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
** Message:    ifcfg-fedora:     error: Ignoring loopback device config.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth2 ...
** Message:    ifcfg-fedora:     read connection 'System eth2'
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...
** Message:    ifcfg-fedora:     read connection 'System eth0'
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth1 ...
** Message:    ifcfg-fedora:     read connection 'System eth1'

$ cat /etc/sysconfig/network-scripts/ifcfg-eth?
# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:0c:29:10:34:4c
IPADDR=192.168.1.62
IPV6ADDR=2000::2062/16
IPV6INIT=yes
IPV6_AUTOCONF=no
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
GATEWAY=192.168.1.1
TYPE=Ethernet
# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
DEVICE=eth1
BOOTPROTO=none
BROADCAST=192.168.5.255
HWADDR=00:0c:29:10:34:56
IPADDR=192.168.5.62
IPV6ADDR=2000::5062/16
IPV6INIT=yes
IPV6_AUTOCONF=no
NETMASK=255.255.255.0
NETWORK=192.168.5.0
ONBOOT=yes
TYPE=Ethernet
# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
DEVICE=eth2
BOOTPROTO=none
BROADCAST=192.168.6.255
HWADDR=00:0c:29:10:34:6a
IPADDR=192.168.6.62
IPV6ADDR=2000::6062/16
IPV6INIT=yes
IPV6_AUTOCONF=no
NETMASK=255.255.255.0
NETWORK=192.168.6.0
ONBOOT=yes
TYPE=Ethernet
Comment 68 Gilboa Davara 2008-05-05 17:10:45 EDT
P.S. NM also ignores the default gateway configuration. (Found in ifcfg-eth0)

- Gilboa
Comment 69 Dan Williams 2008-05-06 09:30:52 EDT
Gilboa: NM will only ignore devices marked NM_CONTROLLED=no.  If there is no
NM_CONTROLLED=no line, then NM is free to use the device.

Can you paste in the output of '/sbin/route -n' and '/usr/bin/nm-tool' when the
connections are up?  I assume that whenever eth0 is up, you want the default
route to go through eth0 to the gateway defined in ifcfg-eth0, right?
Comment 70 Gilboa Davara 2008-05-06 13:06:37 EDT
(In reply to comment #69)
> Gilboa: NM will only ignore devices marked NM_CONTROLLED=no.  If there is no
> NM_CONTROLLED=no line, then NM is free to use the device.

Two problems: 
1. The configuration that was generated by S-C-N didn't have NM_CONTROLLED. I
assume that the same will be true for F7->F9 and F8->F9 upgrades.
2. As far as I can see, if a devices -doesn't- have NM_CONTROLLED=xxx, NM
considers it to be NM controlled, while S-C-N considers it to be
non-NM-controlled. Shouldn't the default, on both ends, be the same?

> Can you paste in the output of '/sbin/route -n' and '/usr/bin/nm-tool' when the
> connections are up?  I assume that whenever eth0 is up, you want the default
> route to go through eth0 to the gateway defined in ifcfg-eth0, right?

route seems OK now.
Ever since I added the DNS1 and DNS2 entries to my ifcfg-eth0, everything seems
automagically OK.

If problem 1 and 2 are already fixed, feel free to close this bug. (I'll reopen
if I can reproduce it)

- Gilboa
Comment 71 Chris Ricker 2008-05-07 15:11:38 EDT
I did a clean install of rawhide last night

NetworkManager-0.7.0-0.9.3.svn3623.fc9.x86_64

configured static IP on eth0 during an ftp install

after bootup:

- default gateway wasn't set
- dns wasn't set

so it looks like there's definitely still screwiness with static IPs
Comment 72 BROCKLEHURST ERIC 2008-05-07 18:18:04 EDT
Version FC8 last kernel
NetworkManager don't worked well with a wireless Card. (ipw2200). It works well
with a dhclient. But if you wanted to fixed a static ip and your nameserver, it
works with the ip dhcp. You can note that the information of if-cfgeth1 
IPADDR=IP du DNS while ?
and 
PEERDNS=yes 
You can change the info but etc/resolv.conf is generated by networkmanager and
nameserver is the adress of the gatewayNetworkManager don't worked well with a
wireless Card. (ipw2200). It works well with a dhclient. But if you wanted to
fixed a static ip and your nameserver, it works with the ip dhcp. You can note
that the information of if-cfgeth1 
IPADDR=IP du DNS while ?
and 
PEERDNS=yes 
You can change the info but etc/resolv.conf is generated by networkmanager and
nameserver is the adress of the gateway
I thinck the problème is in the declaration of the object retrieve by the
system-config-network. The number of element are not generated
Comment 73 Dan Williams 2008-05-08 14:27:17 EDT
Chris:  can I get your ifcfg files and also /var/log/messages right after boot
when things aren't configured correctly?
Comment 74 BROCKLEHURST ERIC 2008-05-08 17:11:43 EDT
Created attachment 304901 [details]
Files for your request
Comment 75 BROCKLEHURST ERIC 2008-05-08 17:32:57 EDT
I have find the solution, The problem is during the procedure ifup. 
If you have in the files devices  the value BOOTPROTO is not egal none, the script make the procedure 
dhcp. Unfortunately, the command system-config-network have not effect. you must put it manually.
The second problem must realised by the firewall  It blocked the communication for FC8 No problems 
with FC4 FC5 FC6 . The resolution fails,If you deactived by lokkit, the resolution works wells .DNS are on 
FC4. If you down the master, the resolution fails. No problems for FC4 FC6 or windows or Apple
FC8 don t worked with the second DNS (slave)
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Comment 76 Chris Ricker 2008-05-10 23:16:06 EDT
Created attachment 305050 [details]
Chris /var/adm/messages - first boot after install
Comment 77 Chris Ricker 2008-05-10 23:17:14 EDT
Created attachment 305051 [details]
Chris /etc/sysconfig/network-scripts/ifcfg-eth0
Comment 78 Chris Ricker 2008-05-10 23:21:13 EDT
I did a clean install with F9 gold on the same machine (x86_64 laptop, two
interfaces, eth0 - wired, eth1 - wireless; only configured and used eth0 for
install)

This time, after reboot I had DNS set, but no default gateway. ifcfg-eth0 was set to

NM_CONTROLLED=



To get things going, I changed that to

NM_CONTROLLED=yes

added

GATEWAY=24.214.125.33

and restarted NetworkManager

(attached files are from before the edits)
Comment 79 Linus Torvalds 2008-05-13 14:04:19 EDT
Can we please just KILL NetworkManager?

It still doesn't work, and Fedora 9 is apparently out now, so my test as of
yesterday should be pretty damn up-to-date.

The problem is still exactly the same: if you set the network information by
going to the System -> Administration -> Network tool, running NetworkManager
will still just happily screw up everything, even if you mark the device as not
being managed by NetworkManager.

In fact, even if the network then works (temporarily) because you force it on in
that Network admin tool, starting Firefox will complain about things being in
offline mode, because NetworkManager will not realize that there is a perfectly
fine network that it doesn't control!

So the only way to have a useful box is apparently to go to System ->
Administration -> Services and just turn off NetworkManager. Is that really
supposed to be user-friendly? 

This is a normal desktop machine that simply SHOULD NOT use dhcp. Why is stuff
like this being shipped at all? Why is NetworkManager enabled in the first
place, when it's known to be broken? 
Comment 80 Jakub 'Livio' Rusinek 2008-05-13 14:15:08 EDT
Linus complaining about being user-friendly or not :o .
Or you're not Linus?

It's kinda strange for me, if man which in my imagination is geek sitting 24/7 @
computer and coding kernel, talks about friendliness :) .
Comment 81 Linus Torvalds 2008-05-13 14:33:53 EDT
Hey, I'll happily manually edit textual config files for things like this,
because I know what a netmask is etc. So it doesn't have to be "user-friendly"
in that nice UI sense.

But when there are network configuration tools that are there in the main menus
that DON'T ACTUALLY WORK - that's unfriendly at a whole different level! 

Either the tools should work, or they shouldn't be exposed to users. Not this
"make a friendly GUI tool, and then make it not work". THAT is unacceptable. I
refuse to edit automatically generated files, and I really don't think anybody
should be expected to - whether technically able or not.

As a tech geek, I care about things working. Right now they simply don't work,
and it looks like the NetworkManager people haven't even tested some trivial
things. This whole bugzilla entry seems to have "fixes" that involve editing
those files that you should never have to edit in the first place, because they
are generated by all the GUI tools. 

So fix the tools already, don't ask people to edit files that the tools are
supposed to edit. Or remove the tools, since they don't work. Either or. Not
both. Not neither.

I don't know what is so special about my machines that it would trigger this
problem. I suspect nothing at all. googling for NetworkManager certainly seems
to find a lot of complaints about it. Why was it enabled when it is so trivially
and fundamentally buggy? Or what is the magic thing I do wrong?

And no, don't tell me to edit those files that the tools already generated for
me. At that point, "turn off networkmanager" is the right solution.
Comment 82 markm 2008-05-13 14:46:18 EDT
(In reply to comment #81)
> I don't know what is so special about my machines that it would trigger this
> problem. I suspect nothing at all. googling for NetworkManager certainly seems
> to find a lot of complaints about it. Why was it enabled when it is so trivially
> and fundamentally buggy? Or what is the magic thing I do wrong?

same here, new tool looks promising, but it didn't work for me either. I've
tried to create my custom static ip settings for my wifi connection, after I did
it, network manager has disconnected, created a new entry (under the same name)
and was not able to connect to the network again. 
Comment 83 Dan Williams 2008-05-13 14:48:38 EDT
Linus:

the bug about not respecting system-config-network configuration is a
peculiarity of s-c-n using hardlinks to update the config files.  When hardlinks
are in use, you must inotify-watch the files themselves (watch the inode of
course) not the containing directory, since modification events to hardlinks
won't trigger events from the containing directory obviously.  There was a bug
in the current bits of NetworkManager (and in GNOME's gio inotify backend) that
causes modifications of hardlinks to go unnoticed, something I've filed upstream
at gnome.org (#32815) and something I've just worked around in NetworkManager.

We used to monitor the locations that s-c-n changes directly, but switched the
monitoring to /etc/sysconfig/network-scripts since that's _THE_ canonical place
for network configuration.

In short, the behavior you're experiencing is a bug that should be fixed shortly
in a NetworkManager update.  This will make the coordination issues between
s-c-n and NM magically disappear since nm-system-settings will now get change
notifications when s-c-n configurations are saved.
Comment 84 Jesse Keating 2008-05-13 14:49:33 EDT
It's entire possible for these files to get into an inconsistent state with
especially due to time spent using rawhide.  What would probably be best is to
step back from yelling on bugzilla and perhaps have a conversation via email or
IRC with the NM developer to examine what exactly is the state of things and how
they're going wrong for you.  I suspect that cleansing the files and re-creating
them from scratch with current tools may resolve the issues, or examination may
actually show some other lurking bug.  This particular bug entry has long since
lost any hope of being useful for any specific issue.

Fact of the matter is that NetworkManager works very well for a very signficant
portion of our user base.  So much so that it's doing a disservice to them to
leave it disabled/hidden away from them.  For the few cases where NetworkManager
just doesn't work quite right there is still the 'network' service that can be
fallen back upon if so desired.
Comment 85 markm 2008-05-13 14:59:38 EDT
(In reply to comment #84)
> Fact of the matter is that NetworkManager works very well for a very signficant
> portion of our user base.  So much so that it's doing a disservice to them to
> leave it disabled/hidden away from them.  For the few cases where NetworkManager
> just doesn't work quite right there is still the 'network' service that can be
> fallen back upon if so desired.

I disagree. I have just installed fresh Fedora 9 installation - everything set
by default and NM does not work properly. What I want is simple - facility to
set a static IP for a wireless connection and custom dns. Currently I cannot do
that with NM and I have to use different tools (such as wicd). I can live
without static IP, but I need a custom dns - the only solution for now is to use
different tool (such as wicd) or create a cron entry to overwrite resolv.conf
every couple of minutes. (another issue is that iwl3945/iwl4965 don't work as
desired and they both get disconnected every couple of minutes).

In my opinion, NM has a great potential, but it needs a better management and
many urgent fixed to be done ASAP. we do really want to have hassle free
internet configuration on our machines.
Comment 86 Linus Torvalds 2008-05-13 15:06:19 EDT
(In reply to comment #83)
> 
> the bug about not respecting system-config-network configuration is a
> peculiarity of s-c-n using hardlinks to update the config files.

Hmm. I'm pretty sure I actually rebooted the machine because of this, and it
still didn't take my s-c-n changes.

Of course, it was a controlled reboot, so if NetworkManager keeps re-writing the
files (without noticing that they got overwritten by somebody else too), that
would still explain how it didn't work.

And I would also like to point out that I do have two network devices on both of
those machines: a wired device (that is in use), and a wireless device (that is
not), and I don't think I've ever set up the wireless one (neither with
system-config-network *nor* with NM). Maybe NetworkManager looks at the wireless
one and says "there is no network configured", and decides that there is no
network at all, even though the wired one is perfectly fine and is not managed
by NM at all.

The fact that it works for some people must mean that some configurations work.
I do not know what it is that makes it fail for me. But I'm clearly not alone.

(In reply to comment #84)
>
> I suspect that cleansing the files and re-creating them from scratch with
> current tools may resolve the issues

I literally did this test yesterday with an up-to-date Fedora 9 as of that time
(so I assume it was basically the final F9). One of the machines had been
working fine for a month or more (because it was using DHCP as it was being
prepared for taking over the job of an old machine), but got moved to its final
location with the "real" IP address yesterday. And that's when it got its static
address, using system-config-network.

And that's when that machine started having issues. So all the tools that wrote
the files should have been perfectly up-to-date.
Comment 87 Dan Williams 2008-05-13 15:07:41 EDT
Marek: your configuration should work as long as you need open or WEP (since
s-c-n doesn't support WPA yet).  Static IP certainly works, and for DNS you want
to put your DNS servers into the ifcfg file like so:

DNS1=xxx.xxx.xxx.xxx
DNS2=xxx.xxx.xxx.xxx
SEARCH=foo.com lab.foo.com

Comment 88 Dan Williams 2008-05-13 15:11:26 EDT
Linus: obviously, if you've set NM_CONTROLLED=no on an interface, NM doesn't
know anything about that interface and doesn't know it's state, because you've
told NM to ignore it.

NM itself also does not write out or change any ifcfg files, they are read-only
at the moment.  NM does re-write /etc/resolv.conf but that's it.  We don't touch
/etc/hosts yet (but will have to soon to handle hostname changes).

Any chance you could attach your ifcfg files from /etc/sysconfig/network-scripts?

Also, when you switched to static IP from dynamic, did you use
system-config-network to update the configuration?  And you said you then rebooted?

Can you also run "/usr/sbin/nm-system-settings --debug --plugins=ifcfg-fedora"
and report what output it gives?
Comment 89 Jesse Keating 2008-05-13 15:13:26 EDT
(In reply to comment #85)
> (In reply to comment #84)
> > Fact of the matter is that NetworkManager works very well for a very signficant
> > portion of our user base.  So much so that it's doing a disservice to them to
> > leave it disabled/hidden away from them.  For the few cases where NetworkManager
> > just doesn't work quite right there is still the 'network' service that can be
> > fallen back upon if so desired.
> 
> I disagree. I have just installed fresh Fedora 9 installation - everything set
> by default and NM does not work properly. What I want is simple - facility to
> set a static IP for a wireless connection and custom dns. Currently I cannot do
> that with NM and I have to use different tools (such as wicd). I can live
> without static IP, but I need a custom dns - the only solution for now is to use
> different tool (such as wicd) or create a cron entry to overwrite resolv.conf
> every couple of minutes. (another issue is that iwl3945/iwl4965 don't work as
> desired and they both get disconnected every couple of minutes).

Thank you for proving my point slightly.  Wireless with static IPs is not
necessarily the majority user here.  It /is/ a special configuration and there
/may/ be some issues here, particularly with what Dan has stated above.

> 
> In my opinion, NM has a great potential, but it needs a better management and
> many urgent fixed to be done ASAP. we do really want to have hassle free
> internet configuration on our machines.

Piling on to a generic bug like this is not going to help your cause.  Do you
have a specific bug filed for this specific issue, with the specific
configurations that the tools created?
Comment 90 Linus Torvalds 2008-05-13 15:21:08 EDT
Created attachment 305287 [details]
ifcfg-eth0 file as generated by system-config-network

This is what the ifcfg-eth0 file looks at now on that machine.

There's also one for lo, but it's trivial and presumably not interesting.
There's none for wlan0.

What happened with this config was that even when networking was working, the
nm-applet thing would have a red box with a cross in it, and Firefox would say
that it was in offline mode. "ping www.google.com" would work, but the browser
would not, because apparently there's some hack to make firefox ask NM about
whether the network is up or not.

Oh, and this config file is obviously from a working machine, so it is from
*after* I just disabled NM in disgust after having been unable to make it work.
So for all I know, maybe it looked different when NM was running.
Comment 91 markm 2008-05-13 15:21:45 EDT
(In reply to comment #87)
> Marek: your configuration should work as long as you need open or WEP (since
> s-c-n doesn't support WPA yet).  Static IP certainly works, and for DNS you want
> to put your DNS servers into the ifcfg file like so:
> 
> DNS1=xxx.xxx.xxx.xxx
> DNS2=xxx.xxx.xxx.xxx
> SEARCH=foo.com lab.foo.com

at work we use WPA2, at home I am using WPA Personal... so it does not help :(
but wicd works well without any issues, so I am not worried to much about this
bugs in NM - I give it a try every Fedora's release... I wish I could use NM,
but... since I have better (and working solution), I am just patiently waiting
for NM to be fixed.

Comment 92 Linus Torvalds 2008-05-13 15:27:40 EDT
Btw, about that ifcfg-eth0: it looks like the line

DHCP_HOSTNAME=macmini.linux-foundation.org

is just stale information from when it was still using DHCP. The real hostname
is now in /etc/sysconfig/network.

Another note: my /etc/resolv.conf still says "generated by NetworkManager, do
not edit!", even though I tried to set that up with s-c-n too. But that's ok,
because DHCP will get that part right on my network. It may be that s-c-n
doesn't change any lines it doesn't know about, or doesn't change that file when
it already contained the right information?
Comment 93 Dan Williams 2008-05-13 15:59:22 EDT
Right; it's still generated by NM because at least one of your devices is
managed by NM, and since you've hidden the other device from NM it just ignores
that device.

There doesn't seem to be anything out of the ordinary with that profile, I
expect it to work (without the NM_CONTROLLED=no of course).
Comment 94 Joshua Rosen 2008-05-13 16:10:03 EDT
I've just done a clean install of F9 using the new F9 Live CD. NetworkManager is
flat out broken, I setup the Ethernet card with a static IP during the install
but it came up with DHCP. 

This bug was opened nearly 4 years ago, the oldest post on this thread is
10/6/2004. How is it possible that a bug as serious as this in an area as
important as networking hasn't been fixed in all of that time? And given that it
doesn't work at all why is it enabled by default?

Comment 95 Linus Torvalds 2008-05-13 16:16:54 EDT
(In reply to comment #93)
> Right; it's still generated by NM because at least one of your devices is
> managed by NM, and since you've hidden the other device from NM it just ignores
> that device.

No, there really isn't *any* device managed by NM. None. That ethernet device is
the only device (apart from lo) that is set up. NM has nothing. 

This seems to be the fundamental confusion here. Why do you think NM manages
anything? Why does NM think it manages anything? It doesn't, and it should't,
and there seems to be no way to even tell it so.

Please, you claim that NM does the right thing, but it really REALLY does not do
that at all. It thinks it should manage devices even when there are no devices
for it to manage!
Comment 96 Dan Williams 2008-05-13 16:23:16 EDT
Linus: I thought you had said that there was a wireless device in the machine
that you don't use and never connect to anything:

"I do have two network devices on both of those machines: a wired device (that
is in use), and a wireless device (that is not), and I don't think I've ever set
up the wireless one"

NM manages the wireless device unless you have told it to ignore the wireless
device (by creating an ifcfg file for the device with NM_CONTROLLED=no).  But
it's not _connecting_ the wireless device to anything until you explicitly tell
it to do so via the menus.

NM will manage any device unless you have told it not to do so.  In the absence
of any configuration, NM defaults to bringing up wired connections that have a
cable plugged in using DHCP.  NM will not connect any wireless device until you
have told it to do so.
Comment 97 Linus Torvalds 2008-05-13 16:38:03 EDT
(In reply to comment #96)
> Linus: I thought you had said that there was a wireless device in the machine
> that you don't use and never connect to anything:

Right. And it DOES NOT EVEN WORK. It's an apple mac-mini, with that undocumented
atheros ath5k chipset - a version of the chip that we don't support yet. So it
gets detected.

But my point is that I have never ever allowed networkmanager to manage it, and
there wasn't even a way to do so. Why does networkmanager think that it has the
right to screw up the *working* connection just because there is a non-working
chip in that machine that it hasn't even been told to use?

I can literally tell NM to disable all networking it knows about (uncheck the
"enable networking" check-mark), and I can look at the devices NM knows about
and see that that list is EMPTY, and it STILL just says that there is no network
at all, so Firefox won't work!

Can you seriously continue to argue that that is not a bug? The ONLY way to fix
it that I have found is to turn off NM entirely, at which point everything works
fine.

Can you please understand what the problem is? NM screws up networking, even
though IT HAS NOT A SINGLE DEVICE THAT IT MANAGES!
Comment 98 Dan Williams 2008-05-13 17:35:44 EDT
Linus: the ath5k is driven by the ath5k driver; irregardless of whether the
_driver_ works or not, it's seen as a network device and therefore is managed.

I repeat: NM managed devices unless you have told it not to do so via
system-config-network.

I also repeat: NM cannot know anything about connections you have not told NM to
manage.  Therefore, if you unmanage a device by setting NM_CONTROLLED=no, NM
will ignore the device, specifically because you have told it to do so.  It's
not managed by NM, therefore NM cannot know the device's state and cannot know
if the device is connected or not.
Comment 99 Dan Williams 2008-05-13 17:39:07 EDT
So I burned an F9 Final LiveCD.

I installed from the desktop install icon.

I checked "eth0" and edited the eth0 configuration in the installed to be static
IP (192.168.1.100/24) with a gateway of 192.168.1.1, and DNS servers of 4.2.2.1
and 4.2.2.2.

I then installed and rebooted.

I plugged in a network cable and NetworkManager brought up the connection
correctly with a static IP address.

It *does* work as advertised.

/etc/sysconfig/network-scripts/ifcfg-eth0 looks like this:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.1.255
HWADDR=xx:xx:xx:xx:xx:xx
IPADDR=192.168.1.100
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
DNS1=4.2.2.1
DNS2=4.2.2.2

Repeat, I never edited ifcfg-eth0 manually.  I only used anaconda to do so at
installation time.
Comment 100 Dan Williams 2008-05-13 17:44:19 EDT
I then ran system-config-network.

I edited the "eth0" configuration.

I checked the "Controlled by NetworkManager" box.

I changed the static IP address to 10.1.1.100.

I changed the gateway to 10.1.1.1.

I saved the configuration.

I rebooted.

On reboot, NetworkManager correctly set up the eth0 device with 10.1.1.100 with
a route to 10.1.1.1.

Again, works *as advertised* so far.  We need to figure out what's different
with the cases where it does not work.  But it's certainly NOT broken.
Comment 101 Dan Williams 2008-05-13 17:48:31 EDT
I then ran system-config-network and switched the connection to use DHCP,
connected to the normal network, and rebooted.

It again worked as advertised, and got a DHCP address before login.
Comment 102 Linus Torvalds 2008-05-13 17:59:17 EDT
(In reply to comment #98)
> 
> I also repeat: NM cannot know anything about connections you have not told NM to
> manage.  Therefore, if you unmanage a device by setting NM_CONTROLLED=no, NM
> will ignore the device, specifically because you have told it to do so.  It's
> not managed by NM, therefore NM cannot know the device's state and cannot know
> if the device is connected or not.

I repeat: if NM doesn't list a single device it manages, and knows there are
devices that it does NOT manage, why the h*ll does it claim that the network is
down?

It should just say that it doesn't know, and it should get out of the way.

If there is ANY network device that NM doesn't manage, NM should damn well not
tell firefox that there is no network!

Is it really so hard to understand? Why does NM care about a device that NOBODY
ELSE EVER CARED ABOUT, AND THE USER DIDN'T CONFIGURE AT ALL, AND THAT DOESN'T
SHOW UP ANYWHERE (including nm-applet itself!).

I repeat: right now, the only good solution is to just shut off NetworkManager
entirely. Because right now any random unconfigured device will cause NM to
simply DO THE WRONG THING.

Can you really not admit that it's the wrong thing to stop firefox from working
just because there is some unconfigured device that DOESN'T EVEN SHOW UP in
network manager?

In other words, your logic totally and utterly depends on NM always controlling
all devices.

This is doubly stupid, because I just tried system-config-network on that thing,
and there is no way to even disable that NM thing without first setting up a
dummy new network connection - and when you do that, then NM is disabled by
default anyway!

In other words, NM attaching to some random unconfigured device when there
already is a configured device out there is just insane! Claiming that there is
no networking is CRAZY. It's wrong. It's a bug. Trying to get NM to stop doing
that is apparently possible only by generating a configuration that is stupid,
ie explicitly configuring the device, and then telling the system to never use it!

Why can't NM just do the sane thing? The sane thing is quite obvious:

 - if there is a device that is configured (NM must have parsed those config
files know about that, if only to notice that it has NM_CONTROLLED=no), then
don't claim that there is no networking. Don't turn off DNS.

In other words, don't screw up the already-set-up networking, especially when NM
itself hasn't even been able to get an address for the device it *does* know about!

Do you really think that NM does the right thing as is?

Really?

And if so, who do I need to screw to get somebody else to at least give me a
install-time option to not use NM at all, because the PoS isn't even going to
get fixed?
Comment 103 Dan Williams 2008-05-13 18:19:28 EDT
Linus: I'm apparently confused about the wireless on your device.  What's the
output of:

/usr/bin/nm-tool

while NM is running?  Be sure to mask out your MAC addresses and any AP
addresses it may report.  I assumed that if you had a wifi card in your machine,
that NM would pick it up.  But since you say that it doesn't show up in the
menu, there must be something wrong with it.

And again, if you make NM ignore a device, then by definition, NM does not know
what the devices state is, if the device is connected, etc.  You have manually
removed the device from the control of NM, and therefore applications that check
with NM for the state of your network will not know what you have done with that
device either.

If for some reason NM isn't working for the device which is your primary
connection (and I still don't quite see why your configuration should NOT work
with NetworkManager), then your best bet is to turn NM off and rely on the
'network' serivce instead.  When NM is not running, applications will fall back
on scraping the output of /sbin/ip or /sbin/route or just assume connectivity.

So can I get the output of /usr/bin/nm-tool and /sbin/lspci for the machine you
care about here?

What's the output of 'rpm -qv NetworkManager' as well?

Also, /var/log/messages would be useful here to try and figure out why NM isn't
working for you, but only if you wouldn't mind doing:

chkconfig NetworkManager on
chkconfig network off
chkconfig messagebus resetpriorities
chkconfig haldaemon resetpriorities
chkconfig NetworkManager resetpriorities
<reboot>

Thanks!
Comment 104 Jesse Keating 2008-05-13 18:22:25 EDT
Linus, with your recently recreated static config files, have you tried giving
NetworkManager the authority to bring it up for you?  It'll do it during boot
and have it up before you log in.  Is there something preventing you from
allowing NetworkManager to control your static device?  Sure there might still
be a bug or at least a paradigm problem with NM not set to manage devices, but
this would at least not expose that for you.
Comment 105 Linus Torvalds 2008-05-13 18:42:44 EDT
Created attachment 305302 [details]
nm-tool output

This is the output from 'nm-tool'.

When this was done:
 - NM was running (obviously - otherwise nm-tool doesn't work)
 - Firefox didn't work ("offline mode")
 - nm-applet showed the "no network connection" thing

Notice how there *is* a perfectly fine network connection, and Firefox should
have connected perfectly well. Just not over any device NM managed!
Comment 106 Linus Torvalds 2008-05-13 18:46:26 EDT
(In reply to comment #104)
> Linus, with your recently recreated static config files, have you tried giving
> NetworkManager the authority to bring it up for you? 

I don't *care* who brings it up for me.

I just want it to work when I configure it in System -> Administration ->
Network. I don't care one whit whether it's then the startup scripts, NM, the
boogie man, or the flying spaghetti monster that brings up the device, but it
needs to be up and on the static IP I provided.

And right now, the only way to sanely do that seems to be to kill NM.
Comment 107 Dan Williams 2008-05-13 19:07:43 EDT
Again; I'd really like to try and figure out why this connection isn't working
for you with NM so that we can make stuff work better for everyone.  Any chance
you could re-enable NM and get the logs I requested in comment #103 from the
bits about /var/log/messages after doing the chkconfig stuff?  Thanks!
Comment 108 Linus Torvalds 2008-05-13 21:03:45 EDT
Created attachment 305313 [details]
/var/log/messages network-related stuff

Here's the NetworkManager-related stuff from /var/log/messages.

The box does not actually work with NM running, so I then disabled NM again in
order to make it be in a useful state. Which is why the nm_signal_handler etc
stuf shows up.
Comment 109 Jesse Keating 2008-05-13 21:34:01 EDT
So far I've only seen complaints of when NetworkManager is turned on, but you
have NetworkManager controlled set to off for the particular device.  Can you
humour us and remove that option, disable the 'network' service, and allow the
NetworkManager service to bring up your device?  Maybe you've tried this
recently and I'm just being obtuse, but I'm truly interested in what the failure
case would be here, as this is the scenario we're expecting for most of our
users (NetworkManage bringing up the device at boot time). 
Comment 110 Linus Torvalds 2008-05-13 21:48:23 EDT
(In reply to comment #109)
> So far I've only seen complaints of when NetworkManager is turned on, but you
> have NetworkManager controlled set to off for the particular device.  Can you
> humour us and remove that option, disable the 'network' service, and allow the
> NetworkManager service to bring up your device? 

Can you humor me and JUST FIX THE DAMN BUG ALREADY?

NetworkManager being off is the *default* for when you configure the device. It
should work. Why are you arguing about totally irrelevant issues? If
NetworkManager doesn't work when it's been told to keep its hands off, then
there is a NetworkManager bug.

It's really that simple. I want things to just work. When I configure my
ethernet device for a static IP address, I expect things to just work. I don't
want to have to check that "let NetworkManager manage this device", because (a)
it's not the default and (b) traditionally it didn't even work. 

I also don't want to have to "configure" some device that has nothing to do with
anything (the wireless one).

And the thing is, if I have to jump through hoops to make it work, I already
HAVE that hoop jumped through: it's easier to just disable NM than it is to play
along with these silly games.

Why is that so hard to accept? 
Comment 111 Bug Zapper 2008-05-13 21:57:35 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 112 Jesse Keating 2008-05-13 21:59:48 EDT
It's not the default from a clean install.  If you do a clean install and
configure the device during installation, NetworkManager will indeed control the
device and bring it up per your configuration at boot time.  As for
system-config-network not defaulting to NM controlling the device that's a
different matter, and one that does need to be addressed.  The 3 graphical ways
to configure devices is a little ridiculous but that's where we're at right now.

I'm not stating that there isn't a bug somewhere in having non-networkmanager
managed connections /and/ network manager running but no devices to manage,
/and/ apps like firefox which have been configured (due to upstream requests) to
honour NetworkManager when it's running.

We're not asking anybody to jump through hoops upon install.  And I think it's
somewhat fair to say you've drifted a bit from a clean install, and that's fine.
 I don't think anybody is 'not accepting' what you're claiming, at least I'm
not.  I'm asking you to humour me with trying something that should match what
default installs will look like, where network was configured in anaconda and
left for NetworkManager to manage.
Comment 113 Dan Williams 2008-05-13 22:07:01 EDT
Linus; I need to be able to see where NM is falling over for you when
NM_CONTROLLED=yes in your ifcfg-eth0 file.  That means changing NM_CONTROLLED to
yes, re-enabling NM, disabling network, and rebooting, and then attaching
network-related stuff from /var/log/messages to the bug report again.  I have no
idea what might be going wrong with NM unless I have that log information.

There is an issue right now where, if the file contains _no_ NM_CONTROLLED tag
(anaconda doesn't write one at install time), system-config-network assumes that
it's not NM controlled, but NM assumes that it is NM controlled.  Thus, when
s-c-n starts up, it'll write out NM_CONTROLLED=no to the file, "helpfully"
un-managing your device when you save the configuration in s-c-n.  That's caught
a few people so far.
Comment 114 Linus Torvalds 2008-05-13 22:29:27 EDT
Created attachment 305323 [details]
/var/log/messages with eth0 NM-enabled

This is the equivalent of the previous messages, but now with 'eth0' marked as
managed by NM.

Again, to actually get networking, I had to then disable NM and do eth0 by
hand.

And again, none of that should even matter. NM shouldn't force itself on my
poor defenseless system if I tell it to butt out. It doesn't even matter if the
"Managed by NetworkManager" check-mark is selected by default or not: if it's
there, I still expect things to work even if I have to unselect it manually.

And my system is perfectly standard. The only thing that is non-standard is
that I use my own kernel, and no modules. The network device works fine with
the built-in modules, thank you very much.
Comment 115 Dan Williams 2008-05-14 10:04:11 EDT
Linus: thanks! With the logs you've provided, I've been able to isolate and
reproduce your problem.  Fixes are in NM svn r3668 and r3669.  I'll build
updated packages for F8, F9, and rawhide presently.  Once they are built, I'd
appreciate it if you could test them out for me.  I'll post the link to the
packages in koji when they are done.
Comment 116 Dan Williams 2008-05-14 11:01:15 EDT
Linus:

If you could grab the RPMs for your arch from here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=608593

Use "rpm -Fvh *.rpm" to update only the ones you currently have installed, and then:

<set your ifcfg-eth0 to NM_CONTROLLED=yes>
chkconfig network off
chkconfig NetworkManager on
reboot

and let me know how it goes?  If something doesn't work, /var/log/messages would
be greatly appreciated.  Thanks.
Comment 117 Linus Torvalds 2008-05-14 12:41:01 EDT
(In reply to comment #116)
>
> If you could grab the RPMs for your arch from here:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=608593

Ok, some progress.

With this, the actual network device seems to work *if* I tell NM to manage it.
However, it still seems rather confused, and making things totally unusable is
the fact that i screws up my DNS entry and rewrites /etc/resolv.conf with 

# generated by NetworkManager, do not edit!



# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# SEARCH=lab.foo.com bar.foo.com

which is kind of pointless - the network obviously doesn't work after that.

And no, I'm not going to edit my network-scripts files. I'm going to expect NM
to work together with system-config-network, where I had set those DNS entries
in the first place. Overwriting the /etc/resolv.conf file with some random
instructions that is known to cause DNS to not work is kind of pointless, isn't it?

The fact is, NM has no business overwriting resolv.conf, since it doesn't know
what the hell the DNS information is. 

Have you tried these simple setups (and yeah, maybe to trigger this you still
need that other device that isn't configured at all - I don't know why you claim
it works for some, when it obviously still doesn't work for me):

 - turn a device from NM-managed to non-NM managed, and expect the networking to
still work.

 - start the device in DHCP mode (because it got installed at a temporary
address), but then make the device be a static IP (because that's the final
one), at which point the DNS information comes not from the *device* management,
but from s-c-n DNS configuration and /etc/resolv.conf.

It looks like s-c-n will never overwrite the "generated by NetworkManager" thing
in /etc/resolv.conf, so even if you set the DNS statically, NM then probably
continues to think that it can just overwrite that static DNS information with a
non-working config. Not acceptable.

Anyway: improvement, but not enough to actually make NM useful on this machine
in this setup.
Comment 118 Linus Torvalds 2008-05-14 12:53:23 EDT
Created attachment 305381 [details]
Yet another /var/log/messages file

Ok, so this one is messier, partly because I tried to fix up the
/etc/resolv.conf thing with NM still owning the device. But even the bootup
thing looks a bit strange: it has that warning about "auto_activate_device():
Connection 'System eth0' auto-activation failed:(2) Device not managed by
NetworkManager', even though the regular 'eth0' _is_ managed by NM. So do we
now have a 'System eth0' that is different from the 'eth0' that NM is clearly
managing?

I dunno. Anyway, it's different, and maybe you want it. As explained in the
previous entry, it's not actually *working* yet, because various things don't
play well together (static DNS, nor marking eth0 as being non-NM-managed).
Comment 119 Joachim Frieben 2008-05-14 13:07:35 EDT
I found it useful to remove $HOME/.gconf/system/networking/ left over from
previous versions of NM before logging in to GNOME in order to get rid of
obsolete connection settings which might confuse current NM.
Comment 120 Dan Williams 2008-05-14 13:15:15 EDT
The installer sets up those key/value pairs for you if you install a fresh copy,
but yes, we do need to make s-c-n add that to the ifcfg files for wifi and
ethernet.  If you do follow those instructions, and you do add your DNS servers
to ifcfg-eth0, everything should work correctly.  Fresh installations of F9 will
work here because Anaconda sets up the ifcfg files correctly.  The issue is that
resolv.conf is really a composite of DNS information from multiple places; for
example if you start a VPN, you need to use the VPN's DNS servers to resolve
addresses over the VPN.  But you clearly don't want to use the VPN's DNS servers
_all_ the time, because you're not always connected to the VPN, and you clearly
need to use the VPN DNS when you are on the VPN, otherwise you can't resolv
addresses on the other side of the VPN.  So a single, static /etc/resolv.conf
just doesn't work.  But system-config-network currently assumes a static
resolv.conf and will only write DNS information there, which then just gets
written over the next time you need a VPN connection, and your info is lost.

I realize that your specific use-case doesn't require a VPN with this machine,
but we need to solve the problem generally, not on a per-case basis.

The "device not managed by NM" message is because sky2 bounced the link on you
even though there was always a cable plugged in.  Some network drivers (sky2 and
tg3 are worst) bounce IFF_RUNNING around quite a bit before settling down on
just exactly what they think their worldview is...  might be due to N-Way
autonegotiation delays or whatever.  It would be nice if they'd just not
announce IFF_RUNNING until they had a consistent link state.  But whatever.

May 14 09:14:59 tove NetworkManager: <info>  (eth0): carrier now OFF (device
state 3)
May 14 09:14:59 tove NetworkManager: <info>  (eth0): device state change: 3 -> 2
May 14 09:14:59 tove NetworkManager: <info>  (eth0): deactivating device.
May 14 09:14:59 tove NetworkManager: <WARN>  auto_activate_device(): Connection
'System eth0' auto-activation failed: (2) Device not managed by NetworkManager

But NM notices the carrier coming back a second later and does bring the device
up correctly.

So again, if you add the DNS entries to your ifcfg-eth0 file (as Anaconda would
have done on a fresh install, which I verified yesterday), it'll work for you. 
And we'll work to make s-c-n write things to the right place.
Comment 121 Dan Williams 2008-05-14 13:16:47 EDT
joachim: those GConf settings should have no impact here; they are the 0.6
stored wireless network format and are converted once when the applet starts up
and doesn't have anything in /system/networking/connections.  I don't think they
are an issue for Linus, and they are only wireless anyway.
Comment 122 Chris Ricker 2008-05-14 13:43:46 EDT
(In reply to comment #99)
> So I burned an F9 Final LiveCD.

> Repeat, I never edited ifcfg-eth0 manually.  I only used anaconda to do so at
> installation time.

(In reply to comment #100)
> 
> On reboot, NetworkManager correctly set up the eth0 device with 10.1.1.100 with
> a route to 10.1.1.1.
> 
> Again, works *as advertised* so far.  We need to figure out what's different
> with the cases where it does not work.  But it's certainly NOT broken.


Dan, my installs of F9 gold do not show that. I get an unmanaged interface and
have to manually edit to get things going

One big difference - I never use the live media. Is it another case of which
install media you use determines which bugs you get?
Comment 123 Linus Torvalds 2008-05-14 14:13:04 EDT
(In reply to comment #120)
> The installer sets up those key/value pairs for you if you install a fresh
> copy

NO IT DOES NOT.

The thing is, I installed that particular machine with DHCP set to true, and all
the DNS information coming from DHCP.

I then turned the interface into a static IP address when it was ready to be
moved to its final place.

And as far as I can tell, that simply does not work, because s-c-n and NM simply
cannot then agree about things. This has nothing to do with installation, and
everything to do with the fact that you seem to be assuming that things have to
be done your way or not at all.

I asked you to consider this exact thing in comment #117. You aren't listening.
I have a totally bog-standard F9 install, and what you claim should work has
nothing to do with the bug I see.

I'm not going to re-install the whole system now that it's finally in a working
condition, especially since turning it into a static IP setup was conditional on
it being tested and installed, so *even*if* I were to re-install, I would
*again* install first under a temporary IP address (using DHCP, of course) until
the machine is up and running and tested, and then I would *again* turn it into
a static IP address with s-c-n.

And it would *again* not work. Fresh copy or not doesn't matter. What matters is
that I use s-c-n to turn a device (and the DNS settings that go with it) from
the DHCP thing to a static setting.

So this has nothing what-so-ever to do with Anaconda.

And you still haven't even addressed the "mark network device as not being
managed by NM" case.

End result: NM apparently needs to be disabled to get even *trivial* things to
work, namely to install with DHCP and then later change things to a static
address. This is not something odd or unreasonable.

Yes, maybe by now it's a s-c-n issue, but the fact that you refuse to even
acknowledge that there is a "don't let NM manage this device" problem makes me
nervous.
Comment 124 Jesse Keating 2008-05-14 14:18:46 EDT
Linus, when you did the install, you say you set it up for DHCP.  Did that
include getting dns from DHCP?  Because if it did, then obviously the key value
pair isn't going to be written out to the config file, as it's expecting that
information to come from the DHCP server.

What Dan is claiming that if you had configured the system for static IP and
static DNS during anaconda install, that key value pair /would/ have been
written out.

I think the two of you are talking past each other a bit.

Going from DHCP configured at install time to static /after/ the fact is not a
'bog standard' setup.  It is however a use case that we should be testing for in
our release tests.  I'll make note of this and bring it to our QA folks.
Comment 125 Dan Williams 2008-05-14 14:28:10 EDT
Linus: regarding comment #117:

> - turn a device from NM-managed to non-NM managed, and expect the networking
> to still work.

Yes I expect that networking will still work.  But that apparently depends on
how the ifcfg file was set up in the first place.  If you used the installer to
install your system with static IP, then it will work correctly because the
DNS1/DNS2 tags are in the ifcfg file.  But if you set it up for DHCP and then
later change that with system-config-network to static IP with manually-defined
DNS servers, then you've discovered a failure case.  We will work to fix
system-config-network such that it correctly writes out the DNSX options so that
this case will work in all configurations.

But if the underlying ifcfg will work with NM, then just switching
managed/unmanaged will certainly be expected ot work.

> - start the device in DHCP mode (because it got installed at a temporary
> address), but then make the device be a static IP (because that's the final
> one), at which point the DNS information comes not from the *device*
> management, but from s-c-n DNS configuration and /etc/resolv.conf.

Right; this is a failure case as you've discovered.  We need to fix
system-config-network.
Comment 126 Dan Williams 2008-05-14 14:32:00 EDT
Linus: to get NetworkManager to work for you, the resolution is two things:

You:
- Add DNS1 and DNS2 to your ifcfg-eth0 file and NM_CONTROLLED=yes

Me:
- Fix system-config-network to write out DNS1/DNS2 for all connections
Comment 127 Linus Torvalds 2008-05-14 14:43:05 EDT
(In reply to comment #124)
> 
> Going from DHCP configured at install time to static /after/ the fact is not a
> 'bog standard' setup.  It is however a use case that we should be testing for in
> our release tests.  I'll make note of this and bring it to our QA folks.

I really object to you saying it's not 'bog standard'. It certainly has always
been for me, and I bet it has been for tons and tons of other people. It's a
very natural thing to do: almost everybody has a DHCP server somewhere on their
network, but I also claim that almost everybody has reason to use static IP
addresses for particular machines.

And when I replace a machine, I *always* leave the old machine running until the
new machine is ready. And quite frankly, I do not think that anybody can
reasonably claim to not do the same thing. Especially with a new release, you
want to see the machine working first, *before* you replace your old machine
with the new one.

So I have basically always done the "temporary IP numbers with DHCP" thing, and
installed machines that way. Then, when youtube works and I can actually give
the end result to my wife (having copied all her files over), I go and shut down
the old machine, replace it in-place with the new one, and switch the new one to
the same old static IP address that the old one used to have.

This is not in the least odd.

In fact, I would say that anybody who replaces existing machines using any other
model is the odd one. Do you take some machine down for several days (or in this
case, months, since I had to wait for F9 to stabilize), to install a new one in
its place without first checking that it all works?
Comment 128 Linus Torvalds 2008-05-14 14:51:59 EDT
(In reply to comment #126)
> 
> You:
> - Add DNS1 and DNS2 to your ifcfg-eth0 file and NM_CONTROLLED=yes

You still don't seem to get that I already had a fix for this, long ago:

Me:
 - turn off NM

which was really easy, and didn't involve editing any configuration files.

I'm not at all interested in having NM running on that machine per se. I have a
perfectly working setup, and I got there myself. I'm *not* going to hand-edit
any config files because I already solved my problem, and I don't understand why
you can't just accept that fact.

So why am I doing a bug-report at all? My machine already worked!

I'm doing this bug-report, and giving you my message logs not because I care
about having that machine work (I already have it), but because I am trying to
help you get NM working for others, and because I don't want to go through this
next time I set up a machine.

So the *only* thing I care about is to have NM and s-c-n work together in every
single combination, so that I will never ever have to care ever again. Please
don't continually ask me to edit configuration files by hand, because every time
you do that, you just show that you don't understand that that isn't what this
whole report is all about.

Please? Can we agree that you will never *ever* ask me to edit a config file
just to hide the bugs? I'm not interested. I'm interested in showing the bug,
not hiding it!

And until the bug is fixed, I'll just not run NetworkManager. In fact, I very
much *refuse* to touch any config files, because if I do, the bug just goes away
and gets forgotten, and presumably will then never ever be fixed because
apparently nobody cared for the last four years because apparently static IP
addresses are such an "odd thing".
Comment 129 Jesse Keating 2008-05-14 15:06:04 EDT
No, we always use dynamically assigned static IPs, and dhcp persistence.

Regardless if it's "bog standard" or not, it is an actual bug and it will be
fixed.  It didn't get seen in our installation tests because we were testing
selecting at install time the configuration that would be used later.
Comment 130 Ron Yorston 2008-05-15 15:49:17 EDT
FTP install of Fedora 9 on an Athlon XP with a single wired network card.  I
asked for a static IP address.  This is a standard install so NetworkManager is
enabled, network is not.  On boot I got a DHCP assigned IP address.  This is
what anaconda generated for ifcfg-eth0:

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.42.255
HWADDR=xx:xx:xx:xx:xx:xx
IPADDR=192.168.42.1
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.0
NETWORK=192.168.42.0
ONBOOT=yes
DNS1=192.168.42.254
SEARCH="rmyorston.plus.com"
NM_CONTROLLED=

Running s-c-n and checking the box to allow NetworkManager to control the device
made it work as expected.  Reverting to the anaconda-generated config I fond
that the minimal change required to get a static IP address is to add the line:

TYPE=Ethernet

Though, of course, that doesn't set a default route so it's also useful to add:

GATEWAY=192.168.42.254
Comment 131 Dan Williams 2008-05-15 16:12:19 EDT
Linus: see https://bugzilla.redhat.com/show_bug.cgi?id=446743 for the patch to
the s-c-n / NM miscommunication issue.

Ron: NM should be interpreting an ifcfg file with a missing TYPE line by
auto-detecting whether it's Ethernet or Wifi, so this seems like a bug and I'll
look at it.
Comment 132 Linus Torvalds 2008-05-15 16:25:18 EDT
(In reply to comment #131)
> Linus: see https://bugzilla.redhat.com/show_bug.cgi?id=446743 for the patch to
> the s-c-n / NM miscommunication issue.

I'll wait for those updated packages to hit me, and will try. I don't know s-c-n
nor python, so I can't tell if this does the right thing when there are multiple
devices already configured and you change DNS (without changing anything else
about the devices), but I assume it does.

Or can you now set DNS (statically) per-device, along with IP address? That
would match what the config file contains, and would probably be good regardless.

> Ron: NM should be interpreting an ifcfg file with a missing TYPE line by
> auto-detecting whether it's Ethernet or Wifi, so this seems like a bug and I'll
> look at it.

Umm. What does it matter whether it's Wifi or Ethernet? If it was marked static,
it shouldn't do DHCP regardless. Whether it is ethernet or not has nothing to do
with anything.
Comment 133 Răzvan Sandu 2008-05-16 16:50:32 EDT
Hello,

Regarding comment #130, last line:

Maybe it's offtopic and/or newbie question, but please let us know (in some
piece of documentation) why default gateway (GATEWAY=...) and static routes are
treated as *interface-specific* and not *system-wide*.

For example, why is GATEWAY= present in
/etc/sysconfig/network-scripts/ifcfg-eth0 and not /etc/sysconfig/network ?


Regards,
Răzvan
Comment 134 Dan Williams 2008-05-16 18:12:32 EDT
Răzvan: because they actually are interface specific.  A wired connection might
have one gateway, while a wireless card in the same computer might have a
completely different gateway if they aren't on the same network.  Thus, if there
was one global GATEWAY, it would most certainly be wrong when you switched
network connections.
Comment 135 Răzvan Sandu 2008-05-16 19:12:38 EDT
To comment #134 above:

IMHO, this is pretty weird.

If a computer is hooked to two or more networks *simultaneosly* (say it's a
router, different IP classes, etc.), a packet that is to be sent to the Internet
(default gateway) still needs a *single*, unequivocal route to follow. I imagine
this was the reason for GATEWAY= in /etc/sysconfig/network...

Is that any manual/official documentation/Red Hat supported text on this matter,
please ? To see the "canonical" way of doing things...


Regards,
Răzvan
Comment 136 Răzvan Sandu 2008-05-16 19:16:46 EDT
Because questions in comment #134 and comment #135 above are not directly
related with the bug itself, I've opened bug #446997 on this. Please add al
replies there.

Răzvan
Comment 137 Gilboa Davara 2008-05-17 00:04:16 EDT
(In reply to comment #134)
> Răzvan: because they actually are interface specific.  A wired connection might
> have one gateway, while a wireless card in the same computer might have a
> completely different gateway if they aren't on the same network.  Thus, if there
> was one global GATEWAY, it would most certainly be wrong when you switched
> network connections.

Huh?
Correct me if I'm wrong - but ifcfg-XXX doesn't support subnet routes.
The equivalent of GATEWAY=x.x.x.x in, say, ifcfg-eth0 is 'route add -net 0.0.0.0
netmask 0.0.0.0 gw x.x.x.x eth0' which makes it the global catch-all gateway.
Adding other GATEWAY lines to subsequent ifcfg-xxx files is redundant - as only
the lowest order ifcfg-XXX gateway will be used.

- Gilboa
Comment 138 Fedora Update System 2008-05-19 11:42:07 EDT
NetworkManager-0.7.0-0.9.3.svn3669.fc9 has been submitted as an update for Fedora 9
Comment 139 Fedora Update System 2008-05-19 11:46:35 EDT
NetworkManager-0.7.0-0.6.8.svn3669.fc8 has been submitted as an update for Fedora 8
Comment 140 Fedora Update System 2008-05-21 06:55:58 EDT
NetworkManager-0.7.0-0.9.3.svn3669.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4167
Comment 141 Răzvan Sandu 2008-05-21 12:05:20 EDT
Hello,

quagga daemons (zebra and ripd) "die" a short time after boot, even if there's
some connection active across the network.

If restarted manually, then they work OK.

Regards,
Răzvan
Comment 142 Răzvan Sandu 2008-05-27 06:31:08 EDT
After testing for a few days, on different machines running F9 (most of them
upgraded from F8 via preupgrade or via CD), Network Manager keeps disconecting
my workstations unexpectedly ("freezing" my ssh connections or disrupting the
routing daemons as presented in comment #141 ). This is strange, since I've used
Ubuntu's NetworkManager with no problems.

This is probably one of the most annoying bugs in F9 (not only annoying, but
undermining company's network stability).

For the moment, I had to disable NetworkManager on most workstations, despite
the fact that I'm willing to test it.

*Please* find a solution to this and point us to some in-depth documentation.

My NetworkManager is NetworkManager-0.7.0-0.9.3.svn3669.fc9.i386

Regards,
Răzvan
Comment 143 Alan 2008-06-03 18:11:15 EDT
where comments 134-137 dealt with routes, I'm worried about DNS defaults being
in ifcfg- files instead of [also] being in a more global place.
I want to have a default SEARCH path for my machine.  if I "ping shorthostname"
the system needs a default search path regardless of which interfaces are up...
I can see use cases where you might want to add/subtract something to the search
path based on bringing an interface up or down.  and I expect the default domain
name to be correlated to the current default route.  But I still might want to
have other items in the search path regardless of which interface is up (and
possible default nameservers).  With the default actions that anaconda and now
s-c-n take this means I have to add those search items to each ifcfg- file...

in older fedora versions this was fixed with the /etc/dhclient-enter-hooks file.
 but now that NM does not use dhclient-script that file is no longer read.  I
tried adding a SEARCH= line to /etc/sysconfig/network but no dice (though I am
still on fedora 8)...

-alan
Comment 144 Dan Williams 2008-07-02 19:00:40 EDT
*** Bug 453351 has been marked as a duplicate of this bug. ***
Comment 145 Dan Williams 2008-07-02 19:01:54 EDT
*** Bug 447500 has been marked as a duplicate of this bug. ***
Comment 146 Fedora Update System 2008-07-09 17:47:03 EDT
NetworkManager-0.7.0-0.6.9.svn3675.fc8, NetworkManager-openvpn-0.7.0-10.svn3632.fc8, NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.