ATT Uverse RG Bypass (0.2 BTC)
-
@AiC0315 I need them too please
-
@hfrazier since this was a public repo, do we know which is the new parent where future work should go? If he deleted/made private, there should have been a split and all the forks should have gotten reparented.
edit: looks like MonkWho is the new parent repo, based on the graph. Here's all the most recent updates for anyone who needs them https://github.com/MonkWho/pfatt/network
-
@andrewpdupuis Ah, thanks! I had found that repo just wasn't sure if it was the latest.
-
This post is deleted! -
@hfrazier Looks like the latest fork from that is found at https://github.com/neclimdul/pfatt
-
Does anyone have the zip of https://github.com/aus/pfatt/tree/supplicant ?
-
I decided to check if there were any changes to pfatt last week and found out that original is now gone and my fork became a new parent. No idea how or why.
I will maintain it to the best of my abilities. I pulled some requests and done some commits to clean things up. Screwed up a little when I was uploading the supplicant branch but got it all fixed up now. I also separated OPNsense specific script into it's own file for clarity. So currently https://github.com/MonkWho/pfatt contains the latest files.
@GPz1100 said in ATT Uverse RG Bypass (0.2 BTC):
Does anyone have the zip of https://github.com/aus/pfatt/tree/supplicant ?
A copy of it is here - https://github.com/MonkWho/pfatt/tree/supplicant. It contains most recent files. Unfortunatly this branch was not there when I originally created my fork so I had to semi-manually recreate it from a backup I had locally.
-
@MonkWho I just want to say thank you for carrying the torch. I just recently discovered this whole workaround thing - was getting discouraged trying to find a way to build the netgraph for my SG3100 - then found out it is included with pfsense now. Except on 2.4.5, the ng_etf package is missing! lol
https://redmine.pfsense.org/issues/10463
So now I must wait until 2.4.5-p1 release to be able to set this all up. Anyways, thank you for carrying on the work @aus started.
-
@glio Maybe I am missing something, I am running 2.4.5 with the supplicant bypass. I did install it on an earlier version.
-
@AiC0315 The EAP proxy is not available without ng_etf being present. I've not previously set up this stuff on earlier versions so maybe that's the difference.
-
I've heard people being able to use the supplicant mode without netgraph if they used a switch or bypass switch between pfSense and the ONT. Can anyone confirm and what model switch did you use?
I tried this on my new physical firewall with a DGS-1005G and had no luck. Any one?
-
So based on what I'm reading over the past 2+ years pfsense still requires netgraph in order to work with the 802.1x certificates?
Also of note, someone on Reddit found a downgrade loophole for the BGW210-700 which allows root access. So you can extract the 802.1x certificates and disable the auto-updates to the gateway.
Reddit post:
https://www.reddit.com/r/ATT/comments/g59rwm/bgw210700_root_exploitbypass/Pastebin with steps to perform:
https://pastebin.com/SUGLTfv4 -
This post is deleted! -
Is this expected behavior?
Running the netgraph bypass as documented at https://github.com/MonkWho/pfatt . No LANs have been routed to ngeth0 just yet.
I get about about one packet every two-three minutes from the RG: tcpdump -ei em4
10:06:30.887851 f8:2d:c0:yy:yy:yy (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 424: vlan 0, p 3, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f8:2d:c0:yy:yy:yy (oui Unknown), length 378And I get about 100 per minute from the ONT: tcpdump -ei em5
09:59:03.144906 a0:f3:e4:59:27:94 (oui Unknown) > f8:2d:c0:yy:yy:yy (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 0, p 0, ethertype IPv4, 162-224-176-1.lightspeed.stlsmo.sbcglobal.net > zzz-zzz-179-129.lightspeed.stlsmo.sbcglobal.net: ICMP echo reply, id 30739, seq 4885, length 8- $RG_IF = em4
- $ONT_IF = em5
- f8:2d:c0:yy:yy:yy / zzz-zzz-179-129.lightspeed.stlsmo.sbcglobal.net = my RG
- a0:f3:e4:59:27:94 / 162-224-176-1.lightspeed.stlsmo.sbcglobal.net = ATT
-
^^For the first one, I think that might be a byproduct of the rg not getting an ip when using the eap proxy method. That is, it keeps requesting, but because the proxy only passes 802.1x traffic, it never actually receives it.
The 2nd looks like the gateway is responding to a ping request? You have something pinging the gateway ip (162.224.176.1) often?
-
Sounds like the first one is benign, unless, it is an indicator that something else is wrong.
The second - I’m not pinging in on that IP.
Edit: The second thing, with the 100+ pings per minute, was the pfSense gateway monitor. It's now disabled.
-
What gateway box are you using? Maybe time to dump it entirely and go wpa_supplicant method?
-
@GPz1100 Worked on that last night, I’ve got the certs off of the RG and broken into PEMs. Will work on the rest this evening.
Bricked the gateway though. I think I left the file system RW when I rebooted. It’s in a boot loop.
Thankfully, I still have my Charter connection, so I’m not in an outage condition.
-
Can't get the supplicant mode to work.
I had to comment lines 205-231 of pfatt.sh to get the system to boot.
wpa_cli status says:
Supplicant PAE state=HELD
suppPortStatus=Unauthorized
EAP state=FAILUREtcpdump -i ONT_IF -e vlan says:
05:20:52.486546 f8:2d:c0:xx:xx:xx (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 22: vlan 0, p 0, ethertype EAPOL, EAPOL start (1) v2, len 0/conf/pfatt/bin/* is 755 and /conf/pfatt/wpa/* is 644
Certs import without error into the web configurator, if only to make sure that they're intact. I've since pulled them back out of there.
What could be keeping this thing from being authorized?
-
I just moved into a temporary housing situation and was told this unit has ATT U-Verse. I'm looking at the back of my current RG (BGW210-700) and it's using an RJ11 from "broadband" port to the wall. The wall port doesn't have an RJ45 connection. Are there any workarounds for this using this method?
