New PPPoE backend, some feedback
-
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.
-
Hey, I just wanted to say thanks for the new PPPoE backend! I have a Netgate 1100 and was pretty disappointed at first: after switching from my ISP’s router to the SG-1100, my DL speed dropped from around 650-700 Mbps to 450-500 Mbps. I was seriously thinking about switching to third-party hardware and reselling the Netgate. But then I came across the
if_pppoeoption and decided to give it a try. My DL speed are now back to almost what they were originally, an incredible improvement. Really appreciate it! -
Any chance we can have some logging for if_pppoe? Seems odd not being able to see the connection / chap / IPV6CP process.
️ -
Mmm, good question. You can enable the debug output but that's more like a torrent of data! Let me see....
-
@stephenw10 said in New PPPoE backend, some feedback:
....more like a torrent of data! Let me see....
Yep, that tsunami got old very quickly!
️ -
Some remarks:
- Using the old PPOE did show that the IPV6 gateway was active at startup. However probably after after a short interruption, the IPV6 gateway did show offline.
- The new PPOE does show the IPv6 gateway as unkown
- In all situations I have met IPV6 is working never the less
- I simply do NOT believe that the IPV6-address at the provider side is un kown or not ping able from within the level2-lan connecting the PPOE with the provider. That for two simple reasons 1) there is a connection 2) it is nonsense that you can not ping an IP or mac from the connection lan, independent from the type of destination address link local or a global address.
- If I assign an IP-address to the IPV6-gateway to verify the connectivity, I face two problems 1) it does not work 2) I can not access the IP-address used for verification any more for other purposes 3) it is not measuring the access time to the ISP-network, it is testing the response time of the IP-used for testing. All points are not good !! The IP-address of the providers network access point probably link local but not necessary link local should be used!
Having said this I am surely willing to help debugging the issue!
-
To be clear, those are your individual issues that need to be understood and hopefully resolved. They are not facts as to how if_pppoe behaves generally. You know this, you have been shown examples from various users where the IPv6 gateway is indeed responding correctly.
️ -
Also I think there may be some language barrier confusion here. Obviously the WAN gateway should be pingable from within the same layer 2 segment, even if the gateway doesn't chose to respond.
In pfSense the 'LAN' interface is taken to be an internal interface on a different layer 2 segment than the PPPoE connection. From a client on that segment it will not be possible to ping a link local address on the PPPoE segement, gateway or otherwise, becaue lik-local traffic is not routable.
-
@stephenw10
I'd go further as PPPoE, when used for wholesale connections or subscriber access, is Layer 3. It uses both logical and defined routing instances to partition the traffic. The routing table is there, albeit in a stricter form (specifying PP0 interface etc). As such it becomes an exception to the 'normal' link-local rules.All from the books of Juniper and Cisco of course, albeit the Juniper version is easier to digest. Personally I think the OSI Model has had its day but what do I know...
@louis2
You have an issue that is not fully understood, is not being seen by others and may be somewhat unique. I think it is best for now to avoid terms such as Layer 2 or 3 as it may not be helpful and can only add confusion.Response to ping is not mandatory or enforced, no matter what the RFCs originally intended.
️ -
Be aware that I am not at all saying that a user can directly access the ISP-node, but I am sure that PPOE interface can !!
Whats ever I it helps, I am absolutely OK to activate PPOE debug logging for a short period!
Note that my actual config is like this
ISP => ISP-fiber-interface => one of my small switches => pfSense.Internet should arrive via VLAN 6, IPTV via VLAN4 and (Old) VoIP via VLAN7.
Untagged routed to vlan1 and vlans (internet) are routed to pfSense.I did add vlan1 to be quite sure that even untagged messages are passing to pfSense. Normally I would simply have blocked untagged. However the PPPOE is assigned to VLAN6.
