<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Arial">Hi, all. Thank you. I'll incorporate this and
test as soon as i can.</font><br>
<br>
<div class="moz-cite-prefix">On 10/24/2019 10:46 AM, John Crispin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a9b7a3fe-3896-c38d-b203-f1320c354dbd@phrozen.org">On
24/10/2019 14:18, Daniel Golle wrote:
<br>
<blockquote type="cite">On Thu, Oct 24, 2019 at 01:21:56PM +0200,
Jo-Philipp Wich wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
<blockquote type="cite">On the Luci GUI, the current behaviour
of Save&Apply of changes to the
<br>
items in wifi.lua and wireless_modefreq.htm is to invoke a
network
<br>
restart. I would like to to change this behavior to invoke
wifi restart
<br>
directly from wifi.lua.
<br>
</blockquote>
<br>
This is not supported and will confuse the netifd wireless
state
<br>
tracking. You should instead extend the netifd wireless
handlers to
<br>
properly deal with updated values.
<br>
</blockquote>
<br>
John and me have been working on this in the past months, I'm
now doing
<br>
a final round of rebasing and testing right now.
<br>
Take a look at my staging tree here:
<br>
<a class="moz-txt-link-freetext" href="https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=summary">https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=summary</a>
<br>
</blockquote>
<br>
thanks for wrapping this feature up !
<br>
John
<br>
<blockquote type="cite">
<br>
What is new here is that hostapd and wpa_supplicant are running
<br>
permanently and offering a ubus interface to add, remove and
modify
<br>
wifi interfaces. netifd and the scripts previously wrapping
around
<br>
hostapd/wpa_supplicant have been modified to make use of that.
<br>
You can easily test it by modifying the wireless configuration
and
<br>
calling 'wifi reconf', changes should take effect immediatly
without
<br>
affecting unmodified networks.
<br>
<br>
Currently, there is still one instance of each service for each
<br>
wiphy, however, once things have been tested a bit more, we can
<br>
reduce this and use the same service to manage interfaces
accross
<br>
radios -- this should already be supported in
hostapd/wpa_supplicant
<br>
right now, however, we intend to change things one by one to
make
<br>
debugging easier.
<br>
<br>
I'd highly appreciate all reviewing and testing of our changes,
I'm
<br>
planning to merge them into master at the end of next week after
<br>
posting a comprehensive series on the mailing list tomorrow or
monday.
<br>
<br>
<br>
Cheers
<br>
<br>
<br>
Daniel
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
<br>
~ Jo
<br>
<br>
_______________________________________________
<br>
openwrt-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
openwrt-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>