Jeff Morriss
changed
bug 11414
| What |
Removed |
Added |
| CC |
|
jeff.morriss.ws@gmail.com
|
Comment # 6
on bug 11414
from Jeff Morriss
(In reply to Michael Mann from comment #5)
> When this bug can been duplicated, the ICMP request frame has been processed
> twice (so the visited flag is set on the second time it's processed) and the
> ICMP response has not been processed at all. So it seems in live captures,
> processing "every" packet first once can't always apply.
> The GUI must periodically say "these are all the packets I've got, so run a
> second pass on them". If the last packet in that list is an ICMP request,
> the INFO column will list that ICMP the response hasn't been found.
When I first read this I was a bit surprised but it makes perfect sense: if
we're dissecting packets during live capture then it's completely possible that
some frame may be dissected multiple times before the first pass dissection has
been run on some later (response) packet. So the Info column and packet
details may change during the capture. I don't think there's much that can be
done about that. We certainly don't want to go triggering redissections each
time we get a new packet, for example. A more reasonable possibility would be
to trigger redissections of *visible* frames *referenced* from a frame we just
dissected but even that seems like more complication than it's worth...
What is wrong, though, is what is shown in attachment 13788 [details]: that the Packet
Details shows the response but the Info column shows "no response found!"
Shouldn't the packet-details dissection and the Info column be generated in the
same (single) dissection pass? Could there be Info column caching at work
here?
You are receiving this mail because:
- You are watching all bug changes.
