Wireshark-bugs: [Wireshark-bugs] [Bug 8533] tshark "-T fields" output of bundled SCTP chunks doe
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 05 May 2015 23:12:45 +0000

changed bug 8533


What Removed Added
Version 1.8.4 1.10.2

Comment # 2 on bug 8533 from 
(In reply to Evan Huus from comment #1)
> I suspect we don't want to just print all delimiters by default, since then
> you'd end up with just an enourmous string of delimiters if the field is an
> uncommon one.
> 
> However, if more than one field is being printed it may be worth aligning
> them - the logic for that may not be simple, I haven't looked at the current
> code.
> 
> Bill, CCing you as you were in this code recently (replacing use of
> ep_strbuf if I recall correctly).

Revisiting this. I'd really like to retire my -T text output parser and use -T
fields option instead.

First, let me explain that with SCTP, we are typically dealing with packets
that contain several bundled DATA chunks which each need to be extracted from
the packet for individual analysis. It's quite tedious to troubleshoot with
Wireshark when heavy bundling is occurring. So it is very useful to parse each
chunk out as CSV and dump into a database.

I don't understand why printing the delimiters would be troublesome. The user
can decide when specifying output fields whether they want to deal with long
strings of delimiters for uncommon fields. If the field is not uncommon, you'll
still print the delimiters.

As it is now, if a field isn't relevant for every data chunk, the output of
that field is of questionable value since it becomes very difficult to reliably
match it up with the chunk to which it belongs.

Dealing with long delimiter strings is certainly more efficient than parsing a
dozen or more values per chunk from -T text.

If we consider a different collection of data chunks, I have a single frame
with three chunks and I would parse the following from the -T text output:
+-------+---------------+--------------------+----------------------+------------------------+
| frame | sctp.data-tsn | diamter.Session-Id | diameter.Result-Code |
diameter.Error-Message |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1000          | a                  | 2001                 |          
             |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1001          | b                  | 3002                 | no peer
response       |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1002          | c                  | 3002                 | no
routing rule found  |
+-------+---------------+--------------------+----------------------+------------------------+

parsing -T fields provides this:
+-------+---------------+--------------------+----------------------+------------------------+
| frame | sctp.data-tsn | diamter.Session-Id | diameter.Result-Code |
diameter.Error-Message |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1000          | a                  | 2001                 | no peer
response       |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1001          | b                  | 3002                 | no
routing rule found  |
+-------+---------------+--------------------+----------------------+------------------------+
| 1     | 1002          | c                  | 3002                 |          
             |
+-------+---------------+--------------------+----------------------+------------------------+

The big problem here is when I go to troubleshoot why Session-Id b failed. I'll
go looking for a configuration error that won't exist instead of trying to
figure out why the peer did not respond.

You are receiving this mail because:
  • You are watching all bug changes.