Comment # 7
on bug 8462
from Anders Broman
(In reply to comment #5)
> Yes, but it is not quite so simple, since we want to avoid writing extra
> names to the NRB to avoid leaking information. If we just keep name
> resolution data for the lifetime of the file (across multiple dissections)
> then we can end up with stale data getting written to the NRB.
>
You are thinkig of the case where we filter out packets and then write to a new
file and the NRB might have all IP addresses of the original file resolved?
We might offer the option off not dumping NRB:s and settle for this less
elegant "solution".
> It seems to me that the correct way to handle all cases is to associated
> name resolution data with each frame (in the frame_data perhaps) in addition
> to the global hash table. Then base the data in the NRBs according to the
> what is linked from each frame being written (as opposed to just writing
> everything in the hash table).
That might be costly in memory usage, on the other hand the fdata entry could
perhaps be used in the packet list and could be a pointer to the string in the
hastable. For tshark ther would be no gain.
>
> So the frame_data resolutions are cleared on each dissection, but the hash
> table is never cleared. Then when manual resolution occurs, it gets added to
> the hash table, the packet is redissected, and the frame_data name list is
> rebuilt from scratch with only the new information.
You are receiving this mail because:
- You are watching all bug changes.
