| 13 Jun 2025 |
 @magic_rb:numtide.com | DFS start_dfs_cac() failed, -1 | 17:26:50 |
| @magic_rb:numtide.com | i cant get this working, no matter what channel i set it complains about "hardware doesnt support channel" | 17:41:50 |
| @magic_rb:numtide.com | also all my 5ghz channels are no IR? | 17:42:08 |
| @magic_rb:numtide.com | i love it when broken firmware makes it into linux git ffs, rolled back to whatever i have in nixos unstable and it magically works | 17:47:58 |
| @magic_rb:numtide.com | 😮💨 | 17:48:05 |
 K900 | No you shouldn't | 17:57:10 |
| K900 | Wrong regdomain? Or missing regdb | 17:57:22 |
 emily | 🫡 | 18:15:35 |
| emily | how does the fast path between the SFP+ LAN port and the twisted pair LAN ports work? | 18:16:28 |
| emily | it seems like the twisted pair ports are on their own switch and the SFP+s are just independent | 18:16:39 |
| @magic_rb:numtide.com | fucked firmware more lik | 18:17:03 |
| @magic_rb:numtide.com | * fucked firmware more like | 18:17:05 |
| K900 | I still don't quite get that | 18:17:38 |
| K900 | I have not looked at the leaked docs | 18:17:42 |
| K900 | They should be connected to the same NETSYSv3 block | 18:17:57 |
| K900 | But what that means exactly, I don't know | 18:18:02 |
| emily | do I have to do something special to make it work? | 18:18:24 |
| K900 | You probably just want a hardware flowtable | 18:18:55 |
| emily | ugh :P | 18:19:18 |
| emily | I'll need to figure out all this offload stuff soon I guess | 18:19:22 |
| @magic_rb:numtide.com | having internet is nice | 18:32:37 |
| emily | uhhh. I think my ISP might have gotten sick of how many times I've connected recently and started dropping my PPP connections | 19:20:45 |
| 14 Jun 2025 |
|  @donjoe:nanashi0x74.dev left the room. | 09:20:47 |
| 15 Jun 2025 |
 Luke | Hey folks, sorry if this is not the right room (I can ask elsewhere if this is not the correct place for questions about nginx); I recently made some updates to the Fluidd and Moonraker services to allow serving these at a path here. I've tested this on my setup, using a single path /printer/ for the new baseUrl and routePrefix options, but I am not sure the nginx declarations are correct. If someone who is an nginx expert could give it a once over I'd appreciate it. In particular, I don't know if any of the proxyPass parts are robust enough to merge yet, or if they would even work if Moonraker and Fluidd have different paths? Though it seems those services may be intended to be served at the same path? | 02:55:05 |
| K900 | Looks reasonable enough, but also, why? | 09:24:44 |
| K900 | Generally sharing the same domain name between multiple services is just A Bad Idea | 09:24:56 |
| K900 | For a variety of reasons | 09:25:00 |
|  @c3r5b8:matrix.org left the room. | 13:32:28 |
|  debtquity joined the room. | 14:03:04 |
| Luke | In reply to @k900:0upti.me
Looks reasonable enough, but also, why? It is a fairly uncommon setup (because most people with printers tend not to go about using a domain at all from my time in the 3D printing community), but some people like myself end up exposing these machines under a subpath that only gets served if the request comes from behind a VPN subnet. If you have many machines, like a print farm, you would also benefit from this sort of setup - easier to serve at a subpath than manage a ton of DNS entries for subdomains etc.
But if you mean, “why do Moonraker and the web interface share a domain?” That seems to be the default configuration already for the most part, given that Moonraker gets served at “/websocket” as this combination of apps usually runs from the same SBC and is tightly coupled to control a 3D printer running Klipper.
The pattern for these printers is as follows:
- Klipper opens a unix socket that acts as its API endpoint
- Moonraker interacts with that API socket to control Klipper, and exposes a websocket.
3 Web frontends like Fluidd or Mainsail interact with the Moonraker websocket for user control via a GUI (nobody is running their printer directly from API calls to Moonraker)
| 18:45:19 |
