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

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

[Adolf Belka]

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.

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

[Michael Tremer]

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.
> 
> 

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

[Adolf Belka]

Hi Michael,

On 03/04/2026 14:57, Michael Tremer wrote:
> 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.

I had also thought that and also found no new change.

> 
> Looking through the changes in the update, the only explanation is glibc which implements the syslog() function. Since we cannot really do much 

I would not have thought of glibc. I didn't know that it implements that logging function. Learn something new each day.

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.

That new version has been around for a while now hasn't it. I also saw that they have an issue defined to include TLS capability for remote logging and that is planned to go into sysklogd-3.x. That will be good to have then as some users have wanted secure remote logging as they send it out of their local network.

> 
>    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.

Have tested out doing a core update upgrade of 201 Testing and that ended up with the logs labelled as kernel: again.

I then also did a fresh install of that new CU201 Testing and that also has the logs with kernel: and therefore they are again shown in the WUI page.

So I can confirm it has been resolved.

Regards,

Adolf.


> 
> 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.
>>
>>
> 
>