[Bug 604283] Re: network servers do not listen on 127.0.1.1

[Brian Murray]

** Bug watch added: Debian Bug tracker #617268
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617268

** Also affects: ifupdown (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617268
   Importance: Unknown
       Status: Unknown

** Tags added: udd-find

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/604283

Title:
  network servers do not listen on 127.0.1.1

Status in “ifupdown” package in Ubuntu:
  New
Status in “ifupdown” package in Debian:
  Unknown

Bug description:
  Binary package hint: ifupdown

  release: Ubuntu 10.04 LTS (but probably all releases back to Hardy and forward to Maverick)
  package: ifupdown: Installed: 0.6.8ubuntu29

  Since upgrading my systems to lucid and cleaning up the
  configurations, I've noticed strange behaviour where client tcp or udp
  sessions to local tcp/ip servers have timed out even though the
  servers were running and netstat showed they were listening on all
  interfaces. Wireshark traces showed that successful connections went
  to 127.0.0.1, while any connection attempt to 127.0.1.1 would fail.

  The systems are fully controlled by NetworkManager <offtopic>a long and painful story!</offtopic> and so /etc/network/interfaces contains only two lines:
      auto lo
      iface lo inet loopback

  This "minimal configuration" is not only highly recommended to avoid
  wierd behaviour with NetworkManager, but also to avoid problems with
  upstart (e.g.
  https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/497299). All
  the other network interfaces are managed by NM.

  "In the old days", a typical /etc/hosts file would define all the local hostnames as follows:
      127.0.0.1  myhostname.localdomain  myhostname  localhost.localdomain  localhost 

  For several releases (back as far as Hardy), ubuntu installations have been creating a more sophisticated version of the hosts file (presumably because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099), e.g.
      127.0.0.1  localhost
      127.0.1.1  myhostname.mydomain  myhostname

  This modern variant allows the system to always resolve its own
  hostname and canonical name, even when there is no external network.

  It appears to work really well... e.g. "ping hostname" and "ping
  localhost" both succeed. "hostname" and "hostname -f" return the
  expected values. (note: I don't fully understand why ping hostname
  actually works - perhaps because the class A 127.0.0.0 subnet has been
  defined for ever as a loopback subnet?).

  The problem comes when a local client tries to connect to a local server... a well-behaved server will listen on "all available network interfaces", e.g.
      brian at myhostname:~$ netstat -ln | grep 53
      tcp        0      0 10.1.252.115:53         0.0.0.0:*               LISTEN     
      tcp        0      0 192.168.252.115:53      0.0.0.0:*               LISTEN     
      tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
      udp        0      0 10.1.252.115:53         0.0.0.0:*                          
      udp        0      0 192.168.252.115:53      0.0.0.0:*                          
      udp        0      0 127.0.0.1:53            0.0.0.0:*                          

  ... so, when a client tries to connect to the local server (in my not
  very realistic example you would have to edit /etc/resolv.conf to
  point to myhostname instead of the default localhost), the nslookup
  connection would never be received by the local bind server and so
  will eventually time out.

  If we are to keep the "new style" hosts file structure (and I think we
  should), then we MUST ensure that local servers are able to access all
  available interfaces, including BOTH of the loopback addresses
  mentioned in the hosts file, so we need to define an additional
  interface for the myhostname loopback address.

  This can be easily demonstrated by defining a second (virtual) address for the lo interface:
      sudo ifconfig lo:0 127.0.1.1 netmask 255.0.0.0

  Stop the server and it will discover the extra interface when it is restarted:
      brian at myhostname:~$ netstat -ln | grep 53
      tcp        0      0 10.1.252.115:53         0.0.0.0:*               LISTEN     
      tcp        0      0 192.168.252.115:53      0.0.0.0:*               LISTEN     
      tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN     
      tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
      udp        0      0 10.1.252.115:53         0.0.0.0:*                          
      udp        0      0 192.168.252.115:53      0.0.0.0:*                          
      udp        0      0 127.0.1.1:53            0.0.0.0:*                          
      udp        0      0 127.0.0.1:53            0.0.0.0:*                          

  Of course, this circumvention will only last until the next reboot.
  The solution can be made permanent by updating the
  /etc/networking/interfaces file to automatically bring up both
  loopback interfaces early in the boot process:

      # This file describes the network interfaces available on your system
      # and how to activate them. For more information, see interfaces(5).

      # automatically bring up both these interfaces at boot (ifup -a == all)
      auto lo lo:0

      # The standard loopback network interface
      iface lo inet loopback

      # another loopback interface for that pesky dual loopback hosts file
      iface lo:0 inet static
        address 127.0.1.1
        netmask 255.0.0.0

  I do not know if there is a more elegant solution to the same problem
  (but remember that some of the server processes are started very
  early, hence the upstart bug reference above).

  If acceptable, this bug should be pushed upstream to encompass the
  other distros that use the same multiple loopback interface /etc/hosts
  file organisation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/604283/+subscriptions