| 2 Jun 2025 |
 emily | but yeah, that makes sense, "I guess". | 12:32:39 |
| emily | yes, here too | 12:32:48 |
 magic_rb | In reply to @emilazy:matrix.org
I think your → is my ← Yep, symmetry :P | 12:33:22 |
| emily | (almost every provider using the Openreach network uses PPPoE. there are a small handful that do DHCP. this seems to be true invariant of DSL vs. fibre, I guess because the backbone network is the same in both cases.) | 12:33:24 |
| magic_rb | Ill see what freedom does (yes we have a provider called freedom) they use the KPN network, but maybe they dont so funky pppoe over it? Doing wireguard would be cool lmao | 12:34:17 |
| emily | (I expect this is because PPP infrastructure happened earlier and it just stuck. also, because most ISPs are going through one of a handful of wholesale providers who deal directly with Openreach, and I think that PPPoE vs. DHCP is a decision made at at that level, so only providers big enough to deal directly with the network can even make the choice themselves.) | 12:34:43 |
| emily | I would expect if they use the KPN network they don't have a choice about using PPPoE, based on what the landscape looks like here. | 12:35:09 |
| emily | i.e., the PPPoE is going to happen before they get their hands on the traffic, so to speak. | 12:35:20 |
| emily | have you checked whether the network supports mini jumbo frames? Openreach do here, so you can at least get a full 1500 MTU on the resulting link. | 12:35:46 |
| magic_rb | Probably, hopefully ill see on the 10th, im supposed to get fritzbox with a sfp+ pon, which ill try shoving into my bpir4 and see what happens | 12:35:55 |
| emily | (by using an 1508 MTU on the WAN link to offset the PPPoE encap overhead) | 12:36:00 |
| magic_rb | Yeah i do that | 12:36:12 |
| magic_rb | One of the rhings that broke a lot of sites for me, macos assumes 1500, or at least i couldnt get it to cooperate and if then the router would have to fragment things, cloudflare would fail to defragment it somehow | 12:37:05 |
| magic_rb | cache.nixos.org was not working at all when it was fragmenting. I still dont know wtf was up with that | 12:37:33 |
| magic_rb | I actually owe this setup to puck, (not in this room, but i think they should be somewhere in this space), cause i assumed theyd know how to set it up, which they did. I also initially had a bug where the bpi couldnt handle packets smaller than 40 bytes i think, which would break pppoe, now there is a patch at least in franks tree, which pads the frames out to 40 bytes | 12:39:29 |
| emily | I think this probably just means you had stuff configured wrong? | 13:14:49 |
| emily | macOS definitely supports MTU < 1500 | 13:14:55 |
| magic_rb | yeah probably | 13:15:04 |
| magic_rb | but its interesting that the fragmenetation broke it anyway | 13:15:24 |
| magic_rb | id expect it to be slower, but work | 13:15:28 |
 hexa | mssfix | 13:16:56 |
| emily | is there anything I can set to make sure none of the legacy networking.* stuff gets used? not sure if anything but networking.useDHCP = false; is needed to get it out of the way | 13:22:56 |
| emily | (yes I should have gone all-in on networkd sooner) | 13:24:04 |
 K900 | Uhh you can probably assert on the existence of network-setup.service or whatever | 13:27:33 |
| emily | magic_rb: looks like pppoe.so is in fact rp-pppoe these days. or at least a fork of it upstream in ppp or something. | 13:31:03 |
| emily | https://github.com/ppp-project/ppp/blob/6f3bf58b846fb320db7f68e9ecbda7992c396750/Changes-2.4#L33-L35 | 13:31:35 |
| emily | at least a common ancestry | 13:31:38 |
| emily | no idea which is better. | 13:31:46 |
| K900 | Man | 13:33:31 |
| K900 | This is giving me flashbacks | 13:33:36 |
