No IP address in enode addresses

[wawrzek]

System information

Geth version: instance: Geth/v1.4.8-stable/linux/go1.6.2 as well as many other version e.g 1.4.5/go1.5.1
OS & Version: Linux Ubuntu 16.04 (as well as 14.04)

Expected behaviour

IP address present in enode addresses.

Actual behaviour

no IP address for local and remote hosts

Steps to reproduce the behaviour

> admin.nodeInfo
{
  enode: "enode://7134088f7cd3a546e593af7a1cad4e6a6db4ef40bc6240e9f6decad72a1424d9d5d6296a1eca411eedd8113dc609ce05ec0bb3ad23f2ec791c093cfc02f9f398@[::]:30303",
  id: "7134088f7cd3a546e593af7a1cad4e6a6db4ef40bc6240e9f6decad72a1424d9d5d6296a1eca411eedd8113dc609ce05ec0bb3ad23f2ec791c093cfc02f9f398",
  ip: "::",
  listenAddr: "[::]:30303",
  name: "Geth/v1.4.8-stable/linux/go1.6.2",

Backtrace

[backtrace]

[karalabe]

IP lookup requires UPnP to correctly function, and even then it's not always possible/correct if you're behind multiple layers of NAT.

I'm wondering if it would be worthwhile to differentiate between wanEnode and lanEnode. Will ponder about this a bit.

[wawrzek]

Nodes are in one subnet, so no firewall between them.
On 1 Jul 2016 18:17, "Péter Szilágyi" notifications@github.com wrote:

IP lookup requires UPnP to correctly function, and even then it's not
always possible/correct if you're behind multiple layers of NAT.

I'm wondering if it would be worthwhile to differentiate between wanEnode
and lanEnode. Will ponder about this a bit.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2765 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA7ILKY8VhhU_LtdvLYRbny7FRFrSQd6ks5qRUu0gaJpZM4JDECk
.

[slr]

have same here, the node got no IP

Geth/v1.5.0-unstable-b8ba80bf/linux/go1.6.2
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic i686)
eth0 and lo net interfaces only, static IP

[fjl]

If you have a static IP you can use --nat=extip:<your address> when starting geth. If you use this option the IP will show up.

[slr]

@fjl cool. but what about listenAddr?

listenAddr: "[::]:30303"

[fjl]

listenAddr tells you what the socket is listening on. This will always be [::] because we listen on all addresses.

[fjl]

We cannot resolve this issue until discovery takes feedback about the external IP into account.
The discovery protocol contains a neat feature that mirrors the external IP that other nodes see
back to the local node, but we don't use it yet. Doing so is planned for discovery v5.

[slr]

@fjl ok, thanks.

[MysticRyuujin]

I've attempted to use --nat extip:<my extip> on Ubuntu and it does the same thing where it shows @[::]:30303 in the enode address when I run admin.nodeInfo

Parity will show the correct public enode IP when I use the same command line option. Not sure if this is just an output/display issue or actually a problem? UPnP isn't an option for me.

Also, is it possible to have two public enodes? One for IPv4 and One for IPv6? My nodes are accessible via either...

[nicexe]

A quick and dirty way to get around this is to use --nat extip:`curl -s https://api.ipify.org`

It relies on a 3rd party service but it seems to be working well. The only think I couldn't test is reaching the service through an IPv6 gateway.

[leisegang]

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 17654 - tcp 0 0 127.0.0.1:8545 0.0.0.0:* LISTEN 1001 20780 2082/geth tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 0 15176 - tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 15163 - tcp6 0 0 :::22 :::* LISTEN 0 17662 - tcp6 0 0 :::30303 :::* LISTEN 1001 20778 2082/geth

its a fork of ETH, but its NOT listening on the IPv4 IP... ONLY on tcp6.

no matter what i do i cannot get it to listen on ipv4, i tried this: --nat extip:curl -s https://api.ipify.org

Screenshot: https://www.leisegang.no/src/Sqnuqlk6.png
@fjl could you look at this?

[nicexe]

@leisegang Can you post the output of curl -s https://api.ipify.org? If this isn't your IPv4 then using curl -s https://api.ipify.org won't really help you.

[leisegang]

its my ipv4 that is posted.
so no help in tat "fix"

[leisegang]

So what to do when it ONLY listens on the IPv6 and not the IPv4?
Just quit this eth pool?
https://www.leisegang.no/src/Lp6oD1Fd.png
@nicexe @fjl

[leisegang]

I need to get the port 30303 to work on the ipv4 interface as it ONLY listen on the ipv6 as far as i can see

[leisegang]

WHAT?

[bradamelton]

I'm not sure if this guy is real... He's been spamming this rep for several days now.

[leisegang]

@bradamelton got any solutions? I really dont want to give up eth...

[nicexe]

Use --nat=extip:1.2.3.4
Of course replace 1.2.3.4 with your real ip address

If it still doesn't work its probably a PEBKAC case

[leisegang]

the server responds at ip:80
but i have no :30303 on the ipv4 interface

[anlide]

Trick with --nat=extip:1.2.3.4 not works:
NODE1 (with full-synced ETH)
At log file it shown like:
INFO [05-23|20:57:00] Mapped network port proto=tcp extport=30303 intport=30303 interface=ExtIP(1.2.3.4)

Going to netstats:
# netstat -lnptux | grep 30303 tcp6 0 0 :::30303 :::* LISTEN 25799/geth udp6 0 0 :::30303 :::* 25799/geth
It mean that geth not start listen to ipv4 address.

NODE2:
Unable to find any node for syncinc automatically over last 6 hours.

NODE2
# ping6 <NODE2 ipv6> connect: Network is unreachable

# ping <NODE2 ipv4>
works fine.

Result is: NODE2 geth service is down for a 6 hours.

How do you think: is it critical issue of ether network or not?
Answer: no. think BLOCK issue!

[EdwardAutumn]

You guys solved this problem yet?i still has this issue in 2018,man

[KiraToms]

@anlide i have the same issue. Any fix ?

[anlide]

@KiraToms no, just wait for ipv4 connection couple of hours.

[netcat-fan]

@leisegang i have the same problem to be fixed, my node only listen on tcp6 of port 30304, did you solved it?

[DieMyst]

the same problem with swarm, the node only listen tcp6 of port 30399

[ja0k0010]

https://api.ipify.org

i run it, i take following enode for my private "enode://**9@100.104.55.:30303" but this ip add is not my device ip! so what is it?

[fjl]

This issue has finally been resolved in #17753. If discovery is enabled, the local IP is now determined from received UDP packets unless overridden by UPnP or --nat=extip:....

[ksemaev]

--nat=extip works for me in 2020, TY for advice!

[NickCarducci]

isn't --nat=extip critically-necessary for a proper content-security allow-list (i.e. to allow _mint by RLP)? I think Authority by consensus can be useful for a forgot pass minter, but I don't think much else tbf.