Re: CU201 Testing - No firewall logs displayed although they are in the messages file

[Michael Tremer <michael.tremer@ipfire.org>]

Hello Adolf,

Thanks for raising this. This is probably a regression that would block the release. However, it is not a difficult problem to solve.

What introduced the change? My first guess was an update of klogd, but that has not been updated since May 2025.

Looking through the changes in the update, the only explanation is glibc which implements the syslog() function. Since we cannot really do much about that, I have decided to upgrade to sysklogd 2.x where syslogd and klogd have been combined into one. It is a fresh rewrite and entirely compatible with our configuration - so basically a drop-in replacement.

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=3b32430a4d16d9d5f2334b3acbc94f1f88fad7c8

With this, the messages appear as “kernel:” again.

Please let me know if this solves the problem for you, too.

All the best,
-Michael

> On 1 Apr 2026, at 17:06, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> There was a forum post about not finding any output in the WUI Firewall Logs with CU201 Testing.
> 
> I did some testing and found that the logs were displayed in the WUI if I was working with an IPFire that had been updated from CU200 to CU201 Testing but when I did a fresh install of CU201 Testing then the logs were not displayed.
> 
> Doing a fresh install of CU200 showed the logs as normal in the WUI.
> 
> I checked the /var/log/messages file with the fresh install of CU201 Testing and found that there were firewall logging messages in there but the problem is that the starting section of the log lines with a fresh install of CU201 Testing is
> 
> Apr  1 15:54:23 ipfire klogd: DROP_INPUT IN=red0
> 
> while for CU200 or a CU201 Testing updated from CU200 it is
> 
> Apr  1 16:13:59 ipfire kernel: DROP_INPUT IN=red0
> 
> So the process name has changed from kernel: to klogd: but only for the fresh install of CU201 Testing.
> 
> I have been unable to identify if this was intended to be changed or not and if intended why it is not in the upgraded version.
> 
> So this is to ask if anyone knows why this would be occurring and what should be the expected status?
> 
> Regards,
> 
> Adolf.
> 
>