On Sep 29, 2004, at 6:16 AM, Cardenas Arevalo Gustavo Antonio wrote:
All datagrams IP that I captured about one connection TCP, the IP header has "4000" (hex) as more fragments flag and fragment offset.
That's the "don't fragment" flag, the "more fragments" flag, and fragment offset; 0x2000 is "more fragments", and 0x4000 is "don't fragment", so the "don't fragment" flag is set -which is often the case for TCP; that's done for "Path MTU discovery":
http://www.faqs.org/rfcs/rfc1191.html
A host send a sequence of 1635 bytes.
I see:
a) A first packet IP with 1460 bytes (total length 1500), flag: ACK, sequence IP: D5C1 b) A second packet IP with 175 bytes (total length 215), flag: ACK, PSH, sequence IP: D5C2 c) both packets have the same acknowledgment number D69D108E
then
1) I can take the PSH as end of sequence of 1635 bytes?
No. To quote RFC 793:
Sometimes users need to be sure that all the data they have
submitted to the TCP has been transmitted. For this purpose a push
function is defined. To assure that data submitted to a TCP is
actually transmitted the sending user indicates that it should be
pushed through to the receiving user. A push causes the TCPs to
promptly forward and deliver data up to that point to the receiver.
The exact push point might not be visible to the receiving user and
the push function does not supply a record boundary marker.The push function causes the PSH flag to be set in the segment; if a machine receives a segment with PSH set, then:
if there are no segments before that segment that haven't been received, it should make the data from the segment with PSH available to the application, and not wait for any later segments to arrive;
if there are segments before that segment that haven't been received, it should make the data from the segment with PSH available as soon as all the missing segments are received.
It does not mean that a sequence representing records for a protocol running *atop* TCP is complete - as RFC 793 says, "the push function does not supply a record boundary marker". There are no record boundary markers in TCP; an application that needs to have record boundary markers in a TCP stream has to put them there itself, either by putting in a record length into the data stream at the beginning of a record, or by putting some form of end-of-record marker into the data stream, or....
2) the sequences IP D5C1 and D5C2 help me to order datagrams?
No. RFC 791 calls that field the "Identification" field:
Identification: 16 bits
An identifying value assigned by the sender to aid in assembling the
fragments of a datagram.It's not a sequence number. A given IP implementation might happen to assign IP identifications sequentially, but
1) there's no guarantee that it does so
and
2) it's only 16 bits, so even if they are assigned sequentially, the next sequence number after 65535 would be 0.
The TCP sequence number should be used to put TCP segments in order (although note that it wraps around as well, although it's 32 bits and wraps around less often).
3) if both packets have the same acknowledgment number, it help?
Not necessarily. It merely indicates that no TCP packets with data were received and handled, by the machine sending the acknowledgments, between the times at which the two packets were sent.
4) why header ckecksum field of IP in some packets are 0000? no problem?
If those packets were being sent by the machine on which you're running the application capturing the packets, and if the network interface on which the packets are being transmitted does IP checksum offloading, it's probably zero because the IP implementation isn't setting the checksum before supplying the packet to the network interface, as it's relying on the network interface to compute the checksum before sending the packet. Most Ethernet interfaces - and possibly other interfaces - don't receive the packets that they transmit, or, if they do, they don't supply them to the host as input, so, in order to capture packets being transmitted on the host on which the capture program is running, the packets are "wrapped around" by the networking code, so they're supplied to libpcap/WinPcap before being supplied to the network interface, and therefore before being given an IP header checksum, if the IP header checksum is being computed by the network interface rather than the host.
5) In the book I no found description of 3-bit fragments flag. what is the description?
In chapter 3 it says "Similarly, we'll also look at the 'flags' field and the 'fragmentation offset' field when we talk about fragmentation." In the index, it says
fragmentation, 29, 548
IP, 148-150Pages 148-150 are in the section on UDP (probably because TCP and ICMP packets are rarely fragmented, but some protocols that can run on top of UDP, such as Sun's ONC RPC and some Microsoft streaming media protocols, frequently fragment packets when running on UDP).
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
