Roger Nichols wrote:
> i am using ethereal 10.5 and have a question on the decode of the following
> 4 packets. (these are a t.38 trace from udp port 17126 to port 56210.) the
> first packet decodes correctly, and is the 2nd to last piece of an ecm
> frame. the 2nd packet has a decode error, which it should. i believe the
> ifp length is wrong. it is reported as 10, but there seems to be a byte
> missing from the ifp indicating the recovery packet type. my question is on
> the 3rd and 4th packets. they do not have a decode error in ethereal, even
> though they contain as recovery/ secondary packets the same ifp which is
> (correctly, i believe) flagged as malformed.
>
> what do you guys think? is there an ethereal decoder bug? or am i missing
> somthing in the 'a' length ifp?
>
> thanks,
> --roger
>
> ps, ive never quite figured out how the hi-lighting works, and i liked the
> decode descriptions better in 10.4, which behaves the same way on these 4
> packets
Hı I havent been able too look at your fıles sınce Im on a vatatıon trip and sıttıng on
an Internet cafe.
But please note that you may have to change preference settıngs for T38 ın Ethereal
(Edıt/Preferences.../Protocols/T38).
There are ıncompatıble ASN.1 specifıcations for T.38 so you have to select the
right one (pre-Corrigendum ıs the default).
Attachment:
packet_1.pcap
Description: Binary data
Attachment:
packet_2.pcap
Description: Binary data
Attachment:
packet_3.pcap
Description: Binary data
Attachment:
packet_4.pcap
Description: Binary data
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users