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

Why cannot fully decode NAS field on S1AP protocol?

0

Hi,

can you please help me on the following issue I am having.

Wireshark cannot fully decode NAS field on S1AP protocol. Error (GUI): Unknown-aborting dissection on last few NAS fields

(P.S. WS Windows version decodes NAS fileds just fine!)

Is it a way to attach a small trace file here?

===============================

Platform: HP Proliant DL140 running CentOS 6.5

===============================

[[email protected] scripts]$ wireshark -v wireshark 1.8.10 (SVN Rev Unknown from unknown)

Copyright 1998-2013 Gerald Combs [email protected] and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GTK+ 2.20.1, with Cairo 1.8.8, with Pango 1.28.1, with GLib 2.26.1, with libpcap, with libz 1.2.3, without POSIX capabilities, with SMI 0.4.8, without c-ares, without ADNS, without Lua, without Python, with GnuTLS 2.8.5, with Gcrypt 1.4.5, with MIT Kerberos, without GeoIP, without PortAudio, with AirPcap.

Running on Linux 2.6.32-431.17.1.el6.i686, with locale en_US.UTF-8, with libpcap version 1.4.0, with libz 1.2.3, GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap.

Built using gcc 4.4.7 20120313 (Red Hat 4.4.7-4).

======================

Regards

Valter

asked 06 Jun '14, 05:06

Valpix's gravatar image

Valpix
11114
accept rate: 0%

edited 06 Jun '14, 05:14

You can post your capture somewhere public and share a link to it, e.g. CloudShark, dropbox, Google Drive etc.

(06 Jun '14, 06:03) grahamb ♦

Thanks Graham,

https://www.dropbox.com/s/f3q6utyqwejy5lh/S1AP_cannot_fully_dissect_NAS_selected_3_packets.pcap

For instance if you look at packet #1, inside NAS, there are 3 fields that should be dissected as e.g. EPS Mobility Identity, UE Network Capabilities, ESM Message Container.

Win7 and OSX SW versions decode these fields just fine. Start thinking if it's a bug ... unless someone else can import the trace on CentOS 6.5, lastest WS 1.8.10-7 (downloaded from the official CentOS 6.5 baseline repository) and confirm they can read these fields fine.

Thanks

Valter

(06 Jun '14, 08:29) Valpix

What versions of Wireshark are you running on win 7 and OSX?

(06 Jun '14, 08:32) grahamb ♦

Win7 64bit -- > 1.10.7 (latest stable) OSX Lion -- > 1.6.2 (SVN Rev 38931)

(06 Jun '14, 08:37) Valpix

The current old stable release is 1.8.14. Likely to be a bug in that version. Unfortunately the Centos\Redhat versions seem to move on very slowly.

(06 Jun '14, 08:39) grahamb ♦

Any chance to check what are the corrected bugs between my CentOS version 1.8.10 and the latest stable you are referring 1.8.14? I'd like to see if this S1AP/NAS dissection error is included in the corrections ...

(06 Jun '14, 08:49) Valpix

I have no idea if 1.8.14 has fixes for this issue or not. At the moment we know 1.8.10 doesn't and 1.10.7 does, but there is a lot of changes between those two versions. You could download and install 1.8.14 on your win 7 system and see what happens.

Another factor is that the rpm install isn't built by the Wireshark team, so who knows what is actually in that release.

This page shows all the changes in the dissector, 1.8.10 came out in Oct 2013, but as per the policy, older versions only get serious issues backported, dissector improvements generally aren't backported.

Unfortunately since the change from SVN to Git, I have no idea how to track what actually went into a build these days.

(06 Jun '14, 11:38) grahamb ♦

What specific fields are giving that error for 1.8.10? Is it the whole NAS field in general?

I can't check against it right now but I've got 1.8.6 running on Centos 6 without decoding problems for NAS, though your trace is a bit uncommon (unauthenticated, and accept/complete is unciphered).

(06 Jun '14, 11:48) Quadratic

@Quadratic, I think the OP identified the fields in their comment that added the link to the capture on dropbo; EPS Mobility Identity, UE Network Capabilities, ESM Message Container

(06 Jun '14, 12:04) grahamb ♦

Ah, gotcha. Those fields in general can definitely be decoded in 1.8.6 on Centos 6, though I'll check with that capture file itself...

(06 Jun '14, 12:08) Quadratic

Ok, I can confirm I recreate the same issue with decoding your file on 1.8.10, and when running 1.10.6 the file decodes correctly. I'll now recompile 1.8.14 on Centos 6.2 to confirm if it was fixed at that point.

(06 Jun '14, 12:44) Quadratic
showing 5 of 11 show 6 more comments

2 Answers:

2

It looks like there is a bug affecting Wireshark version 1.8.10. I've tested with your example file on that version as well as 1.8.14 and found the same issue, however when I compile Wireshark 1.10.6 (newest) I do not have that problem.

I suggest compiling 1.10.6 on your Centos server to have the fields decode correctly. I've tested this on Centos 6.4 successfully though I'd be surprised if you have any prerequisite issues on 6.2 (Centos 5 has issues with the GTK prereq but I believe 6.2 would be fine).

answered 06 Jun '14, 13:02

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

Nice the correction is there already and the bug has been spotted! Where can I download the 1.10.6 rpms for my CentOS 6.5 32bit?

(06 Jun '14, 19:12) Valpix
1

That's the tricky part - I don't know if the RPMs themselves exist (Yum repos are incredibly slow for Wireshark) but you can do a manual compile. Latest version's source can be found at: http://wiresharkdownloads.riverbed.com/wireshark/src/wireshark-1.10.7.tar.bz2

From that, off a stock Centos install you can just do a yum install for the prerequisites (gtk2, gtk2-devel, libpcap, libpcap-devel, gcc, bison, flex, and I'm pretty sure that's it). Then just a configure/make/make install.

(06 Jun '14, 20:17) Quadratic

Thanks Quadrantic ...

(08 Jun '14, 17:18) Valpix

2

The regression was introduced between 1.8.8 and 1.8.9 versions with svn revision 50675. This was fixed in 1.10 branch in commit 47218 but I missed the fact that the bug has been introduced in the 1.8 branch.

It means that the whole 1.8.X branch cannot decode properly most 3GPP based messages starting from 1.8.9 and up to 1.8.14.

answered 06 Jun '14, 13:20

Pascal%20Quantin's gravatar image

Pascal Quantin
5.5k1060
accept rate: 30%

Ah, that explains why my 1.8.6 works fine. :)

(06 Jun '14, 14:20) Quadratic

The offending commit has been reverted. Wireshark 1.8.15 will be able to decode those messages again.

(08 Jun '14, 05:24) Pascal Quantin
(08 Jun '14, 10:08) shaun001