PPPoE: Why is ARP still around?

Using my GL.iNet as router (firmware 3.125, latest snapshot) with PPPoE on WAN. The GL.iNet is connected to a DSL modem / switch which allows port mirroring. While monitoring the data traffic in Wireshark, I see ARP traffic. One to five seconds, again and again. Without PPP headers. The queries are for

  • 8.8.8.8
  • 8.8.8.4
  • 208.67.220.220
  • 208.67.220.222

The former are Google Public DNS. The latter is OpenDNS. I have no idea why this happens. Furthermore, when I go for PPPoE, just PPP should leave the WAN.

It sounds like the traffic is from mwan3 that constantly goes out to these 4 specific IP addresses to test for Internet connectivity. In your case of PPPoE, it would use arping instead of ping, which I don’t think has PPP headers.

I do not work for and I do not have formal association with GL.iNet

1 Like

Thanks! That was a valuable starting point for further research … However, three things:

  1. That module defaults to ping and I did not find the configuration file which changed it to arping.
  2. I could not find it, probably because it was changed already. At least after a reboot, I am not able see any arping anymore.
  3. Anyway, GL.iNet should look into this because it looks like that service is not stopped after changing the WAN port to PPPoE.

My initial configuration was a (1) factory reset, (2) latest snapshot, (3) factory reset device. It should not ARP after changing to PPPoE. @GL.iNet are you able to reproduce the issue?

In /usr/sbin/mwan3track, the validate_track_method function checks that the required type of ping command has been installed, which may be arping. I have not investigated further how it selects which tracking method to use, only that you are seeing ARP traffic.

I have found that just disabling mwan3 may not stop the pings because it may get started again by another script (e.g., gl_monitor). depending on the specific router. When I also disabled gl_monitor, the router thinks it is not connected to the Internet and disables some functions, so I just gave up.

This problem is caused by mwan3.

When WAN switches to PPPoE, the device eth0.2(WAN’s DHCP) of mwan3 is not turned off.

/bin/sh /usr/sbin/mwan3track wan eth0.2 online 192.168.113.140 8.8.4.4 8.8.8.8 208.67.222.222 208.67.220.220
ping -I eth0.2 -c 1 -W 2 -s 56 -t 60 -q 8.8.4.4

This problem has been fixed, please check https://github.com/gl-inet/gl-feeds/commit/35698d96e800ad35adf27ae33f192abe9f47ac85

2 Likes

Great. Fixed it for me. No ARP outside PPP after reseting and selecting PPPoE.

Thanks, dengxinfa.
It seems to finally fix the problem of mwan3 constantly pinging 8.8.4.4 8, 8.8.8, 208.67.222.222 and 208.67.220.220 when there is only one WAN connection. Now, there is no need to try disabling mwan3 or even uninstalling the package.

EDIT:
Oops … spoke too soon. mwan3track still running and pinging. :face_with_hand_over_mouth:
I edited /etc/config/mwan3 so it only pings 1.1.1.1 and 9.9.9.9.

wcs2228, thanks for keeping up. However, my complain was just about PPPoE and Ethernet frames without PPPoE be done in parallel. I am not sure what happens within the WAN. Did you see a blog post about this? Reading that, I do not understand why GL.iNet has mwan3 running when there is just one WAN either. Nevertheless, is that particular question not a question for support or another thread?