> Every IP packet has a checksum attached to it, to help detemine if the
> packet has arrived intact. If the packet has been corrupted
> in some way,
> the cheksum will not match the rest of the packet. The
wrong. the ip header check sum covers the ip header only.
Every ethernet frame has an 32 bit CRC which covers the whole frame, so
the IP layer should never receive a packet with mistakes in it, except
1.in the case of buggy NIC, or buggy NIC driver
2.statistically 1 of each ~4'000'000'000 frames with errors will be
passed to upper layers :)
FR, PPP, HDLC have a 16 bit FCS, which covers the whole frame
I don't know about ATM, POS, DPT, etc...
The checksum in the IP header (16 bits) covers the ip header only, so
the upper layers could receive wrong data if ip layer has received wrong
data.
The checksum in the TCP header (16 bits) covers some parts of the ip
header, the whole tcp header, and the tcp data, it is generaly thought
to be impossible to receive wrong data from tcp
UDP does have a checksum, like tcp's one, but it is not mandatory, so
upper layers may receive wrong data if there was wrong data in the ip
packet.
ICMP has a checksum, which covers the entire ICMP message.
In an ICMP error message that a host sends to the source address of an
ip packet that failed the host must include at least ip header with no
options (20 bytes) + 8 octets (which a colegue of mine says "was at some
point changed to 'the whole packet'", I couldn't find an rfc about this
change but I slill beleave him)
Getting close to the point...
Looking through the code: net/ipv4/ip_masq.c
1921 /* Ensure the checksum is correct */
1922 if (ip_compute_csum((unsigned char *) icmph, len))
1923 {
1924 /* Failed checksum! */
1925 IP_MASQ_ERR( "reverse ICMP: failed checksum from
%d.%d.%d.%d!\n",
1926 NIPQUAD(iph->saddr));
1927 return(-1);
1928 }
expl: they check the icmp checksum (remember, it covers the whole icmp
message)
possibility 1: buggy NIC, buggy driver
quite possible
possibility 2: the icmp message was sent wrong, or got wrong somewhere
in the path.
2.1: sent wrong
What I imagine is that you masq some users behind this linux machine.
Somebody on the internet does not like them (like irc ignorant bullshit
stuff) so they try to break their connections to the ip addresses you
see in your log by sending them (aka your linux box) icmp error messages
about their connection, but they manage to send wrong error messages
from time to time.
But that, of course is not the only posibility to consider.
2.2: got wrong
I can't imagine that, but it is still possible.
possibility 3: there is a bug in the linux kernel
quite impossible
possibility 4: you are so lucky to hit those correct checksum-wrong data
conditions. more than once! go to by some lotary tickets. :)
Regards,
CCNP Boyan Krosnov
Network Administrator
Lirex Net
phone: +359-2-91815
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Nov 01 2001 - 13:46:59 PST