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
[email protected]
https://mail.gna.org/listinfo/freeciv-dev
