Closed NanoRed closed 3 days ago
@MarcoPolo Hi~sorry to border, can i get any information?
After some testing, it seems that when one of my NAT nodes has not yet obtained a public address
You'll need a public address for hole punching. Why is this device unable to get a public address?
After some testing, it seems that when one of my NAT nodes has not yet obtained a public address
You'll need a public address for hole punching. Why is this device unable to get a public address?
hi thanks for responding! this two device is under the NAT device, when i enable the holepunch service, it will run a goroutine called "waitForPublicAddr" it looks like a public address is needed to set the "/libp2p/dcutr" protocol stream handler
when Node B connected to Node A through p2p-circuit protocol(Node B is waiting the its public address from other nodes at the same time), Node A immediately send dcutr request to Node B although the Node B has not yet got its public address to set its protocol handler, that cause the error "failed to open hole-punching stream: failed to negotiate protocol: protocols not supported: [/libp2p/dcutr]"
i have another question: how is the public address obtained?
i think i figured it out by myself, thanks
Hello, I found that if the relay node is physically close enough to the nodes that under the NAT device, an error "failed to open hole-punching stream: failed to negotiate protocol: protocols not supported: [/libp2p/dcutr]" will occur in hole punching.
After some testing, it seems that when one of my NAT nodes has not yet obtained a public address and set stream handler for the protocol ID /libp2p/dcutr, another NAT node has already sent a request for /libp2p/dcutr.
This caused the hole punching to not work. Is there any solution? Or is there something wrong with my usage?
Here are some logs about my problem,
Node A:
Node B:
These two nodes were both running on my PC under the same home NAT network.