AttributeError: No attribute named gquic

[t3chn0m4g3]

With quic enabled I am getting the following error, strangely it only happens within a VM environment, not on a physical device:

Traceback (most recent call last):
  File "fatt.py", line 974, in <module>
    main()
  File "fatt.py", line 968, in main
    cap.apply_on_packets(pp.process)
  File "/usr/lib/python3.8/site-packages/pyshark/capture/capture.py", line 248, in apply_on_packets
    return self.eventloop.run_until_complete(coro)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/usr/lib/python3.8/site-packages/pyshark/capture/capture.py", line 259, in packets_from_tshark
    await self._go_through_packets_from_fd(tshark_process.stdout, packet_callback, packet_count=packet_count)
  File "/usr/lib/python3.8/site-packages/pyshark/capture/capture.py", line 285, in _go_through_packets_from_fd
    packet_callback(packet)
  File "fatt.py", line 283, in process
    if 'tag' in packet.gquic.field_names:
  File "/usr/lib/python3.8/site-packages/pyshark/packet/packet.py", line 117, in __getattr__
    raise AttributeError("No attribute named %s" % item)
AttributeError: No attribute named gquic

The following log entry is associated with the error:

{"timestamp": "2021-05-30T13:42:14.236588", "sourceIp": "1.2.3.4", "destinationIp": "172.20.254.143", "sourcePort": "443", "destinationPort": "34076", "protocol": "tls", "tls": {"ja3s": "ad79b260268c688aca351dae7229c877", "ja3sAlgorithms": "771,49200,65281-11-23-16", "ja3sVersion": "771", "ja3sCiphers": "49200", "ja3sExtensions": "65281-11-23-16"}}

Please let me know if I can be of further assistance.

[kauedg]

I've been trying to track the removal of the 'tag' attribute and found this:

Field name	Description	Type	Versions
quic.tag	Tag	Character string	2.0.0 to 2.4.16

Source: [Display Filter Reference: QUIC IETF](https://www.wireshark.org/docs/dfref/q/quic.html)

So, what happened on 2.4.16 next release (which is 2.6.0)?

The QUIC dissector has been renamed to Google QUIC (quic → gquic)

and

New Protocol Support
[...], QUIC (IETF), [...]
Souce: Wireshark 2.6.0 Release Notes

So there was a protocol named QUIC that became GQUIC so that the standardized QUIC IEFT could be developed. Then we have this line in fatt.py:

elif (proto == 'GQUIC' or proto == 'QUIC') and\

which I believe is mistaking two different protocols, as QUIC IETF doesn't have the "tag" attribute anymore. I'm saying this based on this message:

IETF QUIC version 1 doesn't use the Google QUIC CHLO tag, it instead uses TLS 1.3 ClientHello format.
You can parse this message by following the specifications in RFC 9000, 9001 and 8446.
Source: QUIC Parser without CHLO tag

So Fatt's code should reflect this difference, parsing QUIC IETF and GQUIC in different ways.