New PPPoE backend, some feedback
-
-
Yup me too. LL gateway works just fine for me. Which doesn't really help much.
But I think @benbng may be on to something there. Check the values in the pppoe files in /tmp. Perhaps you don't have a /tmp/pppoe0_defaultgwv6 file at all?
-
Perhaps, as the status > interface page should have 2 link local addresses listed; one for the router and one for the default gateway (as per the file in /tmp/). Pinging its own link local would give a result in µs and the default gateway address would be in ms.
I think we need to see what @benbng is looking at.
️ -
Mine is like this (since the new ppoe)
However IPV6 is working
With the old PPOE after some time the IPV6 looked to be gone, but it was still working. There is a ticket related to that old item.
However I think it is the same item.
And I did complain a couple of times that the indicated IPV6 times in the gui where IMHO also too high not correct.
And in my option all those sings are related to the same wrong way of checking the IPV6 interface
-
@louis2 can you see if you have any luck bringing up the IPv6 gateway with the following?
- Diagnostics > Command Prompt (Shell Command):
netstat -6rWn | grep ::/0 | awk '{print $2}' > /tmp/pppoe0_routerv6 - Diagnostics > Command Prompt (PHP Command):
setup_gateways_monitor(); - Status > Filter Reload (Reload Filter)
- Diagnostics > Command Prompt (Shell Command):
-
Those of you seeing the pending gateway are you all seeing it correctly if you switch back to mpd5?
I think we have a good handle on the problem here if so. Working on the correct fix.
-
@stephenw10 yep no issues when using mpd5 (with no changes to config) on CE 2.8.0
Glad to hear things are being looked into, let me know if I can test anything/provide any more logs.
-
@benbng Here's a patch you can test on 2.8.0 to work around the lack of RA issue:
https://nc.netgate.com/nextcloud/s/bt2fWWjdzT4KFHy -
@marcosm I've applied that and it's working great, thank you!
-
Nice. Thanks for testing!
-
No, and the reaction on
setup_gateways_monitor(); => Badly placed ()'s. -
Try the above patch. Your situation is exactly what it should address.
-
I did test this patch (https://nc.netgate.com/nextcloud/s/bt2fWWjdzT4KFHy), at least I hope I did.
I never did add a patch to the test set before:
- did add the URL
- add
- did not know how to start it
- so I did say start at boot
- and did a reboot
If this was the correct procedure .... the patch did not work !
-
The URL field is only for the direct commit ID. For this I would just copy/paste the patch text into the new patch directly.
Once you've created it an 'Apply' button will appear if it can be applied correctly. Click the button to apply it.
https://docs.netgate.com/pfsense/en/latest/development/system-patches.html#adding-a-custom-patch
-
Perhaps I will try that tomorrow, however why not adding the patch as ^test patch with small decription^ to the normal patch set / function !!??
-
You mean as part of the recommended patch list within the package?
That's only used for known good patches between releases, not for tests like this.
-
To clarify on what's happening with the pending gateway, in your instances IPV6CP negotiation establishes the IPv6 endpoints on the PPP session, and the link local peer address is intended to be the gateway for your DHCPv6 assigned address, with no RAs to nominate a gateway. The interface gateway is correctly set to the address of the peer endpoint by the driver, but the existing LL address on the interface is not updated with the remote destination address, and that destination address is expected to be present in order to identify the PPP gateway when the gateway monitoring setup is triggered. The patch intuits the PPP gateway from the routing table instead of the interface address in the IPv6 case. I'm working on a correction to the driver that should eliminate the need for this special case handling.
