Some more input on this matter...
1. ./ethereal -r BigCap.snoop -R wtp
1.1 1052 packets show up
1.2 WTP reassembly not successful (WTP Paload reassembled
in packet 0). I cannot get rid of 1.2 if I reprocess
the capture through Ethereal (e.g., dfilter = frame).
1.3 If Ethereal runs without color filters, then the effect
of a read filter is that the following happens:
for every packet in capture do
process packet (tree defined, pinfo->fd->num == 0)
process packet (tree == NULL**, pinfo->fd->num set)
end for
** If color filters are used, then tree is defined here,
but different from the tree pointer in the 1st step.
The problem is that reassembly (and conversation buildup)
occurs in the FIRST packet processing, but then
pinfo->fd->num is not set!
1.4 Packet count is handled incorrectly in e.g., "save as"
as the captured packet count is set to the read filter
packet count in capture, but when saving to a new file
*all* packets are saved (also the ones *not* matching
the read filter).
2. ./ethereal -r BigCap.snoop ; (choose "wtp" as dfilter)
2.1 1062 packets show up: the 1052 from above PLUS 10 packets
of a new conversation initiated by a conversation after a
WSP Redirect.
2.2 WTP reassembly is successful
2.3 If Ethereal runs without color filters, then the following
happens:
for every packet in capture do
process packet (tree == NULL**, pinfo->fd->num set)
end for
** If color filters are used, then tree is defined here.
2.4 Packet count is handled correctly.
3. If I process the output from 2. through tethereal *without*
a read filter, then the 10 packets from a redirected
conversation show up as "UDP", not as WTP or WTP+WSP.
To summarize, I think that if we solve 1.3 both reassembly
and conversations will get processed correctly when using
a read filter.
Regards,
Olivier
| From: Olivier Biot
|
| I'm struggling with non-TCP reassembly and read filters,
| which do not seem
| to work together. If I read a WAP capture with the "-R wtp"
| read filter,
| then I never get reassembled WTP, as I always get "Reassembled in: 0".
| Additionally, I see that the packets are being pocessed
| twice, once the
| packet has no pinfo->fd->num and then pinfo->fd->num *is* defined.
| this does not happen if I don't use a read filter but only a
| display filter.
|
| It looks like reassembly always requires two passes over the data.
