Chinh Nguyen wrote: > I discovered that the "bug" is in the function tcp_v4_rcv for kernel > 2.6.16-rc1. > > After the ESP packet is decapped and decrypted in xfrm4_rcv_encap_finish, the > unencrypted packet is pushed back through ip_local_deliver. For a UDP packet, > it > goes (back) to function udp_queue_rcv_skb. The first thing this function does > is > called xfrm4_policy_check. As noted previously, in xfrm4_policy_check, if the > skb->sp != NULL, the esp_post_input function is called. The post input > function > sets skb->ip_summed to CHECKSUM_UNNECESSASRY if we are in transport mode. > Therefore, further down in udp_queue_rcv_skb, we skip the checksum check and > the > packet is passed up the stack. > > However, for a decrypted TCP packet, the packet goes to tcp_v4_rcv. This > function does the checksum check right away if skb->ip_summed != > CHECKSUM_UNNECESSARY while xfrm4_policy_check is called a little later in the > function. Therefore, the esp post input has not yet set the ip_summed to > unnecessary. The decrypted packet fails the checksum and is discarded. > > To confirm this, I added another call to xfrm4_policy_check before the > checksum > check in tcp_v4_rcv (to call esp post input). Once patched, my systems were > able > to initiate TCP connections using Transport Mode/NAT.
What values does skb->ip_summed have before that? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
