3 May
2017
3 May
'17
9:30 p.m.
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