Kernel Debug Syntax

Description:

During a kernel debug session, Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. prints special debug messages that help Check Point Support and R&D understand how the Security Gateway processes the applicable connections.

Important - In Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., you must configure and perform the kernel debug procedure on all cluster members in the same way.

Action plan to collect a kernel debug:

Note - See the Kernel Debug Procedure, or the Kernel Debug Procedure with Connection Life Cycle.

Step	Action	Description
1	Configure the applicable debug settings: Restore the default settings. Allocate the debug buffer.	In this step, you prepare the kernel debug options: Restore the default debug settings, so that any other debug settings do not interfere with the kernel debug. Allocate the kernel debug buffer, in which Security Gateway holds the applicable debug messages.
2	Configure the applicable kernel debug modules and their debug flags.	In this step, you prepare the applicable kernel debug modules and their debug flags, so that Security Gateway collects only applicable debug messages.
3	Start the collection of the kernel debug into an output file.	In this step, you configure Security Gateway to write the debug messages from the kernel debug buffer into an output file.
4	Stop the kernel debug.	In this step, you configure Security Gateway to stop writing the debug messages into an output file.
5	Restore the default kernel debug settings.	In this step, you restore the default kernel debug options.

To restore the default kernel debug settings

To reset all debug flags and enable only the default debug flags in all kernel modules:

fw ctl debug 0

To disable all debug flags including the default flags in all kernel modules:

Best Practice - Do not run this command, because it disables even the basic default debug messages.

fw ctl debug -x

To configure the debug modules and debug flags

General syntax:

fw ctl debug [-d <Strings to Search>] [-v {"<List of VSIDs>" | all}] -m <Name of Debug Module> {all | + <List of Debug Flags> | - <List of Debug Flags>}

fw ctl debug [-s "<String to Stop Debug>"] [-v {"<List of VSIDs>" | all}] -m <Name of Debug Module> {all | + <List of Debug Flags> | - <List of Debug Flags>}

To see a list of all debug modules and their flags:

Note - The list of kernel modules depends on the Software Blades you enabled on the Security Gateway.

fw ctl debug -m

To see a list of debug flags that are already enabled:

fw ctl debug

To enable all debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> all

To enable the specified debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> + <List of Debug Flags>

To disable the specified debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> - <List of Debug Flags>

To collect the kernel debug output

General syntax (only supported parameters are listed):

fw ctl kdebug [-p <List of Fields>] [-T] -f > /<Path>/<Name of Output File>

fw ctl kdebug [-p <List of Fields>] [-T] -f -o /<Path>/<Name of Output File> -m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]

To start the collection of the kernel debug into an output file:

fw ctl kdebug -T -f > /<Path>/<Name of Output File>

To start collecting the kernel debug into cyclic output files:

fw ctl kdebug -T -f -o /<Path>/<Name of Output File> -m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]

Parameters

Note - Only supported parameters are listed.

Parameter

Description

0 | -x

Controls how to disable the debug flags:

0

Resets all debug flags and enables only the default debug flags in all kernel modules.

-x

Disables all debug flags, including the default flags in all kernel modules.

Best Practice - Do not use the "-x" parameter, because it disables even the basic default debug messages.

-d <Strings to Search>

When you specify this parameter, the Security Gateway:

Examines the applicable debug messages based on the enabled kernel debug modules and their debug flags.
Collects only debug messages that contain at least one of the specified strings into the kernel debug buffer.
Writes the entire kernel debug buffer into the output file.

Notes:

These strings can be any plain text (not a regular expression) that you see in the debug messages.

Separate the applicable strings by commas without spaces:

-d String1,String2,...,StringN

You can specify up to 10 strings, up to 250 characters in total.

-s "<String to Stop Debug>"

When you specify this parameter, the Security Gateway:

Collects the applicable debug messages into the kernel debug buffer based on the enabled kernel debug modules and their debug flags.
Does not write any of these debug messages from the kernel debug buffer into the output file.
Stops collecting all debug messages when it detects the first debug message that contains the specified string in the kernel debug buffer.
Writes the entire kernel debug buffer into the output file.

Notes:

This one string can be any plain text (not a regular expression) that you see in the debug messages.
String length is up to 50 characters.

-m <Name of Debug Module>

Specifies the name of the kernel debug module, for which you print or configure the debug flags.

{all | + <List of Debug Flags> | - <List of Debug Flags>}

Specifies which debug flags to enable or disable in the specified kernel debug module:

all

Enables all debug flags in the specified kernel debug module.

+ <List of Debug Flags>

Enables the specified debug flags in the specified kernel debug module.

You must press the space bar key after the plus (+) character:

+ <Flag1> [<Flag2> ... <FlagN>]

Example: + drop conn

- <List of Debug Flags>

Disables the specified debug flags in the specified kernel debug module.

You must press the space bar key after the minus (-) character:

- <Flag1> [<Flag2> ... <FlagN>]

Example: - conn

-v {"<List of VSIDs>" | all}

Specifies the list of Virtual Systems.

A VSX Gateway Physical server that hosts VSX virtual networks, including all Virtual Devices that provide the functionality of physical network devices. It holds at least one Virtual System, which is called VS0. automatically filters the collected kernel debug information for debug messages only for these Virtual Systems.

-v "<List of VSIDs>"

Monitors the messages only from the specified Virtual Systems.

To specify the Virtual Systems, enter their VSID number separated with commas and without spaces:

"VSID1[,VSID2,VSID3,...,VSIDn]"

Example: -v "1,3,7"

-v all

Monitors the messages from all configured Virtual Systems.

Notes:

This parameter is supported only in VSX Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. mode.
This parameter and the -k parameter are mutually exclusive.

-e <Expression>

-i <Name of Filter File>

-i -

-u

Specifies the INSPECT filter for the debug:

-e <Expression>

Specifies the INSPECT filter. See fw monitor.
-i <Name of Filter File>

Specifies the file that contains the INSPECT filter.
-i -

Specifies that the INSPECT filter arrives from the standard input.

The Security Gateway prompts to enter the INSPECT filter on the screen.
-u - Removes the INSPECT debug filter.

Notes:

These are legacy parameters ("-e" and "-i").
When you use these parameters ("-e" and "-i"), the Security Gateway cannot apply the specified INSPECT filter to the accelerated traffic.
For new debug filters, see Kernel Debug Filters.

-z

The Security Gateway processes some connections in both SecureXL Check Point product on a Security Gateway that accelerates IPv4 and IPv6 traffic that passes through a Security Gateway. code and in the Host appliance code (for example, Passive Streaming Library (PSL Passive Streaming Library. Packets may arrive at Security Gateway out of order, or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases, a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with the Passive Streaming Library (PSL) technology. (1) The PSL is an infrastructure layer, which provides stream reassembly for TCP connections. (2) The Security Gateway makes sure that TCP data seen by the destination system is the same as seen by code above PSL. (3) The PSL handles packet reordering, congestion, and is responsible for various security aspects of the TCP layer, such as handling payload overlaps, some DoS attacks, and others. (4) The PSL is capable of receiving packets from the Firewall chain and from the SecureXL. (5) The PSL serves as a middleman between the various security applications and the network packets. It provides the applications with a coherent stream of data to work with, free of various network problems or attacks. (6) The PSL infrastructure is wrapped with well-defined APIs called the Unified Streaming APIs, which are used by the applications to register and access streamed data.) - an IPS Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). infrastructure, which transparently listens to TCP traffic as network packets, and rebuilds the TCP stream out of these packets.).

The Security Gateway processes some connections in only in the Host appliance code.

When you use this parameter, kernel debug output contains the debug messages only from the Host appliance code.

-k

The Security Gateway processes some connections in both kernel space code and in the user space code (for example, Web Intelligence).

The Security Gateway processes some connections only in the kernel space code.

When you use this parameter, kernel debug output contains the debug messages only from the kernel space.

Notes:

This parameter is not supported in the VSX mode, in which the Firewall works in the user space.
This parameter and the -v parameter are mutually exclusive.

-p <List of Fields>

By default, when the Security Gateway prints the debug messages, the messages start with the applicable CPU ID and CoreXL Firewall instance ID.

You can print additional fields in the beginning of each debug message.

Notes:

These fields are available:

all, proc, pid, date, mid, type, freq, topic, time, ticks, tid, text, errno, host, vsid, cpu.
When you specify the applicable fields, separate them with commas and without spaces:

Field1,Field2,...,FieldN
The more fields you specify, the higher the load on the CPU and on the hard disk.

-T

Prints the time stamp in microseconds in front of each debug message.

Best Practice - Always use this parameter to make the debug analysis easier.

-f

Collects the debug data until you stop the kernel debug in one of these ways:

When you press the CTRL+C keys.
When you run the "fw ctl debug 0" command.
When you run the "fw ctl debug -x" command.
When you kill the "fw ctl kdebug" process.

/<Path>/<Name of Output File>

Specifies the path and the name of the debug output file.

Best Practice - Always use the largest partition on the disk - /var/log/. Security Gateway can generate many debug messages within short time. As a result, the debug output file can grow to large size very fast.

-o /<Path>/<Name of Output File> -m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]

Saves the collected debug data into cyclic debug output files.

When the size of the current <Name of Output File> reaches the specified <Size of Each Cyclic File in KB> (more or less), the Security Gateway renames the current <Name of Output File> to <Name of Output File>.0 and creates a new <Name of Output File>.

If the <Name of Output File>.0 already exists, the Security Gateway renames the <Name of Output File>.0 to <Name of Output File>.1, and so on - until the specified limit <Number of Cyclic Files>. When the Security Gateway reaches the <Number of Cyclic Files>, it deletes the oldest files.

The valid values are:

<Number of Cyclic Files> - from 1 to 999
<Size of Each Cyclic File in KB> - from 1 to 2097150