Raspberry pi4b w/ 8gb ram - Which I have been trying to configure as a "travel router".

Wan interface wifi using rtl8812au usb-wifi adapter. (Needs to be compiled from github repo)

Lan interface the rpi's built-in ethernet.
Iptables firewall.
Unbound dns server for local caching and DoT to upstream.

That is all it needs to do.

But I have had nothing but trouble trying to configure this in Raspbian Bookworm and in Bullseye.

Because ...
The rtl8812au driver will not compile on Raspbian. Forcing me to use the Pi's built-in wifi which has poor reception.
The network keeps going down (literally) every 2 minutes. Due to iptables firewall suddenly deciding to drop all packets, and needing to be manually flushed and restarted.
Unbound just stopping and eventually unloading it's service for no reason, and needing to be manually restarted.

But I have setup a sff PC to do this task in Slackware15-64, and it works. Except that sff PC is still not small enough for "travel".

Is Slackware arm64 a mature enough OS to do this task I need?

https://github.com/morrownr/8812au-20210820
based on this it is not the OS, but the wifi adapter itself which is unreliable.
I think if it works, it will work with any OS, the setup/configuration is more or less the same.

All the severe unreliability problems I have had trying to do it with Raspian, were happening with stock Pi hardware - because the rtl8812au driver would not compile.

My question is, can Slackware arm64 run better with the stock Pi hardware?

The rtl8812au wifi did compile and works ok when connected to a PC with Slackware64-15.

You not need Unbound. Slackware ships with Dnsmasq that is perfect for this type of project you are working on.

Iptables does not cause:
So that is likely an issue with Rasbperry Pi OS. Unrelated to Slackware.

Slackware ARM 15.0 is a 32 bit OS. It will be much slower and have the limitation to use 4GB of RAM. Not ideal for the Raspberry pi 4 with 8GB of RAM. Slackware Aarch64/Arm64 is still in development. The "current" branch is the development branch of Slackware.

With that said, I have a wireless router I made using a RockPro64 and generic PCIe realtek wireless chipset I bought for 15$. I do not see why the Raspberry Pi 4 would work differently, aside from having the requirement of a USB wireless adapter. Indeed, the built-in wifi on the Pi 4 is lacking. The Pi 4 has a large performance increase with Slackware-current Aarch64.

You should consider using this repository to grab the source code for your Wireless adapter: https://github.com/aircrack-ng/rtl8812au

It builds the 88XXau kernel module out of tree. So keep that in mind.

Build it manually. It works well on Slackware ARM 15.0 and -current. I use it regularly with the hostapd package for a wireless access point in conjunction with dnsmasq. Generally, Slackware-current is very stable and great for projects like this.

2 members found this post helpful.

Thank you.

So 32-bit arm is stable but not good for a pi4b with 8gb ram.
And 64-bit arm is still a work under development?

But my user needs are for something that "just works" after I am done configuring it. Other than selecting from available wifi hotspots to connect to.

So I guess Slackware arm/arm64 would not be good for me.

I must wonder why Raspios was so glitchy on my pi4b even with stock hw. If Raspios was this bad for everyone, there would be some popular outcry. My pi4b might have hardware problems. Either the pi4b itself or the usb flash drive it is set to boot from. Flash drives are always going bad.

I will try again with a usb harddrive. If it is still so buggy, then it must be the pi4b itself vs linux, and I would give up trying to run it on linux. There is freebsd pretty stable for the arm64. If that does not work either, then it is the pi4b's hardware gone bad.

There are so many different builds of dnsmasq, with different functionality details, all being called "dnsmasq". Even the version numbers run different between distros. But most of them can not handle DoT encrypted connections to the upstream, and require dnscrypt as a dns proxy. So if I would be using something else anyways, I would rather just keep Unbound. It is a known factor and has good configuration options.