Logan oos Even

I kind of "fixed" it by providing this exact same strange, seemingly fixed MAC address (provide it through `-m ...` command-line parameter). It seems that it just cannot be changed...

I just want to share today's / yesterday's findings of various `hexdump`s and `printf`s on this issue real quick: The SIOC**S**IFHWADDR in `tuntap_linux.c` seems (!) to work as SIOC**G**IFHWADDR delivers...

Argh... :weary: it was the network manager! `systemd-networkd` seems to change TAP interface's MAC address shortly (but not immediately) after the TAP device is up. The first packet still went...

As it turns out, the journey hasn't ended yet. It only helps once – even with new network manager. It must be something else, maybe some part of the virtualization...

As [mentioned earlier](https://github.com/ntop/n2n/issues/562#issuecomment-787740706), this would be a very interesting enhancement! Everybody, please share your thoughts on how to realize and implement this.

Do I get it correctly that this feature would require a bundle of sockets for each connection? That would require some new "abstraction layer", namely a "connection" which holds and...

I like that idea! However, some might object against the possibly bigger file size in supernode-only use-cases.

In a very first approach, some `n2n.c` containing a new `main()` could be created. It evaluates `argv[]` to decide which of the original `main()`s is to be called along with...

I would not want to add another parameter... the new `main` needs to decide whether to run as edge or supernode just by the parameters present. Luckily, `-c` and `-l`...

> no longer consider compatibility > and redefine the original conflicting parameters of supernode and edge There is an effort to do that. Actually, it only hits the `-l` and...