I got the rpi4b awhile ago in hopes of making it my new home router/gateway/ap/firewall/dhcp server. Discovered right away that OpenWRT provided no stable release. So I put that project on the back burner and set up a Linksys WRT AC1900 instead. I got impatient recently and decided to have a go at getting the rpi4 set up. Having problems configuring wulfy23's build on this device.
rpi4 is a test router hooked to my current OpenWRT LAN. I first tried a different build on this device, one I found at https://github.com/robcollins55/Raspberry-Pi-4-OpenWrt-Router-Custombuild. Almost everything worked well out of the box using that build except that the Luci web interface was inaccessible. I've also realised that, although the individual that produced that build said that he would be releasing a new build weekly, no new build has been made since end of Nov. 2020. So I'm considering that project moribund and decided to try wulfy23's rpi4 build instead.
After flashing wulfy23's (r15323) build I quickly realized a kernel module was missing for the USB/ethernet adapter I have and want to use for my WAN port. I was able to get and install that module, then configure eth1 to be the WAN port and dhcp client. So the device gets an IP on my LAN and it also will give out an IP on its LAN port (eth0, different subnet). Further, I can access the Luci web interface from the client connected to the LAN port. I can ping internet addresses from the rpi4 itself in an ssh session.
However, the rpi4 is not routing any traffic out to the internet from the client hooked to it. I have so far not discovered the setting(s) on the rpi4 that will allow it to route traffic, whether ping or http traffic, from the client out to the internet. Another problem, which may or may not be related, is that although wulfy23's build comes with an ap (ap101) preconfigured and I have it enabled, no SSID is being broadcast.
Any suggestions as to how I can get this device functioning as intended? I've got a few years of experience fiddling with OpenWRT and a few more with DD-WRT, but there is obviously a fair amount about configuring routers that I do not understand terribly well. Any help will be much appreciated.
PS I've done a number of reflashes after trying various configuration options. The current flash is pretty vanilla with minimal tweaking.
Forwarding (with NAT) from LAN to WAN is part of the firewall function. If you name your WAN network exactly 'wan' (lower case), the default firewall is already set up for it. Unless of course the third-party build has a non standard default firewall configuration.
Thank you very much for that tip, mk24. Going in the Luci interface into Network > Interfaces and selecting the interface I'd set up (and named something other than wan), I was able, by selecting "edit," to, on the "Firewall settings" tab, assign the created interface to the preformulated WAN zone. Traffic is now being routed properly through the rpi4 out to the internet.
Now I just have to find out why the SSID is not broadcasting.
A screenshot of the LuCi "Wireless overview" page for this device can be seen at https://ibb.co/qmgRfD9. The only potentially strange thing I see there in connection with the AP interface is "Mode:Client." In the configuration for that interface I've chosen "Access point." Any hints as to a problem there that might result in the SSID not being broadcast? The "Hide ESSID" box is not ticked, btw. Thanks
PS See content of /etc/config/wireless on this device at https://pastebin.com/WGZ3VzCQ
PPS So far as I can tell, my configuration conforms very closely to options listed at https://openwrt.org/docs/guide-quick-start/basic_wifi except that I've disabled wifi security for the moment while doing initial testing (open network).
If you set encryption to none, also take out the key.
In the radio config simplify as much as possible: get rid of noscan (which I don't think does anything on 5 GHz anyway) and cell_density. Try htmode of 'HT20'.
Restart networks (
service network restart) then check logs for wifi related errors.
I made the suggested changes and restarted the network as advised. Both before and after I see in the system log a lot of this type of thing, which seems definitely wifi-related:
Fri Jan 22 22:32:57 2021 daemon.notice netifd: radio0 (3138): command failed: No error information (-524)
Fri Jan 22 22:32:57 2021 daemon.notice netifd: radio0 (3138): command failed: I/O error (-5)
Fri Jan 22 22:33:47 2021 daemon.notice netifd: radio0 (3138): Command failed: Request timed out
Fri Jan 22 22:33:47 2021 daemon.notice netifd: radio0 (3138): Command failed: Not found
Fri Jan 22 22:33:47 2021 daemon.notice netifd: radio0 (3138): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Fri Jan 22 22:33:47 2021 daemon.notice netifd: radio0 (3138): Command failed: Invalid argument
Sat Jan 23 09:36:21 2021 daemon.notice netifd: radio0 (16762): Command failed: Not found
Sat Jan 23 09:36:22 2021 daemon.notice netifd: radio0 (16762): command failed: No error information (-524)
Sat Jan 23 09:36:22 2021 daemon.notice netifd: radio0 (16777): command failed: No error information (-524)
Sat Jan 23 09:36:23 2021 daemon.notice netifd: radio0 (16777): command failed: I/O error (-5)
Sat Jan 23 09:36:54 2021 daemon.notice netifd: radio0 (16777): Command failed: Request timed out
Sat Jan 23 09:36:54 2021 daemon.notice netifd: radio0 (16777): Command failed: Not found
Sat Jan 23 09:36:54 2021 daemon.notice netifd: radio0 (16777): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Is it revelatory of anything? If so, what?
PS I should add that, when experimenting with the first, now moribund, build, the SSID was broadcasting fine. The above errors therefore do not seem to me likely to indicate bad wifi hardware.
It looks like a necessary package is missing. I think neccessary to bring wifi up on a Pi4B are:
wpad-basic (or other wpad build)
Use opkg list-installed to see if your build contains all of these.
/etc/init.d/wpad enable; /etc/init.d/wpad start
opkg list-installed shows all listed packages are present except:
iw (but I have iw-full)
kmod-mac80211 (but I have kmod-macvlan)
wpad-basic (I have wpad-openssl)
Should I be posting about this problem in wulfy23's thread (Rpi4 < $(community_build))?
Thanks for the input, wulfy23. I've run that command but I still don't see the SSID (ap101) of this rpi4 being broadcast here. This is the 1GB RAM model, btw, if that makes any difference. Bought close to 2 years ago.
kmod-mac80211 is essential. It handles most wifi operations at the kernel level, it is the link between hostapd and the chip-specific driver.
kmod-macvlan has nothing to do with wireless.
Installing kmod-mac80211 and restarting the network allows the SSID to broadcast on this device. Thanks so much for your input on this, mk24. It looks like major issues I was having are now resolved.
Afterthough: looks like an oversight that such a key module got excluded from this build, no?
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Here is the summary of what resolved issues I was seeing. First, my rpi4 was not properly routing traffic to the internet due to the fact that I had named the WAN interface something other than "wan." This resulted in the built-in firewall/routing rules not getting applied to the interface, thus leading to no routing of traffic. The resolution to that issue was, as indicated in one of my posts above (the third in this thread), to add my differently-named WAN interface to the zone containing the preformulated routing/firewall rules. Thanks to mk24 for cluing me in to that resolution.
The second issue of the SSID not broadcasting was related to a missing kernel module (kmod-mac80211) that had been erroneously omitted from the build I am using. Once I'd installed that module, the SSID began broadcasting properly and I could connect to the AP. Once again, thanks to mk24 for helping me identify where the problem lay.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.