09.12.2012 Views

RM0090: Reference manual - STMicroelectronics

RM0090: Reference manual - STMicroelectronics

RM0090: Reference manual - STMicroelectronics

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Ethernet (ETH): media access control (MAC) with DMA controller <strong>RM0090</strong><br />

IP header Length field. In other words, this bit is set when an IP header error is<br />

asserted under the following circumstances:<br />

a) For IPv4 datagrams:<br />

– The received Ethernet type is 0x0800, but the IP header’s Version field does not<br />

equal 0x4<br />

– The IPv4 Header Length field indicates a value less than 0x5 (20 bytes)<br />

– The total frame length is less than the value given in the IPv4 Header Length field<br />

b) For IPv6 datagrams:<br />

– The Ethernet type is 0x86DD but the IP header Version field does not equal 0x6<br />

– The frame ends before the IPv6 header (40 bytes) or extension header (as given<br />

in the corresponding Header Length field in an extension header) has been<br />

completely received. Even when the checksum offload detects such an IP header<br />

error, it inserts an IPv4 header checksum if the Ethernet Type field indicates an<br />

IPv4 payload.<br />

● TCP/UDP/ICMP checksum<br />

The TCP/UDP/ICMP checksum processes the IPv4 or IPv6 header (including<br />

extension headers) and determines whether the encapsulated payload is TCP, UDP or<br />

ICMP.<br />

Note that:<br />

a) For non-TCP, -UDP, or -ICMP/ICMPv6 payloads, this checksum is bypassed and<br />

nothing further is modified in the frame.<br />

b) Fragmented IP frames (IPv4 or IPv6), IP frames with security features (such as an<br />

authentication header or encapsulated security payload), and IPv6 frames with<br />

routing headers are bypassed and not processed by the checksum.<br />

The checksum is calculated for the TCP, UDP, or ICMP payload and inserted into its<br />

corresponding field in the header. It can work in the following two modes:<br />

– In the first mode, the TCP, UDP, or ICMPv6 pseudo-header is not included in the<br />

checksum calculation and is assumed to be present in the input frame’s checksum<br />

field. The checksum field is included in the checksum calculation, and then<br />

replaced by the final calculated checksum.<br />

– In the second mode, the checksum field is ignored, the TCP, UDP, or ICMPv6<br />

pseudo-header data are included into the checksum calculation, and the<br />

checksum field is overwritten with the final calculated value.<br />

Note that: for ICMP-over-IPv4 packets, the checksum field in the ICMP packet must<br />

always be 0x0000 in both modes, because pseudo-headers are not defined for such<br />

packets. If it does not equal 0x0000, an incorrect checksum may be inserted into the<br />

packet.<br />

The result of this operation is indicated by the payload checksum error status bit in the<br />

Transmit Status vector (bit 12). The payload checksum error status bit is set when<br />

either of the following is detected:<br />

– the frame has been forwarded to the MAC transmitter in Store-and-forward mode<br />

without the end of frame being written to the FIFO<br />

– the packet ends before the number of bytes indicated by the payload length field in<br />

the IP header is received.<br />

When the packet is longer than the indicated payload length, the bytes are ignored as<br />

stuff bytes, and no error is reported. When the first type of error is detected, the TCP,<br />

919/1416 Doc ID 018909 Rev 3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!