Hello: 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 |
2 Answers:
I don't see that effect with a sample capture file on Windows with Wireshark 1.10.0
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 answered 03 Jul '13, 15:57  Kurt Knochner ♦ 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 - 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. answered 03 Jul '13, 15:29  Guy Harris ♦♦ edited 03 Jul '13, 15:29 |
can you please add a sample capture file (google docs, dropbox) or a screenshot?
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. :)
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.
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.