Bug 444502

Can you update to the latest koji version and see if that fixes the issue?

http://koji.fedoraproject.org/koji/buildinfo?buildID=47429

If it does not, there are a few more things we can try.  NM should definitely be
respecting this configuration though.

Nope, no change (eth0 still activated):
------------------------------------------------------------------------------
[root@owl ~]# rpm -q NetworkManager
NetworkManager-0.7.0-0.9.2.svn3614.fc9.x86_64
[root@owl ~]# ---------------------------------------------------------------
[root@owl ~]# /usr/sbin/NetworkManager --no-daemon
NetworkManager: <info>  starting...
RTNETLINK answers: File exists
NetworkManager: <info>  eth0: Device is fully-supported using driver 'skge'.
NetworkManager: <info>  Found new Ethernet device 'eth0'.
NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_0e_a6_2d_87_64
NetworkManager: <info>  (eth0): device state change: 1 -> 2
NetworkManager: <info>  Bringing up device eth0
NetworkManager: <info>  Deactivating device eth0.
Nothing to flush.
Nothing to flush.
NetworkManager: <info>  (eth0): carrier now ON (device state 2)
NetworkManager: <info>  (eth0): device state change: 2 -> 3
NetworkManager: <info>  Activation (eth0) starting connection 'Auto eth0'
NetworkManager: <info>  (eth0): device state change: 3 -> 4
NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: <info>  (eth0): device state change: 4 -> 5
NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure)
successful.
NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start)
scheduled.
NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start)
started...
NetworkManager: <info>  (eth0): device state change: 5 -> 7
NetworkManager: <info>  Activation (eth0) Beginning DHCP transaction.
Internet Systems Consortium DHCP Client 4.0.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

NetworkManager: <info>  dhclient started with pid 6777
NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start)
complete.
NetworkManager: <info>  DHCP: device eth0 state changed (null) -> preinit
Listening on LPF/eth0/00:0e:a6:2d:87:64
Sending on   LPF/eth0/00:0e:a6:2d:87:64
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.17.91
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.17.91
NetworkManager: <info>  DHCP: device eth0 state changed preinit -> bound
NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get)
scheduled...
NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) started...
NetworkManager: <info>    address 192.168.17.190
NetworkManager: <info>    netmask 255.255.255.0
NetworkManager: <info>    broadcast 192.168.17.255
NetworkManager: <info>    gateway 192.168.17.91
NetworkManager: <info>    nameserver '192.168.17.91'
NetworkManager: <info>    domain name 'home'
NetworkManager: <info>    nis domain 'home'
NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit)
scheduled...
NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) complete.
NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit)
started...
bound to 192.168.17.190 -- renewal in 8421 seconds.
NetworkManager: <info>  (eth0): device state change: 7 -> 8
NetworkManager: <info>  Policy set (eth0) as default device for routing and DNS.
NetworkManager: <info>  Activation (eth0) successful, device activated.
NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit)
complete.
^CNetworkManager: <WARN>  nm_signal_handler(): Caught signal 2, shutting down
normally.
NetworkManager: <info>  (eth0): now unmanaged
NetworkManager: <info>  (eth0): device state change: 8 -> 1
NetworkManager: <info>  Bringing down device eth0
receive_packet failed on eth0: Network is down
[root@owl ~]# --------------------------------------------------------
[root@owl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
# 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0e:a6:2d:87:64
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=yes
DHCP_HOSTNAME=f9-owl
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=no
PEERDNS=yes
[root@owl ~]# 
[root@owl ~]# 
-------------------------------------------------------

Well, at least  some good news .... while
NetworkManager-0.7.0-0.9.2.svn3614.fc9.x86_64
does NOT fix my problem with NM_CONTROLLED=no being honored, it DOES appear to
fix the problem of sending the system name for dhcpd to dynamically update DNS
(like it should and like "ifup" does).

Could you (all as root):

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

and attach the output of that here?

Also, what's the MAC address of your 3com 3c940 as reported by '/sbin/ifconfig
eth0' ?

OK, the info you requested follows.  HOWEVER, I may have screwed things up by
updating to "current" rawhide which changes things to Fedora 9 (rawhide) from
the f9-preview.  I am still using your recommended NetworkManager but there is a
new s-c-network package.

Furthermore, in my fooling around, I have found that NM_CONTROLLED has no effect
for Network Manager whether it is yes or no BUT s-c-network will only let me
activate/deactivate is NM_CONTROLLED=no.

Furthermore, futhermore, I have found that NetworkManager will only bring up the
network IF I use nm-connection-editor to add a wired network (dhcp) connection
... the connection is brought up regardless of the NM_CONTROLLED setting.

#######
####### 3COM MAC addr from ifconfig is 00:0E:A6:2D:87:64
#######
[root@owl ~]# 
[root@owl ~]# 
[root@owl ~]# rpm -q NetworkManager
NetworkManager-0.7.0-0.9.2.svn3614.fc9.x86_64
[root@owl ~]# rpm -q system-config-network
system-config-network-1.5.7-1.fc9.noarch
[root@owl ~]# 
[root@owl ~]# service NetworkManager stop
Stopping NetworkManager daemon:                            [  OK  ]
[root@owl ~]# killall -TERM nm-system-settings
############
############ Note: NM_CONTROLLED=yes in ifcfg-eth0
############
[root@owl ~]# /usr/sbin/nm-system-settings --plugins=ifcfg-fedora --debug
** Message: Loaded plugin 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-eth0 ... 
** Message:    ifcfg-fedora:     read connection 'System eth0'
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
** Message:    ifcfg-fedora:     error: Ignoring loopback device config.
############
############ rerun with NM_CONTROLLED=no
############
[root@owl ~]# /usr/sbin/nm-system-settings --plugins=ifcfg-fedora --debug
** Message: Loaded plugin 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-eth0 ... 
** Message:    ifcfg-fedora:     read connection 'System eth0'
** Message:    ifcfg-fedora: Ignoring connection 'ifcfg-eth0' and its device
because NM_CONTROLLED was false.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
** Message:    ifcfg-fedora:     error: Ignoring loopback device config.
--------------------------------------------------------------------------
If you need me to go back to a base install with only the new
NetworkManager-0.7.0-0.9.2.svn3614.fc9.x86_64 say the word and I will try again.

BTW, with the updated system, there is now an selinux problem with dhclient
which I will report separately.

OK, I believe I may have found a (if not the) problem pertaining to this bug report.

When NetworkManager is started, it also starts nm-system-settings (which looks
at NM_CONTROLLED) ... if the setting is "no", then the network is not started.

If NetworkManager is then stopped, NM_CONTROLLED=yes is set,and then
NetworkManager is started, the network will not start because nm-system-settings
is still using the "old" value ... nm-system-settings needs to be stopped when
NetworkManager is stopped and then restarted when NetworkManager is restarted.

No, they should be independent.  The system-settings daemon uses inotify to
monitor the ifcfg files and should pick up the changes.

Can you run /usr/sbin/nm-system-settings like I described before (with NM
stopped), and then in another terminal change NM_CONTROLLED to the opposite of
what it is, and then paste the nm-systme-settings output here?  Lets see if the
system settings service picks up the change.

Well, well ... now this is interesting (see details below) ... using s-c-network
to change NM_CONTROLLED, the change is not recognized but if I vi the file to
change NM_CONTROLLED, the change is detected!

For the first attempt, I used s-c-network to change NM_CONTROLLED
----------------------------------------------------------------
[root@owl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
# 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0e:a6:2d:87:64
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=no
DHCP_HOSTNAME=f9-owl
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=yes
PEERDNS=yes
[root@owl ~]# /usr/sbin/nm-system-settings --plugins=ifcfg-fedora --debug
** Message: Loaded plugin 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-eth0 ... 
** Message:    ifcfg-fedora:     read connection 'System eth0'
** Message:    ifcfg-fedora: Ignoring connection 'ifcfg-eth0' and its device
because NM_CONTROLLED was false.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
** Message:    ifcfg-fedora:     error: Ignoring loopback device config.
^C
[root@owl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
# 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0e:a6:2d:87:64
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=no
DHCP_HOSTNAME=f9-owl
TYPE=Ethernet
NM_CONTROLLED=yes
USERCTL=yes
PEERDNS=yes
[root@owl ~]# 

----------------------------------------------------------------
The is I used vi to change NM_CONTROLLED
----------------------------------------------------------------
[root@owl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
# 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0e:a6:2d:87:64
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=no
DHCP_HOSTNAME=f9-owl
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=yes
PEERDNS=yes
[root@owl ~]# /usr/sbin/nm-system-settings --plugins=ifcfg-fedora --debug
** Message: Loaded plugin 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-eth0 ... 
** Message:    ifcfg-fedora:     read connection 'System eth0'
** Message:    ifcfg-fedora: Ignoring connection 'ifcfg-eth0' and its device
because NM_CONTROLLED was false.
** 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-eth0 ... 
** Message:    ifcfg-fedora:     read connection 'System eth0'
^C
[root@owl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
# 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0e:a6:2d:87:64
IPV6INIT=yes
IPV6_AUTOCONF=yes
ONBOOT=no
DHCP_HOSTNAME=f9-owl
TYPE=Ethernet
NM_CONTROLLED=yes
USERCTL=yes
PEERDNS=yes
[root@owl ~]# 

So, all os this problem concerns system-config-network NOT doing something when
I edit & save NM_CONTROLLED settings that using vi DOES do ... something which
is detected by nm-systems-settings ... something not detected by "inotify".

I just ran a quick test and s-c-network does change the date/time on the file
when it is updated.

1. The bug is in nm-system-settings so this should remain a report against
NetworkManager.

2. The bug in in s-c-network so this report should be change to be against
s-s-network OR this report should be closed and a new report opened against
s-c-network

3. There is something wrong with inotify so this bug should be closed and a new
one opened against ?? (the kernel?).

4. NetworkManager has come a long way and with current support of static IPs and
multiple NICs AND management of devices can be split between NetworkManager and
system-config-network, this problem should be identified and fixed.

Now that I understand the problem, I can work around it.  However, others will
hit this problem and I am willing to put some time into getting it fixed.

I just ran another quick test and running "touch" against the ifcfg file is
detected by nm-system-settings

OK, this bug is not really a big deal BUT it will annoy users with something
unexpected (changes by s-c-network are not detected by nm-system-settings). 
Therefore, I believe it is worth pursuing and I believe it is a NetworkManager
problem.

I have looked at the system-settings/plugins/ifcfg-fedora/plugin.c source code
(around lines 775 through 900) {specifically sc_plugin_inotify_init() and
stuff_changed() ... at least so far).  I don't see anything obviously wrong.

To try to gather more info, I ran the following tests using:
   inotifywatch -v  /etc/sysconfig/network-scripts/ifcfg-eth0 
to look at what was happening.

First, I used vi to "update" write the ifcfg-eth0 file.  Then I used s-c-network
to change the NM controlled to no and then back to yes ... I then "saved" the
updated file.

In BOTH cases, inotifywatch reported:

total  access  modify  attrib  close_write  close_nowrite  open  filename
11     2       2       1       1            2              3    
/etc/sysconfig/network-scripts/ifcfg-eth0

My conclusion, is that s-c-network is doing nothing unusual.  There must be a
race condition or some other circumstance occurring ifcfg-fedora/plugin.c.

I am contemplating creating a special "instrumented" version of
nm-system-settings ... any tips on where to put the instrumentation will be
appreciated.

One difference might be that system-config-network _hardlinks_ the ifcfg file
into /etc/sysconfig/network-scripts.  That shows up as different inotify
behavior.  You probably want to look at
system-settings/plugins/ifcfg-fedora/plugin.c::stuff_changed() and see what
'path', 'filename', and 'evt.mask' are to start with. 

OK, I have done some crude "instrumentation" of plugin.c and can see what is
happening but not necessarily why or what a good fix would be.

As an aside, I used inotifywatch to look at
/etc/sysconfig/network-scripts/ifcfg-eth and
/etc/sysconfig/networking/devices/ifcfg-eth0 while I changed the file using
s-c-network ... the result was exactly the same events/event types in both cases.

I am attaching a patch so you can see what my "instrumentation" is.  I am also
attaching the terminal output of running 
[root@owl ~]# nm-system-settings --debug --config /etc/nm-system-settings.conf 

I used rpmbuild -bi to create BUILD tree, manually updated plugin.c, did a
"make" from system-settings, and then did a rpmbuild -bi --short-circuit to get
an updated libnm-settings-plugin-ifcfg-fedora.so 

I then:
  - stopped NetworkManager
  - copied the new library to /usr/lib64/NetworkManager
  - ran nm-systenm-settings in a terminal session
  - started NetworkManager and waited for the network to initialize.
  - Then, I did an "=no" update with vi
  - followed by an "=yes" update
  - then I brought up s-c-network
  - then I set NM off and saved followed by NM on and save [this is the last six
lines of the console output]

To me, it looks like s-c-network uses the full pathname to do the update whereas
vi must "cd" to the directory and then only use the filename.  I do not know if
this is actually what is happening.

I also do not know just what a good fix would be.

While NetworkManager may be the strategic direction for Fedora (and Red Hat
products), I suspect that s-c-network will be around for a while to handle
corner cases and to please paying Red Hat customers.

If you believe (you, Dan Williams) as an apparent major developer of
NetworkManager that NetworkManager's nm-system-settings is doing things the
"right way", then it may be "easier" to change s-c-network to be compatible with
what NetworkManager expects.

Regardless, I recommend that a [post release obviously] not be added to the
Fedora 9 Release Notes that says (more or less) "changes made by the
"system-config-network" tool may not be detected by NetworkManager". 
Unfortunately, just restarting NetworkManager will not fix things since
nm-system-settings is not restarted and will tell NEtworkManager that no change
has occurred [btw, maybe nm-system-settings should be stopped when
NetworkManager is stopped].

Created attachment 304895 [details]
crude "instrumentation" patch for plugin.c

Created attachment 304896 [details]
console log

# nm-system-settings --debug --config /etc/nm-system-settings.conf

I took a look at s-c-network ... sorry, python is not my bag!

I am not that familiar with inotify so this is probably a stupid question ...
Why is wd (the watch descriptor) of the even caused by s-c-network always "2" as
opposed to "1"?  Does this have anything to do with the fact that "path" is the
whole pathname with filename being a zero length string as oppose to path being
NULL and the filename having a value?  What determines "wd"?

If you are busy, just ignore this and will continue bumbling along ... who
knows, I might learn something.

OK, more testing and code examination ...

nm-system-settings (specifically ifcfg-fedora/plugin.c) is not currently
handling hardlinks.

There are (at least) three different locations for ifcfg- files:
/etc/sysconfig/network-scripts/ (which is directory plugin.c monitors),
/etc/sysconfig/networking/devices/ and /etc/sysconfig/profiles/default/  ... all
hardlinked in some fashion ... s-c-network appears to be creating/updating one
of these but definitely NOT /etc/sysconfig/network-scripts/ifcfg-* ... in fact,
the s-c-network code refers to /etc/sysconfig/network-scripts as the "OLD" location.

There is code in plugin.c to handle hardlinks -- watch_path() around line 290. 
It even saved "wd" into the hash table.  Unfortunately, stuff_changed() around
line 775 specifically ignores all watch events because it checks to make sure
the "wd" for the event matches the "wd" which was created and saved in
sc_plugin_inotify_init().

There is also the complicating factor that, in the first case, the path==NULL
and the filename is a string of some form "ifcfg-" whereas, in the hardlink
case, the filename is a zero length string and the path points to the fully
qualified name of the file.

Possible fix/patch:

1. add code to watch_path() to save "wd"
2. in stuff_changed(), just before the "else" following "if (evt.wd ==
priv->wd)" add an "} else if (<test for hardlink's wd>) {" followed by (more or
less) the proceeding code but with "path" substituted for "filename".

Comments???

Yet more fooling around and testing.

I MAY have found a quick and simple fix:

In ifcfg-fedora/plugin.c around line 52, change:

#define IFCFG_DIR SYSCONFDIR"/sysconfig/network-scripts/"

to:

#define IFCFG_DIR SYSCONFDIR"/sysconfig/networking/devices/"

This change appears to put ifcfg-fedora/plugin.c in sync with
system-config-network as the what the "real" file is being changed.  However,
the whole business of hardlinks is being ignored stuff_changed() since evt.wd is
NOT the expected one.  What I have seen so far is the wd==1 for the watched
directory but wd>1 for hardlinks.  Since there can be multiple devices defined,
the value of wd can vary all over the place.

Now, the question is:  What does this change screw up???

If you really want, I can create a "patch" but it seems a bit overkill at this
point.

Here are some patches.

These patches wre created based on NetowrkManager-0.7.0-0.9.3.svn3623.fc9.src.rpm

I used rpbbuild -bc, then went in and modified plugins/ifcfg-fedora/plugin.c,
manually ran make, then ran rpmbuild -bi --short-circuit to get the library.

To test: stop NetworkManager, manually kill the nm-system-settings and dhclient
processes, copy the updated library to /usr/lib64/NetworkManager, manually run
nm-system-settings in a terminal, and then start NetworkManager.

Testing consisted of modifying the ifcfg- files with s-c-network, touching
and/or vi'ing the files in all three of the locations.  Everything seemed to work.

To run nm-system-settings, I used:
[root@owl ~]# nm-system-settings --debug --config /etc/nm-system-settings.conf

With the "hardlinks" patch applied, I am not sure that the directory needs to be
changed.

Created attachment 305067 [details]
change the directory monitored to .../networking/devices/

Created attachment 305068 [details]
hardlinks patch

add code to stuff_changed() for "evt.wd > priv->wd" (GT 1?)

I left some of the filename checks in even if I do not see how they could occur
for hardlinks.

This patch more or less assumes that "evt.wd == priv->wd == 1" for
non-hardlinks and evt.wd>priv->wd for all hardlinks

Created attachment 305069 [details]
crude debug "instrumentation"

Although this patch was not developed in this manner, it is intended to be
applied over patch #1 and patch #2.

This adds some crude "instrumentation" to plugin.c so that I could see what was
happening

Just a note that I've fixed this issue with hardlinks upstream and will build a
new testing version of NM shortly.

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

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

Please test these updates and see confirm that they fix this issue.  Thanks!  It
might take a day or two for them to hit f9-updates-testing

NetworkManager-0.7.0-0.9.3.svn3675.fc9.x86_64 here. This version seems to leave
my PPP/DSL connection ppp0 alone (it is NM_CONTROLLED=no), but runs dhclient on
eth2 which is the interface where the DSL modem is attached which shouldn't get
an IP address at all.

A little OT, but I'd like to check whether my setup makes sense -- I have these
system-wide interfaces:

- eth0, eth1: static IP
- eth2: IP-less interface to DSL modem
- ppp0: DSL to Internet, activated at boot time

The only thing I'd need NM for is connecting to the VPN. While it seems to do
that, I had to set eth0, eth1 to NM_CONTROLLED=yes so NM knows it has (some)
connection -- is that on purpose? Ideally (IMO), NM would see that there are
connected interfaces, but leave them alone. Is there a way to specify a VPNC
script in NM and that it should leave resolv.conf alone as well -- the script
would take care of setting up things in a way that VPN addresses and hostnames
are resolved through the VPN nameservers, while the rest is resolved locally.

NB: It would also be good if I could specify the PPP/DSL connection as
system-wide, but NM-controlled so that if it goes down and pppd doesn't recover
(it will give up after a while), I could restart it manually from the applet
(would let me get rid of the modem lights applet as well).

Ironically, due to NM really wanting to control eth2 but not getting an address
on it, VPN won't work as well. To top it off, disabling "Enable Networking" in
the applet killed the PPP connection as well, despite it being NM_CONTROLLED=no.

Nils: if you create a skeleton ifcfg for eth2 using system-config-network or
manually, and set NM_CONTROLLED=no, then NM will ignore it.  Make sure you
specify the HWADDR variable with the MAC address of your card.

Hi Dan, this is my ifcfg-eth2:

nils@wombat:~> cat /etc/sysconfig/network-scripts/ifcfg-eth2
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Ethernet
DEVICE=eth2
HWADDR=00:30:84:40:1d:b2
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
PEERDNS=no
IPV6INIT=no
NM_CONTROLLED=no

I think I've done just what you described -- NM still tries DHCP on the
interface, though. As that fails, NM seems to think that it doesn't have a
connection (crossed out icon) and activating the VPN connection doesn't have an
effect (the entries under "VPN connections" aren't grayed out, but nothing
noticable happens if I click on one of them).

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

Installed and tested the update ... it works ...the reported problem is fixed.

I do notice that stopping NetworkManager still leaves nm-system-settings running
... I thought that was to be fixed also ... or is it in a later version?

For my purposes, this report could be closed as FIXED.  However, others have
reports added which may or may not be fixed so I am leaving it to Dan
<dcbw> to make that decision.

Nils; can you:

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

and report what it says there?

If you unmanage a device from NM, then you've told NM to ignore it, and thus NM
won't report it's status becuase it's not controlled by NM.  This means that if
you want to use VPN, your primary device will need to be managed by NM.

Also, is your eth2 just an ethernet card hooked up to an external DSL router, or
is it a USB device that acts like an ethernet device or something?

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 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 NetworkManager-openvpn NetworkManager-vpnc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5203

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.