Hello Christophe,
You are correct about the issues with the overlapping WTP TID's.
Regarding the proposed solution, I think taking the UDP port (TCP is not
used with WSP, unless you're tunnelling WSP over HTTP or so) in combination
with the WTP transaction identifier (TID) will probably be better. However
many phones *do* use the same source port at every connect (and even after a
redirect).
If we want to use the WDP (UDP when we're using IP as transport) port and
the WTP TID, then we could construct one 32-bit identifier consisting of the
16-bit port and the 15-bit (16th is direction bit) WTP TID. Maybe a more
generic approach would allow us to specify two identifiers (in our case: WDP
port and WTP TID) instead of one for enabling the reassembly.
Best regards,
Olivier
----- Original Message -----
From: CHARBONNIER Christophe
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
--------------------------------------------------------------------------------
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev