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

Hello:
When I decode a MTP3 section (SS7 with CAMEL-v2 protocol), Wireshark indicate that the SOURCE and DESTINATION Point Code are the same (always is the OPC for both values).
Actually, when you see the decodification part below, you look OK (i.e. OPC and DPC are different).

I observed this error -at least - in this versions: Wireshark-win32-1.8.4, Wireshark-win32-1.8.6 and Wireshark-win32-1.10.0 (last stable version available).

OS: WinXP (5.1.2600)/32 bit.

Regards. Miguel Quintana.

asked 02 Jul '13, 11:46

mquintanap's gravatar image

mquintanap
16225
accept rate: 0%

can you please add a sample capture file (google docs, dropbox) or a screenshot?

(02 Jul '13, 14:12) Kurt Knochner ♦

What MTP3 format are you using (ANSI, ITU, China)? I understand that Wireshark 1.10 has added a heuristic check to decide what point code format to use for MTP3, but you should still be able to manually go to Preferences > Protocols > MTP3 and specify it.

I'm confused by the question though. You say that Wireshark is decoding both OPC and DPC as being the same point code number? Are you putting these in decimal, dot-decimal or is it the same regardless of protocol settings? A picture file would be helpful, as well as the trace and your current MTP3 protocol preference configuration.

You mention Camel phase 2 here. Is there a problem decoding that application at all? How is Camel relevant if we're talking about OPC and DPC values? If there's an issue with the decoding of Camel layer, I believe that dissector is called based on the SSN so if you're using a non-default SSN you may want to check the Preferences > Protocols > Camel section of Wireshark and make sure that the SSN you're using for Camel queries is listed there, otherwise it won't decode properly.

edit: updated to a comment since it's more questions than answers. :)

(02 Jul '13, 15:19) Quadratic

Hello,

Below are the screenshot and the MTP3 preferences. We're using ITU format. In this case, I'm working with a CAMEL v2 trace, this is not relevant like you said (just for tell you the nature of the trace) and there's not problem decoding that part. With an ISUP capture appears the same behaviour. In fact ISUP, CAMEL and others protocols that i'm working are only transported by MTP3.

I thought it could be our MTP2 application who was logging corrupted files; but when I process the same captures (Camel and ISUP) with a Linux Version no problem arises. I will upload some traces soon.

Regards, Miguel.

alt text

alt text

(03 Jul '13, 15:04) mquintanap

Thanks. If you can post a sample capture with that problem I can compare it with my 1.10 install on Windows. I work with MTP traces every day in 1.8 and 1.10 without seeing this issue, though not often in ITU format and usually in the context of M3UA.

(03 Jul '13, 16:27) Quadratic

I don't see that effect with a sample capture file on Windows with Wireshark 1.10.0

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=camel2.pcap

As you say the problem does not show up on Linux, maybe the definition of your columns has somehow changed on Windows.

To check, please right click on the Source and Destination column and then select "Edit Column Details". You should see "Source address" and "Destination address" in the 'Field type'. If that is not the case, please change it to the expected values.

Regards
Kurt

permanent link

answered 03 Jul '13, 15:57

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 03 Jul '13, 15:59

Hello Kurt, Finally that was the problem. For some reason the "Field Type" it was changed. I didn't know that the "Title" it's only a name reference and you can change the "Field Type" and put there any value...

Thanks everyone for your help.

Regards, Miguel Quintana.

(04 Jul '13, 11:17) mquintanap

I'm a little suspicious of the MTP3 dissector code, as it's using global variables - mtp3_addr_dpc and mtp3_addr_opc - in ways that might cause issues.

Please file a bug on this at the Wireshark bugzilla, so that we can track this. (Give the symptoms, not my theory, as the problem; just cite my theory as one possibility.) Upload captures by attaching them to the bug rather than uploading them to Cloudshark or a site such as that. Also re-attach the screenshot to the bug.

permanent link

answered 03 Jul '13, 15:29

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

edited 03 Jul '13, 15:29

Your answer
toggle preview

Follow this question

By Email:

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

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "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:

×21
×16
×6
×4
×2

question asked: 02 Jul '13, 11:46

question was seen: 6,778 times

last updated: 04 Jul '13, 11:17

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