New AT&T EAP Failures

[abock]

I woke up this morning (after about a year of eap_proxy working flawlessly) to EAP failures between the AT&T Fiber Gateway (Raleigh, NC) and UniFI Security Gateway. I am not sure of what to make of the logs other than "failure". I'm wondering if anyone else on AT&T fiber has started having similar issues.

admin@Gateway:/config/scripts/post-config.d$ sudo python /config/scripts/eap_proxy.py eth0 eth2 --restart-dhcp --ignore-when-wan-up --ignore-logoff --ping-gateway --set-mac --debug
[2019-06-18 09:20:27,844]: proxy_loop starting
[2019-06-18 09:20:47,407]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAPOL start (1) v2, len 0
[2019-06-18 09:20:47,412]: eth0.0: no IP address
[2019-06-18 09:20:47,414]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAPOL start (1) v2, len 0 > eth0
[2019-06-18 09:20:47,418]: eth0: sent 60 bytes
[2019-06-18 09:20:47,421]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 15, Request (1) id 29, len 15 [11]
[2019-06-18 09:20:47,425]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 15, Request (1) id 29, len 15 [11] > eth2
[2019-06-18 09:20:47,429]: eth2: sent 64 bytes
[2019-06-18 09:20:47,499]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 22, Response (2) id 29, len 22 [18]
[2019-06-18 09:20:47,504]: eth0.0: no IP address
[2019-06-18 09:20:47,507]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 22, Response (2) id 29, len 22 [18] > eth0
[2019-06-18 09:20:47,511]: eth0: sent 60 bytes
[2019-06-18 09:20:47,530]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 6, Request (1) id 30, len 6 [2]
[2019-06-18 09:20:47,535]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 6, Request (1) id 30, len 6 [2] > eth2
[2019-06-18 09:20:47,539]: eth2: sent 64 bytes
[2019-06-18 09:20:48,683]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 206, Response (2) id 30, len 206 [202]
[2019-06-18 09:20:48,689]: eth0.0: no IP address
[2019-06-18 09:20:48,692]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 206, Response (2) id 30, len 206 [202] > eth0
[2019-06-18 09:20:48,697]: eth0: sent 224 bytes
[2019-06-18 09:20:48,801]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 31, len 1020 [1016]
[2019-06-18 09:20:48,805]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 31, len 1020 [1016] > eth2
[2019-06-18 09:20:48,809]: eth2: sent 1038 bytes
[2019-06-18 09:20:49,707]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 31, len 6 [2]
[2019-06-18 09:20:49,711]: eth0.0: no IP address
[2019-06-18 09:20:49,714]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 31, len 6 [2] > eth0
[2019-06-18 09:20:49,718]: eth0: sent 60 bytes
[2019-06-18 09:20:49,736]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 32, len 1020 [1016]
[2019-06-18 09:20:49,739]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 32, len 1020 [1016] > eth2
[2019-06-18 09:20:49,743]: eth2: sent 1038 bytes
[2019-06-18 09:20:50,731]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 32, len 6 [2]
[2019-06-18 09:20:50,736]: eth0.0: no IP address
[2019-06-18 09:20:50,738]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 32, len 6 [2] > eth0
[2019-06-18 09:20:50,742]: eth0: sent 60 bytes
[2019-06-18 09:20:50,760]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 33, len 1020 [1016]
[2019-06-18 09:20:50,763]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 1020, Request (1) id 33, len 1020 [1016] > eth2
[2019-06-18 09:20:50,767]: eth2: sent 1038 bytes
[2019-06-18 09:20:51,756]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 33, len 6 [2]
[2019-06-18 09:20:51,761]: eth0.0: no IP address
[2019-06-18 09:20:51,764]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 6, Response (2) id 33, len 6 [2] > eth0
[2019-06-18 09:20:51,768]: eth0: sent 60 bytes
[2019-06-18 09:20:51,785]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 710, Request (1) id 34, len 710 [706]
[2019-06-18 09:20:51,789]: eth0: 00:90:d0:63:ff:01 > ATT_GATEWAY, EAP packet (0) v1, len 710, Request (1) id 34, len 710 [706] > eth2
[2019-06-18 09:20:51,792]: eth2: sent 728 bytes
[2019-06-18 09:20:52,802]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 13, Response (2) id 34, len 13 [9]
[2019-06-18 09:20:52,807]: eth0.0: no IP address
[2019-06-18 09:20:52,809]: eth2: ATT_GATEWAY > 01:80:c2:00:00:03, EAP packet (0) v2, len 13, Response (2) id 34, len 13 [9] > eth0
[2019-06-18 09:20:52,813]: eth0: sent 60 bytes
[2019-06-18 09:20:52,831]: eth0: 00:90:d0:63:ff:01 > 01:80:c2:00:00:03, EAP packet (0) v1, len 4, Failure (4) id 34, len 4 [0]
[2019-06-18 09:20:52,835]: eth0: 00:90:d0:63:ff:01 > 01:80:c2:00:00:03, EAP packet (0) v1, len 4, Failure (4) id 34, len 4 [0] > eth2
[2019-06-18 09:20:52,839]: eth2: sent 64 bytes

[csbowe]

I am also in Raleigh and noticed this when I woke up this morning as well. Have not had a chance to debug yet, but it appears I'm receiving an IP via DHCP from AT&T as viewed in ERL UI but zero connectivity otherwise. I have colleagues also using this script on their USG that have not experienced this issue.

[abock]

I just got off the line with escalated tech support and they are sending a line tech. I reset the RG to what AT&T would prefer and it still wasn’t getting an IP address. There are auth issues in the RG logs as well.

I opened this issue in case maybe AT&T had rolled out changed how they do auth as a heads up to others using the proxy who might search for similar issues today.