Corrupted Destination Port & TCP Header for an FTP Segment

1. How the receiving TCP reacts to the corrupted port

The IP datagram reached host 130.14.16.19/16 (same /16 network as the intended 130.14.16.17), so IP delivers it normally — IP only checks the network/host address, not the transport port. The problem is at TCP:

1. TCP first verifies its checksum (which covers the TCP header, the pseudo-header of source+destination IP, and the data). A corrupted destination-port field changes the header, so the checksum fails → TCP silently discards the segment and sends no ACK and no ICMP error (TCP never reports errors for damaged segments, to avoid error-reporting storms).
2. The sender receives no ACK → its retransmission timer expires → it retransmits the segment; the original (correct) segment then reaches 130.14.16.17.
3. Even if the bad port passed checksum (hypothetically), TCP at .19 would look up the port in its connection table, find no socket bound to that port, discard the segment and reply with a TCP RST (reset) segment to the sender, tearing down the bogus connection attempt.

Key point: ports are used only for demultiplexing at the endpoints, never for routing — so corruption cannot mis-route the packet; it only causes local delivery failure + retransmission/RST.

2. TCP header for a message from an FTP client to an FTP server (data = 40 bytes)

Well-known port = 21 (FTP control). Ephemeral port chosen = 52345 (in the dynamic range 49152–65535). Header length = 20 bytes (5 words), so total segment = 20 + 40 = 60 bytes.

Field	Value	Remark
Source Port	52345	ephemeral port, client side
Destination Port	21	FTP well-known port
Sequence No.	1000	(example) first byte of this segment
Acknowledgment No.	5000	(example) next byte expected from server
Data Offset	5	5 × 4 = 20-byte header, no options
Reserved	000	—
Flags	URG=0, ACK=1, PSH=1, RST=0, SYN=0, FIN=0	pure data segment
Window	8192	advertised receive window (example)
Checksum	0x0000	filled with 0s as instructed
Urgent Pointer	0	URG=0, field unused
Options	none	header stays 20 bytes
Data	40 bytes	e.g. an FTP command/response

Total length = 60 bytes.