I've seen that the answer is the port (80 or 443 is labeled as quic and not UDP). I'm trying to find in the open source of wireshark where does it actually label a packet that way and couldn't find it.
Let me rephrase my question: When wireshark receives a packet it needs to decide which dissector to call (Quic or UDP in this case). Where in the code it decides if the packet is UDP or Quic? (by searching online I found that it depends on the port if it's 80 or 443 then it is labeled as Quic)
That usually depends on your config. UDP is generic. Quic is more specific. If you disable that dissector in your config then it will be UDP as the more specific dissector is ignored.
Wireshark dissectors are chained together, so the link layer info in the capture indicates which dissector to call first, e.g. Ethernet, the type field in the Ethernet header indicates IP so it calls the IP dissector, in the IP header the protocol field indicates UDP so it calls the UDP dissector, that dissector uses registered ports and\or heuristics to determine the protocol being carried and then calls the QUIC dissector.
If any dissector does determine (via initial checks) that the data is for that protocol, then it usually sets the protocol column with its info. Each subsequent dissector overwrites whatever was previously in the column.
Thank you for your answer :) I am still having trouble locating the code which is responsible for the classification of UDP or Quic, I've tried looking in the udp dissector but with no luck. I only need to find where in the code the dissector uses the ports and\or heuristics to decide it needs to call QUIC dissector.
A dissector registers with transport dissectors in a function named proto_reg_handoff_<protoname> and that for the QUIC dissector is shown below:
void
proto_reg_handoff_quic(void)
{
tls13_handshake_handle = find_dissector("tls13-handshake");
dissector_add_uint_with_preference("udp.port", 0, quic_handle);
heur_dissector_add("udp", dissect_quic_heur, "QUIC", "quic", proto_quic, HEURISTIC_ENABLE);
quic_follow_tap = register_tap("quic_follow");
}
You can see that the dissector registers with the UDP dissector via the udp.port table using the port preference for the dissector and also registers as a heuristic dissector, with the entry point being dissect_quic_heur. The start of that function looks like this:
static gboolean dissect_quic_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
{
/*
* Since draft -22:
* Flag (1 byte) + Version (4 bytes) +
* Length (1 byte) + Destination Connection ID (0..255) +
* Length (1 byte) + Source Connection ID (0..255) +
* Payload length (1/2/4/8) + Packet number (1/2/4 bytes) + Payload.
* (absolute minimum: 9 + payload)
* (for Version Negotiation, payload len + PKN + payload is replaced by
* Supported Version ...Asked: 2021-10-10 21:57:14 +0000
Seen: 3,865 times
Last updated: Oct 11 '21