default route ignored when ppp0 up

Discussion in 'Linux Networking' started by Don, Apr 10, 2012.

  1. Don

    Don Guest

    I have a Lenny Debian distro with a 2.6.21 kernel. I start with a
    single Ethernet interface to the Internet:

    tcors01:~# netstat -rn
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt Iface
    129.116.XXX. 0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
    0.0.0.0 129.116.XXX.254 0.0.0.0 UG 0 0 0 eth2
    tcors01:~# ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=35.0 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=30.3 ms

    --- 8.8.8.8 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1006ms
    rtt min/avg/max/mdev = 30.381/32.726/35.072/2.352 ms

    The default route works fine until I bring up a point-to-point
    interface.

    tcors01:~# pon att
    tcors01:~# netstat -rn
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt Iface
    192.168.111.111 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    129.116.XXX.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
    0.0.0.0 129.116.XXX.254 0.0.0.0 UG 0 0 0 eth2
    tcors01:~# ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    From 129.116.XXX.27 icmp_seq=1 Destination Host Unreachable
    From 129.116.XXX.27 icmp_seq=2 Destination Host Unreachable
    From 129.116.XXX.27 icmp_seq=3 Destination Host Unreachable

    --- 8.8.8.8 ping statistics ---
    5 packets transmitted, 0 received, +3 errors, 100% packet loss, time
    4012ms
    , pipe 3

    Why does the default route fail with the addition of the ppp0
    interface to the routing table?
     
    Don, Apr 10, 2012
    #1
    1. Advertisements

  2. Don

    J G Miller Guest

    Probably because you are using the Debian scripts to bring up ppp0
    which invokes a script to change the default route. As I do not
    have ppp installed I cannot say which one but you should look in
    /etc/ppp at the scripts there for if-up* and also probably in
    /etc/network/if-up.d for one related to ppp.

    And yes you do have to fight with those scripts to stop the
    default route from being changed.
     
    J G Miller, Apr 10, 2012
    #2
    1. Advertisements

  3. Don

    Andy Furniss Guest

    IIRC there's a pppd option defaultroute it may be in /etc/ppp/options.

    This can be changed to nodefaultroute.

    Of course distro scripts may also be involved eg passing defaultroute on
    the command line.
     
    Andy Furniss, Apr 10, 2012
    #3
  4. Don

    J G Miller Guest

    J G Miller, Apr 10, 2012
    #4
  5. Don

    Don Guest

    Thank you for your reply, but I do not believe that is the issue. I
    am familiar with the nodefaultroute option in the /etc/ppp/peers/
    provider file. I am using it. That is why the routing table has ppp0
    added as a host route (as shown in the original post) after bringing
    up ppp0, but it does NOT have ppp0 shown as a gateway route (i.e. with
    the 'G' flag). If I do not use the nodefaultroute option, after
    bringing ppp0 up ppp0 DOES appear in the routing table with the 'G'
    flag.

    Don
     
    Don, Apr 10, 2012
    #5
  6. Hello,

    Don a écrit :
    This message normally means that the " next hop" (either router or final
    destination) IP address could not be resolved with ARP.
    What is 129.116.XXX.27 ? The host itself, I guess ?
    What is the output of : ip route get 8.8.8.8
    What is the output of : ping 129.116.XXX.254
    What is the output of : ip neigh
    While trying to ping 8.8.8., what is the output of : tcpdump -ni eth2
     
    Pascal Hambourg, Apr 10, 2012
    #6
  7. Don

    Don Guest

    Hello, and thank you for your interest.
    That is the static IP address of the eth2 interface.
    tcors01:~# ip route get 8.8.8.8
    8.8.8.8 via 129.116.XXX.254 dev eth2 src 129.116.XXX.27
    cache mtu 1500 advmss 1460 hoplimit 64
    tcors01:~# ping 129.116.XXX.254
    PING 129.116.XXX.254 (129.116.XXX.254) 56(84) bytes of data.
    From 129.116.XXX.27 icmp_seq=10 Destination Host Unreachable
    From 129.116.XXX.27 icmp_seq=11 Destination Host Unreachable
    From 129.116.XXX.27 icmp_seq=12 Destination Host Unreachable

    --- 129.116.XXX.254 ping statistics ---
    13 packets transmitted, 0 received, +3 errors, 100% packet loss, time
    12001ms
    , pipe 3
    tcors01:~# ip neigh
    129.116.XXX.254 dev eth2 FAILED
    tcors01:~# tcpdump -r eth2dump.log
    reading from file eth2dump.log, link-type EN10MB (Ethernet)
    22:01:43.987949 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:44.987696 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:45.987553 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:47.857363 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:48.857228 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:49.857100 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:51.856821 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:52.856628 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
    22:01:53.856490 ARP, Request who-has 129.116.XXX.254 tell 129.116.XXX.
    27, length 28
     
    Don, Apr 10, 2012
    #7
  8. Don a écrit :
    [...]
    Routing is fine, but the gateway does not reply to ARP queries - or at
    least your box does not receive them. This looks like a layer-2 issue. I
    cannot see how the PPP connection could possibly cause this.
    What kind of PPP connection is it ?
     
    Pascal Hambourg, Apr 10, 2012
    #8
  9. Don

    Don Guest

    It is a cellular modem connecting through AT&T as an ISP.

    tcors01:~# ifconfig ppp0
    ppp0 Link encap:point-to-Point Protocol
    inet addr:32.176.37.1 P-t-P:192.168.111.111 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
     
    Don, Apr 11, 2012
    #9
  10. Don a écrit :
    So it seems to be unrelated with the ethernet interface (unlike a PPPoE
    connection). Again, I cannot see a reason for the behaviour you observe.

    What happens if the gateway or another host on the ethernet network
    tries to communicate with the Debian system ?
    Is the communication on eth2 restored after the PPP connection is
    terminated ?
     
    Pascal Hambourg, Apr 12, 2012
    #10
  11. Don

    Don Guest

    It turned out that this was a driver issue for that particular
    Ethernet port. The manufacturer of the PC/104 peripheral Ethernet
    board did not support 2.6 kernel version drivers for that board. 2.4
    kernel drivers seem to work fine, and the other Ethernet port on the
    board works fine as well. Thank you for your help!

    Don
     
    Don, May 1, 2012
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.