ATT Uverse RG Bypass (0.2 BTC)
-
@Darth-Android said in ATT Uverse RG Bypass (0.2 BTC):
That said, I still do not have IPV6 working fully, and am at a loss there-- I can get a WAN IP via DHCPv6, and I can get prefix delegations for all of my LANs, but IPv6 packets just get dropped several hops outside of my network without the slightest hint as to why.
Did you set your IPv6 to DHCPv6 on your WAN and then in the IPv6 settings set a prefix? I have my prefix set to /60 and the following settings:
Use IPv4 Connectivity as Parent Interface - Checked
Request only an IPv6 Prefix - Checked
Send IPv6 Prefix Hint - CheckedOnce this is done save and then go to each non-WAN interface and set IPv6 to TRACK and then set the track interface to WAN and start with 0 incrementing by one for each interface.
-
@pyrodex Hmmmm, those checkboxes are different from what's recommended in the pfatt repo, but even with your settings I can't get more than 2 hops into AT&T's network before the packets disappear. (
traceroute6 google.com
always shows pfsense + 2 more hops, and then nothing; pfsense is connected directly to the ONT in my setup) -
@Darth-Android said in ATT Uverse RG Bypass (0.2 BTC):
always shows pfsense + 2 more hops, and then nothing
I actually seem to get a 3rd hop beyond pfsense when I uncheck Request only an IPv6 Prefix, but still no actual connectivity to external addresses.
-
@Darth-Android Interesting I may give this a try later. Though it’s working now in bridge mode and that makes me hesitant to touch it more... especially with potential changes they’re making..
Is the supplicant mode meant to be faster than bridge?
-
@shad0wca7 It should not be any faster per se, but it reduces complexity (read: failure points) and allows you to not have to find space / power for the RG.
The questions about speed are around the use of netgraph (
ngctl
) to strip the VLAN0 headers in pfsense instead of putting a dumb switch between the ONT and pfsense; netgraph is extremely flexible, but comes at a cost of CPU performance and if your CPU doesn't have enough horsepower, that could be an issue. However: Both the bridge and supplicant methods with pfatt use netgraph, so if you have the bridge method working satisfactorily, supplicant should be about the same in terms of speed/CPU usage. -
Actually if you are running pfsense as a guest under vmware, you don't need netgraph at all for the wpa_supplicant version. And this also meant for me that I didn't need to do PCI passthrough of interfaces which made VM migration to another machine much easier.
I haven't been able to figure out how to make vmotion migration work, though I did buy a dumb switch that will let me play with it when I get time and the kids aren't using the network for school.
-
Ah, yeah I keep forgetting the difference between virtualized and bare-metal. If you have something that (dumb switch, virtualization) strips the VLAN0 tags, straight supplicant without any netgraph will be faster / less CPU intensive.
-
@Darth-Android cool. I’m running bare metal on an HP T620 plus (4 core AMD Jaguar) which is ample.. I’ll leave bridge mode working for now but watch this with interest.
-
Hi Folks having some trouble wpa_supplicant seems to be hanging at starting wpa_supplicant doesn’t advance past that I put another usr/bin/logger -st before wpa_daemon_cmd and it stops right there before that command is run any ideas
-
I am running OPNsense (Don't hate me..) with the same code base and using supplicant mode with netgraph on bare metal without issues.
I get full line speed and can make my line testing with Torrents and multiple users.
-
@shad0wca7 said in ATT Uverse RG Bypass (0.2 BTC):
supplicant mode
No updates this this thread in a while. Anyone have any luck recently with supplicant mode on bare hardware?
-
@bkatt said in ATT Uverse RG Bypass (0.2 BTC):
@shad0wca7 said in ATT Uverse RG Bypass (0.2 BTC):
supplicant mode
No updates this this thread in a while. Anyone have any luck recently with supplicant mode on bare hardware?
I’ve been running it...... still have to use net graph due to vlan 0.
-
@bkatt said in ATT Uverse RG Bypass (0.2 BTC):
@shad0wca7 said in ATT Uverse RG Bypass (0.2 BTC):
supplicant mode
No updates this this thread in a while. Anyone have any luck recently with supplicant mode on bare hardware?
I'm still running supplicant mode on my SG-5100 without any issues.
-
You can get around the vlan0 requirement by using a dumb switch between the ONT and pf/ontsense box.
-
@bk150 A few different people were having issues. Specifically I and a few others were having waiting for auth issue. ATT fiber installed in the area about 2 years ago now, so may be that has newer firmware not allowing that method to work. Or could be something I am doing wrong. Who knows. I have the bridge netgraph working for last few months, I guess close enough.
-
@fresnoboy any post or walk through you know of on doing this, bridging or supplicant, when virtualizing pfSense. Interested in doing this on Proxmox, but want to be less ignorant about it before attempting.
-
I was running the supplicant bypass with the certs, that quit working for me. Then I was using the RG connected bypass and about a week or two ago that quite working as well.
-
Apparently the people who had their just stop working with any method of bypass is most likely due to upgrades in your area to XGS-PON. Supposedly the certificate isn’t enough anymore and looks like AT&T has added more checks to TR-069 that exists on the RG. Smart people are looking into it but as AT&T moves away from the separate ONT and to a combo RG/ONT this maybe dead on the vine.
-
@pyrodex
I had read about that over on the dsl forums. It's a shame, it was working very well. I am hoping someone figures out the magic solution to the new ONT/RG. Even though it has WIFI 6, i just dont want their crap in the way. -
If supplicant mode still works for you in 2.4.5-p1, has anyone tried if it still works in pfsense+ 21.02 (or pfsense ce 2.5.0)?
-
@t41k2m3 I was able to just update from 2.4.5 to 2.5.0 using the update button in the web config and everything continued to work. System updated, rebooted, and automatically reconnected.
-
This is great news. Are you using the WPA supplicant or the bridging approach with the RG?
-
@fresnoboy I'm using wpa_supplicant with extracted certificates at the moment. RG continues to sit in a box in the closet.
I did double-check my previous tweaks to pfatt.sh mentioned earlier in this thread, and they are still required for wpa_supplicant to work for me (notably, wpa_supplicant has to run on the raw interface, not the
ngeth0
interface that has vlan0 headers stripped).I've been trying to further tweak the script so that it no longer hangs on bootup if the router can't get an IP for any reason, which I've found to be a particular annoyance, but luckily everything has been super stable so it's mostly only an issue when I'm tinkering with things. If I get something working I'll upload/post it.
-
@darth-android said in ATT Uverse RG Bypass (0.2 BTC):
@fresnoboy I'm using wpa_supplicant with extracted certificates at the moment. RG continues to sit in a box in the closet.
I did double-check my previous tweaks to pfatt.sh mentioned earlier in this thread, and they are still required for wpa_supplicant to work for me (notably, wpa_supplicant has to run on the raw interface, not the
ngeth0
interface that has vlan0 headers stripped).I've been trying to further tweak the script so that it no longer hangs on bootup if the router can't get an IP for any reason, which I've found to be a particular annoyance, but luckily everything has been super stable so it's mostly only an issue when I'm tinkering with things. If I get something working I'll upload/post it.
That sounds great. I run pfsense as a VM under a vmware host, so I deal with the vlan0 tagging that way and don't use ngeth at all anymore.
As a VM it's easy to take a snapshot and revert, so I'll try the upgrade and see if I have the same success. Thanks for posting here!
-
I did the upgrade to 2.5.0 today. Went fine, and no issues with the pfatt WPA supplicant working in 2.5.0. Pretty smooth overall.
Hopefully this solves the occasional mbuf panics I was seeing in 2.4.5p1
-
So there is an issue. the wpa_supplicant on my system is showing 100% CPU utilization on one if the 4 CPUs. are other people seeing this too?
Note in my situation I am not using ngeth0 at all - just a pure bypass with the certs, and vmware doing the vlan0 processing.
This actually may have been going on before - as CPU usage seemed high before I made the transition earlier.
-
That's actually the issue that has been going on. That's why i haven't upgraded yet, i noticed in the github issues. There hasn't been an update in a bit. I was waiting for the next incremental release to see if anything changes.
-
And just FYI, 2.5.1 doesn't fix the wpa supplicant CPU locked at 100% problem. But so far, no mbuf panic either.
-
I think I may have figured out the problem. See here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252844 It seems this is the likely issue with the wpa-supplicant running at 100%, since we start it before the routing table is populated as well. The fix there would may solve our problem as well.
-
@fresnoboy said in ATT Uverse RG Bypass (0.2 BTC):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252844
So does the kill and restart of supplicant fix the issue?
-
@fresnoboy I did notice this as well after upgrading, but I simply killed & restarted wpa_supplicant and things seem to be holding fine. I’ve not rebooted the box since then, so perhaps I’ll re-encounter it at such a time. Things are still working at the moment, so I’m inclined to just not touch anything, but if there’s a fix to test ping me and I can take a look.
-
@fresnoboy have you looked into applying the patch to pfs or would that not be easy/possible?
-
I haven't tried it yet. I don't have a build environment for PFSense set up (I do have a FreeBSD VM I can play with), but the patch there looks like it's been committed to the production environment, so it should be easy for the Netgate guys to cherry pick this and include it in a beta update.
Anyone from Netgate want to comment?
-
I have written a list of easy mitigation steps for cpu usage issue. Credits go to all ppl who root caused the issue.
https://github.com/MonkWho/pfatt/issues/41#issuecomment-830450022
-
Do you have steps of how to get vlan0 working on esxi?
-
@netnerdy Thanks, that was the one hurdle which was keeping me from upgrading.
-
You need to create a new switch (it can't be the same switch as your LAN). For the Switch, set the VLAN ID to (0) None. This will strip the VLAN tags off that interface. Make sure your physical adapter is mapped to that switch, and then connect that WAN switch to an interface on your PFSense VM. Enjoy.
BTW, the snapshotting feature is super useful when updates are having issues. :)
-
Do you still use ngeth with this method? I was assuming that ngeth wouldn't be necessary in this case. I couldn't get wpa_supplicant to work with virtualized interface. It only works when I pci passthrough the raw device.
-
I run virtualized and have no need for ngeth. I think if you are using the WPA supplicant mode, and clear the vlan 0 issue, then you don't need ngeth at all.
-
I use a Netgate SG-3100 which runs ARM7 32-bit . Wondering if anyone has/can compile this same fix for that platform. Would be great to have this.
Right now I have 1 core at constant 100% CPU, and I can't downgrade on this platform easily.