On some IPFire devices, a message appears after running the WIO add-on: "This function is temporarily unavailable, because in the background client states are being updated (active/inactive)." Below is a link to a forum topic describing the problem https://community.ipfire.org/t/wio-addon-broken-cant-change-anything/4518
Created attachment 1008 [details] after_click-Update-all-clients-now.jpg
Created attachment 1009 [details] after_click-Update-all-clients-now.jpg
Created attachment 1010 [details] test-command-wioscan-s-red0-on-VM-testOK.jpg
Created attachment 1011 [details] test-command-wioscan-s-red0-on-problematic-device.jpg
Created attachment 1012 [details] rows-commented-on-in-wio.pl
Created attachment 1013 [details] another-possible-message
In the thread below, a possible workaround/solution to the problem https://community.ipfire.org/t/wio-addon-broken-cant-change-anything/4518/19?u=tphz
I have done some reading and testing out. The wioscan code is c based and I have never done any coding in c so I will have to work a bit at reading the code to understand the details of what it is doing. However, clearly what it is doing is scanning the specified networks to see what available IP's are present and if they are active for the involved interface connection. On my system it scans my red and comes up with a list 1022 IP's. 1022 are scanned because my ISP has the subnet from xxx.yy.216.1 to xxx.yy.219.254 for clients on its network in my area. This is a subnet of xxx.yy.216.0/20 Scanning the 1022 IP's takes my system about 3 seconds. Looking at the result from wioscan on your problematic machine your ISP is using a private network and it looks to have a subnet defined of 10.0.0.0/8 which equates to 16,777,214 usable IP addresses. Based on my IPFire machine's speed for 1022 IP's your red network would take wioscan over 13 hours. I suspect that wio is not hanging but just taking a long time to complete the scan. The code that you commented out basically means that the red interface is not added to the array of interfaces to search. This should then mean that WIO does not provide the status of or update the information regarding the red0 interface. However when I commented out that code on my system the WIO page was still providing the status of my red IP and that of the gateway from my ISP. In fact I could see no difference in the wio page with that code in or commented out. It could be that elsewhere in the code it takes the required info for the red interface without needing to do a scan but I don't know. I will now spend some time looking through the code and trying to understand where the info for the red interface shown on the WIO WUI page comes from and how that relates back to the @ifaces array in wio.pl
Forgot to ask, in the output of the wioscan red0 command the mac codes shown only have the first two octets. There should be 6 octets followed by a comma and then the IP address. Did you edit the mac codes to remove 4 of the octets or is this output also coming from wioscan as it runs on your system?
(In reply to Adolf Belka from comment #9) > Forgot to ask, in the output of the wioscan red0 command the mac codes shown > only have the first two octets. There should be 6 octets followed by a comma > and then the IP address. > > Did you edit the mac codes to remove 4 of the octets or is this output also > coming from wioscan as it runs on your system? Yes, I have edited mac codes to remove 4 octets.
> I suspect that wio is not hanging but just taking a long time to complete > the scan. > ... to complete the scan... and sorting, because --> wioscan -s wioscan -help wioscan [-faep] [interface] [ip-range] -s sort responses -a do not list interface's own address -e do not include info from /etc/ethers -p print vendor names -w slow operation -l listen only (not promiscuous) ip-range: ip ip/bits ip-ip
The lines of code that you have identified were included in WIO in July 2020 in Core Update 147. Unfortunately there is no commit message about these lines so nothing to explain why they were added. The patch set that the lines were added with are related to the removal of the IPFire shutdown commands from WIO as these were duplicating what is available in IPFire anyway. So the additional lines are unrelated to the principle aim of the patch set. A similar set of lines were also added to wio.cgi with the same patch set but these lines were added only as comment lines. It may be that these lines were used for some experimental or testing activity and got left in by mistake but it is no longer possible to find out. I have searched through the code for wio.pl and wio.cgi and run various experiments and have reached the following conclusions. Both with the wio.pl lines commented out and with them present the status update of the red interface and of the Gateway IP for the red interface (ISP's Gateway) works if the red Ethernet plug is taken out. This works both when the update symbols are pressed on the WUI page or after the periodically run wio.pl has completed and the wui page is refreshed. I have not yet been able to figure out how the red interface sections are being updated when the code is not in use in wio.pl. I am still searching through the wio.cgi code and am sure that I will eventually figure it out. I still need to do a test with a static red ip with aliases set to see how these are dealt with when the lines in wio.pl are commented out. If that works also then the likely solution I will submit is a patch removing these lines from wio.pl
Patch has been submitted to dev mailing list and to patchwork https://patchwork.ipfire.org/project/ipfire/list/?series=2771
https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=12fbbc61e568b208f007df3b02c28b0bb6fe14e7 https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=aee369fea30e210bf1088e88116610f8ce970a4b Not bumping to MODIFIED since this is my temporary personal branch, but I expect this to land in 'next' soon.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=12fbbc61e568b208f007df3b02c28b0bb6fe14e7 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=aee369fea30e210bf1088e88116610f8ce970a4b
https://blog.ipfire.org/post/ipfire-2-27-core-update-168-is-available-for-testing
https://blog.ipfire.org/post/ipfire-2-27-core-update-168-released