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 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 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.
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
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.
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...
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 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 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.
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
I guess what they did works but it makes some of valid ip addresses unavailable.
Was thinking along the same lines; why do we hardcode a /24? Is that reality in ISP last mile networks?!