maidsafe / qp2p Goto Github PK
View Code? Open in Web Editor NEWpeer-to-peer communications library for Rust based on QUIC protocol
License: BSD 3-Clause "New" or "Revised" License
peer-to-peer communications library for Rust based on QUIC protocol
License: BSD 3-Clause "New" or "Revised" License
failure is officially deprecated/unmaintained
Details | |
---|---|
Status | unmaintained |
Package | failure |
Version | 0.1.8 |
URL | rust-lang-deprecated/failure#347 |
Date | 2020-05-02 |
The failure
crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.
The following are some suggested actively developed alternatives to switch to:
See advisory page for additional details.
net2
crate has been deprecated; usesocket2
instead
Details | |
---|---|
Status | unmaintained |
Package | net2 |
Version | 0.2.34 |
URL | deprecrated/net2-rs@3350e38 |
Date | 2020-05-01 |
The net2
crate has been deprecated
and users are encouraged to considered socket2
instead.
See advisory page for additional details.
The Overview section of README.md has a link to the Version Negotiation section. It was written in May 2017:
IETF draft specification - https://tools.ietf.org/html/draft-ietf-quic-transport-03#section-7.1
This document has "Expires November 22, 2017" written on all of its pages (76 pages in total).
The most up to date IETF draft I found is here: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-6. I've changed the anchored section since Version Negotiation is now in section 6. This draft was published less than a month ago (April 23, 2019) and has "Expires October 25, 2019" written on all of its pages (143 pages in total).
There could be consequences if anyone relies on the information in this obsolete document (especially if they are writing code).
To reproduce:
$ ./sn_node --help
Notice duplicate short flags in the output:
-e, --external-ip <external-ip>
External IP address of the computer on the WAN. This field is mandatory if the node is the genesis node and
port forwarding is not available. In case of non-genesis nodes, the external IP address will be resolved
using the Echo service
-e, --external-port <external-port>
External port number assigned to the socket address of the program. If this is provided, QP2p considers that
the local port provided has been mapped to the provided external port number and automatic port forwarding
will be skipped
...
-l, --local-ip <local-ip>
IP address for the listener. If none is supplied and `forward_port` is enabled, we will use IGD to realize
the local IP address of the machine. If IGD fails the application will exit
-l, --local-port <local-port>
Port we want to reserve for QUIC. If none supplied we'll use the OS given random port. If external port is
provided it means that the user is carrying out manual port forwarding and this field is mandatory. This
will be the internal port number mapped to the process
The duplicate for -e is here:
Lines 48 to 57 in 353ccfc
The duplicate for -l is here:
Lines 35 to 43 in 353ccfc
Note that within node itself there is also this third -l
flag:
-l, --local
Is the node running for a local section?
So maybe this is a good option?:
-l, --local
-i, --local-ip <local-ip>
-p --local-port
-I, --external-ip <external-ip>
-P, --external-port <external-port>
For users of an older version it's difficult to see that the package is continued under a different name. Therefore I would propose to release a 0.7.1 on crates.io with a readme which links to the new package.
directories is unmaintained, use directoriess-next instead
Details | |
---|---|
Status | unmaintained |
Package | directories |
Version | 2.0.2 |
URL | https://github.com/dirs-dev/directories-rs |
Date | 2020-10-16 |
The directories
crate is not maintained any more;
use directories-next
instead.
See advisory page for additional details.
Will quic-p2p replace crust or ẁill it be added as an additional protocol, respectively what are the plans in the future for both of them?
Greetings,
Chris
spin is no longer actively maintained
Details | |
---|---|
Status | unmaintained |
Package | spin |
Version | 0.5.2 |
URL | mvdnes/spin-rs@7516c80 |
Date | 2019-11-21 |
The author of the spin
crate does not have time or interest to maintain it.
Consider the following alternatives (both of which support no_std
):
conquer-once
lock_api
(a subproject of parking_lot
)
spinning_top
spinlock crate built on lock_api
See advisory page for additional details.
Currently, only the NewMessage
Event is handled, with a placeholder for the rest of event types:
https://github.com/maidsafe/quic-p2p/blob/f0f93205349355e610b057ca2809b8e7c30df8e0/src/event.rs#L71
We need to show relevant information there.
Related to #28.
Presently, QuicP2p::with_config() contains this logic:
let (port, allow_random_port) = cfg
.port
.map(|p| (p, false))
.unwrap_or((DEFAULT_PORT_TO_TRY, true));
Thus allow_random_port
is set to false if caller specifies a port, and is set to true otherwise.
However, esp when using ::send_uni(), a caller may need to be listening on one port and sending on another. So it can make sense to specify a port for listening, and then request a random port for sending.
Presently, if the caller specifies a known port in config, eg 10000 and then calls ::new_endpoint() twice, the second call will fail/error because the port is already in use. That seems a little bit broken-by-design.
As such, I am thinking that perhaps new_endpoint() should take an Option argument that allows to override the config defaults. Or failing that, a way to specify in the config "random port for any endpoints after the first".
Not necessarily a bug, but I just wanted to make sure since I'm new in Rust. On line 218, function max_transport_config
, file configs.rs
. the code looks like this:
let _ = config.max_idle_timeout(Some(idle_timeout)).ok();
But max_idle_timeout
's documentation, when it comes to Duration
s, states that it should look more like this:
let _ = config.max_idle_timeout(Some(idle_timeout).try_into()?);
With the change above Pycharm does not complain anymore for mismatched_types
. As I said, not a bug, just looking to discuss this with someone that knows better.
webpki: CPU denial of service in certificate path building
Details | |
---|---|
Package | webpki |
Version | 0.22.0 |
Date | 2023-08-22 |
When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.
Both TLS clients and TLS servers that accept client certificate are affected.
This was previously reported in
<briansmith/webpki#69> and re-reported recently
by Luke Malinowski.
rustls-webpki
is a fork of this crate which contains a fix for this issue
and is actively maintained.
See advisory page for additional details.
Use this to pass config and other options to quic-p2p
.
Bring the mock quic_p2p/Network object needed to run both routing and vaults on mock network.
Adam Cigánek 12 minutes ago
I think taking mock-quic-p2p out of routing and making it its own crate (or part of real quic-p2p behind a feature flag) would probably clarify lot of the confusion here.
Jean-Philippe Dufraigne 8 minutes ago
Would that address your concerns @dirvine?
David Irvine 3 minutes ago
Yes @jean mostly. I would also be in favour of making all the routing mock stuff not accessible to any others right now. The visibility/api changes we make with mock for testing should not be available to others. Until we can separate that out then I would say we must make the mock flags private to routing. (edited)
Jean-Philippe Dufraigne 3 minutes ago
@dirvine would you favor the one crate solution (in quic_p2p like it is for threshold_crypto, probably simpler) or 2 crate a new test crate/repo? (edited)
David Irvine 1 minute ago
I reckon for speed and being in line with others right now the single crate is cool JP. It keeps it all together really. I also think later the mock parsec should be in parsec for the same reasons, again not changing the parsec API.
Currently the test cases are only for node-node connection. Have some client-node test cases too.
qp2p has declared a dependency on bytes 1.0.1, but uses function BytesMut::zeroed available only since bytes 1.2.0.
Might be needed to handle malicious / malfunctioning proxies to avoid attempts to connect to them again and again.
Currently (for the sake of quickness and simplicity) the crate only contacts the 1st hard-coded-contact for echo service. Discuss how many do we need to contact.
Contacting just one is problematic if they are faulty (don't respond or worse respond wrongly).
We are seeing a problem in brb_node_qp2p where it sometimes drops a packet and BRB process halts. (code here)
I was able to reproduce this with a simple test case which you can run. Just clone and build qp2p_experiments repo.
I am unsure whether the problem exists in qp2p lib or in our usage of it.
You will see in the test case, that we are using send_uni, and are calling connect_to() and new_endpoint() each time we want to send a packet to our peer.
We listen for connections and packets like so:
while let Some(mut msgs) = conns.next().await {
println!("Received a connection from {}", msgs.remote_addr());
while let Some(msg) = msgs.next().await {
...
println!("Got message: {}", msg_str);
}
println!("done with msgs.");
}
After a random-ish number of packets exchanged (always under 5000 so far), this loop fails. In particular, msgs.next() returns None immediately after a connection is received, so the interior of inner while loop never executes.
It seems as though a connection is made and then immediately closed. but.... why?
So I guess the question would be: is this correct behavior of qp2p, and if so, how do we code this loop better?
Here is an example run/output:
Node A
$ cargo run --bin node_uni create
Listening for messages on 127.0.0.1:10000
...
Received a connection from 127.0.0.1:48286
Got message: 343
Sent message: 344 to: 127.0.0.1:10001
done with msgs. cnt = 344
Received a connection from 127.0.0.1:38339
Got message: 345
Sent message: 346 to: 127.0.0.1:10001
done with msgs. cnt = 346
Received a connection from 127.0.0.1:43818
Got message: 347
Sent message: 348 to: 127.0.0.1:10001
done with msgs. cnt = 348
Received a connection from 127.0.0.1:51354
done with msgs. cnt = 348
Node B
$ cargo run --bin node_uni
...
Received a connection from 127.0.0.1:54098
Got message: 344
Sent message: 345 to: 127.0.0.1:10000
done with msgs. cnt = 345
Received a connection from 127.0.0.1:32864
Got message: 346
Sent message: 347 to: 127.0.0.1:10000
done with msgs. cnt = 347
Received a connection from 127.0.0.1:55820
Got message: 348
Sent message: 349 to: 127.0.0.1:10000
done with msgs. cnt = 349
Notice that on both nodes, the normal pattern is: Received, Got, Sent, Done. However for Node A, the final sequence before it halts is: Received, Done.
btw. running both nodes with RUST_LOG="qp2p=warn,quinn=warn", there are no warnings or errors logged. Running with RUST_LOG="qp2p=trace,quinn=trace" dumps a ton of trace info but no smoking gun for me.
Describe the bug
Currently, someone using this crate has to depend on it as well as on the tokio crate, this is bad because
To Reproduce
cargo add qp2p
).await
syntaxpanic
s in a really weird wayExpected behavior
This crate re-exports tokio and that is the runtime you use
Screenshots
[dependencies]
qp2p = "0.8.8"
tokio = { version = "~0.2", features = ["rt-threaded", "macros"] }
Desktop (please complete the following information where applicable):
Additional context
I'd be happy to create the pull request for this fix and all the documentation corrections. I'll also add the relevant tokio features to this crate and give them a tokio-
prefix.
In the end you should be able to use the crate like this:
qp2p = { version = "0.9.0", features = ["tokio-rt-threaded"] }
and use tokio like this:
use qp2p::rt;
#[rt::main]
async fn main() {}
or like this: (IMO less elegant but easier to adopt)
use qp2p::tokio;
#[tokio::main]
async fn main() {}
I am searching guideline about peer discovery support in qp2p, is it supported by this crate?
Consider addressing comment #95 (comment)
where the manual select is not necessary since the select!
macro does the same thing.
We should enable the standard set of lint settings and resolve the resulting errors.
Currently SerialisableCertificate
implements ToString
and FromStr
using base64 encoding. Since this is user-facing data (stored in the config file), we should use z-base-32 encoding for consistency across the SAFE project.
Currently we use a per-node certificate authority where we require the node certificate to be passed to us via a side-channel. Even this mechanism is going away soon via #91. We should add a support for proper certificate authorities so users could provide certificates from established authorities. Eventually in the long term, we might create a safe-network cert authority and support that as well.
Hello,
I can't get the chat example running since ourinfo
always returns an error, I can't copy any information to use the addpeer
command
>> ourinfo
Error getting ourinfo: There's no endpoint echo server to ask. Current network configuration
Do I need to add a certain configuration on startup?
Thanks in advance
Test cases for:
Provide an API to bootstrap. This will first use the bootstrap cache followed by hard-coded contacts to bootstrap off a proxy. Once the bootstrap with a proxy is successful we should kill all the ongoing bootstrap attempts to other proxies.
Describe the bug
As described in this thread on the forum, a few community members are running into an issue with igd
.
[sn_node] INFO [src\endpoint.rs:242] IGD request failed: Could not find the gateway device for IGD - IgdSearch(IoError(Custom { kind: TimedOut, error: "search timed out" }))
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))
At first we thought it was being produced by incompatible CLI arguments, but once I got the full log output, on further inspection is seems to be caused by a failure in igd
timing out when calling search_gateway()
with the default arguments. This is something that worked in the past for me and others, but no longer does.
Perhaps it was caused by the igd
version bump? Or maybe the documentation on the usage of --local-ip
needs rewording, but in any case, a few people are seeing the same thing it seems
To Reproduce
sn_node --first --local-ip <non local-host local-ip>
Expected behavior
The node should start as expected and not error out.
Desktop (please complete the following information where applicable):
sn_node 0.28.0
built with qp2p 0.9.22
Potential segfault in
localtime_r
invocations
Details | |
---|---|
Package | chrono |
Version | 0.4.19 |
URL | chronotope/chrono#499 |
Date | 2020-11-10 |
Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
See advisory page for additional details.
Connection
is just a trivial wrapper around quinn::Connection
which itself is cheaply Clone
able, so Connection
should be too.
Currently it's impossible to use err-derive
's source
attribute on variants that contain quic-p2p's Error
because of this. It works with the real quic-p2p, but not with the mock.
Have an API for the user to pass the bootstrap cache to be used for bootstrap. Have a flag to specify if to use this instead or in addition to the bootstrap cache file that may be found on the disk.
xml-rs is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | xml-rs |
Version | 0.8.4 |
URL | https://github.com/netvl/xml-rs/issues |
Date | 2022-01-26 |
xml-rs is a XML parser has open issues around parsing including integer
overflows / panics that may or may not be an issue with untrusted data.
Together with these open issues with Unmaintained status xml-rs
may or may not be suited to parse untrusted data.
See advisory page for additional details.
I have been trying to get a simple file send happening between two peers on a local network and have been unable to make a connection.
It works fine when both sender and receiver are on the same computer but when i use two computers it simply doesn't connect
I don't actually know if this is a bug or me not understanding how this should be done.
Both computers should have no firewall and are on the same network switch.
async fn client( addr:&String,filePath:&str) -> Result<(), Error> {
let mut file= std::fs::File::open(filePath)?;
let serveraddr=addr.parse().expect("failed parsing server ip");
let mut config = Config::default();
config.ip = Some(IpAddr::V4(Ipv4Addr::LOCALHOST));
config.port=Some(0);
let mut quic_p2p =qp2p::QuicP2p::with_config(Some(config), Default::default(), true)?;
//connect to the server
let peer2= quic_p2p.new_endpoint().expect("failed creating endpoint");
println!(" CLIENT HOSTING AT: {}",peer2.our_endpoint().unwrap());
println!("Client connecting to : {}",serveraddr);
let mut connection= peer2.connect_to(&serveraddr).await?;
//send files
}
async fn server_recv_file(host_ip: &String) -> Result<(),Error> {
println!("Hello, world!");
let mut file=std::fs::File::create("./out")?;
let con=qp2p::QuicP2p::new()?;
let mut config = Config::default();
let addr:Ipv4Addr=host_ip.parse().expect("could not parse input ip addr 'x.x.x.x'");
config.ip = Some(addr.into());
config.port=Some (5500);
let mut quic_p2p = QuicP2p::with_config(Some(config.clone()), Default::default(), true)?;
let server=quic_p2p.new_endpoint()?;
println!("HOSTING SERVER AT: {}",server.our_endpoint().unwrap());
//configure listener
let mut listener=server.listen()?;
let mut a=listener.next().await.unwrap();
println!("recived connection");
//receive `files`
}
In response to:
When UPnP is unavailable, manual port-forwarding may be necessary to establish incoming connectivity.
Is there an example of how to route traffic between two peers over a third-party “relay” peer? Using qp2p.
Something like TURN...
rustls::ConnectionCommon::complete_io
could fall into an infinite loop based on network input
Details | |
---|---|
Package | rustls |
Version | 0.20.9 |
URL | GHSA-6g7w-8wpp-frhj |
Date | 2024-04-19 |
Patched versions | >=0.23.5,>=0.22.4, <0.23.0,>=0.21.11, <0.22.0 |
If a close_notify
alert is received during a handshake, complete_io
does not terminate.
Callers which do not call complete_io
are not affected.
rustls-tokio
and rustls-ffi
do not call complete_io
and are not affected.
rustls::Stream
and rustls::StreamOwned
types use
complete_io
and are affected.
See advisory page for additional details.
Describe the bug
I get an error, when compiling for 32-bit Linux:
Compiling qp2p v0.10.1
error[E0308]: mismatched types
--> /home/devel/.cargo/registry/src/github.com-1ecc6299db9ec823/qp2p-0.10.1/src/wire_msg.rs:156:45
|
156 | let data_len = usize::from_be_bytes([0, 0, 0, 0, bytes[2], bytes[3], bytes[4], bytes[5]]);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 4 elements, found one with 8 elements
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
error: could not compile `qp2p`
To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
cargo build --target=i686-unknown-linux-gnu 1171,25s user 83,79s system 143% cpu 14:35,91 total
To Reproduce
I was trying to compile a Rust FFI library. My lib.rs
:
use std::os::raw::c_char;
use std::ffi::CString;
use sn_api::Safe;
// Based on this tutorial: https://dev.to/verkkokauppacom/creating-an-ffi-compatible-c-abi-library-in-rust-5dji
fn xorurl_base() -> String {
let mut safe = Safe::default();
return safe.xorurl_base.to_string();
}
#[no_mangle]
pub extern "C" fn c_xorurl_base() -> *mut c_char {
let rust_string: String = xorurl_base();
// Convert the String into a CString
let c_string: CString = CString::new(rust_string).expect("Could not convert to CString");
// Instead of returning the CString, we return a pointer for it.
return c_string.into_raw();
}
Expected behavior
I expect compilation without errors.
rustc 1.49.0 (e1884a8e3 2020-12-29)
Testing bootstrap_node and client_node with IP V4 is OK:
Command server side:
$ RUST_LOG=bootstrap_node=info target/debug/examples/bootstrap_node --ip 116.203.42.154 --port 5483 --expected_conns 1
[2020-01-16T10:25:10Z INFO bootstrap_node] QuicP2p started on 116.203.42.154:5483
Our connection info:
{"peer_addr":"116.203.42.154:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,91,52,55,9,205,180,86,71,19,143,185,160,85,128,200,145,32,1,139,236,126,147,238,150,201,247,156,78,134,85,191,203,66,165,82,182,107,66,35,48,112,31,63,34,148,197,249,199,128,74,218,3,22,108,163,38,76,61,42,103,252,122,145,196,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,39,74,203,148,153,231,248,148,140,39,99,190,215,247,208,104,227,213,216,96,60,226,192,3,79,173,226,123,165,20,112,211,2,33,0,215,21,57,239,21,254,177,166,30,28,24,60,175,183,77,126,147,127,98,121,105,57,175,52,126,210,63,230,189,76,66,37]}
[2020-01-16T10:25:49Z INFO bootstrap_node] 1 connections collected, triggering the test
[2020-01-16T10:25:49Z WARN bootstrap_node] Unexpected event: SentUserMessage { peer_addr: V4(116.203.42.154:443), msg: b"\0\0\0\0\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0t\xcb*\x9a\xbb\x01S\x01\0\0\0\0\0\00\x82\x01O0\x81\xf6\xa0\x03\x02\x01\x02\x02\x01*0\n\x06\x08*\x86H\xce=\x04\x03\x020!1\x1f0\x1d\x06\x03U\x04\x03\x0c\x16rcgen self signed cert0\"\x18\x0f19750101000000Z\x18\x0f40960101000000Z0!1\x1f0\x1d\x06\x03U\x04\x03\x0c\x16rcgen self signed cert0Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xf2w\x95\xc8\xc2\x8c\x0e\xc0\x0e\xd6\xe7>\x18l\t\x04b\x87\xdery\x0c\x1ch\x1e\x9d\x7f>\xd4\xefd\xc2\xeb\xc5\n;.\xa3\x89`\xd8\x84\x9cV\xc8\xb9\xe2\xc3\xfcm\xa2P\xf8t\x9e9Y\x9a\x01\x921\x19\xaba\xa3\x1b0\x190\x17\x06\x03U\x1d\x11\x04\x100\x0e\x82\x0cMaidSAFE.net0\n\x06\x08*\x86H\xce=\x04\x03\x02\x03H\00E\x02!\0\xad\xd2\xc8F\x81'\xde\x81N0\xf8\xc5]\x1fz\"\x82pe\xe7\xe4\xb8U\x12\x12\x1f\\\xf6\xa6p\x0fT\x02 \r\x92\x0f\x9c\xe0\xba\x9e-\x06\xec\x01\xbb\x11\x8b;\x01\x99j`\xe3B\x96\x83>\xcb7\xb7?x8\xef<", token: 0 }
[2020-01-16T10:25:49Z WARN bootstrap_node] Unexpected event: NewMessage { peer_addr: V4(116.203.42.154:443), msg: b"\x01\x02\x03" }
[2020-01-16T10:26:39Z WARN bootstrap_node] Unexpected event: ConnectionFailure { peer_addr: V4(116.203.42.154:443), err: ConnectionCancelled }
Command client side:
$ RUST_LOG=client_node=info target/debug/examples/client_node --hard-coded-contacts '[{"peer_addr":"116.203.42.154:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,91,52,55,9,205,180,86,71,19,143,185,160,85,128,200,145,32,1,139,236,126,147,238,150,201,247,156,78,134,85,191,203,66,165,82,182,107,66,35,48,112,31,63,34,148,197,249,199,128,74,218,3,22,108,163,38,76,61,42,103,252,122,145,196,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,39,74,203,148,153,231,248,148,140,39,99,190,215,247,208,104,227,213,216,96,60,226,192,3,79,173,226,123,165,20,112,211,2,33,0,215,21,57,239,21,254,177,166,30,28,24,60,175,183,77,126,147,127,98,121,105,57,175,52,126,210,63,230,189,76,66,37]}]'
CliArgs { quic_p2p_opts: Config { hard_coded_contacts: {NodeInfo { peer_addr: V4(116.203.42.154:5483), peer_cert_der: [48, 130, 1, 79, 48, 129, 246, 160, 3, 2, 1, 2, 2, 1, 42, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 34, 24, 15, 49, 57, 55, 53, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 24, 15, 52, 48, 57, 54, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 89, 48, 19, 6, 7, 42, 134, 72, 206, 61, 2, 1, 6, 8, 42, 134, 72, 206, 61, 3, 1, 7, 3, 66, 0, 4, 91, 52, 55, 9, 205, 180, 86, 71, 19, 143, 185, 160, 85, 128, 200, 145, 32, 1, 139, 236, 126, 147, 238, 150, 201, 247, 156, 78, 134, 85, 191, 203, 66, 165, 82, 182, 107, 66, 35, 48, 112, 31, 63, 34, 148, 197, 249, 199, 128, 74, 218, 3, 22, 108, 163, 38, 76, 61, 42, 103, 252, 122, 145, 196, 163, 27, 48, 25, 48, 23, 6, 3, 85, 29, 17, 4, 16, 48, 14, 130, 12, 77, 97, 105, 100, 83, 65, 70, 69, 46, 110, 101, 116, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 3, 72, 0, 48, 69, 2, 32, 39, 74, 203, 148, 153, 231, 248, 148, 140, 39, 99, 190, 215, 247, 208, 104, 227, 213, 216, 96, 60, 226, 192, 3, 79, 173, 226, 123, 165, 20, 112, 211, 2, 33, 0, 215, 21, 57, 239, 21, 254, 177, 166, 30, 28, 24, 60, 175, 183, 77, 126, 147, 127, 98, 121, 105, 57, 175, 52, 126, 210, 63, 230, 189, 76, 66, 37] }}, port: None, ip: None, max_msg_size_allowed: None, idle_timeout_msec: None, keep_alive_interval_msec: None, our_complete_cert: None, bootstrap_cache_dir: None, our_type: Node } }
[2020-01-16T10:25:49Z INFO client_node] Peer started
[2020-01-16T10:25:49Z INFO client_node] Connected with: 116.203.42.154:5483
[2020-01-16T10:25:49Z INFO client_node] Connected to bootstrap node. Waiting for other node contacts...
[2020-01-16T10:25:49Z WARN client_node] Unexpected event: SentUserMessage { peer_addr: V4(116.203.42.154:5483), msg: b"\x01\x02\x03", token: 0 }
But using IP V6 is not OK:
Command server side:
$ RUST_LOG=bootstrap_node=info target/debug/examples/bootstrap_node --ip 2a01:4f8:1c1c:9ca9::1 --port 5483 --expected_conns 1
[2020-01-16T10:08:00Z INFO bootstrap_node] QuicP2p started on [2a01:4f8:1c1c:9ca9::1]:5483
Our connection info:
{"peer_addr":"[2a01:4f8:1c1c:9ca9::1]:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,168,14,159,37,80,240,21,161,192,247,190,83,160,186,190,150,88,205,200,119,158,27,39,20,206,200,61,242,161,164,18,12,209,241,227,7,196,151,66,182,88,243,157,64,253,72,135,78,199,201,204,16,60,169,120,57,48,141,114,1,171,73,205,93,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,87,222,18,184,16,88,216,243,242,37,214,89,92,211,2,88,24,221,168,28,147,43,137,170,45,53,129,159,18,221,224,202,2,33,0,244,10,245,169,45,170,26,97,66,133,58,99,5,53,200,49,133,150,102,26,223,32,57,147,99,26,198,218,10,194,160,148]}
Command client side:
$ RUST_LOG=client_node=info target/debug/examples/client_node --hard-coded-contacts '[{"peer_addr":"[2a01:4f8:1c1c:9ca9::1]:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,168,14,159,37,80,240,21,161,192,247,190,83,160,186,190,150,88,205,200,119,158,27,39,20,206,200,61,242,161,164,18,12,209,241,227,7,196,151,66,182,88,243,157,64,253,72,135,78,199,201,204,16,60,169,120,57,48,141,114,1,171,73,205,93,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,87,222,18,184,16,88,216,243,242,37,214,89,92,211,2,88,24,221,168,28,147,43,137,170,45,53,129,159,18,221,224,202,2,33,0,244,10,245,169,45,170,26,97,66,133,58,99,5,53,200,49,133,150,102,26,223,32,57,147,99,26,198,218,10,194,160,148]}]'
CliArgs { quic_p2p_opts: Config { hard_coded_contacts: {NodeInfo { peer_addr: V6([2a01:4f8:1c1c:9ca9::1]:5483), peer_cert_der: [48, 130, 1, 79, 48, 129, 246, 160, 3, 2, 1, 2, 2, 1, 42, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 34, 24, 15, 49, 57, 55, 53, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 24, 15, 52, 48, 57, 54, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 89, 48, 19, 6, 7, 42, 134, 72, 206, 61, 2, 1, 6, 8, 42, 134, 72, 206, 61, 3, 1, 7, 3, 66, 0, 4, 168, 14, 159, 37, 80, 240, 21, 161, 192, 247, 190, 83, 160, 186, 190, 150, 88, 205, 200, 119, 158, 27, 39, 20, 206, 200, 61, 242, 161, 164, 18, 12, 209, 241, 227, 7, 196, 151, 66, 182, 88, 243, 157, 64, 253, 72, 135, 78, 199, 201, 204, 16, 60, 169, 120, 57, 48, 141, 114, 1, 171, 73, 205, 93, 163, 27, 48, 25, 48, 23, 6, 3, 85, 29, 17, 4, 16, 48, 14, 130, 12, 77, 97, 105, 100, 83, 65, 70, 69, 46, 110, 101, 116, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 3, 72, 0, 48, 69, 2, 32, 87, 222, 18, 184, 16, 88, 216, 243, 242, 37, 214, 89, 92, 211, 2, 88, 24, 221, 168, 28, 147, 43, 137, 170, 45, 53, 129, 159, 18, 221, 224, 202, 2, 33, 0, 244, 10, 245, 169, 45, 170, 26, 97, 66, 133, 58, 99, 5, 53, 200, 49, 133, 150, 102, 26, 223, 32, 57, 147, 99, 26, 198, 218, 10, 194, 160, 148] }}, port: None, ip: None, max_msg_size_allowed: None, idle_timeout_msec: None, keep_alive_interval_msec: None, our_complete_cert: None, bootstrap_cache_dir: None, our_type: Node } }
Server is not reached and connection info is not sent back to client.
My UFW configuration allows 5483/udp for both IP V4 and IP V6:
$ ufw status | grep 5483
5483/udp ALLOW Anywhere
5483/udp (v6) ALLOW Anywhere (v6)
ansi_term is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | ansi_term |
Version | 0.12.1 |
URL | ogham/rust-ansi-term#72 |
Date | 2021-08-18 |
The maintainer has adviced this crate is deprecated and will not
receive any maintenance.
The crate does not seem to have much dependencies and may or may not be ok to use as-is.
Last release seems to have been three years ago.
The below list has not been vetted in any way and may or may not contain alternatives;
See advisory page for additional details.
The code has some TODOs and FIXMEs that can (or at-least needs to be analysed if they can) occur in some edge cases. Fix these
Hey,
I am now trying to setup multiple nodes with slightly different, non-default setups where I want to save the cert,...
When trying to use Config::read_or_construct_default I realized that I couldn't specify the Dirs as it is inside a private/pub(crate) module and isn't made public in lib.rs too.
Is this a bug or is there a different intended way to use this function?
Thanks in advance,
Chris
It probably needs to be sent to the event channel when the QuicP2P handle is being dropped.
See https://github.com/maidsafe/quic-p2p/pull/107/checks?check_run_id=677634467#step:8:533
Extract from logs
18: std::panic::catch_unwind
at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\src\libstd\panic.rs:394
19: test::run_test_in_process
at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\/src\libtest\lib.rs:542
20: test::run_test::run_test_inner::{{closure}}
at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\/src\libtest\lib.rs:451
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
tests::echo_service
test result: FAILED. 21 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out
error: test failed, to rerun pass '-p quic-p2p --lib'
##[error]The process 'C:\Rust\.cargo\bin\cargo.exe' failed with exit code 101
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.