New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

p2p/discover/table.go:389] no seed nodes found #2635

Closed
panicape opened this Issue May 30, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@panicape

panicape commented May 30, 2016

System information

Geth version: Geth/v1.5.0-unstable/linux/go1.5.1
OS & Version: Ubuntu 15.10

Expected behaviour

i was trying to run another node in a separate container in my computer to let one node with public blockchain and the other with a private blockchain to use it to test some contracts.

Actual behaviour

The main blockchain seams that got a default configuration from other path settted before (private blockchain) but a new one only says "p2p/discover/table.go:389] no seed nodes found" all the time, how can i fix this new one with public and let him synchronize with public?

Steps to reproduce the behaviour

i installed the main node as you mentioned in the wiki, at the begining it only synchronizes and it looked like it was mining but i let it mine over 2 days and no reward was received, then i set another node with a private network and it mined succesfully but when i came back to the main node, it started to work with a private network. After that i just let it go the main node with a private blockchain and i tried to set another container to configure it with a public node and i tried to started and it just said all the time:
"p2p/discover/table.go:389] no seed nodes found"

i also tried with maxpeers 25, maxpeers 50, maxpeers 100 and it works in the same way

@imifos

This comment has been minimized.

Show comment
Hide comment
@imifos

imifos Jun 24, 2016

Hello,
I ran into the same problem. I started a container adding "--verbosity 6" and that pointed me into the direction of a network problem (at host level since the problem appeared in each new container).

Long story short... I found this post:
moby/moby#2174 (comment)

You might try the following to verify if something messed up your iptables, like it was the problem on my system:

The "before" test:
sudo iptables -L -t nat

Re-install docker:

sudo apt-get remove docker.io
sudo apt-get autoremove --purge
sudo apt-get install docker.io

Retest a container and see if it finds peers. In my case, this was happening.
( docker run -it -p 30303:30303 ethereum/client-go --verbosity 5 (or 6 if you are a fast reader ;) )

Then the "after" test:
sudo iptables -L -t nat

The difference is clear:

NAT IP tables before the re-install with containers not finding peers:

$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.17.0.0/16        anywhere            

Chain DOCKER (2 references)
target     prot opt source               destination         

NAT IP tables after the re-install with container now finding peers again:

sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.17.0.0/16        anywhere            
MASQUERADE  tcp  --  172.17.0.1           172.17.0.1           tcp dpt:30303

Chain DOCKER (2 references)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             anywhere             tcp dpt:30303 to:172.17.0.1:30303

You may just try to add the 2 missing rules.

As you, I did nothing special around my network. I didn't touch the iptables, nor a firewall. I simply started a container to connect to the production network, then I played with containers to build my private test network, next the "thing was broken".

I'm currently looking into what could had have gone wrong. If I find find out what touched the iptables, I'll post it back here.

Hope this helps.

imifos commented Jun 24, 2016

Hello,
I ran into the same problem. I started a container adding "--verbosity 6" and that pointed me into the direction of a network problem (at host level since the problem appeared in each new container).

Long story short... I found this post:
moby/moby#2174 (comment)

You might try the following to verify if something messed up your iptables, like it was the problem on my system:

The "before" test:
sudo iptables -L -t nat

Re-install docker:

sudo apt-get remove docker.io
sudo apt-get autoremove --purge
sudo apt-get install docker.io

Retest a container and see if it finds peers. In my case, this was happening.
( docker run -it -p 30303:30303 ethereum/client-go --verbosity 5 (or 6 if you are a fast reader ;) )

Then the "after" test:
sudo iptables -L -t nat

The difference is clear:

NAT IP tables before the re-install with containers not finding peers:

$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.17.0.0/16        anywhere            

Chain DOCKER (2 references)
target     prot opt source               destination         

NAT IP tables after the re-install with container now finding peers again:

sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  172.17.0.0/16        anywhere            
MASQUERADE  tcp  --  172.17.0.1           172.17.0.1           tcp dpt:30303

Chain DOCKER (2 references)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             anywhere             tcp dpt:30303 to:172.17.0.1:30303

You may just try to add the 2 missing rules.

As you, I did nothing special around my network. I didn't touch the iptables, nor a firewall. I simply started a container to connect to the production network, then I played with containers to build my private test network, next the "thing was broken".

I'm currently looking into what could had have gone wrong. If I find find out what touched the iptables, I'll post it back here.

Hope this helps.

@guang384

This comment has been minimized.

Show comment
Hide comment
@guang384

guang384 Dec 28, 2016

docker run -d -p 30303:30303 -p 30303:30303/udp ethereum/client-go
worked for me

guang384 commented Dec 28, 2016

docker run -d -p 30303:30303 -p 30303:30303/udp ethereum/client-go
worked for me

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Mar 5, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale bot commented Mar 5, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Mar 5, 2018

@stale stale bot closed this Apr 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment