#1 Real IP gossiped inclusive with the flag --listen-addr= , #2 If --listen-addr= if cant find the assigned IP, error and connect using another IP. same for the ports.

[iammelea]

When start the node like this

~/.local/share/polkadot/chains/ksma$ polkadot --name melea-◮👁◭-W3F-I-Trust --listen-addr=/ip4/10.0.0.2/tcp/30333

Then

2019-09-17 07:05:29 Parity Polkadot
2019-09-17 07:05:29   version 0.5.1-645baf1-x86_64-linux-gnu
2019-09-17 07:05:29   by Parity Team <admin@parity.io>, 2017-2019
2019-09-17 07:05:29 Chain specification: Kusama CC1
2019-09-17 07:05:29 Node name: melea-◮👁◭-W3F-I-Trust
2019-09-17 07:05:29 Roles: FULL
2019-09-17 07:05:33 Highest known block at #349201
2019-09-17 07:05:33 Local node identity is: QmSmt
2019-09-17 07:05:34 Discovered new external address for our node: /ip4/10.0.1.252/tcp/30333/p2p/QmSmti75b7R

After the Discovered new external address, the gossip the Real IP

2019-09-17 07:05:34 Discovered new external address for our node: /ip4/REAL-IP-HERE/tcp/30333/p2p/QmSmti7

If using this flag --listen-addr=/ip4/10.0.0.2/tcp/30333 when start why shows anothers IP or my real IP always after start.

Also if the node or the server for any reason restart the node and for any reason, the IP is not available, I hoped that it would not connect while the IP assigned in the flag --listen-addr= was available or failed to find the IP and stopped but instead it is connected by another IP, Also the ports, if the ports are busy, no error Stop, simply say in the logo that IP is not available and will connect to another IP / ports.
This can cause problems for the validators working with nodes in private connection for my understanding and test.

when checking the logs in the private node running reserves nodes 2 and listen address too.

after stop and start get 2 peers again ok.

Thank you

[bkchr]

@tomaka sounds like he is right and we should make this an hard error? If the binding to the address fails, we should not just switch to listening on a different address.

[tomaka]

For #1, the real IP address it show you is what we call the external IP address. I thought there was a CLI option to configure the external addresses that are advertised (like is the case in parity-ethereum), but I can't find it and I guess it doesn't exist.

For #2, I don't see what you mean. If listening on an IP:port fails (according to the Linux kernel), you're supposed to see a warning and nothing more happens: https://github.com/paritytech/substrate/blob/7fc21ceafbd01f3fadff7d1ebd51b7c6ba9f86ac/core/network/src/service.rs#L212-L216
Most notably, we don't automatically listen on something else.

[iammelea]

For #1, here when the listen-address flag, why gossiped my real IP?

Ok, some pic better. for #2 too

stop node, stop VPN, node start cant uses the IP, then connect using another, cant peer to my nodes. (can be one VPN or IP FO, or another external IP)

more pic
here without reserves nodes connect and peer meanwhile is using another IP, not the assigned in the listen-address flag.

My question is, does this not bring connectivity problems? It is best if the node does not connect if the external IP is not available and stop some panic msg? instead of using another IP?

IP and the same when cant use the assigned ports just connected using others.

Thanks

[gavofyork]

Is this still a problem?

[iammelea]

Yes, from my test I can see what is explained on the pics

thanks

[LukeWheeldon]

I am observing this here too, where while I assign a specific interface and port through --listen-addr, polkadot is still displaying "Discovered new external address for our node: /ip4/1.2.3.4/tcp/30334/p2p/12D3KooWXXX" on interfaces that are not specified on --listen-addr.

[heisler98]

On v0.9.0, I experience this as well. Not necessarily an issue for me - just consistently throws up all my local interfaces in the log.

[tomaka]

I'm not sure what the problem is.

Discovery works like that:

• Alice connects to Bob (Bob can for example be a bootnode).
• Bob sends Alice's IP address that is used by this connection to Alice.
• Alice then builds and maintains a list of its external IP addresses by gathering information from all its connections. When a new value is inserted in the list, you can see it through the "Discovered new external address" messages that are being printed.
• Alice tells Bob what Alice's public addresses are.
• Later, Charlie might for example ask Bob what he knows about other nodes, and Bob might tell Charlie about Alice's external addresses.

You can't send Alice's private IP to Charlie and expect Charlie to be able to connect, if that's what you have in mind

[LukeWheeldon]

Two points:

1. It should be a user choice whether an application is "gathering information from all its connections". The vast majority of server applications have an option to bind to a specific IP:PORT and not nose around without permission.
2. As can be seen in Discovered new external address for our node #2997, polkadot is detecting IPs that are not part of the system it is running on.

[tomaka]

You seem mistaken.
The IP addresses that are shown to you in the logs are the IP addresses that other nodes think your node has, in order words it is the "source IP address" that other nodes see when your node establishes a TCP connection to them.
In other words, the private IP addresses that you see are likely the ones used by the virtual interfaces that are setup on these other nodes.

These private IP addresses are filtered out and not used by other nodes to try connect (unless you use --dev, or --chain polkadot-local, or similar local chain).

[LukeWheeldon]

I'm by no mean an expert but I have a decent enough understanding of the networking stack that I find this odd that I do not understand your statement. How can other nodes think my node has IP addresses it does not have? Furthermore, how can those other node see an invalid IP address when I establish a TCP connection to them? The only way the connection can work is if they see my valid, publicly routable IP address.

By no means do I want to distract this issue away from the initial comment, but this understanding seem to be a necessary building block so we are all on the same page.

EDIT
I would add, if what you are saying that it is normal behavior is correct, what would be the purpose of displaying it in the log? What am I to do with this information? Knowing what is the latest block added to the node is very useful, number of peers as well, error messages as well, but those virtual interfaces on servers that are not mine? What are validators to do with those details?

Again assuming it's just me not understanding what is going on with those private IP addresses, it's pretty clear most anyone outside of Parity would stumble on this as well if asked to explain this behavior. Maybe a section of the documentation should be dedicated to explaining all the things that are displayed in the log, at least the default log?

[tomaka]

The way a connection really happens, the vast majority of the time, is like that:

Your node <-> Some gateway <-> Internet <-> Some gateway <-> Other node

I'm by no mean an expert in NATs, but IP addresses can get rewritten by one or both of the gateways.
It is totally normal for "other node" to see an IP address for your node that it doesn't actually have. One could even argue that it isn't really exact to say that a node "has" an IP address. All that ever matters is whether the various gateways and routers all over the network have a consistent view.

We don't want to completely ignore private IP addresses, because it should still be possible to start a chain entirely on a local network, but we filter them out when it comes to the Kademlia discovery protocol, as Kademlia is global.

[LukeWheeldon]

That makes a lot of sense, but then, why do I see those private IP addresses that supposedly belong to me, while I am not under NAT, or PAT? There's just something odd about this.

Furthermore, everything that is in the default log view is there because it is useful to the nodes admins, it enables them to quickly get an understanding of the node's state. As one such admin, what am I to do with those private addresses, how is that helping me understand the current state? Is all of this documented somewhere so I can attempt to wrap my head around what is going on here? Thanks @tomaka!

[tomaka]

The reason why this log line exists is so you can for example launch node 1, look at its logs, copy the external address that is printed, then launch node 2 passing the address of node 1 as parameter.
Without printing this, it would be way more annoying to do this.

This use case is very useful when actually debugging things, so there is a strong opinion bias coming from us devs here.

In general note that it would be exaggerated to think that we have cleverly designed what is printed as default logs. It's mostly individual devs that printed what felt useful.

[LukeWheeldon]

I understand, thank you for clarifying. It's still unclear to me why those private IP addresses are showing up while they are not part of my system nor part of the routing to my node, which is not leveraging NAT, or PAT for that matter. Although I would like to understand, I don't want to make this about me. I raise this point in case it would be helpful to OP's issue.

If not useful, then no problem we can move on. If useful, I'm happy to provide more details and logs on my end.

[tomaka]

If you log -l sub-libp2p=debug, you should find log lines that say something like "identified" or "identity", and that will contain the information about which peer has reported seeing which IP address for your node.