| 13 Jun 2025 |
 @magic_rb:numtide.com | will try cutting | 14:51:11 |
| @magic_rb:numtide.com | also | 14:51:14 |
 emily | the more I investigate this PPP stuff the less sense it makes | 14:51:32 |
| @magic_rb:numtide.com | https://gitlab.com/K900/nix/-/blob/master/shared/platform/bpi-r4.nix#L70 what does this do? | 14:51:39 |
| @magic_rb:numtide.com | why is it there, i copied it but i have no clue why its there | 14:51:47 |
| emily | OpenWrt:
Fri Jun 13 14:22:09 2025 daemon.debug pppd[3465]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xa3c5f758>]
Fri Jun 13 14:22:09 2025 daemon.debug pppd[3465]: rcvd [LCP ConfReq id=0x49 <auth chap MD5> <magic 0x45a13285>]
Fri Jun 13 14:22:09 2025 daemon.debug pppd[3465]: sent [LCP ConfAck id=0x49 <auth chap MD5> <magic 0x45a13285>]
Fri Jun 13 14:22:09 2025 daemon.debug pppd[3465]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xa3c5f758>]
Fri Jun 13 14:22:09 2025 daemon.debug pppd[3465]: sent [LCP EchoReq id=0x0 magic=0xa3c5f758]
NixOS with the exact same MTU/MRU configuration:
Jun 13 14:47:09 bpi-r4 pppd[1784]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x549f006a>]
Jun 13 14:47:12 bpi-r4 pppd[1784]: rcvd [LCP ConfReq id=0x80 <auth chap MD5> <magic 0x40db49af>]
Jun 13 14:47:12 bpi-r4 pppd[1784]: sent [LCP ConfAck id=0x80 <auth chap MD5> <magic 0x40db49af>]
Jun 13 14:47:12 bpi-r4 pppd[1784]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x549f006a>]
Jun 13 14:47:15 bpi-r4 pppd[1784]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x549f006a>]
Jun 13 14:47:16 bpi-r4 pppd[1784]: rcvd [LCP ConfReq id=0x81 <auth chap MD5> <magic 0x40db49af>]
Jun 13 14:47:16 bpi-r4 pppd[1784]: sent [LCP ConfAck id=0x81 <auth chap MD5> <magic 0x40db49af>]
Jun 13 14:47:18 bpi-r4 pppd[1784]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x549f006a>]
[gets stuck forever]
| 14:52:04 |
 K900 | In reply to @magic_rb:numtide.com
https://gitlab.com/K900/nix/-/blob/master/shared/platform/bpi-r4.nix#L70 what does this do? What, the runCommand? | 14:52:19 |
| emily | how come NixOS sends the exact same requests as OpenWrt, but the ISP acks it when OpenWrt does it and ignores NixOS??? | 14:52:23 |
| @magic_rb:numtide.com | yeah | 14:52:33 |
| K900 | Saves me from uploading 700MB of linux-firmware to the thing every other week is what | 14:52:34 |
| @magic_rb:numtide.com | oh so you build a firmware which contains only firmware you actually need? | 14:52:55 |
| K900 | Less relevant now that it's on a non-shit drive | 14:53:02 |
| @magic_rb:numtide.com | so i shouldnt need that, got it | 14:53:13 |
| K900 | But copying that to the eMMC fucking suuuuuuuucked | 14:53:22 |
| K900 | In reply to @magic_rb:numtide.com
oh so you build a firmware which contains only firmware you actually need? Well, "build", as in I just yoink the one directory I care about from nixpkgs linux-firmware | 14:53:43 |
| @magic_rb:numtide.com | last time i had that, it was due to the hardware of the bpi not being able to handle sub 40 byte packets properly, but that fixed made it into franks tree (courtesy of yours truly) and then i assume into k900's tree and maybe mainline? | 14:54:03 |
| @magic_rb:numtide.com | yeah i just was confused what youre doing there, because it seemed like you were doing exactly what you were doing, but i failed to consider the why | 14:54:23 |
| @magic_rb:numtide.com | now it makes sense :) | 14:54:27 |
| @magic_rb:numtide.com | okay, ill try the hard reboot | 14:54:42 |
| emily | wait are you on PPP too? | 14:54:49 |
| K900 | I am actually not sure if that fix is in mainline | 14:54:59 |
| @magic_rb:numtide.com | yes, KPN in the NL does PPPoE | 14:55:01 |
| K900 | But it's not in mainline..my current tree | 14:55:08 |
| @magic_rb:numtide.com | well, it must be somewhere, because my internet works | 14:55:25 |
| K900 | On 6.16-rc1? | 14:55:34 |
| @magic_rb:numtide.com | uh | 14:55:42 |
| @magic_rb:numtide.com | no 6.1 | 14:55:49 |
| emily | if there's a kernel patch I can try applying I'll apply it. | 14:55:52 |
| @magic_rb:numtide.com | * no 6.15 | 14:55:53 |
| @magic_rb:numtide.com | right, so emily if youre on 6.16 you probably dont have the fix | 14:56:03 |
