Ok, can I give it a try to help clear things up? Not that I am an expert on the subject, but hopefully... :-) Somebody please correct me if I get something wrong here. When we speak of "network", there are several layers at work here. First, there is hardware. Cables, network cards at their ends and such. Your particular host machine may have two network cards, for example (wired and wireless, typically for a laptop). These network cards, the *hardware*, are called "network interfaces". They are present in your computer whether you like it or not, and can have a "state", for example they can be "active" or "inactive" and such. Next there is the kernel. It has drivers and other software to communicate with other computers using the network cards, ie. interfaces. This software (inside the kernel) encompasses various protocols, firewall, settings, parameters etc. You may wish to take a look at /proc/net for a feel of it. The kernel is responsible for actual communication, it holds inside the settings such as IP number of each interface, its current state and such. Then there are various utilities that are used to setup and configure these settings in the kernel. It goes along the way of conversation like: utility: "Please, could you set the IP for eth0 interface to be 10.0.0.1?" kernel: "Ok, it is set, from now on eth0 operates with this IP." utility: "Please, could you drop any udp packets coming from 1.2.3.4 if they are not a response to an outgoing connection?" kernel: "Ok, the appropriate firewall rule is set up." utility: "Please, could you tell me if wlan0 interface is active and configured?" kernel: "No, the wlan0 interface is not active, but is configured." (I hope you get the idea.) Various utilities are used to set up various aspects of communication. These utilities include ifconfig, ip, iptables, arp, rarp, tc, and so on. These utilities also have appropriate config files which they consult when asking the kernel to do this or that. Some of these config files reside under /etc/sysconfig/network*, while other reside elsewhere (for example, resolv.conf resides in /etc). Now here is the catch. There may be more than one utility to perform the same configuration of network interfaces. These utilities that do equivalent job may have config files that differ or contradict each other. This means that *only one* of those should be used, in order to avoid potential havoc. At this point let me simplify a bit --- there are basically *two* utilities that do this on a Fedora system. One is the script /etc/init.d/network (go take a look at it) which does its job by looking at appropriate config files (those in /etc/sysconfig/network*) and calls some executables (like /sbin/ip) to do the job. Another is the NetworkManager, which has its config files elsewhere and does all on its own or uses other executables (or maybe the same?). Now having, say, two network interfaces on the system, you may choose to configure for example eth0 using the /etc/init.d/network, while wlan0 using NetworkManager. This is ok, as long as you say to *both* of these services to "ignore the other interface". As for /etc/init.d/network, you tell it to ignore wlan0 by starting system-config-network gui and clicking appropriate checkmark, or manually editing a file under /etc/sysconfig/network*. As for NetworkManager I don't know, but guess that there should be some way to tell it to ignore some interface (btw, the system-config-network gui has *absolutely nothing* to do with NetworkManager --- it is merely a gui for the files under /etc/sysconfig/network* which NM doesn't use at all). Given all this, if you configure everything properly, you would want *both* NetworkManager service and network service active under system-config-services. But it is usually easier to configure only one of them for all interfaces and shut down the other, in order to avoid confusion. Which one you would want to use is up to your preference and needs, because the two tools use different paradigms to function and one may be better suited over the other for a particular task. Hence both are included in Fedora. Having all that in mind, you should be aware that there is no daemon to control the network --- the kernel does this, and these utilities merely communicate to the kernel to ask for this or that behavior. This means that you can use one tool (NM) to configure eth0 interface, and then use another (service network status) to ask the kernel for the status of eth0. This is why the sequence # service network stop # service network status gives you the output that seems confusing at first glance. The NetworkManager has configured and activated eth0, so it is active no matter that service network is stopped. Service network is probably configured not to touch eth0 (because it is serviced by NM) so when you say "stop" it doesn't stop eth0, but rather ignores it. This is the action of the appropriate flag somewhere in /etc/sysconfig/network* that you activated using the system-config-network gui. And then you ask for status, and you get the status --- eth0 is still active. That is, the hardware is configured in the kernel to be active, regardless of the utility that asked for this configuration to take place. Given two different utilities that can do equivalent job means you have to take care that they do not contradict each other when talking to the kernel. If you are an ignorant user with a laptop moving around networks, you may just want to let NM do the work and shut down network service. If you are an administrator configuring a 24/7 server and know what you are doing, you would probably turn off NM and configure network service. Or if you really know what you are doing, you may be careful and configure both services properly and keep them both up. Or you may have a standalone machine with no network access, and turn them both down. Fedora is all about having enough choices for various preferences. :-) I hope things are a bit clearer now. I also hope that I got all this right and did not say something extremely stupid. This is simply the way I see and understand the internal workings of the network, so the whole story may not be entirely correct, but works for me. ;-) Best, :-) Marko -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
