Extracting/Dissecting Protocol/Layer information

[causalloop]

I'm not an expert in pretty much anything, so bare with me here...

We've got an old script from python 2.7 that I'm trying to update to 3.x because the author refuses to do it. Its purpose is to basically look at the stream from a camera and make sure that various things work correctly - thats the short version. Jumping ahead a bit, when I look at the pcap in wireshark, the info I need is from the UDP packet is in the H.264 Layer/Protocol (I'm not sure what the right word is). I can see it fine in wireshark, and if I only needed to look at one packet, that'd be the end of it, but I have to do run this script for 2 minutes at all the different resolutions a particular camera can do.

So. using pyshark and tshark, I can get 4 layers that actually have information I can do something with (except that I don't actually need them...), those layers are, ETH, IP, UDP and RTP. The remaining layers show up as "DATADATA".

I can upload some of the info, but it gets tricky because we're working with stuff that hasn't been released yet and I don't know what I can and can't share... I did upload a screen shot of some of the data we're using - basically as an identifier for the other information in the packet, i.e., if it has this, then look at some timing info etc. I know it's not much to go on, but I've spent too long on it already (I need to learn to fail faster...)

Any thoughts on how I can turn "DATADATA" into something useful...?

This is what I see in the output:

Packet (Length: 1378)
Layer ETH:
	Destination: 00:50:b6:a2:f0:52
	Address: 00:50:b6:a2:f0:52
	.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
	.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
	Source: a4:11:62:75:90:ab
	.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
	.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
	Type: IPv4 (0x0800)
	Address: a4:11:62:75:90:ab
Layer IP:
	0100 .... = Version: 4
	.... 0101 = Header Length: 20 bytes (5)
	Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
	0000 00.. = Differentiated Services Codepoint: Default (0)
	.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
	Total Length: 1364
	Identification: 0xd4cc (54476)
	Flags: 0x40, Don't fragment
	0... .... = Reserved bit: Not set
	.1.. .... = Don't fragment: Set
	..0. .... = More fragments: Not set
	...0 0000 0000 0000 = Fragment Offset: 0
	Time to Live: 64
	Protocol: UDP (17)
	Header Checksum: 0xdf25 [validation disabled]
	Header checksum status: Unverified
	Source Address: 192.168.0.13
	Destination Address: 192.168.0.73
Layer UDP:
	Source Port: 5010
	Destination Port: 62681
	Length: 1344
	Checksum: 0xb07e [unverified]
	Checksum Status: Unverified
	Stream index: 59
	Timestamps
	Time since first frame: 1.249315000 seconds
	Time since previous frame: 0.000125000 seconds
	UDP payload (1336 bytes)
DATADATA

[cbrauckmiller]

Does the pcap look the same way when you load it into Wireshark?
I had this problem with UDP and DTLS. Wireshark wasn't displaying the DTLS protocol, but was showing it as QUIC. I used "Decode As" in Wireshark and told it to do DTLS instead. I exited Wireshark and then ran my script and started seeing DTLS in my output.

I assume there is a way to get tshark to do a 'decode as' as well, but I'm no expert.

Hope that helps.

[KimiNewt]

If that is indeed the solution then you can either save your wireshark configuration (tshark will by default use the default wireshark ones). You can also use the decode_as= flag in the Capture constructor. See the docs:

:param decode_as: A dictionary of {decode_criterion_string: decode_as_protocol} that are used to tell tshark
        to decode protocols in situations it wouldn't usually, for instance {'tcp.port==8888': 'http'} would make
        it attempt to decode any port 8888 traffic as HTTP. See tshark documentation for details.