Show HN: We Fixed UniFi's Slow PPPoE Performance with PPPoE Half-Bridge (arcbox.dev)

I guess what they did works but it makes some of valid ip addresses unavailable.

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!

I miss when this kind of content would've just been two paragraphs and a config snippet.

(also, this isn't a "Show HN")

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.

In my specific situation I was able to use this WAS-110 to get full speed PPPoE from my fiber provider (Bell).

https://pon.wiki/guides/masquerade-as-the-bce-inc-giga-hub-2...

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.

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.

> 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.

[dead]

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.

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).

There is really so much failure in this post: crappy vendor, misunderstanding how PPP actually works (it requires no addressing at all), using "half bridge" (idiot term) instead of just using it properly. I swear people are even less informed than 20 years ago, it's very sad.

> thanks to their buggy ARP implementation, we additionally need to add static ARP entries on OpenWrt

Is there any more information about this? I'm curious what behavior they exhibit / what issues there are

[dead]