ATT Uverse RG Bypass (0.2 BTC)
-
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.
-
@slushieken maybe this might help? http://www.macfreek.nl/memory/FreeBSD_kernel_cross-compiling
-
Can you send support @Netgate a request to get a the cherry picked patch put into the main distribution? They really should just put the fix into the next release of the code so folks don't have to manually patch it, esp for appliance users.
-
@fresnoboy said in ATT Uverse RG Bypass (0.2 BTC):
Can you send support @Netgate a request to get a the cherry picked patch put into the main distribution? They really should just put the fix into the next release of the code so folks don't have to manually patch it, esp for appliance users.
How do I reach them? I don't have a paid support package...
--Edit-- I figured it out and opened a ticket. I'll reply with any feedback.
-
It looks like it should be possible to include this, it's a one line patch, but because it's not in 12-stable we would need to review what impact it might have.
Steve
-
Thanks for looking into this. It would be a blessing to many users to get this incorporated, but especially those on your appliances, as it's more painful to build a manual patch for them.
The patch has been successfully installed on many user's machines and had no issues reported so far.
Please let us know what you guys decide.
-
When you say 'patch' I assume you mean the patched SSL libs since this is not something that can be patched on an installed system directly.
-
Sorry if I wasn't clear. By "cherrypick", I meant take the patch from the v13 version of wpa_supplicant and apply it to the current pfsense wpa_supplicant code. It's an easy one line change: https://cgit.freebsd.org/src/commit/?id=d70886d063166786ded0007af8cdcbf57b7b4827
-
That should now be in current 21.09/2.6 snapshots if anyone is able to test.
https://github.com/pfsense/FreeBSD-src/commit/61c7d15d84f80ae1d92b42dc2da56ad94a80b46bSteve
-
This is now also in 2.5.2 snaps. Feedback appreciated.
-
Hi All,
I'm using frontier 1gb fiber service for my internet and I have a strange issue when using the netgraph script.
Currently my setup is using a pfsense instance on a Hyper-V server which is great because the virtual switch strips the vlan tags so my pfsense works great natively. My speed test show about 940mbp up and down on my hyper v instance.
If I use a use pfsense on comparable hardware directly on a metal box using the netgraph script I get speed tests of about 750mbs down and 840 up consistently. CPU and memory aren't even breaking a sweat. I would have expected speeds of around the same as my Hyper-V since that PC is actually using more resources. Not to mention other than adding the netgraph script I'm using pfsense straight from installation without making any other changes.
I'm happy to post any benchmarks and would love to hear this groups thoughts on this.
Thanks -
@michaellacroix recommend you look through and tune/test interface settings eg:
NIC Flow Control
NIC Offload
NIC Rx Buffer
NIC Tx BufferThese being out of tune for best performance on your particular platform likely would explain that amount of speed discrepancy.
-
Great idea! I will try that as soon as I get home. These are intel em cards.
-
@stephenw10 I upgraded from 2.4.4 with no issues. I'm using supplicant mode.
-
I'm using the latest 2.5.2 release.
-
So I tried making changes to tune my interface settings which made no difference in speed.
I did however remove netgraph from the equation and set a static IP from the dhcp pool and it also made very little difference in regard to speed. I think the hyper-v vmswitch is just stripping out all the crap from my ISP's connection allowing for the best connection and performance.
If that's the case I guess I'm stuck using pfsense as a vm. I would have much rather preferred using dedicated equipment instead. -
Mmm, yeah if you're going through a v-switch and trying to use vlan0 I could certainly see that causing problems!
-
I got the "joy" of receiving the BGW320-500 device in my new house. Let me know if anyone wants me to test anything regarding a potential bypass. I'm reasonably strong with Linux/UNIX and have a fair bit of hardware laying around that can run pfsense and others.
