pfSense as router OS?

I understand your OS does what it needs to but what about pfSense as OS? Isn’t is much more powerful and professional? Your router also seems to be powerful enough (x86 like, where pfSense lives). I must say I don’t know much about the porting process and how hard it would be and AFAIK there’s no ARM port of pfSense but there’s work on it. What do you think? Is this even a feasible stretch goal? (3 year warranty isn’t that exciting because hardware usually doesn’t break like that)

PS: yes this forum software is modern and stuff but is has no real hierarchy and no pages and a few more things which would make it more kind of professional (instead of hipster like) and I don’t know how your experience is but mine is that once you start to have a few more pages it’s basically unusable.

It’s not just about a generic ARM support, there must be support for the particular SoC and I’m afraid there is nothing like that in pfSense.

Forum - Do you have any tip for a better software?

Too bad pfSense isn’t going to be the OS in the near future. I think this would be kind of an ultimate goal.

I would have said simply phpBB or SMF but in case you want JS-heavy forums, I rechecked some alternatives and non of them (nodeBB, Flarum) even offered simple pages (even plugins which would allow static pages are not enough so solve the issues with these new “next-gen” forums) (other issues aside). AFAIK the “old” forums are still preferred in not only big forums, but also in professional, non-hipster, environments (yes that sounds lol but it’s true so far I’ve seen). I noticed these JS-heavy forums also require a lot of resources (even my 84W TDP CPU struggles relatively often, not sure if it’s because of all the JS and/or because the server was slow). Just from my experience, despite all these new JS features I find them unusable unorganized. There are also lengthier posts by others who tested, in this case, Discourse and they have the same problems. I also don’t like that they require JS in the first place.

I agree that this device could be a better alternative to PC engines’s APU2, but only if it can run pf/OPNsense.
You guys should get in touch with http://www.semihalf.com/. They do have experience porting ARM/Marvell drivers to FreeBSD.

I doubt that pfsense will run on any non-PC hardware without heavy modifications. pfSense is FreeBSD based OS, and FreeBSD support for ARM is still very limited (only few boards are supported) + you will need all drivers for the SOC itself. So if you need pfSense i would recommend to use x86 based hardware for it.

Also i dont think that WIFI card support on FreeBSD is mature enough to get access point in AC standard up and running.

If the FDT is correct i think most drivers for the SoC should be there and simply work. USB3 may and AC-Wifi will be problematic. Hardware revision changes may cause new bugs but nothing impossible.

But this is only valid for recent (>=10) versions of FreeBSD and may not be valid for pfSense. And it may still require a lot of compiling.

No, its not the case. Take a look how much efforts costs porting of the FreeBSD to RPi. Its a lot of work in the kernel and will require a lot of knowledge, especially because many of the typical embedded staff (switches, i2c, gpio, etc.) are not yet ported to the arm. List of the supported ARM chipsets is very limited and i don’t see our SoC in it. And yes, ARM related work is done mostly in -10 and -HEAD. So again, if you are looking for hardware to run pfSense - this router is not a very good choice.

Most blocks are there already. Armada XP is its not-so-embedded sibling.
The difference between RPi and Turris Omnia: RPi was a complete new platform.
Turris Omnia is like a new mainboard with some shiny new extras for x86.

This still does not make it a good choice for the near future.

But while checking the base hardware blocks i miss some reference to the network accelerator on Armada 385. But this is totally off topic.

If you need a low-power board for pfSense, I’d suggest pcEngines Apu 2. It even has 2 mini-PCIe slots and an mSATA slot.

Just to make a suggestion - a upcoming star on the router-os-heavens might not be openwrt or pfsense, but McDebian - https://github.com/Chadster766/McDebian
There you will (once) get the full set of features of debian…

If it is just a plain Debian build for the Linksys WRT1900\1200 platform - no. Really, i think that traditional Debian configuration sucks when we are talking about wifi AP or similar use-cases. From my POV such device should provide some GUI or at least CLI for the most basic functions. But i am agree that OpenWRT on such modern devices do have some limitations - e.g. many applications are compiled without debug support to save space, special libc without any real need, etc.

Hmm, can’t see the limitations in that… musl libc is the most modern libc and debian just to conservative to adapt it and most distros come without debug info…
But what makes OpenWrt superior as a router-distro are the newer inventions like procd/fw3/netifd and so, imho, there’s nothing like it in debian

if you want to run other distros, why not just put them into a lxc-container?

(i’m using buildroot for example, but that needs a lot of configuration-work, though)

I wont start religious wars about musl libc vs glibc, but just want to mention that goals of this projects are different. Regarding “most distros come without debug info” - it is completely wrong statement. In Debian based and RHEL based you can get -debug packages and use gdb for whatever you need. In OpenWRT it is not possible (you have to rebuild package) and moreover, some critical packages, like hostapd, are stripped from debug-level logging messages to save some space.
It does make a perfect sense if we are talking about 4-8Mb flash, but not for the our device, when this optimization is completely useless and will just add some pain if debugging. And of course i am agree that OpenWRT is a perfect (probably the best) router-distro, i just mentioned that for the modern devices it has some issues. Hopefully project will move in a right direction.

About LXC/OpenWRT - you can find my presentation here, it really works, and works pretty cool.

yeah, that’s right, but you still have to install them and i usually build my own openwrt images without using sstrip and so on, didn’t think about that

[quote]some critical packages, like hostapd, are stripped from debug-level logging messages to save some space
[/quote]

i agree, wouldn’t hurt to drop some of those “optimiziation-patches”

But what makes OpenWrt superior as a router-distro are the newer inventions like procd/fw3/netifd and so, imho, there’s nothing like it in debian

Debian has something like procd. It is called systemd and i really like it.

some critical packages, like hostapd, are stripped from debug-level logging messages to save some space

i agree, wouldn’t hurt to drop some of those “optimiziation-patches”

No need to patch something. It is configurable.
Set CONFIG_WPA_MSG_MIN_PRIORITY to 0 for hostapd/wpa_supplicant/wpad’ log output. Mission accomplished. I would prefer 2 though.
For used libc (musl, uclibc, (e)glibc), libstdc++/uclibc++, debug info etc there are also config options.

But please don’t whine because you are unable to reach the full speed because all these optional debug calls are limiting the execution speed.

Sorry, you dont have any idea of what you talking about. Try this yourself please. Or just read the official documentation:

Note that recent versions of openwrt ship with a version of hostapd
which has verbose debug messages disabled in order to save on space (see
https://dev.openwrt.org/ticket/15658 ).

Also see https://dev.openwrt.org/ticket/8847 about reason to do that. Moreover in recent (CC) hostapd packages debug is also stripped.

P.S. please don’t post thing you never checked next time. Thank you.

If you only want the debug output of hostapd with the official packages then ignore the rest. It is optimized out by the compiler and won’t change in the near future.

The rest:

https://dev.openwrt.org/ticket/8847#comment:2 says exactly what i meant. There exists a menuconfig option (Network -> Minimum debug message priority) that sets CONFIG_WPA_MSG_MIN_PRIORITY in .config. Setting this to 0 adds all debug output. Default value is 3 so anything with level < 3 will be removed by the compiler.

Setting CONFIG_NO_STDOUT_DEBUG=y as proposed in 8847 was never added.

Changing the .config-Setting and rebuilding also changes the uncompressed file size about 220k. Tried it!

https://wiki.openwrt.org/doc/devel/debugging#logging_hostapd_behaviour makes it clear: you have to recompile and strip is fine. sstrip is not but this is not the default. In the end this won’t matter as you will want to change something in code so you will have to build it yourself.

No, its not, of course. 0 level will never give you debug output for the hostapd. And you probably never really tried it because you writing such nonsense. E.g. most of the 802.11i and non of the 802.11r messages will ever be displayed.

You correct that CONFIG_NO_STDOUT_DEBUG=y been never added. But if you
will read tickets i mentioned carefully, you will be able to find that it was solved in a different way, with this commit.

Thats why ticket 15658 is still opened, and thats why official documentation mentions that issue. And real debug output is always like “2” or so. Another bad thing is that it just silently ignoring debug output switch, so first time its very confusing.
UPDATE: it is 3, see hostapd/Config.in

P.S. i personally want to submit a patch which will make -debug package, because now its hard, if ever possible, to debug hostapd when something goes wrong, especially with WPA2-EAP or FT-* ciphers. And again, please read tickets i mentioned. See also this thread.

Ahh, i got your point, you mentioned that i need to change config and rebuild it. But thats what i told from the beginning ) And the thing is that OpenWRT is full of such restrictions, making perfect sense for the tiny flash, but absolutely useless on the router with a higher class. Hostapd is just a first one comes to my mind, but its really a lot of them, e.g. many packages are compiled with very-minimal feature set, some of the functionality often is stripped to reduce resulted binary size, etc. Also openwrt build infrastructure is kind of dependency hell and if you will compare it with most of the modern package managers you will find that it does not look very good. E.g. i been never able to build entire package tree without many manual steps, because some of the distfiles are fetched from the dead svn servers, some dependencies are missing, etc.,etc. Parallel builds are also very unreliable.

I understand your OS does what it needs to but what about pfSense as OS?
Isn’t is much more powerful and professional? Your router also seems to
be powerful enough (x86 like, where pfSense lives). I must say I don’t
know much about the porting process and how hard it would be and AFAIK
there’s no ARM port of pfSense but there’s work on it. What do you
think? Is this even a feasible stretch goal? (3 year warranty isn’t that
exciting because hardware usually doesn’t break like that)

IPFire is a better firewall OS IMO and supports ARM already. Of course, it is kinda buggy and does not support just any ARM hardware, but at least it has some support already.