| ▲ | zokier 3 days ago |
| I love OpenWrt. But I wished there was something similar but for "big" (in a relative sense) devices. I feel lot of the constraints OpenWrt is based on are not really that applicable when you have hundreds of megabytes of flash and RAM, and that is starting to become a common thing for routers these days. Even their own OpenWrt One router has 256M flash and a full gigabyte of RAM. That is not all that resource constrained anymore. What I would love is to have something that would be closer to "normal" linux distro while getting the networking goodies and ease of configuration from OpenWrt. |
|
| ▲ | thisislife2 3 days ago | parent | next [-] |
| I have the opposite complaint. I wish OpenWRT ran on low-resource routers like those really cheap TP-link ones. DD-WRT does support a few of it, and my personal opinion is that it is better optimised than OpenWRT. By the way, you should explore OpenBSD ( https://openbsdrouterguide.net/ ). |
| |
| ▲ | imiric 2 days ago | parent | next [-] | | Thanks for the OpenBSD guide. Do you know whether 10Gb NICs are supported in OpenBSD, and can the link be fully saturated? I'd be interested in building a DIY router on OpenBSD, but I need support for 10Gb SFP+, with an upgrade path beyond that. | | | |
| ▲ | zokier 3 days ago | parent | prev [-] | | Yeah, I know openbsd is a thing. I just like Linux too much. |
|
|
| ▲ | jauntywundrkind 3 days ago | parent | prev | next [-] |
| Strongly agreed. I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together. I'm super glad openwrt exists, and their uci config predates systemd's attempt to build a cohesive consistent whole system configuration pattern & is epic, but given the capabilities of these systems it feels so worthwhile to de-specialize the environment, to make it more boring. What I really want is Kubernetes oriented tools that can manage hostapd & something like dawn or openert's usteer for band/ap steering. And some other ancillary wifi tools. Maybe maybe a setup for radius/enterprise, instead of just psk. You can do so much more with it, but at its core openwrt is 90% packaging for openwrt. It's not even particularly super well tuned hostapd: theres so much wireless config one can go try & enable that really is just additional 802.11 specs hostapd supports, they may improve your openwrt wifi experience. |
| |
| ▲ | freetime2 3 days ago | parent | next [-] | | > I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together. I agree. I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing. I thought about trying to set up an Ubuntu (or other popular distro) box as a router, which I think would be much easier to maintain over time. But my concern is that I might overlook some important config that is set by default in OpenWrt, and leave my machine vulnerable to attack. Having a web UI that I can log into and view/make config changes is also kind of nice. Are there any good out-of-the-box solutions or guides for doing this? (I know that OPNSense/PFSense are really popular among homelab users, but unfortunately the Marvell NICs in my mini PC are not supported in FreeBSD). [1] https://openwrt.org/docs/guide-user/installation/openwrt_x86... | | |
| ▲ | c0wb0yc0d3r 3 days ago | parent [-] | | > I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. I have been doing this myself recently. The docs around this are pretty out of date. The docs as they’re written only work for the ext4 images if I remember correctly. I got it to work with the squashfs version, but it was really janky. The problem is the OS just writes the to the empty space at the end of the squash partition without changing the partition table. I could only successfully get it working if resized the partition on first boot before the writable overlay is created. > And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing. I feel similarly about the process. There is either a command or a place on disk where you can put files to protect them across upgrades, but I can’t remember just now. I think it works that way because it’s targeted at embedded devices where I would think you typically bake everything you need into the root file system at compile time. I’m not an embedded engineer so maybe there are better ways of doing it. | | |
| ▲ | freetime2 3 days ago | parent [-] | | > The docs as they’re written only work for the ext4 images if I remember correctly I was using an ext4 image and still ran into problems. And in addition to the scripts on the page that I linked above, I also tried this other variation from their docs [1]. They all ended up rendering the sytem unbootable. Eventually I think I ended up using an Ubuntu Live ISO to boot the system and made the change there. Definitely a bit of a pain, and according to the docs it sounds like something I would need to do again after an upgrade. I also tried following their steps for "building your own image with larger partition size" [2], but couldn't get that to work either. I had fun playing around with OpenWrt. But in the end was forced to admit that I didn't really need any features in OpenWrt, and whatever benefits I was getting from it were not worth the effort. Also, even a minute of downtime for a reboot was pretty annoying to my family when they were trying to stream a movie, etc. [1] https://openwrt.org/docs/guide-user/advanced/expand_root [2] https://openwrt.org/docs/guide-user/installation/openwrt_x86... | | |
|
| |
| ▲ | the_biot 3 days ago | parent | prev [-] | | > I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together. Yup, that's the answer. Debian is rock solid, and a script with a bunch of iptables and iproute2 commands is so much simpler than the mess that is OpenWRT's network setup. I only use it for dumb APs, and even then it's questionable -- the UI is nice, but configuring it is unnecessarily complex IMHO. |
|
|
| ▲ | hagbard_c 3 days ago | parent | prev | next [-] |
| I run OpenWRT on a 'big' device, this being a container on a Proxmox-managed DL380 G7. It works fine in this context, performance is good enough to be able to easily saturate the gigabit fibre link without breaking into a sweat. Installing OpenWRT on such a device comes down to downloading openwrt-${version}-x86-64-rootfs.tar.gz and unpacking it in the target location. Boot the container or VM (or old PC or whatever) and follow the normal OpenWRT configuration procedure. Updating such an installation comes down to making a configuration backup in OpenWRT, unpacking the new distribution and restoring the configuration backup to the new install. Given the low resource requirements for such an installation it makes sense to first clone the working container or VM and performing the upgrade on one of the instances so you always have a working instance at hand. |
| |
| ▲ | zokier 3 days ago | parent [-] | | Sure, openwrt works. I too have run it on x86 vm at a time. That being said, there is lot that could be improved. My biggest gripe is the weird filesystem layout with overlays and stuff in /tmp and whatnot. I can see it being needed on tiny devices, but on bigger ones can I just have regular ext4/xfs gpt partitions please? Another thing is just replacing the tiny versions of software with regular ones, like busybox->gnu or dropbear->openssh etc. Systemd could be at least considered as init. All of this kind of things make sense when you consider openwrts origins. But on "big" system I'd just much rather have it be closer to "normal" Linux. | | |
| ▲ | hagbard_c 9 hours ago | parent [-] | | OpenWRT on x86_64 does not use overlay mounts, here's an overview of a current instance running in a Proxmox-managed container: /dev/mapper/pve-vm--500--disk--0 on / type ext4 (rw,relatime,stripe=512)
none on /dev type tmpfs (rw,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
... more proc mounts...
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
... more sysfs mounts
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
udev on /dev/net type devtmpfs (rw,nosuid,relatime,size=65960672k,nr_inodes=16490168,mode=755,inode64)
none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
lxcfs on /proc/cpuinfo type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
... more lxcfs mounts
udev on /dev/full type devtmpfs (rw,nosuid,relatime,size=65960672k,nr_inodes=16490168,mode=755,inode64)
... more udev mounts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
... more devpts mounts
none on /proc/sys/kernel/random/boot_id type tmpfs (ro,nosuid,nodev,noexec,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,uid=100000,gid=100000,inode64)
No overlays, just a normal ext4 filesystem. Data in /etc is stored in /etc, data in /var is stored in /var, etc. OpenWRT running from a filesystem image is 'just another Linux distribution which happens to run the same software as that re-flashed router'. |
|
|
|
| ▲ | opan 3 days ago | parent | prev | next [-] |
| Something with a more normal way of updating the packages and OS would be nice. I thought I'd heard someone was working on an Alpine-based thing a few years ago, but haven't heard anything since. |
| |
| ▲ | imiric 2 days ago | parent | next [-] | | Agreed. When I last tried to update packages there was a scary disclaimer about it being likely to break the system, and that flashing a new firmware is preferred. I nope'd out of that, and don't wish to go through the hassle of flashing again, so my AP is running a year+ old version. It works fine, and I'm not too concerned about it, but I would still like to be able to easily upgrade the system without worrying about breaking it. | |
| ▲ | zokier 3 days ago | parent | prev [-] | | They did replace opkg with apk recently https://forum.openwrt.org/t/major-change-notice-new-package-... |
|
|
| ▲ | m463 2 days ago | parent | prev [-] |
| zyxel gs1900-48 - 48-port gigabit switch supported by openwrt (also versions with fewer ports) |
