I just recently upgrade to 19.7.1 to 19.7.4 and LuCi HTTPS stopped working. Thought that I may need to re-do the luci-ssl configuration I followed:
I used luci-ssl-openssl (instead of luci-ssl). I have also created a myconfig.conf file as per below:
which generated mycert2.crt and mycert2.key files in /etc/ssl/ folder and uploaded using Luci-uhttpd:
Saved and Applied the changes then rebooted the router for good measure.
After all of this, HTTPS still not working
Hope you guys can help me out
Also just to further add, I tried to look at the syslog but didn't find anything relevant under UHTTPd
Is the server running?
ps wwww | grep uhttp
Is it bound to the proper addresses?
netstat -lnp | grep http
Thanks much for taking time to reply. Here’s the output for the commands you ask to run.
uhttpd is not listening to 192.168.1.2:443
Is there something else listening?
netstat -lnp | grep 443
Please use the "Preformatted text
</>" button for logs, scripts, configs and general console output.
Alright, here’s the result netstat grep 443.
root@OpenWrt-1900:~# netstat -lnp | grep 443
tcp 0 0 :::443 :::* LISTEN 1629/uhttpd
Weird huh? ... in the luci uhttpd page 192.168.1.2 defined for https.
Just making sure, but this router has 192.168.1.2 as it's normal LAN ipv4 address, right?
(So that 192.168.1.2 is not any specially invented address just for uhttpd...)
Yes ... it’s a dumb AP that’s why it is 192.168.1.2. The main router 192.168.1.1.
Haven’t upgraded the main WRT3200 router until things are stable with this.
Is there a way to put UHTTPD to debug mode? Co’z the syslog isn’t saying any problems going on
service uhttpd stop
then run the command from
ps wwww | grep uhttpd on the console. It won't fork to background so any errors will be visible.
Here’s the output as per the commands you sent:
root@OpenWrt-1900:~# service uhttpd stop
root@OpenWrt-1900:~# ps wwww | grep uhttpd
6574 root 1072 R grep uhttpd
root@OpenWrt-1900:~# service uhttpd start
root@OpenWrt-1900:~# ps wwww | grep uhttpd
6610 root 3956 S /usr/sbin/uhttpd -f -h /www -r OpenWrt-1900 -x /cgi-bin -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0.0.0.0:80 -p [::]:80 -C /etc/ssl/mycert2.crt -K /etc/ssl/mycert2.key -s [::]:443 -s 192.168.1.2:443 -q
6658 root 1072 R grep uhttpd
It now works!!! See below:
You now see padlock. It’s listening to port 443 now
I am just at a loss what solved it. One just stopped/start the service and the other was a process listing. I have restarted this a bunch of times before reaching out to you guys.
so I’m clueless as to what solved it. Hope you can provide some clarification regarding my confusion. Thanks!
I think I know now what the problem is:
There might be an issue the the uhttpd service startup during reboots. Co’z I tried to reboot router and https isn’t working again
But when I execute “service uhttpd stop” and “service uhttpd start” https is working again.
This also explains why my reboots wasn’t resolving eventhough I have correctly defined the ip addresses for port 443 https will listen to.
Having said that, the question now is, do you know where I can check startup parameters for the service?
Is the device taking settings from dhcp or has static IP?
It’s statically assigned see below:
For some reason uHTTPd is not listening on the unspecified address
Try to reset its config to the defaults, reboot the device and make sure the socket is not busy.
I suppose the OP wanted it that way for some reason. But maybe it is better to just leave it to default
0.0.0.0:443 and see how it goes.
Interface/socket binding is known to be problematic due to possible race conditions with network management services.
If possible, it's best to avoid it and utilize firewall to manage access permissions.
Thanks for taking time to looking into my issue. Really am appreciating it.
So to summarize, I will just remove the 192.168.1.2:443 defninition for HTTPS in UHHTPD? I will just
remove the higlighted entrie as seen below?
I can do that I’m just a home user so no need to have paranoid levels of security for me
However, just curious though why is it when I restart the service it works just fine?
No, replace it with the following:
A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.
The term race condition was already in use by 1954, for example in David A. Huffman's doctoral thesis "The synthesis of sequential switching circuits".
Race conditions can occur especially in logic circuits, multithrea...
I tried to apply the changes but it is not getting reflected when applied through LuCi.
it times out and rolls back the changes.
Will do it through the configuration file now. Will update you guys in a while of the results.
I can now confirm that HTTPS is now working again in LuCi
even after reboot Yipee!
Thanks to you and
@trendy for your support.