Opened 22 months ago

Last modified 22 months ago

#2675 accepted defect

PacketBuilder blown up by wrong fragment size

Reported by: jogger Owned by: zzz
Priority: minor Milestone: undecided
Component: router/transport Version: 0.9.44
Keywords: Cc:
Parent Tickets: Sensitive: no


got the following error:

ERROR [acket pusher] er.transport.udp.PacketBuilder?: Size is 1456 for 1456 byte pkt with [2601:c7:8280:2050:fcf5:9497:4943:9ba3]:37535 data size 1397 pkt size 1504 MTU 1488 -3 for all acks, -3 for full acks, -1 full acks included, 0 partial acks included, Fragments: [Fragment 0 (1397 bytes) of OB Message 1981530637 type 11 with 2 fragments of size 1707 volleys: 1 lifetime: 902 pending fragments: 0 1

packet to be sent on IPv6 with fragment size from IPv4. First send attempt after 902 ms suggests peer changed through loadFrom() and states were transferred.

If that is true, messages should not be transferred/refragmented when loading from v4 to v6 because of woes with partial ACKing.


Change History (2)

comment:1 Changed 22 months ago by zzz

Status: newaccepted

Known issue, but there wasn't a ticket. IIRC it's not easy to fix.
For now, reduced log level to WARN in 7aa16e10e7c560e32eeecd5a3d2468bfad74a2f6 to be 0.9.44-4

comment:2 Changed 22 months ago by jogger

I see an easy 100% compatible fix: hardcode fragmentSize to 1394. Abandon piggyback ACK headroom calc. Leaves 16 bytes piggyback headroom (up from 13) on IPv4. On IPv6 piggyback ACKs would go with the last fragment. Not a single change for > 99% of packets sent.

If someone insists piggybacks should go ASAP, she could implement a minor change to the fragmenting code to make the first segment the smallest, instead of the last what I have never understood. That also is 100% compatible with the existing base.

Note: See TracTickets for help on using tickets.