I used the latest n3n_3.4.4-86-gb0b6944-1_amd64.deb and made a docker container and ran the tcp transfer and reported an error.

[chenxudong2020]

This is my docker project https://github.com/chenxudong2020/n2n-dcoker
In supernode, I only reported missing tcp ports, as follows:
docker run -itd --name=n2n --restart=always -p 1234:1234/tcp -v /usr/n3n/:/etc/n3n/ registry.cn-hangzhou.aliyuncs.com/dubux/n2n:v3

the edge configuration file is as follows:

[tuntap]
name=n3nedge
address=100.100.100.2
address_mode=static
macaddr=DE:AD:BE:EF:99:99
[filter]
allow_routing=true

[community]
name=xxx
key=yyy
supernode=xyz:1234

[connection]
bind=50001
allow_p2p=false
connect_tcp=true

After starting, it was found that the connection was successful, and then the following error was reported:

It can be accessed between edges, but it keeps reporting errors and is unstable.

[hamishcoleman]

What version supernode are you communicating with? If you can run the edge with -vvvv then we will get more logs. Also, images are hard to use for debugging. Finally, can you try the same config without docker to help confirm where the issue might be?

[chenxudong2020]

The supernode and edge versions I built using docker are the same. Supernode has no error logs. Edge is started through the configuration file. I don’t know how to get more logs. Maybe you can use my docker to build it and run it to see.

[hamishcoleman]

Add the -vvvv option to the list of paramaters in your CMD statement and that will turn on more debug logging.

Did you try running this without docker? This will confirm if the problem can be reproduced in a simpler environment that is easier to test

[hamishcoleman]

Thanks for the logs.
It looks to me like something in the docker networking is causing TCP packets not to be detected as arriving at the edge.

Have you been able to reproduce the issue without docker?

[chenxudong2020]

Reference

Run the docker command of supernode docker run -itd --name=n2n --restart=always -p 1234:1234/tcp -v /usr/n3n/:/etc/n3n/ registry.cn-hangzhou.aliyuncs.com/dubux /n2n:v3 I only opened the tcp port. I don’t know if it has something to do with it. If I don’t use docker, wouldn’t supernode and edge be used?

[hamishcoleman]

The port opening in your docker command is probably not doing what you think it is doing - this is for allowing traffic from the outside world into the container.

If you dont use docker, you can just extract the n3n-edge and run ./n3n-edge start ./edge.conf -vvvv

[hamishcoleman]

Can you try commenting out your bind=50001 line.

I think it might be causing your issues. Also, it is unlikely to be achieving a lot in the docker case, since most outbound docker traffic will have a source NAT applied to it

[hamishcoleman]

Did you retry with bind=50001 commented out?

[hamishcoleman]

I do not believe I have found the issue - I'm still struggling to reproduce exactly the issue you are seeing. It has been working fine in almost all my tests - the only hint I could see is that repeated edge reconnections with TCP mode with binding turned on resulted in attempts to reuse the same TCP 4-tuple (which is not a condition supported by TCP stacks)

Running in a docker container sends traffic through an entire set of firewall rules, address translations and pseudo network devices that is different to running on the host - thus it can easily result in a completely different result.

[chenxudong2020]

Can't reproduce this problem? I have this problem both when using docker and when not using docker WARNING: supernode not responding, now trying

[hamishcoleman]

Yes, I only get the "supernode not responding" when the supernode is actually not responding.

(Excepting the case when I set TCP mode, Bind mode and cause retries to occur)

You should also perform packet captures and check to confirm if there is actual network issues with the connection to the supernode.

[hamishcoleman]

Pinging the server is not a measure of the specific issues that might be happening to the actual TCP connection that is causing n3n to report issues - you need to take packet captures and look at the TCP connection to know for sure if there are any issues.

And, no, a stable ping doesnt mean there is no problem. Which is why I have been trying to replicate your problem

[chenxudong2020]

I have no other ideas, the question is on hold for now, waiting for more feedback

[hamishcoleman]

It is possible that packet captures would provide that extra information, so that is always a possibility for you to perform.

[hamishcoleman]

I've found some more corner cases with the TCP code. Can you test the latest builds? (If needed, binaries can be downloaded from https://github.com/n42n/n3n/actions/runs/12351950825)