When checksum offload is enabled, the driver calls setChecksumResult method to encode the checksum result on the each received packet before passing it up towards the protocol stacks.
I want to verify checksum value computed by the hardware on received packets is correct or not. It is really not easy for me. It is because if the hardware provides error checksum value, protocol stacks seems re-calculate no matter in full or
partial checksum mode.
For instance, in partial checksum mode, driver provides a partial 16-bit checksum value to allow the protocol stacks to calculate and verify the final checksum. But if the driver provides error partial checksum value, the protocol stacks seems re-calculate checksum value and without any signal or log to tell users, even tcpstat.tcps_rcvbadsum's value has not increased. So I could not know the checksum value that hardware provided is correct or not.
Question:
1. Does the OSX shows any message or log to User while stacks indicates a bad checksum calculated by h/w?
If receive checksum offloading is enabled then the hardware will reject the packet when it sees the bad checksum and the OS will not get to see it in the first place. That is more or less the point of checksum offloading, to avoid the bus transfer of the copy of the received data from the Ethernet chip FIFO into mbufs and the subsequent receive interrupt, running the ISR, running ip_input and tcp_input, etc., only to have wasted all that work on a bad packet.
2. In a received packet, from which byte to which byte is the partial
checksum calculated?
It depends on the protocol family and what the chip supports. Most chips will support TCP/IP directly, but for example won't support RTSP. There are separate flags in the header for what's supported on a given interface. See the family documentation you were pointed to yesterday for details.
3. Does the calculation of partial checksum include the trailer?
RFC 791 states that the ip checksum is a header-only checksum for the encapsulating header. RFC 793 states that a TCP checksum covers the TCP header and payload. Other protocols vary.
If you are talking about TCP option 14 and 15 for alternate checksums or TCP option 18 for trailer checksums, I imagine you would have to disable at least TCP checksum offloading to successfully use one of these. I've never bought the performance claims for 18 if the Ethernet contoller is capable of header-based offload anyway.
4. If CRC code is appended into each packet, does partial checksum have to be calculated the CRC code?
Answered above, I think. It seems to me that you are intending a trailer checksum. If so, the speed improvement they claim in the paper is based on setting the option bit, which necessarily means the TCP header checksum is not going to be valid from the sender side which would in turn mean that you would need to disable verification in hardware on the receive side. This would increase the possibility for DOS attacks and/or receiver livelock, particulary the more interfaces you have, unless you implement firmware changes on the interfaces (similar to Luigi Rizzo did in FreeBSD and Peter Druschel's group did at Rice University, with the Tigon II firmware). I'm pretty sure Broadcom quit licensing the firmware source in 2001 or so when they released the Tigon III.
5. Does the driver need to provide partial checksum to all the protocols?
Since IP is for the header only, it would depend on your encapsulated protocol, unless you were swizzling the IP header contents, too, and whether you altered the payload on it. Theoretically, if the hardware is capable of the protocol (e.g. TCP) and you have sender checksum offloading, it's going to calculate the whole thing in the sending side for the entire payload anyway, so the receiver check will pass on the packet to the IS anyway..
-- Terry
Any reply would appreciated...
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|