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 4cQRwl0m8Wz32Pn for ; Mon, 15 Sep 2025 14:19:03 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R13" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4cQRwg593Mz2xLw for ; Mon, 15 Sep 2025 14:18:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4cQRwf4VPBz2Ln; Mon, 15 Sep 2025 14:18:58 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1757945938; 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=gWs08IoT7+s/MMLuz1k/iSrtku6EWvZpy6la4QvrhNM=; b=8haV/BOWhK+lXzkv1q5I0UnoLdp6GF2OrlCcNtOUpNUHrbaBrdanOiRX6+yzi06q4SYzDN pzGkhwNOvf2BTpCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1757945938; 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=gWs08IoT7+s/MMLuz1k/iSrtku6EWvZpy6la4QvrhNM=; b=VrDot+h6nb2Y3CFBpVtMdOtfr5CENdWS+M4QH9muvkc13zrWq3NufneauISBWOsOB89BC+ M5THJy6lP++fG9Mqgw2SnKsBnmXzTy83HDdlfAc0agaJKZpIK4p0dH9F0SVcxP9eGIq2n4 mWMj3dPuHwdR6kTenLZ+9eb7PEnW9ZWaeT99XyiazDLNwtXoKBM+H58NKwbT8aTUw9YiPk PIE/XB4hQnwP70OAnRrLdE0KWFVve1SN1ZUymj9lR0xEDOdHaFPEsFfRpGVMotNYl+Ab1v Owuqgq3a/UTc4Ztw9ovpNRcwSMc4AJ0rVcTNrCR1BELQ1aOhMXsofRRrVM7Wdg== Content-Type: text/plain; charset=us-ascii Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: CU197 Testing - OpenVPN Road Warrior Statistics graphs not working. From: Michael Tremer In-Reply-To: <90bb67c2-8ee4-4c96-a764-4303ce78493b@ipfire.org> Date: Mon, 15 Sep 2025 15:18:58 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <3F808A39-2952-4FE4-B32C-B3F99F2C48C4@ipfire.org> References: <4d1adf3c-1165-4cbf-917d-ea80c6009209@ipfire.org> <42d98f14-ffa8-4513-a5c5-04559d2624a0@ipfire.org> <27af52c0-d46d-4772-94eb-438f21ea62cf@ipfire.org> <90bb67c2-8ee4-4c96-a764-4303ce78493b@ipfire.org> To: Adolf Belka Hello, > On 15 Sep 2025, at 12:45, Adolf Belka wrote: >=20 > Hi Michael, >=20 > A further update. >=20 > On 15/09/2025 13:23, Adolf Belka wrote: >> Hi Michael, >> I am going to reply to all the openvpn changes related to CU197 = Testing. >> The changes for the Road Warrior Statistics graphs worked. All the = graphs are working in CU197 Testing. >> I also submitted changes for the wio addon to update the RW log file = name. Those changes were implemented but obviously are not enough to = make wio show the openvpn connection statuses. There must be some other = aspects that the wio code is using that need to be updated. >> However, I think that this can be left for CU198. The status of the = openvpn connections can be see on the openvpn WUI page and I don't think = we need to delay CU197 Testing for me to fix the wio openvpn status. I = will continue to look at that and submit any required patches once I = understand what other changes in wio are needed. >=20 > I identified that the wio addon was also using openvpn.pid and this = has been updated to openvpn-rw.pid so I now know how to fix this. Still = need to test it out to confirm that it actually fixes it. I really hate how much code relies on broken checks like a PID file. = That is not a valid check whether something is enabled and alive or not. = But since we want to get this release out and since WIO has also seen = very little attention recently, there is no need to rewrite this right = now. If ever. > However, my investigation on the openvpn.pid identified that this is = also used in the ids.cgi to check if openvpn has been started and, if = yes, to add openvpn to the list of network zones. I then checked the = list of zones shown in the IDS and OpenVPN was missing. I changed the = openvpn.pid to openvpn-rw.pid in ids.cgi and the openvpn option to be = enabled was shown again. > That function I think we do want to have in CU197. I will submit a = patch for that shortly so it can be merged into CU197 Testing. Thank you. > Regards, >=20 > Adolf. >=20 >=20 >> I also tested out the routes stuff, to the extent that I could.The = data from the routes-push file is now being correctly taken on board and = applied in the server.conf and then the old routes-push file is removed. = The problem of the gateway push problem that @iptom raised the bug for, = I don't think I can easily test as I could never reproduce the problem = he had in my network, which is a very simple limited network. I will = update the bug and request @iptom to test out the new CU197 Testing = build. >> Presuming the routes issue of @iptom is solved with the latest = version, then I am not aware of any remaining issues to block release. >> Regards, >> Adolf. >> On 14/09/2025 12:40, Michael Tremer wrote: >>> Sorry, I just overlooked them. >>>=20 >>> I merged them and pushed them just now. >>>=20 >>> -Michael >>>=20 >>>> On 14 Sep 2025, at 11:11, Adolf Belka = wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> On 08/09/2025 15:07, Adolf Belka wrote: >>>>> Hi All, >>>>> On 03/09/2025 20:21, Adolf Belka wrote: >>>>>> Hallo All. >>>>>>=20 >>>>>> I have found another issue with OpenVPN on CU197 Testing. >>>>>>=20 >>>>>> The RW graphs Statistics graphs are not getting updated. >>>>>>=20 >>>>>> After some searching around, I found that it was because the = collectd.vpn plugin was still saying /var/log/ovpnserver.log >>>>>>=20 >>>>>> I discovered that there was an update to the collectd.vpn file = but collectd was not shipped in CU197 Testing so it didn't get included. >>>>>>=20 >>>>>> I have submitted a patch to ship collectd in CU197 Testing. >>>>> I have dropped that patch in patchwork. >>>>> I realised that doing that would update the ovpnserver.log to = openvpn-rw.log but it would also remove any n2n entries in collectd.vpn >>>>> I have submitted two new patches. One for update.sh in CU197, = which after running the ovpnmain.cgi file checks if collectd.vpn has the = old log file name in it and if so replaces it with the new version. >>>>> The other patch is to do the same thing in backup.pl for any = restores from old backups before CU197. >>>>> This makes sure that the RW entry is updated but leaves any = existing n2n entries alone in collectd.vpn. >>>>> The above was tested and resulted in working graphs for the RW = connection. >>>>=20 >>>> The two new patches mentioned above >>>>=20 >>>> = https://lists.ipfire.org/development/20250908125938.3389609-1-adolf.belka@= ipfire.org/T/#t >>>>=20 >>>> have not been merged yet. Have they just been missed or is there a = question about them? >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>> Regards, >>>>> Adolf. >>>>>>=20 >>>>>> Evaluated the change in my vm and the rw graphs worked again. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>=20 >>>=20 >=20