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
Crash with ipv6 #9
Comments
Not sure if that is IPv6 specific. |
same test, same platform, over ipv4, does work, but yes, could be something else. |
Perhaps a firewall preventing IPv6 UDP connectivity? |
no firewall in play here. |
@richb-hanover - you using ipv6? |
My configuration works fine for IPv4. I can make a crash happen when I use IPv6...
Test connectivity using address found from
Server log
Client log
|
Tested with v0.0.10-testing and it seems to work fine with IPv6 (public IPv6 or local IPv6) Server: Ubuntu 22.04 Proxmox PVE 8.0 LxC container (Intel N100 mini PC connected to RT-AX86U 2.5G LAN port)
|
I re-ran my experiment at #9 (comment) ensuring that both server and client were the current commit - a89abd2. It ran successfully without an error/crash. I think this issue can be closed. |
Hmm, my previous test was done using local network test. Today I am trying to test over the internet and it has the same problem now. IPv4 passed. IPv6 failed. ping and iperf3 over IPv6 are okay. crusader v0.0.10-testing Server: OpenWRT 23.05 Proxmox PVE 8.0 virtual router (Intel N100 mini PC) -- this is on network 1 (one public IPv4 address and /56 IPv6) Client: Windows 11 x84 using wireless (Acer Windows 11 laptop with Intel AX201 WiFi 6 adapter), using wireless connection through Asus RT-AX86U -- this is on network 2 (another public IPv4 address, another /56 IPv6)
|
Just wondering if you can test over the internet to see if you can reproduce the issue or not. Thanks. |
Two thoughts:
|
@mcuee Was both UDP and TCP forwarded? There seems to be some problem with IPv6 UDP here. |
In this paticular case, I am running crusader directly under OpenWRT router. Therefore I am not using port forwarding, but rather using Firewall -- Traffic Rules. |
If you feel like investigating you could try to run Wireguard and see which directions send or receives UDP traffic. |
You mean to say Wireshark, right? I will need to learn Wireshark first. Haha. I will see what I can do. |
Yeah I meant Wireshark =P |
Simple things first -- to use the debug version and get the trace.
|
I am using a Proxmox PVE 8.0 LxC container as the client this time. crusader v0.0.10-testing Here is the output from tcpdump. Hopefully it will give some hints about the potential issue. More detailed tcpdump output using |
Just wondering if you can test over the internet again to see if the issue exists on your side or not. Thanks. |
My setup is a bit strange that the two home networks are actually sharing the same upstream ONT and a smart switch. This is the reason I can only test either download or upload but not both. ISP ONT -- TP-Link TL-SG105E smart switch --> two networks |
oot@lqos:~# crusader test --stream-stagger 5 --streams 2 --load-duration 10 fd77::2
Connected to server [fd77::2]:35481
thread 'main' panicked at 'called
Result::unwrap()
on anErr
value: "Unable to measure latency to server"', crusader-lib/src/test.rs:1304:10stack backtrace:
0: 0x7fdf8f501ddd -
1: 0x7fdf8f53bc0c -
2: 0x7fdf8f4fc771 -
3: 0x7fdf8f503335 -
4: 0x7fdf8f503056 -
5: 0x7fdf8f5038c6 -
6: 0x7fdf8f5037b7 -
7: 0x7fdf8f502294 -
8: 0x7fdf8f5034e9 -
9: 0x7fdf8f388103 -
10: 0x7fdf8f3881f3 -
11: 0x7fdf8f3e6c8a -
12: 0x7fdf8f38e850 -
13: 0x7fdf8f392c63 -
Aborted (core dumped)
The text was updated successfully, but these errors were encountered: