I would find it bizarre in the extreme to classify this bug as an
enhancement request.
It is a corner case, yes, but it is still a severe bug under
demonstrable conditions. It cost me about 3 man-weeks of time to
troubleshoot the problem and find a work-around. Basically, wireshark
was unusable for my client with this bug there.
Simply let the TCP window close and it becomes a significant problem
for any TCP protocol since when the flow control is relieved packets
start getting chunked out on 1500 byte boundaries, regardless of what
the PSH bits were. PSH is just a hint, as I understand it. It doesn't
guarantee anything. TCP models a stream.
Flow control is not the norm I guess but it is fully supported in TCP.
In my case it occurs because I have an embedded device that sends
frequent notifications and and if they are not relieved from the
socket quickly enough eventually the connection gets flow controlled.
Besides I doubt anyone would argue at this point that desegment_tcp is
doing the "Right Thing." This is just a plain old bug, not a feature.
All that said I can see that Blocker would be the wrong severity.
Major seems right to me since it is a severe problem when it happens
to you and it affects many dissectors since the bug is in
desegment_tcp. However one might also consider it "minor" since I have
a hack that works for me... it just isn't a hack that could be applied
to the trunk.
-- John.
