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



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

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

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:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to