(Redirected to ethereal-dev, as this is ultimately a development
question.)
On Tue, Apr 15, 2003 at 11:08:21AM +0800, konghw wrote:
> Currently I am using Ethereal to capture and dissect BGP
> messages. It works well for most of the times. However, I noticed that
> when the BGP message header is over the edge of TCP segment, the BGP
> dissector will meet some problem. I have reported the bug and patch to
> Guy Harris. After checking in this patch, Ethereal BGP dissector works
> well when there is no TCP segment loss and retransmission.
>
> However, when there is TCP segment loss and retransmission, I
> found BGP dissector didnt take the retransmission into consideration.
> Once one segment is lost and the following several TCP segment
> (depending on the length of the BGP message) may not be decoded
> correctly even though the retransmission of the lost segment are
> captured correctly. I think TCP layer has solved the problem of segment
> loss and retransmission. I don't know whether Ethereal's BGP dissector
> can be configured to handle the problem of segment loss and
> retransmission correctly. If not, are there any plan of adding this
> feature to the BGP dissector of Ethereal?
There probably shouldn't be any plans to do that, because...
> I think this is not a problem only pertaining to BGP dissector.
> All other dissectors for the protocols based on TCP will have the
> similar problem.
...you're right - this *isn't* a problem unique to BGP, so it shouldn't
be solved in the BGP dissector, it should be solved in the *TCP*
dissector; as you said:
I think TCP layer has solved the problem of segment loss and
retransmission.
> Adding the handling of TCP segment loss and retransmission in ethereal
> will be very helpful to the analysis of these protocols.
Yes.
The code that currently does TCP sequence number analysis might be the
code that should handle retransmissions; if it detects retransmitted
data, and the original data is in the capture (which might always be the
case if it can detect a retransmission), it should arrange that
subdissectors of the TCP dissector not be called with the retransmitted
data.
That would mean that you'd have to have TCP sequence number analysis
enabled in order to get retransmissions handled; in order to handle
retransmissions, Ethereal would probably have to have a data structure
for each TCP connection it sees, but that means that if you read in a
capture of a SYN flood, and create a data structure for each SYN, you
might run out of memory (that problem was, as I remember, seen in
tcpdump, which allocates a data structure for each TCP connection by
default, in order to support relative sequence numbers), so you want to
have *some* option to control whether to handle retransmissions.
It should also perhaps handle out-of-order data; that might best be
handled in the reassembly code.
