I couldn't understand why UDP header has 'length' field, and why it is needed?
If the reason is to know where the 'application message(L5 data)' begins in the segment, it can just be gotten from 'UDP data - UDP header length(it is already known value)'.
Because UDP can be transmitted over another protocol than IP.
And also because UDP transmits datagram messages with a length (udp length) which can be sent over multiple IP fragmented packets.
Source: https://notes.shichao.io/tcpv1/ch10/
The UDP header length field is the length of the UDP header plus the UDP data. It is indeed redundant since this length can be calculated from the IP header total length field where the UDP datagram length is the IP total length minus the IP header length.
UDP uses message stream NON FIFO as communication model between the sender and receiver. If the size is not mentioned then it will not be possible to decipher the message at rxr.
Say m1m2m3 is sent then each message to be notified so that u can trace back the message.
Regards
Related
For example, one 2000 bytes UDP package(contains UDP header) and network MTU is 1500. So this UDP package should be split to two IP fragments. Only the first IP package contains the UDP header.
What value should be filled into UDP length in the UDP header of first IP package? 1480 or 2000?
Is there any document to confirm this?
UDP Length is the length of the UDP header AND the UDP data, in bytes. The fragmentation will/should NOT change this.
[UDP] "Length is the length in octets of this user datagram including this header and the data" --RFC768, an Internet Standard. It is also in the Stevens link referenced: "Referring to Figure 10-2, the UDP Length field is the length of the UDP header and the UDP data in bytes."
I think you may be overthinking this. Just set the UDP length to however big your data is.
IP fragmenting can occur at any router hop, without your knowledge (assuming you are the sender). It's the IP layer's responsibility to fragment and re-assemble the packet before the UDP datagram is delivered to the application. Unless you're plugged in to the NIC driver, you won't be able to reliably tell if the packet was fragmented on the way.
If there's an IP fragment lost on the way, you won't get any UDP datagram at all, it will simply be lost from the application's point of view, even though the IP layer may have gotten 9 out of 10 fragments.
Everything about this is brilliantly described in Richard Stevens et al's seminal work: TCP/IP Illustrated, Volume 1: The protocols
, section 10.7 IP Fragementation.
Exam question (with no additional info):
When an bunch of IP datagram fragments are being sent over the network and only one of them does not get to it's destination, what will happen then?
I'm not sure if ICMP is involved here or not. Does ICMP send an error report reporting to the source that it needs to resend that same fragment (only this one fragment)?
The problem is here that I don't know if the IP fragments use UDP or TCP therefore I don't know the answer to the question.
(I've posted on the networkengineering.stackexchange but my question was rejected)
Points to cover:
After a timer triggered by the receipt of the first fragment has expired, the reassembling host will discard all the of fragments.
The reassembling host may generate an ICMP Time Exceeded (Fragment reassembly time exceeded).
The first fragment will need to have been received for the ICMP to include the first 8 bytes of the triggering payload. IPv6 will not generate the ICMP Time Exceeded unless the first fragment was received.
With IPv6 if the reassembled datagram would be larger than 1500 bytes then it may be silently discarded.
If a higher level protocol with reliable delivery was used (e.g. TCP), then the originating host should retransmit datagrams for which no acknowledgement has been received.
No ICMP error message will be generated for a fragmented datagram that is not the first fragment.
- Data Communications and Networking by FOROUZAN
Why?
The original RFC which defines ICMP, RFC 792, INTERNET CONTROL MESSAGE PROTOCOL, makes this rule:
The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages. Also ICMP
messages are only sent about errors in handling fragment zero of
fragemented datagrams. (Fragment zero has the fragment offeset equal
zero).
Only the first fragment will have IP header information.
When an ICMP error is sent, the first 8 bytes of the original datagram.
For the first fragment, this 8 bytes (Actual Ip header) will be useful information to the sender, not in the case of other fragments.
Only first fragment has TCP header.
when sender received ICMP, there is 2 types of header in ICMP data section. (IP, TCP)
The sender can check the TCP header to recover what is wrong.
but, if not first fragment, There is no data to check what is wrong
so, ICMP only generated for a first fragment. Because sender cannot do anything.
I'm filtering packets with libpcap with a filter like "tcp src localhost". It filters all the packets whose source is localhost (my host).
When localhost doesn't receive a TCP confirmation of an already sendt packet, localhost will forward the packet.
Not all the packets filtered by libpcap will arrive to its destination, and I need to identify when a packet is a "forwarded packet". Is there any way with libpcap to identify a forwarded packet?
By my understanding, you're looking for TCP retransmissions. These can be found by display fitters in wireshark after capturing. These two should help you:
Retransmitted packets can be found through the display filter tcp.analysis.retransmission (more such filters).
When the receiver gets an out-of-order packet (usually indicates lost packet), it sends a ACK for the missing seq number. This is a duplicate ACK and these can be found by using tcp.analysis.duplicate_ack (details).
I have a question on how TCP_ACK works when the original packet are fragmented.
For example, original packet size is 1,500*N bytes and MTU is 1,500. Then, the packet will be frgmented into (approximately) N packets.
In this case, how does the receiver sends TCP_ACK to the sender?
I checked with wireshark, it seems that the receiver sends TCP_ACK for every two fragmented packet. Is it right?
Could you give me some refereces for this or explanation?
Thanks.
IP layer on the receiver stack reassembles all the IP fragments into a single TCP segment before handing the packet over to TCP. Under normal conditions, TCP should send only one ACK for the entire TCP segment. The ACK # would be the next expected SEQ # as usual.