----- Original Message -----
From: "Martin Regner"
| Sudhakar Godithi wrote in
| http://www.ethereal.com/lists/ethereal-users/200401/msg00102.html:
| > Problem i am getting is Ethereal not recognising the TPKT Header
present
| > in the IFP,
| >
| > Its treating TPKT as IFP starting and decoing the TPKT Header
with T.38.
|
| The original T.38 specifications doesn't specify that TPKT is to be
used
| over TCP, so there is implementations
| that are sending T.38 IFP packets directly over TCP as well as
| implementations that are sending T.38 IFP
| packets over TPKT over TCP.
|
| I have made a patch to support both T.38IFP/TCP and T38IFP/TPKT/TCP.
|
| There is one new preference setting tpkt_usage where you can specify
if TPKT
| header is used. With the default setting (tpkt_usage=Maybe) the
dissector
| will look on the first four octets and try to determine if TPKT is
used or
| not. This setting seems to work well with the captures I have tried,
| but there might be some scenarios where it will be better to set the
value
| to 'Always' or 'Never' dependant on if TPKT header is used or not.
|
| There is also a new preference setting regarding TCP desegmentation.
TCP
| desegmentation is currently only supported when TPKT header
| is used.
| You will need to set the preference setting "Allow subdisectors to
desegment
| TCP streams" for TCP and also the "Desegment all TPKT
| messages spanning multiple TCP segments" for TPKT if you want to use
this
| feature. I don't have any T.38 captures with segmented packets
| so I have not been able to test this so much.
|
| The patch also includes some other changes:
|
| -Support for T.38 (2002) ASN.1 specification
|
http://www.itu.int/ITU-T/asn1/database/itu-t/t/t38/2003/T38(2002).html
| Note: This ASN.1 specification is incompatible with the
Pre-Corigendum T.38
| ASN.1 specification (1998) so you will need to set the preference
setting
| accordingly.
|
| -When there are extra octets after the T.38 UDPTL packet you will
now see
| [Malformed?] in the Info-column. I thought that it
| was quite irritating that non-T.38 packets could look like they were
| correctly coded T.38 packets.
|
| -There might be several T.38 IFP packets in a TCP packet for the
T.38
| directly over TCP scenario. There is now at least some support for
this, but
| since
| TCP desegmentation is only supported for the TPKT scenario this will
not
| work if an IFP packet is splitted into several TCP packets.
Checked in, along with a comment fix and t38_tpkt_options declared
static as no-one else is using it.
Regards,
Olivier
