Hi,
I would like to switch wifi on/off with a http request. Is there a possibility to perform this?
I only found a way to toggle wifi acording to a shedule on the router with a config file, but that is not the way I would like to handle it.
thx for some hints
I've got to ask.. But.. Why?
Even if you manage to do this (and I suspect it would require writing your own code in the uhttpd or in luci to handle the inbound request), keep in mind that if YOU can do it, someone ELSE can as well..
…and once the wifi is off, your (wifi connected-) phone can't re-enable it, which -while not the only option- probably would be the most common expectations these days.
--
insert something about ssh keys, and invoking /sbin/wifi here, even if that wouldn't be a great idea either.
An elegant solution would be to install php on the router, and write a short PHP-script to edit /etc/config/wireless . Or just to emit a shell cmd like 'wifi down' .
PHP can be used with uhttpd.
PHP on a router makes my skin itch. Far to many security issues, either from the code or the base..
Yes, please install the package "luci-app-commands" (to execute shell code via LuCI) and configure two actions like that, e.g.:
After that switch to the Dashboard tab and copy the second link of each command to your browser favourites, e.g.:
... that's it! No php, no ssh, without LuCI login etc. ... 
Please limit your LuCi to only service your LAN and not the default binding of Any interface, if you are going to do this. Ideally, an Admin VLAN if possible.
The router/LuCI is not available from WAN by default ... and that was not the question of the TO.
True, but then again, the OP asked about http. Sometimes, we have to protect those without certain knowledge-sets from themselves.
I just looked, and below is the default settings from opkg install luci-ssl on the Snapshot I just built.. Those are unbound IP listen addresses, even if the Firewall is keeping it from coming in on WAN, it could.
root@OpenWrt:/# uci show uhttpd
uhttpd.main=uhttpd
uhttpd.main.listen_http='0.0.0.0:80' '[::]:80'
uhttpd.main.listen_https='0.0.0.0:443' '[::]:443'
uhttpd.main.redirect_https='0'
uhttpd.main.home='/www'
uhttpd.main.rfc1918_filter='1'
uhttpd.main.max_requests='3'
uhttpd.main.max_connections='100'
uhttpd.main.cert='/etc/uhttpd.crt'
uhttpd.main.key='/etc/uhttpd.key'
uhttpd.main.cgi_prefix='/cgi-bin'
uhttpd.main.lua_prefix='/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
uhttpd.main.script_timeout='60'
uhttpd.main.network_timeout='30'
uhttpd.main.http_keepalive='20'
uhttpd.main.tcp_keepalive='1'
uhttpd.main.ubus_prefix='/ubus'
uhttpd.defaults=cert
uhttpd.defaults.days='730'
uhttpd.defaults.key_type='ec'
uhttpd.defaults.bits='2048'
uhttpd.defaults.ec_curve='P-256'
uhttpd.defaults.country='ZZ'
uhttpd.defaults.state='Somewhere'
uhttpd.defaults.location='Unknown'
uhttpd.defaults.commonname='OpenWrt'
once upon a time... I tried this... whilst the recommendation is sound... in practice, it can create complications when toying with networking/vlans etc. ( especially for general users )
mac/vlsm based firewall rulesets are a likely a little more forgiving in this regard...
I only have to tell my virtual assistant to turn it on again
the router is only used as access point behind a Fortigate Firewall
Thinking your beyond reach is never a good idea. However! You will better be able to weigh your exposure vs likelihood, I just wanted to give you another point of view 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.