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. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
