dmesg buffer flood

[Hristo_Grigorov]

Hi,

I noticed dmesg kernel buffer on a 1595 appliance running R82.00.11 (998002800) is being constantly flooded with messages:

[433997.048200] [SIM4];reorder_after_decrypt: Could not get QoS config for ifnum -1
[433997.048411] [SIM4];reorder_after_decrypt: Could not get QoS config for ifnum -1
[433997.064086] [SIM4];reorder_after_decrypt: Could not get QoS config for ifnum -1
[433997.112309]
[433997.112309] FW-1: stopping debug messages for the next 57 seconds. To disable this suppression see sk74580

While it does not bother me, I am sure it does bother the device itself. Perhaps logging it once is enough.

[PhoneBoy]

Anytime you're generating messages, be it to a log file or the terminal, it creates non-zero load.
The fact we're suppressing the message when we see a number of them in a short period of time definitely helps that.
If this is happening often, then it might warrant a TAC case. 

[Hristo_Grigorov]

I don't know what work is being done before generating this log message and I leave who is responsible for this to decide if it is worth fixing. May contact me as well of course.

Endless loops are never good. At the very least they interrupt CPUs, cause re-scheduling of threads, etc.

[HristoGrigorov]

LoL, there are two of us now 🤣

I noticed the following rather incorrect statement that might be the reason for this log message. I do have configured Internet connection but I haven't enabled QoS on it yet.

[LINnik]

Hi Hristo,

Just adding data points from our side: We ran into the exact same log spam on all appliances updated to R82.00.11 (Build 823) following the PHP2Shell patching.

After thorough testing, we can confirm this appears to be purely cosmetic—we observed no measurable performance impact or network degradation.

That said, kernel buffer floods are never ideal. Looking at reorder_after_decrypt: Could not get QoS config for ifnum -1, it seems SecureXL (SIM) is attempting to query QoS structures post-decryption for an unresolved interface (ifnum -1), even when QoS isn't active on the link.

Does anyone know if Check Point / TAC has already acknowledged this as a general bug in this build, or if an active case ID exists to track a fix?

[LINnik]

Hi Hristo,

Just adding data points from our side: We ran into the exact same log spam on all appliances updated to R82.00.11 (Build 823) following the PHP2Shell patching.

After thorough testing, we can confirm this appears to be purely cosmetic—we observed no measurable performance impact or network degradation.

That said, kernel buffer floods are never ideal. Looking at reorder_after_decrypt: Could not get QoS config for ifnum -1, it seems SecureXL (SIM) is attempting to query QoS structures post-decryption for an unresolved interface (ifnum -1), even when QoS isn't active on the link.

Does anyone know if Check Point / TAC has already acknowledged this as a general bug in this build, or if an active case ID exists to track a fix?

[Hristo_Grigorov]

Hello LINnik,

Thanx for sharing. I haven't observed any performance issues as well. It messes the output of dmesg and fills in the sfwd.elg file real quick and that's it. 

I can't open TAC case but if you can and you do please keep us up-to-date how it goes.