When troubleshooting networking problems, one of the most useful tools is the CLI ping command. This command can send one of more ICMP ECHO, TCP or UDP packets to a specified IPv4 or IPv6 address and reports the reply that is received.

A Simple ICMP Example

The simplest example of ping usage is sending an ICMP ping message to the IPv4 address 10.4.0.2. The CLI command would be:

System:/> ping 10.4.0.2

In the above command, the source interface is not explicitly specified so cOS Stream derives this by looking up the destination IP in the relevant routing table. The routing table used defaults to main but could be specified in the command using the -routingtable=<table> option. For example:

System:/> ping 10.4.0.2 -routingtable=my-rtable

Note that when the source interface is not explicitly specified in this way, the configuration's rule sets are not checked to see if the traffic is allowed. Therefore the message is always sent and cannot be blocked or have address translation applied by the configured IP rules.

Specifying the Protocol and the Message Load

The ICMP ECHO, TCP or UDP protocols can be used when sending a message, with ICMP being the default. The protocol option is specified immediately following the ping command. For example, to send a UDP message to 10.4.0.2, the command would be:

System:/> ping -udp 10.4.0.2

When relevant, the message load can be specified using the -request option, so the response from an HTTP server could be tested with the following command:

System:/> ping -tcp 203.0.113.10 -port=80 -request="GET /HTTP/1.0\n\n"

Sending to IPv6 Addresses

A message can be sent to an IPv6 address in the same way that it is sent to an IPv4 address. Any of the other options discussed previously can be used with IPv6 addresses. Below is an example of pinging the c1a1::1:2 IPv6 address:

System:/> ping c1a1::1:2

Sending 4-byte ICMP ping to c1a1::1:2:61083 from c1a1::1:1:128
4-byte ICMP reply from c1a1::1:2:61083 to c1a1::1:1:129

The -verbose Option

Extra information about traffic sent and received can be displayed when the -verbose option is used (this can be shortened to -v). For example:

System:/> ping 10.4.0.2 -v

In some cases, extra information is available if the -vv (more verbose) option is used.

The verbose options are required when performing ping traffic simulation (described next) in order to see the configuration elements that are triggered during the simulation.

Incoming Packet Simulation Using the -srciface and -srcip Option

In addition to testing the responsiveness of a remote host, the ping command can be used to simulate incoming traffic on a given interface and thereby test how the current configuration responds to different types of traffic. This is done by using the -srciface option to specify the interface that will appear to be receiving the message generated, along with the -srcip option to specify the source IP address of the message.

For example, the following command would simulate an incoming ICMP ping message arriving on the if2 interface that was coming from the source IP address 192.168.0.10:

System:/> ping 10.6.58.10 -srciface=if2 -srcip=192.168.0.10 -verbose

This command will construct an ICMP packet with a destination IP of 10.6.58.10 and cOS Stream will behave as though that packet had arrived at the interface if2 and had come from the external IP address 192.168.0.10.

Note that the simulated traffic received in this way will be treated by the configuration as normal traffic. This means that such configuration elements as IP rules will be applied so any relevant NAT or SAT actions will also be applied. The traffic might even be dropped. Also note that the -routingtable option cannot be used with the -srciface option as it has no relevance in this context.

If there is no route that matches the combination of source IP address and receiving interface, the packet will be dropped. Some example output when this happens is listed below:

System:/> ping 192.168.14.1 -srciface=if14 -srcip=192.168.14.12 -verbose
Simulating 4-byte ICMP ping to 192.168.14.1:44434
  from (if14) 192.168.14.12:8
(Response is not displayed when '-srciface' is used)
SNOOP:  POLICY-1  : Forward lookup matched PBR rule "RoutingRule_1"
  (id 0x3039) against <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:44434>
SNOOP:  POLICY-1  : Drop <ICMP
  if14;192.168.14.12:2048 -> 192.168.14.1:44434>:
	No route to source in table "Main" (ID: 0x20).

For the ping message not to be dropped, there must not only be a route that matches the source IP address and source interface combination but also an IP rule set entry that allows the traffic on that interface. If the administrator simulates the packet arriving on the if2 interface and going to some host on the network if1_net, the allowing IP rule set entry might be the following:

If there is no IP rule set entry that allows the traffic it will also be dropped. The following example shows some example console output when this happens:

System:/> ping 192.168.14.1 -srciface=if14 -srcip=192.168.14.12 -verbose
Simulating 4-byte ICMP ping to 192.168.14.1:2524
  from (if14) 192.168.14.12:8
(Response is not displayed when '-srciface' is used)
SNOOP:  POLICY-1  : Forward lookup matched PBR rule "RoutingRule_1"
(id 0x3039) against <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:2524>
SNOOP:  POLICY-1  : <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:2524>:
  Found reverse route "Route_3" (ID: 0x3ead62f) 192.168.14.0/24 ->
  if14 (Gateway: none) in table "Main" (ID: 0x20).
SNOOP:  POLICY-1  : <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:2524>:
  Found forward route "Route_3" (ID: 0x3ead62f) 192.168.14.0/24 ->
  if14 (Gateway: none) in table "Main" (ID: 0x20).
SNOOP:  POLICY-1  : Matched default rule "System::DefaultDrop"
SNOOP:  POLICY-1  : Dropped by default rule "System::DefaultDrop"
SNOOP:  POLICY-1  : <ICMP if14;192.168.14.12:2048 ->
  192.168.14.1:2524>: Dropped by IP rules

Once both the routing problem and the IP rule problems that were indicated in the above two output examples are fixed, the following is an example of some problem-free output:

System:/> ping 192.168.14.1 -srciface=if14 -srcip=192.168.14.12 -verbose
Simulating 4-byte ICMP ping to 192.168.14.1:24093
  from (if14) 192.168.14.12:8
(Response is not displayed when '-srciface' is used)
SNOOP:  POLICY-1  : Forward lookup matched PBR rule "RoutingRule_1"
  (id 0x3039) against <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:24093>
SNOOP:  POLICY-1  : <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:24093>:
  Found reverse route "Route_3" (ID: 0x3ead62f) 192.168.14.0/24 -> if14
  (Gateway: none) in table "Main" (ID: 0x20).
SNOOP:  POLICY-1  : <ICMP if14;192.168.14.12:2048 -> 192.168.14.1:24093>:
  Found forward route "Route_3" (ID: 0x3ead62f) 192.168.14.0/24 -> if14
  (Gateway: none) in table "Main" (ID: 0x20).
SNOOP:  POLICY-1  : Matched rule "iprule_all_services" with id 0xdaa96f5
SNOOP:  POLICY-1  : Allow <ICMP if14;192.168.14.12:2048 ->
  192.168.14.1:24093>: route via if14

Specifying Only the -srcip Option

The -srcip option can be used without -srciface when traffic is not being simulated. This usage allows an outgoing ping message to originate from a specific source IP address. For example, to send an ICMP ping from the IPv4 address 192.168.0.5 to 10.4.0.2, the command would be the following:

System:/> ping 10.4.0.2 -srcip=192.168.0.5

Normal route lookup determines the sending interface. However, to use -srcip in this way, one of the following conditions needs to be true:

All ping command options are listed in the separate CLI Reference Guide.

During system operation, important troubleshooting information is saved in system memory by the Dconsole subsystem. This information takes the form of time stamped messages which record both normal events such as system restarts but also any abnormal system events. These messages can be retrieved at any time using the CLI command:

System:/> dconsole

The output generated by the dconsole command provides an important diagnostic tool that can help to determine the cause of a system problem. However, it should be remembered that interpreting the output is often best done by sending the information to qualified support personnel.

Message Content

Each dconsole message that is written during system operation includes the following information:

Some typical output from the dconsole command is shown below:

System:/> dconsole
Showing diagnose entries since 2025-11-22:
2025-11-22 07:58:10.943  01:14:32.856  INFO  CONFIG,SYSTEM  vsinit
Beginning system reconfigure [type=Activate][reason=Updated
configuration] [0e925f4f] 
2025-11-22 07:58:12.220  01:14:34.132  INFO  CONFIG,SYSTEM  vsinit
Reconfigure completed successfully [11895f4f]

Here, the dconsole command is used without any parameters and by default only messages stored for today are displayed. The first message retrieved indicates the time of a reconfigure. The second indicates the reconfigure has been successfully completed.

All the recent dconsole messages could have been displayed by using the command with some previous date specified:

System:/> dconsole -show -date=2024-10-20

The Message Buffering Mechanism

A finite amount of volatile memory is allocated for the buffering of dconsole messages. Typically, this buffer holds around a thousand messages although this number can vary because of the variable message length. The contents of this buffer are lost between system restarts.

When the volatile memory buffer is full, the newest message overwrites the oldest message. At certain times, the entire buffer is copied to a non-volatile memory file called dcon.bin and then the buffer is cleared. These copy operations occur when:

When the copy operation occurs, the messages in the volatile memory buffer are appended to the existing messages in the non-volatile file dcon.bin. After the copying is complete, the volatile memory buffer is automatically cleared and begins to fill up again with new messages.

Messages can be appended to the non-volatile file until the configured maximum size of the file is reached. When this happens, cOS Stream erases the oldest 50% of the messages to clear space for new appended messages. The newest 50% of messages in the file are preserved.

During system startup the non-volatile file is allowed to temporarily grow beyond its configured maximum to accommodate any messages generated. This deals with the case that the file may be close to its size limit at startup but vital troubleshooting information still needs to be retained if a problem occurs.

The Volatile Memory Buffer is Circular

The volatile buffer is circular which means that new messages overwrite the oldest messages when it becomes full. When overwriting occurs, a dconsole message is generated that takes a form similar to the following:

2025-11-22 09:47:28.632 43:10:26.415 INFO LOG dconsole 139 Message list
Messages got Overwritten

Manually Clearing All Messages

All messages currently held in dconsole storage can be removed with the command:

System:/> dconsole -clean

This clears all messages in both the volatile memory buffer and the non-volatile memory file.

Filtering Messages

When output reports are generated, dconsole scans all the available messages in both volatile and non-volatile memory. The command provides a variety of options for filtering this output since the total number of available messages may be high.

For example, to show all events that have a severity of Critical or higher, use the command:

System:/> dconsole -show -severity=Critical

To show all events that were generated after and including 2025-11-22, use the command:

System:/> dconsole -show -date=2025-11-22

To show all events related to the system vsinit component, use the command:

System:/> dconsole -show -app=vsinit

To show all events related to the system dataplane component, use the command:

System:/> dconsole -show -app=dataplane

For a full list of dconsole command options, refer to the separate Clavister NetShield Firewall CLI Reference Guide.

A valuable diagnostic tool is the ability to examine the packets that enter and leave the interfaces of a Clavister NetShield Firewall. For this purpose, cOS Stream provides the CLI command pcapdump which allows the recording of packets entering and leaving all or certain interfaces. The captured packets can be stored in a file and/or displayed on the console in an easily readable text form. Filters can also be applied so that only packets meeting specific criteria are recorded.

This section focuses on some of the important options for using the command. The complete syntax of the pcapdump CLI command is described in the cOS Stream CLI Reference Guide.

The Command View Needs to be Changed

The pcapdump command is not available in the default CLI view. The CLI view must be changed to at least debug with the following command:

System:/> cmdview debug

A Simple Example

An example of pcapdump usage is the following sequence which will record the packet flow on the if3 interface:

Using -snaplen to Reduce File Size

The -snaplen option can be used to truncate all packet information before it saved in the buffer and/or a file. However, it will not truncate the information displayed on the console. For example, to only store the first 100 characters of information for each packet, the following command could be used:

System:/> pcapdump -start if3 -snaplen=100

The truncation is done only when the information is stored and does not affect any filtering performed.

The -snaplen option is also useful in reducing the space needed in the pcapdump buffer by shortening the packet information stored. The allocated buffer size is discussed later in this section.

The Memory Buffer Records All Packets Stored

Except for the case of using only console output, all packet information captured is always saved in a memory buffer of a fixed size. There is one buffer allocated at the start of a capture for each interface involved. The space in the buffer occupied by packets can vary depending on the type of packets captured. The current buffer contents can be displayed with just the -show option:

System:/> pcapdump -show

The buffer contents can be explicitly written to a file with the command:

System:/> pcapdump -write

This will write all the buffer contents into as many files as there are interfaces being recorded. If only a particular interface is to be written to a file with a given name, say if3.cap, then the following command would be used:

System:/> pcapdump -write if3 -filename=if3.cap

Writing to the memory buffer can be turned off with the -nocap option. This might be used with the -out option so there is just live output to the console:

System:/> pcapdump -start -out -nocap

When the -nocap option is used, the -status option output will show the Mode as SNOOP instead of ACTIVE.

System:/> pcapdump -status
             PCAP Status

Interface Mode   Packets(In)  Packets(Out) Filter
--------- ------ -----------  ------------ ------
if3       SNOOP  124          174

The memory buffer can be cleared (along with any saved files) by using the command:

System:/> pcapdump -remove

As mentioned earlier, the buffer is usually cleared after packet recording stops and files are automatically written. However, if file writing is disabled by using the -nowrite option, the buffer is not cleared and subsequent pcapdump -start commands will append packet information to the current buffer contents.

The administrator has the option to examine the buffer contents or write the buffer contents to file. To clear the buffer when using the -nowrite option, the administrator must use the pcapdump -remove command.

Changing the Allocated Memory Buffer Size

A pcapdump -start command will allocate a buffer for each interface involved in the packet capture. By default, this buffer is 128 Kbytes. If the captured packets exceed this memory allocation, capture will stop and the following message will appear on the console:

	     Packet capture stopped (buffer size limit reached).

If this is a problem, the buffer size can be specified as larger in the command to start capture. For example, if the desired buffer size is 256 Kbytes then the command would be the following:

System:/> pcapdump -start if3 -bufsize=256 

The minimum buffer size is 128 Kbytes, but it is unlikely that the buffer size needs to be reduced to this. Another approach to solving an insufficient buffer size problem is to use the -snaplen option discussed previously. This will truncate the stored packet information and so reduce the information stored in the buffer and the size of the file created.

Writing Directly to the Console

As well as writing output to a file, output can be also directed to the console with the following version of the start command:

System:/> pcapdump -start if3 -out

This will send output to the console and at the same time save output to a file. If no file should be created then the -nowrite option is used:

System:/> pcapdump -start if3 -out -nowrite

The above command will still cause a buffer to be allocated to the interface and filled with captured packets so a file could be written by saving the buffer to a file, as described previously.

As discussed earlier, if the desire was to write to the console but only to the console and not allocate and fill a buffer, the command would be:

System:/> pcapdump -start if3 -out -nocap

Filtering Output

In conjunction with the above versions of the pcapdump command where the -start option was used with an interface, further filters can be applied to further restrict the type of packet captured.

The range of filters available is large and is fully documented on the online help (type help pcapdump) as well as in the separate CLI Reference Guide. This section will show examples of some of the filters to illustrate their use.

Compatibility with Wireshark

The open source tool Wireshark (formerly called Ethereal) is a useful analysis tool for examining the logs of captured packets. The industry standard .pcap file format is used by pcapdump when it writes data to a file which means that it is compatible with Wireshark.

The administrator must use SCP in order to download the .cap files created by pcapdump from cOS Stream disk storage to a local management workstation for reading by Wireshark.

Writing in Hex and K12 Format

All files written by the pcapdump command are in the .cap format. However, it is possible to write console output in either hexadecimal or K12 format. For example, to write output to the console in hexadecimal format, the command would be:

System:/> pcapdump -start if3 -out -hex

To write output to the console in K12 format, the command would be:

System:/> pcapdump -start if3 -out -k12

cOS Stream can also perform a conversion from the current buffer contents in .cap format to hexadecimal or K12 format on the console. To display the current buffer contents in hexadecimal, the command would be:

System:/> pcapdump -show if3 -hex

Writing hexadecimal to the console provides an alternative way to get packet data into Wireshark or another tool. The hexadecimal output displayed in an SSH client console can be copy and pasted into a local text file on the management workstation and then that file can be read by Wireshark.

The PCAP Remote Capture feature enables network administrators to perform packet captures towards cOS Stream remotely using a third party software such as Wireshark or TShark over an SSH connection. This feature is designed to facilitate detailed network traffic analysis without the need to save captured data to a local, potentially limited, buffer.

When Remote Capture is enabled, administrators can initiate a packet capture session from their local machine, connecting securely to a cOS Stream firewall through SSH. The firewall acts as the capture source, providing real-time packet data to the connected e.g. Wireshark instance. This allows for in-depth inspection of network traffic traversing cOS Stream, including troubleshooting, security analysis, and performance monitoring.

Allowing Remote Capture In cOS Stream

Allowing Remote Capture does not require any additional configuration other than SSH management access to the firewall, which should be already configured on at least one interface. It can be the same interface and management rule the administrator already use to manage the firewall. The following CLI command can be used to see a summary of the current SSH remote management access rule(s).

System:/> show RemoteManagement

If no rule exists under the RemoteMgmtSSH section, a remote management rule allowing SSH management is required in order to use Remote Capture.

Filtering Support

Only the basic form of inclusion filtering is supported. This means that it is not possible to use keywords such as "not", "or" or parentheses ( ). It is possible to select ranges (when applicable) and groups up to four. Attempts to use an unsupported filter would result in an error message regarding unsupported filter parsing.

Supported IP protocol presets:

TCP / UDP / ICMP / ICMPv6 / IGMP / IPv4 / IPv6 / GRE
/ ESP / AH / MTP / SCTP / OSPF / L2TP / ip proto <n>

IP filtering keywords:

src host / src net / dst host / dst net / host / net

Ethernet filtering keywords:

ether src / ether dst / ether host

Port filtering keywords:

src port / src portrange / dst port / dst portrange
/ port / portrange

Filter Examples:

Filter UDP traffic from/to port 53:

udp port 53

Filter OSPF traffic from 192.168.0.1 and 192.168.0.10:

ospf src host 192.168.0.1,192.168.0.10

Filter TCP traffic to 192.168.0.0/16:

tcp dst net 192.168.0.0/16

Filter traffic from/to ports 5000-6000 and 8000-10000:

portrange 5000-6000,8000-10000

Filter traffic from/to ethernet address 00:11:22:33:44:55:

ether host 00:11:22:33:44:55

Filter traffic with IP protocol 100 (GMTP):

ip proto 100

Filter ICMP traffic coming from host 192.168.0.1 going to 192.168.0.2:

icmp and src host 192.168.0.1 and dst host 192.168.0.2

Wireshark Support

Using Remote Capture in Wireshark is possible but the needed external capture tool (SSHDump) is not installed by default and must be selected during software installation as shown below: Configuring Remote Capture in Wireshark consists of the following steps (example) once SSHDump is installed: Tip: If the capture for some reason is not working as it should, try setting the Remote Capture Command field (shown in the screenshot above) manually to e.g:

dumpcap -i <iface> -w - -s <snaplen> -f '<filter>'

Remember to change the Remote Capture Command Selection option from "dumpcap" to "Other" in order to use manual options and filters.

Using Remote Capture Command To Limit Capture Size (Snaplen)

Using the Remote Capture Command field to manually input a capture syntax can have a big advantage as it is possible to use the "-s" flag which means snaplength, a way to limit the amount of data captured in each packet.

This can have be very useful as it is then possible to limit the amount of data captured in each packet. If the administrator is only interested in the headers of the packets and not actual data/payloads there would be no point of capturing large amounts of data which can be very bandwidth intensive. By setting the "-s" parameter to e.g. 100 it means that it only captures the 100 first bytes of the packet, which can be very useful to keep the bandwidth low while at the same time being able to capture large amounts of packets.

An example syntax when snaplength is set to 100 bytes;

dumpcap -i if1 -w - -s 100 -f icmp

Remember to change the Remote Capture Command Selection option from "dumpcap" to "Other" in order to use manual options and filters.

TShark Support

TShark is a command-line network protocol analyzer, similar to Wireshark, that captures and analyzes network traffic. It provides detailed packet data, either in real-time or from pre-captured files, in a text-based format suitable for automation and scripting.

To capture packets using TShark, the following command template can be used:

ssh admin@<ip> "dumpcap -i <iface> -w - -f '<filter>'" | tshark -i -

Replacing <ip> with the IP of the firewall, <iface> with the interface to capture on and <filter> with the capture filter.

The techsupport CLI command is a general command for problem troubleshooting that combines the output from several other troubleshooting commands into a single console output. This information can then used by the administrator but is usually sent to qualified support personnel to troubleshoot problems.

The simplest form of the command is the following:

System:/> techsupport

This will create a file in the top level (root) directory of the system file system called techsupport.txt. Each usage of the command will overwrite any previous techsupport.txt file.

Once created, there are two ways of examining the file's contents:

The first few lines of the techsupport.text file include the system time when the contents were created. A typical example of this header is the following:

Technical Support Information
Please verify the contents before sending to Technical Support.
System Time: 2025-11-22 12:13:48 (UTC+00:00)