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 0.9.10.0 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 0.9.8.8 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 0.9.8.8 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:

[main]
plugins=keyfile
dhcp=dhcpcd

[ifnet]
managed=true
auto_refresh=false

[keyfile]
hostname=meshedgedx

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:

[main]
plugins=keyfile
dhcp=dhcpcd
no-auto-default=eth0

[keyfile]
hostname=meshedgedx

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 10.90.21.1 dev eth0  proto static  metric 100
default via 10.96.0.1 dev wlan0  proto static  metric 600
10.90.21.0/24 dev eth0  proto kernel  scope link  src 10.90.21.112  metric 100
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86  metric 303
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
192.0.2.1 via 10.96.0.1 dev wlan0  proto dhcp  metric 600
#

10.90.21.1 is the IP address of the gateway for the wired connection, and 10.90.21.112 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
[ethernet]
mac-address=70:5A:B6:3E:C1:8A
mac-address-blacklist=

[connection]
id=eth0
uuid=cb3d5786-f947-44b8-92f7-8471fc94c568
type=ethernet
permissions=
secondaries=

[ipv6]
method=ignore
dns-search=

[ipv4]
method=auto
dns-search=

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).

Conclusion

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).

References

  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

Preventing a DNS Leak and WebRTC Leak when using Tor in Linux

Background

I have added to my 2011 Tor post a note on how to avoid a DNS Leak and WebRTC Leak, but am repeating it here in a new post, along with a Bash script that can be used to toggle the relevant Firefox user preferences before and after using Firefox with Tor, which makes the process easier.

The original eleven steps I gave in my above-mentioned post will not prevent the so-called DNS Leak problem. If your Web browser is not configured correctly it will still use your ISP’s DNS servers instead of the DNS servers favoured by Tor, in which case your ISP will know which sites you are accessing. See What is a DNS leak? for details. Reference 1 at the end of this post is a link to an article about DNS leakage, and Reference 2 is a link to an article on the Tor Browser, a browser designed to help avoid DNS leakage.

Furthermore, now that WebRTC is incorporated in some browsers, a ‘WebRTC Leak‘ is also possible if you have not configured your browser correctly.

Using the Tor Browser

Instead of performing Steps 1 to 11 in my original Tor post, download the Tor Browser, unpack it (no installation is required) and use that browser. Reference 3 below is a link to the download page, and Reference 4 below is a link to the instructions on how to unpack the tarball and launch the browser.

If you want even more security, you could instead download the ISO for the Tails Linux distribution, burn a LiveDVD or LivePenDrive — see my post Help for Windows users: How to create a Linux LiveCD, LiveDVD or LivePenDrive from an ISO file if you don’t know how to do that — and launch the browser from a Live Environment.

Using Tor with Firefox

However, if you still want to use the method I gave in my original Tor post then you could try all the additional steps given below to stop DNS leakage and WebRTC leakage.

  1. Use the OpenDNS servers instead of your ISP’s DNS servers. That will not help, though, if your ISP is using a Transparent DNS Proxy.
  2. Make the following changes to the preferences in Firefox (enter about:config in the Firefox address bar):
    Preference Name                       Status   Type     Value
    network.dns.disableIPv6               default  boolean  false  Change to true
    network.dns.disablePrefetch           default  boolean  false  Change to true
    network.proxy.socks_remote_dns        default  boolean  false  Change to true
    browser.safebrowsing.enabled          default  boolean  true   Change to false
    browser.safebrowsing.malware.enabled  default  boolean  true   Change to false
    media.peerconnection.enabled          default  boolean  true   Change to false
    

    (When you have finished using Tor, set media.peerconnection.enabled back to true if you want to use WebRTC. If you also want Firefox to warn you of phishing Web sites and Web sites that download malware, also set browser.safebrowsing.enabled and browser.safebrowsing.enabled back to true after you have finished using Tor.)

    You may be wondering why I disable IPv6 DNS requests. It is because some IPv6-capable DNS servers may return an IPv4 address when an IPv6 address is requested. I disable the two ‘safe browsing’ preferences because, if enabled, they cause Firefox to compare visited URLs against a remotely-stored blacklist or submit URLs to a third party to determine whether a site is legitimate, and I don’t want the possibility of Firefox contacting other sites outside Tor or trying to find an IP address for a URL. The PeerConnection preference relates to WebRTC, and I disable that to stop Firefox contacting STUN servers (see Reference 5 below).

  3. Test if there is still leakage by visiting the DNS leak test Web site and clicking on the Standard test button, and visiting the IP/DNS Detect site.

Furthermore, do not forget to use a Private Browsing window in Firefox.

Automate the editing of Firefox user preferences

Using about:config to change the user preferences in Firefox is laborious, so I created a Bash script edit_firefox.sh to toggle the relevant user preferences:

#!/bin/bash
# Script to change Firefox user preferences rather than
# using about:config from within Firefox.
# Make sure you only run this script when Firefox is not running.
#
FILE="/home/fitzcarraldo/.mozilla/firefox/fm8q09x0.default/prefs.js"
#
#
STATE=$(grep media.peerconnection.enabled $FILE | cut -c 43- | cut -d')' -f1)
if ! grep -q media.peerconnection.enabled $FILE ; then
  echo 'user_pref("media.peerconnection.enabled", false);' >> $FILE
  echo 'Added media.peerconnection.enabled false (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*media.peerconnection.enabled.*$/'user_pref("media.peerconnection.enabled", false);'/ $FILE
     echo 'media.peerconnection.enabled changed to false (secure) in prefs.js'
  else
     sed -i s/^.*media.peerconnection.enabled.*$/'user_pref("media.peerconnection.enabled", true);'/ $FILE
     echo 'media.peerconnection.enabled changed to true (not secure) in prefs.js'
fi
#
STATE=$(grep browser.safebrowsing.malware.enabled $FILE | cut -c 51- | cut -d')' -f1)
if ! grep -q browser.safebrowsing.malware.enabled $FILE ; then
  echo 'user_pref("browser.safebrowsing.malware.enabled", false);' >> $FILE
  echo 'Added browser.safebrowsing.malware.enabled false (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*browser.safebrowsing.malware.enabled.*$/'user_pref("browser.safebrowsing.malware.enabled", false);'/ $FILE
     echo 'browser.safebrowsing.malware.enabled changed to false (secure) in prefs.js'
  else
     sed -i s/^.*browser.safebrowsing.malware.enabled.*$/'user_pref("browser.safebrowsing.malware.enabled", true);'/ $FILE
     echo 'browser.safebrowsing.malware.enabled changed to true (not secure) in prefs.js'
fi
#
STATE=$(grep browser.safebrowsing.enabled $FILE | cut -c 43- | cut -d')' -f1)
if ! grep -q browser.safebrowsing.enabled $FILE ; then
  echo 'user_pref("browser.safebrowsing.enabled", false);' >> $FILE
  echo 'Added browser.safebrowsing.enabled false (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*browser.safebrowsing.enabled.*$/'user_pref("browser.safebrowsing.enabled", false);'/ $FILE
     echo 'browser.safebrowsing.enabled changed to false (secure) in prefs.js'
  else
     sed -i s/^.*browser.safebrowsing.enabled.*$/'user_pref("browser.safebrowsing.enabled", true);'/ $FILE
     echo 'browser.safebrowsing.enabled changed to true (not secure) in prefs.js'
fi
#
STATE=$(grep network.proxy.socks_remote_dns $FILE | cut -c 45- | cut -d')' -f1)
if ! grep -q network.proxy.socks_remote_dns $FILE ; then
  echo 'user_pref("network.proxy.socks_remote_dns", true);' >> $FILE
  echo 'Added network.proxy.socks_remote_dns true (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*network.proxy.socks_remote_dns.*$/'user_pref("network.proxy.socks_remote_dns", false);'/ $FILE
     echo 'network.proxy.socks_remote_dns changed to false (not secure) in prefs.js'
  else
     sed -i s/^.*network.proxy.socks_remote_dns.*$/'user_pref("network.proxy.socks_remote_dns", true);'/ $FILE
     echo 'network.proxy.socks_remote_dns changed to true (secure) in prefs.js'
fi
#
STATE=$(grep network.dns.disablePrefetch $FILE | cut -c 42- | cut -d')' -f1)
if ! grep -q network.dns.disablePrefetch $FILE ; then
  echo 'user_pref("network.dns.disablePrefetch", true);' >> $FILE
  echo 'Added network.dns.disablePrefetch true (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*network.dns.disablePrefetch.*$/'user_pref("network.dns.disablePrefetch", false);'/ $FILE
     echo 'network.dns.disablePrefetch changed to false (not secure) in prefs.js'
  else
     sed -i s/^.*network.dns.disablePrefetch.*$/'user_pref("network.dns.disablePrefetch", true);'/ $FILE
     echo 'network.dns.disablePrefetch changed to true (secure) in prefs.js'
fi
#
STATE=$(grep network.dns.disableIPv6 $FILE | cut -c 38- | cut -d')' -f1)
if ! grep -q network.dns.disableIPv6 $FILE ; then
  echo 'user_pref("network.dns.disableIPv6", true);' >> $FILE
  echo 'Added network.dns.disableIPv6 true (secure) to prefs.js'
elif [ $STATE = "true" ]; then
     sed -i s/^.*network.dns.disableIPv6.*$/'user_pref("network.dns.disableIPv6", false);'/ $FILE
     echo 'network.dns.disableIPv6 changed to false (not secure) in prefs.js'
  else
     sed -i s/^.*network.dns.disableIPv6.*$/'user_pref("network.dns.disableIPv6", true);'/ $FILE
     echo 'network.dns.disableIPv6 changed to true (secure) in prefs.js'
fi

You will need to change the path to the Firefox prefs.js file in the sixth line of the script, to suit your installation. If you have the utility mlocate installed you can find the file easily by using the command:

$ locate prefs.js | grep firefox

You will also need to make the script executable:

$ chmod +x edit_firefox.sh

You can see below how the script works:

$ ./edit_firefox.sh
media.peerconnection.enabled changed to false (secure) in prefs.js
browser.safebrowsing.malware.enabled changed to false (secure) in prefs.js
browser.safebrowsing.enabled changed to false (secure) in prefs.js
network.proxy.socks_remote_dns changed to true (secure) in prefs.js
network.dns.disablePrefetch changed to true (secure) in prefs.js
network.dns.disableIPv6 changed to true (secure) in prefs.js
$ ./edit_firefox.sh
media.peerconnection.enabled changed to true (not secure) in prefs.js
browser.safebrowsing.malware.enabled changed to true (not secure) in prefs.js
browser.safebrowsing.enabled changed to true (not secure) in prefs.js
network.proxy.socks_remote_dns changed to false (not secure) in prefs.js
network.dns.disablePrefetch changed to false (not secure) in prefs.js
network.dns.disableIPv6 changed to false (not secure) in prefs.js
$

Procedure to use Tor

So, if I am not using the Tor Browser, in summary I do the following (refer to my 2011 Tor post for the details):

  1. Launch Polipo from a Konsole window.
  2. Launch Vidalia from a Konsole window.
  3. Launch edit_firefox.sh to make sure the relevant user preferences are set securely.
  4. Launch Firefox and change the network settings to enable use of Polipo and Vidalia.
  5. Launch a Firefox Private Browsing window and close the original window.
  6. Visit TorCheck at Xenobite.eu, What Is My IP Address?, DNS leak test and IP/DNS Detect to be sure I am using Tor and that there is no DNS leak or WebRTC leak.

The router provided by my ISP does not allow me to change its DNS server settings. Using the router’s Web browser interface I was able to view the IP addresses of the DNS servers the router uses (Whois Lookup is a good place to check to whom an IP address belongs), and they are indeed owned by the ISP. However, the leak test Web sites I mention above show me that there is no DNS leakage to the ISP’s DNS servers when I have performed all the steps above.

When I have finished using Tor, I do the following:

  1. Exit Firefox.
  2. Stop Tor from the Vidalia GUI, exit Vidalia and end the Konsole session.
  3. Stop Polipo and end the Konsole session.
  4. Launch edit_firefox.sh to set the relevant user preferences back to their original settings.
  5. Launch Firefox and change the network settings back to the original settings.

References

1. Preventing Tor DNS Leaks
2. Tor new advice (February 2014)
3. Download Tor Browser
4. Linux Instructions for Tor Browser
5. New Browser Based Flaw Leaks VPN Users’ IP Addresses

Cannot browse some Web sites: yet another cause

Having spent hours yesterday trying to figure out why I could no longer browse a few specific Web sites from my old Gateway Solo 9300 laptop running Linux, whereas all the other Linux and Windows laptops that use my wireless network can browse any Web site, I thought I’d post the solution as Google did not turn up this particular cause.

There are several possible reasons why one may not be able to browse some Web sites: IPv6; the MTU; a black hole router en route; the settings in the various ip_* and tcp_* files in /proc/sys/net/ipv4/, and so on. So, unfortunately I had many avenues to pursue.

My old Gateway Solo 9300 laptop had enabled me to browse the Web reliably via my home wireless network until recently. Suddenly I could neither browse the Sabayon Linux Web site nor access the Entropy package manager’s repository. I could also no longer browse some other Web sites, although most Web sites were still accessible without trouble.

I tried many different things without success, and then finally remembered that I had reconfigured my router a couple of weeks ago because one of my family had reset it whilst I was away from home. Now, when this model of router (BT Home Hub, Version 1.0) is reset it defaults to WEP encryption for wireless networking. However, I normally have it set to use WPA-PSK encryption. So, when I got home I accessed the router’s Web interface via Ethernet from a Desktop PC and changed wireless networking encryption to “WPA-PSK Version: WPA+WPA2″. In the past I had set it to “WPA-PSK Version: WPA”, and thought that setting “WPA+WPA2″ instead of “WPA” this time would not cause any problems. Well, it didn’t on all the other laptops using my network, but my old Gateway Solo 9300 with Linksys CardBus card (‘Linksys WPC54G (EU) v7.1 wireless notebook adapter card’) was different.

As soon as I wondered if the encryption setting was the cause of my problem, I browsed to the BT Home Hub configuration page and changed wireless networking encryption from “WPA-PSK Version: WPA+WPA2″ to “WPA-PSK Version: WPA”. Bingo, my Gateway Solo 9300 running Sabayon Linux E17 Edition and Firefox 4 could browse all Web sites again. Mind you, I also need to have the ipv6 module disabled (I had previously uncommented the line alias net-pf-10 off in the file /etc/modprobe.d/aliases.conf and used the command update-modules) as well as the modifications mentioned in an earlier post (Why can’t I access a specific Web site?). But all those other measures do not solve the problem if the router is configured for “WPA-PSK Version: WPA+WPA2″.

The router’s wireless security option “WPA-PSK Version: WPA” is intended for a network that would only be used by clients configured to use WPA encryption; the router’s option “WPA-PSK Version: WPA2″ is intended for a network that would only be used by clients configured to use WPA2 encryption; the router’s option “WPA-PSK Version: WPA+WPA2″ is intended for a network that would be used by clients configured to use either WPA or WPA2 encryption. So I wonder why there was a problem, as the laptop and CardBus card are configured for “WPA & WPA2 Personal” in nm-applet, and the card supports WPA (TKIP) and WPA2 (CCMP a.k.a. AES).

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.

BACKGROUND

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 www.cisco.com

e.g.

# ping -M do -s 1472 www.cisco.com

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…

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
0

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)

# START OF MY ADDITIONS
# 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
# END OF MY ADDITIONS

# 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.

Follow

Get every new post delivered to your Inbox.

Join 54 other followers