Wireshark · Wireshark-users: Re: [Wireshark-users] Fwd: sequence number and packet id

[Guy Harris <guy@xxxxxxxxxxxx>]

Fabiana moreno wrote:
> yes i was in indeed refering to the following sequence number (the one 
> in bold red) and it is from the rtp protocol. I am confused; because it 
> seems like a packet identifiers; it starts with a random number and then 
> goes on adding 1 for every packet.

Somebody earlier in this thread quoted RFC 1889, "RTP: A Transport 
Protocol for Real-Time Applications", which is the specification for RTP:

	sequence number: 16 bits
	     The sequence number increments by one for each RTP data packet 
sent, and may be used by the receiver to detect packet loss and to 
restore packet sequence. The initial value of the sequence number is 
random (unpredictable) to make known-plaintext attacks on encryption 
more difficult, even if the source itself does not encrypt, because the 
packets may flow through a translator that does. Techniques for choosing 
unpredictable numbers are discussed in [7].

So, yes, the RTP sequence number starts with a random number and then is 
increased by 1 for each packet, because that's what the RTP 
specification says should happen.

It is unrelated to the IP packet identifier.

> My other email is that i have noticed something very weird while taking 
> the captures with tcpdump instead of wireshark. The packets id´s are 
> always 0; which is not correct;

Why is it not correct?  There is *NOTHING* in RFC 791 that requires the 
IP ID to be unique in non-fragmented packets, and there's nothing I 
found in the Host Requirements RFC 1122 about it, either, as per my 
other mail:

	http://www.wireshark.org/lists/wireshark-users/200804/msg00194.html

> ive been reading about and apparently 
> theres is bug in the kernel 2.6...but i dont really know why i am 
> getting those captures with packet id=0 ....

At least some pages I found with Google seem to suggest that this is a 
*feature* of the Linux kernel, introduced in the 2.4.8 kernel or earlier.