I am capturing incoming and outgoing WAN to LAN data at a particular host on my LAN (i.e., the one actually receiving/sending the data). Sometimes I get anomalous captured frames that are missing the udp string in the frame.protocols field.

That is, instead of containing the correct string:


These frames have:


Examining the ip.version and ip.proto fields of these frames in order to make sure that they are in fact UDP datagrams, I see, as expected:

ip.version=4   # IPv4
ip.proto=17    # UDP

The bad thing about these captured frames is that I do not get any UDP specific info, such as src/dest port info, since no UDP parsing is attempted on them. I am pretty much limited to just the two IP addresses and the data length which are part of the IP v4 header, with the especially desirable udp.srcport and udp.dstport fields being absent.

It is unclear to me what is special about the frames that get processed like this, although I have noticed that they all have frame lengths in the set {68,69,71} bytes with data lengths in bytes of {34,35,37}, respectively.

If anyone can please shed a light on why these frames are not parsed properly by tshark, I would greatly appreciate it.


I was told in a comment that I am not providing enough info to help determine the cause of this. Below is a full frame breakdown in JSON of one of these troublesome frames. Note that I have masked out some personal info with "x" characters. Other than that, this is a complete parsed frame data dump from tshark.

Dumpcap (from Wireshark) is being used directly to capture the data on a (very powerful, 18 physical core i9-7980XE w/ 128 GB RAM) Windows 10 host.

The version of dumpcap is:

Dumpcap (Wireshark) 3.0.2 (v3.0.2-0-g621ed351d5c9)

The command being used to capture is:

"C:\Program Files\Wireshark\dumpcap.exe" -n -q -s 94 -b filesize:256000 -p \
-w i:\v3_packet_capture -i \Device\NPF_{AA8Fxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} \
-f "ip and (((icmp or udp) and ((src and not (dst net\
    or dst xxx.xxx.xxx.xxx)) or (dst and not (src net\
    or src xxx.xxx.xxx)))) \
    or (tcp and (port 52799 or port xxxx or \
       (src \
        and not (dst net 192.168.8/24 or dst port 80 \
                 or dst port 443 or dst xxx.xxx.xxx.xxx)) \
    or (dst and not (src net \
        or src port 80 or src port 443 \
    or src xxx.xxx.xxx.xxx))))) \
and not broadcast and not multicast"

I know that the capture filter is exceedingly complex and so I will break it down in English:

1. Restrict captured frames to LAN to WAN unicast traffic, only.
     More specifically, only IPv4 packets that consist of
     TCP/UDP/ICMP segments/datagrams/messages should be captured.
2. Exclude most HTTP(S) traffic by via port exclusions (80/443).

..., and finally (although not relevant to the case at hand):

3. Include other TCP traffic that is for sure sourced/destined 
   from/to the app being monitored (ports 52799 and xxxx). 

It may or may not be also important to note that in order to reduce the amount of data being captured and written to files, I am restricting the frame data being captured to the first 94 bytes of each frame via the -s 94 maximum frame data to capture switch to dumpcap. I don't believe that this impacts anything, since the maximum frame length of the anomalous frames of 71 is well below this threshold.

This is the tshark command that is being used to parse the pcapng data file (on a Linux host):

tshark -V -O tcp,icmp,udp -r packet_capture_00006_20190614224011 -T json
       -Nt -E "occurrence=a"

Here is the tshark version information, if helpful:

TShark (Wireshark) 2.6.8 (Git v2.6.8 packaged as 2.6.8-1~ubuntu18.10.0)

And this is an excerpt of an anomalous frame:

    "_index": "packets-2019-06-15",
    "_type": "pcap_file",
    "_score": null,
    "_source": {
      "layers": {
        "frame": {
          "frame.interface_id": "0",
          "frame.interface_id_tree": {
            "frame.interface_name": "\\Device\\NPF_{AA8Fxxxx-
            "frame.interface_description": "Ethernet 2"
          "frame.encap_type": "1",
          "frame.time": "Jun 14, 2019 22:40:13.262031000 CDT",
          "frame.offset_shift": "0.000000000",
          "frame.time_epoch": "1560570013.262031000",
          "frame.time_delta": "0.000001000",
          "frame.time_delta_displayed": "0.000001000",
          "frame.time_relative": "1.630154000",
          "frame.number": "1918",
          "frame.len": "71",
          "frame.cap_len": "71",
          "frame.marked": "0",
          "frame.ignored": "0",
          "frame.protocols": "eth:ethertype:ip:data"
        "eth": {
          "eth.dst": "14:35:8b:xx:xx:xx",
          "eth.dst_tree": {
            "eth.dst_resolved": "14:35:8b:xx:xx:xx",
            "eth.addr": "14:35:8b:xx:xx:xx",
            "eth.addr_resolved": "14:35:8b:xx:xx:xx",
            "eth.lg": "0",
            "eth.ig": "0"
          "eth.src": "70:85:c2:xx:xx:xx",
          "eth.src_tree": {
            "eth.src_resolved": "70:85:c2:xx:xx:xx",
            "eth.addr": "70:85:c2:xx:xx:xx",
            "eth.addr_resolved": "70:85:c2:xx:xx:xx",
            "eth.lg": "0",
            "eth.ig": "0"
          "eth.type": "0x00000800"
        "ip": {
          "ip.version": "4",
          "ip.hdr_len": "20",
          "ip.dsfield": "0x00000000",
          "ip.dsfield_tree": {
            "ip.dsfield.dscp": "0",
            "ip.dsfield.ecn": "0"
          "ip.len": "57",
          "ip.id": "0x0000076d",
          "ip.flags": "0x000000af",
          "ip.flags_tree": {
            "ip.flags.rb": "0",
            "ip.flags.df": "0",
            "ip.flags.mf": "0",
            "ip.frag_offset": "175"
          "ip.ttl": "128",
          "ip.proto": "17",
          "ip.checksum": "0x0000ccxx",
          "ip.checksum.status": "2",
          "ip.src": "",
          "ip.addr": "",
          "ip.src_host": "",
          "ip.host": "",
          "ip.dst": "38.132.xxx.xxx",
          "ip.addr": "38.132.xxx.xxx",
          "ip.dst_host": "38.132.xxx.xxx",
          "ip.host": "38.132.xxx.xxx"
        "data": {
          "data.data": "dc:dd:2e:14:xx:...:xx:e2:16:5b:9c",
          "data.len": "37"

Here is an example of the UDP section that is missing from the above frame, based on the properly parsed UDP datagram that immediately followed it (with, other than data length and frame specific header info/checksums, identical (IP/UDP) characteristics):

      "frame.number": "1919",
    "udp": {
      "udp.srcport": "52799",
      "udp.dstport": "51413",
      "udp.port": "52799",
      "udp.port": "51413",
      "udp.length": "1437",
      "udp.checksum": "0x000097c5",
      "udp.checksum.status": "2",
      "udp.stream": "0"

I believe that I have provided all of the pertinent info above. If not, please let me know what to add to this question in order to help troubleshoot the cause.

  • 2
    You're providing nowhere near enough information for anyone to answer your question.
    – Zac67
    Commented Jun 15, 2019 at 19:35
  • I've added additional info in the form of a parsed frame of the erroneous type. Commented Jun 15, 2019 at 19:42
  • Have you tried explicitly setting the decode to UDP?
    – Ron Trunk
    Commented Jun 15, 2019 at 20:20
  • @Ron, well this is just one frame among many and there is a mix of TCP/UDP/ICMP (not to mention TCP/ICMP and UDP/ICMP) containing frames that all need to be decoded. So, I am not sure how I should go about doing this wile preserving the formentioned parsing. Commented Jun 15, 2019 at 21:58
  • Do the undecoded frames have anything in common? Source? Destination?
    – Ron Trunk
    Commented Jun 15, 2019 at 22:47

1 Answer 1


You have fragmentation and when you don't see UDP header, it means this is not the first fragment of the IP Datagram. In your given frame, look at the 'ip.frag_offset' which is 175.

So there is at least one previous fragment that you can find with the same ID field in the IP header ("ip.id").

  • OK, so you believe that the UDP parser is not parsing subsequent fragments of a fragmented UDP datagram, despite the fact they they are well formed and contain a proper UDP header. Also, the parser reports no errors (e.g., for TCP segment fragmentation issues, errors are properly reported by the TCP parser). As a result, none of the UDP header fields get reported and udp is absent from the descriptive frame.protocols field even though the ip.proto field is 17 (UDP). I will look into this and see if the captured anomalous frames all contain the characteristics you pointed out. Commented Jun 16, 2019 at 13:53
  • @MichaelGoldshteyn, packets that are fragments will not have the transport protocol header. The transport protocol header will only be in the first packet.
    – Ron Maupin
    Commented Jun 16, 2019 at 15:04
  • 1
    @Ron, I did more reading on the subject, and you are absolutely correct. Omuffat, therefore, deserves the checkmark! Commented Jun 16, 2019 at 19:40
  • @MichaelGoldshteyn, that is because the packet payload is just data to IP. IPv4 knows nothing about what is in the payload, so it fragments it as is.
    – Ron Maupin
    Commented Jun 16, 2019 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.