Rendered at 14:43:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
chaz6 6 minutes ago [-]
A lot of people dunk on PPPoE, but it does have one redeeming feature: failover is a lot easier and faster compared to IPoE. With IPoE you often rely on vendor-proprietary mechanisms. The closest thing to a common standard is packet-triggered sessions. Normally, BNG's set up sessions using DHCP but you can rig it to do a RADIUS request for a non-DHCP packet without a known session. In this case, it will send the source IP as the radius username, rather than the configured value (this usually comes from dhcp option 82 which includes the customer-id and circuit-id). In an access network, the source address is usually untrusted so instead you would want to have your BNG attach the NAS-Port-Id to the request (which usually contains the SVLAN and CVLAN).
sarabveer 3 hours ago [-]
> Even in 2026, a huge number of ISPs still rely on PPPoE, including Bell Canada, AT&T Fiber, and Xfinity in the US, along with the vast majority of ISPs in Europe, Asia, and China.
Comcast (Xfinity) does not use PPPoE.
tristor 15 minutes ago [-]
PPPoE is pretty much only used for DSL in the US. I'm not sure about elsewhere.
Xfinity and AT&T Fiber do /not/ use PPPoE. Xfinity is built on DOCSIS, and AT&T Fiber is built on XGSPON. This means neither one relies on PPPoE at the data link layer. XGSPON uses XGEM/XGTC at data link layer, DOCSIS uses MAC (same data link protocol as Ethernet).
This article is making a bunch of assertions which are just patently false. PPPoE is basically old hat at this point. It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
davidhariri 4 hours ago [-]
In my specific situation I was able to use this WAS-110 to get full speed PPPoE from my fiber provider (Bell).
Sure, it bypasses the supplied hardware but does not solve PPPoE limitations on UniFi.
I use the same WAS-110 on Bell.
nottorp 3 hours ago [-]
Oh thanks. My local ISP insists on pppoe even for business lines.
I like the unifi APs but then using their gateways is a no-no.
cr3ative 5 hours ago [-]
I always suspected this was possible but having it demonstrated is excellent. I would assume this would be of most benefit on an OpenWRT box which _does_ support hardware offload!
q3k 5 hours ago [-]
I miss when this kind of content would've just been two paragraphs and a config snippet.
(also, this isn't a "Show HN")
mono442 5 hours ago [-]
I guess what they did works but it makes some of valid ip addresses unavailable.
ksk23 4 hours ago [-]
Was thinking along the same lines; why do we hardcode a /24?
Is that reality in ISP last mile networks?!
hayleyest 2 hours ago [-]
AT&T offers only a /25 here. But it's just a shell script, adjust to whatever your flavor is. You can hardcode in your own netmask, bits, and gateway without any issue.
simonjgreen 4 hours ago [-]
I mean at this point just ditch the Unifi? You have a much more capable gateway in play now that needs to have equal to greater throughput than the one you are bridging for.
p_l 4 hours ago [-]
No, the half-bridge is less capable for various functions, but happens to have hardware PPPoE offload which makes it faster for this specific function but not for others
Ballas 1 hours ago [-]
Could you go into more detail - how is the half-bridge less capable? (I'm not familiar with ether device, but the ultimate solution seems like a sub-optimal solution to me?)
p_l 57 minutes ago [-]
Essentially, it's a case of smaller device with less powerful CPU and less powerful routing offloads, but which happens to have a hardware offload for the specific use case that they needed offloading - PPPoE.
As the article itself mentions, hardware PPPoE is often present on lower shelf chips, but missing from higher end chips that in turn have more switching/routing capabilities.
effnorwood 2 hours ago [-]
[dead]
sage981 3 hours ago [-]
The UCG Fiber numbers make the case: this is a SoC acceleration gap, not a PPPoE overhead problem. Half-bridge is a workaround for hardware Ubiquiti shipped.
Comcast (Xfinity) does not use PPPoE.
Xfinity and AT&T Fiber do /not/ use PPPoE. Xfinity is built on DOCSIS, and AT&T Fiber is built on XGSPON. This means neither one relies on PPPoE at the data link layer. XGSPON uses XGEM/XGTC at data link layer, DOCSIS uses MAC (same data link protocol as Ethernet).
This article is making a bunch of assertions which are just patently false. PPPoE is basically old hat at this point. It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
https://pon.wiki/guides/masquerade-as-the-bce-inc-giga-hub-2...
I use the same WAS-110 on Bell.
I like the unifi APs but then using their gateways is a no-no.
(also, this isn't a "Show HN")
As the article itself mentions, hardware PPPoE is often present on lower shelf chips, but missing from higher end chips that in turn have more switching/routing capabilities.