ATT Uverse RG Bypass (0.2 BTC)
-
@GoldServe
figured it out, had to be done on a fresh pfsense startup. -
@bulldog5 you got it, script needs to run at bootup (either get the Shellcmd package or manually edit /conf/config.xml to run it at <earlyshellcmd> stage). At/after first boot, a few more adjustments may need to be made once ngeth0 is available.
@aus posted code and instructions on github, if you follow those steps, you should be good to go. Take a backup of your config.xml in case anything goes wrong and reimaging may be needed. Still confused how your connection was working before without netgraph and VLAN0 (didn't look like switch config you posted was doing that). -
Not sure, i never had any issues with that GS105 switch, i set the VLAN ID to 1 for 2 ports, ONT and PFs WAN, and the Supplicant method worked fine going through that switch without NG. That particular switch version ignores VLANID 0 which is why it works. Try setting your PFSense WAN to static assign your IP as a test and see if it works?
-
@t41k2m3
So i noticed that the config.xml clears the <earlyshellcmd> part out after the initial restart from me adding it. Does it need to only be run that one time for NG to be setup? What keeps supplicant running in the future? -
@bulldog5 I'm no expert but that does not sound right to me. Maybe you are placing it in the wrong part of the config.
The first time I did this with a manual edit I placed the command incorrectly, after </earlyshellcmd>, Note the slash. This is the END of the directive (or whatever it is called). It needs to be before that statement.
<earlyshellcmd>
/usr/local/bin/php-cgi -f /usr/local/bin/apply_patches.php
[your command goes here].
</earlyshellcmd>There is a pkg you can use, download the Shell Command package. It has an option to select early and you can use it to insert your command. Run it from the Services menu.
-
@bulldog5 similar observation as @JonH insofar as this is not expected behavior. Not sure what may be causing it in this case, however, the netgraph script needs to run at every reboot (if not, ngeth0 won't be available). Shellcmd package seems to work well and it makes it easy to add/delete scripts to run at different bootup stages, you might want to give that a try and see if that fixes the issue.
-
I have <earlyshellcmd>/conf/pfatt.sh</earlyshellcmd> right above the </system> line in the config.xml -- thats what the instructions say.
I'm familiar with the shell command pkg and have it installed/used it for the wpa_supplicant method. Just was curious why config.xml was clearing out this section after reboot.
-
Because manual edits of the config file are not guaranteed to be saved.
Use the shell command package.
-
@Derelict thought that config.xml did not get overwritten or recreated/changed at boot. is that incorrect (and if so, is the whole file reparsed or just certain sections)?
-
Manual edits outside the GUI are not supported. You can edit what is there if there is a supported configuration, but adding something like earlyshellcmd without the shell command package installed is just asking for trouble. Best to use the gui.
-
I did/do have the shell command pkg installed, same treatment.
-
That makes no sense. You'll have to post more details. Use the shell command package to make the entry and you will be fine.
-
@Derelict said in ATT Uverse RG Bypass (0.2 BTC):
That makes no sense. You'll have to post more details. Use the shell command package to make the entry and you will be fine.
but adding something like earlyshellcmd without the shell command package installed is just asking for trouble. Best to use the gui.
I read this as -- if i have the shell command package installed, i can use the <earlyshellcmd> in the config.xml. which is what I did. that still gets eliminated from the config.xml on reboot.
I will use the shell cmd package. Directions for the pfatt script might need to be updated then.
-
Yes, that was bad advice. The internet is full of it.
-
shellcmd package is easiest option here.
that said, even the pfSense book suggests hand editing config.xml in certain situations:
https://docs.netgate.com/pfsense/en/latest/book/bridging/bridging-and-interfaces.html#quickest-but-most-difficult-hand-edit-config-xmlis that bad advice? beyond @bulldog5 's issue, this is jusr an educational question about how config.xml is handled at boot time rather than whether hand editing it is advisable, supported or safe to do.
-
It is fine if you are manually changing the configuration instead of using the GUI for something that has a GUI field. The system does not know the difference when you restore the configuration.
But you should use the GUI to initially establish the necessary XML. In the instant case, that involves installing the shellcmd package.
For instance, if you are migrating a configuration from a system with em NICs to one with igb NICs it is perfectly acceptable to download the configuration, edit it to change the physical NIC names, and restore it to the new unit.
But don't expect just any manual edit to survive.
In other words, changing values in existing XML tags works (as long as your changes are sane) but you have to know exactly what you are doing if you choose to add your own tags from nothing.
-
Thanks for elaborating @Derelict, makes sense. Just speculating along those lines, as it sounded like he was using both the gui (via shellcmd pkg) and manually editing the <earlyshellcmd> section -- that may be why manual edits were lost at boot (gui superseded them).
-
Thanks for clearing it up.
-
Has anyone attempted (or ideally achieved) a bypass of the AT&T ONT? I am successfully bypassing the Residential Gateway, but I was curious about taking the fiber directly in to an SFP or SFP+ NIC. Latency should be superior by avoiding the media conversion to copper. The same NIC could then connect to a switch via fiber on a different port.
-
@jasonsansone you should look at pfatt method to bypass. I use to to plug my ONT directly into my pfsense router. https://github.com/aus/pfatt
