TCP Demultiplexing, Checksum Handling, and FTP Header Construction

When a TCP segment arrives inside an IP datagram, the receiving host must (1) verify the integrity of the TCP segment (via the TCP checksum, which includes a pseudo-header), and then (2) deliver the segment to the correct TCP socket (demultiplexing) based on the 4-tuple: source IP, destination IP, source port, destination port. If demultiplexing fails—e.g., because the destination port number is corrupted—the OS/TCP will not pass the segment up the stack to an application. Instead, standard TCP behavior is to respond with a RST (reset) when appropriate (typically when the segment reaches the TCP layer but no matching listening/established socket exists).
A key nuance: the IP destination host address (the actual receiver) is still correct here: the segment arrives at 130.14.16.19/16 (same /16 destination). The corrupted part is the TCP destination port, not the IP address. Therefore the TCP layer on 130.14.16.19 still gets the segment, but it can’t find a socket matching the destination port, and reacts accordingly.

Mermaid overview of the receive path:

Key terms in this section:

• demultiplexing
• pseudo-header
• RST segment
• ephemeral port
• well-known port

What TCP does when the destination port is corrupted

Given:

• IP datagram’s destination host (as delivered) = 130.14.16.19/16
• TCP segment’s destination port is corrupted
• It therefore does not match the server’s expected FTP port or any existing connection endpoint at the receiver

The receiving TCP implementation will:

1. Compute and verify TCP checksum (if checksum is invalid, segment is discarded; OS does not normally send application data anywhere).
2. Attempt to demultiplex to an existing TCP socket using the corrupted destination port.
3. If there is no matching socket (no listening FTP control port, and no established connection with that local port), TCP responds with RST to signal “no such connection/port”.

This “RST on no matching socket” behavior is commonly taught as the response to segments arriving for an unused/closed port on the destination host. (It prevents silent failures and helps the sender quickly recognize that the connection cannot be formed.)

Callout (important): If the destination IP itself were corrupted such that the datagram never reached 130.14.16.19, then the receiver TCP would never see it. Here, only the TCP destination port is wrong, so TCP at 130.14.16.19 still receives the segment but can’t deliver it.

FTP ports to use in the TCP header you must construct

For classic FTP:

• well-known port for FTP control is 21.
• FTP often uses ephemeral ports for the client side during the control connection (the client picks a temporary source port from the ephemeral range).

So in your constructed TCP header:

• Choose a client ephemeral source port, e.g. 49152 (an appropriate ephemeral range value).
• Set the server destination port to the FTP control port 21.

Because the problem statement says the destination port address is corrupted and arrives at the destination host, the real receive behavior is about mismatched destination port. But for the “Show the entries for the header … from an FTP client to an FTP server” construction, we should fill the correct FTP server well-known port number in the TCP destination port field (21) and use an ephemeral client source port.

TCP header fields (what you would write)

Below is a conventional TCP header layout. Since the question asks “Show the entries for the header of a TCP segment … Fill the checksum field with Os … The length of the data is 40 bytes,” the main required numeric choices are ports, checksum, and payload length. For fields not specified, common simplified placeholders are used.

Example TCP header (field-by-field)

Assume:

• Source IP: 130.14.16.17
• Destination IP: 130.14.16.19
• TCP Source Port (ephemeral): 49152
• TCP Destination Port (FTP control well-known): 21
• Data length = 40 bytes
• TCP header length = 20 bytes (Data Offset = 5)
• TCP flags: PSH + ACK (data-bearing segment)

Callout (pro tip): Many homework questions accept simplified placeholder values for sequence/window when they aren’t explicitly requested—focus on ports, checksum, and consistent data offset/payload length.

How the receiving TCP reacts (putting it together)

At 130.14.16.19:

• If the checksum is verified as correct: TCP proceeds to demultiplexing.
• Because the destination port is corrupted, no matching socket exists for that local port, so TCP generates an RST (reset) rather than delivering the segment to an application.

If the checksum is not correct, TCP discards the segment and may not send an RST due to port mismatch (implementation-dependent), but the typical assignment expectation is: bad checksum ⇒ drop before demux.