[cassianoleal]

IPv6 support is basic at best. The zone-based firewall is very prescriptive and limited. ACL stuff is not great. To increase the MTU of the physical interface connected to the ISP I would need to hack a systemd unit that did it on boot (I either need it at 1508 so the PPPoE interface uses 1500, or I need to MSS clamp it and have it effectively reduced to 1492). Initial configuration requires the device to be connected to the Internet.

There were a few other niggles, and in the end I just found it easier to do what I need on OpenWRT.

[tarunupaday]

1492 is the default frame size set by unifi on wan pppoe. You neither need to know such esoteric details nor need to set them. “It just works”

You can also modify your frame size: Unifi Devices - Gateway - Settings - MSS Clamping.

In my view , unifi gives you all the power and very good defaults at a very reasonable price. Their nearest competitors (eero on consumer side and ruckus / Aruba on business side) have less features and more price.

[cassianoleal]

Read my other comments in this thread.

> 1492 is the default frame size set by unifi on wan pppoe. You neither need to know such esoteric details nor need to set them. “It just works”

It doesn't just work. It kept it as 1500 and I started having all sorts of issues. MSS clamping effectively reduces it to 1492 but that's not what I want. Something so simple as setting an interface's MTU shouldn't be a big deal, this is a dumb design choice.

> unifi gives you all the power

Yes but hides it out into creating a boot-time systemd unit to ensure it persists.

> Their nearest competitors (eero on consumer side and ruckus / Aruba on business side) have less features and more price.

Clearly you haven't read the rest of the thread. I'm comparing Unifi with OpenWRT, opnSense, vyos, etc.

I would never rely on the likes of Eero, and I don't want to shell out for enterprise gear which in fact don't tend to be great to operate either.

> You can also modify your frame size: Unifi Devices - Gateway - Settings - MSS Clamping.

This reduces my MTU inside the tunnel and even though it works, it's not as efficient as using the full 1500 MTU.

[izacus]

The MTU thing is a bit bizarre - all connections I've seen on PPPoE in practice (fiber or DSL) used 1492 MTU to fit data into frames (and ISPs configured their routers like that too). What are you trying to hack with this unusual 1508 frame size?

[cassianoleal]

It's not a hack. It's literally having the tunnel at 1500 MTU.

Check my answer to the sibling comment [0]. It's also known as mini jumbo frames, and is documented in RFC4638 [1]. And here's a post [2] talking about using it on OpenReach FTTC, which is similar to my own infrastructure, only I'm FTTP.

[0] https://news.ycombinator.com/item?id=48589677

[1] https://datatracker.ietf.org/doc/html/rfc4638

[2] https://blah.cloud/networks/enabling-mini-jumbo-frames-rfc46...

[m-s-y]

just genuinely curious about your MTU use case and why this is required...?

[cassianoleal]

PPPoE introduces an 8 byte overhead per packet. The "MTU of the Internet" is 1500, so that's what more or less everything defaults to.

This includes physical NICs on Linux, but the PPPoE interface has to tunnel through one of such physical NICs.

If the physical NIC has an MTU of 1500 (and can't be changed), the PPPoE NIC must do MSS clamping, effectively reducing the MTU from my network to the Internet to 1492. This increases fragmentation and overhead.

If I can increase the physical NIC's MTU to 1508 (and the ISP supports it, which mine does), then the PPPoE tunnel can use the full 1500 when talking to the Internet.

So, it's technically not _required_ but it's an improvement I should be able to implement easily (in OpenWRT I literally type 1508 on the MTU box for the NIC, or issue a single uci command).