2018-06-18 11:01:31 -07:00
#
# Wireshark tests
# By Gerald Combs <gerald@wireshark.org>
#
2018-11-20 16:27:56 +01:00
# Copyright (c) 2018 Peter Wu <peter@lekensteyn.nl>
#
2018-06-18 11:01:31 -07:00
# SPDX-License-Identifier: GPL-2.0-or-later
#
''' sharkd tests '''
import json
import subprocess
2023-06-04 23:03:30 +01:00
import pytest
2018-11-20 16:27:56 +01:00
from matchers import *
2018-06-18 11:01:31 -07:00
2023-06-04 23:03:30 +01:00
@pytest.fixture ( scope = ' session ' )
2018-11-13 02:17:33 +01:00
def cmd_sharkd ( program ) :
return program ( ' sharkd ' )
2023-06-04 23:03:30 +01:00
@pytest.fixture
def run_sharkd_session ( cmd_sharkd , base_env ) :
2018-11-20 16:27:56 +01:00
def run_sharkd_session_real ( sharkd_commands ) :
2023-06-04 23:03:30 +01:00
sharkd_proc = subprocess . Popen (
( cmd_sharkd , ' - ' ) , stdin = subprocess . PIPE , stdout = subprocess . PIPE , stderr = subprocess . PIPE , encoding = ' utf-8 ' , env = base_env )
sharkd_proc . stdin . write ( ' \n ' . join ( sharkd_commands ) )
stdout , stderr = sharkd_proc . communicate ( )
2018-11-20 16:27:56 +01:00
2023-06-04 23:03:30 +01:00
assert ' Hello in child. ' in stderr
2018-11-20 16:27:56 +01:00
outputs = [ ]
2023-06-04 23:03:30 +01:00
for line in stdout . splitlines ( ) :
2018-11-20 16:27:56 +01:00
line = line . strip ( )
if not line :
continue
try :
jdata = json . loads ( line )
except json . JSONDecodeError :
2023-06-04 23:03:30 +01:00
pytest . fail ( ' Invalid JSON: %r ' % line )
2018-11-20 16:27:56 +01:00
outputs . append ( jdata )
return tuple ( outputs )
return run_sharkd_session_real
2023-06-04 23:03:30 +01:00
@pytest.fixture
def check_sharkd_session ( run_sharkd_session ) :
2018-11-20 16:27:56 +01:00
def check_sharkd_session_real ( sharkd_commands , expected_outputs ) :
sharkd_commands = [ json . dumps ( x ) for x in sharkd_commands ]
actual_outputs = run_sharkd_session ( sharkd_commands )
2023-06-04 23:03:30 +01:00
assert expected_outputs == actual_outputs
2018-11-20 16:27:56 +01:00
return check_sharkd_session_real
2023-06-04 23:03:30 +01:00
class TestSharkd :
2018-11-20 16:27:56 +01:00
def test_sharkd_req_load_bad_pcap ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' non-existant.pcap ' ) }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " error " : { " code " : - 2001 , " message " : " Unable to open the file " } } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2023-02-28 10:04:37 -05:00
def test_sharkd_req_load_truncated_pcap ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' trunc.pcap ' ) }
} ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " Less data was read than was expected " , " err " : - 12 } } ,
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_status_no_pcap ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " status " } ,
2018-11-20 16:27:56 +01:00
) , (
2024-03-25 13:58:54 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " frames " : 0 , " duration " : 0.000000000 , " columns " : [ " No. " , " Time " , " Source " , " Destination " , " Protocol " , " Length " , " Info " ] ,
" column_info " : [ {
2024-09-11 14:26:14 +02:00
" title " : " No. " , " format " : " % m " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Time " , " format " : " % t " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Source " , " format " : " %s " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Destination " , " format " : " %d " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Protocol " , " format " : " % p " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Length " , " format " : " % L " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Info " , " format " : " %i " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} ]
} } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_status ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " status " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " frames " : 4 , " duration " : 0.070345000 ,
2023-02-19 01:55:21 +00:00
" filename " : " dhcp.pcap " , " filesize " : 1400 ,
2024-03-25 13:58:54 -04:00
" columns " : [ " No. " , " Time " , " Source " , " Destination " , " Protocol " , " Length " , " Info " ] ,
" column_info " : [ {
2024-09-11 14:26:14 +02:00
" title " : " No. " , " format " : " % m " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Time " , " format " : " % t " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Source " , " format " : " %s " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Destination " , " format " : " %d " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Protocol " , " format " : " % p " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Length " , " format " : " % L " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} , {
2024-09-11 14:26:14 +02:00
" title " : " Info " , " format " : " %i " , " visible " : True , " display " : " R "
2024-03-25 13:58:54 -04:00
} ]
} } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_analyse ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " analyse " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " frames " : 4 , " protocols " : [ " frame " , " eth " , " ethertype " , " ip " , " udp " ,
" dhcp " ] , " first " : 1102274184.317452908 , " last " : 1102274184.387798071 } } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_info ( self , check_sharkd_session ) :
matchTapNameList = MatchList (
{ " tap " : MatchAny ( str ) , " name " : MatchAny ( str ) } )
2023-08-21 10:11:24 -04:00
matchNameDescriptionList = MatchList (
{ " name " : MatchAny ( str ) , " description " : MatchAny ( str ) } )
2018-11-20 16:27:56 +01:00
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " info " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : {
2018-11-20 16:27:56 +01:00
" version " : MatchAny ( str ) ,
" columns " : MatchList ( { " format " : MatchAny ( str ) , " name " : MatchAny ( str ) } ) ,
" stats " : matchTapNameList ,
" convs " : matchTapNameList ,
" eo " : matchTapNameList ,
" srt " : matchTapNameList ,
" rtd " : matchTapNameList ,
" seqa " : matchTapNameList ,
" taps " : matchTapNameList ,
" follow " : matchTapNameList ,
" ftypes " : MatchList ( MatchAny ( str ) ) ,
2023-08-21 10:11:24 -04:00
" capture_types " : matchNameDescriptionList ,
" encap_types " : matchNameDescriptionList ,
2018-11-20 16:27:56 +01:00
" nstat " : matchTapNameList ,
2021-06-20 17:07:28 +01:00
} } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_check ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " check " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " check " , " params " : { " filter " : " garbage filter " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " check " , " params " : { " field " : " garbage field " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " check " , " params " : { " filter " : " ip " , " field " : " ip " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 5001 , " message " : " Filter invalid - \" filter \" was unexpected in this context. " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " error " : { " code " : - 5002 , " message " : " Field garbage field not found " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : { " status " : " OK " } } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_complete_field ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " complete " } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " complete " , " params " : { " field " : " frame.le " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " complete " , " params " : { " field " : " garbage.nothing.matches " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " field " : MatchList (
2024-09-12 14:20:55 +02:00
{ " f " : " frame.len " , " t " : 7 , " n " : " Frame Length " } , match_element = any ) }
2021-06-20 17:07:28 +01:00
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " field " : [ ] } } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_req_complete_pref ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " complete " , " params " : { " pref " : " tcp. " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " complete " , " params " : { " pref " : " garbage.nothing.matches " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " pref " : MatchList (
{ " f " : " tcp.check_checksum " , " d " : " Validate the TCP checksum if possible " } , match_element = any ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " pref " : [ ] } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_frames ( self , check_sharkd_session , capture_file ) :
# XXX need test for optional input parameters, ignored/marked/commented
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frames " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " :
2018-11-20 16:27:56 +01:00
MatchList ( {
" c " : MatchList ( MatchAny ( str ) ) ,
" num " : MatchAny ( int ) ,
" bg " : MatchAny ( str ) ,
" fg " : MatchAny ( str ) ,
2021-06-20 17:07:28 +01:00
} )
} ,
2018-11-20 16:27:56 +01:00
) )
sharkd: Fix displayed delta times in "frames" method
As noted in #17923, commit c4731738 broke timereferences and displayed
delta time (`frame.time_delta_displayed`) in the `frames` method of
`sharkd`. This commit adds back to `sharkd_session_process_frames`
the local variables `prev_dis_num`, `current_ref_frame` and
`ref_frame` which are used to determine the `frame_ref_num` and
`prev_dis_num` arguments to each call to `sharkd_dissect_request` in
the main loop of `sharkd_session_process_frames`.
Below is an example on `master` (`b7cc44eb34`, specifically) of a
`frames` request for packets 1 and 800 of the capture
`./test/captures/logistics_multicast.pcapng` where we ask for columns
`frame.time_relative`, `frame.time_delta` and
`frame.time_delta_displayed`:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","0.193716000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is `0.193716000`, which is time difference between it and packet 799,
not packet 1.
Compare this to the same `frames` request using the changes from this
commit:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","191.872111000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is now `191.872111000`, the time difference between it and packet 1.
This is the expected value since only packets 1 and 800 are visible
due to the request's `filter` parameter.
A new `test_sharkd_req_frames_delta_times` unit test has been added to
verify this fix and prevent it the bug from being accidentally
sneaking in again. If this fix is accepted, this change should
probably be cherry-picked to the `release-4.2` branch.
Fixes #17923.
2023-11-07 10:51:21 -05:00
def test_sharkd_req_frames_delta_times ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' logistics_multicast.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frames " , " params " : { " filter " : " frame.number==1||frame.number==800 " , " column0 " : " frame.time_relative:1 " , " column1 " : " frame.time_delta:1 " , " column2 " : " frame.time_delta_displayed:1 " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " :
[
epan: various time-related cleanups and impreovements.
Have routines to calculate, for a frame:
* the time relative to the first frame in the capture;
* the time relative to the previous reference frame or, if there is
none, the first frame in the capture;
* the time relative to the previous captured frame;
* the time relative to the previous displayed frame.
That centralizes the determination of which frame that is, so that if we
want to change the rule for determining that (e.g., if we decide to
change to "relative to the previous XXX frame *that has a time stamp*),
we only need to change it in one place.
When computing relative times, make sure both the current frame and the
frame from which a relative time is being computed exist, and, if not,
indicate that the relative time is missing (even if we set its value to
zero).
Don't display relative times (whether relative to the first frame, the
most recent reference frame, the previous captured frame, or the
previous displayed frame) that don't, in fact, exists; omit the protocol
tree field, and show a blank in the time column.
Remove a ws_debug message in epan_get_frame_ts() if we can't get the
frame time stamp, as that may just mean it didn't *have* a time stamp.
When sorting columns by time, make non-existent times - which display as
blank - sort to the top.
Note, in comments, some issues found while doing this.
Update tests as appropriate for the first packet not having a "time
since previous packet" value. This includes adding some packets to
nfs.pcap, from the same file whence they originally came (with times
shifted), with additional time shifting to make all tests doable.
2025-05-08 16:49:24 -07:00
{ " c " : [ " 0.000000000 " , " " , " " ] , " num " : 1 , " bg " : " feffd0 " , " fg " : " 12272e " } ,
sharkd: Fix displayed delta times in "frames" method
As noted in #17923, commit c4731738 broke timereferences and displayed
delta time (`frame.time_delta_displayed`) in the `frames` method of
`sharkd`. This commit adds back to `sharkd_session_process_frames`
the local variables `prev_dis_num`, `current_ref_frame` and
`ref_frame` which are used to determine the `frame_ref_num` and
`prev_dis_num` arguments to each call to `sharkd_dissect_request` in
the main loop of `sharkd_session_process_frames`.
Below is an example on `master` (`b7cc44eb34`, specifically) of a
`frames` request for packets 1 and 800 of the capture
`./test/captures/logistics_multicast.pcapng` where we ask for columns
`frame.time_relative`, `frame.time_delta` and
`frame.time_delta_displayed`:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","0.193716000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is `0.193716000`, which is time difference between it and packet 799,
not packet 1.
Compare this to the same `frames` request using the changes from this
commit:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","191.872111000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is now `191.872111000`, the time difference between it and packet 1.
This is the expected value since only packets 1 and 800 are visible
due to the request's `filter` parameter.
A new `test_sharkd_req_frames_delta_times` unit test has been added to
verify this fix and prevent it the bug from being accidentally
sneaking in again. If this fix is accepted, this change should
probably be cherry-picked to the `release-4.2` branch.
Fixes #17923.
2023-11-07 10:51:21 -05:00
{ " c " : [ " 191.872111000 " , " 0.193716000 " , " 191.872111000 " ] , " num " : 800 , " bg " : " feffd0 " , " fg " : " 12272e " } ,
] ,
} ,
) )
2024-05-31 11:35:26 -04:00
def test_sharkd_req_frames_comments ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' comments.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frames " , " params " : { " filter " : " frame.number==3||frame.number==4||frame.number==5 " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " :
[
{ " c " : [ " 3 " , " 0.610021 " , " :: " , " ff02::1:ffdc:6277 " , " ICMPv6 " , " 78 " , " Neighbor Solicitation for fe80::c2c1:c0ff:fedc:6277 " ] , " num " : 3 , " ct " : True , " comments " : [ " hello hello " ] , " bg " : " fce0ff " , " fg " : " 12272e " } ,
{ " c " : [ " 4 " , " 0.760023 " , " :: " , " ff02::1:ffdc:6277 " , " ICMPv6 " , " 78 " , " Neighbor Solicitation for fec0::c2c1:c0ff:fedc:6277 " ] , " num " : 4 , " ct " : True , " comments " : [ " goodbye goodbye " ] , " bg " : " fce0ff " , " fg " : " 12272e " } ,
{ " c " : [ " 5 " , " 0.802338 " , " 10.0.0.1 " , " 224.0.0.251 " , " MDNS " , " 138 " , " Standard query response 0x0000 A, cache flush 10.0.0.1 PTR, cache flush Cisco29401.local NSEC, cache flush Cisco29401.local " ] , " num " : 5 , " bg " : " daeeff " , " fg " : " 12272e " }
] ,
} ,
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_tap_invalid ( self , check_sharkd_session , capture_file ) :
# XXX Unrecognized taps result in an empty line, modify
# run_sharkd_session such that checking for it is possible.
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " garbage tap " } } ,
2023-08-16 13:36:52 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " tap " , " params " : { " tap0 " : " conv:Ethernet " , " filter " : " garbage filter " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 32600 , " message " : " Mandatory parameter tap0 is missing " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 11012 , " message " : " sharkd_session_process_tap() garbage tap not recognized " } } ,
2023-08-16 13:36:52 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " error " : { " code " : - 11013 , " message " : " sharkd_session_process_tap() name=conv:Ethernet error=Filter \" garbage filter \" is invalid - \" filter \" was unexpected in this context. " } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_tap ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " conv:Ethernet " , " tap1 " : " endpt:TCP " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 32600 , " message " : " Mandatory parameter tap0 is missing " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
2018-11-20 16:27:56 +01:00
" taps " : [
{
" tap " : " endpt:TCP " ,
" type " : " host " ,
" proto " : " TCP " ,
" geoip " : MatchAny ( bool ) ,
" hosts " : [ ] ,
} ,
{
" tap " : " conv:Ethernet " ,
" type " : " conv " ,
" proto " : " Ethernet " ,
" geoip " : MatchAny ( bool ) ,
" convs " : [
{
" saddr " : MatchAny ( str ) ,
" daddr " : " Broadcast " ,
" txf " : 2 ,
" txb " : 628 ,
" rxf " : 0 ,
" rxb " : 0 ,
" start " : 0 ,
" stop " : 0.070031 ,
" filter " : " eth.addr==00:0b:82:01:fc:42 && eth.addr==ff:ff:ff:ff:ff:ff " ,
} ,
{
" saddr " : MatchAny ( str ) ,
" daddr " : MatchAny ( str ) ,
" rxf " : 0 ,
" rxb " : 0 ,
" txf " : 2 ,
" txb " : 684 ,
" start " : 0.000295 ,
" stop " : 0.070345 ,
" filter " : " eth.addr==00:08:74:ad:f1:9b && eth.addr==00:0b:82:01:fc:42 " ,
}
] ,
} ,
]
2021-06-20 17:07:28 +01:00
} } ,
2018-11-20 16:27:56 +01:00
) )
2023-02-28 15:16:26 -05:00
def test_sharkd_req_tap_rtp_streams ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' sip-rtp.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " rtp-streams " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " rtp-analyse:200.57.7.204_8000_200.57.7.196_40376_0xd2bd4e3e " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" taps " : [ {
" tap " : " rtp-streams " ,
" type " : " rtp-streams " ,
" streams " : [ {
" ssrc " : " 0xd2bd4e3e " ,
" payload " : " g711A " ,
" saddr " : " 200.57.7.204 " ,
" sport " : 8000 ,
" daddr " : " 200.57.7.196 " ,
" dport " : 40376 ,
2023-08-07 14:17:59 -04:00
" start_time " : 8.479371 ,
" duration " : 24.124055 ,
2023-02-28 15:16:26 -05:00
" pkts " : 548 ,
2023-08-07 14:17:59 -04:00
" lost " : 0 ,
" lost_percent " : 0.0 ,
2023-02-28 15:16:26 -05:00
" max_delta " : 5843.742000 ,
2023-08-07 14:17:59 -04:00
" min_delta " : 0.159 ,
" mean_delta " : 44.102477 ,
" min_jitter " : 0.388213 ,
2023-02-28 15:16:26 -05:00
" max_jitter " : 7.406751 ,
" mean_jitter " : 2.517173 ,
" expectednr " : 548 ,
" totalnr " : 548 ,
" problem " : False ,
" ipver " : 4
} ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " :
{ " taps " : [ {
" tap " : " rtp-analyse:200.57.7.204_8000_200.57.7.196_40376_0xd2bd4e3e " ,
" type " : " rtp-analyse " ,
" ssrc " : " 0xd2bd4e3e " ,
" max_delta " : 5843.742000 ,
" max_delta_nr " : 168 ,
" max_jitter " : 7.406751 ,
" mean_jitter " : 2.517173 ,
" max_skew " : 319.289000 ,
" total_nr " : 548 ,
" seq_err " : 0 ,
" duration " : 24124.055000 ,
" items " : MatchAny ( )
} ]
} } ,
) )
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
def test_sharkd_req_tap_phs ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' protohier-with-comments.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " phs " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " load " ,
" params " : { " file " : capture_file ( ' protohier-without-comments.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " tap " , " params " : { " tap0 " : " phs " } } ,
2023-08-16 13:36:52 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " tap " , " params " : { " tap0 " : " phs " , " filter " : " ipv6 " } } ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" taps " : [ {
" tap " : " phs " ,
" type " : " phs " ,
" filter " : " " ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " frame " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 115 ,
" bytes " : 22186 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " eth " ,
" frames " : 115 ,
" bytes " : 22186 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " ipv6 " ,
" frames " : 39 ,
" bytes " : 7566 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " icmpv6 " ,
" frames " : 36 ,
" bytes " : 3684
} , {
" proto " : " udp " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 3 ,
2024-09-22 10:21:01 -04:00
" bytes " : 3882 ,
" protos " : [ {
" proto " : " data " ,
" frames " : 3 ,
" bytes " : 3882
} ]
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
2024-09-22 10:21:01 -04:00
} , {
" proto " : " ip " ,
" frames " : 70 ,
" bytes " : 14260 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " udp " ,
" frames " : 60 ,
" bytes " : 13658 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " mdns " ,
" frames " : 1 ,
" bytes " : 138
} , {
" proto " : " ssdp " ,
" frames " : 30 ,
" bytes " : 8828
} , {
" proto " : " nbns " ,
" frames " : 20 ,
" bytes " : 2200
} , {
" proto " : " nbdgm " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
" bytes " : 248 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " smb " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
" bytes " : 248 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " mailslot " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
2024-09-22 10:21:01 -04:00
" bytes " : 248 ,
" protos " : [ {
" proto " : " browser " ,
" frames " : 1 ,
" bytes " : 248
} ]
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} ]
2024-09-22 10:21:01 -04:00
} , { " proto " : " dhcp " ,
" frames " : 4 ,
" bytes " : 1864
} , {
" proto " : " dns " ,
" frames " : 4 ,
" bytes " : 380
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
2024-09-22 10:21:01 -04:00
} , {
" proto " : " igmp " ,
" frames " : 10 ,
" bytes " : 602
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} , {
2024-09-22 10:21:01 -04:00
" proto " : " arp " ,
" frames " : 6 ,
" bytes " : 360
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} ]
} ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : {
" taps " : [ {
" tap " : " phs " ,
" type " : " phs " ,
" filter " : " " ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " frame " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 115 ,
" bytes " : 22186 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " eth " ,
" frames " : 115 ,
" bytes " : 22186 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " ipv6 " ,
" frames " : 39 ,
" bytes " : 7566 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " icmpv6 " ,
" frames " : 36 ,
" bytes " : 3684
} , {
" proto " : " udp " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 3 ,
2024-09-22 10:21:01 -04:00
" bytes " : 3882 ,
" protos " : [ {
" proto " : " data " ,
" frames " : 3 ,
" bytes " : 3882
} ]
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
2024-09-22 10:21:01 -04:00
} , {
" proto " : " ip " ,
" frames " : 70 ,
" bytes " : 14260 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " udp " ,
" frames " : 60 ,
" bytes " : 13658 ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " mdns " ,
" frames " : 1 ,
" bytes " : 138
} , {
" proto " : " ssdp " ,
" frames " : 30 ,
" bytes " : 8828
} , {
" proto " : " nbns " ,
" frames " : 20 ,
" bytes " : 2200
} , {
" proto " : " nbdgm " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
" bytes " : 248 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " smb " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
" bytes " : 248 ,
" protos " : [ {
2024-09-22 10:21:01 -04:00
" proto " : " mailslot " ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
" frames " : 1 ,
2024-09-22 10:21:01 -04:00
" bytes " : 248 ,
" protos " : [ {
" proto " : " browser " ,
" frames " : 1 ,
" bytes " : 248
} ]
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} ]
2024-09-22 10:21:01 -04:00
} , { " proto " : " dhcp " ,
" frames " : 4 ,
" bytes " : 1864
} , {
" proto " : " dns " ,
" frames " : 4 ,
" bytes " : 380
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
2024-09-22 10:21:01 -04:00
} , {
" proto " : " igmp " ,
" frames " : 10 ,
" bytes " : 602
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} , {
2024-09-22 10:21:01 -04:00
" proto " : " arp " ,
" frames " : 6 ,
" bytes " : 360
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
} ]
} ]
} ]
} ]
} } ,
2023-08-16 13:36:52 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : {
" taps " : [ {
" tap " : " phs " ,
" type " : " phs " ,
" filter " : " ipv6 " ,
" protos " : [ {
" bytes " : 7566 ,
" frames " : 39 ,
2024-09-22 10:21:01 -04:00
" proto " : " frame " ,
2023-08-16 13:36:52 -04:00
" protos " : [ {
" bytes " : 7566 ,
" frames " : 39 ,
2024-09-22 10:21:01 -04:00
" proto " : " eth " ,
2023-08-16 13:36:52 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" bytes " : 7566 ,
" frames " : 39 ,
" proto " : " ipv6 " ,
2023-08-16 13:36:52 -04:00
" protos " : [ {
2024-09-22 10:21:01 -04:00
" bytes " : 3684 ,
" frames " : 36 ,
" proto " : " icmpv6 "
} , {
2023-08-16 13:36:52 -04:00
" bytes " : 3882 ,
" frames " : 3 ,
2024-09-22 10:21:01 -04:00
" proto " : " udp " ,
" protos " : [ {
" bytes " : 3882 ,
" frames " : 3 ,
" proto " : " data "
} ]
2023-08-16 13:36:52 -04:00
} ]
} ]
} ]
} ]
} ]
} } ,
sharkd: Add phs tap to sharkd
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
2023-08-09 11:51:20 -04:00
) )
sharkd: add voip-calls and voip-convs taps
Add `voip-calls` and `voip-convs` taps to `sharkd`, which provide the
same information as the `Telephony -> VoIP Calls` GUI menu item. The
`voip-convs` tap accepts an optional comma-separated list of call ID's
allowing the caller to limit which conversations are returned. Both a
single call ID or a `<start>-<end>` call ID range is accepted. For
example, `voip-convs:` returns all conversations, `voip-convs:123`
returns only the conversation with call ID 123 and
`voip-convs:1,5-7,9` returns conversations with call ID's 1, 5, 6, 7
and 9. The call ID for a conversation is returned in the `call`
field. The set of call ID's requested by the caller is stored in a
bit-array which, on a standard Linux amd64 machine, supports storing a
maximum of 65536 call ID's.
Because many of the taps initialized by `voip_calls_init_all_taps` are
not able to be built without it, a basic CLI-based implementation of
`simple_dialog` which prints to `stderr` has been added in
`ui/cli/simple_dialog.c`.
2023-08-11 09:14:50 -04:00
def test_sharkd_req_tap_voip_calls ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' sip-rtp.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " voip-calls " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" taps " : [ {
" tap " : " voip-calls " ,
" type " : " voip-calls " ,
" calls " : [ {
" call " : 0 ,
" start_time " : 0.000000 ,
2023-08-22 09:47:17 -04:00
" stop_time " : 8.524137 ,
sharkd: add voip-calls and voip-convs taps
Add `voip-calls` and `voip-convs` taps to `sharkd`, which provide the
same information as the `Telephony -> VoIP Calls` GUI menu item. The
`voip-convs` tap accepts an optional comma-separated list of call ID's
allowing the caller to limit which conversations are returned. Both a
single call ID or a `<start>-<end>` call ID range is accepted. For
example, `voip-convs:` returns all conversations, `voip-convs:123`
returns only the conversation with call ID 123 and
`voip-convs:1,5-7,9` returns conversations with call ID's 1, 5, 6, 7
and 9. The call ID for a conversation is returned in the `call`
field. The set of call ID's requested by the caller is stored in a
bit-array which, on a standard Linux amd64 machine, supports storing a
maximum of 65536 call ID's.
Because many of the taps initialized by `voip_calls_init_all_taps` are
not able to be built without it, a basic CLI-based implementation of
`simple_dialog` which prints to `stderr` has been added in
`ui/cli/simple_dialog.c`.
2023-08-11 09:14:50 -04:00
" initial_speaker " : " 200.57.7.195 " ,
" from " : " <sip:200.57.7.195:55061;user=phone> " ,
" to " : " \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> " ,
" protocol " : " SIP " ,
" packets " : 5 ,
" state " : " IN CALL " ,
" comment " : " INVITE 200 "
} , {
" call " : 1 ,
" start_time " : 24.665953 ,
2023-08-22 09:47:17 -04:00
" stop_time " : 24.692752 ,
sharkd: add voip-calls and voip-convs taps
Add `voip-calls` and `voip-convs` taps to `sharkd`, which provide the
same information as the `Telephony -> VoIP Calls` GUI menu item. The
`voip-convs` tap accepts an optional comma-separated list of call ID's
allowing the caller to limit which conversations are returned. Both a
single call ID or a `<start>-<end>` call ID range is accepted. For
example, `voip-convs:` returns all conversations, `voip-convs:123`
returns only the conversation with call ID 123 and
`voip-convs:1,5-7,9` returns conversations with call ID's 1, 5, 6, 7
and 9. The call ID for a conversation is returned in the `call`
field. The set of call ID's requested by the caller is stored in a
bit-array which, on a standard Linux amd64 machine, supports storing a
maximum of 65536 call ID's.
Because many of the taps initialized by `voip_calls_init_all_taps` are
not able to be built without it, a basic CLI-based implementation of
`simple_dialog` which prints to `stderr` has been added in
`ui/cli/simple_dialog.c`.
2023-08-11 09:14:50 -04:00
" initial_speaker " : " 200.57.7.195 " ,
" from " : " \" Ivan Alizade \" <sip:5514540002@200.57.7.195:55061;user=phone> " ,
" to " : " \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> " ,
" protocol " : " SIP " ,
" packets " : 3 ,
" state " : " CALL SETUP " ,
" comment " : " INVITE "
} ]
} ]
} } ,
) )
def test_sharkd_req_tap_voip_convs ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' sip-rtp.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " voip-convs: " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " voip-convs:0 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " tap " , " params " : { " tap0 " : " voip-convs:0-1 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " tap " , " params " : { " tap0 " : " voip-convs:garbage " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " method " : " tap " , " params " : { " tap0 " : " voip-convs:999 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " method " : " tap " , " params " : { " tap0 " : " voip-convs:0,999,0-1,999-999,1,1 " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" taps " : [ {
" tap " : " voip-convs: " ,
" type " : " voip-convs " ,
" convs " : [ {
" frame " : 1 ,
" call " : 0 ,
" time " : " 0.000000 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723 g711U) " ,
" comment " : " SIP INVITE From: <sip:200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12013223@200.57.7.195 CSeq:1 "
} , {
" frame " : 2 ,
" call " : 0 ,
" time " : " 0.007889 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 3 ,
" call " : 0 ,
" time " : " 0.047524 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} , {
" frame " : 6 ,
" call " : 0 ,
" time " : " 8.477925 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 200 Ok SDP (g711A g711U GSM iLBC speex telephone-event) " ,
" comment " : " SIP Status 200 Ok "
} , {
" frame " : 7 ,
" call " : 0 ,
" time " : " 8.479371 " ,
" dst_addr " : " 200.57.7.196 " ,
" dst_port " : 40376 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 8000 ,
" label " : " RTP (g711A) " ,
" comment " : " RTP, 548 packets. Duration: 24.12s SSRC: 0xD2BD4E3E "
} , {
" frame " : 10 ,
" call " : 0 ,
" time " : " 8.524137 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " ACK " ,
" comment " : " SIP Request INVITE ACK 200 CSeq:1 "
} , {
" frame " : 352 ,
" call " : 1 ,
" time " : " 24.665953 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723) " ,
" comment " : " SIP INVITE From: \" Ivan Alizade \" <sip:5514540002@200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12015624@200.57.7.195 CSeq:1 "
} , {
" frame " : 353 ,
" call " : 1 ,
" time " : " 24.674680 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 354 ,
" call " : 1 ,
" time " : " 24.692752 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
" taps " : [ {
" tap " : " voip-convs:0 " ,
" type " : " voip-convs " ,
" convs " : [ {
" frame " : 1 ,
" call " : 0 ,
" time " : " 0.000000 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723 g711U) " ,
" comment " : " SIP INVITE From: <sip:200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12013223@200.57.7.195 CSeq:1 "
} , {
" frame " : 2 ,
" call " : 0 ,
" time " : " 0.007889 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 3 ,
" call " : 0 ,
" time " : " 0.047524 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} , {
" frame " : 6 ,
" call " : 0 ,
" time " : " 8.477925 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 200 Ok SDP (g711A g711U GSM iLBC speex telephone-event) " ,
" comment " : " SIP Status 200 Ok "
} , {
" frame " : 7 ,
" call " : 0 ,
" time " : " 8.479371 " ,
" dst_addr " : " 200.57.7.196 " ,
" dst_port " : 40376 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 8000 ,
" label " : " RTP (g711A) " ,
" comment " : " RTP, 548 packets. Duration: 24.12s SSRC: 0xD2BD4E3E "
} , {
" frame " : 10 ,
" call " : 0 ,
" time " : " 8.524137 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 , " label " : " ACK " , " comment " : " SIP Request INVITE ACK 200 CSeq:1 "
} ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : {
" taps " : [ {
" tap " : " voip-convs:0-1 " ,
" type " : " voip-convs " ,
" convs " : [ {
" frame " : 1 ,
" call " : 0 ,
" time " : " 0.000000 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723 g711U) " ,
" comment " : " SIP INVITE From: <sip:200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12013223@200.57.7.195 CSeq:1 "
} , {
" frame " : 2 ,
" call " : 0 ,
" time " : " 0.007889 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 3 ,
" call " : 0 ,
" time " : " 0.047524 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} , {
" frame " : 6 ,
" call " : 0 ,
" time " : " 8.477925 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 200 Ok SDP (g711A g711U GSM iLBC speex telephone-event) " ,
" comment " : " SIP Status 200 Ok "
} , {
" frame " : 7 ,
" call " : 0 ,
" time " : " 8.479371 " ,
" dst_addr " : " 200.57.7.196 " ,
" dst_port " : 40376 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 8000 ,
" label " : " RTP (g711A) " ,
" comment " : " RTP, 548 packets. Duration: 24.12s SSRC: 0xD2BD4E3E "
} , {
" frame " : 10 ,
" call " : 0 ,
" time " : " 8.524137 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " ACK " ,
" comment " : " SIP Request INVITE ACK 200 CSeq:1 "
} , {
" frame " : 352 ,
" call " : 1 ,
" time " : " 24.665953 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723) " ,
" comment " : " SIP INVITE From: \" Ivan Alizade \" <sip:5514540002@200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12015624@200.57.7.195 CSeq:1 "
} , {
" frame " : 353 ,
" call " : 1 ,
" time " : " 24.674680 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 354 ,
" call " : 1 ,
" time " : " 24.692752 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " error " : {
" code " : - 11014 , " message " : " sharkd_session_process_tap() voip-convs=voip-convs:garbage invalid ' convs ' parameter "
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " result " : {
" taps " : [ {
" tap " : " voip-convs:999 " ,
" type " : " voip-convs " ,
" convs " : [ ]
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " result " : {
" taps " : [ {
" tap " : " voip-convs:0,999,0-1,999-999,1,1 " ,
" type " : " voip-convs " ,
" convs " : [ {
" frame " : 1 ,
" call " : 0 ,
" time " : " 0.000000 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723 g711U) " ,
" comment " : " SIP INVITE From: <sip:200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12013223@200.57.7.195 CSeq:1 "
} , {
" frame " : 2 ,
" call " : 0 ,
" time " : " 0.007889 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 3 ,
" call " : 0 ,
" time " : " 0.047524 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} , {
" frame " : 6 ,
" call " : 0 ,
" time " : " 8.477925 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 200 Ok SDP (g711A g711U GSM iLBC speex telephone-event) " ,
" comment " : " SIP Status 200 Ok "
} , {
" frame " : 7 ,
" call " : 0 ,
" time " : " 8.479371 " ,
" dst_addr " : " 200.57.7.196 " ,
" dst_port " : 40376 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 8000 ,
" label " : " RTP (g711A) " ,
" comment " : " RTP, 548 packets. Duration: 24.12s SSRC: 0xD2BD4E3E "
} , {
" frame " : 10 ,
" call " : 0 ,
" time " : " 8.524137 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " ACK " ,
" comment " : " SIP Request INVITE ACK 200 CSeq:1 "
} , {
" frame " : 352 ,
" call " : 1 ,
" time " : " 24.665953 " ,
" dst_addr " : " 200.57.7.204 " ,
" dst_port " : 5061 ,
" src_addr " : " 200.57.7.195 " ,
" src_port " : 5060 ,
" label " : " INVITE SDP (g711A g729 g723) " ,
" comment " : " SIP INVITE From: \" Ivan Alizade \" <sip:5514540002@200.57.7.195:55061;user=phone> To: \" francisco@bestel.com \" <sip:francisco@bestel.com:55060> Call-ID:12015624@200.57.7.195 CSeq:1 "
} , {
" frame " : 353 ,
" call " : 1 ,
" time " : " 24.674680 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 100 Trying " ,
" comment " : " SIP Status 100 Trying "
} , {
" frame " : 354 ,
" call " : 1 ,
" time " : " 24.692752 " ,
" dst_addr " : " 200.57.7.195 " ,
" dst_port " : 5060 ,
" src_addr " : " 200.57.7.204 " ,
" src_port " : 5061 ,
" label " : " 180 Ringing " ,
" comment " : " SIP Status 180 Ringing "
} ]
} ]
} } ,
) )
2023-09-18 14:28:48 -04:00
def test_sharkd_req_tap_hosts ( self , check_sharkd_session , capture_file ) :
matchAddrNameList = MatchList (
{ " name " : MatchAny ( str ) , " addr " : MatchAny ( str ) } )
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dns-mdns.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " tap " , " params " : { " tap0 " : " hosts: " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " hosts:ip " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " tap " , " params " : { " tap0 " : " hosts:ipv4 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " tap " , " params " : { " tap0 " : " hosts:ipv6 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " method " : " tap " , " params " : { " tap0 " : " hosts:invalid " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " method " : " tap " , " params " : { " tap0 " : " hosts:ipv4,ipv6 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 8 , " method " : " tap " , " params " : { " tap0 " : " hosts:ipv4,ipv6,invalid " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" taps " : [ {
" tap " : " hosts: " ,
" type " : " hosts " ,
" ipv4_hosts " : matchAddrNameList ,
" ipv6_hosts " : matchAddrNameList ,
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
" taps " : [ {
" tap " : " hosts:ip " ,
" type " : " hosts " ,
" ipv4_hosts " : matchAddrNameList ,
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : {
" taps " : [ {
" tap " : " hosts:ipv4 " ,
" type " : " hosts " ,
" ipv4_hosts " : matchAddrNameList ,
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : {
" taps " : [ {
" tap " : " hosts:ipv6 " ,
" type " : " hosts " ,
" ipv6_hosts " : matchAddrNameList ,
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " error " : { " code " : - 11015 , " message " : " sharkd_session_process_tap() hosts=hosts:invalid invalid ' protos ' parameter " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " result " : {
" taps " : [ {
" tap " : " hosts:ipv4,ipv6 " ,
" type " : " hosts " ,
" ipv4_hosts " : matchAddrNameList ,
" ipv6_hosts " : matchAddrNameList ,
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 8 , " error " : { " code " : - 11015 , " message " : " sharkd_session_process_tap() hosts=hosts:ipv4,ipv6,invalid invalid ' protos ' parameter " } } ,
) )
2023-08-17 16:12:13 -04:00
def test_sharkd_req_tap_eo_http ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " setconf " ,
" params " : { " name " : " tcp.reassemble_out_of_order " , " value " : " true " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " load " ,
2023-08-17 16:12:13 -04:00
" params " : { " file " : capture_file ( ' http-ooo.pcap ' ) }
} ,
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " eo:http " } } ,
2023-08-17 16:12:13 -04:00
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
2023-08-17 16:12:13 -04:00
" taps " : [ {
" tap " : " eo:http " ,
" type " : " eo " ,
" proto " : " HTTP " ,
" objects " : [ {
2025-03-02 13:50:17 -05:00
" pkt " : 4 ,
" filename " : " 1 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_0 " ,
2025-03-02 13:50:17 -05:00
" len " : 4 ,
" sha1 " : " 83f5a5c359f3dc8317519240e32f1f51f68bc051 "
2023-08-17 16:12:13 -04:00
} , {
2025-03-02 13:50:17 -05:00
" pkt " : 10 ,
" filename " : " 3 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_1 " ,
2025-03-02 13:50:17 -05:00
" len " : 6 ,
" sha1 " : " a214ad86e2def05fcb0f4c878dfebe5a6041fb7e "
2023-08-17 16:12:13 -04:00
} , {
2025-03-02 13:50:17 -05:00
" pkt " : 11 ,
" filename " : " 4 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_2 " ,
" len " : 5 ,
2025-03-02 13:50:17 -05:00
" sha1 " : " 4a4121ecd766ed16943a0c7b54c18f743e90c3f6 "
} , {
" pkt " : 15 ,
" filename " : " 5 " ,
" _download " : " eo:http_3 " ,
" len " : 4 ,
" sha1 " : " 580393f5a94fb469585f5dd2a6859a4aab899f37 " } ]
2023-08-17 16:12:13 -04:00
} ]
} }
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_follow_bad ( self , check_sharkd_session , capture_file ) :
# Unrecognized taps currently produce no output (not even err).
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " follow " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " follow " ,
" params " : { " follow " : " garbage follow " , " filter " : " ip " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " follow " ,
" params " : { " follow " : " HTTP " , " filter " : " garbage filter " }
} ,
sharkd: Improve sub-stream support in "frame" and "follow" methods
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
2024-04-23 14:29:10 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " follow " ,
" params " : { " follow " : " HTTP " , " filter " : " http " , " sub_stream " : " garbage sub_stream " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 32600 , " message " : " Mandatory parameter follow is missing " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 12001 , " message " : " sharkd_session_process_follow() follower=garbage follow not found " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 ,
" error " : { " code " : - 12002 , " message " : " sharkd_session_process_follow() name=HTTP error=Filter \" garbage filter \" is invalid - \" filter \" was unexpected in this context. " }
} ,
sharkd: Improve sub-stream support in "frame" and "follow" methods
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
2024-04-23 14:29:10 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 ,
" error " : { " code " : - 32600 , " message " : " The data type for member sub_stream is not valid " }
} ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_follow_no_match ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " follow " ,
" params " : { " follow " : " HTTP " , " filter " : " ip " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 ,
" result " : { " shost " : " NONE " , " sport " : " 0 " , " sbytes " : 0 ,
" chost " : " NONE " , " cport " : " 0 " , " cbytes " : 0 }
} ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_follow_udp ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " follow " ,
" params " : { " follow " : " UDP " , " filter " : " frame.number==1 " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 ,
" result " : {
2018-11-20 16:27:56 +01:00
" shost " : " 255.255.255.255 " , " sport " : " 67 " , " sbytes " : 272 ,
" chost " : " 0.0.0.0 " , " cport " : " 68 " , " cbytes " : 0 ,
" payloads " : [
2021-06-20 17:07:28 +01:00
{ " n " : 1 , " d " : MatchRegExp ( r ' AQEGAAAAPR0A[a-zA-Z0-9] {330} AANwQBAwYq/wAAAAAAAAA= ' ) } ] }
} ,
2018-11-20 16:27:56 +01:00
) )
2024-06-01 02:25:05 +01:00
def test_sharkd_req_follow_http2 ( self , check_sharkd_session , capture_file , features ) :
# If we don't have nghttp2, we output the compressed headers.
# We could test against the expected output in that case, but
# just skip for now.
if not features . have_nghttp2 :
pytest . skip ( ' Requires nghttp2. ' )
2025-01-09 07:45:40 -05:00
if not features . have_brotli :
pytest . skip ( ' Requires brotli. ' )
2024-06-01 02:25:05 +01:00
sharkd: Improve sub-stream support in "frame" and "follow" methods
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
2024-04-23 14:29:10 -04:00
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' quic-with-secrets.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " follow " ,
" params " : { " follow " : " HTTP2 " , " filter " : " tcp.stream eq 0 and http2.streamid eq 1 " , " sub_stream " : 1 }
} ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 ,
" result " : {
" shost " : " 2606:4700:10::6816:826 " , " sport " : " 443 " , " sbytes " : 656 ,
" chost " : " 2001:db8:1::1 " , " cport " : " 57098 " , " cbytes " : 109643 ,
" payloads " : [
{ " n " : 12 , " d " : MatchRegExp ( r ' ^.*VuLVVTLGVuO3E9MC45Cgo.*$ ' ) } ,
{ " n " : 19 , " s " : 1 , " d " : MatchRegExp ( r ' ^.*7IG1hPTg2NDAwCgo.*$ ' ) } ,
{ " n " : 44 , " s " : 1 , " d " : MatchRegExp ( r ' ^.*Pgo8L2h0bWw.*$ ' ) } ,
] }
} ,
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_iograph_bad ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " iograph " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " iograph " ,
" params " : { " graph0 " : " garbage graph name " }
} ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " iograph " ,
" params " : { " graph0 " : " max:udp.length " , " filter0 " : " udp.length " , " interval " : 0 } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " iograph " ,
" params " : { " graph0 " : " max:udp.length " , " filter0 " : " udp.length " , " interval_units " : " garbage units " } } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 32600 , " message " : " Mandatory parameter graph0 is missing " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " iograph " : [ ] } } ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " error " : { " code " : - 32600 , " message " : " The value for interval must be a positive integer " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " error " : { " code " : - 7003 , " message " : " Invalid interval_units parameter: ' garbage units ' , must be ' s ' , ' ms ' or ' us ' " } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_iograph_basic ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " iograph " ,
2021-06-20 17:07:28 +01:00
" params " : { " graph0 " : " max:udp.length " , " filter0 " : " udp.length " }
} ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " iograph " ,
2021-06-20 17:07:28 +01:00
" params " : { " graph0 " : " packets " , " graph1 " : " bytes " }
} ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " iograph " ,
2021-06-20 17:07:28 +01:00
" params " : { " graph0 " : " packets " , " filter0 " : " garbage filter " }
} ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " iograph " ,
" params " : { " graph0 " : " packets " , " graph1 " : " bytes " , " interval " : 1 , " interval_units " : " us " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " method " : " iograph " ,
" params " : { " graph0 " : " packets " , " graph1 " : " bytes " , " interval " : 1 , " interval_units " : " ms " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " method " : " iograph " ,
" params " : { " graph0 " : " packets " , " graph1 " : " bytes " , " interval " : 1 , " interval_units " : " s " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
sharkd: Support microsecond intervals in "iograph" method
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
2024-04-25 14:52:26 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " iograph " : [ { " items " : [ 308.000000 ] } ] } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " iograph " : [ { " items " : [ 4.000000 ] } , { " items " : [ 1312.000000 ] } ] } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " error " : { " code " : - 6001 , " message " : " Filter \" garbage filter \" is invalid - \" filter \" was unexpected in this context. " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : { " iograph " : [
{ " items " : [ 1.0 , ' 127 ' , 1.0 , ' 1118f ' , 1.0 , ' 112c9 ' , 1.0 ] } ,
{ " items " : [ 314.0 , ' 127 ' , 342.0 , ' 1118f ' , 314.0 , ' 112c9 ' , 342.0 ] } ,
] } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " result " : { " iograph " : [
{ " items " : [ 2.0 , ' 46 ' , 2.0 ] } ,
{ " items " : [ 656.0 , ' 46 ' , 656.0 ] } ,
] } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " result " : { " iograph " : [
{ " items " : [ 4.0 ] } ,
{ " items " : [ 1312.0 ] } ,
] } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_intervals_bad ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " intervals " ,
" params " : { " filter " : " garbage filter " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 7001 , " message " : " Invalid filter parameter: garbage filter " } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_intervals_basic ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " intervals " } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " intervals " ,
" params " : { " interval " : 1 }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " intervals " ,
" params " : { " filter " : " frame.number <= 2 " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " intervals " : [ [ 0 , 4 , 1312 ] ] , " last " : 0 , " frames " : 4 , " bytes " : 1312 } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " intervals " : [ [ 0 , 2 , 656 ] , [ 70 , 2 , 656 ] ] , " last " : 70 , " frames " : 4 , " bytes " : 1312 } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : { " intervals " : [ [ 0 , 2 , 656 ] ] , " last " : 0 , " frames " : 2 , " bytes " : 656 } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_frame_basic ( self , check_sharkd_session , capture_file ) :
# XXX add more tests for other options (ref_frame, prev_frame, columns, color, bytes, hidden)
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frame " ,
" params " : { " frame " : 2 }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
sharkd: Improve sub-stream support in "frame" and "follow" methods
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
2024-04-23 14:29:10 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" fol " : [ [ " UDP " , " udp.stream eq 1 " ] ] ,
" followers " : [ { " protocol " : " UDP " , " filter " : " udp.stream eq 1 " , " stream " : 1 } ]
} } ,
) )
def test_sharkd_req_frame_http2 ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' quic-with-secrets.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frame " ,
" params " : { " frame " : 12 }
} ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" fol " : [ [ " HTTP2 " , " tcp.stream eq 0 and http2.streamid eq 1 " ] , [ " TCP " , " tcp.stream eq 0 " ] , [ " TLS " , " tcp.stream eq 0 " ] ] ,
" followers " : [
{ " protocol " : " HTTP2 " , " filter " : " tcp.stream eq 0 and http2.streamid eq 1 " , " stream " : 0 , " sub_stream " : 1 } ,
{ " protocol " : " TCP " , " filter " : " tcp.stream eq 0 " , " stream " : 0 } ,
{ " protocol " : " TLS " , " filter " : " tcp.stream eq 0 " , " stream " : 0 } ,
]
} } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_frame_proto ( self , check_sharkd_session , capture_file ) :
# Check proto tree output (including an UTF-8 value).
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frame " ,
" params " : { " frame " : 2 , " proto " : True }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " :
2018-11-20 16:27:56 +01:00
MatchObject ( {
" tree " : MatchList ( {
" l " : " Dynamic Host Configuration Protocol (Offer) " ,
" t " : " proto " ,
" f " : " dhcp " ,
2023-08-16 10:24:44 -04:00
" fn " : " dhcp " ,
2018-11-20 16:27:56 +01:00
" e " : MatchAny ( int ) ,
" n " : MatchList ( {
2017-11-02 08:45:18 +01:00
" l " : " Padding: 0000000000000000000000000000000000000000000000000000 " ,
2018-11-20 16:27:56 +01:00
" h " : [ 316 , 26 ] ,
2023-08-16 10:24:44 -04:00
" f " : " dhcp.option.padding == 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 " ,
" fn " : " dhcp.option.padding "
2018-11-20 16:27:56 +01:00
} , match_element = any ) , # match one element from 'n'
" h " : [ 42 , 300 ] ,
} , match_element = any ) , # match one element from 'tree'
2021-06-20 17:07:28 +01:00
} )
} ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_setcomment ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' dhcp.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " setcomment " ,
" params " : { " frame " : 99999 , " comment " : " meh \n baz " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " setcomment " ,
" params " : { " frame " : 3 , " comment " : " foo \n bar " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " frame " ,
" params " : { " frame " : 3 }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 3002 , " message " : " Frame number is out of range " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " status " : " OK " } } ,
sharkd: Improve sub-stream support in "frame" and "follow" methods
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
2024-04-23 14:29:10 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : { " comment " : [ " foo \n bar " ] , " fol " : MatchAny ( list ) , " followers " : MatchAny ( list ) } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_setconf_bad ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " setconf " ,
" params " : { " name " : " uat:garbage-pref " , " value " : " \" \" " }
} ,
2018-11-20 16:27:56 +01:00
) , (
sharkd: Restore printing detailed UAT pref error message
Commit 647205177179a6e9ef6c08f08c33a2b405efffbc removed printing
in sharkd the detailed error message for setting UAT preferences that
was added in c9b0e9c81335e098cdb256b1c58597cda96703b1
Causes sharkd to produce more useful error messages for UATs:
{"jsonrpc":"2.0", "id":1, "method":"setconf","params":{"name": "uat:ssl_keys", "value": "\"192.168.168.110\", \"443\", \"http\", \"/etc/nginx/cert/server.key\", \"\" "}}
{"jsonrpc":"2.0","id":1,"error":{"code":-4005,"message":"Unable to set the preference: ssl_keys:1: File '/etc/nginx/cert/server.key' does not exist or access is denied."}}
{"jsonrpc":"2.0", "id":1, "method":"setconf","params":{"name": "uat:ssl_keys", "value": "\"192.168.168.110\", \"443\", \"http\" "}}
{"jsonrpc":"2.0","id":1,"error":{"code":-4005,"message":"Unable to set the preference: ssl_keys:1: expecting field keyfile"}}
Ping #19562, #20292
2024-12-13 09:01:37 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " error " : { " code " : - 4005 , " message " : " Unable to set the preference: Unknown preference " } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_dumpconf_bad ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " dumpconf " ,
" params " : { " pref " : " bad.preference " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " dumpconf " ,
" params " : { " pref " : " invalid-garbage-preference " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " dumpconf " ,
" params " : { " pref " : " uat:custom_http_header_fields " }
} ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " error " : { " code " : - 9001 , " message " : " Invalid pref bad.preference. " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 9002 , " message " : " Invalid pref invalid-garbage-preference. " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 9002 , " message " : " Invalid pref uat:custom_http_header_fields. " } } ,
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_dumpconf_all ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " dumpconf " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " prefs " : MatchObject ( { " tcp.check_checksum " : { " b " : 0 } } ) }
} ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_req_download_tls_secrets ( self , check_sharkd_session , capture_file ) :
2023-02-28 15:16:26 -05:00
# XXX test download for eo: too
2018-11-20 16:27:56 +01:00
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' tls12-dsb.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " download " ,
" params " : { " token " : " ssl-secrets " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2024-10-20 16:31:45 -04:00
# There are two used CLIENT RANDOM secrets, we don't know
# the order they will appear when iterating a hash table,
# and it can be different on Big-Endian systems than L-E.
# Check the Base64 for both "CLIENT_RANDOM f67a" and
# "CLIENT_RANDOM 1e0d".
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " file " : " keylog.txt " , " mime " : " text/plain " ,
2024-10-20 16:31:45 -04:00
" data " : MatchRegExp ( r ' Q0xJRU5UX1JBTkRP(TSBmNjdh|TSAxZTBk).+ ' ) }
2021-06-20 17:07:28 +01:00
} ,
2018-11-20 16:27:56 +01:00
) )
2023-02-28 15:16:26 -05:00
def test_sharkd_req_download_rtp_stream ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' sip-rtp.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " download " ,
" params " : { " token " : " rtp:200.57.7.204_8000_200.57.7.196_40376_0xd2bd4e3e " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " download " ,
" params " : { " token " : " rtp:1.1.1.1_8000_1.1.1.2_9000_0xdddddddd " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : {
" file " : " rtp:200.57.7.204_8000_200.57.7.196_40376_0xd2bd4e3e " ,
" mime " : " audio/x-wav " ,
" data " : MatchRegExp ( r ' UklGRv.+ ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 10003 , " message " : " no rtp data available " } } ,
) )
2023-03-29 17:24:33 -04:00
def test_sharkd_req_download_bad_tokens ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( ' tls12-dsb.pcapng ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " download " ,
" params " : { " token " : " BOGUSTOKEN " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " download " ,
" params " : { }
} ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " error " : { " code " : - 10004 , " message " : " unrecognized token " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " error " : { " code " : - 10005 , " message " : " missing token " } } ,
) )
2023-08-17 16:12:13 -04:00
def test_sharkd_req_download_eo_http_with_prior_tap_eo_http ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " setconf " ,
" params " : { " name " : " tcp.reassemble_out_of_order " , " value " : " true " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " load " ,
2023-08-17 16:12:13 -04:00
" params " : { " file " : capture_file ( ' http-ooo.pcap ' ) }
} ,
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " tap " , " params " : { " tap0 " : " eo:http " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_0 " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_1 " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 6 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_2 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " method " : " download " ,
2023-08-17 16:12:13 -04:00
" params " : { " token " : " eo:http_999 " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
2023-08-17 16:12:13 -04:00
" taps " : [ {
" tap " : " eo:http " ,
" type " : " eo " ,
" proto " : " HTTP " ,
" objects " : [ {
2025-03-02 13:50:17 -05:00
" pkt " : 4 ,
" filename " : " 1 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_0 " ,
2025-03-02 13:50:17 -05:00
" len " : 4 ,
" sha1 " : " 83f5a5c359f3dc8317519240e32f1f51f68bc051 "
2023-08-17 16:12:13 -04:00
} , {
2025-03-02 13:50:17 -05:00
" pkt " : 10 ,
" filename " : " 3 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_1 " ,
2025-03-02 13:50:17 -05:00
" len " : 6 ,
" sha1 " : " a214ad86e2def05fcb0f4c878dfebe5a6041fb7e "
2023-08-17 16:12:13 -04:00
} , {
2025-03-02 13:50:17 -05:00
" pkt " : 11 ,
" filename " : " 4 " ,
2023-08-17 16:12:13 -04:00
" _download " : " eo:http_2 " ,
" len " : 5 ,
2025-03-02 13:50:17 -05:00
" sha1 " : " 4a4121ecd766ed16943a0c7b54c18f743e90c3f6 "
} , {
" pkt " : 15 ,
" filename " : " 5 " ,
" _download " : " eo:http_3 " ,
" len " : 4 ,
" sha1 " : " 580393f5a94fb469585f5dd2a6859a4aab899f37 " } ]
2023-08-17 16:12:13 -04:00
} ]
} } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : {
2025-03-02 13:50:17 -05:00
" file " : " 1 " , " mime " : " application/octet-stream " , " data " : " MQoyCg== " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : {
2025-03-02 13:50:17 -05:00
" file " : " 3 " , " mime " : " application/octet-stream " , " data " : " YWZ0ZXIK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " result " : {
" file " : " 4 " , " mime " : " application/octet-stream " , " data " : " Zm91cgo= " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 7 , " result " : { } } ,
2023-08-17 16:12:13 -04:00
) )
def test_sharkd_req_download_eo_http_without_prior_tap_eo_http ( self , check_sharkd_session , capture_file ) :
check_sharkd_session ( (
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " setconf " ,
" params " : { " name " : " tcp.reassemble_out_of_order " , " value " : " true " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " load " ,
2023-08-17 16:12:13 -04:00
" params " : { " file " : capture_file ( ' http-ooo.pcap ' ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_0 " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_1 " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " download " ,
2025-03-02 13:50:17 -05:00
" params " : { " token " : " eo:http_2 " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " method " : " download " ,
2023-08-17 16:12:13 -04:00
" params " : { " token " : " eo:http_999 " } } ,
) , (
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2025-03-02 13:50:17 -05:00
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : {
2025-03-02 13:50:17 -05:00
" file " : " 1 " , " mime " : " application/octet-stream " , " data " : " MQoyCg== " } } ,
2023-08-17 16:12:13 -04:00
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : {
2025-03-02 13:50:17 -05:00
" file " : " 3 " , " mime " : " application/octet-stream " , " data " : " YWZ0ZXIK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : {
" file " : " 4 " , " mime " : " application/octet-stream " , " data " : " Zm91cgo= " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 6 , " result " : { } } ,
2023-08-17 16:12:13 -04:00
) )
2018-11-20 16:27:56 +01:00
def test_sharkd_req_bye ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " bye " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_bad_request ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " dud " } ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ ' jsonrpc ' : ' 2.0 ' , ' id ' : 1 , ' error ' : { ' code ' : - 32601 , ' message ' : ' The method dud is not supported ' } } ,
2018-11-20 16:27:56 +01:00
) )
def test_sharkd_config ( self , check_sharkd_session ) :
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " setconf " ,
" params " : { " name " : " uat:custom_http_header_fields " , " value " : " \" X-Header-Name \" , \" Description \" " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " setconf " ,
" params " : { " name " : " tcp.check_checksum " , " value " : " true " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " dumpconf " ,
" params " : { " pref " : " tcp.check_checksum " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " setconf " ,
" params " : { " name " : " tcp.check_checksum " , " value " : " false " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " dumpconf " ,
" params " : { " pref " : " tcp.check_checksum " }
} ,
2018-11-20 16:27:56 +01:00
) , (
# Check that the UAT preference is set. There is no way to query it
# (other than testing for side-effects in dissection).
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " prefs " : { " tcp.check_checksum " : { " b " : 1 } } } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : { " prefs " : { " tcp.check_checksum " : { " b " : 0 } } } } ,
2018-11-20 16:27:56 +01:00
) )
2018-06-18 11:01:31 -07:00
2018-11-20 16:27:56 +01:00
def test_sharkd_config_enum ( self , check_sharkd_session ) :
''' Dump default enum preference value, change it and restore it. '''
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " dumpconf " ,
" params " : { " pref " : " wlan.ignore_wep " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " setconf " ,
" params " : { " name " : " wlan.ignore_wep " , " value " : " Yes - with IV " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " method " : " dumpconf " ,
" params " : { " pref " : " wlan.ignore_wep " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " method " : " setconf " ,
" params " : { " name " : " wlan.ignore_wep " , " value " : " No " }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " method " : " dumpconf " ,
" params " : { " pref " : " wlan.ignore_wep " }
} ,
2018-11-20 16:27:56 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " prefs " : { " wlan.ignore_wep " : { " e " : [ { " v " : 0 , " s " : 1 , " d " : " No " } , { " v " : 1 , " d " : " Yes - without IV " } , { " v " : 2 , " d " : " Yes - with IV " } ] } } } } ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 3 , " result " : { " prefs " : { " wlan.ignore_wep " : { " e " : [ { " v " : 0 , " d " : " No " } , { " v " : 1 , " d " : " Yes - without IV " } , { " v " : 2 , " s " : 1 , " d " : " Yes - with IV " } ] } } } } ,
{ " jsonrpc " : " 2.0 " , " id " : 4 , " result " : { " status " : " OK " } } ,
{ " jsonrpc " : " 2.0 " , " id " : 5 , " result " : { " prefs " : { " wlan.ignore_wep " : { " e " : [ { " v " : 0 , " s " : 1 , " d " : " No " } , { " v " : 1 , " d " : " Yes - without IV " } , { " v " : 2 , " d " : " Yes - with IV " } ] } } } } ,
2018-11-20 16:27:56 +01:00
) )
2019-01-19 23:36:53 +01:00
def test_sharkd_nested_file ( self , check_sharkd_session , capture_file ) :
''' Request a frame from a file with a deep level of nesting. '''
check_sharkd_session ( (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " method " : " load " ,
" params " : { " file " : capture_file ( " http2-data-reassembly.pcap " ) }
} ,
{ " jsonrpc " : " 2.0 " , " id " : 2 , " method " : " frame " ,
" params " : { " frame " : " 4 " , " proto " : " yes " }
} ,
2019-01-19 23:36:53 +01:00
) , (
2021-06-20 17:07:28 +01:00
{ " jsonrpc " : " 2.0 " , " id " : 1 , " result " : { " status " : " OK " } } ,
2019-01-19 23:36:53 +01:00
MatchAny ( ) ,
2020-11-03 11:22:14 -08:00
) )