GL-AR300M produces massive ping traffic to 8.8.4.4 via OVPN client

Technical Support for Routers
1

Hi,

I’ve got a serious problem with my GL-AR300M. The only purpose of that device is to have an entry point into my network in case my internet connection fails.

For this purpose the AR300M connects to a Open VPN server which is hosted on my machine in a datacenter. The WAN connection for the AR300M is provided via a Huawei 4G stick in tethering mode.

Within one week the AR300M produces more than 150 Megabytes of Traffic (!!!) with nothing but the VPN connection open. This does massively exceed any keep-alive traffic for the VPN connection.

Tracing the traffic on the tunnel I found that there is a permanent ping from the AR300M (it’s VPN endpoint IP is 10.250.250.100) to 8.8.4.4 (which is one of Google’s public DNS servers). I’m not using this server and I don’t have that configured in the GL-AR300M as a custom DNS server. There is no traffic on the LAN interface to 8.8.4.4 (checked with tcpdump on the AR300M), so that’s definitely “produced” by the AR300M.

This kills my available data plan on this stick within 3 weeks! How can this be resolved as soon as possible, in which place of the AR300M is 8.8.4.4 coded and what performs the permanent pings?

12:12:03.714130 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9112, seq 0, length 64
12:12:03.719171 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9112, seq 0, length 64
12:12:04.054115 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9158, seq 0, length 64
12:12:04.059127 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9158, seq 0, length 64
12:12:04.274202 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9185, seq 0, length 64
12:12:04.279189 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9185, seq 0, length 64
12:12:04.534208 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9212, seq 0, length 64
12:12:04.539222 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9212, seq 0, length 64
12:12:04.781863 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9239, seq 0, length 64
12:12:04.786956 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9239, seq 0, length 64
12:12:05.034174 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9266, seq 0, length 64
12:12:05.039186 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9266, seq 0, length 64
12:12:05.294241 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9293, seq 0, length 64
12:12:05.299265 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9293, seq 0, length 64
12:12:05.533893 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9316, seq 0, length 64
12:12:05.538820 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9316, seq 0, length 64
12:12:05.774113 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9344, seq 0, length 64
12:12:05.779083 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9344, seq 0, length 64
12:12:06.022173 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9371, seq 0, length 64
12:12:06.027094 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9371, seq 0, length 64
12:12:07.454053 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9636, seq 0, length 64
12:12:07.459113 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9636, seq 0, length 64
12:12:07.814265 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9682, seq 0, length 64
12:12:07.819249 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9682, seq 0, length 64
12:12:08.074499 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9715, seq 0, length 64
12:12:08.079696 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9715, seq 0, length 64
12:12:08.282129 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9742, seq 0, length 64
12:12:08.287132 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9742, seq 0, length 64
12:12:08.502200 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9769, seq 0, length 64
12:12:08.507180 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9769, seq 0, length 64
12:12:08.754163 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9803, seq 0, length 64
12:12:08.759106 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9803, seq 0, length 64
12:12:09.014062 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9830, seq 0, length 64
12:12:09.019040 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9830, seq 0, length 64
12:12:09.234272 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9860, seq 0, length 64
12:12:09.239299 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9860, seq 0, length 64
12:12:09.473781 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9887, seq 0, length 64
12:12:09.478798 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9887, seq 0, length 64
12:12:09.734096 IP 10.250.250.100 > 8.8.4.4: ICMP echo request, id 9914, seq 0, length 64
12:12:09.739113 IP 8.8.4.4 > 10.250.250.100: ICMP echo reply, id 9914, seq 0, length 64

2

Hi,

seems to be a V3 related issue (that’s why it’s called “testing” :wink: )

I’ve flattened the AR300M and flashed 2.27 back … all looks relaxed again.

3

The traffic is from MWAN3.

You can remove it.

mwan3 stop
opkg remove mwan3
1 Like
4

@kyson-lok
Thank you! Although it was not as bad as with V3, I still saw pings also on 2.27. I’ve removed MWAN3 and now the only traffic I see on the WAN is the keepalive of my OpenVPN connection! :slight_smile:

I’ve still two questions:

This huge traffic increase started when I changed the old modem stick which has lost connectivity against the Huawei stick which supports tethering. It seems that there is a difference between WAN as 3G modem and WAN as tethering concerning that awful traffic.

What’s the purpose of MWAN3? Any drawbacks not running it?

5

In v2.x firmware, the mwan3 only track tethering interface, it won’t track modem interface, so if you use usb stick as tethering, it is the same as v3.x firmware, which will consume extra data traffic.

The mwan3 is used to failover, it means that if there has two or more than two methods for Internet, such as cable and modem. When the cable lost the connection, it will switch to modem, so you can still access the Internet. It will back to cable when it is available again.

If you don’t need to failover function, there is not affected.

1 Like