Husarnet auto-remove hostname

Dear Husarnet,

We have successfully developed a multi drone, multi discovery server system (each drone a discovery server) all registering on husarnet that connects dynamically do new drones.

There is however one detail that is capable of breaking inter drone communication.

The problem arises when a drone gets a full update and the VPN sidecar is fully reset. This sidecar is configured to use the hostname that matches the drone ID, which after a full reset and wipe, is the same. So now husarnet will register with the same hostname as before the update.

This causes two hostnames with the same name to be present in the hosts file but witth two different ip adresses. This breaks the discoverability of nodes, seemingly randomly.

So my question is this, is it possible that husarnet automatically removes and de-registers an old hostname entry and replaces it when a new device logs in with the same hostname? (Basically disallows multiple IP addresses with the same hostname).

Or even better, could the newly updated drone be assigned the same ip address that it previously had before the update? Thereby preventing the double hosts entry?


Hello @deniz

Husarnet IPv6 address (fc94... address) is determined by the identity file, which on Linux is /var/lib/husarnet/id. Husarnet Daemon, during startup procedure looks for this file and if it does not exist, generates a new one. So the way to persist IPv6 address is to make this file survive the update. I am not sure how would one apply this to your scenario, but this should be possible (is the update wiping all Docker volumes?)

Best regards,

Dear @ympek,

thank you for your quick reply, much appreciated.

Your suggestion sounds like the perfect solution. I think for our scenario, the only thing guaranteed to survive updates is the global environment variable DRONE_ID. So I will simply add an entrypoint script that writes and overwrites /var/lib/husarnet/id based on this drone id and only launch the husarnet daemon after that has finished.

edit: I read the content of this file and it seems that having it being directly linked to a drone id might not be possible. Setting the content of this file as a global variable also doesn’t seem right. Do you have maybe another suggestion with the assumption that the only thing guaranteed persistent is environment variables? We sometimes have to wipe / reset / re-flash drones, so physical content on the drives cannot be assumed persistent in our use case, it will however first connect to our remote management system and download the docker-compose file, and then it downloads and launches those containers.

For example, is it possible that we tell husarnet’s daemon to look for the existence of a hostname in the network, if it does, retrieve that /var/lib/husarnet/id file?

Thank you for your suggestion and have a great day.


Hello @deniz,

I was thinking about your case a little and here are some thoughts I came up with.

First of all, determining cryptographic identity is first thing Husarnet Daemon do and swapping the identity in runtime is impossible… ID file with IP address that we want has to be available before Husarnet Daemon starts, or it will be random.

I think you could maybe keep ID (around 200 bytes each) for each drone in your remote management system in a map like: DRONE_ID => identity. In order to pull this off, it would be nice for you to have possibility to generate Husarnet ID on different machine than the machine that will be actually using this ID. We don’t yet have this functionality, but I guess we could put it on our todo list (workaround is to write custom bash script that brings husarnet up and down many times with purging id file and extracts generated IDs).

Maybe let’s also consider your earlier idea:

So my question is this, is it possible that husarnet automatically removes and de-registers an old hostname entry and replaces it when a new device logs in with the same hostname? (Basically disallows multiple IP addresses with the same hostname).

Our control plane does not have such functionality. It is doable though, something like an option in Husarnet Group setttings, for example. I’ll talk to the team about the possibility to implement such option.

As I was writing this, I realized that it could be (in a hacky way, but still) somewhat possible with Husarnet CLI right now. Husarnet CLI allows you to query and manage your groups and devices on Dashboard. So we could write a script that unassigns (deletes) the old device. For example:

husarnet status

And extract our current (new) IP address from status output

husarnet dashboard device ls

Parse device ls output to find out which device:

  1. has our hostname
  2. has different IP than ours

Extract this IP. Once we have it, we can execute:

husarnet dashboard unassign <OLD_DEVICE_IP> <GROUP_NAME>

Now, this requires some scripting and another downside is that every drone should then have credentials to the Dashboard, which seems like a big no from security POV…

Anyways, these are some ideas I wanted to share with you, and as I said we will discuss possible solutions internally soon.

Thank you!
Best regards,

Dear @ympek,

Thank you for your efforts and energy in finding a solution for this, it is greatly appreciated. Out of your suggestions the key generator idea sounds like a great option for users like me. The way i see it then is something like

$ husarnet generate_key --seed $DRONE_ID
$ husarnet daemon

the seed option allows us to generate a key which is always the same, or without the seed option, generate a random key.

Really hoping this functionality could be on your todo lists.

Thank you very much for your time and you and your team have a great product already.

Have a good day


we’ve just released probably the latest version for 2022: Release v2.0.22 · husarnet/husarnet · GitHub

It contains a genid util which you may find helpful. In general it’s not using any seeds to generate an id. You simply run it and get a new, valid contents of an /var/lib/husarnet/id file. First part of this file is a Husarnet IP that a host with this IP will be using. Also - this tool, despite executing husarnet-daemon binary under the hood, does not need a full setup for Husarnet - you can treat it as just another CLI tool and i.e. run it on a server with no Husarnet connectivity.

In your particular case you may be able to build a service that will give out “stable” id file contents given hostname of a drone, generating new ones with the said tool, whenever new hostname is encountered.

Let me know if that helps.
Have a wonderful day

1 Like

Hey @pidpawel,

thank you for giving us this feature. We will now simply have a predefined database with this as we can generate this drone_id → husarnet_id link ahead of time now.

Thank you for this.