-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
luci-mod-network: invalid dnsmasq instance written to config #7199
Comments
That PR does look relevant, but I tried 23.05.3 and it seems unchanged. I also tried adding a new dnsmasq instance with the new version but static leases are still being assigned by index; the generated commands for a new instance and a static lease were
and the lease still doesn't end up in the generated dnsmasq config.
|
I've tried now with 23.0.5 and I don't see any change unfortunately. |
Should be available in the repo tomorrow. |
Thanks. I upgraded luci-mod-network:
It doesn't seem to be quite right. I see both my instances in the list when I edit a static lease, but if I edit a lease and save it without any changes the instance is lost. |
I don't observe those results. What you see happening is the mac getting re-written, since it's now (for simplicity) a list, and not a space separated field. All other properties are retained. You might need to toggle instance to another, save it, edit again and toggle back, save to get the result you need the first time. |
Sorry yes I see what you mean now. Thanks. |
This seems to happen on every single edit now, btw. Even if I save the changes, next edit does exactly the same thing. Unrelated to this issue of course. |
Might be related to the mac verify function that runs. One could add a bit more code to prevent a new write. |
Static leases are saved with an invalid dnsmasq instance setting. The instance is saved by index, not by name, and does not end up in the resultiing dnsmasq config file.
Steps to reproduce:
Actual behavior:
1.Selected instance is referenced by number, which does not work.
Expected behavior:
1.Selected instance is referenced by name, which does work.
Additional Information:
The text was updated successfully, but these errors were encountered: