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.
Attachment:
packet-t38.c.patch
Description: Binary data