Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - kuleszdl

#1
@tsgan: May I ask how much CPU ressources (name idle) are left on your Nanopi platform when running Opnsense with WAN connected?

One thing I'd like to share with this community: It seems like some other people who bought the rockpro64 boards (rk3399) from Pine64 have been also experimenting with adding more poreful NICs using the PCIe slot and running OpenWRT on it.

The Pine64 people are now thinking about providing a case for this board for exactly this router use case. You can read more about it on their blog:

https://www.pine64.org/2020/04/15/april-update-ce-fcc-software-update-and-diy-router/

Since I have the rockpro64 and the NAS case already, I thought about setting this up with OPNSense and just "wasting" the extra room in the case. But I wasn't successful in building OPNSense for arm64 so far, yet,
#2
Thank you for providing this first build! I was keen to see how HBSD 12.1 would perform, so I tried the image on a APU 1D4 that was running the latest stable (currently 20.1.4) before. I am using the base unit with only the stock 16G msata card (no wifi installed, no USB addons). With the switch to HBSD 12.1 I was hoping for better throughput (due to newer Realtek drivers) and lower power consumption.

The good news is that the 20.7 version seems to be working without  regressions in this very simple test so far. However, I could not observe any improvements regarding throughput or power consumption. I am still limited to around 350 Mbps of my Gigabit line in various speed tests and the box consumes around 9.5-10 Watts in idle. In comparison, Linux-based systems consume only around 5.5-6 Watts and deliver gigabit speed on the very same hardware.

I noticed some python3 and php processes that are keeping both cpu cores quite busy all the time. But this has been already the case in the 20.1 series.
#3
Hardware and Performance / Re: NanoPi R2S
April 09, 2020, 06:10:46 PM
This device is being discussed here:

https://forum.opnsense.org/index.php?topic=12186.0

Regarding the performance, you can check e.g. the geekbench results which suggest that the J3060 is about 1/3 faster:

https://browser.geekbench.com/v5/cpu/1669137
https://browser.geekbench.com/v5/cpu/1470518

OT: Personally I am rather looking at getting OPNSense to work on my Pine64 Rockpro64 (https://www.pine64.org/rockpro64/). Unlike the NaniPI R2S it has an PCIe slot and would allow to add a decent NIC instead of using the onboard crap that comes usually soldered to these boards.
#4
Hi,

for those of you who managed to build an aarch64 image (e.g. for the NanoPi R1): Which FreeBSD version did you use for compiling and which OPNSense version (20.1 or 20.7) did you build? I tried to build 20.1 using FreeBSD 12.1 and failed.
#5
OPNSense sollte sich an dieser Stelle doch wieder jeder andere DHCP-Client verhalten, d.h. seitens der Fritzbox sollte keine weitere Konfiguration nötig sein.

@MartinMV: Wenn Du den Rechner direkt an den Port steckst, an dem jetzt OPNSense hängt, dann kannst Du einen Ping auf 8.8.8.8 absetzen?
#6
Normalerweise sollte das ohne Zusatzkonfiuguration out-of-the-box laufen, ohne exposed host und sonstige Scherze. Was ich mir aber vorstellen könnte: Hast Du im WAN-Interface die Option

Block private networks

aktiviert? Falls ja, nimm sie mal raus. Die OPNSense-Kiste bekommt ja eine IP aus einem privaten Bereich (bei den Fritzboxen normalerweise 192.168.178.x), und vermutlich blockt sie wegen dieser Option alle Pakete, die von der Fritzbox kommen.
#7
Hi,

I recently played around with an OPNSense box with an attached USB network interface. Everything was fine, until I removed the usb interface during operation. After that, the whole system became non-operational.

I investigated this and it seems that removing the interface resulted in a reboot, but since on the next boot the system noticed that something has changed in the interfaces, it has reset all interfaces to default. I understand that this makes sense security-wise, but especially in cases where

- removable interfaces are used and
- these interfaces are neither configured as lan or wan but as some optional interface

resetting *all* interfaces just because one was disconnected seems a bit over the top to me. And yes, I know that one gets asked on the next boot, but this is only visible on the local console...

Is this behavior really intended to be this harsh?