script doesn't use interface vlan for looking up gateway to ping

[radicand]

I'm not sure if this should go as a PR for the README, but I'd search issues first personally so I'm putting this here for others. Readme or code can be updated as you see fit.

1. The default eap_proxy.sh script does not have the --set-mac line specified by default. You need to add this in.

2. The default --ping-gateway argument did not work for my AT&T Fiber setup, and resulted in the link cycling every few minutes. I changed this to --ping-ip 1.1.1.1 and it works perfectly now.

So if you're on AT&T Fiber, you will need to update 1., and possibly need 2.

[jaysoffian]

Thanks for the feedback.

1. is already in the README:

Update the MAC address for eth0 vif 0 to that of your AT&T router, or let eap_proxy do it with the --set-mac option. I prefer to set it in my router config.

2. is YMMV. I use AT&T Fiber and have no problems without it.

[jaysoffian]

The problem with 1.1.1.1 is that it's not on AT&T network, so it might not be reachable for reasons other than your fiber link being down. The same is true of the gateway, but much less likely since it's the closest IP to the other end of your fiber link. I'm not sure why the gateway isn't pingable in your case. Is it pingable now that your link is up?

[radicand]

Thanks for the quick follow up; missing the --set-mac was my bad.

What's strange is the gateway is in fact pingable, but changing it back to ping-gateway results in the same end loop of reauthenticating and restarting dhclient (which cycles my network connection every minute). Changing back to --ping-ip with the actual gateway IP works. Further investigation revealed that the getifgateway routine was retuning None. I'm looking into this and will follow up with what I find.

[radicand]

Ok, I've gotten to the root of the issue.

ping_wan_gateway is asking for the interface name, but the routing table (on my USG 3P at least) returns a list with the interface.vlan. Example (addresses redacted):

root@Gateway3P:/config/scripts# cat /proc/net/route
Iface	Destination	Gateway 	Flags	RefCnt	Use	Metric	Mask		MTU	Window	IRTT
eth0.0	00000000	FFFF0001	0003	0	0	0	00000000	0	0	0
eth0.0	FFFF0000	00000000	0001	0	0	0	FFFFFC00	0	0	0
lo	7F000000	00000000	0001	0	0	0	FF000000	0	0	0
eth2	C0A80000	00000000	0001	0	0	0	FFFFFF00	0	0	0
eth1	C0A80100	00000000	0001	0	0	0	FFFFFF00	0	0	0

Below is an updated routine which is working for me now with the --ping-gateway option.

    def ping_wan_gateway(self):
        if_wan = self.args.if_wan
        if_vlan = "%s.%d" % (if_wan, self.args.vlan_id)
        ipaddr = getifgateway(if_vlan)
        if not ipaddr:
            self.log.debug("ping: no gateway for %s", if_wan)
            return False
        self.log.debug("ping: using %s", ipaddr)
        return self.ping_ipaddr(ipaddr)

I don't know how unique this is to me, but worth noting as I felt I had a pretty vanilla setup followed from the medium post.

Regardless, thanks for providing this code -- super helpful to get free from the ATT RG.

[jaysoffian]

Thank you for troubleshooting. I'll leave this open till I can push a fix.

[jaysoffian]

Ah, I suspect 3a7e783 broke --ping-gateway for the USG. Thank you for providing the /proc/net/route output.

[jcoleman]

I wonder if it's possible that the column output or something related changed with a recent Unifi update; my install was working perfectly, then last night I upgraded the firmware, and then immediately has this every minute or so in the logs:

Feb 25 13:48:08 ubnt eap_proxy[2958]: eth2: bc:2e:48:42:c4:41 > 01:80:c2:00:00:03, EAPOL start (1) v2, len 0 > eth0                                                                                                 
Feb 25 13:48:08 ubnt eap_proxy[2958]: eth0.0: restarting dhclient  

with a corresponding connection drop.

I confirmed my install had the commit you were thinking might have broken it (but it was working for me), and after upgrading to the latest version of the script it's working again.

See also my post on DSLReports