Re: fragmented ip packets

[Guy Harris <guy () alum mit edu>]

On Nov 23, 2010, at 8:44 AM, Ankith Agarwal wrote:

> Thank you for your valuable suggestions. I have tried out this filter
> expression---"ip[6]&0x02 == 1 and (sip related port numbers)". But, if a
> fragmented SIP packet is encountered, will this filter return the first
> fragments as sip or the last fragment?

What do you mean by "return ... as"?

The filter doesn't know what SIP is, so it doesn't "return" anything as SIP.  Libpcap/WinPcap will pass to the callback 
routine for pcap_loop() or pcap_dispatch(), or supply to the caller of pcap_next() or pcap_next_ex(), an array of raw 
bytes, beginning with the link-layer header, corresponding to a packet received by the networking code, without 
interpreting it as SIP or as anything else.  Deciding whether a packet is SIP or not is up to the program *using* 
Libpcap/WinPcap to capture traffic, or up to the program reading the capture saved by that program if the program 
capturing the traffic is just writing packets to a capture file without interpreting them (for example, tcpdump if run 
with the -w flag, or Wireshark's dumpcap).

Each fragment will be delivered to the application as a separate packet.  The first fragment - i.e., the one with a 
fragment offset of 0 - will be the one that includes the UDP header (unless the maximum packet size for the network is 
so small, or the IP header includes *so* many options, that the UDP header doesn't fit in the first fragment, but 
that's unlikely).  That means that if your program is determining whether a packet is SIP or not based on, among other 
things, the source or destination UDP port number, that will work only for the first fragment.  For the other 
fragments, you'll have to find the corresponding first fragment, based on the IP identifiers of the fragments, and 
associate them with the first fragment and reassemble them if and when you have all the fragments.

Note that there is no guarantee that the "first fragment" - i.e., the one with a fragment offset of 0 - will be the 
first one you receive!  I think that, at least at one point, Linux's Internet protocol stack would send fragments in 
*reverse* order.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.