# [SOLVED] UMTS failover triggered by ping

## Evil.2000

Hello!

I'm trying to set up a script, which checks if a given DSL broadband connection is active and if not it starts a UMTS connection over a Huawei USB-Stick.

This is my layout:

```
ADSL --- [ADSL-Router] --eth0-\

                               >-- [Gentoo Box]

UMTS ---- [UMTS-Stick] --ppp0-/
```

My script looks like this:

```
#!/bin/bash

while true; do

   ping -I eth0 -W 1 -c 1 87.118.117.126 >/dev/null 2>&1

   if [ "$?" == "0" ]; then

      ifconfig ppp0 >/dev/null 2>&1 && poff umts

      sleep 10

      # Don't set route because we are using

      # different metrics for eth0 and ppp0

      #route add default gw 192.168.2.1

      echo "nameserver 192.168.2.1" > /etc/resolv.conf

   else

      #route del default gw 192.168.2.1

      ifconfig ppp0 >/dev/null 2>&1 

      if [[ "$?" -ne "0" ]]; then

         pon umts

      fi

      sleep 120

   fi

   if [[ -e /tmp/check_umts.stop ]]; then

      # Die if we have to...

      rm /tmp/check_umts.stop

      exit 0

   fi

done
```

As you can see i'm using ping with -I option because i want to check if the desired host is reachable through eth0 (which is the DSL-side).

Now, if ping exits with a code other then zero (cause the DSL line is disconnected or something else happened), the script establishes the UMTS connection.

Until now, all works perfectly.

But if the DSL is reconnected, the ping does not receive any echo reply.

If i use tcpdump to look on the eth0 wire, the ICMP replies are there.

```
# ping -I eth0 -c 10 87.118.117.126

PING 87.118.117.126 (87.118.117.126) from 192.168.2.102 eth0: 56(84) bytes of data.

--- 87.118.117.126 ping statistics ---

10 packets transmitted, 0 received, 100% packet loss, time 9000ms
```

```
# tcpdump -i eth0 icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes

17:17:38.596125 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 1, length 64

17:17:38.661285 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 1, length 64

17:17:39.596431 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 2, length 64

17:17:39.661742 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 2, length 64

17:17:40.596422 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 3, length 64

17:17:40.662728 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 3, length 64

17:17:41.596432 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 4, length 64

17:17:41.674022 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 4, length 64

17:17:42.596431 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 5, length 64

17:17:42.661434 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 5, length 64

17:17:43.596419 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 6, length 64

17:17:43.662220 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 6, length 64

17:17:44.596442 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 7, length 64

17:17:44.661382 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 7, length 64

17:17:45.596428 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 8, length 64

17:17:45.662027 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 8, length 64

17:17:46.596429 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 9, length 64

17:17:46.661921 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 9, length 64

17:17:47.596429 IP 192.168.2.102 > ns2.km33902.keymachine.de: ICMP echo request, id 33906, seq 10, length 64

17:17:47.662601 IP ns2.km33902.keymachine.de > 192.168.2.102: ICMP echo reply, id 33906, seq 10, length 64

^C

20 packets captured

20 packets received by filter

0 packets dropped by kernel
```

This is my routing table and ifcondig with UMTS established:

```
 # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0

0.0.0.0         192.168.2.1     0.0.0.0         UG    1      0        0 eth0

# ifconfig 

eth0      Link encap:Ethernet  HWaddr 00:22:68:61:37:0e  

          inet addr:192.168.2.102  Bcast:192.168.2.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:631727 errors:0 dropped:0 overruns:0 frame:0

          TX packets:84208 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:796756166 (759.8 MiB)  TX bytes:34106772 (32.5 MiB)

          Interrupt:19 Base address:0x2c00 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:569 errors:0 dropped:0 overruns:0 frame:0

          TX packets:569 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:55954 (54.6 KiB)  TX bytes:55954 (54.6 KiB)

ppp0      Link encap:Point-to-Point Protocol  

          inet addr:10.77.159.33  P-t-P:10.64.64.64  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:4656 errors:7 dropped:0 overruns:0 frame:0

          TX packets:3920 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:3 

          RX bytes:2796732 (2.6 MiB)  TX bytes:604107 (589.9 KiB)
```

Does anyone have an idea how to check if DSL is reestablished so i can disconnect the UMTS again?

Or does someone know how to tell ping to react on the reply packets?

Btw.: If i ping a local lan address over eth0 its working.

Thanks in advice.

Evil

----------

## Evil.2000

I found the solution.

I figured out that the ICMP packet gets stuck in the kernel netfilter between the PREROUTING table mangle and nat:

```
---[filter]----------------------------------------------------

Chain INPUT (policy ACCEPT 86221 packets, 77M bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain OUTPUT (policy ACCEPT 12922 packets, 1072K bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

---[nat]-------------------------------------------------------

Chain PREROUTING (policy ACCEPT 1037 packets, 145K bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain POSTROUTING (policy ACCEPT 980 packets, 61391 bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain OUTPUT (policy ACCEPT 980 packets, 61391 bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

---[mangle]----------------------------------------------------

Chain PREROUTING (policy ACCEPT 86231 packets, 77M bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain INPUT (policy ACCEPT 86231 packets, 77M bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain OUTPUT (policy ACCEPT 12932 packets, 1073K bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain POSTROUTING (policy ACCEPT 12968 packets, 1074K bytes)

 pkts bytes target     prot opt in     out     source               destination         

    1    84 LOG        icmp --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

    0     0 LOG        icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
```

As you can see, the packet travels out to eth0 and the response comes in through eth0 and disappears between PREROUTING mangle and nat.

Look here for a graphic which shows the packet-flow through the kernel:

http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

After i searched a bit i found this message:

http://mailman.ds9a.nl/pipermail/lartc/2006q1/018175.html

After that i disabled rp_filter and now all is working well.

```
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
```

Look here for more info about rp_filter:

http://www.frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html#AEN634

Evil

----------

## Fennec74

Hi, 

I've searched information about failover and UMTS and I've founded your post.

But I don't understand your answer. Perhaps because my knowledge are a bit small.

Have you got an example script, like your first post, to explain it.

Thanks in advance.

----------

## Evil.2000

There's nothing to explain.

I'm just doing a ping to a public IP through the eth0 interface. If that ping does not return, a PPP connection is established over UMTS.

Now, if the PPP connection is established, the default path for all packets is ppp0. But i wanted to check if the ping over eth0 returns and not over ppp0.

So i had to set the rp_filter flag as described above, that the ICMP ping packets are allowed to come in over eth0 even if the PPP connection exists.

Nothing more, nothing less.

HTH.

Evil

----------

## Fennec74

Thanks you for your explanation.

----------

