More on NetworkManager creating a new connection ‘eth0′ that does not work

In a previous post I described a problem I have been experiencing with NetworkManager since Version (I am now using Version 1.0.0): sometimes, but not always, there is an invalid second eth0 connection when my laptop boots. This invalid second eth0 connection has only IPv6 Link-Local enabled (i.e. IPv4 and IPv6 are disabled) and is Active. As a result the existing eth0 connection for IPv4 I previously created is Available but unable to connect.

While on a work trip and using my laptop on an office network and an hotel network I made some changes to my installation (see the above-mentioned previous post) that seemed to fix this problem on those networks. However, on returning home and connecting my laptop to my home network, I found the problem still exists. This makes me wonder if a race condition is occurring, as network latency can differ between networks. Could it be that my home network takes longer to assign an IPv4 address than the office and hotel networks I used, which results in NetworkManager creating a second eth0 connection with IPv4 and IPv6 disabled? Or perhaps there is a race condition between services but network latency has nothing to do with it. In retrospect, I should have checked the contents of the log file /var/log/messages while on my work trip to see if those networks were providing my laptop with an IPv6 address in addition to an IPv4 address, i.e. check if the IPv6 address was not just a Link-Local address.

But why is NetworkManager creating any additional connection at all when NetworkManager.conf in my installation currently contains ‘no-auto-default=eth0‘? Surely this must be a bug in NetworkManager?

I have found virtually no mention of this behaviour on the Web. Debian bug report no. 755202 appears to describe the same problem. I started experiencing the problem in Gentoo Linux (~amd64 installation using OpenRC) after I upgraded NetworkManager to Version too, and it has continued occurring up to the current version of NetworkManager (1.0.0). Fellow Gentoo Linux user Keivan Moradi’s fix (Message #79 in the aforementioned Debian bug report) did not cure the problem for me, and, anyway, my wired NIC uses a different driver (atl1c module) which appears to be stable in my installation.

CentOS bug report no. 0007435 also appears to report the same behaviour, but I’m not sure.

NetworkManager usually (but not always) creates an invalid second eth0 connection when my laptop boots and an Ethernet cable is connected to my home network. The second eth0 connection is shown as Active in plasma-nm (the KDE front-end for NetworkManager) but only has an IPv6 Link-Local connection configured (i.e. IPv4 is shown as Disabled). If I click on Disconnect in plasma-nm then this ‘rogue’ eth0 connection disappears from plasma-nm. Once the invalid IPv6 Link-Local connection has been disconnected, the valid IPv4 eth0 available connection can connect to the network and access the Internet.

I examined /var/log/messages when the invalid second eth0 connection occurs and when it doesn’t, and the invalid eth0 connection only seems to occur when NetworkManager appears to have first started earlier than syslog-ng began logging. When NetworkManager first starts after syslog-ng began logging, I can see it launches dhcpcd and acquires an IPv4 address. avahi-daemon does not seem to be the cause of the problem if I understand the log file correctly. Anyway, my experiments described below seem to exonerate the Avahi daemon. I could be misinterpreting what is going on, but that’s how it looks to my inexpert eyes. In Debian bug report no. 755202 some commenters refer to extra interfaces with names such as ‘eth0:avahi’ being listed by the ifconfig command when the problem occurs, but I wonder if that is just a side effect. Anyway, the ifconfig command does not list such interfaces in my case.

I tried the following experiments:

1. I commented out the entire contents of the file /etc/conf.d/net (the configuration file for initscripts /etc/init.d/net.*) — which I think is analogous to Debian’s /etc/network/interfaces file — but it did not stop the invalid second eth0 connection occurring.

2. I added ‘use-ipv6=no‘ and, later, ‘use-ipv4=no‘ in the file /etc/avahi/avahi-daemon.conf but they did not stop the invalid second eth0 connection occurring.

3. I added ‘deny-interfaces=eth0‘ in the file /etc/avahi/avahi-daemon.conf but it did not stop the invalid second eth0 connection occurring.

4. In my installation, the ‘local‘ service (launched by initscript /etc/init.d/local) has always been allocated to two runlevels: ‘default‘ and ‘nonetwork‘. I de-allocated the ‘local‘ service from the ‘nonetwork‘ runlevel but this did not stop the invalid second eth0 connection occurring.

5. In my installation, the ‘net.lo‘ service (launched by initscript /etc/init.d/net.lo) has always been allocated to the ‘boot‘ runlevel (the other net.* services, such as ‘net.eth0‘ and ‘net.wlan0‘, have never been allocated to a runlevel in my installation). I de-allocated ‘net.lo‘ from the ‘boot‘ runlevel but it did not stop the invalid eth0 connection occurring.

As experiments 4 and 5 did not stop the laptop accessing the Internet once I had deleted the invalid second eth0 connection, I have left the ‘local‘ service in the ‘default‘ runlevel only, and I have left the ‘net.lo‘ service unallocated to a runlevel.

6. Since the invalid eth0 connection is allocated an IPv6 Link-Local address rather than an IPv4 address on my home network, I tried a work-around: I disabled IPv6 system-wide by un-commenting the line ‘alias net-pf-10 off‘ in the file /etc/modprobe.d/aliases.conf. Now a second eth0 connection is no longer created, and the valid eth0 IPv4 connection I created previously connects automatically. I have not rebooted many times yet, so I don’t know if this work-around has eliminated the problem for good, but it looks promising.

Nevertheless I would like to find the root cause of the problem, rather than settling for a work-around of disabling IPv6 system-wide. Given that, when IPv6 is enabled, a second eth0 connection is sometimes not created and the ‘good’ IPv4 eth0 connection I created previously can connect, hopefully it should be possible somehow to have both IPv6 and IPv4 enabled system-wide without an invalid eth0 connection ever being created. Could NetworkManager be modified so that it does not create a connection if the DHCP client launched by NetworkManager does not obtain an IP address, for example?

This is not the end of the story, I’m sure.

For information, the services currently used are shown below:

meshedgedx fitzcarraldo # rc-status --all
Runlevel: nonetwork
Runlevel: shutdown
 killprocs                               [  stopped  ]
 savecache                               [  stopped  ]
 mount-ro                                [  stopped  ]
Runlevel: sysinit
 devfs                                   [  started  ]                            [  started  ]
 sysfs                                   [  started  ]
 dmesg                                   [  started  ]
 udev                                    [  started  ]
Runlevel: boot
 hwclock                                 [  started  ]
 modules                                 [  started  ]
 device-mapper                           [  started  ]
 fsck                                    [  started  ]
 root                                    [  started  ]
 mtab                                    [  started  ]
 localmount                              [  started  ]
 sysctl                                  [  started  ]
 bootmisc                                [  started  ]
 termencoding                            [  started  ]
 keymaps                                 [  started  ]
 swapfiles                               [  started  ]
 ufw                                     [  started  ]
 procfs                                  [  started  ]
 dbus                                    [  started  ]
 tmpfiles.setup                          [  started  ]
 serial                                  [  started  ]
 hostname                                [  started  ]
 consolekit                              [  started  ]
 consolefont                             [  started  ]
 xdm                                     [  started  ]
 loopback                                [  started  ]
Runlevel: single
Runlevel: default
 swap                                    [  started  ]
 bluetooth                               [  started  ]
 syslog-ng                               [  started  ]
 sshd                                    [  started  ]
 fbcondecor                              [  started  ]
 atd                                     [  started  ]
 NetworkManager                          [  started  ]
 avahi-daemon                            [  started  ]
 cupsd                                   [  started  ]
 mdadm                                   [  started  ]
 acpid                                   [  started  ]
 nfsclient                               [  started  ]
 netmount                                [  started  ]
 alsasound                               [  started  ]
 laptop_mode                             [  started  ]
 cups-browsed                            [  started  ]
 hddtemp                                 [  started  ]
 mysql                                   [  started  ]
 nfs                                     [  started  ]
 samba                                   [  started  ]
 urandom                                 [  started  ]
 vixie-cron                              [  started  ]
 local                                   [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 rpcbind                                 [  started  ]
 rpc.statd                               [  started  ]
 rpc.pipefs                              [  started  ]
 rpc.idmapd                              [  started  ]
 xdm-setup                               [  started  ]
Dynamic Runlevel: manual
meshedgedx fitzcarraldo #

The allocations of services to runlevels are shown below:

meshedgedx fitzcarraldo # rc-update show -v
           NetworkManager |      default
 NetworkManagerDispatcher |
                    acpid |      default
                alsasound |      default
                  apache2 |
                      atd |      default
               atieventsd |
             avahi-daemon |      default
           avahi-dnsconfd |
                bluetooth |      default
                 bootmisc | boot
                   brltty |
             busybox-ntpd |
         busybox-watchdog |
                 cgconfig |
                    cgred |
                  cgroups |
                    clamd |
              consolefont | boot
               consolekit | boot
          courier-authlib |
                 cpupower |
             cups-browsed |      default
                    cupsd |      default
                     dbus | boot
                  deluged |
                    devfs |                                        sysinit
            device-mapper | boot
                      dgc |
                   dhcpcd |
                  dmcrypt |
                    dmesg |                                        sysinit
                 dmeventd |
                  dropbox |
                    eposd |
               fancontrol |
               fbcondecor |      default
                     fsck | boot
                     fuse |
               git-daemon |
                 gkrellmd |
                      gpm |
                     gpsd |
                  hddtemp |      default
                   hdparm |
          heimdal-kadmind |
              heimdal-kcm |
              heimdal-kdc |
         heimdal-kpasswdd |
                 hostname | boot
                   hsqldb |
                  hwclock | boot
                ip6tables |
                 iptables |
                   irexec |
                  keymaps | boot
                killprocs |                        shutdown
        kmod-static-nodes |
              laptop_mode |      default
                    lircd |
                   lircmd |
               lm_sensors |
                    local |      default
               localmount | boot
                 loopback | boot
                      lvm |
           lvm-monitoring |
                  lvmetad |
                    mdadm |      default
                   mdraid |
            microcode_ctl |
                  modules | boot
                 mount-ro |                        shutdown
                     mtab | boot
                multipath |
               multipathd |
                    mysql |      default
                      nas |
                 net.ath0 |
                 net.ath1 |
                 net.ath2 |
                 net.ath3 |
                 net.ath4 |
                 net.eth0 |
                 net.eth1 |
                 net.eth2 |
                 net.eth3 |
                 net.eth4 |
                 net.eth5 |
                 net.eth6 |
                 net.eth7 |
                 net.eth8 |
                   net.lo |
                 net.ppp0 |
                 net.ppp1 |
                 net.ppp2 |
                 net.ppp3 |
                  net.ra0 |
                  net.ra1 |
                  net.ra2 |
                  net.ra3 |
                  net.ra4 |
                  net.ra5 |
                net.wlan0 |
                net.wlan1 |
                net.wlan2 |
                net.wlan3 |
                 netmount |      default
                      nfs |      default
                nfsclient |      default
                 nfsmount |
               ntp-client |
  ntp-client.bak.20141013 |
                     ntpd |
                  numlock |
                  pciparm |
                  pktcdvd |
                   polipo |
                   procfs | boot
                  pwcheck |
                pydoc-2.7 |
                pydoc-3.2 |
                pydoc-3.3 |
                pydoc-3.4 |
              rename_ethX |
                   rfcomm |
                     root | boot
               rpc.idmapd |
               rpc.pipefs |
                rpc.statd |
                  rpcbind |
                rrdcached |
                   rsyncd |
                    samba |      default
                    saned |
                saslauthd |
                savecache |                        shutdown
                   serial | boot
                     slpd |
                   smartd |
                    snmpd |
                snmptrapd |
                     sntp |
                     sshd |      default
                 svnserve |
                     swap |      default
                swapfiles | boot
                  swclock |
                   sysctl | boot
                    sysfs |                                        sysinit
                syslog-ng |      default
    system-tools-backends |
             termencoding | boot
                 timidity |
    |                                        sysinit
           tmpfiles.setup | boot
                      tor |
                   twistd |
                     udev |                                        sysinit
                      ufw | boot
                  urandom |      default
               vboxwebsrv |
               vixie-cron |      default
                     vpnc |
           wpa_supplicant |
                      xdm | boot
                xdm-setup |
                   xinetd |
meshedgedx fitzcarraldo #

My installation has the following six runlevels:

meshedgedx fitzcarraldo # ls /etc/runlevels
boot default nonetwork shutdown single sysinit

Using a Samsung Xpress C460FW with Gentoo Linux and Android KitKat for printing and scanning


A work colleague has just received a Samsung Xpress C460FW MFP (laser printer, scanner, copier and fax machine) for small print jobs. It is possible to connect to it via USB, Direct USB, wired network, wireless network, Wi-Fi Direct and NFC; that’s impressive for a MFP that can be purchased for GBP 270 in the UK.

I wanted to use the C460FW to print and scan from my laptop running Gentoo Linux, and also to print and scan from my Samsung Galaxy Note 4 running Android KiKat. It turned out that I was able to do all of those, and it was not difficult to set up.

A technician from the IT Support department had already entered a static IP address, subnet mask and default gateway IP address via the C460FW’s control panel to connect it to the office’s wired network. So my options to connect to this particular C460FW are: the wired network for Linux; Wi-Fi Direct for Linux and Android; NFC for Android.

I had never used Wi-Fi Direct before, but it turned out to be easy in Gentoo Linux on my laptop, and also easy in Android KitKat on my Samsung Galaxy Note 4. I had never used NFC before either, and that also turned out to be easy on my Samsung Galaxy Note 4.

Samsung has a series of videos on YouTube explaining how to use Wi-Fi Direct and NFC for printing, scanning and faxing with the C460FW from a Samsung smartphone; here are links to a few of them:

Samsung Smart Printing – 01 NFC Connect

Samsung Smart Printing – 02 Wi Fi Direct

Samsung Smart Printing – 03 Wi Fi

Samsung Smart Printing – 04 NFC Print

Samsung Smart Printing – 05 NFC Scan

Samsung Smart Printing – 06 NFC Fax

Samsung Smart Printing – 11 Samsung Mobile Print App(Printer Status)



Wired connection

I had installed the package net-print/samsung-unified-linux-driver Version 1.02 from a Portage local overlay back in March 2013 when I needed to print to a different model of Samsung MFP, so I thought I would see if that driver would work with the C460FW. I opened the CUPS Printer Manager in a browser window (http://localhost:631/) to configure my Gentoo installation to print to the device via the wired network. ‘Samsung C460 Series‘ was in the list of discovered network printers in the CUPS Printer Manager, and the driver ‘Samsung C460 Series PS‘ was displayed at the top of the list of models, so it was a piece of cake to set up the printer via CUPS, and I was able to print a test page in no time at all. My colleague uses a laptop running Windows 7, and he had to install the Windows driver from a Samsung CD that came with the C460FW.

Wireless connection

As the IT Support technician had configured the C460FW to print via the office wired network rather than the office wireless network, I decided to configure my laptop to print via Wi-Fi Direct, just to learn about Wi-Fi Direct, really. On the C460FW’s control panel I selected Network > Wireless > Wi-Fi Direct and enabled Wi-Fi Direct. Scrolling through the Wi-Fi Direct entries in the LCD I saw the following information:

Device Name: C460 Series
Network Key: <an 8-digit code>
IP address:

Two new networks were listed under ‘Available connections’ in plasma-nm (the KDE GUI front-end to NetworkManager) on my laptop: ‘DIRECT-HeC460 Series‘ and ‘DIRECT-SqC460 Series‘, both using WPA2-PSK encryption. I used the control panel of the C460FW to print a network configuration report in order to check which of the two SSIDs I should select, and it is ‘DIRECT-HeC460 Series‘ (I found out later that an adjacent room also has a C460FW and its Wi-Fi Direct SSID is ‘DIRECT-SqC460 Series‘). So I selected ‘DIRECT-HeC460 Series‘ and plasma-nm prompted me to enter a network password. I entered the 8-digit key I had found from the C460FW’s LCD panel (it’s also listed in the printed network configuration report), and NetworkManager connected to the printer.

In exactly the same way as I do when setting up any printer in Linux, I launched Firefox, opened the CUPS Printer Manager page, clicked on ‘Administration’ > ‘Add Printer’ and entered the user name ‘root’ and the password in the pop-up window. Again the ‘Add Printer’ page had ‘Samsung C460 Series‘ in the list of discovered network printers, so I just selected it and clicked on ‘Continue’. As I had already set up the printer in CUPS for the wired network connection and given it the name ‘Samsung_C460FW_office‘, I entered the name ‘Samsung_C460FW_office_WiFi_Direct‘ to distinguish it from the wired network entry, entered a Description and Location, and clicked on ‘Continue’. The next page had ‘Samsung C460 Series PS‘ first in the driver list so I selected that, clicked on ‘Add Printer’ and that was it. I was able to print a test page from the CUPS Printer Manager, and the printer is now included the list of printers in Linux applications’ print dialogues.

When I want to print using Wi-Fi Direct the only thing I need to remember to do first is select ‘DIRECT-HeC460 Series‘ in the network GUI on the KDE Panel, so that the connection is active when I click ‘Print’ in whichever application I want to print from.

Given the ease of printing via the wired network and Wi-Fi Direct, I have no doubts that printing would also work had the C460FW been configured for the office wireless network instead of the wired network.

Duplex printing

The only downside to the Samsung Xpress C460FW is that it only supports manual duplex printing. If you specify duplex printing when printing from Windows, Samsung’s Windows driver prints all the odd-numbered pages in reverse order and displays a message in Windows telling you what to do next (turn over the pile of paper and put it back in the paper tray!), but in Linux it’s not difficult to work out what you have to do: you simply have to print all the odd-numbered sides first, turn over the paper, then print all the even-numbered sides. The print dialogue in Linux applications gives you the option to print only odd-numbered pages or only even-numbered pages, so there is no problem. The print dialogue in some Linux applications allows you to print pages in reverse order as well but, if not, you have to reverse the order yourself before printing the even-numbered pages (i.e. put Page 1 face down at the top of the pile then Page 3 face down under it, and so on). It’s not a big deal unless the document has a large number of pages.


As you would expect with devices from the same manufacturer, setting up my Samsung Galaxy Note 4 to print with the Samsung Xpress C460FW via WPS (Wi-Fi Protected Setup) was easy. When I selected ‘Print’ on the Galaxy Note 4, it gave me the option to print via wireless network or Wi-Fi Direct. I chose the latter and, as I had already enabled Wi-Fi Direct on the C460FW’s control panel, the printer name was displayed in the list of available devices. I selected it, a blue LED began flashing on the C460FW’s control panel and the LCD prompted me to press the WPS button (on the left of the control panel). As soon as I pressed that, the C460FW printed the document sent by my Galaxy Note 4. From then onwards, I just needed to select ‘Print’ on the Galaxy Note 4, select the printer from the list of available devices, and the document is printed. When I want to print using Wi-Fi Direct the only thing I need to remember to do first on the Galaxy Note 4 is select ‘DIRECT-HeC460 Series‘ as the Wi-Fi network.


I then decided to try to print using NFC. I placed the Galaxy Note 4, without Wi-Fi enabled and with the Home Screen displayed (not the Lock Screen), on the NFC label on top of the C460FW; Android launched Play Store and prompted me to install Samsung Mobile Print, which I did. Now when I place the Galaxy Note 4 on the NFC label, the Galaxy Note 4 automatically enables Wi-Fi, connects to the C460FW directly and displays the Mobile Print app showing the options Print, Scan and Fax, and a page of icons labelled: Gallery, Camera, Google Drive, E-mail, Web page, Document, Facebook, DropBox, Evernote, OneDrive and Box, as well as a Settings icon to configure the printer (paper size etc.). I am able to select a document, photograph, Web page, etc. on the Galaxy Note 4 and print it. It is also possible to launch the Mobile Print app first and then place the Galaxy Note 4 on the C460FW.

NFC is not entirely trouble-free, though. Sometimes the Galaxy Note 4 displays a ‘Device not found‘ message but I can still print. Sometimes the Galaxy Note 4 displays the message ‘Connecting printer. There was some error while connecting to this device. Check your printer and try again. If NFC Pin was changed then please enter new NFC Pin.‘ and the two devices will not connect. Powering off then on the C460FW solves that. Sometimes the Galaxy Note 4 connects to another wireless network instead of to the C460FW via Wi-Fi Direct and the Samsung Galaxy Note 4 then has to disconnect automatically from the other network. Sometimes the C460FW prompts me to press its WPS button and the Galaxy Note 4 then connects via Wi-Fi Direct but the Mobile Print app then displays the error message ‘Device not found. To troubleshoot please check – C460 Series is powered on. – Wi-Fi direct is enabled on C460 Series. – C460 Series and Mobile are connected to the same network.‘. Again, powering off then on the C460FW solves that. Despite these hiccups, printing via NFC is still handy.



I found out how to get the C460FW scanner working by consulting the third-party Web site The Samsung Unified Linux Driver Repository which someone created to provide .deb packages for the Samsung driver as well as tips on how to get Samsung printers and scanners working in Linux. It turned out to be relatively straightforward to scan, both via the office wired network and via Wi-Fi Direct. I edited the file /etc/sane.d/xerox_mfp.conf and replaced the following:

#Samsung C460 Series
usb 0x04e8 0x3468

with the following in order to use the C460FW to scan via the office wired network:

#Samsung C460 Series
#usb 0x04e8 0x3468
#Wired network static address of this C460FW:

or with the following in order to use the C460FW to scan via Wi-Fi Direct:

#Samsung C460 Series
#usb 0x04e8 0x3468
#Wi-Fi Direct address of this C460FW:

I found the IP addresses from the network configuration report I printed earlier.

I was able to use the two Linux scanning applications I normally use, XSane and gscan2pdf, to scan via the wired network and via Wi-Fi Direct. The resulting scans were very good. Given the ease of scanning via the wired network and Wi-Fi Direct, I have no doubts that scanning would work via a wireless network had the C460FW been configured for the office wireless network instead of the wired network.


To use NFC to scan a document I place the Galaxy Note 4, without Wi-Fi enabled and with the Home Screen displayed (not the Lock Screen), on the NFC label on top of the C460FW. The Galaxy Note 4 enables Wi-Fi, connects automatically to the C460FW directly and launches the Mobile Print app showing the options Print, Scan and Fax. It is also possible to launch the Mobile Print app first and then place the Galaxy Note 4 on the C460FW. In other words, the procedure is exactly the same as when wanting to print via NFC. If I select Scan, the Galaxy Note 4 displays buttons for previewing and scanning. Amongst other things, the app’s Settings menu allows you to select whether you want to save the scanned image as a JPEG, PNG or PDF file. The hiccups mentioned above when printing via NFC also apply to scanning. Nevertheless, scanning from the C460FW to the Samsung Galaxy Note 4 via NFC is still handy.


As I am mainly interested in printing text documents I have only tried to print a few colour photographs on plain copier paper, and they look good. Text in documents looks crisp. Despite the lack of automatic duplex printing the C460FW is an excellent peripheral, especially for the price, although I don’t pay for the consumables so I have no idea of the operating costs. The ease with which I got it printing and scanning in Gentoo Linux (laptop) and Android KitKat (Samsung Galaxy Note 4) means that I would definitely consider purchasing this model for home use.

NetworkManager creates a new connection ‘eth0’ that does not work

Several months ago a new entry ‘eth0’ began appearing under ‘Available connections‘ in the KDE plasma-nm widget (the KDE GUI front-end to NetworkManager) in my Gentoo Linux installation. However, there was already an automatically-created entry ‘Wired connection 1’ for the wired interface. In the plasma-nm GUI I could see that both entries were for the same interface (eth0) and MAC address. My laptop could access the Internet via the connection ‘Wired connection 1’ as usual, but not via the new connection ‘eth0’. And if I deleted ‘eth0’ in the plasma-nm GUI, ‘Wired connection 1’ could not access the Internet until I recreated ‘eth0’ manually.

Apart from the fact that two entries for the same interface is unnecessary, it was annoying because sometimes ‘eth0’ automatically became the active connection instead of ‘Wired connection 1’, despite the fact that only ‘Wired connection 1’ had ‘Automatically connect to this network when it is available’ ticked in the plasma-nm GUI. When this happened, the network icon on the Panel showed an active connection but in fact the laptop could not connect to the Internet. However, the connection did work as expected on the occasions when ‘Wired connection 1’ automatically became the active connection or if I switched manually to ‘Wired connection 1’ via the plasma-nm GUI.

Even more strangely, if I happened to be using WiFi when no Ethernet cable was connected, very occasionally the network icon on the Panel would change from a wireless icon to a wired icon and connection to the Internet would be lost. I would then have to re-select the wireless network in order to reconnect to the Internet.

As my laptop has only one Ethernet port, and as there was previously no ‘eth0’ entry under ‘Available connections‘, initially I thought that the new entry occurred because I had recently installed a new version of udev. I have the parameter net.ifnames=0 in the kernel boot line to stop udev/eudev using the so-called Predictable Network Interface Names, and I have the following udev/eudev rules files relating to networking:

# ls -la /etc/udev/rules.d/*net*
lrwxrwxrwx 1 root root    9 Nov 30 15:25 80-net-setup-link.rules -> /dev/null
# ls -la /lib64/udev/rules.d/*net*
-rw-r--r-- 1 root root  452 Nov  7 09:57 /lib64/udev/rules.d/75-net-description.rules
-rw-r--r-- 1 root root 1734 Jan 28 18:29 /lib64/udev/rules.d/77-mm-huawei-net-port-types.rules
-rw-r--r-- 1 root root  491 Nov  7 09:57 /lib64/udev/rules.d/80-net-name-slot.rules
-rw-r--r-- 1 root root  280 Jan 24 00:41 /lib64/udev/rules.d/90-network.rules

Perhaps udev (well, eudev, as I switched to using eudev after the problem started) did have something to do with the new entry, but I began to suspect that NetworkManager was the culprit. I think the problem first occurred after installing NetworkManager last October, but it remained after I installed NetworkManager 1.0.0, until today when I made the various changes described further on.

I had merged NetworkManager 1.0.0 and preceding versions since with USE flags -dhclient and dhcpcd, i.e. NetworkManager in my installation uses the DHCP client dhcpcd instead of dhclient. (I used to merge NetworkManager to use dhclient but found it did not work with and later versions of NetworkManager.)

The relevant network services running in my installation are as follows, and nothing looks incorrect to me:

# rc-update show | grep -i net
       NetworkManager |      default
                local |      default nonetwork
               net.lo | boot
             netmount |      default
# rc-status | grep -i net
NetworkManager                                                    [ started ]
netmount                                                          [ started ]
# rc-update show | grep dh
# rc-status | grep dh
# rc-update -v show | grep supplicant
wpa_supplicant |
# rc-status | grep supplicant

NetworkManager itself launches the DHCP client, so the installation should not be configured to launch a DHCP client. Indeed the output above shows that no DHCP client service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of a DHCP client are not running (they’re not):

# ps -C NetworkManager
  PID TTY          TIME CMD
 6481 ?        00:00:22 NetworkManager
# ps -C dhcpcd
  PID TTY          TIME CMD
10378 ?        00:00:00 dhcpcd
# ps -C dhclient
  PID TTY          TIME CMD

As far as WiFi is concerned, NetworkManager itself launches wpa_supplicant, so the installation should not be configured to launch wpa_supplicant. Indeed the output from rc-update and rc-status above shows that no wpa_supplicant service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of wpa_supplicant are not running (they’re not):

# ps -C wpa_supplicant
  PID TTY          TIME CMD
 6491 ?        00:00:00 wpa_supplicant

So, as far as I could tell, there was nothing wrong with the non-NetworkManager side of my installation.

I thought the problem might be due to the settings in the file /etc/NetworkManager/NetworkManager.conf, which contained the following:




I studied the manual pages for NetworkManager.conf:

# man NetworkManager.conf

If I understand correctly, the ifnet plug-in is Gentoo-specific (see References 3, 4 and 5 further on). The entries under [ifnet] in my NetworkManager.conf file were redundant in any case because the ifnet plug-in was not included in the plugins list under [main], so I deleted the entire [ifnet] section. There is no mention of the ifnet plug-in on the NetworkManager.conf manual page or in the Gentoo Linux Wiki article on NetworkManager, and a cursory look in the Gentoo ebuild for NetworkManager 1.0.0 clearly indicates the ifnet plug-in is broken. See, for example, the following comment in the ebuild:

# ifnet plugin always disabled until someone volunteers to actively
# maintain and fix it

and the following warning messages in the ebuild if the user has included ifnet in plugin=<plugin list> in NetworkManager.conf:

ewarn "Ifnet plugin is now disabled because of it being unattended"
ewarn "and unmaintained for a long time, leading to some unfixed bugs"
ewarn "and new problems appearing. We will now use upstream 'keyfile'"
ewarn "plugin."
ewarn "Because of this, you will likely need to reconfigure some of"
ewarn "your networks. To do this you can rely on Gnome control center,"
ewarn "nm-connection-editor or nmtui tools for example once updated"
ewarn "NetworkManager version is installed."
ewarn "You seem to use 'ifnet' plugin in ${EROOT}etc/NetworkManager/NetworkManager.conf"
ewarn "Since it won't be used, you will need to stop setting ifnet plugin there."

I modified NetworkManager.conf to contain the following:



Note that the ifnet plug-in was not specified in the plugins list in the [main] section of my previous NetworkManager.conf so it was not the cause of my problem, but I hoped that adding no-auto-default=eth0 to NetworkManager.conf would solve the problem. I deleted the ‘Wired connection 1’ entry from the plasma-nm GUI, ticked ‘Automatically connect to this network when it is available’ for the ‘eth0’ entry and made sure that option was not ticked for any of the other entries under ‘Available connections‘, then rebooted. There was no longer an entry ‘Wired connection 1’ in the plasma-nm widget GUI, just an entry for ‘eth0’, and the installation connected automatically to the wired network and I could access the Internet, but did not reconnect to the wired network if I removed and reinserted the Ethernet cable when also connected to a wireless network. So I was not home and dry yet.

I have read on various Web sites that NetworkManager prefers wired connections over wireless connections. I assume this is because NetworkManager sets a higher metric for the wired connection.

I am on a work trip at the moment and cannot use a dynamic wired connection, only a static wired connection, but I can see that NetworkManager 1.0.0 does set a higher-priority metric for wired connections:

# # Now with both dynamic wireless and static wired:
# ip route show
default via dev eth0  proto static  metric 100
default via dev wlan0  proto static  metric 600 dev eth0  proto kernel  scope link  src  metric 100 dev wlan0  proto kernel  scope link  src dev wlan0  proto kernel  scope link  src  metric 303 dev lo  scope host via dev lo via dev wlan0  proto dhcp  metric 600
# is the IP address of the gateway for the wired connection, and is the IP address of my laptop’s wired interface. The smaller the metric value, the higher the routing priority. Notice that the metric for the eth0 interface is 100 whereas the metric for the wlan0 interface is 600, so it does appear that NetworkManager favours a wired connection over a wireless connection when both are active.

After doing all the above, I came across Debian bug report no. 755202: network-manager: keeps creating and using new connection “eth0” that does not work which appears to be exactly what I was experiencing. Various people posted solutions that worked in their particular circumstances, so I am none the wiser. Gentoo user Keivan Moradi posted message no. 79 on that bug report, about a warning message he found in the NetworkManager log file regarding a file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0, and he then deleted the latter file. I found the same message in /var/log/messages:

# grep networkmanager /var/log/messages
Feb  9 04:10:05 localhost NetworkManager[10355]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing
Feb 11 15:53:05 localhost NetworkManager[13143]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing

The file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 also existed in my installation, so I also deleted it. It was a zero-length file and I do not know if it had anything to do with my problem:

# ls -la /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
-rw------- 1 root root 0 Jan 20 00:09 /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
# rm /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0

Anyway, the file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 has not reappeared since I deleted it.

Keivan Moradi had ‘id=Wired‘ under [connection] in the file /etc/NetworkManager/system-connections/eth0, and he decided to change the name of the file from ‘eth0‘ to ‘Wired‘. However, in my case the file name and the id in the file /etc/NetworkManager/system-connections/eth0 are both ‘eth0‘:

# cat /etc/NetworkManager/system-connections/eth0




I had already deleted and recreated the connection ‘eth0’ in the plasma-nm GUI by the time I checked the contents of the directory /etc/NetworkManager/system-connections/ so I do not know if the original file name and id were the same. I had also already deleted the connection ‘Wired connection 1’ in the plasma-nm GUI by the time I checked the contents of the directory; presumably files for connections ‘Wired connection 1’ and ‘eth0’ both existed in /etc/NetworkManager/system-connections/ before then. I do not know why the zero-length file .keep_net-misc_networkmanager-0 was created, but no further files have appeared in the directory since I deleted the connection ‘Wired connection 1’ and the file .keep_net-misc_networkmanager-0.

Keivan Moradi was also previously using a buggy r8169 kernel module (Realtek Ethernet hardware) and switched to using the r8168 module, but I am using a Qualcomm Atheros AR8131 Gigabit Ethernet card and an Intel Corporation Ultimate N WiFi Link 5300 card, so that part of his problem cannot be a factor in my case.

Anyway, as I wrote earlier, I no longer have two connection entries for the wired interface, and NetworkManager no longer creates automatically a second connection entry for the wired interface. And now if I am already connected to a wireless network, NetworkManager connects/reconnects automatically to a wired network with the ‘Automatically connect’ option ticked. So it looks like my problem is completely solved, although I reserve judgement until I have been able to use the laptop in my home network (which has the same router for both wired and wireless connections, whereas the wired network and wireless network are separate networks in the office in which I am now working).


If you had the patience to read all the above, I am impressed! If you also understood it, I am doubly impressed!

To cut a long story short, if you are experiencing a similar problem to mine, I recommend you do the following:

  1. Check that your network driver is reliable. You can search the Web to see if other users have experienced problems with the same driver you are using.

  2. Make sure the contents of NetworkManager.conf are correct. Read the NetworkManager.conf man page and the GNOME Wiki page on NetworkManager settings to find out what options are available.

  3. Delete all the files (i.e. including hidden files) in the directory /etc/NetworkManager/system-connections/ and recreate your connections via either the NetworkManager GUI (e.g. plasma-nm in KDE or nm-applet in GNOME) or NetworkManager TUI (nmtui).


  1. man NetworkManager.conf
  2. Gentoo Linux Wiki – NetworkManager
  3. GNOME Wiki – NetworkManager SystemSettings – Configuration Plugins
  4. Gentoo NetworkManager Plugin
  5. Another Gentoo Dev – Ifnet updates for NetworkManager 0.9

UPDATE (March 10, 2015): Well, I was right to reserve judgement until I was able to use my laptop with my home network. I am now back at home and an Ethernet cable is plugged into my laptop’s RJ45 socket. Even with the changes I made, when I boot the laptop NetworkManager sometimes (but not always) has two connections named ‘eth0’, one of them the ‘Active connection’ (but not able to connect to the Internet) and the other an ‘Available connection’. In this situation the wired network icon on the Panel has a yellow question mark superimposed. If I delete the ‘eth0’ active connection and use the other ‘eth0’, the latter works as expected and I have no trouble connecting to the Internet. In Debian bug report no. 755202 (see the link further up) user Frederik Himpe added a comment on March 4, 2015 that he is also still experiencing this problem and “It looks like there is a race somewhere, causing the network interface to be brought up before Network Manager is started, and this prevents correct configuration by NM”. So the problem is still unresolved. Hmm … I wonder if udev does have something to do with it after all.

UPDATE (March 12, 2015): The problem persists. I disabled use of IPv6 in /etc/avahi/avahi-daemon.conf to see if the Avahi daemon has something to do with the problem, but that made no difference. Later I also disabled use of IPv4 in /etc/avahi/avahi-daemon.conf, but that made no difference either. So it looks like the Avahi daemon is not the culprit. Checking via the plasma-nm GUI I notice that the ‘rogue’ eth0 Active connection has IPv4 disabled and IPv6 Link-Local enabled. So why is NetworkManager creating a second eth0 connection just for IPv6 Link-Local? And why on Earth is NetworkManager creating any additional connection at all when NetworkManager.conf contains no-auto-default=eth0? Surely this must be a bug in NetworkManager 1.0.0?

UPDATE (March 17, 2015): I have been investigating the problem further: see my latest blog post for details.

‘Server not found’ by browser at launch

I haven’t had any significant Linux problems or new requirements in the last few months, hence no new posts here. My last real problem was back in June 2013 when I rolled my Gentoo installation to latest using Portage and found that, whenever I launched Firefox, it displayed the ‘Server not found’ page and I had to click ‘Try Again’, and then Firefox displayed the expected Web site. From then onwards, Firefox would work as expected until I exited the application. Thunderbird was also unable to access e-mail servers on the first attempt after it was launched. The same thing happened in Sabayon Linux when I rolled to latest using Entropy a couple of days later. Anyway, here is how I fixed the problem in both distributions.

First I used Wireshark to see what was going on, and it transpired that Gentoo (and Sabayon) was sending an IPv4 request followed quickly by an IPv6 request, but the reply to the IPv6 request was being received first and was a ‘server not found’ message since my ISP does not support IPv6 and my router apparently does not handle IPv6 requests correctly. Gentoo (and Sabayon) then used an IPv4 address when I clicked ‘Try Again’ in the browser window, and thereafter Firefox always dispayed the expected Web sites.

I should point out that IPv6 is enabled in the kernels I use and I’ve never before had to disable IPv6 in Firefox (or system-wide) on the affected laptops. So why the change in functionality, I wonder?

With Wireshark capturing packets, when I launched Firefox I was seeing a server failure message indicating “AAAA” (IPv6) instead of “A” (IPv4). To stop this happening I could have chosen any one of the three following solutions:

1. I could have used about:config in Firefox (and Config Editor in Thunderbird) to change the value of network.dns.disableIPv6 to true instead of false.

2. I could have disabled IPv6 system-wide by editing /etc/modprobe.d/aliases.conf and uncommenting the line “alias net-pf-10 off“.

3. I could have forced the getaddrinfo() function in glibc to make the IPv4 and IPv6 requests sequentially rather than in parallel.

Just for the fun of it I chose the third option on a couple of my laptops, and, as they use NetworkManager, this is how I did it:

fitzcarraldo@aspire5536 ~ $ su
aspire5536 fitzcarraldo # cat /etc/resolv.conf
# Generated by resolvconf
domain home
aspire5536 fitzcarraldo # cd /etc/NetworkManager/dispatcher.d/
aspire5536 dispatcher.d # touch 06-dhclientoptions
aspire5536 dispatcher.d # nano 06-dhclientoptions
aspire5536 dispatcher.d # cat 06-dhclientoptions
echo "options single-request" >> /etc/resolv.conf
aspire5536 dispatcher.d # chmod +x /etc/NetworkManager/dispatcher.d/06-dhclientoptions
aspire5536 dispatcher.d # # Now I disconnect then reconnect to the network
aspire5536 dispatcher.d # cat /etc/resolv.conf
# Generated by resolvconf
domain home
options single-request
aspire5536 dispatcher.d #

As you can see above, I added a two-line Bash script 06-dhclientoptions in the directory /etc/NetworkManager/dispatcher.d/ that appends the line “options single-request” (without the quotes) to the contents of the file /etc/resolv.conf. The addition of the line “options single-request” in resolve.conf causes the getaddrinfo() function in glibc to make the IPv4 and IPv6 requests sequentially rather than in parallel. With this change, Firefox and Thunderbird no longer have a problem accessing the Internet the first time they are launched.

From “man 5 resolv.conf” under “options”:

single-request (since glibc 2.10)
sets RES_SNGLKUP in _res.options. By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9. Some appliance DNS servers cannot handle these queries properly and make the requests time out. This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

single-request-reopen (since glibc 2.9)
The resolver uses the same socket for the A and AAAA requests. Some hardware mistakenly sends back only one reply. When that happens the client system will sit and wait for the second reply. Turning this option on changes this behavior so that if two requests from the same port are not handled correctly it will close the socket and open a new one before sending the second request.

I had to use NetworkManagerDispatcher to add the line “options single-request” to /etc/resolv.conf because NetworkManager overwrites /etc/resolv.conf if you edit it manually.

UPDATE (February 4, 2014): As I have recently seen the line “options single-request” occurring more than once in the file /etc/resolv.conf I now recommend /etc/NetworkManager/dispatcher.d/06-dhclientoptions consists of the following:

if grep -q "options single-request" /etc/resolv.conf; then
    echo "options single-request" >> /etc/resolv.conf

Synchronise your Gentoo Linux clock with an Internet time server

There are a number of ways to synchronise Gentoo Linux with a time server on the Internet. Here I look at a few alternatives.


ntp-client and the NTP daemon ntpd are installed when you install the package net-misc/ntp. Although I have read on some Web sites that /etc/init.d/ntp-client should be added to the default runlevel in order to read the time from an NTP server (once-only, during start-up), this in fact does not work because usually the network connection is not up by the time the ntp-client initscript runs. Bear in mind that ntp-client does not run continuously; it syncs once with an external time server if there is a network connection, and that’s it.

NetworkManager Dispatcher

If you are using NetworkManager, an elegant solution is to use NetworkManagerDispatcher to restart ntp-client in order to resync your system clock every time a network connection comes up. This is my favoured solution for laptops; see further on for how to configure your machine to do this.


Another way would be to create a cronjob to run periodically the ‘/etc/init.d/ntp-client restart‘ command or the ‘ntpd -q‘ command (the -q option means “set the time and quit”).

Wait a while after start up

A ‘quick-and-dirty’ method, which I have used sometimes to synchronise a laptop’s system clock every time it boots, would be to delay running ntp-client until the network is up by putting e.g. the command below in a file 10_ntp-client.start in the directory /etc/local.d/ (10 seconds is usually enough time for a wired or wireless connection to my home network to be established):

sleep 10s && /etc/init.d/ntp-client restart

Don’t forget to make it executable:

# chmod 744 /etc/local.d/10_ntp-client.start

NTP daemon

Regarding the NTP daemon, it is possible to configure this from the command line, rather than via a Desktop Environment GUI, to run at start-up and continue running to adjust your system clock. The command:

# rc-update add ntpd default

will add the daemon’s initscript to the default runlevel so that it is launched automatically at the next startup, and the command:

# /etc/init.d/ntpd start

will start the daemon running right now.

Note that, by default, the NTP daemon won’t correct, all in one go, a time difference between your system clock and the remote NTP server if that difference is above a certain size. However, if you want to override the default behaviour, i.e. allow the NTP daemon to make a large first adjustment to the system clock, you can set the environment variable NTPD_OPTS in the file /etc/conf.d/ntpd as follows:

# The -g option enables ntpd to make large adjustments.

This would mean that you would not need to run ntp-client before ntpd. However, if you run ntp-client automatically — either once after start-up or periodically — then that would be good enough for the typical Desktop user, and could be an alternative to having a continuously-running NTP daemon. Nothing stops you doing both if you want, of course.

Updating the hardware clock

If you make clock_systohc="YES" in the file /etc/conf.d/hwclock then the time in the system clock will be written to the BIOS (CMOS) clock (a.k.a. hardware clock) when you shut down your PC.

How to configure NetworkManager Dispatcher to synchronise the system clock only when a network connection is made

If you’re using a machine that is permanently connected to a network, running the NTP daemon makes sense. But what if you have a machine that is not always connected to a network when it is powered up? I have a laptop and I don’t want the NTP daemon running all the time. But I would like my laptop to synchronise with an external time server once after start up when I connect to the Internet. NetworkManager has a handy tool called NetworkManager Dispatcher for doing just this.

If you have installed NetworkManager, you’ll find there is an initscript /usr/portage/net-misc/networkmanager/files/NetworkManagerDispatcher. Copy it to the directory /etc/init.d/ and give it the necessary restrictive permissions:

# cp /usr/portage/net-misc/networkmanager/files/NetworkManagerDispatcher /etc/init.d/
# chmod 744 NetworkManagerDispatcher

You no longer need to perform the above step regarding a NetworkManagerDispatcher initscript. See my update of September 23, 2014 at the bottom of this post.

Then create a shell script called e.g. 99_ntp-client in the directory /etc/NetworkManager/dispatcher.d/ to be run by NetworkManagerDispatcher when a network connection is established, containing the following code:


INTERFACE=$1 # The interface which is brought up or down
STATUS=$2 # The new state of the interface

case "$STATUS" in
    'up') # $INTERFACE is up
        echo "System time before starting ntp-client:" > /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
        echo "Starting ntp-client:" >> /home/fitzcarraldo/ntp-client.txt
        rc-config restart ntp-client &>> /home/fitzcarraldo/ntp-client.txt
        echo "System time after starting ntp-client:" >> /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
    'down') # $INTERFACE is down
        # Check for active interface and down if no one active
        if [ ! `nm-tool|grep State|cut -f2 -d' '` = "connected" ]; then
            echo "Stopping ntp-client at:" > /home/fitzcarraldo/ntp-client.txt
            date >> /home/fitzcarraldo/ntp-client.txt
            rc-config stop ntp-client &>> /home/fitzcarraldo/ntp-client.txt

The nm-tool command no longer exists, so use the nmcli command instead in the script. See further down for a new version of the script.

Make the root user the owner of the script, and only allow the root user to write to it and execute it:

# cd /etc/NetworkManager/dispatcher.d/
# chown root:root 99_ntp-client
# chmod 744 99_ntp-client

Then add NetworkManagerDispatcher to the default runlevel so that it will be launched every time you boot your machine:

# rc-update add NetworkManagerDispatcher default

You no longer need to perform the above step regarding a NetworkManagerDispatcher initscript. See my update of September 23, 2014 at the bottom of this post.

As the package net-misc/ntp installs both /etc/init.d/ntpd and /etc/init.d/net-client, users could optionally add the NTP daemon ntpd to the default runlevel too if desired, which would provide continuous, incremental adjustments to the system clock once net-client has done its one-shot adjustment each time a network comes up:

# rc-update add ntpd default

But users who don’t leave their PCs on for days on end — or who use laptops — can ignore the above step and just stick with the NetworkManagerDispatcher and net-client solution, whereas users who leave their machines on for days or weeks on end can also use the NTP daemon to keep the system clock in sync in between the times when ntp-client has synchronised.

Don’t forget to delete ntp-client from the start-up level if you are using NetworkManagerDispatcher to run it:

# rc-update del ntp-client

Notice that the script /etc/NetworkManager/dispatcher.d/99_ntp-client logs some information in a text file ntp-client.txt in my home directory which I can check. Here is an example of what ntp-client.txt contains after I select a network (or it is selected automatically) following start up of my laptop:

System time before starting ntp-client:
Sun Jun 3 19:24:08 BST 2012
Starting ntp-client:
Restarting init script
* Setting clock via the NTP client 'ntpd' ...ntpd: time slew +0.067178s
[ ok ]
System time after starting ntp-client:
Sun Jun 3 19:24:17 BST 2012

As you can see above, the ntpd command was executed once by NetworkManagerDispatcher and made a small adjustment to the system time on my laptop.

Replacing ntpdate with ntpd in ntp-client

Just for the fun of it, I changed /etc/conf.d/ntp-client to use the command ntpd instead of ntpdate, even though the ntpdate command works fine. Anyway, here’s my /etc/conf.d/ntp-client file these days:


I have added the -g option so that the ntpd command can make large adjustments to the system time if it is way off the actual time. This is useful at the beginning and end of Daylight Saving Time, or if you dual boot with Windows. Here is an example of the former when I powered up my laptop the morning after the clocks changed from BST to GMT at the end of Summer 2010:

$ cat /home/fitzcarraldo/ntp-client.txt
System time before starting ntp-client:
Sun Oct 31 09:37:23 GMT 2010
Starting ntp-client:
Starting init script
* Setting clock via the NTP client 'ntpd'...ntpd: time set -3600.122381s
[ ok ]
System time after starting ntp-client:
Sun Oct 31 08:37:30 GMT 2010

You can specify the NTP server or NTP server pool in the file /etc/ntp.conf, but the default server pool already specified in that file should work. Note again that, when ntpd is run with the -q option, it synchronises the system clock once and terminates, i.e. it is not running as a daemon.

UPDATE (September 23, 2014): Things have become easier since I wrote the above post. These days it is no longer necessary to create a NetworkManagerDispatcher initscript; you just need to put the shell script you want NetworkManagerDispatcher to execute into the directory /etc/NetworkManager/dispatcher.d/, give it attributes and permissions as shown in this post, and NetworkManager will take care of everything.

UPDATE (October 1, 2019): The nm-tool command no longer exists, so use the nmcli command instead in the script. The new version is shown below.


INTERFACE=$1 # The interface which is brought up or down
STATUS=$2 # The new state of the interface

case "$STATUS" in
    'up') # $INTERFACE is up
        echo "----------" > /home/fitzcarraldo/ntp-client.txt
        echo "Interface $INTERFACE" >> /home/fitzcarraldo/ntp-client.txt
        echo -n "System time before starting ntp-client: " >> /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
        echo "Starting ntp-client:" >> /home/fitzcarraldo/ntp-client.txt
        rc-config restart ntp-client &>> /home/fitzcarraldo/ntp-client.txt
        echo -n "System time after starting ntp-client: " >> /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
        echo "----------" >> /home/fitzcarraldo/ntp-client.txt
    'down') # $INTERFACE is down
        # Check for active interface and down if no one active
        if [ `nmcli c | grep -v "\-\-" | grep -v "NAME.*UUID.*TYPE.*DEVICE" | wc -l` -eq 0 ]; then
            echo "----------" > /home/fitzcarraldo/ntp-client.txt
            echo "Interface $INTERFACE" >> /home/fitzcarraldo/ntp-client.txt
            echo -n "Stopping ntp-client at: " >> /home/fitzcarraldo/ntp-client.txt
            date >> /home/fitzcarraldo/ntp-client.txt
            rc-config stop ntp-client &>> /home/fitzcarraldo/ntp-client.txt
            echo "----------" >> /home/fitzcarraldo/ntp-client.txt

A fast and easy-to-use scanner of IP addresses and ports

This week I’m working in offices with a local network that uses static IP addressing. Believe it or not, it seems the IT department does not keep a list of configured IP addresses, and sometimes inadvertently configure devices to have the same IP address.

A couple of days ago I was printing quite happily to a networked printer from my laptop in the morning but, when I got back from lunch, found that I couldn’t print any more. It transpired that someone had allocated the IP address of my laptop to a new plotter in my absence. What to do if the organisation has no central list of configured IP addresses? There are too many devices on the local network to check them manually, and I do not have access to them anyway.

So I installed Angry IP Scanner (a.k.a. ipscan), an easy-to-use scanner of IP addresses and ports, and use it to find an IP address that is currently unused on the network.

I wanted to install ipscan by using Gentoo’s package manager Portage. There is no ebuild for it in the Portage main tree, but a quick search of the Web told me that there is an ebuild in a third-party overlay ( Rather than add an external overlay, I decided to install the package using a local overlay:

1. I downloaded the ebuild:

# wget --output-document=/home/fitzcarraldo/Desktop/ipscan-3.0_beta4.ebuild

The ebuild contents are as follows:

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $


inherit java-pkg-2

DESCRIPTION="Angry IP - The fast and friendly network scanner"

SRC_URI="amd64? ( ${SRC_BASE}/${PN}-linux64-${MY_PV}.jar )
        x86? ( ${SRC_BASE}/${PN}-linux-${MY_PV}.jar )"

KEYWORDS="~amd64 ~x86"




src_unpack() {

src_install() {
        local jarname
        use amd64 && jarname="${PN}-linux64-${MY_PV}.jar"
        use x86 && jarname="${PN}-linux-${MY_PV}.jar"
        java-pkg_jarinto "${INSTALL_DIR}"
        java-pkg_newjar "${DISTDIR}/${jarname}"

2. I synchronised the Portage main tree’s ebuilds on my PC with those in the repositories:

# emerge --sync

3. I made sure that /etc/make.conf has the following lines at the end of the file:

PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/"

4. I created the required directories in the local overlay:

# mkdir -p /usr/local/portage/net-analyzer/ipscan

5. I made sure Portage would not nag me about a missing name for my local overlay:

# mkdir /usr/local/portage/profiles
# echo "local_overlay" > /usr/local/portage/profiles/repo_name

6. I copied the ipscan ebuild into the relevant directory in the local overlay:

# cd /usr/local/portage/net-analyzer/ipscan
# cp /home/fitzcarraldo/Desktop/ipscan-3.0_beta4.ebuild .

7. I generated the manifest for the package:

# ebuild ipscan-3.0_beta4.ebuild manifest

8. I merged the package:

# emerge -1v ipscan

9. I downloaded a 64×64 pixel PNG image of the Angry IP Scanner logo from Then I right-clicked on Kickoff, selected Menu Editor and added an entry for Angry IP Scanner under Applications | System, although I can also launch ipscan from the command line if I want:

$ ipscan

To find an unused IP address on the local network which I can allocate to my laptop whilst I’m working in this office, I launch ipscan and enter the start and end IP addresses of the range I wish to check, and click on Start. The application quickly searches through the IP addresses in that range and lists which are in use and which are not. It’s as simple as that. I then use Network Management to edit the connection and enter the static IP address.

Note that Angry IP Scanner will not detect a live IP address if the device is behind a properly-configured firewall. See the Angry IP Scanner Web site’s FAQ and Documentation pages for further details.

Why can’t I access a specific Web site?

Is there one specific Web site that you can never access? That always causes your Web browser to stall when you click on a link to that site or enter the site’s URL in the browser’s address bar? Perhaps it’s an Internet banking site? You don’t have trouble with other sites, just this one particular site or perhaps just a couple of sites?

The chances are that this problem is caused by what is called a ‘black hole’ router somewhere between you and that site. For the technical explanation of a black hole router, see e.g. the article Black Hole (networking).

I experienced this precise problem a couple of days ago with the popular Web site IMDb. The old Gateway Solo 9300 laptop I was using has no built-in networking hardware so I use a couple of CardBus cards for wireless and wired network access. The Linksys WPC54G (EU) v7.1 wireless notebook adapter works fine but, irrespective of the Web browser, I could not access the IMDb Web site; the browser always stalled when trying to load the site. I discovered I also had the same problem with my bank’s Web site.

I could ping other sites by IP address and by domain name, but pinging the IMDb site never received a reply (and it still doesn’t, even after the fix explained below which allows browsing of the site).

I also experienced this problem several years ago under Windows XP when trying to access the Amazon UK Web site, using an MTU that I had incorrectly set to a value smaller than possible. The problem this time was due to a correctly-set MTU. In both cases, the two MTUs are smaller than a router somewhere en route to those sites wanted to handle.


Bear with me while I explain how the problem arose, as it’s relevant (and useful) information.

I had just installed Sabayon Linux on the laptop and got the wireless network connection up, and the first thing I then did was to launch Firefox. With an MTU of 1500 for wlan0, Firefox would only load Google (and that, only intermittently). All other sites would stall. So I used the following command iteratively in order to find the MTU for this hardware, which is 1464 (the maximum packet size in bytes that does not fragment + 28 bytes):

# ping -M do -s packet_size_in_bytes


# ping -M do -s 1472

I just varied the packet size in the ping command until “Frag needed and DF set” was not displayed.

I can reduce the MTU to 1464 as follows:

# ifconfig wlan0 mtu 1464

I could make this permanent by adding an entry (mtu_wlan0=”1464″) to the file /etc/conf.d/net, but I chose instead to make it permanent by adding the above ifconfig command to the file /etc/conf.d/local. This (correct) MTU works fine for all sites I have visited so far except for two, which just stall the browser: IMDb and my bank’s Web site.

I also have a Belkin F5D5010 CardBus Network Card (wired Ethernet) for the laptop. It works fine with an MTU of 1500, and there is no problem accessing the IMDb Web site in Firefox. So, apparently, the MTU is the problem when using the wireless network connection. Now let’s look at the solution…


Well, in the case of Windows it is possible to edit the Registry to solve the problem of network ‘black holes’. But what do you do in the case of Linux? It turns out that the kernel /proc file system provides an easy way to enable and disable TCP MTU Probing by changing a value in the ‘file’ /proc/sys/net/ipv4/tcp_mtu_probing. A value of 0 = disabled; 1 = enabled when a black hole router is detected; 2 = always enabled.

This is what my laptop had in that ‘file’:

# cat /proc/sys/net/ipv4/tcp_mtu_probing

So all I needed to do was:

# echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

and, bingo, a browser can access IMDb and my bank’s Web site without a problem. To make it permanent, I just added the above command to the file /etc/conf.d/local so that it is executed every time I boot the laptop. Here is what my file /etc/conf.d/local looks like now:

# Here is where you can put anything you need to start
# that there is not an init script for.

local_start() {
# This is a good place to load any misc programs
# on startup (use &>/dev/null to hide output)

# The Linksys CardBus card does not work with a MTU greater than 1464:
ifconfig wlan0 mtu 1464
# Enable TCP MTU Probing in order to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

# We should always return 0
return 0

local_stop() {
# This is a good place to unload any misc.
# programs you started above.

# We should always return 0
return 0

UPDATE (May 13, 2011): OpenRC 0.8.0 and later in Gentoo and Sabayon Linux no longer use the file /etc/conf.d/local but instead require the commands to be in files in the directory /etc/local.d/. So I created a file /etc/local.d/01network.start containing the following lines:

# The Linksys CardBus card does not work with MTU greater than 1464:
ifconfig wlan0 mtu 1464
# Enable TCP MTU probing to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

and made it executable:

# chmod +x /etc/local.d/01network.start

UPDATE (April 11, 2012): If “echo 2” does not solve the problem, try “echo 1” instead. The possible values are:

0   Do not perform PLPMTUD (Packetization Layer Path MTU Discovery)
1   Perform PLPMTUD only after detecting a ‘blackhole’.
2   Always perform PLPMTUD.