n2n
n2n copied to clipboard
ntop
Can you add a option to the crazy p2p?
Corresponds to S1 & S2. even if it's unstable, it's fine. When in conflict, choose S1/S2.
I am not sure if I understand correctly. Do you propose auto-switching between the modes?
Currently, if p2p does not work, n2n automatically falls back to "forward via supernode" correpsonding to -S1. In this regard, we somehow already are having the auto-switch. Providing -S1 at command line permanently forwards through the supernode.
-S2 is still experimental and not working on Windows.
Aut-switch including TCP would require a lot of internal changes as far as I can see, probably a complete new network/connection layer inside the code.
At the moment, trying p2p is not enough, whether it's at the beginning of a connection, or in a connection, not as positivity as zerotier.
In some kind of fixed network environment, it is possible to p2p, however mostly forward, so I want a state, as long as p2p, do not forward, even if not p2p, will forward is just for basic communications, in the meantime, it's going to keep trying to p2p.
In addition, when switching automatically to forward, it is recommended to switch S2 first and then try S1. Because in some places UDP is limited, or even prohibited.
Some of our ideas may be immature, or not the direction of your development, hope you'll think it over before you decide.
Your efforts have been most appreciated. Thank you for your work.
In some kind of fixed network environment, it is possible to p2p, however mostly forward
Yes, in some local networks, it is hard to directly do p2p even inside. Especially, when multicast peer detection does not work. Have you seen our new experimental -e option at edge? You can use it with the computer's local IP address, e.g. -e 192.168.0.100, to advertise this address for p2p. Other edges should connect more easily p2p then.
To get better p2p chance between remote networks, -L might prove helpful, although I have not seen much success with the routers available to me. Also, port forwarding can be useful as well. For now, still lacking uPnP support, this has to be configured manually.
as long as p2p, do not forward
p2p, if possible, always is preferred over forwarding – if not overridden by -S1 or -S2.
if not p2p, will forward is just for basic communications, in the meantime, it's going to keep trying to p2p.
If no -S1 is given, p2p always is being retried. Every time a packet is forwarded, establishing p2p is being retried. Well, not with every packet, that would cause too much extra traffic. But every now and then, see check_query_peer_info().
In addition, when switching automatically to forward, it is recommended to switch S2 first and then try S1. Because in some places UDP is limited, or even prohibited.
This is a very good point. Unfortunately, I can't see how current internal structures would support such ah behavior. This would require a complete new network connection layer...
not the direction of your development
... which I actually have in mind for the 4.0 line. Not for 3.0 yet, because that would revolve whole internal structure.
hope you'll think it over before you decide
I do! And please continue to share your ideas!
If the network connection layer plans materialize as expected in 4.0, we might see much more flexible connectivity options, maybe even multi-socket. Basic idea is to try several options at once (in parallel – which we can't easily do now) and chose the best one.
Your efforts have been most appreciated. Thank you for your work.
:orange_heart:
-
I have already tested that "-e x.x.x.x" is not valid, even within the lan (a bug). I also tested that "L auto/x.x.x.x" of meyerd's v2 can help to p2p (not in lan). with @fengdaolong. Let's hope our "auto" is the default.
-
In forward, trying p2p is working all the time? Is it not as crazy as zerotier? For enhancement, can you try to change port halfway? or run another crazy test and give it to the main line when p2p. so, I want a option to the crazy p2p.
-
S2 "require a complete new network connection layer" ? isn't -S2 already in using?
Thank you!
I have already tested that "-e x.x.x.x" is not valid, even within the lan (a bug). I also tested that "L auto/x.x.x.x" of meyerd's v2 can help to p2p.
Thank you for testing! Actually, -e should show the same behavior as meyerd's -L even though implementation details are different. If it does not, we need to debug this more. As -e also requires active supernode support, I assume that you have also compiled a fresh supernode as well as all edges participating in your trials? It however might take up to a few seconds until the locally preferred socket is propagated through the PEER_INFO message.
Also note that it is supposed to help local edges to better find each other for p2p. In addition, -e always needs to come along with -p provided as we do not auto-detect edge's port if -p is not provided. I meanwhile have successfully tested it in my (limited) setup between two routed LANs.
In forward, trying p2p is working all the time?
Yes, it is. It retries every now and then to send REGISTER packets again if remote edges still are found in pending_peers (meaning: no p2p), see check_query_peer_info().
Is it not as crazy as zerotier?
Honestly, I do not know about zerotier.
S2 "require a complete new network connection layer" ? isn't -S2 already in using?
Sorry for not being sufficiently precise here. It is not the plain usage of -S2 which requires a new network layer. It is the switching between the modes of a running edge which would require a more generalized connection control. The reason is as follows:
Internally, each edge only opens exactly one socket to the external world at a time. It can be either UDP or TCP. If TCP is chosen (by -S2), there is no extra socket for UDP on which we could check if we could switch back to UDP. That would require some extra logic which I do not want to add for just one additional socket. I would rather take a more generalized approach which then could simultaneously deal with even more sockets, the network connection layer.
Also, switching that socket connection type (UDP, TCP) in-between every now and then to check the other mode would close all so far made connections, requiring complete re-registration, intermediate clean-up of peers, ... and probably some other connection logic hazzle I am not able to foresee yet and which I do not want to take shortly before the 3.0 release. That's why I would like to postpone this to after the 3.0 release. Maybe, there is some intermediate hacky solution which we could try sometime then.
For enhancement, can you try to change port halfway?
run another crazy test and give it to the main line when p2p.
I think you are referring to additional NAT-traversal strategies. Those could become part of that network_connection_layer. I am currently not able to see how to add those to the register_with_new_peer() which, by the way, already seems to try different ports if -L <reg_ttl> is provided, see src/edge_utils.c:630.
edge3 -a 172.30.10.100 -c n2n -k test -l n2n.abc.cn:10090 -d sfdsf -e 192.168.1.27 -f
I tested it this way, before I used "supernode.ntop.org:7777", now I use the latest supernode3 (I just made it). However, in lan is still forwarding. Of course, meyerd's v2 is able to p2p.
Thank you for explaining everything to me.
edge3 -a 172.30.10.100 -c n2n -k test -l n2n.abc.cn:10090 -d sfdsf -e 192.168.1.27 -f
Could you please also add some-p 55555? -e still requires -p (this might change soon though). You should see a warning if providing -e without -p.
Yes, after adding p, the lan is connected directly (immediately). With or without "p", there's no mistake.
However, meyerd's v2 can be connected directly without using L and p at the same time. I think it's better not to add p, the simpler the better.
Yes, after adding p, the lan is connected directly.
This is good news!
However, meyerd's v2 can be connected directly without using L and p at the same time.
I did not copy meyerd's code but only the idea of providing a locally preferred socket. Internal realizations most probably differ from each other.
I think it's better not to add p
That would require some additional logic in the code...
the simpler the better.
...which I have just happened to add: The -p-requirement for -e has just been lifted by currently added port detection.
Let me know if it works out for you.
In fact, I don't like p and I don't like e, because they often conflict or don't match up with reality.
I always didn't like meyerd's "L x.x.x.x" before, but after fengdaolong told me "auto", I liked it.
Thank you!
In fact, I don't like p and I don't like e, because they often conflict or don't match up with reality.
You are right. In an ideal world, we would not need either of them.
Thank you!
So, does -e work without -p for you now?
but after fengdaolong told me "auto"
I took a look at @meyerd 's code. Now I see what you mean by auto. So, I have just added auto-detection capability to -e, i.e. -e auto should be available now.
I tested it (-e auto), and now it's almost as good as meyerd's v2 in direct connectivity. Can we make "auto" the default? "Supernode.ntop.org:7777" doesn't apply.
It feels that trying to p2p isn't enough, very!
I tested it (-e auto)
Thank you very much for testing!
now it's almost as good as meyerd's v2 in direct connectivity.
I am glad to hear.
Can we make "auto" the default?
I currently am not planning to enable -e ... by default because I want the user to make this decision on the potential security issue: Sharing your internal IP address with the whole world leaks local network information (same for real host name if -I not provided, but that is a different story; maybe to be addressed soon, too).
"Supernode.ntop.org:7777" doesn't apply.
As far as I know, this supernode is updated every three to four weeks, not with every code change.
It feels that trying to p2p isn't enough, very!
You are right, there probably are more NAT- / Firewall-traversal tricks. That's why I will leave this issue with its original idea to crazy p2p open.
That's the truth, n2n didn’t try hard enough！ ^_^
netstat -ap | grep edge1
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:48191 0.0.0.0:* 1059/edge1
unix 3 [ ] STREAM CONNECTED 24452 1059/edge1
netstat -ap | grep edge2s
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 localhost:5644 0.0.0.0:* 15267/edge2s
udp 0 0 0.0.0.0:12387 0.0.0.0:* 15267/edge2s
netstat -ap | grep edge2
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 localhost:31023 0.0.0.0:* 1061/edge2
udp 0 0 0.0.0.0:1968 0.0.0.0:* 1061/edge2
udp 0 0 0.0.0.0:42964 0.0.0.0:* 1061/edge2
netstat -ap | grep edge3
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 localhost:25081 0.0.0.0:* 15268/edge3
udp 213504 0 0.0.0.0:1968 0.0.0.0:* 15268/edge3
udp 0 0 0.0.0.0:12389 0.0.0.0:* 15268/edge3
netstat -ap | grep tinc
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:tinc 0.0.0.0:* LISTEN 1097/tincd
tcp 0 0 C92.lan:tinc 101.222.246.8:55099 ESTABLISHED 1097/tincd
tcp6 0 0 [::]:tinc [::]:* LISTEN 1097/tincd
udp 0 0 0.0.0.0:tinc 0.0.0.0:* 1097/tincd
udp6 0 0 [::]:tinc [::]:* 1097/tincd
unix 2 [ ] DGRAM 25509 1097/tincd
netstat -ap | grep zerotier
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 C92.lan:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23049 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92.lan:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 localhost:9993 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92.lan:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp 0 0 C92:23050 0.0.0.0:* LISTEN 18769/zerotier-one
tcp6 0 0 ip6-localhost:9993 [::]:* LISTEN 18769/zerotier-one
udp 0 0 C92.lan:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:9993 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92.lan:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23049 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92.lan:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
udp 0 0 C92:23050 0.0.0.0:* 18769/zerotier-one
unix 3 [ ] STREAM CONNECTED 6206215 18769/zerotier-one
For example, add a option such as:
-x 300s -- I can agree that crazy trying in 300 seconds(network unavailable) every starting. -x 30ms -- If the value of ping is greater than 30ms, keep crazy trying.
or
-x 300:30 -- I can agree that crazy trying for 300 seconds until the value of ping is less than 30 ms.
Too many options!
First thing to do is to add a network connection layer. It will help us to take care of UDP and TCP at the same time and switching to TCP as a fall-back automatically. Also, that will be the place to add upnp support (if somebody ever wants to add it). And, it will be the place for "crazy p2p" making parallel connection attempts as well.
But we need to add that layer first as prerequisite. Current internal structures are able to handle only one socket at a time.
Sounds wonderful and worth looking forward to!
I think when v3.0 comes around, upnp is indispensable. It would be even better if joining tcp socket, which would be two-way streets.
It seems that to improve the rate of p2p, need to put more effort.
So what’s the next step? waiting for your good news.
So what’s the next step?
- network connection layer (to deal with different/multiple sockets)
- auto switch TCP / UDP
- uPnP (if somebody implements it)
- parallel connection attempts
waiting for your good news.
It will take some time and effort, so I do not see it finished before 3.2, maybe even later.
Oh, I see. it’s not easy. more people should be involved.
I am concerned that there will be compatibility issues by that date, Can we delay to release v3?
more people should be involved.
More volunteers and contributions always are very welcome!
I am concerned that there will be compatibility issues by that date
The 3.x series shall keep up compatibility among all its versions. I do not expect the network connection layer to impact compatibility.
Can we delay to release v3?
Considering the current availability of actively developing personnel, the action items listed above will take months or maybe even more than a year to come to life. I would not want to wait for it, especially as compatibility should not be an issue.
The p2p's rate of n2n is only 7%--11%, this is very low. here are the details #147 Test time: 2021-10-02. the current version of n2n is v2.9.0_r1001.
I think it should be more than 95% for that it's possible to p2p.
Don’t answer, just for reference.
Fengdaolong has promised to add upnp before releasing n2n_v3. He’s worried he won’t be able to keep up with n2n_v3.
Fengdaolong has promised to add upnp ...
Great news!
...before releasing n2n_v3. He’s worried he won’t be able to keep up with n2n_v3.
No worries! If it is not in time for 3.0, it will be in time for 3.2.
I don’t think it’s appropriate to release v3 at this point
1. What do you think the current v2.9 has over v2.8? what I like better (e/a/F)
S2 / e / a / I / J / R / F ?
2. I think what people are most concerned about,
A.high speed (relation: rate of p2p, stability) (the transfer rate has not improved)
B.security (this is definitely enhanced)
C.convenience (this is a consistent advantage of n2n)
D.strong
3. If released now, on the one hand the attraction is not big to everybody, on the other hand, may cause the confusion in the future
That's the end of v3, and didn’t bother to follow up, because of laziness, because of habit.
Now let's take a look at the v2's users (it's been processed)
id tun_tap MAC edge last_seen
---------------------------------------------------------------------------------
community: bmiin
1 10.0.0.1/8 00:FF:B3:19:4A:47 175.23.15.175:12576 3
2 10.0.0.2/8 00:FF:F6:11:6D:8A 175.23.15.175:12631 17
3 10.0.0.5/8 00:FF:46:9A:68:37 175.23.15.175:12941 10
4 10.0.0.4/8 00:FF:DD:01:A2:78 175.23.15.175:11264 15
5 10.193.141.223/8 00:FF:4C:4B:1B:3F 27.131.12.42:38066 15
community: hlcdftn
1 0.0.0.0/0 32:4C:0B:F5:71:BC 39.181.120.163:38593 7
2 0.0.0.0/0 A2:2A:8D:92:17:94 115.227.211.122:3550 20
3 0.0.0.0/0 0A:9A:60:3A:4E:65 183.113.75.215:58312 12
4 0.0.0.0/0 FA:C2:15:5C:E6:DA 27.13.153.63:30343 6
5 0.0.0.0/0 72:F7:A3:E3:3D:6D 27.13.153.63:31553 18
community: swhyu28
1 0.0.0.0/0 3A:03:63:E1:7F:22 46.33.61.4:33630 26
2 0.0.0.0/0 BE:05:38:C2:F3:27 194.218.76.32:35313 18
3 0.0.0.0/0 00:FF:CA:11:54:E4 46.33.61.4:55529 22
4 0.0.0.0/0 00:FF:69:74:24:DA 194.218.76.32:23998 17
5 0.0.0.0/0 00:FF:82:AC:F7:F3 91.228.212.35:59135 8
6 0.0.0.0/0 F2:4D:A7:4E:E2:58 185.79.156.243:37812 8
community: hhh
1 0.0.0.0/0 00:FF:73:9D:14:84 221.236.145.217:51307 6
2 0.0.0.0/0 00:FF:0B:BC:73:F3 119.85.43.24:3162 4
3 0.0.0.0/0 00:FF:53:5A:DE:97 182.137.64.46:28546 1
4 0.0.0.0/0 00:FF:D3:03:DE:79 183.62.252.210:61751 12
5 0.0.0.0/0 00:FF:A8:86:AC:B0 223.82.12.70:11385 9
6 0.0.0.0/0 00:FF:E9:CA:05:03 118.129.135.21:4929 6
community: blbjlmail
1 0.0.0.0/0 AA:70:0C:3C:C4:06 112.83.69.6:17384 2
community: dxhDfOlzJ
1 0.0.0.0/0 00:FF:2D:0D:F2:7E 117.72.54.45:47696 14
community: NH
1 0.0.0.0/0 9A:2E:4E:08:11:FF 183.142.27.82:18438 5
community: ucvr
1 0.0.0.0/0 CA:2A:15:80:83:89 101.72.35.23:10725 6
2 0.0.0.0/0 EE:0E:14:C5:5B:63 60.174.57.221:58469 18
community: xivklei
1 0.0.0.0/0 AA:EA:9C:90:72:2D 223.86.45.43:44257 1
community: wadroom
1 0.0.0.0/0 42:A2:58:3F:61:B3 223.71.83.215:18889 2
---------------------------------------------------------------------------------
uptime 1054816 | edges 29 | reg_sup 1315913 | reg_nak 0 | errors 0
fwd 14702810 | broadcast 3496168 | cur_cmnts 10
last fwd 0 sec ago
last reg 1 sec ago
See? a lot of people are still using early versions, even though we’ve been talking about some of the new features of v2, but they haven’t been affected by it, in their eyes, it’s v2, unless the v3 comes.
So, until there are significant improvements, I would advise against releasing a new version.
The latest p2p success rate between c92 and A82, reference #147
a lot of people are still using early versions
I assume a major reason being the fact that 2.9 is the development version with a high frequency of (compatibility braking) changes. As soon as it gets released and thus does not change anymore, it is likely to become more attractive to use...
The latest p2p success rate
The rate will not change until UPnP or some other idea will be integrated. Those are big changes which will require a lot of time to integrate in a clean and minimal-invasive way. And it require some more time for testing to prove stability. I am not sure if everybody is willing to untie the current state.
What do you think the current v2.9 has over v2.8?
So, until there are significant improvements ...
for your reference
a lot of people are still using early versionsThat’s not how it works. they’re not using the latest v2.8, see through "0.0.0.0/0", it could be v2.6 or v2.4, or earlier. maybe because of laziness, or habit. It’s just like windows 7. would you be updating patches all the time if it weren’t for a security flaw? If you don’t find it very attractive, will you upgrade to windows 10?
The rate will not change until UPnP or some other idea will be integratedWe can see by the "netstat -ap | grep zerotier", every zerotier's port (23049\23050\9993) has 14 attempts from the outside, but n2n only one. if we do the same thing as zerotier, then n2n’s p2p_success_rate would be like this: 7% x 14 = 98%, even 7% x 14 x (3/2) = 147% (ignore ipv6 upnp & tcp), then upnp is not so important. upnp is very limited, because in many places, we don’t have that right.
I am not sure if everybody is willing to untie the current stateI’m not sure what that means, but you can vote if you need to.
I’d really like to see some of the other people’s ideas, even if against me. n2n is everybody’s fortune.
@Logan007 Thank you for your hard work!!
That’s not how it works. they’re not using the latest v2.8, see through "0.0.0.0/0", it could be v2.6 or v2.4, or earlier. maybe because of laziness, or habit. It’s just like windows 7. would you be updating patches all the time if it weren’t for a security flaw? If you don’t find it very attractive, will you upgrade to windows 10?
Sorry, that was a mistake, and it turns out that only v2 which retains the autoip functionality(v2.7-r525) will display "10.193.141.223/8", not "0.0.0.0/0".