Ask Your Question
0

Auto Decoding of H.225 and H.245 from H.323 captures

asked 2017-10-30 22:55:09 +0000

Cameron gravatar image

updated 2017-10-30 22:56:04 +0000

For some reason, I cannot figure out the magic of getting Wireshark to auto decode H.225 and H.245 from H.323 captures. I am running 2.4.2 [latest].

Sometimes Wireshark does figure it out on it's own and shows the port TCP:1720 H.225 decoding, and also the TCP:dynamic-port H.245 decoding, but just as often as it succeeds, it does not.

The best way to test this is to try the Wireshark Wiki sample H.323 capture, found here: https://wiki.wireshark.org/SampleCapt...
https://wiki.wireshark.org/SampleCapt... [direct file link]

If somebody [or Gerald, bless him], could explain how to get this to operate reliably, I would be quite appreciative.

Regards, Cameron Elliott

edit retag flag offensive close merge delete

Comments

Your question is a little light on detail. What happens when you look at the referenced file? Does it show H.225 / H.245. If yes, what file does not? If no, do you see at least TPKT after TCP? What happens when you add TCP port 1720 to the TPKT dissector preferences?

Jaap gravatar imageJaap ( 2017-10-31 06:37:42 +0000 )edit

Jaap, Thank you for your response. All I see is packets decoded as TCP. With the defaults of 102/102 in the TPKT dissector I see the following: http://take.ms/iZPLz I tried changing the two settings to the following 1720/102, 102/1720, and 1720/1720, no combination causes H225, H245 decoding

Cameron gravatar imageCameron ( 2017-10-31 07:42:30 +0000 )edit

> no combination causes H225, H245 decoding no combination causes H225, H245 decoding *of what*. What file are you referring to? Certainly not the one from SampleCaptures, or are you? Remember, we' can't see your capture, nor magically guess what's going on.

Jaap gravatar imageJaap ( 2017-10-31 09:44:49 +0000 )edit

Yes, the image I linked to is the file from SampleCaptures, that is why I am so puzzled.

Cameron gravatar imageCameron ( 2017-10-31 10:16:41 +0000 )edit

Is this a single instance of Wireshark? Are you using different profiles? is TPKT enabled in all of them?

Jaap gravatar imageJaap ( 2017-10-31 11:04:36 +0000 )edit

Okay Jaap, thanks for your help and persistence. I have located the issue. Here is how to reproduce the issue in WS 2.4.2, likely older versions also:

  1. Install WS 2.4.2 on a new system OR delete the WS user config files found in APPDATA\Wireshark prior to opening WS.
  2. This will give you a fairly good baseline for testing.
  3. Download 'rtp_sample.pcap' from https://wiki.wireshark.org/SampleCapt...
  4. Open 'rtp_sample.pcap' with WS
  5. You will see both H225 and H245 level decoding of TCP sessions
  6. This is how I accidentally broke H225 and H245 decoding:
  7. To break H225/H245 dedode: Enable all protocols via Analyze>Enabled Protocols...>Enable all>OK
  8. You will see that H225/H245 decoding has disappeared
  9. It seems the only way to get the Enabled Protocols selections back to default is to delete APPDATA\Wireshark [when WS is closed].

Suggested fix: Create a 'Restore to ...(more)

Cameron gravatar imageCameron ( 2017-10-31 19:44:45 +0000 )edit
add a comment

1 Answer

Sort by ยป oldest newest most voted
0

answered 2017-10-31 20:31:09 +0000

Jaap gravatar image

Have you gone to "Edit | Configuration Profiles ..."? There you have a list of profiles on your installation. The three buttons below this list allow you to manipulate these profiles (Create, Remove, Copy). The three standard profiles cannot be removed, but they can be deleted. What's the difference, you might ask? Well, once a standard profile is deleted, it's recreated with default values. Problem solved?

edit flag offensive delete link more

Comments

To me the important question is not how to restore the user settings to defaults, but to understand why does displaying of H225 and H245 break when "Analyze>Enabled Protocols...>Enable all>OK" is applied.

Cameron gravatar imageCameron ( 2017-10-31 21:02:42 +0000 )edit

That is because there are some (very) greedy dissectors in there. These are disabled by default (obviously) but once enable can throw off the dissection of normal captures (those not containing the protocols expected by those greedy dissectors).

Jaap gravatar imageJaap ( 2017-11-01 09:38:47 +0000 )edit

Oh! one last thing, sometimes, I must enable the following to get correct H.323/H.225 decoding working.

a. right click on an particular H.225 packet, and enable "Try heuristic sub-dissectors first"

This has sometimes been the missing part for me to get H.225 of H.323 over TCP working.

Cameron gravatar imageCameron ( 2019-12-12 02:11:51 +0000 )edit
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

4 followers

subscribe to rss feed

Stats

Asked: 2017-10-30 22:55:09 +0000

Seen: 3,131 times

Last updated: Dec 12 '19