Keenan Tims

Since I recently moved my primary DNS to PowerDNS, I realized I can expose its API to my OpnSense and finally get support for dynamic DNS for IPv6 with host-part replacement. Now I can choose if I want to expose things natively on IPv6 PD addresses and proxied on IPv4, or proxied on both AFs, rather than proxying everything. Particularly useful for non-HTTP services.

The bits and pieces were mostly there before, but the stars never aligned for me. RFC2136 would support it, but the plugin was deprecated and never had the prefix replacement feature. ddclient plugin with the nsupdate mode in theory might have worked, but OpnSense doesn't include the nsupdate binary so that was a non-starter. Otherwise it only supports proprietary/custom HTTP APIs. Caddy does have a module for rfc2136, but the binaries in the OpnSense plugin don't include it, and host replacement isn't supported anyway. I suppose I could have written something and stuck it in a container somewhere but eh...

Happy to finally have a decent answer that doesn't depend on a 3rd party service's API.

#ipv6 #opnsense

A while back I noticed that my hosted-at-home services (media library etc.) sometimes felt very slow from outside. But never thought much of it.

Needed to do a large file transfer from home and seeing 200KB/s, finally had enough.

Only affects IPv6. Only affects traffic to the OpnSense router itself (not routed traffic), which proxies most of my services. I was ready to blame the ISP for doing weird stuff with the IA_NA address, when I confirmed it happens for the LAN PD address too.

Turns out that when I switched from VirtIO/linux-bridge to PCIe passthrough, in a quest for performance, I inadvertently and implicitly enabled TSO offload. Which is badly broken for igc devices for IPv6 traffic. And capped egress goodput to around 2mbps.

That one took me rather a bit of poking to find.

#ipv6

@hugo@social.treehouse.systems Good things come to those that wait? https://github.com/opnsense/core/pull/9923

Prototype of my next project - a PTP clock with a 1,000,000fps, 1us display, with a true displayed accuracy of better than 500ns with respect to PTP time. No, I don't know why this is useful. Maybe some high speed photography setup with a need for absolute timestamping (though I imagine this is something already offered by high speed camera setups).

I think I've got most of the hard timing stuff sorted out now, and the synchronization with PTP and display updating is working. It needs some polish, custom PCB, a case, POE, etc. but the concept is pretty much proven. Next step is to design that PCB to get away from Nucleo dev board while I continue working on the firmware.

Learned a bunch about DMA to get the us display working. The last two digits have their own SPI bus because there's barely time to transmit the 16 bits at max clock within 1us. To make this work practically, I generate a 100-entry table of display updates, and just DMA circularly through it with transfers triggered by a PTP synchronized timer. Synchronized timers also generate the display latch signals which actually update the display. Getting it all to work was tricky, it uses 3 cascaded timer peripherals, 2 DMAs and 3 different ISRs to handle the time sync and display updates.

Actually validating the time offset of the _displayed_ value will be interesting. I'm thinking a fast photodiode on one or the digits or something. No idea what the actual time delay of an LED is (though it should be well less than 100ns I think).

PS I'm not sure what's going on with the minutes display, but ignore that, it's some assembly issue or a bad chip. Whatever it is isn't too pertinent to the timing etc. problems I've been solving.

#timenuts

The hypocrisy of a bank insisting I give my password for my account at another bank to 3rd party Flinks/Plaid, while insisting in the ToS that if I did so with their account, they're no longer liable for fraud.

Maybe https://woodpecker-ci.org/ is worth a look? Been quite happy with it, but it might not be a good fit for ngscopeclient.

#nasa if you're going to frame #Artemis as an international effort, and accept international financial, crew, and engineering contributions, the least you could do is speak & show metric once in a while on your broadcasts...

RE: @whitequark@social.treehouse.systems

No consumer routers for Americans, I guess. No consumer internet to follow?

USB Audio Class 2.0 has been a bit of a white whale 🐳 for me since sometime around 2018. Pretty much necessary for custom USB-based high performance audio hardware.

Today I finally got my own implementation playing smoothly for the first time 🥳 . Still some way to go, but the class implementation itself is solid, I think.

A brief history:
~2018: Hardware based on XMOS, software based on their reference implementation. Smooth playback, but limited flexibility and complicated, non-portable code, and these chips are $$$.
~2022: Try to cost optimize, select LPC5526. Using the reference NXP implementation works, but audio glitches out every once in a while and I never figured it out.
~2024: Imagining a clean-slate implementation, maybe based on CH32V307, but never got beyond a skeleton of code.
~now: Embedded Rust, using the LPC55 hardware I had previously designed, with the usb-device framework and fully custom usbd_uac2 class implementation.

I intend to polish this up and release it, probably along with a reference design.