This is our old Q&A Site. Please post any new questions and answers at

Wireshark 2.2.4 no longer reassembles the V.21 hdlc-data packets and decodes the message type like DIS, CFR, DCS, etc.

Also, if I have a .pcap file of T.38 packets only it shows UDP. When I do the 'decode as' there is no longer a choice to select T.38.

Anyone have a suggestion for a work around?

asked 25 Jan '17, 10:00

mr2872's gravatar image

accept rate: 0%

I don't have a capture file to work with, can you share a capture in a publicly accessible spot, e.g. CloudShark?

(25 Jan '17, 11:06) Jaap ♦

Here are 2 Google Drive links

T38a is the entire capture, the V.21 messages do not display

T38c is just the T.38 packets, the just show UDP and I can no longer do a 'decode as'

(25 Jan '17, 12:16) mr2872

Almost forgot, there is a third issue. On the page data for the fax data pump, packet 967 is the 'reassembled in packet'. Usually I click on 'message fragments' and 'export packet bytes' into a binary file where I can then use utility fax2tiff to view the page. There is no 'message fragments' in Wireshark 2.2.4 for this page data, but when I open the t38a.pcap in an archived version of Wireshark 1.x.x the 'message fragments' are there and I can export the 'packet bytes'.

(27 Jan '17, 07:25) mr2872

Wireshark 2.2.4 no longer reassembles the V.21 hdlc-data packets and decodes the message type like DIS, CFR, DCS, etc.

When I try it with the version on the master branch, it does do reassembly, but what it's not doing is decoding the reassembled data. For example, frame 206 in the t38a capture decodes the "Reassembled T38" as T.30 in 1.12, but just shows it as data in the master branch version of Wireshark. Is that what you meant? (Presumably you meant T.30 rather than V.21 - V.21, "300 BITS PER SECOND DUPLEX MODEM STANDARDIZED FOR USE IN THE GENERAL SWITCHED TELEPHONE NETWORK" is all analog stuff; those modems didn't have to do much fancy stuff with anything HDLC-like.)

(28 Jan '17, 17:34) Guy Harris ♦♦

If your first issue was that the reassembled data wasn't being decoded as T.30, for that issue:

The handoff from T.38 to T.30 was inadvertently broken in Wireshark 2.2; I've fixed it, so the next 2.2.x release should have it.

For your second issue, the lack of T.38 support in Decode As:

The ability to decode as T.38 was inadvertently removed in Wireshark 2.2; I've added it back, so the next 2.2.x release should have it.

For your third issue, the reassembled data not being available to save:

From looking at the capture, frame 399 contains the first chunk of data, with a sequence number of 154. Frame 400 contains the next chunk, with a sequence number of 155; this continues up to frame 435, with a sequence number of 190.

However, frame 401 has a sequence number of 208, not 191; there is no packet in the capture with a sequence number of 191.

I.e., not all the data is available - packets with sequence numbers of 191 through 207 are missing.

1.12 shouldn't have reassembled the packet, but it did do so, at least on the second pass; 2.2.x fixes that. 2.2.x should also be fixed to 1) indicate that the reassembly failed due to missing packets and 2) not say "Reassembled in:", because it wasn't reassembled.

permanent link

answered 28 Jan '17, 17:22

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%

edited 28 Jan '17, 20:56

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 25 Jan '17, 10:00

question was seen: 1,412 times

last updated: 28 Jan '17, 20:56

p​o​w​e​r​e​d by O​S​Q​A