sn_cli: 0.19.0
sn_node: 0.26.16
sn_launch: 0.0.16
error
$ ~/.safe/sn_launch_tool --ip 2001:983:8610:1:854:efb1:52e6:85a
Using RUST_LOG 'sn_node=debug'
error: Found argument '--ip' which wasn't expected, or isn't valid in this context
USAGE:
sn_node --idle-timeout-msec <idle-timeout-msec> --keep-alive-interval-msec <keep-alive-interval-msec> --verbose
For more information try --help
Think it has to do with this commit in qp2p. Basically, it changed some args to support manual port forwarding (I think before we only supported UPnP port forwarding).
There’s two fixes (I don’t know if they’re being worked on right now). One is sorta the “real” fix and the other just “gets it to work”.
The real fix would be to propogate the changes to sn_node first, allowing manual port forwarding, then propogate those changes to sn_launch_tool in turn. Alternatively, we can change it only in sn_launch_tool for now and the behavior stays the same and we opt not support manual port forwarding until a later date in sn_node or sn_launch_tool.
The latter might be desirable, because some of the comments on the config_handler.rs file in sn_node seem to indicate that MaidSafe is aiming at refactoring that whole file anyway. It uses a bit of a weird parse scheme that doesn’t take full advantage of structopt.
As I mentioned though, I don’t even know if somebody is taking care of this already and if this is a temporary blockage. Maybe @lionel.faber (who authored the qp2p change) or @bochaco (who seems to be the codeowner of sn_launch_tool) knows what the plan/timeline is for propagating those qp2p changes to sn_node or sn_launch_tool. Alternatively, maybe this just slipped through the cracks, in which case I could author a change myself if nobody is working on it, it doesn’t seem like a massive effort.
Yes that’s due to recent changes to qp2p which impacts sn_node args, so as you describe it needs the launch-tool to now pass either --local-ip or --external-ip rather than the old --ip arg to sn_node, @lionel.faber could you please advise us here how to change launch tool to match new node args?
The fastest way to get this going would be to just replace --ip with --local-ip. (Without manual port forwarding)
To support manual port forwarding, the launch tool can have both --local-ip and --external-ip along with --local-port and --external-port which can then be passed to sn_node.
I created a PR with such change: fix(ip): changes to support latest version of sn_node which renamed -… by bochaco · Pull Request #54 · maidsafe/sn_launch_tool · GitHub, it needs to be tested though.
PR is merged now but I am not sure of what is supposed to replace previous --ip flag. I tried --local-ip and then --external-ip, and in both cases the genesis node (with --first flag) doesn’t start. I get error Routing(Network(IgdNotSupported)).
How can we use a straight global interface without port forwarding, IGD, upnp, …?
Think @folaht has a similar thread going. Don’t know the cause, but might be an issue with IpV6.
My take on it is, for what it’s worth, is the following:
--local-ip with is what you would use to get behavior close to the old behavior. If you’re not on LAN/localhost, you can optionally provide --external-ip for manual forwarding or --forward-port for automatic. --external-ip will override --forward-port in the case of both. In the case of neither, we fall back on the echo service using our bootstrap nodes.
You can also use --local-ip but you must supply --external-ip if port-forwarding via --forward-port is not available (which it is not for IPv6 afaik, hence your error) or disabled.
In your case, I think your only option is that --external-ip also needs to be specified. I don’t have mine up in front of me though, so somebody correct me if I’m wrong, but I’ll put the docs below.
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
#[structopt(short, long)]
pub local_port: Option<u16>,
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.
#[structopt(short, long)]
pub local_ip: Option<IpAddr>,
forward-port
/// Specify if port forwarding via UPnP should be done or not. This can be set to false if the network
/// is run locally on the network loopback or on a local area network.
#[structopt(long)]
pub forward_port: bool,
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.
#[structopt(short, long)]
pub external_port: Option<u16>,
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.
#[structopt(short, long)]
pub external_ip: Option<IpAddr>,
No, the problem is the same in IPv4 and IPv6.
Can you paste the command you’re running exactly & what binary versions are you using? Is the implication that you’re running the same command as the OP just replacing --ip with --local-ip? Might help illuminate any sticking points.
Just based on a search through the source code, if your log level is debug, you should theoretically also get some info level logs with some extra information/messaging when the error is thrown (each place the error is thrown in code, it’s accompanied in source by an info! log, so the program should at least be attempting to log this event).
sn_node 0.28.0 which has been current version for 4 days, built from source.
In an alpine container on a docker bridged network:
--external-ip:~ # sn_node -m 2000000000 --external-ip 172.20.0.2 --clear-data --external-port 5483 --first -vvv
[sn_node] INFO 2021-03-01T14:15:07.632772500+00:00 [src/bin/sn_node.rs:89] Node PID is: 33
[sn_node] INFO 2021-03-01T14:15:07.679007800+00:00 [src/bin/sn_node.rs:112]
Running sn_node v0.28.0
=======================
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR 2021-03-01T14:15:17.997360100+00:00 [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))
--local-ip:~ # sn_node -m 2000000000 --local-ip 172.20.0.2 --clear-data --local-port 5483 --first -vvv
[sn_node] INFO 2021-03-01T14:15:52.566579300+00:00 [src/bin/sn_node.rs:89] Node PID is: 44
[sn_node] INFO 2021-03-01T14:15:52.594822900+00:00 [src/bin/sn_node.rs:112]
Running sn_node v0.28.0
=======================
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR 2021-03-01T14:16:02.790902400+00:00 [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))
--external-ip:~ # sn_node -m 2000000000 --external-ip fd2f:9ab3:8b80:69fa::2 --clear-data --external-port 5483 --first -vvv
[sn_node] INFO 2021-03-01T14:16:43.871174900+00:00 [src/bin/sn_node.rs:89] Node PID is: 55
[sn_node] INFO 2021-03-01T14:16:43.902869100+00:00 [src/bin/sn_node.rs:112]
Running sn_node v0.28.0
=======================
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR 2021-03-01T14:16:54.116821900+00:00 [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))
--local-ip:~ # sn_node -m 2000000000 --local-ip fd2f:9ab3:8b80:69fa::2 --clear-data --local-port 5483 --first -vvv
[sn_node] INFO 2021-03-01T14:17:21.843447800+00:00 [src/bin/sn_node.rs:89] Node PID is: 66
[sn_node] INFO 2021-03-01T14:17:21.873755100+00:00 [src/bin/sn_node.rs:112]
Running sn_node v0.28.0
=======================
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR 2021-03-01T14:17:32.091735300+00:00 [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))
This was working previously when sn_node had --ip and --port options.
Seems like something isn’t being written to stdout, try manually setting export RUST_LOG="debug" in your terminal before running it. Anyway, I think I was able to repro this though, so see if you get something similar (I got this for --local-ip with IPv4 address btw, but it won’t matter as you’ve noticed also, for reasons I’ll theorize in a moment):
[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))
If that’s the case, seems like the igd lib is failing (specifically at this line of code in qp2p) and not necessarily maidsafe libs. I don’t have time right now, but I can try increasing my timeout, playing with search options, etc. later and recompiling to see what happens.
Maybe needs another flag to be passed to configure sn_node, maybe router settings, maybe a bug in IGD. But in this case you’re right that it’s not the IPv4/IPv6 issue (assuming we’re getting the same error here).
To get around this for now, you can manually setup port forwarding on your router and provide both --local-ip and --external-ip and it will skip the IGD code branch altogether.
This topic was automatically closed after 60 days. New replies are no longer allowed.