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.
https://bugzilla.gnome.org/show_bug.cgi?id=795284
Also swap the linktype after we detected that we need to do
byteswapping. Fixes a problem with reading pcap files generated
on a machine with different endianness.
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Using gst_adapter_take_buffer_fast() can lead to buffers that are
made up of multiple memories with the first memory smaller than the
RTP header size, which violates assumptions GstRtpBaseDepayloader
makes, namely that the complete RTP header will be in the first
memory. This leads to such packets being dropped when feeding
them from pcapparse to RTP depayloaders. Use take_buffer() so
we get buffers with a single memory.
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Flush any trailing bytes after the payload from the adapter as well,
otherwise we'll read a bogus packet size from the adapter next and
then everything goes downhill from there.
https://bugzilla.gnome.org/show_bug.cgi?id=751879
Also, strictly speaking, these numbers aren't DLT_*; they are LINKTYPE_* because
libpcap translates from internal OS-specific DLT_ numbering to the portable
LINKTYPE_ number space when writing files.
https://bugzilla.gnome.org/show_bug.cgi?id=738206
gstpcapparse.c: In function 'gst_pcap_parse_chain':
gstpcapparse.c:381:6: error: 'eth_type' may be used uninitialized in this function [-Werror=uninitialized]
gstpcapparse.c:354:11: note: 'eth_type' was declared here
The current code is not checking for ethernet type, as it's supposed to,
but link layer device type and it's hard-coded to only accept dumps from
ethernet (ARPHRD_ETHER; 1). We don't care where the dump was fetched
from (wlan, 3G, etc.)
What we care about is the that the ethernet type is IP (ETHERNET_IP;
0x800), which is clearly field 14:
http://www.tcpdump.org/pcap3_man.html
And do a bit of cleanup.
Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>
That is, output timestamps can then either be the absolute capture time,
or the relative capture time (w.r.t. to first output buffer), or the relative
capture time incremented by some offset.
Remove the weird (failing) code to figure out caps on the srcpad.
Add a caps property to decide what caps to put on the outgoing buffers.
Fix an event leak.
Original commit message from CVS:
Patch by: Damien Lespiau <damien dot lespiau at gmail dot com>
* gst/pcapparse/Makefile.am:
* gst/pcapparse/gstpcapparse.c:
Patch to make gstpcapparse compile with mingw32 gcc. Fixes#565439.
Original commit message from CVS:
* gst/pcapparse/gstpcapparse.c:
* sys/winscreencap/gstdx9screencapsrc.c:
* sys/winscreencap/gstgdiscreencapsrc.c:
Added documentation blobs. Thanks to Stefan for noticing!
