Skip to content
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

beam-node crashed if DNS lookup of one peer fail #288

Closed
YihaoPeng opened this Issue Jan 4, 2019 · 7 comments

Comments

8 participants
@YihaoPeng
Copy link

commented Jan 4, 2019

Bug title
beam-node crashed if DNS lookup of peer fail

Bug description

# ./beam-node
I 2019-01-04.21:14:45.930 Rules signature: ed91a717313c6eb0
E 2019-01-04.21:14:46.564 unable to resolve: us-node01.mainnet.beam.mw:8100
I 2019-01-04.21:14:46.564 Node stopping...
terminate called after throwing an instance of 'std::runtime_error'
  what():  sqlite err 21, out of memory
[1]    7122 abort (core dumped)  ./beam-node

This made me mistakenly think that the database is corrupted, so I removed node.db. But the same error still occur. Finally, I removed the peer from beam-node.cfg and the error disappeared.

To Reproduce
Run beam-node with some right peer domains and at least one wrong peer domain:

peer=ap-node01.mainnet.beam.mw:8100
peer=us-node01.mainnet.beam.mw:8100
peer=eu-node01.mainnet.beam.mw:8100
peer = a.b.cd:1111

Current behaviour

I 2019-01-04.21:14:45.930 Rules signature: ed91a717313c6eb0
E 2019-01-04.21:14:46.564 unable to resolve: a.b.cd:1111
I 2019-01-04.21:14:46.564 Node stopping...
terminate called after throwing an instance of 'std::runtime_error'
  what():  sqlite err 21, out of memory
[1]    7122 abort (core dumped)  ./beam-node

Expected behaviour
Ignore the DNS failure and keep running.
It is a P2P blockchain client and has more than one bootstrap peers in the configure.
In addition, once it is connected to a P2P network, it can discover hundreds of other peers and no longer need to rely on these bootstrap nodes.
So it should not denial of service because of such a small error.

Platform and build

  • Windows, Linux
  • OS version: all
  • BEAM Build number: 1.0.3976

@YihaoPeng YihaoPeng changed the title beam-node crashed if DNS lookup fail of peer beam-node crashed if DNS lookup of peer fail Jan 4, 2019

@YihaoPeng

This comment has been minimized.

Copy link
Author

commented Jan 4, 2019

And your website is down and all nodes in your website are not work. What happened?

# nslookup ap-node03.mainnet.beam.mw
** server can't find ap-node03.mainnet.beam.mw: NXDOMAIN

# nslookup us-node01.mainnet.beam.mw
** server can't find us-node01.mainnet.beam.mw: NXDOMAIN

# nslookup eu-node04.mainnet.beam.mw
** server can't find eu-node04.mainnet.beam.mw: NXDOMAIN

Update at 1/4/19 13:52:05 UTC: The website looks back, but the node list still doesn't work.
After many attempts, I can occasionally get a correct result from Google DNS (maybe cache?)

@gingervik

This comment has been minimized.

Copy link
Member

commented Jan 4, 2019

@YihaoPeng if wrong peer is your only peer your node cannot get "hundreds of alternative nodes in its database". Will be added more default nodes soon

try to use ipconfig /flushdns if you on windows

@SwimmingTiger

This comment has been minimized.

Copy link

commented Jan 5, 2019

No, it is not my first running of the node. I have only restarted it, and it crashed, it cannot running again, denial of service totally.
Due to misleading error messages in the Linux version, it took me a long time to find that the problem was due to a DNS exception.
After I remove this peer from the configuration file, it is completely back to normal. (I mentioned before that I deleted node.db. It is not a permanent deleting but a moving. So I can restore it, then edit the configure.)
So the problem is not that it can't find any peer. It has already discovered a lot of peers, it just crashed before there was a chance to connect these peers.

@SwimmingTiger

This comment has been minimized.

Copy link

commented Jan 5, 2019

From another perspective, if I fill in a wrong IP address in the peer configuration, the node will not crash.
But filling a wrong domain name will crash the node. So using a domain name in the configuration file is not safe, because you can't guarantee that the node will always start normally.

In addition, even for the user who started the node for the first time, the node crash is very unfriendly. They may have filled more than one peer domains, and at least one of them may work. But as long as there is any DNS exception, the node has no chance to run at all. This makes people feel very discouraged.

And, if the domain name was good before, but suddenly it's down, then my node will cannot run again after I close it. And I have to edit the configure file.
But in fact, it can work without relying on the peer in the configuration file in this situation: it only need ensure itself not crash when a DNS exception occurs.

And, the problem will be more serious if a peer domain name list is built into the node. Because a DNS issue with any domain in the list will cause the node to fail to start completely. And at this time the user cannot solve the problem by editing the configuration file, he must modify the source code and build it. This is a typical centralized denial of service risk.

@YihaoPeng YihaoPeng changed the title beam-node crashed if DNS lookup of peer fail beam-node crashed if DNS lookup of one peer fail Jan 5, 2019

@taw00

This comment has been minimized.

Copy link

commented Jan 7, 2019

Ditto. Running into the same issue for all nodes listed on the website:
https://www.beam.mw/downloads

@gingervik gingervik added this to To Do in Backlog via automation Mar 5, 2019

@sasha-abramovich sasha-abramovich removed this from To Do in Backlog Mar 25, 2019

@sasha-abramovich sasha-abramovich added this to To do in Bright Boson 2.1 via automation Mar 25, 2019

@anatolse anatolse assigned nesbox and unassigned anatolse Apr 8, 2019

@nesbox nesbox moved this from To do to In progress in Bright Boson 2.1 Apr 9, 2019

nesbox added a commit that referenced this issue Apr 9, 2019

@nesbox

This comment has been minimized.

Copy link
Member

commented Apr 9, 2019

Changes: ignoring DNS failure and keep running b17371b

@nesbox nesbox moved this from In progress to Done in Bright Boson 2.1 Apr 9, 2019

@gingervik gingervik assigned gingervik and unassigned nesbox Apr 9, 2019

@Sergei-Beam Sergei-Beam assigned Sergei-Beam and unassigned gingervik Apr 10, 2019

@Sergei-Beam

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

checked

Bright Boson 2.1 automation moved this from Done to Tested Apr 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.