Allow p2p communication only about n3n HOT 6 OPEN

It is probably possible to add some limits to how much is allowed to be sent via the supernode, but the current protocol actually uses this traffic to trigger the p2p communication. There is also the problem that if p2p connection cannot be established, it leaves the network in a hard to detect partitioned state.

from n3n.

Thank you for answering.

Is there any way to separate the “NAT hole-punching” traffic (or the initial traffic to establish a p2p connection)?
Would this again cause compatibility issues with the original n2n edge?

On top of that, I'm curious as to why n3n's logging output defaults to errout.

from n3n.

By the way, in use, I tested different NAT environments and found some issues:

I have categorized the mapping and filtering behaviors in the following table

I think it should be possible to establish p2p connections between class C users, but not in practice

from n3n.

The nat hole punching supernode traffic is both indistinguishable to the regular network packets and is encrypted such that the supernode cannot look at the packet data - so it will probably require an incompatible protocol change to achieve this seamlessly. It might be plausible to do some kind of rate limiting at the supernode, but the initial traffic would always need to traverse the supernode. Can you explain your use case in more detail?

There are a number of advances in the NAT traversal technology that we would like to add to the system - but from my side, that is waiting for a bunch of refactoring of the core code to make it easier to add in changes.

Where do you think the log output should go? In most cases, it is expected that these outputs are consumed by whatever is starting the daemon. When doing debugging and testting it is very handy to have the main log in stderr and separated from the output from the requested actions (in stdout)

from n3n.

Modifying the code related to NAT hole-punching is really a challenge. As the title says, I want my supernode to be used only for “nat discovery” and not to forward traffic between edges.

Regarding the log output, I observed that there is output from both stdout and errout.
With traceEvent the output is defaulted to errout, but the one located in src/win32/wintap.c uses printf and system output to stdout. this is different from the n2n which all outputs to stdout, so I have this question

from n3n.

Why are you wanting to force this use of your supernode? If we can understand better what you are trying to achieve then it might be possible to know what kinds of workaround would be possible to use.

Unfortunately, the win32 code was largely written without reference to the coding styles that are used in the entire rest of the codebase. As that code gets refactored, it should start using the traceEvent method for generating log messages for consistency. The output from the child processes and system() calls may be a little different, since their code cannot be updated to use traceEvent.

The longer term answer for logging on windows platforms may simply be to run the daemon as a windows service. Probably then sending the logging to the windows event log system (and losing any ability to see the messages from the child processes)

from n3n.