Breakout supplicant and bridge methods into separate scripts
owenthewizard opened this issue · comments
The different bypass methods should be separated into (pf|opn)att_bridge.sh and (pf|opn)att_wpa.sh as they don't really overlap except for the VLAN 0 situation. Maybe that could be broken out into a script function too.
This would make it easier for people to setup and configure the bypass and ease maintenance as well.
I welcome opposing viewpoints on this issue.
N.B. The supplicant branch seems to be out of date (e.g. still using logger).
I agree. I keep meaning to sit down one of these days, cleanup the readme a little, separate bridge and supplicant, and dome some other cleanup. There's just never enough time.
Bridge mode from the supplicant script is a little outdated but it also has a section for 5268AC that might help some folks. So that should probably be rolled into the main script and readme adjusted accordingly.
I want to get rid of supplicant branch altogether and have just one main branch that has all the info. Also need to decide if "before 2.4.5" needs to be kept or not. There was a need in the old version to copy the ng_etf.ko file so that required extra steps. But people should be upgrading to 2.4.5 anyways so maybe there's no need to keep the old branch.
Maybe readme needs to be trimmed down and most of the info moved to the wiki?
I will try and work on it in next couple weeks.
But people should be upgrading to 2.4.5 anyways so maybe there's no need to keep the old branch.
I agree, I don't see a reason not to remove it once 2.4.4-p3 is out of support.
Maybe readme needs to be trimmed down and most of the info moved to the wiki?
That would be nice. My only concern is that if this repo fell to the same fate as the original, the wiki would be lost whereas a readme wouldn't. But I guess the solution of that is to backup the wiki.
Update:
Here's a draft opnatt-wpa.sh, tested working. I'll clean it up a bit before creating a PR.
Perhaps with some cleanup and a few tweaks we could get this project added as a (pf|opn)sense plugin.
I agree on the plug-in portion. I have some experience with the OPNsense plugins and have been looking for time to set aside and package this all up.
Apologies for swinging through here with a related question. I'm looking to set up pfSense + WPA supplicant. Is there an up-to-date guide kicking around anywhere, or is the best path to follow along with the supplicant branch readme from 6ish months ago?
The supplicant branch is fairly accurate. Grabbing the certs from your RG is a bit out of scope for this project but I was able to figure it out with a little google fu. I believe I have some bookmarks I can share when I'm in front of my pc tomorrow. There was a tool I used that was buggy but ended up working after a few tries and adjustments.
This script: https://github.com/iwleonards/extract-mfg
Works, maybe that is the one you referred to?
Related Reddit thread that also has links to the firmware you need and additional info: https://www.reddit.com/r/ATT/comments/g59rwm/bgw210700_root_exploitbypass/
It's not for users that need hand holding, but the process is reasonably straightforward and easy if you can run python scripts and follow instructions.
Closing the loop here. I was able to extract the certs but unable to get things working. Sounds like some markets are changing the auth process, which breaks the supplicant versions of this workaround. Ended up using bridging mode and all is well.
It sounds like your supplicant wasn't configured correctly. If they changed auth on the backend, the bridge would break too since all it sends are eap packets
Where did you read some markets were changing the auth process? That would be really difficult for them to do.
I recently moved from bridge to supplicant and it works fine for me, agree with maxfield-allison that you should re-check your setup.
I much prefer the supplicant method because bridge mode recovery (from loss of service, extended power outages, etc.) is finicky at best. With supplicant when I restore the connection it re-authorizes right away, every time and works better with my LTE failover setup. Also nice to be able to store the giant useless gateway out of sight.
To clarify, AT&T are putting out a new RG model BGW320-50x that has an integrated ONT with SFP. That DOES break the functionality of the bypass methods here. I believe they're swapping to xsg-pon and using their management system to perform additional auth. more information can be found here https://www.dslreports.com/forum/r32605799-BGW320-505-new-gateway-with-integrated-ONT
more good info here
I've been following that thread too. It's interesting and I'm glad they're rolling XG-PON out but wouldn't cause whatever problem @burnburnrocket had getting supplicant mode to work. As you mentioned @maxfield-allison if they somehow changed how auth is done on the back end in certain markets than the bridge bypass mode wouldn't work either.
Also, this is AT&T. It will take them years to roll a new ONT/gateway combo out and longer still before the current crop of certs are invalid.
The second thread you posted is more interesting in that it suggests in limited markets AT&T has started switching customers to new splitters that can handle GPON and XG-PON on the back end and the latter requires additional auth, which causes problems however that still means bridging EAP wouldn't work either. Also that thread is full of a lot of speculation, anecdotal reports and hand-wringing. I'll start keeping more of an eye on this though, and have my old gateway handy :)
Ah, apologies. Didn't mean to spread any misinformation here. Those are the threads I found, which I misunderstood to mean that the pfatt bridge solution worked even when supplicant did not. I struggled with supplicant for a few hours before giving up.
Like the other issue thread, it constantly hung at the waiting for EAP auth, preventing the router from booting. This made it extremely difficult to troubleshoot anything. After finding those posts I had incorrectly assumed I was in an area using the new auth.
No worries. "Bridge mode" can easily be confused for the gateway "bridge" (which of course it isn't but that is what it's called) and that's what those threads are talking about when they said "bridge" - they are going back to the gateway and using passthrough.
If you have EAP bridging working then you should be able to get supplicant going assuming you have the right certs. That extraction script I linked a few posts above works and will grab the certs & convert them automatically.
Hi @Ixian, I was able to extract the certs without problem after rooting my ATT box. It was the steps after that where I got hard-stuck. Maybe sometime I'll try again when I have hours to kill. Oof.
You are using pfsense or opn? Make sure you don't mix the scripts up. Past that, if you got EAP bridge working you should have no problem getting the supplicant going as well, for most people getting the correct certs is the problem. You decoded them with mfg_dat_decode right? That, and checking to make sure you are using the right paths/permissions, is all you really need to do.
I agree on the plug-in portion. I have some experience with the OPNsense plugins and have been looking for time to set aside and package this all up.
@maxfield-allison I don't suppose you have had any time for this? :)
Unfortunately I'm on a new bgw320 and haven't been bypassing for about 9 months. I've kept my ear to the ground but unfortunately I don't think there is a bypass method for this rg yet which makes it difficult to test and package a plugin.