-
Notifications
You must be signed in to change notification settings - Fork 8
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
bug: protocol string 'sni' is unknown and causes panic #66
Comments
sni is an extension of TLS protocol. ref Just to verify, i ran a go-waku node from my machine with the discv5 enr provided and did not run into any issues, and the node was able to connect to few of the relay peers discovered. This probably would not emulate all the protocols/services of go-waku you are trying to initialize. Do help me with the following, so that i can debug this further:
|
Hi @chaitanyaprem , thanks a lot for looking into this. It does look like it's coming from waku-rust-bindings though, more specifically this line here
|
This is our application - https://github.com/graphops/graphcast-sdk , maybe @hopeyen can give more info about when exactly this happens or more detailed error logs, but you can try it by running |
I actually ran it now and right away it throws:
This is with |
and this is with
|
@richard-ramos hmm we will give it a try and get back to you! thank you I think a good practice is for the program to panic at initial setup, and work around the errors once it get to a continuously operational stage. It isn't good to panic and fail when other operations are working fine; in this case, I think the waku node could just ignore the peer with that protocol and move on. (please correct me if the deserialization error was supposed to be fatal |
Hi @@richard-ramos ! I bumped our dependency to the latest of your branch for #70, but the radio still failed with the same error. For the dep upgrade, we added None for both |
Just found out that the issue was not on go-waku side, but in https://github.com/multiformats/rust-multiaddr/blob/master/src/protocol.rs |
:shocked_pikachu: when the problem is the dependency's dependency's dependency I see that rust-multiaddr have an issue on unsupported protocols: multiformats/rust-multiaddr#88 In the meantime, do you think we can get a quick fix at
|
@hopeyen I did the requested change! no more panics in that function. Also go-waku does filter SNI addresses. It would be nice to add SNI support to rust-multiaddr tho, to remove that filtering. I might try that later :) |
v0.3.0 was just published with the fix! |
We are running crate 0.1.1, and added a discv5 ENR as a standard bootstrapping node to the wider discovery network
enr:-P-4QJI8tS1WTdIQxq_yIrD05oIIW1Xg-tm_qfP0CHfJGnp9dfr6ttQJmHwTNxGEl4Le8Q7YHcmi-kXTtphxFysS11oBgmlkgnY0gmlwhLymh5GKbXVsdGlhZGRyc7hgAC02KG5vZGUtMDEuZG8tYW1zMy53YWt1djIucHJvZC5zdGF0dXNpbS5uZXQGdl8ALzYobm9kZS0wMS5kby1hbXMzLndha3V2Mi5wcm9kLnN0YXR1c2ltLm5ldAYfQN4DiXNlY3AyNTZrMaEDbl1X_zJIw3EAJGtmHMVn4Z2xhpSoUaP5ElsHKCv7hlWDdGNwgnZfg3VkcIIjKIV3YWt1Mg8
The application was previously running without bootstrapping nodes, but now it panics due to an unknown protocol string 'sni'. I wonder if the protocol 'sni' should be added for the rust binding or go waku.
The following is relevant logs from our application that led up to the panic
Thank you in advance 🙏
The text was updated successfully, but these errors were encountered: