Comment # 12
on bug 8647
from Evan Huus
A basic simplification to the man page committed in r49422. Hopefully that will
help the original confusion you had.
(In reply to comment #11)
> (In reply to comment #5)
> > (b) When I employ a second trace (this one illustrating an HTTP
> > conversation), tshark and Excel deliver differing results (and the GUI
> > approach continues to deliver nothing).
>
> I want to blame this on packet reassembly, but I'm not sure which way the
> blame should go - either tshark is being smarter than your manual excel
> process, or it's trying to be smarter and is making a mistake. I'll take a
> closer look.
On a more detailed investigation, I'm a bit confused at what column you're
using to export to text. For example, packet #4:
In Akamai-tcp-src-port-80.txt the time column has a value of 0.000238000 for
that packet, however if I open up Wireshark and look at that packet, the
tcp.time_delta field has value 0.004898000.
If I instead filter on tcp.time_delta==0.000238000 I get two packets, both of
which have a destination port of 80, not a source port of 80.
Can you please double-check your process and make sure you're not splicing
together incorrect fields or filters somewhere?
[Note: I'm running a trunk build, so it's *possible* this is an issue fixed in
trunk, but the difference between 1.10 and trunk right now is very small, so
that seems unlikely].
You are receiving this mail because:
- You are watching all bug changes.