Hi list,
I got a really interesting capture-file for you (that's my X-mas gift
;-) !!
Look at that: I got a wap-phone that makes a request for a first file
(Amark.jar) (frame 1), the Wap-gateway gives it what it wants (segmented
results until frame 56). Ok, then I shut-down my phone, and power it
back 2 minutes after. I make a new request for a new file (Pinball.jar)
(frame 58). The Wap-gateway gives me what I want (segmented results
until frame 107). But when I look at what ethereal understood, I got bad
surprise: the defragmentation is messed up !
On frame 56, ethereal is lost in the reassembly, taking frames from the
first AND the second file transmission (frame 3 60 5 62 6 63, etc...).
And on frame 107, that is the last packet of my second segmentation,
ethereal thinks the reassembly was done on frame 56, that is not true !!
By looking quickly at packet-wtp.c and reassemble.c, I understood that
when ethereal sees a wtp-fragment, it adds it in a hash-table for
future-defragementation with the TID as an ID:
packet-wtp.c (line 681):
fd_wtp = fragment_add_seq(tvb, dataOffset,
pinfo, TID,
wtp_fragment_table, psn,
dataLen, !fTTR);
When looking inside this function, I understand that the key for the
fragment is constructed upon the given ID + the net-address of the
packet:
reassemble.c (line 1164):
key.src = pinfo->src;
key.dst = pinfo->dst;
key.id = id;
By this mean, frames from the same source-address and with the same TID,
but at a very different period of time, cannot be isolated !!!!
In my case, the thing is my phone (a Nokia 3100) ALWAYS starts from TID
0x01 when powered on (nothing wrong in that !). It's then normal that
ethereal cannot tell a given packet being part of either the first or
the second reassembly !!
Don't you think it would be necessary to base the key for reassembly
also from the tcp/udp tuple of ports ?? If true, is this behavior to be
taken in WTP part or more generally in reassemble routines ??
For my given example, the UDP-port tuple would be 9201/57919 for the
first transaction, and 9201/62381 for the second - then it would be
possible for ethereal to reassemble my 2 transactions.
What do you think of that ??
Merry Christmas anyway !!
Christophe
Attachment:
fragmentation.cap
Description: fragmentation.cap
