Network Manager doesn't know about static IP addresses on ethernet cards. It will blindly run dhclient when switching to Wired mode.
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).
What about BOOTPROTO=static ? Thats what wound up in my ifcfg-eth0.... NM didn't seem to use my settings.
Changing my BOOTPROTO didn't help. Seems there is something else going on. I will investigate.
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.
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.
Changing version to correct version bug was filed against. (Some were filed against "test3" when they clearly are for FC3T2, a test for FC3.)
Updating version according to comment 4. Dan, is this fixed in FC6/FC7 ?
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.
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.
(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.
(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.
This bug is also evident in FC8
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.
*** Bug 357251 has been marked as a duplicate of this bug. ***
*** Bug 244671 has been marked as a duplicate of this bug. ***
*** Bug 365301 has been marked as a duplicate of this bug. ***
*** Bug 375481 has been marked as a duplicate of this bug. ***
*** Bug 378501 has been marked as a duplicate of this bug. ***
Stupid question: why we just don't take Ubuntu patches [if any]?
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)
*** Bug 320001 has been marked as a duplicate of this bug. ***
*** Bug 283301 has been marked as a duplicate of this bug. ***
The Ubuntu patches are a short-term hack for 0.6.5 and are not where we want to be with NM 0.7.
If NM will be default starting from F9 static configuration is a must.
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.
(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.
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.
*** Bug 391351 has been marked as a duplicate of this bug. ***
More and more CC's but no action...
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.
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.
*** Bug 388641 has been marked as a duplicate of this bug. ***
*** Bug 416331 has been marked as a duplicate of this bug. ***
system-config-network 1.3.99 is disturbed
Disturbed? So what? I don't get it. It doesn't play with NM, or it plays with NM?
*** Bug 212981 has been marked as a duplicate of this bug. ***
*** Bug 428532 has been marked as a duplicate of this bug. ***
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].
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?
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.
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.
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.
Marek, NM for basic tasks, like sitting in tray, using DHCP and notifying of connection state, works well :P .
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.
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.)
(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.
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.
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.
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.
(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
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.
AFAICS svn3476 is the latest build. Stale mirrors?
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
Created attachment 300014 [details] Combined ifcfg-eth? $ cat /etc/sysconfig/network-scripts/ifcfg-* > ifcfg-eth.log
Created attachment 300015 [details] ifconfig output $ ifconfig > ifconfig.log
Created attachment 300016 [details] ifconfig output with NM disabled
Created attachment 300017 [details] Combined ifcfg-eth? (Fixed) $ cat /etc/sysconfig/network-scripts/ifcfg-eth? > ifcfg-eth.log
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
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
(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.
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.
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.
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
P.S. All the network devices are defined as NM_CONTROLLED=no. - Gilboa
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!
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?
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
P.S. NM also ignores the default gateway configuration. (Found in ifcfg-eth0) - Gilboa
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?
(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
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
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
Chris: can I get your ifcfg files and also /var/log/messages right after boot when things aren't configured correctly?
Created attachment 304901 [details] Files for your request
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
Created attachment 305050 [details] Chris /var/adm/messages - first boot after install
Created attachment 305051 [details] Chris /etc/sysconfig/network-scripts/ifcfg-eth0
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)
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?
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 :) .
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.
(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.
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.
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.
(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.
(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.
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
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?
(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?
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.
(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.
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?
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).
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?
(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!
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.
(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!
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.
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.
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.
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.
(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?
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!
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.
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!
(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.
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!
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.
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).
(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?
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
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.
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.
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.
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.
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.
(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.
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).
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.
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.
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.
(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?
(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.
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.
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.
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
(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?
(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".
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.
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
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.
(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.
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
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.
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
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
(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
NetworkManager-0.7.0-0.9.3.svn3669.fc9 has been submitted as an update for Fedora 9
NetworkManager-0.7.0-0.6.8.svn3669.fc8 has been submitted as an update for Fedora 8
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
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
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
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
*** Bug 453351 has been marked as a duplicate of this bug. ***
*** Bug 447500 has been marked as a duplicate of this bug. ***
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.