The edge is failed to connect the supernode with MAC error report

[cholley]

Here is the way how it happened:

1. I run edge and supernode normally;
2. I kill the edge;
3. I run the edge again, but failed;
4. I run the edge again and again, but still failed again and again.

It report the same error but with different ramdon MAC.
eg:
ERROR: 36:8E:97:D4:9B:73 is already used. Stopping the program.
I am 100% sure that the mac is not used before i run the edge, because there is only one edge in this test.

[cholley]

it will work again after few minutes, maybe the supernode released some cache stuff or some timeout policy is expired?
But the edge should be able to connect in any seconds, no need to wait.

[Logan007]

If the edge does not terminate correctly, the MAC and also the tun_tap IP address are still blocked (for 90 +/- 20 seconds or so). This is part of the MAC spoofing prevention as introduced with #505 and as explained here.

You could stop an edge regularly by pressing CTRL-C if running as foreground process. In case of background process, kill -SIGINT <pid> might work, haven't tried that yet, though. If running as systemd service, systemctl stop n2nEdge (your names may vary) usually closes it in a clean way, no issues observed there, I wonder if it also sends SIGINT.

The edge needs to terminate in a regular way to get a chance to send an UNREGISTER_SUPER message to the supernode which would free the IP and MAC for use by another egde (or the same edge again). A hard kill will not allow the edge to send thos message.

Some background information is available in the /doc folder as well.

We might need to add it to the FAQ as this seems to happen more often.

[skyformat99]

If the edge does not terminate correctly, the MAC and also the tun_tap IP address are still blocked (for 90 +/- 20 seconds or so). This is part of the MAC spoofing prevention as introduced with #505 and as explained here.

You could stop an edge regularly by pressing CTRL-C if running as foreground process. In case of background process, kill -SIGINT <pid> might work, haven't tried that yet, though. If running as systemd service, systemctl stop n2nEdge (your names may vary) usually closes it in a clean way, no issues observed there, I wonder if it also sends SIGINT.

The edge needs to terminate in a regular way to get a chance to send an UNREGISTER_SUPER message to the supernode which would free the IP and MAC for use by another egde (or the same edge again). A hard kill will not allow the edge to send thos message.

Some background information is available in the /doc folder as well.

We might need to add it to the FAQ as this seems to happen more often.

Because encryption is already in place (header, community), it is recommended that this property be turned off by default on the supernode side unless it is explicitly turned on.

[cholley]

In my application, the supernode will be running all the time, but I have multiple edges running on the same host to handle different communities, so I need way to stop each edge individually, will kill -SIGINT <pid> instead of kill -9 <pid> solve this kind of issue? How to kill the edge safely to trigger a de-register message to supernode before it is killed?

[Logan007]

will kill -SIGINT instead of kill -9 solve this kind of issue?

@cholley Yes, it safely seems to do the job: Just run an edge in the foreground and do a kill -SIGINT <pid>, you should see the regular end stats (-SIGTERM works as well) – not so with kill -9 <pid>.

In general, -9 aka -SIGKILL is a very rough method to end a program which does not allow it to perform its own end sequence. -SIGKILL should be more of a last resort in case -SIGINT does not work.

[Logan007]

Because encryption is already in place (header, community), it is recommended that this property be turned off by default on the supernode side unless it is explicitly turned on.

@skyformat99 That is an interesting proposal. However, please keep in mind that encryption alone does not replace edge authentication.

The current edge authentication scheme is a very basic one and might undergo some changes anyway.