Posted by jpluimers on 2025/04/18
I wonder how well [Wayback/Archive] H3/H2 Net Card – ODROID is supported by pfSense. It is an M.2 based PCIe network card that adds 4 ethernet ports of 2.5 gigabit each to an ODROID H2 or H3 series (so you have 6 ports total), ideal for some hefty router.
Pictures (from the above link) of the board, cases and mainboard below.
But first: Realtek NICs is not vendor supported on FreeBSD (which pfSense and OPNsense are based on).
Posted in *nix, BSD, Ethernet, FreeBSD, Hardware, Network-and-equipment, pfSense, Power User, routers | Tagged: homelab, serverbuilds | Leave a Comment »
Posted by jpluimers on 2024/07/05
Two interesting posts on fast network routing:
… I also ran into weird DNS slow-downs, which I didn’t fully diagnose. In Wireshark, it looked like my machine sent 2 DNS queries but received only 1 DNS result, and then waited for a timeout.
… Since I last used MikroTik in 2014 the software seems to have barely changed. I wish they finally implemented some table-stakes features like DNS resolution for DHCP hostnames
–jeroen
Posted in Ethernet, Hardware, LifeHacker, MikroTik, Network-and-equipment, Power User, routers | Leave a Comment »
Posted by jpluimers on 2024/03/14
Reminder: check reviews for this little device: [Wayback/Archive] Compact fanless firewall appliance offers 6x 2.5GbE ports for $230 and up – CNX Software
If referred to:
(which for EU customers went up from USD ~230 to USD ~270 the day CNX published; this might have to do with VAT and import duties [W/A])
–jeroen
Posted in Development, Hardware, Hardware Development, Network-and-equipment, pfSense, Power User, routers | Leave a Comment »
Posted by jpluimers on 2023/12/11
Last year, after an already long sequence of doing stupid things, Ubiquiti sued Brian Krebs.
For many this was a reason to think about what to replace their Ubiquiti.
My cloud key had already died, I never installed the USG router, so this is the reminder to see if anything has come up to replace the Unifi access points that is easy to manage in a self-hosted way are powered over ethernet, do the same seamless handover and cooperative WiFi antenna management.
Some links from back then:
Posted in Cloud Key, Ethernet, Hardware, MikroTik, Network-and-equipment, pfSense, Power User, routers, Ubiquiti, Unifi-Ubiquiti, USG Ubiquiti Unifi Security Gateway, WiFi | Leave a Comment »
Posted by jpluimers on 2023/10/27
Some links on the pfSense hardware I am planning to use.
Whereas apu1 was totally different, apu2, apu3, apu4 and apu6 are very similar. The letters after the first digit indicate evolution of the boards. The first and last digit set apart features. Together, they form a confusing matrix which is not really made clear at the PC Engines web-site as some intermediate categories are missing which makes it hard to get an overview.
Basically their shop site has the list of most current products and is easiest to get links to the actual product names. Like many Swiss companies, they accept multiple currencies, so there are three links to the shop:
Posted in APU, Hardware, Network-and-equipment, pfSense, Power User, routers | Leave a Comment »
Posted by jpluimers on 2023/04/24
It was great while it lasted, so be sure to order within the next 12 months as [Wayback/Archive] PC Engines apu platform EOL:
PC Engines apu platform EOL The end is near ! After a long production run, AMD will accept last orders for the SOC used in our apu2/3/4/5/6 boards by end of June 2023. apu phase-out We will do a life-time buy for a quantity of the AMD SOC and some other key components. We are willing to schedule customer shipments through end of June 2024. There is a 26 week lead time on the AMD SOC, expect limited supply until late 2023. First ordered, first served. Binding orders may be required for large quantities.New products ? Despite having used considerable quantities of AMD processors and Intel NICs, we don’t get adequate design support for new projects. In addition, the x86 silicon currently offered is not very appealing for our niche of passively cooled boards. After about 20 years of WRAP, ALIX and APU, it is time for me to move on to different things. Thank you ! I would like to thank all of our customers for their business, and sometimes patience.
–jeroen
Posted in APU, Hardware, Network-and-equipment, pfSense, Power User, routers | Leave a Comment »
Posted by jpluimers on 2023/04/13
MikroTik switches and routers are very flexible to configure, as everything is done through [Wayback/Archive] RouterOS settings.
This means that given enough ports, you can split a physical switch into logical switches. This can be very convenient when you run multiple networks without VLAN.
Earlier this week, I already wrote about Torching a specific port on a MikroTik switch or router running RouterOS which involved turning off hardware acceleration off for specific ports in order to have the flow through the underlying switch chip prohibiting torch and filter features.
For splitting noticing which ports are connected to which switch chip is also important: splitting works best if you can configure each logical switch to exclusively use network ports on one switch chip.
This post was to both research how to configure this, and if my MikroTik devices would allow for hardware acelleration.
Here are some links that should help me with configuring (via [Wayback/Archive] mikrotik split switch in two – Google Search):
–jeroen
Posted in Development, Hardware, MikroTik, Network-and-equipment, Power User, RouterOS, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2023/04/11
On most recent [Wayback/Archive] RouterOS configurations of MikroTik Routers and Switches, running [Wayback/Archive] Torch a port will show zero traffic when they are part of a bridge configuration. The same holds for the Packet Sniffer.
The reason is that these bridges have hardware acceleration turned on, which makes all traffic go through the switch chip instead of the device CPU. Torch works on the CPU level, so won’t show hardly any traffic except for some configuration stuff (depending on the combination of switch chip and CPU type).
This is not documented in the Torch documentation, but it is documented in the Packet Sniffer documentation.
Further reading:
Note: Unicast traffic between Wireless clients with client-to-client forwarding enabled will not be visible to sniffer tool. Packets that are processed with hardware offloading enabled bridge will also not be visible (unknown unicast, broadcast and some multicast traffic will be visible to sniffer tool).
As the ethernet ports are marked as S(laves) in the tables, I would assume that they are member ports of bridges and “hardware acceleration” is enabled (the value of hw in the respective rows of /interface bridge port is set to yes). So any frames which pass through these ports to other ports of the same switch chip are counted by the switch chip counters, but as they never get to the CPU, the torch cannot see them.
Consider the following scenario, you setup a bridge and have enabled hardware offloading in order to maximize the throughput for your device, as a result your device is working as a switch, but you want to use Sniffer or Torch tools for debugging purposes, or maybe you want to implement packet logging.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 hw=yes interface=ether1 learn=yes add bridge=bridge1 hw=yes interface=ether2 learn=yes
When running Sniffer or Torch tool to capture packets you might notice that barely any packets are visible, only some unicast packets, but mostly broadcast/multicast packets are captured, while the interfaces report that much larger traffic is flowing through certain interfaces than the traffic that was captured. Since RouterOS v6.41 if you add two or more Ethernet interfaces to a bridge and enable Hardware Offloading, then the switch chip will be used to forward packets between ports. To understand why only some packets are captured, we must first examine how the switch chip is interconnected with the CPU, in this example we can use a block diagram from a generic 5-Port Ethernet router:
Generic Ethernet router
For this device each Ethernet port is connected to the switch chip and the switch chip is connected to the CPU using the CPU port (sometimes called the switch-cpu port). For packets to be visible in Sniffer tools, the packet must be sent from an Ethernet port to the CPU port, this means that the packet must be destined to the CPU port (destination MAC address of the packet matches the bridge’s MAC address) or the packet’s MAC address has not be learnt (packet is flooded to all ports), this behavior is because of MAC learning·The switch chip keeps a list of MAC addresses and ports called the Hosts table· Whenever a packet needs to be forwarded, the switch chip checks the packet’s destination MAC address against the hosts table to find which port should it use to forward the packet. If the switch chip cannot find the destination MAC address, then the packet is flooded to all ports (including the CPU port). In situations where packet is supposed to be forwarded from, for example, ether1 to ether2 and the MAC address for the device behind ether2 is in the hosts table, then the packet is never sent to the CPU and therefore will not be visible to Sniffer or Torch tool..
Packets with a destination MAC address that has been learned will not be sent to the CPU since the packets are not not being flooded to all ports. If you do need to send certain packets to the CPU for packet analyser or for Firewall, then it is possible to copy or redirect the packet to the CPU by using ACL rules. Below is an example how to send a copy of packets that are meant for
4C:5E:0C:4D:12:4B:/interface ethernet switch ruleadd copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF ports=ether1 switch=switch1Note: If the packet is sent to the CPU, then the packet must be processed by the CPU, this increases the CPU load.
The following script is used to associate IP address of directly connected stations to physical port of the switch.
Warning: Running this script will make the CPU go to 100% for about 30-40 seconds, so please run the script when needed or by using scheduler.
–jeroen
Posted in Development, Hardware, MikroTik, Power User, RouterOS, routers, Scripting, Software Development | 1 Comment »
Posted by jpluimers on 2022/08/12
From [Wayback Archive.is blog — Why has the URL “archive-li” changed to…:
Why has the URL “archive-li” changed to “archive-ph”, and will this affect saved bookmarks at any time in the future?
Anonymous
This is temporary and only for some countries. All 7 domains work, so you do not need to change the bookmarks.
In The Netherlands all Archive Today domains redirect to archive.ph using a HTTP 302 redirect.
This caused trouble at my home location, but not at my brother, so I searched for local issues.
In the end, it was because I have dual WAN as network load balancing at home.
Modifying the routing table so traffic for 54.37.18.234 goes to WAN1 was my solution.
Posted in .NET, Development, Hardware, Network-and-equipment, Power User, PowerShell, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2022/08/05
I tried the solution in [Wayback/Archive.is] Fritz!box 7590 interface extremely slow : fritzbox (remove the some 30-40 unused machines from the network overview), but it didn’t matter: since Fritz!OS 7.x, the Fritz!Box 7490 UI is just very very slow: each page takes 10+ seconds to load.
Hopefully I can get rid of these and move to pfSense based hardware eventually.
–jeroen
Posted in Fritz!, Fritz!Box, Hardware, Network-and-equipment, pfSense, Power User, routers | Leave a Comment »
The Wiert Corner - irregular stream of stuff 