Hi Valdik
I looked through your file but did not see your DCID=f00edb746f767f8a, nor DCID=f10edb746f767f8a and no udp.stream eq 42. Only a total of 32 udp streams are in the file.
If you filtered the file, the udp streams are renumbered.
Injecting the TLS secret into the file would be helpful.
Best regards
Rolf Leutert
Leutert NetServices
www.netsniffing.ch
-----Ursprüngliche Nachricht-----
Von: ValdikSS via Wireshark-users <wireshark-users@xxxxxxxxxxxxx>
Gesendet: Mittwoch, 24. Juli 2024 22:21
An: wireshark-users@xxxxxxxxxxxxx
Cc: ValdikSS <iam@xxxxxxxxxxxxxxx>
Betreff: [Wireshark-users] QUIC in Chrome on YouTube not dissected
Hello list,
I'm seeing undissected QUIC data while watching YouTube in the latest Chrome version 126, using Wireshark 4.2.6 (also tried git master).
First goes regular QUIC session which is detected, dissected and decrypted by Wireshark, but after some time "unknown" UDP traffic follows to the same destination IP and also port 443 UDP, but from another source port.
The previous connection has DCID=f00edb746f767f8a, and the first packet of new connection begins with "xx f1 0e db 74 6f 76 7f 8a", f0 -> f1, which definitely looks like QUIC.
I thought this may be some kind of 0-RTT connection with third-party key exchange (as in DNS SVCB/HTTPS), but I don't see any DNS queries other than A/AAAA.
I guess this is "connection migration" on the same network.
The same issue happens with full QUIC traffic decryption (SSLKEYLOGFILE). No such behavior in Firefox.
Anyone has any information, any ideas?
PCAP (126 MB):
https://valdikss.org.ru/chrome-youtube-quic-not-dissected.pcapng.gz
Check udp.stream eq 42