Viewing a trace of an SNA RJE transmisssion, SNA over UDP. Many packets decode with the error message above. I believe the issue is with an Optional Segment, a status segment in the RTP Transport section. The odd thing is that another user at the vendor uses Wireshark and can view the trace without this issue. The port being used is 12000 - 12004. I've tried to "Decode As" and specify SNA, but it does not have this option for "transport". I've tried RTP and LLC, neither work. asked 31 Mar '14, 10:59  dwsmithjr edited 31 Mar '14, 10:59 showing 5 of 14 show 9 more comments |
One Answer:
If you assume it is the same capture file, I would double-check the following things
Regards answered 02 Apr '14, 14:43  Kurt Knochner ♦ Sorry for the delay. I appreciate the responses. The security policies of the bank will not allow me to post even one packet of the trace. Recently a guy "disappeared" for violating policy. So, I'll see what I can do with what you guys have provided and will post again. (04 Apr '14, 09:54) dwsmithjr |
So you say another user can look at the same packet without this problem? What is your wireshark Version and Operating System? Can you paste a small sample here or to http://cloudshark.org ?
We are both using 1.10.6 on Windows 7, 64bit version. I'll have to see if I can get permission to post a picture.
These are images of the relevant portion of the same packet. The top is decoding properly, the bottom shows the error.
"We are both using 1.10.6 on Windows 7, 64bit version." IP and SNA both have preferences controlling whether to do re-assembly; do both of your versions of Wireshark have the same settings for the IP and SNA preferences?
"I've tried to "Decode As" and specify SNA" Wireshark is already decoding them as SNA, so that wouldn't make a difference.
Does this packet format ok with your wireshark: https://www.cloudshark.org/captures/d12e6090e938 ?
Guy, Yes, SNA was not a choice in the Decode As. Since we were using ports 12000 - 12004, I thought I might have to indicate to Wireshark these ports were SNA. That is what I had to do with my other Protocol Analyzer, Observer. However, Wireshark was already showing the SNA portion, so, as you say, it would not have done any good anyway.
Guy, I'll check the preferences when I get into work this morning and post. I'll have to check with the other user, who is remote, to check the preferences.
mrEEde, I work for a bank which is paranoid about security. I have to be very careful about anything that goes out of the bank. Although the packet does not, as far as I can determine, contain any information that is readable and pertains to customer information, that is a huge, huge concern. I'd like to keep my job, so I don't think I can post the packet as a whole.
mrEEde, I'll check the packet when I get to work and see if it decodes.
mrEEde, the packet DOES display correctly in my Wireshark at work. It does not display as a malformed packet.
Could you paste the frame section indicating the lengths and ethernet mac addresses as well as ip.len and udp.length please ?
We haven't heard anything back from you, so here's another suggestion:
If this capture file is the result of a conversion using IPCS could you try converting with OPTION((SNIFFER(1500 TCPDUMP))) and see if this makes a difference.