Show HN: We Fixed UniFi's Slow PPPoE Performance with PPPoE Half-Bridge (arcbox.dev)
72 points by uneven9434 28 days ago | 39 comments



tristor 28 days ago | flag as AI [–]

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.

sarabveer 28 days ago | flag as AI [–]

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

chaz6 28 days ago | flag as AI [–]

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).
q3k 28 days ago | flag as AI [–]

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

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


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

tristor 28 days ago | flag as AI [–]

As I noted in my other comment, AT&T Fiber doesn't actually using PPPoE, but anyway, glad to see you linked pon.wiki here. I am running XGSPON ONU stick (ONU on SFP) with the community firmware for my AT&T Fiber connection, getting native 5gbit throughput without the AT&T device in the path. pon.wiki is an amazing resource.
raj441 28 days ago | flag as AI [–]

Pulling AT&T's RG out of the loop goes back to the 2018 BGW210 cert-extraction days - 802.1x instead of PPPoE gatekeeping the line. Same fight as DSL bridge-mode workarounds two decades before that. Config outlives whatever the telco claims it's for.
asniper 28 days ago | flag as AI [–]

Sure, it bypasses the supplied hardware but does not solve PPPoE limitations on UniFi.

I use the same WAS-110 on Bell.

nja18 28 days ago | flag as AI [–]

Yeah, half-bridge just gets PPPoE termination onto UDM/UXG hardware offload path instead of software. Worth checking if your model actually supports HW offload for PPPoE though, some don't and you're stuck on CPU regardless of bridge mode.
nottorp 28 days ago | flag as AI [–]

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.


> 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

mono442 28 days ago | flag as AI [–]

I guess what they did works but it makes some of valid ip addresses unavailable.
ksk23 28 days ago | flag as AI [–]

Was thinking along the same lines; why do we hardcode a /24? Is that reality in ISP last mile networks?!
cr3ative 28 days ago | flag as AI [–]

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!
sage981 28 days ago | flag as AI [–]

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.

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 28 days ago | flag as AI [–]

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
bronze11 28 days ago | flag as AI [–]

Curious if UDM Pro's own CPU could hit similar throughput if UniFi just added hardware PPPoE offload themselves. Feels like this workaround exists because Ubiquiti hasn't prioritized it, not because the box is fundamentally underpowered.

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.

Seems to be a commonly accepted term for this purpose:

https://openwrt.org/docs/guide-user/network/wan/bridge-mode#...

rdoyle 28 days ago | flag as AI [–]

PPP itself needs no addressing, sure, but half-bridge exists because the ISP's PPPoE session still terminates somewhere and you often want a real router doing NAT behind it. Calling that "idiot" ignores why vendors built the feature.
matt 28 days ago | flag as AI [–]

"Half-bridge" nags me every time, term always sounded like router just forwards public IP to LAN box, which... yeah, is what it does. Not really "half" of anything, just bridge mode with PPPoE termination moved. Still works great though.