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.
I think I'm closer to finding out why this happens. I use a firewall rule (using FreeBSD ipf(8)) to make sure that traffic leaving my network with a source of 44.0/8 is redirected to the tunneling interface:
# Make certain AMPR/44 hosts reaching outwards will tunnel through AMPR # gate pass out quick on vlan0 to gif0:44.0.0.1 from 44/8 to any
I believe, however, that in picking up and relocating the packet this way, I am perhaps taking a packet that was destined for some interface acceleration (such as offlined checksumming and the like) and placing it on an interface queue that has no such optimizations.
Still more research required, but I see the problem now.
-J