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:
frame.protocols=eth:ethertype:ip:udp:data
These frames have:
frame.protocols=eth:ethertype:ip:data
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.
Update:
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 192.168.8.71 and not (dst net 192.168.8.0/24\
or dst xxx.xxx.xxx.xxx)) or (dst 192.168.8.71 and not (src net 192.168.8.0/24\
or src xxx.xxx.xxx)))) \
or (tcp and (port 52799 or port xxxx or \
(src 192.168.8.71 \
and not (dst net 192.168.8/24 or dst port 80 \
or dst port 443 or dst xxx.xxx.xxx.xxx)) \
or (dst 192.168.8.71 and not (src net 192.168.8.0/24 \
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-
xxxx-xxxx-xxxx-xxxxxxxxxxxx}",
"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": "192.168.8.71",
"ip.addr": "192.168.8.71",
"ip.src_host": "192.168.8.71",
"ip.host": "192.168.8.71",
"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.
