Fixed a bug in previous revision: compute the payload checksum before
we convert ip_len into a network byte order; in_delayed_cksum() still expects it in host byte order. The symtom was the ``in_cksum_skip: out of data by %d'' complaints from the kernel. To add to the previous commit log. These fixes make tcpdump(1) happy by not complaining about UDP/TCP checksum being bad for looped back IP multicast when multicast router is deactivated. Reported by: Vsevolod Lobko
This commit is contained in:
parent
93996f6d58
commit
390cdc6a76
@ -2188,6 +2188,14 @@ ip_mloopback(ifp, m, dst, hlen)
|
||||
if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen))
|
||||
copym = m_pullup(copym, hlen);
|
||||
if (copym != NULL) {
|
||||
/* If needed, compute the checksum and mark it as valid. */
|
||||
if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
|
||||
in_delayed_cksum(copym);
|
||||
copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
|
||||
copym->m_pkthdr.csum_flags |=
|
||||
CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
|
||||
copym->m_pkthdr.csum_data = 0xffff;
|
||||
}
|
||||
/*
|
||||
* We don't bother to fragment if the IP length is greater
|
||||
* than the interface's MTU. Can this possibly matter?
|
||||
@ -2220,14 +2228,6 @@ ip_mloopback(ifp, m, dst, hlen)
|
||||
copym->m_pkthdr.rcvif = ifp;
|
||||
ip_input(copym);
|
||||
#else
|
||||
/* If needed, compute the checksum and mark it as valid. */
|
||||
if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
|
||||
in_delayed_cksum(copym);
|
||||
copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
|
||||
copym->m_pkthdr.csum_flags |=
|
||||
CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
|
||||
copym->m_pkthdr.csum_data = 0xffff;
|
||||
}
|
||||
if_simloop(ifp, copym, dst->sin_family, 0);
|
||||
#endif
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user