Packets not recognized by Wireshark about quant HOT 15 CLOSED

Are you on the latest master version? Are you using the most recent wireshark nightly? Are you feeding the TLS log into wireshark (default location /tmp/quant-tlslog)?

from quant.

Versions:
QUANT - ccf9ecd (with submodules up-to-date)
Wireshark - Version 3.0.2 (Git commit 621ed351d5c9)
TLS log set correctly. Please note that in case TLS log is absent, Wireshark would still able to recognize QUIC packets.

from quant.

Maybe try and go back to 9afd822? I can't look into this much for the next two weeks, sorry

from quant.

Also, please try a newer wireshark - the 3.1.0 series is the current nightly: https://www.wireshark.org/download/automated/osx/

from quant.

@amitgeron You may want to use Wireshark version commit 5e79558a8243c046ce3f279c635f9670be7f8f05 or newer.

You can either git clone https://code.wireshark.org/review/wireshark or download from here https://www.wireshark.org/download/automated/src/

from quant.

Same result with 3.1.0rc0-1058-g142e024e1f02 (Git commit 6183dc441c38)

I don't think this is a Wireshark issue, since with other implementations of QUIC I don't experience this issue.

from quant.

Would you try going back to the commit before I shortened the exporter labels? I just made that change due to what @Lekensteyn

from quant.

Wrote in #12 but didn’t test it fully

from quant.

Tested with commit 9afd822, and after forcing Wireshark to decode the packets as QUIC, I get no errors.

from quant.

Thanks for confirming this. I guess it’s an issue with the shortened labels then, either in quant or in wireshark (cc @Lekensteyn @alagoutte)

from quant.

Key logging works for me.

sudo tcpdump -i lo -p -w quant.pcap &
bin/server &
bin/client http://localhost:4433 -l quant.keys
editcap --inject-secrets tls,quant.keys quant.pcap quant-dsb.pcapng
wireshark -r quant-dsb.pcapng -dudp.port==4433,quic

Capture file with embedded keys (ZIP due to Github limitations): quant-dsb.pcapng.zip

With Wireshark v3.1.0rc0-1099-g2d96da9b7f (git master), everything can be decrypted, except for 0-RTT data (need to check why). Edit: 0-RTT decryption was not yet implemented in Wireshark, proposed patch: https://code.wireshark.org/review/33695

The version field is reported as "0x45474714" instead of the official draft version 0xff000014 (draft-20). That is likely the reason why Wireshark heuristics refuses to interpret it, requiring a manual Decode As action.

quant was built on Arch Linux with:

sudo pacman -S git cmake ninja libbsd http-parser libev
git clone --depth=100 https://github.com/NTAP/quant /tmp/quant
mkdir /tmp/build && cd /tmp/build
cmake -GNinja /tmp/quant -DCMAKE_BUILD_TYPE=Debug
ninja

Environment:

• gcc 9.1.0-1
• http-parser 2.9.2-1
• openssl 1.1.1.c-1
• libev 4.25-1
• cmake 3.14.5-1
• Sources:
  • e6082f6ac8
  • attractivechaos/klib@f719aad5fa
  • NTAP/warpcore@184cc0458f
  • h2o/picotest@f390562fd4
  • h2o/picotls@27f31ba0a8
  • private-octopus/picoquic@9d43127b33
  • https://git.lighttpd.net/libev 31ca40b7a1
  • attractivechaos/klib@f719aad5fa

If you still run into problems, can you share a pcapng file with embedded secrets as described above? A separate pcap + key log file would also work.

from quant.

Thanks!
I can confirm that all looks good now. I built latest Wireshark (3.1.0rc0-1121-gec10752adb78), which already includes the patch that you mentioned.

from quant.

Thanks all for confirming things; I’m closing this now

from quant.

@larseggert you actually reopened it 😄

from quant.

Man this CodeHub app is not great

from quant.