bin/126892: Routing problems when using pppoed and ppp as PPPoE server

Joao Paulo Just just at
Wed Aug 27 15:10:01 UTC 2008

>Number:         126892
>Category:       bin
>Synopsis:       Routing problems when using pppoed and ppp as PPPoE server
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 27 15:10:00 UTC 2008
>Originator:     Joao Paulo Just
>Release:        FreeBSD 7.0-RELEASE-p3 amd64
FreeBSD 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #7: Sat Aug 16 09:09:11 BRT 2008 root at amd64
When a FreeBSD 7.0 server is set up to work as a PPPoE server using pppoed and ppp, we have routing problems when Linux machines tries to establish a PPPoE connection.
Everything works fine when Windows clients connect to the server, but if a Linux machine (be it a computer or any device, as an small router), we get routing problems. The connection is established fine, but ppp adds an incorrect entry in the routing table.
Let's suppose a Windows client established a connection to our server. ppp creates a virtual interface "tun0" to handle this connection. The Windows client gets the IP address and ppp uses as server's address. A new entry in the routing table is created as follow (the output below was get using the command "route get"):
   route to:
  interface: tun0
If another Windows client tries to make another connection, it works fine also:
   route to:
  interface: tun1
But if a Linux machine tries to make a connection, it is established, but the entry in the routing table is incorrect. Let's suppose our Linux box gets as IP address and ppp creates "tun2" as a virtual interface. The entry ppp adds in the routing table would be:
   route to:
  interface: tun0
Pay attention to "interface" field. ppp creates "tun2" as interface for Linux client's tunnel, but it adds a entry using "tun0". The Linux client can't even ping the server.
If the Linux client is the first one to connect, it works OK, just because as first one to establish a connection, its vitual interface would be "tun0" and the "incorrect" entry in the routing table would work.
The same setup was working fine on a 6.3-RELEASE. The problem started happening after installing a new server with FreeBSD 7.0-p3.

A curious fact is that it only happens with Linux machines. I really don't know why. I even tried to change Linux configuration, but with no success. FreeBSD as a client was not tested.

Install FreeBSD 7.0 and set up a PPPoE server as follows. Then, use a Windows machine to establish a connection to this server and, after Windows' connection was made, establish another connection using a Linux machine.
 set log Chat Command Phase LCP IPCP CCP TUN LQM Radius

  allow mode direct 
  enable proxy
  disable ipv6cp
  set mru 1492
  set mtu 1492
  set speed sync
  enable vjcomp

  enable MSCHAPv2
  enable mppe
  enable chap
  deny pap
  disable deflate pred1
  deny deflate pred1
  enable lqr echo
  set timeout 0
  # IP configuration
  set ifaddr
  accept dns
  set dns xx.xx.xx.xx yy.yy.yy.yy # Use two DNS servers here
  # Although I haven't tested without RADIUS, I can assume it is not the problem
  # as the error is in the routing table entry
  set radius /etc/radius.conf
  enable NAS-IP-Address
  set rad_alive 30
  set rad_port_id tunnum
  pppoed_flags="-P /var/run/ -a MyISP -l myisp"

Workaround #1:

I could "fix" the problem creating a shell script to correct the routing table entry. I had also to add the following line to /etc/ppp/ppp.conf to call my new script:
!bg /etc/ppp/ INTERFACE
The script:
  # Fixes routing table's incorrect entry added by ppp
  # by deleting the current entry and adding a correct
  # one.
  # You must add the following line in /etc/ppp/ppp.conf:
  #   !bg /path/to/ INTERFACE
  # Author: Joao Paulo Just <just at>
  # Thanks to: Giancarlo Rubio
  # We need to wait until ppp creates the tun interface
  sleep 10
  # Get some values
  ip=`/sbin/ifconfig $tun | grep inet | cut -f 4 -d " " -`
  # Log (optional)
  echo "$tun: $ip" >> /etc/ppp/fixit.log
  # Fixes the routing table. The command "route change"
  # didn't work here, because something, maybe ppp, changes
  # the entry again, using the incorrect interface, so,
  # we must add a static entry. But this creates another
  # problem: when the connection is closed, the entry stills
  # there.
  route delete $ip
  route add $ip -ifp $tun
Workaround #2:

Actually, this was the one I choosed. Stop using pppoed and ppp and migrate to mpd. mpd also is working faster here, I mean, the connections are being established quicker. The routing problem doesn't exist anymore and we are happy again.


More information about the freebsd-bugs mailing list