Hi everyone,
I tried to secure the webaccess to my LuCi interface by explicitly setting one of the interface IP addresses only, as described here:
uci set uhttpd.main.listen_http="192.168.1.1:80"
uci set uhttpd.main.listen_https="192.168.1.1:443"
The problem is now that the uhttpd service starts, before the network is fully up and this IP address is available.
Is there any place I can tweak the uhttpd service to start after the network is fully up?
Thanks in advance!
Kind Regards,
Johannes
put service uhttpd restart in your local start up script, perhaps add a sleep before the restart, too.
This isn’t the problem!
This is the symptom. You can’t log in before the router is booted anyway and all IP leases are set. And this setting has really nothing to with security since you can call 192.168.1.1 from wherever in the network from all interfaces with firewall setting Input=accept.
Uhttpd only listen for that address, it doesn’t care who makes the call.
Sorry, but this is the error from the logs:
Fri Feb 4 10:24:37 2022 daemon.err uhttpd[1550]: bind(): Address not available
Fri Feb 4 10:24:37 2022 daemon.err uhttpd[1550]: bind(): Address not available
If I wait until the IP is available, and then restart uhttpd via a ssh login, I get the UI perfectly fine.
This is just minimizing the attack surface. All zones that contain potentially bad devices have Input=reject already. But I was just following the Wiki article and wondered, how to do service ordering on OpenWrt.
you could also try to move the S??uhttpd in /etc/rc.d to S99uhttpd, making the web server start last.
I use this system in exactly this way without problem on four different devices.
What openwrt version do you run?
Is this the kernel boot log or system log?
If that error exist because you set the routers own IP address in the uhttpd definition and you get that error in the log than you have another setup issue or there is a bug somewhere in the openwrt code since all devices all over the world use this exact system with the exact same boot order, but only your device doesn’t connect.
To change the boot order to fix the error on this device doesn’t solve the actual problem.
Sorry if I offended you, that was not my intention.
I fully agree, there is something on this device with my settings that leads to this error being shown. It looks like a race condition, in the logs I see that the network is in the middle of getting ready, when uhttpd starts and runs into that error.
Hence my question on how to "order" the services. How to tell uhttpd to wait until the network is fully up? How to create a dependency on the network?
frollic's solution above sounds hacky, but if it does the trick I can give it a shot. Not sure if this is persistent, though.
For the record, this is a TP-Link EAP245v3 running 21.02.01.
Well I have that device up and running and using exactly this function and there is no problems, but this device isn’t buildt as a router. It is a access point. Even though OpenWRT pushed in all router functions in the firmware that I just as fast removed and using it as what it was buildt for.
I use this device as a "dumb access point", so it is not running a firewall or a DHCP server. It is only configured to have all 7 VLANs and the corresponding WiFis.
To me it looks like the VLAN devices are being configured one after the other, and the uhttpd service starts while some of them are already up, but not the one that I need...
Now it starts to make sense!
And you have a miss configuration problem!
You mention first that you set up one of the interfaces IP address but you can only have one interface with dhcp client mode on a dumb access point.
This will be the managemt interface.
And this interface pretty much need to have a static lease for it in the dhcp server in your router and then you can put that IP in the AP uhttpd listening setting.
The other vlan interfaces you have for general wifi data must always be unmanaged interfaces since they are controlled by the router.
The only purpose these extra interfaces have is to bridge the switch vlan to the radios in OpenWRT system.
I at first also tried to have many managed interfaces without dhcp server on the eap245 but the dhcp server in the network will only talk to the first one it finds on a single device and the rest will have “no connection” like you have noticed.
Actually, all VLAN interfaces are using static IPs. There is no DHCP involved on any interface.
(Sorry if I confuse interface, device and things like that, seems like this device has a mixture of swconfig and DSA...)
Static IP or DHCP client with static leases is pretty much the same thing in this case!
But it doesn’t matter, you can only have one managed interface with some kind of IP and the others must always be unmanaged interfaces on a dumb access point.
The IP management must be done in either the router or in the clients on the endpoints with manual static IP if you use manual IP setup.
It is correct that this device is not a full dsa device but it doesn’t really matter. You just run the vlans straight through the switch with swconfig to the cpu and then use DSA standard setup inside the actual OpenWRT system.
It is just swconfig for decoding/coding what goes through the RJ45 connector and then you don’t need to think about that any more and then you use DSA settings for the OpenWRT system.
This setup is actually more clear when you do setup in the network config file than in LuCI.
So, you are proposing that I set all of my LANXX interfaces (except the one that I want to have reachable via uhttp) to unmanaged?
Did I get that correctly?
Yes, if you want the device to work as a dumb access point.
The dumb access point is a client by itself in the network, the vlans or radios isn’t clients, but the devices connected to the radios through a wifi connection is individual clients with their own IP addresses.
But a single client in a network can only have one single IP. If you have one IP on all seven VLANs all with managed interfaces than your dumb access point actually have seven different IP with the same hardware mac address. That doesn’t work.
For the record, this seems to work. Not sure how persistent that will be.
What is the difference between having the same MAC address on seven VLAN interfaces on the router and having another MAC address on all seven VLAN interfaces on the dumb access point?
Sure, I do not need to have IPs on all interfaces, as they are not handling any services (DHCP, DNS, ...). But on the router I need them to have the .1 address for each subnet reachable so the router can server queries in this subnet. And there it works.
So, I don't think this is a real requirement for a dumb AP. I still think this is just a race condition, with the device being too slow to setup the interfaces while uhttpd already starts.
This theory is based on the fact that frollic's recommandation to just start the service later seems to work.
It is your network, do what you want. I don’t care because my stuff works.
Why?
You are using VLAN.