Hi,
WIO is not working properly after updating to CU202.
The WIO plugin does not display the list of clients connected directly to the LAN.
Additionally, if I connect via OpenVPN, the connection does not appear in the WIO dashboard, but it is displayed on the OpenVPN page.
Regards.
CU202 had openvpn updated to branch 2.7
The 2.7 branch has some changes in the status reporting. Fixes for the OpenVPN WUI page and RW connection status were implemented.
I forgot that WIO also uses the status info for it’s reporting so the status extraction also needs to be changed for it. I suspect that is the issue you are experiencing.
I will try and find some time to confirm the source of the problem and submit a patch to fix it.
Yes, it is the issue I am experiencing. I hope you can fix it.
Regards
I have been able to get some time to have a look at it and been able to successfully get the status showing correctly again.
I now need to get it to show the time connected. That will also need as change to where it is being extracted from.
Once that is completed then I will submit a patch and it should be able to get into CU203.
I have got the Condition part working so it will show a Green CONNECTED when the RW is connected. That problem was due to the format change with OpenVPN-2.7.
I also noticed that the Connected since section was always showing a - instead of the number of days, hours, etc.
I checked with the format of OpenVPN-2.7, 2.6 and 2.5 and the date/time format has always been the same, so it looks like the Connected since section has never been working.
The code was expecting the date/time format to be Jan 5 15:23:44 2025 but it has always been 2025-01-05 15:23:44
I am working on changing the code to work with the actual date format in the status log file so that section is also made to work.
Hi Adolf:
Thank you very much for your efforts and for the updated information.
Regards.
thank you 
I have submitted a patch to fix the Condition value so that it again shows CONNECTED in Green.
I have not fixed the missing entry for Connected since. After some investigation this turned out to be more problematical. From my testing that value should have been getting shown but it clearly is not and I have to investigate further to understand why that is so.
That additional fix will likely end up in CU204 but as that has not been shown since at least CU196, I don’t think it will create a significant problem.
If you are showing /srv/web/ipfire/cgi-bin/wio.cgi from your IPFire, then I don’t understand why it is not working.
Here is my screenshot
You can see it is showing a Green Connected.
One thing I did spot is a typo I made which affects the IP not being shown as highlighted by the red outline.
The typo is shown in the white outline
This should be .+\: and not '+\:
but this only affects the IP used for the tunnel and not the status.
How did you apply the patch?
I would suggest copying the changed lines from my patch commit into a text file and then copying the same lines from your IPFire wio.cgi file and then checking for any differences.
Doing a simple check with your image, I have not found any difference but then it should work.
The patch I submitted was created using a diff between the file from the IPFire I used to test the effect on and the previous file in the IPFire repository.
Did you check that the connection was showing as a Green CONNECTED on the OpenVPN WUI page. If that was also showing a Red DISCONNECTED sign then the connection has some problem.
If the OpenVPN WUI page is Green CONNECTED but the WIO WUI page is Red DISCONNECTED, then there has to be some delta between the patch entry and what is in your wio.cgi.
EDIT:
or there is some issue with what your status log file is showing.
If you get a Green CONNECTED in the OpenVPN WUI but a Red DISCONNECTED in the WIO WUI then have a look in the /var/run/openvpn-rw.log file. It should show something like
OpenVPN CLIENT LIST
Updated,2026-06-09 16:18:48
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
xxxxxxxxxx,udp4:192.168.26.40:33545,19520,22387,2026-06-09 15:44:13
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.110.30.6,xxxxxxxxxx,udp4:192.168.26.40:33545,2026-06-09 16:14:17
GLOBAL STATS
Max bcast/mcast queue length,0
END
where xxxxxxxxxx is the connection name you are using.
That’s good to hear.
I have also superseded the previous patch with a v2 version which corrects the typo for the subnet IP address.
