Tails should be usable by those stuck with dial-up Internet access. Recent events have shown that in some cases, dial-up might be the last option to reach the Internet when broadband operators have been shut down.


Next thing to do: make up our mind wrt. towards which one of the possible solutions we want to go: #6045.

Possible solutions:

  • fix Debian bug #258064, but GNOME PPP looks dead upstream, so it might be an option to create a custom package handling resolvconf the way we want.
  • find alternative ways to use WvDial or PPP.

Ideal solution: #5543


NetworkManager (and ModemManager) have full support for mobile modems. But nothing for old school dial-up modems at the moment: see Integrated PPP support

Fallback option: provide GNOME PPP, a GUI front-end to old but trusty WvDial.

Dial-up emulation

Here is a method to test dial-up PPP connections without resorting to a real modem and a real Internet provider available on the Plain Old Telephony System. It needs a system running Tails and another one (the gateway) running standard Debian. So this requires either two computers in the same LAN or runing Tails using virtualization.

  1. Prepare the networking stack on the gateway:

     # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
     # sysctl -w net.ipv4.ip_forward=1
  2. In Tails, create .wvdial.conf:

     [Dialer Defaults]
     Baud = 115200
     Init = ATZ
     Init2 = AT%R1
     Phone =
     Username = test
     Password = test
     Carrier Check = off

    Replace the IP address in Phone with the IP address of the other system.

  3. In Tails, install the modemu package.

  4. In Tails, remove the default route to let room for the one provided by PPP:

     # ip route del default
  5. On the gateway run:

     # pppd noauth local lock nodefaultroute persist debug nodetach pty "nc -l 6789"
  6. And fairly quickly (before pppd times out), run on Tails:

     $ sudo modemu -c 'ln -nsf %s /dev/modem ; wvdial -C .wvdial.conf'

Repeat the last two steps if the connection is broken at some point.

PPPoE emulation

To ensure that PPPoE (broadband DSL) support is not broken by tweaks to PPP configuration files, here is a test procedure. This needs a standard Debian system (the gateway), and either a spare wired network card or using virtualization.

This reciepe uses kvm, but could be easily adapted to other setups:

  1. On the gateway, install the pppoe package.
  2. On the gateway, create /etc/ppp/pppoe-server-options:

     lcp-echo-interval 10
     lcp-echo-failure 2
  3. Start KVM, adding those arguments: -net nic,model=virtio -net tap,ifname=tails.

  4. On the gateway, up this interface:

     # ip link set tails up
  5. On the gateway, start the PPPoE server:

     # sudo pppoe-server -I tails -F -S test -m 1412
  6. On Tails, you can now right-click the NetworkManager icon, and select Edit connections.... In the DSL tab, click Add. Service name should be set to test. Other settings should not matter.

  7. On Tails, left-click the NetworkManager icon and selection the newly created connection.

To debug, use tcpdump, and look at /var/log/syslog.



As WvDial (and thus GNOME PPP) is not integrated with NetworkManager in any way, the hooks in /etc/NetworkManager/dispatcher.d are not normally run upon connection.

They will be after adding the following script as /etc/ppp/ip-up.d/010call-nm-hooks:


run-parts --regex='^[a-z0-9-]+(\.sh)?$' /etc/NetworkManager/dispatcher.d --arg="$1" --arg="up"

But this will probably has the undesired effect of calling NetworkManager hooks twice when using PPPoE. This does not look like a real issue, but Tor is still restarted twice which is not nice.

Answer to this problem is fairly simple: when using WvDial with a good ol' modem, a SPEED environment variable is defined when 01call-nm-hooks runs. Let's simply use this to determine if we should run NetworkManager hooks manually.

Remaining issues:

  • gnome-ppp conflicts with resolvconf, see Debian bug #258064.
  • Clarify what groups must the user be part of to run wvdial / gnome-ppp? We've been told on the forum that the answer was dialout (which is already the case) and dip (which is not).