🚀 go-pugleaf

    A host is sending me large packets that are getting broken up along
    the way across the internet.  When I get them there are two fragments
    [...], one of 1004 bytes and one of 516 bytes.  This makes me think
    that the originating host is sitting on an ethernet pumping out 1.5K
    packets.  I'm not sure what exactly happens, but the Dandelion doesn't
    seem to be able to reassemble the packets [...]

    Anyway, is this a known bug?  I suspect the originator shouldn't really
    be sending such large packets, but I also suspect the dandelion should
    be doing a better job of catching them.  Is there a fix?

The problem is not one of fragmentation, but of packet size.

The ethernet software on the d-machine limits datagrams to 576 bytes
[coincidentally the maximum length of an NS datagram], which is all the IP
spec requires.  Moreover, 576 bytes is the longest datagram that correspondents
may send you in the absence of "assurance that the destination is prepared to
accept the larger datagrams" (RFC791, page 13).  Your correspondent is in
error and should be fixed not to send such large packets by default.

Also:  RFC793 defines the "maximum segment size" option for TCP that limits
the size of TCP datagrams.  Xerox TCP sends this option, but in the second
packet of the connection rather than the first.  This is a failure to meet
one of the conditions of using this option imposed at the top of page 19.
Maybe if you fixed the Xerox code to send this option in the proper packet,
you could get shorter packets out of the problem host.  Maybe Xerox will fix
this and/or issue a patch?
--Christopher
-------