search

private-octopus / picoquic

Minimal implementation of the QUIC protocol
MIT License
562 stars 165 forks source link

Wireshark packet traces detect UDP packets on alternate path and not QUIC #1748

Closed SupradhaBhat closed 1 month ago

SupradhaBhat commented 2 months ago

We tried using the picoquic library with the following network namespace Screenshot 2024-09-08 191708 When capturing packets via Wireshark on link 1 (the primary interface), we observe QUIC packets as expected. However, on link 2 (the alternate path), only UDP packets are captured—no QUIC packets appear in the trace. Is this the expected behavior, or should we be seeing QUIC packets on link 2 as well?

huitema commented 2 months ago

It is very hard to tell without having more information. The packets on link 1 will include the QUIC handshake, which wireshark can recognize easily -- the handshake uses packets with long headers. The packets on link 2 will only include packets of type 1RTT, with a short header. It is possible that wireshark does not recognize them as QUIC packets. That would be an issue with wireshark.

Also, picoquic does not provide wireshark with decryption keys by default -- that would be too much of a security hole, because anyone with machine access could grab these keys. To pass the keys, you have to set the option "-8" in the demo program.

For further debug, you may want to enable qlog capture on client and server. That would help understand whether the issue is with wireshark or with picoquic.

hfstco commented 2 months ago

Wireshark struggles to recognise QUIC frames if they aren't decrypted, if there is no precending handshake. After injecting the TLS secrets everything works fine. Just export the TLS secrets, like @huitema explained above, and you should be fine.

Results were captured on remote side. IMG_0033

multipath.zip

https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-quic.c If I understand the Wireshark code correctly, it only checks whether MP has been negotiated in the transport parameters. Then it looks for MP/QUIC frames, which, as you can see in the pcap without TLS secrets injected, are not visible. But I only briefly flew over the code and recognition of QUIC packets should be not that hard, after decrypting them.

Edit: Put the wrong injected .pcap file into the .zip.

SupradhaBhat commented 1 month ago

I tried adding -8 flag, yet, the Wireshark capture shows UDP on one interface and QUIC on the other. We also tried capturing packets using tcpdump, but we observed that packets captured on both interfaces are UDP. Following is a screenshot of the qlogs captured on the client side WhatsApp Image 2024-09-27 at 18 29 29_e7b420c8

huitema commented 1 month ago

The wireshark issue is an issue with wireshark. You should file that with wireshark. Or maybe there is already an issue filed there. @alagoutte and/or @IvanNardi might be able to help you.

huitema commented 1 month ago

The qlog appears nominal, showing traffic flowing on both paths.

IvanNardi commented 1 month ago

The wireshark issue is an issue with wireshark. You should file that with wireshark. Or maybe there is already an issue filed there. @alagoutte and/or @IvanNardi might be able to help you.

@SupradhaBhat, could you open a ticket in Wireshark repository attaching pcap AND keylog files, please?

(BTW, without keys there is no way for Wireshark to properly identify the traffic on second interface a s QUIC, as clearly stated from @hfstco)