jbk I think your ioctl() is handled in cmlb but should be handled by actual disk driver...

after a bit of dtrace I figured out the problem...

a) it has to be the rdsk (character device) node, and b) the device itself doesn't have a flushable write cache

(the latter was a bit of a surprise)

I just filed bug #17776. Why do I expect this to increment directly to 20000? :)

missed the chance to say you thought it oct to do that :P

heh

jbk: FWIW, most NVMe ssds that have a supercap don't advertise a volatile write cache that I've seen.

Do we compile bhyve with smatch on?

Looks like we do.

Much better.

has anyone tried github.com/slackhq/nebula on illumos/smartos?

I use tailscale. It uses wireguard-go a userland implementation of wg. It also uses the tun driver. Tailscale works, but the tun driver not the fastest implementation.

szilard - there is already a *bsd versions of the nebula client. There is a "managed" version from defined.net, that offers an API for automatic joining the network (docs.defined.net/guides/automating-host-creation) for dynamically created hosts...

I have tried tailscale, too. But I don't like the idea to use tailscales relays.

i've not looked at it in a while, but when I did, the things that stood out to me were the lack of algorithm agility (which I know was explicit, but I think that was a mistake/overreaction to the complexity of IKE(v2)) and how it seemed to require static IPs in a lot of cases that traditionally don't get them (but maybe in an IPv6 world it's less of an issue?)

You can use headscale instead of the tailscale relays. It is open source

tailscale is miraculous, and if you want to use the open coordination clones they exist

I would _imagine_ that breaks some of the nat-traversal trickery they do

nahum would be the expert