a call to `connect` hangs and peerd logs "invalid nodeid" about lnp-node HOT 10 CLOSED

The possible problem is that you are running both LNP node peers on the same CTL interface, so CLI sends it message to the one you are starting first: listening peer daemon. And it tries to connect to itself and fails. The solution is to provide one of two lnpd with a different data dir -d /tmp for instance. Can you pls show how you set up two nodes?

from lnp-node.

The setup is the same I proposed in the written version of the demo alpha.4, and it worked. And I experience the issue both in local and in docker setup.
In the local setup the two nodes have different data dirs, in docker they are inside different containers.

Yesterday i built binaries in debug mode and I saw a TRACE-level log that might help:

[2020-11-18T17:58:37Z TRACE lnp::lnpd::runtime] Executing `"/home/step/lnpbp/lnp-node/target/debug/peerd" "-vvvv" "-d" "data1" "--connect" "{_0}"`

while on the cli side I see:

Executing ConnectPeer(Remote(RemoteNodeAddr { node_id: PublicKey(af1d6e63da37c8686656f6e0b41ffacef19f693111110da21fbc9e871fc6408bfbadb528efe7b6604c46d00d9588c6b31f957fcaa7abaa4213a9725a572ed514), remote_addr: Ftcp(InetSocketAddr { address: IPv4(127.0.0.1), port: 9735 }) }))

Both logs print the variable with "{:?}". Maybe some formatting issue passing the NodeLocator through?

from lnp-node.

I tried out something more to collect some more debugging info:
A is lnp-node:0.1.0-beta.1
B is lnp-node:0.1.0-alpha.4

• A is set to listen mode
• B connects to A
• connection is successful
• A has "{_0}" in the list of peers shown by lnp-cli info, like:

---
node_id: 033888c79b3336ae0d562ac71457aca86db032da97110822be9b685d944343bb1b
listens:
  - Ftcp:
      address:
        IPv4: 0.0.0.0
      port: 9735
uptime: 879
since: 1605805844
peers:
  - "{_0}"
channels: []

It looks even more like a formatting issue

from lnp-node.

O, strange... Can you pls grep for {_0}, and then check git blame comparing to the version that was working?

from lnp-node.

A git grep "{_0}" gives no matches.

I have no clue why, but the issue seems to be solved now on git tag v0.1.0-beta.1 (160b4b1), while I still get the same problem in the version installed from crates.io. Since I now have a working version to play with, I can also close the issue and we'll see if this problem shows up again.

from lnp-node.

Very strange. The version published to the crates is the same as the tag...

from lnp-node.

I tried a number different settings while keeping my testcase as uniform as possible and these are the results I got:

• cargo build: git checkout v0.1.0-beta.1 && cargo build --release --all-features -> lnp-cli connect works
• cargo install from source: git checkout v0.1.0-beta.1 && cargo install --path . --locked --all-features -> lnp-cli connect works
• cargo install via git: cargo install --git https://github.com/LNP-BP/lnp-node#0.1.0-beta.1 --locked --all-features -> lnp-cli connect works
• cargo install via crates: cargo install lnp_node --locked --version 0.1.0-beta.1 --all-features -> lnp-cli connect returns error: Invalid value for '<peer>': Invalid public key data representing node id

So as a workaround it is also possible to use cargo install --git.

from lnp-node.

It could be that cargo is not building all binaries or you are using some previous build of one of them. I had similar issues in such cases

from lnp-node.

Nope, it happens in clean docker containers as well, no way I could be using old binaries there.

from lnp-node.

Since the opening of the issue we nearly have a complete re-write of the node and on the new version connect is working; so closing this for now

from lnp-node.