ATT Uverse RG Bypass (0.2 BTC)

nedyah700

Lucky!

@stephenw10 said in ATT Uverse RG Bypass (0.2 BTC):

Yes, probably. I've never tried to do that though. I'm also not burdened by AT&T.

I would probably install 2.5.2 clean.
Boot into the default install and upload the pfatt scripts.
Restore the config that presumably contains the shellcmds to run it.

Steve

timtrace

I’m getting a permissions error even though it’s 555 on the tree and the script. It’s happening if I use the installer shell, and also if I let the misconfigured pf boot and come into it by ssh. What might be happening, please?

sgc

@timtrace said in ATT Uverse RG Bypass (0.2 BTC):

I’m getting a permissions error even though it’s 555 on the tree and the script. It’s happening if I use the installer shell, and also if I let the misconfigured pf boot and come into it by ssh. What might be happening, please?

What folder is the sh in?

nedyah700

@timtrace When I clean installed 2.6.0 (and 22.01 on my pfSense+ Box) absolutely nothing I did allowed my pfatt script to runs successfully from the /cf/conf directory. I ended up moving it to /root/pfatt and everything worked. This seemed to only be an issue once I moved to a ZFS file system but who knows.

timtrace

Thanks, @stephenw10, @nedyah700, @sgc -- that worked!

For posterity :)

If you've been running in BYPASS MODE and want to get right back to it after a reinstall of pfSense and a restore of a backed-up configuration ...

1> Prepare a USB memstick:
https://docs.netgate.com/pfsense/en/latest/install/write-memstick.html

2> Choose your backup config file, make a copy, and rename the copy config.xml

3> Open config.xml in a text editor and change all references to pfatt.sh so they read like this: /root/pfatt/pfatt.sh

4> Put config.xml on the FAT partition on the memstick. Follow these instructions:
https://docs.netgate.com/pfsense/en/latest/backup/restore-during-install.html

5> Make a copy of your backup of pfatt.sh, open that copy in a text editor and make sure the values for ONT_IF, RG_IF, and RG_ETHER_ADDR are appropriate for your environment.

6> Copy the reviewed/edited copy of pfatt.sh to the root of the FAT partition on the memstick.

7> Install pfSense
https://docs.netgate.com/pfsense/en/latest/install/install-walkthrough.html

8> Near the end of the process, the installer will ask if you'd like to open a shell to make any final manual modifications. Answer yes.

9> These next commands will copy pfatt.sh from the memstick to the pfSense volume. They may not be 100% correct for all environments. Google will help you out

mkdir -p /root/pfatt
mkdir -p /mnt/usb
mount -t msdosfs /dev/da0s3 /mnt/usb/
cp /dev/da0s3/pfatt.sh /root/pfatt/pfatt.sh
chmod -R 555 /root/pfatt
exit

10> Reboot your pfSense and profit.

Caveats:

In step 9, the FAT partition on my memstick was /dev/da0s3. Yours may be different. You can start by viewing the output of this command and (probably) appending 3 for the FAT partition. Google can get you the rest of the way if you need help.

camcontrol devlist

For some reason, my installer wouldn't pick up config.xml during the installation process, so, I left my memstick plugged in for the first reboot and used the computer's boot manager to start pfSense from the hard disk. The ECL took over and all was right in the world.

If you're running pfBlockerNG in Python mode, you may have to disable Python in the DNS resolver before your fresh system will download any packages .... including pfBlockerNG. You can re-enable Python mode after everything settles down.

I hope all this typing helps someone out of a bind some day :)

t41k2m3

@stephenw10 or others - could anyone post specific config and commands to enable the new VLAN 0 support in pfsense+ 23.01?

According to a post in the thread below someone was able to get it "working successfully with AT&T [...] without the need for the pfatt [netgraph / ngeth0 interface] script."

https://redmine.pfsense.org/issues/12070

untamedgorilla

@t41k2m3 I definitely have it working. Nothing to do extra. I'm using the beta version 2.7.
2.7.0-DEVELOPMENT (amd64)
built on Mon Jan 02 06:04:33 UTC 2023
FreeBSD 14.0-CURRENT

And actually you don't need pfatt anymore at all. I don't even run it anymore. If you have gpon you just need a certain sfp+ plug, if you have xgspon (which I have, the 5gbps) you can purchase a fiber modem clone it to your current att router and you are good. I don't use the bgw320-505 ont/modem combo anymore.

stephenw10

Yeah, that feature request is to allow VLAN0 traffic and that is now working in 23.01 and 2.7. You can connect to an ISP that sends priority tagged DHCP replies and they will be passed. You will be able to pull a lease.
That doesn't mean the authentication stuff that AT&T required has changed. If your WAN still requires that you still need the pfatt script to make it happen. At least for now.
Internally we are testing with bridge-to that should make it much easier to accomplish. However if AT&T are removing the need for it that solves the problem anyway.

Steve

bigjohns97

@stephenw10 said in ATT Uverse RG Bypass (0.2 BTC):

Yeah, that feature request is to allow VLAN0 traffic and that is now working in 23.01 and 2.7. You can connect to an ISP that sends priority tagged DHCP replies and they will be passed. You will be able to pull a lease.
That doesn't mean the authentication stuff that AT&T required has changed. If your WAN still requires that you still need the pfatt script to make it happen. At least for now.
Internally we are testing with bridge-to that should make it much easier to accomplish. However if AT&T are removing the need for it that solves the problem anyway.

Steve

I have tried this personally using multiple pcp values (0,1,2) and have never been able to get an DHCP lease.

I do have an Intel e1000 based NIC and I have been disabling hwvlanfiltering before attemping to set the PCP value and run the wpa supplicant.

If someone who has done this successfully please post exactly what commands you ran to get it to work.

stephenw10

If you're connecting to AT&T and they still require auth then I expect to need the pfatt script.

If you're connecting to one of the other ISPs who use priority tagged DHCP where the cut-down script was required that should no longer be necessary in 23.01/2.7.

bigjohns97

@stephenw10 said in ATT Uverse RG Bypass (0.2 BTC):

If you're connecting to AT&T and they still require auth then I expect to need the pfatt script.

If you're connecting to one of the other ISPs who use priority tagged DHCP where the cut-down script was required that should no longer be necessary in 23.01/2.7.

Thanks Stephen, I tried posting in this thread https://redmine.pfsense.org/issues/12070 asking Christopher Cope to share what he used to get att bypass working without netgraph but he hasn't responded yet and I can't find anyway to reach out to him directly.

If there is a way to get it to work with att there are quite a few people who would love to know.

bk150

@bigjohns97

We have a discord that most of the folks from DSLreports have migrated to regarding discussion about AT&T specific bypass methods. There is a working GPON and XGS-PON bypass method. I can't speak much to the GPON method as I have XGS-PON but the XGS-PON method entails simply buying an Azores WAG-D20 and setting a handful of values on it. Once the device gets O5.1 status to the upstream OLT, you can send a DHCP request with the use of Netgraph on pfsense 2.7/23.01.

Hopefully it's not against the rules to post a link to the Discord (dm me if it gets removed): https://discord.gg/6TwFBquMTT

bigjohns97

@bk150 Let me check out the gpon method and see if it works for me, currently my ONT is terminated in the garage and I have a copper base NIC on my pfsense box so I would require a separate ONT to be able to work with current hardware.

t41k2m3

@bigjohns97 @stephenw10
thank you for your replies. in this use case (as it seems may be true for others), the old pfatt script with both netgraph and wpa_supplicant for auth continue to work in 23.01.

The question as @bigjohns97 indicated is if and how it may work without netgraph (running wpa auth directly on WAN with no other devices involved). Unless the VLAN 0 new feature does not actually work as initially described, in which case that would be good to clarify.

t41k2m3

@bk150 discord link says invite expired, is there another way to join?

ccope

@bigjohns97
Hey. Sorry for the confusion over the redmine post. I was mainly confirming the VLAN 0 was working. The bits to get ATT in particular working aren't tied into the GUI yet. There is work being done on that.

I am currently running a custom patch that hard codes some of the values for testing purposes, so it requires manual editing for each setup and isn't production ready yet.

bigjohns97

@ccope Thanks, if you ever need someone to test a possible implementation of this let me know :)

nedyah700

Hey All!

Just wanted to clear up some confusion I'm seeing in these last few posts.

AT&T is definitely not removing the need for 802.1X. There just happens to be another workaround that, for some, has eliminated the need.
We definitely still need the script for 802.1X, but the desire is to remove the netgraph portions that previously enabled VLAN 0 communication, and use the new native methods. This is the piece a few of us are struggling with.

Hope it helps!

bigjohns97

@bk150 said in ATT Uverse RG Bypass (0.2 BTC):

@bigjohns97

We have a discord that most of the folks from DSLreports have migrated to regarding discussion about AT&T specific bypass methods. There is a working GPON and XGS-PON bypass method. I can't speak much to the GPON method as I have XGS-PON but the XGS-PON method entails simply buying an Azores WAG-D20 and setting a handful of values on it. Once the device gets O5.1 status to the upstream OLT, you can send a DHCP request with the use of Netgraph on pfsense 2.7/23.01.

Hopefully it's not against the rules to post a link to the Discord (dm me if it gets removed): https://discord.gg/6TwFBquMTT

Did some research on this and this doesn't help me as I don't have XGS-PON nor do I have a newer 320 Att supplied RG. If I should ever upgrade to multi-gig service which would require a 320 based integration ONT/RG then I would have to do these GPON stick tricks and upgrade my NIC hardware on my PfSense box to accommodate. Even after that I would still be left having to send wpa_supplicant based authentication over VLAN 0.

At the end of the day we still have to send 802.1x over VLAN 0 which is what historically netgraph has been used for and what we are trying to get away from if possible with this new 2.7 PfSense implementation.

untamedgorilla

@bigjohns97 with the 2.7 devel you don't have to use netgraph anymore. The supplicant is completely unnecessary. The only part you need is the netgraph if you choose not to use 2.7