URL: <http://gna.org/bugs/?21300>
Summary: Network compression can send packet which receiver interprets incorrectly Project: Freeciv Submitted by: jtn Submitted on: Sun Nov 24 14:41:49 2013 Category: None Severity: 3 - Normal Priority: 5 - Normal Status: In Progress Assigned to: jtn Originator Email: Open/Closed: Open Release: 2.3.4,2.4.0,2.5.0,2.6.0 Discussion Lock: Any Operating System: Any Planned Release: 2.3.5,2.4.1,2.5.0,2.6.0 _______________________________________________________ Details: If, by bad luck, an outgoing compressed lump of data ends up being *exactly* 49148 octets, then the network compression (USE_COMPRESSION) decides to send it with "normal" rather than "jumbo" encoding due to its test of JUMBO_BORDER. Unfortunately, the encoded length ends up being 0xFFFF, which the receiver interprets as being a "jumbo" packet (JUMBO_SIZE). It then tries to interpret the next four octets (which are in fact the start of the compressed data) as a length field. You'd have to be quite unlucky to hit this, but if you did then the network connection would likely never recover. With things as they stand this is most likely to show up when a client connects. I believe I've reproduced this by hacking, but it's too tangled up with other changes to present here. The client eventually barfed with "can't grow buffer". Fix should be trivial: in conn_compression_flush() on the sender, change "compressed_size <= JUMBO_BORDER" to <. No change is needed on the receiver. _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?21300> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev