Add leanp2p transport interop tests

[bismuth01]

The leanp2p transport scripts as well as the docker container have been merged in the official leanp2p repository and the image has been added to transport/images.yml.

[dhuseby]

🧐

  → [5/35] leanp2p x rust-v0.56 (quic-v1)...[FAILED]
  → [4/35] leanp2p x rust-v0.55 (quic-v1)...[FAILED]
  → [2/35] leanp2p x rust-v0.53 (quic-v1)...[FAILED]
  → [3/35] leanp2p x rust-v0.54 (quic-v1)...[FAILED]
  → [17/35] leanp2p x zig-v0.0.1 (quic-v1)...[FAILED]
  → [34/35] zig-v0.0.1 x leanp2p (quic-v1)...[FAILED]

I'm not concerned about the zig-v0.0.1 failures. I think we're likely to add that to the ~failing alias soon since it isn't being maintained. I'll have to ask Marco about that. I think the preferred Zig implementation is eth-p2p-z which passed:

→ [18/35] leanp2p x eth-p2p-z-v0.0.1 (quic-v1)...[SUCCESS]
→ [35/35] eth-p2p-z-v0.0.1 x leanp2p (quic-v1)...[SUCCESS]

However, I am concerned about the rust-libp2p failures. Notice that it is only one way (i.e. leanp2p dialing rust and not the other way around).

Let me run this locally with debug output enabled to see if we can deduce what's going on.

[dhuseby]

I was able to recreate the failures locally and it looks like there's a ping protocol error happening when leanp2p dials rust-libp2p:

leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Redis key: 00077d1b_listener_multiaddr
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Retrieved listener address from redis: /ip4/10.16.0.3/udp/58754/quic-v1/p2p/12D3KooWLcgsFKCoenstDrHQpptweMmX1KUj3jLNETQKZ1h6SzCu
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Connecting to /ip4/10.16.0.3/udp/58754/quic-v1/p2p/12D3KooWLcgsFKCoenstDrHQpptweMmX1KUj3jLNETQKZ1h6SzCu
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Connected successfully
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Fatal Ping error: STREAM_CLOSED

[bismuth01]

I was able to recreate the failures locally and it looks like there's a ping protocol error happening when leanp2p dials rust-libp2p:

leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Redis key: 00077d1b_listener_multiaddr
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Retrieved listener address from redis: /ip4/10.16.0.3/udp/58754/quic-v1/p2p/12D3KooWLcgsFKCoenstDrHQpptweMmX1KUj3jLNETQKZ1h6SzCu
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Connecting to /ip4/10.16.0.3/udp/58754/quic-v1/p2p/12D3KooWLcgsFKCoenstDrHQpptweMmX1KUj3jLNETQKZ1h6SzCu
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Info Connected successfully
leanp2p_x_rust-v0_56__quic-v1__dialer  | 26.02.23 19:43:04 Fatal Ping error: STREAM_CLOSED

Yes, I had already seen this happen when testing the integration with test-plans. I have reviewed the code thoroughly and my debug runs showed that the rust listener did not return back a ping value in the non-refactored code.

Essentially it was failing at
https://github.com/bismuth01/leanp2p/blob/c026347b07bc5a1e64293d3523135b576e7f8316/test-plans/ping/ping.cpp#L251-L257
which resolved to true and threw the error.

[dhuseby]

@bismuth01 hrm...that's interesting. I wonder where the bug lies. It's definitely an upstream bug, but whether it is in leanp2p or rust-libp2p remains to be seen. Do you know how to debug this? Do you need help debugging the rust-libp2p implementation?

[bismuth01]

Let me try debugging it solo, I will ask for help if needed.

[dhuseby]

any progress?

[bismuth01]

Nope.
What I have tried on the leanp2p script : -

• Adding abort on Fatal logging to check for early exits
• Manually check for missing values
• Any methods for force stop io_context which might lead to stream closing
• Overview of BasicHost, Stream and Quic classes
• Compare script logic on connection establishment (Connection creation -> Upgrading to QUIC transport )

The best guess that I currently have is that Rust is closing the stream after host connection and the programs crash on negotiating an upgrade to quic.

Also, the leanp2p x rust-v0.56 fails. But rust-v0.56 x leanp2p fails too as it faces a connection upgrade issue but rust still returns a successful run yaml, which can be checked in the test run logs in debug mode.

[2026-03-19 19:37:49] INFO: Starting test: rust-v0.56 x leanp2p (quic-v1)
[2026-03-19 19:37:50] INFO: [3] rust-v0.56 x leanp2p (quic-v1) (key: ce132062)
[2026-03-19 19:37:50] DEBUG:   Starting containers...
[2026-03-19 19:37:50] INFO: Running: rust-v0.56 x leanp2p (quic-v1)
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Creating
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Created
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Creating
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Created
Attaching to rust-v0_56_x_leanp2p__quic-v1__dialer, rust-v0_56_x_leanp2p__quic-v1__listener
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.264807�[0m  �[1m�[38;2;034;139;034mInfo    �[0m  �[1mPing�[0m  Found network interface eth0 with IP 10.16.0.5�[0m
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.264914�[0m  �[1m�[38;2;034;139;034mInfo    �[0m  �[1mPing�[0m  Using detected network IP: 10.16.0.5�[0m
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.264919�[0m  �[1m�[38;2;034;139;034mInfo    �[0m  �[1mPing�[0m  Redis key: ce132062_listener_multiaddr�[0m
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.275640�[0m  �[1m�[38;2;034;139;034mInfo    �[0m  �[1mPing�[0m  Pushing connect address /ip4/10.16.0.5/udp/11789/quic-v1/p2p/12D3KooWAPAjzbGxDSe7EKFWWpWQcUAyVUes7e5kFSz8S5T8g1Nq�[0m
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.275900�[0m  �[1m�[38;2;034;139;034mInfo    �[0m  �[1mPing�[0m  Listener address pushed to redis�[0m
rust-v0_56_x_leanp2p__quic-v1__listener  | 26.03.19 14:07:51�[38;2;128;128;128m.518102�[0m  �[1m�[38;2;255;165;000mWarning �[0m  �[1mListenerManager�[0m  can not negotiate protocols, STREAM_CLOSED�[0m
rust-v0_56_x_leanp2p__quic-v1__dialer    | latency:
rust-v0_56_x_leanp2p__quic-v1__dialer    |   handshake_plus_one_rtt: 7.849
rust-v0_56_x_leanp2p__quic-v1__dialer    |   ping_rtt: 0.449
rust-v0_56_x_leanp2p__quic-v1__dialer    |   unit: ms

�[Krust-v0_56_x_leanp2p__quic-v1__dialer exited with code 0
Aborting on container exit...
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Stopping
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Stopped
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Stopping
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Stopped
[2026-03-19 19:37:52] INFO:   ✓ Test complete
[2026-03-19 19:37:52] DEBUG:   Cleaning up containers...
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Stopping
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Stopped
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Removing
 Container rust-v0_56_x_leanp2p__quic-v1__dialer  Removed
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Stopping
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Stopped
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Removing
 Container rust-v0_56_x_leanp2p__quic-v1__listener  Removed

I have tried debugging the rust-libp2p side, but they use a trace logger so I can't find exact function points where they give out a particular log. If possible, I would like some help on the rust side.

tracing::debug!("{event:?}")

Another thing I noticed is for leanp2p dialer, the output is not being parsed properly, that could be a result to due to the new macros placed in the script, but I will have to dig deeper.

[bismuth01]

An update on the issue, after more digging and comparing logs from other tests and implementations, it seems that leanp2p tends to close stream earlier than expected when acting as listener. This comes up after the peer has connected and protocol negotiation fails as leanp2p closes stream.
Might be the script issue as the simple ping applications work well together.

But what's more interesting is other tests report a success even though leanp2p listener fails protocol negotiations and never reaches ping protocol usage. I guess something can be done there.

[bismuth01]

The fix was implemented to the leanp2p transport script in this PR and tested with

./run.sh --impl-ignore "~failing" --transport-select "quic-v1"

All 25 tests passed. Every single one with leanp2p listener passed and the ones with leanp2p dialer sucessfully outputted results that was parsed by the framework.