Don't hole punch if either peer is behind a Symmetric NAT #1046

aarshkshah1992 · 2021-02-03T10:43:05Z

If either peer is behind a Symmetric NAT, there's no point in wasting a hole punch and bandwidth on Relay servers.

TODO

Unit Tests.

aarshkshah1992 · 2021-02-04T06:04:57Z

Based on an offline discussion with @willscott

The fact that we dial a peer if it has any public addresses at all before giving up on Hole Punching due to NAT types will take care of Full Cone NATs.

It will break for address restricted Cones. So, we need to look at how our current code performs in the wild (with some stats around failures rates) to decide if we need to remove the restriction this PR introduces.

godcong · 2021-02-05T03:54:15Z

but after my experiment, some operators can make reverse connections through the opened ports.
I just don’t know how many operators support it now

aarshkshah1992 · 2021-02-05T04:42:31Z

@godcong Yeah, that's a FULL Cone NAT. This PR will dial public addresses before giving up because of the NAT type.

vyzo

couple of nits, but overall looks good.

vyzo · 2021-02-17T18:09:40Z

p2p/protocol/identify/id.go

+	UDPNATDeviceTypeKey = "UdpNATDeviceType"
+	// TCPNATDeviceTypeKey is the key with which we will persist a peer's TCP NAT Device Type to the peerstore.
+	TCPNATDeviceTypeKey = "TcpNATDeviceType"


funky capitalization in the strings; it's UDP not Udp and same for TCP.

vyzo · 2021-02-17T18:10:21Z

p2p/protocol/identify/pb/identify.proto

+    UNKNOWN = 100;
+    CONE = 200;
+    SYMMETRIC = 300;


vyzo · 2021-02-17T18:10:38Z

p2p/protocol/identify/pb/identify.proto

+
+  optional NATDeviceType tcpNATDeviceType = 10;
+  optional NATDeviceType udpNATDeviceType = 11;
+}


vyzo

few more comments.

vyzo · 2021-02-18T08:12:05Z

p2p/protocol/holepunch/coordination.go

+
+	for {
+		select {
+		case _, ok := <-sub.Out():


shouldn't we look at the actual event? why are we ignoring it?

Also, where do we set the support meta-variables into the peerstore?
Shouldn't we be doing it here? Or is it handled elsewhere?

I think we need a comment if this is correct as is.

@vyzo

Our local vars are set in the peerstore in basic_host.go during initialisation of the Host & updated in the obs addr manager.

Remote vars are set in the peerstore by Identify.

Both changes are included in this PR. I've added a comment.

vyzo · 2021-02-18T08:13:33Z

p2p/protocol/identify/id.go


 	return mes
 }

+func toPbNATDeviceTyp(typ network.NATDeviceType) pb.Identify_NATDeviceType {


typo in method name; shouldn't this be Type?
Also, typ is a very funky variable name, better call it just t.

vyzo

removing the handler is a BUG.

vyzo · 2021-02-18T08:35:09Z

p2p/protocol/holepunch/coordination.go

+			if hs.peerSupportsHolePunching(hs.host.ID(), hs.host.Addrs()) {
+				hs.host.SetStreamHandler(protocol, hs.handleNewStream)
+			} else {
+				hs.host.RemoveStreamHandler(protocol)


wait, this is a BUG -- we lose the ability to dial back connect to a public node that has dialed us.

oh wait, nvm we just direct dial back when we see the relayed connection without coordination. Sorry about that.

aarshkshah1992

@vyzo

Rebased and addressed review.

aarshkshah1992 · 2021-02-19T10:00:31Z

p2p/protocol/holepunch/coordination.go

+
+	for {
+		select {
+		case _, ok := <-sub.Out():


@vyzo

Our local vars are set in the peerstore in basic_host.go during initialisation of the Host & updated in the obs addr manager.

Remote vars are set in the peerstore by Identify.

Both changes are included in this PR. I've added a comment.

aarshkshah1992 · 2021-02-19T10:06:59Z

p2p/protocol/identify/id.go


 	return mes
 }

+func toPbNATDeviceTyp(typ network.NATDeviceType) pb.Identify_NATDeviceType {


aarshkshah1992 · 2021-02-19T10:36:49Z

p2p/protocol/identify/obsaddr.go

@@ -200,6 +207,21 @@ func (oas *ObservedAddrManager) filter(observedAddrs []*observedAddr) []ma.Multi
 		}
 	}

+	// For certain use cases such as hole punching, it's better to advertise even unactivated observed addresses rather than none at all


@vyzo This needs your attention. I discussed this with @Stebalien and he was okay with it.

…update-deps update deps due to license

BigLep · 2021-10-24T04:43:17Z

@marten-seemann @vyzo @aarshkshah1992 : I'm putting this back to draft for now. Feel free to close if that's the better option.

vyzo · 2021-10-24T05:42:30Z

I actually think we ahould close it, i personally find it dangerous.

introspection3 · 2024-05-05T02:01:38Z

@aarshkshah1992 @BigLep @vyzo @marten-seemann
"Don't hole punch if either peer is behind a Symmetric NAT" is an evil proposal, as
Symmetric can connect Full Cone,IP restrict.
Symmetric can also connect Port restrict use
Use the birthday paradox

aarshkshah1992 and others added 30 commits January 27, 2021 17:26

emit NAT device type

78ce16b

unit tests

0b45239

emit event for NAT Device Type

3566bfd

updated deps

29d4987

refactor tcp-udp NAT events

5484ccb

update go ver

1537769

go mod tidy

c2295d5

update deps

2296117

fix multiple events

d337499

Implement support for simultaneous open

1956fea

updated deps

cfef141

simultaneous connect

10adf33

added tests

ef26854

added tests

ae61f65

more testing

0b0b410

host changes

90cd9bb

test scripts

2603920

default listen

e868d73

addrs

431a9a6

relay server

fa9994c

rela server

001aa52

relay server

14ef1ec

relay server

450d431

addrs

36ca4a7

testing

1bdb86c

server code

1d6d07f

server code

5ecac86

more changes

d9d7e6a

upated swarm

dcf822c

clean-up

2ee5344

aarshkshah1992 changed the title ~~Event Driven Hole Punching~~ Don't hole punch if either peer is behind a Symmetric NAT Feb 4, 2021

vyzo reviewed Feb 17, 2021

View reviewed changes

address review

651ae86

vyzo reviewed Feb 18, 2021

View reviewed changes

vyzo previously requested changes Feb 18, 2021

View reviewed changes

aarshkshah1992 changed the base branch from feat/simopen to feat/hole-punching-signalling February 19, 2021 09:47

aarshkshah1992 changed the base branch from feat/hole-punching-signalling to feat/simopen February 19, 2021 09:56

rebased PR

9b483aa

aarshkshah1992 changed the base branch from feat/simopen to feat/hole-punching-signalling February 19, 2021 10:05

aarshkshah1992 added 5 commits February 19, 2021 15:38

fix typo

3e9dc38

fixed errs

ea96e13

fixed errs

792ff75

save NAT type to peerstore

6efab25

added a test

00bd3a7

aarshkshah1992 commented Feb 19, 2021

View reviewed changes

aarshkshah1992 and others added 6 commits February 19, 2021 16:32

removed double init

48350b4

finished merging

9267948

unit tests

b553c16

fixed races

f981b25

update deps due to license

a3fee65

Merge pull request #1146 from ZBoIsHere/feat/evt-based-hole-punching-…

9b67b75

…update-deps update deps due to license

BigLep marked this pull request as draft October 24, 2021 04:42

marten-seemann closed this Oct 25, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't hole punch if either peer is behind a Symmetric NAT #1046

Don't hole punch if either peer is behind a Symmetric NAT #1046

aarshkshah1992 commented Feb 3, 2021 •

edited

aarshkshah1992 commented Feb 4, 2021

godcong commented Feb 5, 2021

aarshkshah1992 commented Feb 5, 2021

vyzo left a comment

vyzo Feb 17, 2021

aarshkshah1992 Feb 18, 2021

vyzo Feb 17, 2021

aarshkshah1992 Feb 18, 2021

vyzo Feb 17, 2021

aarshkshah1992 Feb 18, 2021

vyzo left a comment

vyzo Feb 18, 2021

vyzo Feb 18, 2021 •

edited

aarshkshah1992 Feb 19, 2021

vyzo Feb 18, 2021

aarshkshah1992 Feb 19, 2021

vyzo left a comment

vyzo Feb 18, 2021

aarshkshah1992 left a comment

aarshkshah1992 Feb 19, 2021

aarshkshah1992 Feb 19, 2021

aarshkshah1992 Feb 19, 2021

BigLep commented Oct 24, 2021

vyzo commented Oct 24, 2021

introspection3 commented May 5, 2024

Don't hole punch if either peer is behind a Symmetric NAT #1046

Don't hole punch if either peer is behind a Symmetric NAT #1046

Conversation

aarshkshah1992 commented Feb 3, 2021 • edited

TODO

aarshkshah1992 commented Feb 4, 2021

godcong commented Feb 5, 2021

aarshkshah1992 commented Feb 5, 2021

vyzo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vyzo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vyzo Feb 18, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vyzo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aarshkshah1992 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BigLep commented Oct 24, 2021

vyzo commented Oct 24, 2021

introspection3 commented May 5, 2024

aarshkshah1992 commented Feb 3, 2021 •

edited

vyzo Feb 18, 2021 •

edited