Wireshark-bugs: [Wireshark-bugs] [Bug 8787] 9P dissector - compute fids on first visit
Dominique Martinet
changed
bug 8787
| What |
Removed |
Added |
| Attachment #10975 is obsolete |
|
1
|
Comment # 14
on bug 8787
from Dominique Martinet
Created attachment 11173 [details]
patch build fids on first pass v3
Hope you had fun at sharkfest :)
I'm finally done with my refactoring, so I'm attaching yet another patch that
obsoletes the previous one.
It merges both parsing trees in one as you suggested, and renames most
variables that had "always" been here into more sensible names.
I don't have anything to test it right now short of the attachment pcap sample
in the previous bug, but it looks like it works -- I'll run further tests on
thursday and friday, I use wireshark/9P quite a bit ;)
(By the way, since we already had a build issue due to a different version of
gcc, there's a dubious cast from "const char*" to "void*" for
emem_tree_insert32 that discards the const attribute and I'm surprised this
works. I think the insert function really doesn't do anything to the pointer
and honestly doubt it'll cause any real problem, but shout if it or anything
else doesn't build)
The last thing I noticed recently is that if there's a huge amount of data, the
TCP packets will contain multiple 9P messages (they're normally split as
there's a one-request one-reply correspondance, but multiple simultaneous
requests/replies get aggregated).
Is there an easy way to tell the upper layer we'd like to split, or maybe run
the dissector again (like we call the data dissector for read/writes) ?
It will probably mean I need yet another index for my fid tree though.. Oh,
well, this isn't something I'm in such a hurry to fix, and it's been here since
day one, so I guess it can wait another patch altogether.
Thanks again for your time!
You are receiving this mail because:
- You are watching all bug changes.
