I have been adding peers to the wireguard interface, and found interesting things happen when I add a fourth one (i.e. more than three).
I checked luci-proto-wireguard at versions git-19.352.74009-3a657b8-1 (unstable) and git-19.309.48729-bc17ef6-1 (stable) both on Chrome and Icecat (Firefox derivative), showing the same behaviour, were applicable.
The wireguard status page just shows the first three peers, any additional peers are not shown. Checking the interface settings, more specific the place where peers are defined, in stable it looks fairly normal, whereas in unstable the popup holding the peers configuration never extends to show more than three peers. I can still add more peers, but sort of fly blind as the field labels are not readable (see picture). This may be related to a LuCI quirk, because the LuCI from stable does not use popups to show the configuration.
I do not think a user mistake could cause this, so I'm guessing it's about bugs? Can anybody reproduce this finding?
That commit by itself doesn't seem to help, but there's a second max-height: 2400px in /www/luci-static/bootstrap/cascade.css, removing that one as well does fix the peer display in luci's wireguard configuration:
Thanks for your replies. In the mentioned file /www/luci-static/bootstrap/cascade.css I can find only one instance of max-height: 2400px;, though. Removing it fixes the problem in the peer configuration (the issue illustrated in the picture) but not the peer status...
You are not talking about two different files, right?
I'm talking about /www/luci-static/bootstrap/cascade.css, the first instance was already removed in @jow's referenced commit, the second is still present (and needs to be removed as well; formatting might differ due to js minimization).
I understand you're saying my installation may have had the first fix already. But then, according to your statement, application of the second one should have fixed the peer status issue as well, right? Well, it hasn't, as I pointed out before, the only change was that the configuration was fixed.
I am happy to report that the second problem is figured out.
After rebooting the device I found nothing related to wireguard worked anymore. The interface would not come up, and the status page complained about wireguard not having a public key ("what the heck?" I thought, as the device's public key only goes into the peer machine's configuration. There is not even a field in LuCI to enter it.).
I found out in one peer's configuration I had done a typo when entering the peer's public key (the wireguard software on that peer is stupid enough to not allow copy-paste). That typo initially meant that tunnel wouldn't work, but it wouldn't for other reasons anyway. After reboot, all hell broke loose as all the peers are configured with the interface at the same time. One invalid public key ruined the setup, and netifd would do the yo-yo with the interface.
Turned out the peer entry with the invalid key was the fourth entry. So when building the wireguard status page, the sub-process building the page would crash on the fourth entry, leaving only the first three to be displayed.
So it is true this is a bug, but not in the status display. The wireguard GUI on OpenWRT relies heavily on the integrity of the entered keys, so the bug is that the GUI does not check the entered keys properly.
So after fixing that typo everything is hunkydory now. Well, except for the sad, terrible state of the wireguard implementations on the peers, but that is a different story.
Unfortunately the gui cannot really verify entered certificates without implementing a full fledged certificate parser, unless there happens to be a wg subcommand to perform the checking?
Can you share details about the crash? Were there any backtraces in either logread or the browser debug console?
I'm sure right now I will not find anything in the logs, as the problem is fixed now. When I have some time I'll reproduce the problem and check the logs. However it should be straightforward for anybody with a working OpenWRT/Wireguard setup: In LuCI, go to Network / Interfaces, edit the Wireguard Interface, go to the Peers tab and choose one peer whose public key you mess up a bit. Saving, LuCI does not complain, even though while applying the modified settings wireguard would refuse to accept the messed up public key. With the probable exception of the messed up peer, Wireguard would still be working. Then, go to Status / Wireguard, and in the list of Peers the messed up one as well as all following ones are gone. After reboot, Wireguard does not work at all anymore, as netifd tries to apply the whole configuration at once - failing due to the messed up entry.
