Wireshark · Ethereal-dev: RE: [Ethereal-dev] Bug in reassembly (WTP-SAR)

["CHARBONNIER Christophe" <christophe.charbonnier@xxxxxxxxxxxx>]

Hi list,

I suggest the following addition in packet-wtp.c for the mentionned problem:

			if (fd_wtp) {
				/* Reassembled */
				reassembled_in = fd_wtp->reassembled_in;
				if (pinfo->fd->num == reassembled_in) {
					/* Reassembled in this very packet:
					 * We can safely hand the tvb to the WSP dissector */
					call_dissector(wsp_handle, wsp_tvb, pinfo, tree);
				} else {
					/* Not reassembled in this packet */
					if (check_col(pinfo->cinfo, COL_INFO)) {
						col_append_fstr(pinfo->cinfo, COL_INFO,
								"%s (WTP payload reassembled in packet %u)",
								szInfo->str, fd_wtp->reassembled_in);
					}
					if (tree) {
						proto_tree_add_text(wtp_tree, tvb, dataOffset, -1,
								"Payload");
					}
				}

/***************************************************************/
              char *reassembled_data = fragment_delete(pinfo, TID, wtp_fragment_table);
              if (reassembled_data)
                g_free(reassembled_data);
/***************************************************************/

			} else {
				/* Not reassembled yet, or not reassembled at all */
				if (check_col(pinfo->cinfo, COL_INFO)) {
					col_append_fstr(pinfo->cinfo, COL_INFO,
								"%s (Unreassembled fragment %u)",
								szInfo->str, psn);
				}
				if (tree) {
					proto_tree_add_text(wtp_tree, tvb, dataOffset, -1,
							"Payload");
				}
			}
			/* Now reset fragmentation information in pinfo */
			pinfo->fragmented = save_fragmented;
		}

That is when something has been reassembled and passed to the upper dissector (WSP), then we delete all the fragments and the reassembled buffer. In that way, if a new transaction with the same fragmentation-key (ie net-address/wtp.tid), no overlapping will occur.

I tested on tethereal only, this works well.
I cannot test on ethereal-GUI (no GTK environnment for compilation), but I'm afraid (I'm sure) this will not work because if we destroy the information, there will be not meaning of surfing over the packets that have been freed...

So this is only a very tethereal-specific workaround, and I guess it's not acceptable as an official ethereal solution.
Christophe

-----Original Message-----
From: Olivier Biot [mailto:ethereal@xxxxxxxxxx] 
Sent: samedi 25 décembre 2004 12:18
To: Ethereal development
Subject: Re: [Ethereal-dev] Bug in reassembly (WTP-SAR)

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
> 


_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev