It gets weirder: on a few packets a day, your host sends one that has the
ip->ip_off field byteswapped. Ie, the field is 0x0040 instead of 0x4000,
which latter would be setting the DF bit. The outgoing kernel sendto() on
amprgw doesn't like these at all, since that would imply that they're
a middle fragment of a fragmented datagram, but the ip->ip_len field is
preposterous. So we get a kernel sendto() error for "Invalid option" and
the packet is dropped. Most of the packets you send with a preposterous
length field also have the DF bit set, and rules in the ipip router code
catch that, tally it, and discard it instead of attempting to write it
to the kernel. But not those with the ip_off field byteswapped. At first
I thought it was a bug in my code, but no, it's really there. Arrgh.
Glad you're working on it. Best wishes!
- Brian
On Wed, May 03, 2017 at 07:30:50PM -0700, Jeremy Cooper wrote:
On Wed, 26 Apr 2017, Brian Kantor wrote:
>A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8)
>is sending an encapped packet that is peculiar: it is either 40 or 44
>bytes long, but the length field in the IP header is set to a varying but
>very large packetsize (for example, 61,683 bytes) and the Don'tFragment
>bit is set so the amprgw IP kernel sending routine can't break it up
>into MTU-sized fragments - thus it gets a transmit failure and isn't
>sent anywhere.