Date: Wed, 27 Aug 2008 15:06:10 GMT From: Joao Paulo Just <just@rg3.net> To: freebsd-gnats-submit@FreeBSD.org Subject: bin/126892: Routing problems when using pppoed and ppp as PPPoE server Message-ID: <200808271506.m7RF6ARs009080@www.freebsd.org> Resent-Message-ID: <200808271510.m7RFA1H5040373@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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 >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 27 15:10:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Joao Paulo Just >Release: FreeBSD 7.0-RELEASE-p3 amd64 >Organization: RG3.Net >Environment: FreeBSD zeus.rg3network.com.br 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #7: Sat Aug 16 09:09:11 BRT 2008 root@zeus.rg3network.com.br:/usr/obj/usr/src/sys/ZEUS amd64 >Description: 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 192.168.0.10 and ppp uses 192.168.0.1 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 192.168.0.10"): route to: 192.168.0.10 destination: 192.168.0.10 interface: tun0 .. If another Windows client tries to make another connection, it works fine also: route to: 192.168.0.11 destination: 192.168.0.11 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 192.168.0.12 as IP address and ppp creates "tun2" as a virtual interface. The entry ppp adds in the routing table would be: route to: 192.168.0.12 destination: 192.168.0.12 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. >How-To-Repeat: 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. /etc/ppp/ppp.conf: default: set log Chat Command Phase LCP IPCP CCP TUN LQM Radius myisp: 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 192.168.0.1 192.168.0.2-192.168.0.254 255.255.255.255 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 /etc/rc.conf: pppoed_enable="YES" pppoed_interface="em0" pppoed_flags="-P /var/run/pppoed.pid -a MyISP -l myisp" >Fix: 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/fixit.sh INTERFACE The script: /etc/ppp/fixit.sh: #!/bin/sh # # 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/fixit.sh INTERFACE # # Author: Joao Paulo Just <just@rg3.net> # Thanks to: Giancarlo Rubio # We need to wait until ppp creates the tun interface sleep 10 # Get some values tun=${1} 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 172.16.0.1 -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. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808271506.m7RF6ARs009080>