I am using nano pi r2s as openwrt as home router, but i want to add a (lowcost) device to do ips/ids.
Do you think the nano r2s i viable as ips/ids,
or itâs better to get a r4s or bpi-w2?
Do you think the Orange Pi R1 Plus Orange Pi R1 Plus router SBC features Rockchip RK3328, Dual GbE - CNX Software is compatible? (same hardware as the nanopi r2s)
I donât think rk3328 is a best solution for ids/ips.
If you have a small network and less device then make rk3399 nanopir4s will do the job.
Ids did work in my test but i donât think use it for more than a day as i had just set it up to see how much of load it can take.
From my perspective of view this is the wrong way to do business. One need not to support this clientele.
I do not want to be offensive, so I do apologies if this could be seen so. IPFIRE is a great product and should focus on customers which valuate this.
Again I do not to be too hard in my argumentation. I only want to support Michaels point of view from some one who dealt a lot with business concepts in the past.
What is bad about a serial console?
This interface is just very simple and used for decades. And thus IMO the best solution for the system console. No requirements for an adequate graphic hw and keyboard interface.
The serial console is yet another failure point. I find that SBC can need to be rebooted (uncleanly) or the UART adapter unplugged/plugged to get the arrangement to respond. Iâve drilled a hole in the case of my R1S, so that the serial adapter can be permanently in place, because the system breaks so often. The R5S also does not have external access to the UART pins.
The need for serial adapter is also a deterrent for less experienced users, who might otherwise be able to install & operate IPFire.
I canât see any benefits with this board. As long as the CPU wonât get their L3 cache Iâm not interested into more cores. Itâs the same why the old AMD APUs are so âlowâ. Therefore the board is at least 2 years too late.
In response to recent discussions on this site, Iâd like to make a plea for continued Raspberry Pi 4 (RPi4) support. Primarily because it works very well for home firewalls*.
I currently run 64-bit IPFire on a 2GB RPi4, with three USB Ethernet adapters, to provide a Red+Orange+Blue+Green firewall fronting a domestic broadband connection.
The RPi4 might not handle more demanding situations, but it copes well with the throughput of a typical domestic firewall, albeit one running at only 25mb/s (âfiber to cabinetâ speed).
Equally importantly, it also does a good job of meeting the other primary requirements of a domestic firewall; itâs small and reliable, draws little power, needs no moving parts (fans etc), and is relatively cheap. This makes the RPi4 a useful platform to support, especially as there are very few alternatives that do as good a job of meeting all the domestic firewall requirements.
* I should note that, while the Rpi4 works well as a firewall, the rather odd bus architecture of the earlier variants (1, 2 and 3) means that they do not.
I have been following this thread and despite developers saying âARM is deadâ I am glad to see that this isnât the case.
There is a potentially suitable device (industrial grade with long term support, 1GHz, 2GB RAM, 16GB eMMC, 2x GbE) that is well integrated into Debian and comes with DTBâs and support. I think Michaelâs post #4 was hearedâŠ
After flashing the latest aarch64 release and booting from SD the boot process halted. There was no graphics output at all (different to the vendorâs reference image) and UART output just reported lots of hardware errors - I assume the kernel could not access all resources due to missing hardware definitions/addresses.
Since I am new to IPFire and I am not familiar with architectural issues - some questions:
IPFire is based upon a standard linux kernel, so why doesnât it incorporate the drivers that are integrated since 2020?
Isnât there a âbasicâ (e.g. generic) support for common devices for any kind of boards like USB, MMC, NIC, DP/HDMI?
Can I integrate DTBâs on my own?
How does the build process look like, is there a âhandâs onâ manual?
I believe this is related to 32 bit ARM. That will eventually be stopped. It has already been marked as a legacy release in the secondary architectures section of the download. Somewhere it will be marked as being deprecated and then stopped.
64bit ARM is still being supported - aarch64. Even there the concern is that every new arm system needs to end up having IPFire custom tuned to be able to work. That is not really supportable, when the devs only have a few examples of the hardware and there are so few core devs working on IPFire.
I can provide input on some of your questions.
IPFire has all the drivers that are in the kernel at the release currently running - 5.15.49. Unfortunately, not all hardware suppliers submit their drivers to the Linux Kernel team to be integrated.
https://wiki.ipfire.org/devel/ipfire-2-x/build-howto
Bear in mind that if you are looking at integrating specific drivers into the build then you can not just build them and add them in.
For security of the firewall, all kernel modules are signed in the build and after the build is completed the key is deleted so no one can ever build a module or rootkit against the IPFire kernel. So to add an additional driver you will have to build the whole kernel and add that to your build process.
If you know the specific driver and it is GPL compatible then you can either submit a patch for the addition of the driver. https://wiki.ipfire.org/devel/submit-patches https://community.ipfire.org/t/arm-sbc-support-discussion/2650/68
The other alternative is to raise the driver requirement as a bug but that may take some time as there are only a few people capable of dealing with the integration of drivers into IPFire
For your remaining questions other people with more knowledge of arm on IPFire will have to provide answers.
