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

‘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

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 &amp;&gt;/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 &gt; /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.


Get every new post delivered to your Inbox.

Join 54 other followers