From AAISP Support Site
Revision as of 14:22, 4 June 2013 by AA-Andrew (talk | contribs)
Jump to: navigation, search

The Basics

You can use a Linux box in place of a PPPoE-capable router. Why would you want to do this?

  • You're already running a Linux box, and you don't see any point in powering a router as well
  • You want fine control over packets
  • You have a PPPoE router but it doesn't do everything you want


This is what RogerBW is using. It'll probably be much the same on other Linuxen. The basic recipe came from [1].

You will have two ethernet interfaces - one for your internal network (let's assume that's eth1), one for connection to the BT modem (eth0). You will be running PPPoE over the external interface, creating a new interface that actually passes packets.


  • Install ppp, pppoe and iproute.
  • Edit /etc/ppp/peers/aaisp to include:
user mylogin@a.1      <----- your AAISP login
eth0             <----- The ethernet interface to run PPPoE on
#usepeerdns      <----- uncomment this if you want resolv.conf to be set up automatically
lcp-echo-interval 1      <---- this is how often the LCP echo packets get sent to AAISP, in seconds.
lcp-echo-failure 10      <---- this is how many LCP echo failures before the ppp daemon quits
connect /bin/true
maxfail 0      <---- redial forever until your modem regains sync else default is 10x or N times if you enter N
#holdoff 120      <---- this will cause pppd to dial once every 2 mins else default is 0 sec
mtu 1492
  • Edit /etc/ppp/chap-secrets to include this line, consisting of three tab-separated words. The first entry is your AAISP router login, the second is an asterisk, and the third is your AAISP router password. For example:
mylogin@a.1   *    pa$$w0rd
  • Create /etc/ppp/ipv6-up.d/0000defaultroute. In it place the following shell script:
/sbin/ip -6 route add default dev $1
  • chmod it 755.


Run as root: pppoe -A

This should show something like this:

Access-Concentrator: BT_ADSL
Got a cookie: 6e c5 4a dd 1e c0 d6 b6 fe b4 4b 23 38 8f 63 58
AC-Ethernet-Address: 00:90:1a:40:f2:9f

To start your PPPoE session just type

pon aaisp

and to stop it running

poff aaisp

You can check connectivity with a cron job, and add a stanza to /etc/network/interfaces to connect at boot.

Extra configuration

You will find at this point that most web sites work, but some few don't - they just freeze on loading or during initial SSL negotiation. This is because they are blocking ICMP, which is stupid - in part because they are then unable to indicate or respond to the need to fragment large packets. You can get round it by limiting the maximum packet size for TCP: set TCPfix on your clueless control panel, or on the router:

iptables -t mangle -F FORWARD
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452


  • Assign your /64 to the inside interface of your router - eth1 in this example.
ifconfig eth1 inet6 add 2001:8b0:blah/64
  • Enable ipv6 forwarding by adding to /etc/sysctl.conf:
  • If you don't want to reboot, also push these values into /proc/sys/etc.:
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/default/forwarding

In theory, "default" should apply to all interfaces created later, while "all" should apply to all interfaces that exist now. This doesn't always seem to be the case.


  • There's a bug in 2.6.36,, that can cause a kernel panic when the link goes down (55c95e73, fixed in 2a27a03d)


  • Linux is capable of supporting RFC 4638 for an MTU of 1500 (or greater) over PPPoE
    • This is supported on BT FTTC
    • Kernel 2.6.34 is required to fix bugs with certain network cards and non-linear SKBs (ea8420e9, 19937d04)
    • pppd 2.4.6 is required for RFC 4638 support (this is in git but not yet released)

PPP Not coming back after a blip:

This was reported in IRC on Feb 6th 2011. If you get people saying their line didn't come back or their linux box crashed (as in kernel oopsed) after a blip, turns out there's a bug in the kernel pppoe code for 2.6.36 which has been hitting me. some kind of double free in the disconnect code causes a kernel panic. there's a patch here: which seems to work for me

Also see: