Yesterday, a user privately messaged me asking how to resolve the issue of being unable to access the web page after flashing the OpenWrt firmware on their K2P device. During our chat, it was clear that they had little foundational knowledge, so today I am organizing some thoughts, but you will still need to explore on your own.First, you need to understand the basic components of a web service, which you can refer to:About Web Development on the OpenWrt PlatformLocating the IssueThe user’s problem description is: After flashing the OpenWrt firmware package on the K2P, they cannot access the web page by entering the IP address in the browser, and it shows a connection refused error.Since we didn’t discuss much, many details are unclear, so I will share some thoughts briefly.First, let’s talk about the general approach. Taking the official OpenWrt firmware as an example, you need to ensure that the following components are present:
- Frontend and backend code implementation, the official firmware uses LuCI.
- Web server, default is uhttpd service.
Next, check the network. Is your PC getting an IP address? Is the IP address in the 192.168.1.X subnet? Since the default gateway address for the official OpenWrt firmware is 192.168.1.1, the IP address you enter must be this one.I am not sure if the K2P firmware you mentioned is applied to the K2P hardware. If the software and hardware do not match, various strange issues may arise, and you may not even be able to obtain an IP address due to incorrect network drivers.Then, check the HTTP service on the device and confirm whether the LuCI package is installed. First, you can access the device’s backend via SSH to see if you can find the LuCI file. Here, I am using the GL-iNet Slate 7 as a demonstration for reference:
root@GL-BE3600:~# ls /www/cgi-bin/cgi-backup cgi-download cgi-exec cgi-upload glc luciroot@GL-BE3600:~#If you do not find it, congratulations! You just need to flash a firmware that includes LuCI or install the LuCI package.If these files are present but you still cannot access them, you need to check whether the HTTP service is running. Search in the device’s backend:
root@GL-BE3600:~# ps | grep uhttpd | grep -v grep10311 root 5000 S /usr/sbin/uhttpd -f -h /www -r GL-BE3600 -x /cgi-bin -u /ubus -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -p 0.0.0.0:8080 -C /etc/uhttpd.crt -K /etc/uhttpd.key -s 0.0.0.0:8443root@GL-BE3600:~#If you see a process similar to the above, it indicates that the web service is running. However, it is also possible that improper configuration of the uhttpd service is causing the issue, so you need to check the configuration in /etc/config/uhttpd. You can use the following command to check if port 80 is already in use:
root@GL-BE3600:~# netstat -tunlpActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 26978/uhttpdtcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 10784/nginx.conf -gtcp 0 0 192.168.111.13:53 0.0.0.0:* LISTEN 5378/dnsmasqtcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 5378/dnsmasqtcp 0 0 192.168.8.1:53 0.0.0.0:* LISTEN 5378/dnsmasqtcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3497/dropbeartcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 26978/uhttpdtcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 10784/nginx.conf -gtcp 0 0 :::80 :::* LISTEN 10784/nginx.conf -gtcp 0 0 fe80::9683:c4ff:feab:9d17:53 :::* LISTEN 5378/dnsmasqtcp 0 0 fe80::ecda:2eff:feaa:aa62:53 :::* LISTEN 5378/dnsmasqtcp 0 0 fe80::50c0:83ff:feca:a0be:53 :::* LISTEN 5378/dnsmasqtcp 0 0 fe80::9683:c4ff:feab:9d17:53 :::* LISTEN 5378/dnsmasqtcp 0 0 fe80::f8c0:87ff:fe44:800a:53 :::* LISTEN 5378/dnsmasqtcp 0 0 ::1:53 :::* LISTEN 5378/dnsmasqtcp 0 0 :::22 :::* LISTEN 3497/dropbeartcp 0 0 :::443 :::* LISTEN 10784/nginx.conf -gudp 0 0 192.168.111.13:53 0.0.0.0:* 5378/dnsmasqudp 0 0 127.0.0.1:53 0.0.0.0:* 5378/dnsmasqupd 0 0 0.0.0.0:67 0.0.0.0:* 5378/dnsmasqudp 0 0 127.0.0.1:9900 0.0.0.0:* 4824/hostapdudp 0 0 127.0.0.1:9902 0.0.0.0:* 4809/wpa_supplicantudp 0 0 0.0.0.0:5353 0.0.0.0:* 10654/avahi-daemon:udp 0 0 :::546 :::* 22235/odhcp6cudp 0 0 :::547 :::* 2328/odhcpdudp 0 0 fe80::9683:c4ff:feab:9d17:53 :::* 5378/dnsmasqudp 0 0 fe80::ecda:2eff:feaa:aa62:53 :::* 5378/dnsmasqtcp 0 0 fe80::50c0:83ff:feca:a0be:53 :::* 5378/dnsmasqtcp 0 0 fe80::9683:c4ff:feab:9d17:53 :::* 5378/dnsmasqtcp 0 0 fe80::f8c0:87ff:fe44:800a:53 :::* 5378/dnsmasqtcp 0 0 ::1:53 :::* 5378/dnsmasqtcp 0 0 :::5353 :::* 10654/avahi-daemon:If it is still not working, it may also be related to the firewall. This can get complicated, and for beginners, switching to a stable firmware may be more efficient.Finally, the entire interaction process can be analyzed through network packet capture to see exactly where the issue lies, but you need to have some understanding of packet capturing and the HTTP protocol interaction process.Flashing Official FirmwareOn the OpenWrt official website, you can find the official firmware for all supported hardware devices, which ensures basic functionality is normal and can be used directly. You just need to visit the firmware selector URL:https://firmware-selector.openwrt.org/
You just need to select the desired firmware system version from the dropdown box and enter the firmware model you are looking for in the input box. It supports fuzzy search, so you can just enter K2P:
Select the complete model name and wait for the query results:
Note that this search process may fail, so please try several times. As long as you can find the model, there should be no problem. Click the SYSUPGRADE button below to download the official upgraded firmware and upgrade it to your device.Compiling Firmware YourselfFor information on how to compile firmware yourself, you can refer to the previous article:Setting Up the OpenWrt Development EnvironmentIf it is for the K2P hardware device, focus on the following two configurations. The first is hardware selection, refer to the first three lines of configuration in the image below:
Then there is the LuCI package, refer to the image below, as it is not selected by default, you need to manually check it:
Finally, for beginners, learning OpenWrt will face many difficulties and endless failures, which is a necessary part of the growth process. Only those with strong determination are likely to become experts in a certain field; the entire technology stack of OpenWrt is very large, so it is impossible to say that the problems you encounter have been faced by others, nor can you say that others are obliged to answer your questions. Many times, others can only provide you with a thought process, and ultimately you need to do more research and hands-on verification. I wish all friends who are eager to learn OpenWrt good luck!