Comment # 7
on bug 12855
from Michael Mann
(In reply to Pascal Quantin from comment #6)
> For both cases, 2.0.5 behavior seems better (as discussed in Gerrit I'm not
> a fan of the reassembly happening despite missing packets).
> Maybe that's why previous code was not simple ;)
> IMHO the Follow TCP stream feature should not rely on the upper dissector
> having TCP reassembly activated / supported or not.
> Not sure how to move forward. Obviously the current handling needs more
> work, and the previous code was working fine for those use cases. Should we
> revert the change until a more solid version is available? Michael, what's
> your opinion?
I'd really not like to revert if we can avoid it. My two big issues with the
previous implementation are:
1. Duplicate logic of TCP behavior/dissector.
2. Use of temporary file to collect streams (which doesn't perform as well as
the tap interface)
While the TCP dissector isn't my favorite to modify, I really didn't like
having TCP logic in 2 places. It sounds like both have their bugs, but I'd
like to continue trying to fix the bugs of the new implementation.
There are certainly some good "test cases" here, but should we start with
trying to compile as many "test cases" as possible (and maybe add them to the
test suite)? From there we could compare the output and fix the differences in
the new implementation.
You are receiving this mail because:
- You are watching all bug changes.
