[<Cedric.Pillonel@xxxxxxxxxxxx>]

Hi,

Wireshark tells me that some T.38 packets are malformed and I don't see why (perhaps a bug?).
Have a look at the attached trace, for example frames 483, 485, 507, 508, 509.

I have Wireshark 1.0.3 running on RedHat Linux 4, libpcap 0.8.3. I have the same problem on Windows XP with Wireshark1.0.2, WinPCap 4.0.2.

I have tried to decode such a packet myself but I am not a PER expert:

Frame 1985 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Netopia_4b:d8:6c (00:0f:cc:4b:d8:6c), Dst: NmsCommu_32:2a:70 (00:20:22:32:2a:70)
Internet Protocol, Src: 196-130-186-195.bluewin.ch (195.186.130.196), Dst: 192.168.1.26 (192.168.1.26)
User Datagram Protocol, Src Port: 60498 (60498), Dst Port: commtact-http (20002)
    Source port: 60498 (60498)
    Destination port: commtact-http (20002)
    Length: 26
    Checksum: 0xacbd [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
ITU-T Recommendation T.38
    [Stream setup by SDP (frame 1963)]
    UDPTLPacket
        seq-number: 2
        primary-ifp-packet
            type-of-msg: t30-data (1)
                t30-data: v21 (0)
            data-field: 1 item
                Item 0
                    Item
                        field-type: hdlc-data (0)
                        field-data: FF
                        Reassembled in: 2008
        error-recovery: secondary-ifp-packets (0)
            secondary-ifp-packets: 3 items
                Item 0
                    Item
                        type-of-msg: t30-indicator (0)
                            t30-indicator: v21-preamble (3)
                Item 1
                    Item
                        type-of-msg: t30-indicator (0)
                            t30-indicator: no-signal (0)
                Item 2
                    Item
                        type-of-msg: t30-indicator (0)
                            t30-indicator: no-signal (0)
    [MALFORMED PACKET or wrong preference settings]

0000  00 20 22 32 2a 70 00 0f cc 4b d8 6c 08 00 45 28   . "2*p...K.l..E(
0010  00 2e 00 00 40 00 fa 11 78 55 c3 ba 82 c4 c0 a8   ....@...xU......
0020  01 1a ec 52 4e 22 00 1a ac bd 00 02 06 c0 01 80   ...RN"..........
0030  00 00 ff 00 03 01 06 01 00 01 00 00               ............

UDPTL
00
02      sequence number = 2 (coded on 2 octets, range of 64K)
06      ???
c0      1100 0000
        first bit 1 = optional data-field is present
        second bit 1 = choice 1 (t30-data)
        4 bits 0 = enumerated value 0 (v21)
        4 bits 0 = padding
01      1 element in sequence of sequence  (data-field)
80      first bit 1 = field-data is present, 3 next bits 0 = hdlc-data, other bits = padding
00
00      length = 1, constrained whole number coded on 2 octets (n-1 = 0)
ff      data
00      first bit 0 = choice secondary-ifp-packets, other bits = padding
03      semi-constrained whole number, number of elements in sequence of = 3
01      ???
06      ???
01      ???
00      ???
01      ???
00      ???
00      ???

Can someone help me? Is that a bug or what's wrong with that T.38 packet?

Thank you.

Cédric Pillonel

Attachment: t38.pcap
Description: t38.pcap