search

ntop / n2n

Peer-to-peer VPN
GNU General Public License v3.0
6.14k stars 928 forks source link

select-rtt option bug report #1060

Closed codercaizh closed 1 year ago

codercaizh commented 1 year ago

description: When the federated mode is used and the "--select-rtt" option is enabled on the edge, once the connected supernode goes offline, the edge will not perform failover edge startup command： /usr/bin/n2n-edge -f -H --select-rtt -A3 -d n2n0 -a static:10.0.2.2/24 -c cai -l ***:** -k **** -M 1400 -r

one of the edges netcat screenshot

image

The supernode with IP '116.26..' is offline，but it is still in the first line of the supernode list and still seems to be selected

one of the supernodes netcat screenshot

image

The IP '116.26..' supernode does not appear in the federate list

guess: edge uses the first item in the supernode list by default, and when the "select-rtt" option is used, the supernode list will be sorted by rtt. When the supernode is offline, its rtt is empty, but the result is still ranked first, causing the edge to still try to connect to it, and ultimately fail to failover

suggestion: When using the "select-rtt" option, prioritize the supernodes whose rtt is not empty according to the existing rules at the front of the list, and put the supernodes whose rtt is empty at the end of the list, so that the edge can normally connect to the non-faulty supernode

codercaizh commented 1 year ago

After testing, even if the SLECT-RTT option is not added, a similar problem will occur with the default LOAD option, and I find that there will be a "." Character after the corresponding supernode name. What does this mean? IMG_20221119_074354 IMG_20221119_074420

GreatMichaelLee commented 1 year ago

seems your first supernode run with different build version as there is no build version displayed like below two supernodes in the first snapshot pic.

codercaizh commented 1 year ago

seems your first supernode run with different build version as there is no build version displayed like below two supernodes in the first snapshot pic.

After many attempts, I found that as long as the edge is working in p2p, the failover of the supernode will not take effect. I try to directly kill the supernode that is being connected to the edge in Federated (the name ends with a * character). In the netcat of the edge, the status of the supernode only changes to the end with '.', and from the log, the edge It will only repeatedly try to connect to the supernode that has been killed, instead of connecting to another available supernode. May I ask why you want to design it this way?

image
Logan007 commented 1 year ago

Hello, could you please try the current dev branch for supernodes and edges? I remember some issues with supernode selection being fixed after 3.0 release.

codercaizh commented 1 year ago

When I compile a new Edge with the DEV branch, I found that it can work as expected. In the P2P mode, one supernode in manual Kill, Edge connected to other supernode after a period of time. So what is the reason for this problem? Which Commit is solved?

Hello, could you please try the current dev branch for supernodes and edges? I remember some issues with supernode selection being fixed after 3.0 release.

IMG_20221123_015838

IMG_20221123_015955

Logan007 commented 1 year ago

When I compile a new Edge with the DEV branch, I found that it can work as expected.

So, current dev solves it for you completely?

So what is the reason for this problem?

Bugs :wink:

Which Commit is solved?

Several... you might be able to retrieve them in the commit history if this is of specific interest to you as we try to keep commits descriptive.