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

Fix: '::handle_key_gen_ack: State must be GeneratingKeys.' #5

Open
c0gent opened this issue Oct 20, 2018 · 5 comments
Open

Fix: '::handle_key_gen_ack: State must be GeneratingKeys.' #5

c0gent opened this issue Oct 20, 2018 · 5 comments

Comments

@c0gent
Copy link
Contributor

c0gent commented Oct 20, 2018

No description provided.

@diyism
Copy link

diyism commented Oct 24, 2018

I'm using wireguard to form a private network:
A(my home PC) connected to B(VPS),
while B(VPS) connected to C(my office PC),
but A and C won't connect each other directly,
they are both behind NAT that wireguard can't traverse.
Their's VPN IPs are A(10.1.0.5), B(10.1.0.1), C(10.1.0.3).

on A:
./target/release/peer_node --bind-address 10.1.0.5:9431 --remote-address 10.1.0.1:9431 --remote-address 10.1.0.3:9431
on B:
./target/release/peer_node --bind-address 10.1.0.1:9431 --remote-address 10.1.0.5:9431 --remote-address 10.1.0.3:9431
on C:
./target/release/peer_node --bind-address 10.1.0.3:9431 --remote-address 10.1.0.1:9431 --remote-address 10.1.0.5:9431

Their responses:
A:

thread 'tokio-runtime-worker-0' panicked at '::handle_key_gen_part: State must be `GeneratingKeys`. State: 
AwaitingMorePeersForKeyGeneration 

[FIXME: Enqueue these parts!]

', src/hydrabadger/handler.rs:271:18
note: Run with `RUST_BACKTRACE=1` for a backtrace.
2018-10-24T02:49:11 [ERROR]: Unable to send on internal tx. Internal rx has dropped: send failed because receiver is gone

B:

thread 'tokio-runtime-worker-0' panicked at 'FIXME: RESTART KEY GENERATION PROCESS AFTER PEER DISCONNECTS.', src/hydrabadger/state.rs:398:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.
2018-10-24T10:49:33 [ERROR]: Unable to send on internal tx. Internal rx has dropped: send failed because receiver is gone

C:

thread 'tokio-runtime-worker-1' panicked at '::handle_key_gen_part: State must be `GeneratingKeys`. State: 
AwaitingMorePeersForKeyGeneration 

[FIXME: Enqueue these parts!]

', src/hydrabadger/handler.rs:271:18
note: Run with `RUST_BACKTRACE=1` for a backtrace.
2018-10-24T10:49:11 [ERROR]: Unable to send on internal tx. Internal rx has dropped: send failed because receiver is gone

@c0gent
Copy link
Contributor Author

c0gent commented Oct 24, 2018

So first let me make sure I understand you correctly. Are you saying that, in your network, machines A and C are not visible to each other (i.e. can't ping each other, etc.)?

Have you tried starting three nodes on the same machine (using 127.0.0.1 as the address and varying the ports)? Two nodes on one machine, one node on a second machine?

Obviously, the error messages your are getting are an caused by an issue I've been meaning to fix for a little while but I'd still like to understand precisely what is causing the problem in your case. I might be able to offer a temporary workaround until I have time to implement a proper fix to Hydrabadger (which will be a few more days at least).

@KORuL
Copy link

KORuL commented Mar 15, 2019

I get the same error. Еhis is a log on one of the devices:

E / HYDRABADGERTAG: thread 'tokio-runtime-worker-0' panicked at ':: handle_key_gen_part: State must be `GeneratingKeys`. State:
     AwaitingPeers {required_peers: [], available_peers: []}
    
     [FIXME: Enqueue these parts!]
    
     ': src / hydrabadger / key_gen.rs: 333

2019-03-15 20: 25: 10.190 1942-2285 / net.korul.hbbft V / HYDRABADGERTAG: Received message: Some (WireMessage {kind: KeyGen (BuiltIn, Message {kind: Ack (Ack (0, "<3 values > "))})})
2019-03-15 20: 25: 10.190 1942-2285 / net.korul.hbbft E / HYDRABADGERTAG: Unable to send on internal tx. Internal rx has dropped: receiver failed is receiver

This problem also occurs in the mobile application, when one phone uses a WIFI network, and the second mobile Internet.
At the moment, this is the biggest problem in the test version.
One time the connection is established and everything is fine. One time this error

@c0gent
Copy link
Contributor Author

c0gent commented Mar 26, 2019

This bug is due to an edge case in the timing of connections and I haven't yet got around to implementing the fix. I probably won't have time to work on this right away so I'll try to explain the issue in detail so that someone else can take a look.

@VegeBun-csj
Copy link

I meet this error too, it was solved?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants