These messages do not have timestamps, thus you don't know
WHEN they happened. Browsing thru /var/log/messages might
tell you that.
This typically means that somewhere in the line from the
source to you the datalink corrupts IP packets somehow.
Perhaps you have AsyncPPP connection, and the asyncmap
characters don't match, or some control character is bad
for the modems in between, or you get occasional character
overruns (no, IP level should discard the packet then), or ..
> TCPv4 bad checksum from 205.229.196.5:0017 to 208.196.141.34:28ee,
> len=20/20/40
> TCPv4 bad checksum from 128.214.248.6:12e0 to 208.196.141.34:0019,
> len=1349/1349/1369
> TCPv4 bad checksum from 128.214.248.6:12e0 to 208.196.141.34:0019,
> len=425/425/445
> TCPv4 bad checksum from 128.214.248.6:0ef2 to 208.196.141.34:0019,
> len=1480/1480/1500
>
> The first address is from my ISP, so I can imagine something with that,
> the 128.* numbers are nic.funet.fi.... I don't remember contacting there
> lately at all, and I'm curious where these packets come from, or issit
> possible that the packet is so malformed that the IP address is not
> reliable anymore? Can this in any way be related to teardrop attack? Let
> me know if I can give more information.
IP header checksum would (should) detect errors in the IP header,
and thus the IP headers are most likely ok.
nic.funet.fi is doing SMTP relay on behalf of vger.rutgers.edu
for several toplevel domains, including ORG. Now if somebody
would be willing to install a high-power list relay server
in US for the ORG, the traffic could be moved to relay from
there. (Either you need BIG machine with sendmail, or medium
machine with ZMailer, or PMDF. If you want to step in, mail me.)
> Thanks,
> Fred Leeflang
/Matti Aarnio <matti.aarnio@tele.fi> <mea@nic.funet.fi>