From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fnsPq6JWVz32wS for ; Sat, 04 Apr 2026 10:33:35 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fnsPm3Zz4z2xSL for ; Sat, 04 Apr 2026 10:33:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fnsPk09kfz2SK; Sat, 04 Apr 2026 10:33:29 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1775298810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5IfzRg2Oy1lzDujny1dJ8mdQDcTmFtYGhtZZM32tMJw=; b=pf/aDd1vOEYgdU8rjhnaJxucJsbKGzKv78p6raH4K+/uZj5aVGxXrxnFMm8ZX+zKAUmOxE g82DuPXZOuTpofCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1775298810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5IfzRg2Oy1lzDujny1dJ8mdQDcTmFtYGhtZZM32tMJw=; b=QZlKKKPwOD7+dU6kkdmGgVIBW5M6Kt8ABbcIAlGgTDmLml4aj4xi4nZwrqBiLHGox8yPFw 1kNPEHMhOSaKdMmjY7+Oh6rep6P7qBO0VjR3T1q/G7Z5iGXDXCvSvBU3VXyR5IRV7lvws3 h7CLp4npfPVDsfOmTPqYU1xUu+Jf+0/ZcnDF87xJC66/bCwXjvKzbzPb8C7CSfNtwiuEeV dvcO0ynoR8iB0X4TIw+Rju3bsqLZ/adLI3hChG8Ts//3ReAk0JDpqNlOg9grZ7Md7fnG72 iiFz/5iPFUTIDuuwEubtAyxlItf1Nr+r9NaURn+rwsU3DRX3wnCOZi0wTTHt7A== Message-ID: Date: Sat, 4 Apr 2026 12:33:20 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: CU201 Testing - No firewall logs displayed although they are in the messages file To: Michael Tremer References: <2B659A71-89C8-4BBA-BADC-1AE6A62E5CD4@ipfire.org> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: <2B659A71-89C8-4BBA-BADC-1AE6A62E5CD4@ipfire.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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. >> >> > >