GNOME Bugzilla – Bug 795284
pcapparse: give error on fragmented IP packets
Last modified: 2018-04-16 08:23:12 UTC
Hi, I was testing pcapparse on some capture of a Panasonic GH3 camera (the video data is some MJPEG over UDP variant BTW): wget http://www.personal-view.com/talks/uploads/FileUpload/03/24c6c8d18eb6ca40775e1438464147.jpg -O LumixLink_captureStill.pcap The Wireshark filter to see the interesting data is: "udp.srcport == 65416" I didn't understand why, when specifying the src-port, no data was getting downstream. After adding some printouts and looking again at the wireshark logs I finally figured out it was because pcapparse cannot parse fragmented IP packets. So what about adding an explicit check for this and warn the user with an error? I will propose a patch for that, along with some comments which may help readers new to pcapparse code. Ciao, Antonio
Created attachment 370969 [details] [review] pcapparse: add some comments about the pcap format headers Since the code is full of magic add at least some guidance for newbies.
Created attachment 370970 [details] [review] pcapparse: bail out in case of fragmented packets pcapparse cannot parse fragmented IP packets correctly, in particular it will get confused when trying to parsing fragments as standalone frames in two ways: 1. the first fragment will have the packet length greater than the frame size and will always be discarded; 2. fragments with non-zero offsets will be interpreted as full packets and the first part of their raw payload data will be parsed as the transport protocol header, resulting in bogus values for addresses and ports, thus evading the properties filtering on those values. This can make it difficult for users to see why the data does not get downstream. So be more explicit and just bail out when fragmented packets are encountered.
Could we also try to merge fragmented packets again and only drop them if not all fragments are available, i.e. what ever IP stack would do?
In the particular case of LumixLink_captureStill.pcap I managed to come up with a dumb mechanism to get all the fragments downstream. However in general fragment reassembling is not super trivial, fragments can arrive out of order, and AFAIU fragments from different packets can be interleaved, so some state tracking with supplementary data structures is needed. And to detect incomplete packets some timeout mechanism is needed. See https://tools.ietf.org/html/rfc815 pcapparse seems to parse things as they come with no state tracking whatsoever so some refactoring seems to be needed, unless I am missing something. Not something I can tackle right now, so I went for the at-least-admit-your-limits way. Ciao, Antonio
Makes sense, thanks
Attachment 370969 [details] pushed as a4df513 - pcapparse: add some comments about the pcap format headers Attachment 370970 [details] pushed as 53d7a12 - pcapparse: bail out in case of fragmented packets