Ethereal-users: Re: [Ethereal-users] h323 decoding problem

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Martin Regner" <martin.regner@xxxxxxxxx>
Date: Fri, 7 Jan 2005 15:48:56 +0100
Romel Khan wrote:
<Lot of h323 messages from Cisco GWs is not being decoded properly and
<is being labeled as Short Frame in ethereal. Calls are getting setup properly
<though and therefore, it seems to be ethereal deconding problem. Cisco is
<passing proprietary GTD information in the h225 encapsulation, which
<ethereal is not supposed to decode. But there are other information
<which ethereal has to be able to decode. See attached.
 
The TPKT header indicates a length of 589 (0x024d) and the User-to-User Information element length is 558 (0x22e), so it seems that part of the TPKT PDU is sent in another frame. There is only 536 bytes sent as TCP payload in the frame you captured.
 
You need to configure Ethereal to do TCP reassembly from Edit/Preferences... menu item:
Edit/Preferences... /Protocols/TCP/Allow subdissector to reassemble TCP streams   (checkbox should be CHECKED)
Edit/Preferences... /Protocols/TCP/Check the validity of the TCP checksum when possible (checkbox should NOT be CHECKED if TCP checksum calculation offloading is used)
 
Edit/Preferences... /Protocols/H225/Reassemble H.225 messages spanning multiple TCP segments   (checkbox should be CHECKED)
Edit/Preferences... /Protocols/Q931/Reassemble Q.931 messages spanning multiple TCP segments   (checkbox should be CHECKED)
Edit/Preferences... /Protocols/TPKT/Reassemble TPKT messages spanning multiple TCP segments   (checkbox should be CHECKED)
 
 
You then need to make a new capture where you don't capture just the first part of the TPKT PDU (you might need to modify your capture filter to do this,
e.g. not filtering on port number)