[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	11306
Summary	Error dissecting TCP/SMPP packets | Invalid SMPP Operations statistics
Product	Wireshark
Version	1.12.6
Hardware	x86
OS	Windows 7
Status	UNCONFIRMED
Severity	Major
Priority	High
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	aristotelis.metsinis@gmail.com

Created attachment 13688 [details]
"smpp operations" - 1.12.6 & 1.10.14 versions

Build Information:
$ wireshark -v
wireshark 1.10.14 (v1.10.14-0-g825f971 from master-1.10)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> 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 (64-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with
PortAudio V19-devel (built May 12 2015), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
       Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, with 3969MB of physical
memory.


Built using Microsoft Visual C++ 10.0 build 40219

--
Overview: 

I have taken a "tcp" dump (of about 3 min) containing "tcp/smpp" traffic. Based
on application logs and later parsing the "pcap" file "manually", I was
expecting about 280K "submit_sm" PDUs and about the same number of
"submit_sm-resp" PDUs. However, when checking "smpp operations" statistics, it
showed me an unexpected list of results. "wireshark" version is 1.12.6 (64bit).
On the other hand, using an older version such as the 1.10.14 (64bit), the
"smpp operations" statistics showed me the "expected" list of results ! On top
of these, the behavior of "decode as" option seems "unexpected" even in the
case of 1.10.14 "wireshark" version.

1. Details concerning version 1.12.6 (64bit) as well as of older versions like
1.12.6 (32bit), 1.12.0 (64bit) and 1.11.0 (64bit).

   1.1. "wireshark" loaded a "tcp" trace (pcap) file consisting of 103,118
"tcp/smpp" packets.

   1.2. "wireshark" did NOT understand automatically "tcp/smpp" protocol PDUs.
So, checking "smpp operations" statistics, it showed me a list with all
operations = 0.

   1.3. Due to this, I had to set the "decode as" option to "transport tcp |
port 10000 as smpp". Then, checking again "smpp operations" statistics, it
showed me a list with "unexpected" results, for example: "sumbmit_sm" requests
= 0 although "tcp" trace file consisted of about 280K of those as mentioned !
Have a look at the attached doc and look for "1.12.6.jpg" screenshot. 

   1.4. by making use of "tshark" command line tool, it showed me the
statistics mentioned above in point # 1.3. That is, defining "–d" option
(decode as) for "tcp" port 10000 to decode as "smpp", I got the following list
of "unexpected" results: 

  
==================================================================================================
   SM_PP Operations:
   Topic / Item             Count  Average Min val Max val Rate (ms) Percent
Burst rate Burst start  
  
--------------------------------------------------------------------------------------------------
   SMPP Operations          278775                         1.4944    100%   
9.5800     70.532       
    SMPP Responses          278744                         1.4942    99.99% 
9.5800     70.532       
     Submit_sm - resp       278653                         1.4937    99.97% 
9.5800     70.532       
     Enquire_link - resp    91                             0.0005    0.03%  
0.0300     2.783        
    SMPP Requests           31                             0.0002    0.01%  
0.0100     5.901        
     Enquire_link           31                             0.0002    100.00%
0.0100     5.901        
   SMPP Response Status     278744                         1.4942    100%   
9.5800     70.532       
    Ok                      278660                         1.4938    99.97% 
9.5800     70.532       
    Invalid source address  84                             0.0005    0.03%  
0.0300     25.372       

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

2. Details concerning version 1.10.14 (64bit) as well as of older versions like
1.10.0 (64bit) and 1.6.5 (32bit).

   2.1. "wireshark" loaded a "tcp" trace (pcap) file consisting of 103,118
"tcp/smpp" packets (same number as above in point # 1.1).

   2.2. "wireshark" understood automatically "tcp/smpp" protocol PDUs. So,
checking "smpp operations" statistics, it showed me a list with "expected"
results. Have a look at the attached doc and look for "1.10.14.not_decoded.jpg"
screenshot.

   2.3. setting also the "decode as" option to "transport tcp | port 10000 as
smpp" and then checking again "smpp operations" statistics, it showed me a list
with "unexpected" results, for example: "submit_sm" requests = 0 although "tcp"
trace file consisted of about 280K of those as mentioned (i.e. results similar
to the ones mentioned in point # 1.3 above) ! Have a look at the attached doc
and look for "1.10.14.decoded.jpg" screenshot.

   2.4.1. by making use of "tshark" command line tool, it showed me the
statistics mentioned above in point # 2.2. That is, without defining "–d"
option (decode as) for "tcp" port 10000 to decode as "smpp", I got the
following list of "expected" results:

   $ tshark.exe -r dump.pcap -q -z smpp_commands,tree

   ===================================================================
    SM_PP Operations               value           rate         percent
   -------------------------------------------------------------------
   SMPP Operations            557497       2.988454
     SMPP Requests              278753       1.494251          50.00%
      Submit_sm                  278661       1.493758          99.97%
      Enquire_link                   92       0.000493           0.03%
     SMPP Responses             278744       1.494203          50.00%
      Submit_sm - resp           278653       1.493715          99.97%
      Enquire_link - resp            91       0.000488           0.03%
    SMPP Response Status         278744       1.494203
     Ok                           278660       1.493752          99.97%
     Invalid source address           84       0.000450           0.03%

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

   2.4.2. while defining "–d" option (decode as) for "tcp" port 10000 to decode
as "smpp", I got the following list of "unexpected" results, which are similar
to the ones found in point # 1.4 above: 

   $ tshark.exe -r dump.pcap -q -z smpp_commands,tree -d tcp.port==10000,smpp

   ===================================================================
    SM_PP Operations               value           rate         percent
   -------------------------------------------------------------------
    SMPP Operations            278775       1.494380
     SMPP Requests                  31       0.000166           0.01%
      Enquire_link                   31       0.000166         100.00%
     SMPP Responses             278744       1.494214          99.99%
      Submit_sm - resp           278653       1.493726          99.97%
      Enquire_link - resp            91       0.000488           0.03%
    SMPP Response Status         278744       1.494214
     Ok                           278660       1.493764          99.97%
     Invalid source address           84       0.000450           0.03%

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

3. Conclusion

So, something might have broken (completely) after the 1.10.14 version (> =
1.11). However, it seems that there was already a bug/error taking into
consideration the “decode as/smpp operations” behavior and results in the older
version(s) also.

---

      You are receiving this mail because:

• You are watching all bug changes.