ATT Uverse RG Bypass (0.2 BTC)
-
@DefenderLLC would it theoretically be possible if you had a pfSense box that had a fiber input used as WAN? Unless there's a reason someone is using that same certificate type that's using the Ethernet rule. I don't have either but was curious if someone may have tried that option.
-
@Zaf9670 said in ATT Uverse RG Bypass (0.2 BTC):
@DefenderLLC would it theoretically be possible if you had a pfSense box that had a fiber input used as WAN? Unless there's a reason someone is using that same certificate type that's using the Ethernet rule. I don't have either but was curious if someone may have tried that option.
You cannot do this with the newer AT&T gateways like BGW320 (newer installs in the past 2 years). The ONT module is built-in to the modem itself and it must be used in conjunction with the SFP+ module that they provide to authenticate the service. There's no getting around it for new AT&T Fiber installs unless they happen to give you an older modem and separate ONT box which would be very rare unless they have no way to get the fiber to the modem directly.
-
Thanks to C McDonald (@cmcdonald ), there's a new wpa_supplicant out which now listens on vlan0. Netgraph or vlan stripping switches no longer needed.
code
https://reviews.freebsd.org/D40442You can either compile your own or get the binary in this thread on dslr
source - https://github.com/freebsd/freebsd-src/tree/main/contrib/wpa
binary (for 23.05) - https://www.dslreports.com/forum/r33686937-
Future versions of pfsense will come with the new binary.
As this is using wpa_supplicant, certs are still required. Existing wpa_supplicant.conf is still usable.
For implementing, 2 shell command lines are really all that's needed.
earlyshellcmd
/sbin/ifconfig igb0 ether "RG MAC" && /root/wpa_supplicant -B -Dwired -i igb0 -c /root/wpa_supplicant.conf -P/var/run/wpa_supplicant.pid && sleep 10 && /usr/sbin/wpa_cli logonAdjust paths and interface as needed. RG mac should be in the form of "11:22:33:44:55:66". Probably works without the double quotes, but given the sequence contains colons, quotes preferred.
shellcmd
wpa_cli logoff && sleep 10 && wpa_cli logonDon't forget to update the wan interface to reflect correct interface, not ngeth0. Also for now, mac spoofing still in effect, but we're testing if that's really needed.
This sequence should provide a relatively fast boot, without the 60s delay at the "configuring wan interface..." line. The logon commands are there to speed things up. Normally the upstream sends a username request to the gateway (or supplicant in this case) every 30s until a response is received. The login command expedites this.
In testing, wan ip via dhcp was generally obtained right at the end of boot or within a few seconds after.
-
@GPz1100
The wpa_supplicant.conf is the pfatt.sh correct? Or is there a specific .conf file to get?Thanks
-
@AiC0315 I use the conf that was generated when I extracted the keys
-
@AiC0315 You could use the pfatt script, but will need to modify it to remove all references to netgraph. It applies configuration a bit differently but it's the same values. Also, pf's native dhcp works, so that line too can be commented out.
The command lines I posted earlier are simple enough, don't really see a need for a script. You can add a
-sto enable logging to syslog.wpa_supplicant.conf is the one created with the devicelocksmith tool when generating the certs. You will need to a line early on for wpa_cli to work.
ctrl_interface=DIR=/var/run/wpa_supplicantunder the last comment (#) line.
-
@GPz1100 Thanks, I bought my certs so I don't have the .conf. I have the 5268. not sure if there is a way to get the certs from that without desoldering?
-
@AiC0315 If you got your certs from a seller respecting devicelocksmith's tool license, then you should have just received the mfg.dat and some CA certs. You had to run the tool to generate actual usable (by wpa_supplicant) certs.
If not, the format looks like this.
wpa_supplicant.conf
# Generated by 802.1x Credential Extraction Tool # Copyright (c) 2018-2019 devicelocksmith.com # Version: 1.04 linux amd64 # # Change file names to absolute paths ctrl_interface=DIR=/var/run/wpa_supplicant eapol_version=1 ap_scan=0 fast_reauth=1 network={ ca_cert="{PATH TO CA CERT.PEM file}" client_cert="{PATH TO CLIENT CERT.PEM file}" eap=TLS eapol_flags=0 identity="{RG MAC}" # Internet (ONT) interface MAC address must match this value ie 11:22:33:44:55:66 key_mgmt=IEEE8021X phase1="allow_canned_success=1" private_key="{PATH TO PRIVATE KEY.PEM file}" } -
@GPz1100 I found the original files and was able to get it sorted out. Thank you for your help!!
-
@GPz1100 I'm using the dfp-34x to bypass the AT&T ONT and RG, but curiously, I don't need to authenticate at all with the DFP-34X. Does anyone know why I no longer need to authenticate with wpa_supplicant when bypassing the ONT? I've read conflicting info about whether authentication should be needed or not.
Prior to bypassing the ONT with the dfp-34x, I was using AT&T ONT -> Swtich (strip VLAN0) -> Pfsense, but could not pull IP unless I authenticated with wpa_supplicant.
-
@AiC0315 said in ATT Uverse RG Bypass (0.2 BTC):
@GPz1100 I found the original files and was able to get it sorted out. Thank you for your help!!
It's because the authentication isn't really needed (there is long thread on DSLreports that proves that 802.1x authentication isn't necessary). What is needed is a compatible ont or ont sfp+ (2.5 gig sensing, which isn't in all ont or ont sticks), that is spoofed to the mac address and type of RG. That is why you can bypass the ont and RG. The only hold up was that most firewalls wouldn't recognize vlan0 on the wan. There are numerous people like myself who no longer use the RG and ONT. I do have the 5gig connection so I'm not on the older GPON, I'm on XGS-PON. But it works 100% without extracting certs. I personally have been using the Azores WAG-D20 for about a year now. The only time I have ever had my bgw320-505 powered on is when AT&T had to replace my fiber line when tree cutters dropped a tree on my fiber line and cut it. So they could run a line test.
-
@untamedgorilla Thanks, I've consistently seen that XGS-PON doesn't use authentication in the same way as GPON - but, I'm on GPON. I have seen the DSLreports thread but then again on the discord there are conflicting discussions. I guess I should be happy with it and let it go but concerned its just a temporary fluke in my setup.
-
@DefenderLLC I understand the box is combined but that doesn't necessarily mean the process is different to intercept/use. It sounds like the replies after ours show it has had some mixed success unless the all-in-ones register differently between models.
-
@Zaf9670 said in ATT Uverse RG Bypass (0.2 BTC):
@DefenderLLC I understand the box is combined but that doesn't necessarily mean the process is different to intercept/use. It sounds like the replies after ours show it has had some mixed success unless the all-in-ones register differently between models.
I certainly hope so. Most of them seem to have the BGW310. I have the BGW320 and I haven't seen anyone crack the cert/keys on that one yet. It's really not that big of a deal to me as I'm not experiencing any packet loss, but if someone gets it to work then I would love to try it.
-
@anyn12 said in ATT Uverse RG Bypass (0.2 BTC):
@GPz1100 I'm using the dfp-34x to bypass the AT&T ONT and RG, but curiously, I don't need to authenticate at all with the DFP-34X. Does anyone know why I no longer need to authenticate with wpa_supplicant when bypassing the ONT? I've read conflicting info about whether authentication should be needed or not.
Prior to bypassing the ONT with the dfp-34x, I was using AT&T ONT -> Swtich (strip VLAN0) -> Pfsense, but could not pull IP unless I authenticated with wpa_supplicant.
Based on discussions on discord, it appears some on GPON users are connected to an olt that allow traffic without 802.1x auth taking place. That is, even when using the stock 010a ont.
Then there's your sfp which maybe spoofing a successful 802.1x response upstream. In terms of xgspon, it would appear 802.1x auth is not used (at this time?) with such implementations so devices such as the azores wag20 work with just serial/mac spoofing.
One thing is clear, att is consistently inconsistent.
-
S stephenw10 referenced this topic on
-
@untamedgorilla said in ATT Uverse RG Bypass (0.2 BTC):
Azores WAG-D20
So you are saying
Even though i have 1 Gig Att Fiber with a Pace 5268AC
i can use a Azores WAG-D20 to replace my Pace 5268AC and connect it directly to my pfsense box?
No headaches or setup just plug and play? -
@Eddie55 it's not that easy. If you're on the Pace rg you likely have GPON, so the Azores ont won't work.
-
@dreamdenizen
what would you recommend i do
i currently havePace 5268AC
4 port pfsense router
Unifi 24 port poe managed switch -
I have never been able to update past 22.05, but previously didn't have the time to extensively debug the issue. I am also starting to care more as I don't want to be running an unpatched, insecure system indefinitely. I am using the supplicant method which works great on 22.05. Certs are extracted from my BGW210, not purchased. Here is what happens if I execute the script manually in 23.01.
pfatt 59368 - - starting pfatt... pfatt 59524 - - resetting netgraph... pfatt 60893 - - creating vlan node and ngeth0 interface... pfatt 61867 - - enabling promisc for igb0... pfatt 63602 - - starting wpa_supplicant... pfatt 63884 - - terminating existing wpa_supplicant on PID 42344... pfatt 76978 - - wpa_supplicant running on PID 76616... pfatt 77163 - - setting wpa_supplicant network configuration... pfatt 87692 - - waiting for EAP authorization... pfatt 17137 - - EAP authorization completed... pfatt 17614 - - no IP address assigned, force restarting DHCP... dhclient not running? (check /var/run/dhclient/dhclient.ngeth0.pid). DHCPREQUEST on ngeth0 to 255.255.255.255 port 67 DHCPREQUEST on ngeth0 to 255.255.255.255 port 67 DHCPDISCOVER on ngeth0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on ngeth0 to 255.255.255.255 port 67 interval 13 My address (104.62.99.47) was re-added DHCPDISCOVER on ngeth0 to 255.255.255.255 port 67 interval 12 My address (104.62.99.47) was deleted, dhclient exiting pfatt 67484 - - IP address is ... pfatt 67576 - - ngeth0 should now be available to configure as your WAN... pfatt 74890 - - set mac address on ngeth0...I never get an IP and the WAN remains down. Does anyone have any thoughts? My pfatt script is attached. pfatt.txt
-
The bug in e1000 that stopped it passing vlan0 tagged traffic is fixed in 23.09(.1) so try that.
You can probably do that directly without netgraph there too since both WPA and dhclient can now accept vlan0.
