This of course means you need a VLAN-aware switch that this single ethernet port can plug into, configured as a VLAN trunk (in Cisco terms) port. You would then want to configure one of the other switch ports as a VLAN access port assigned to VLAN 100 (untagged). This is the port you would plug your cable modem into. Then (in the simplest example) you could assign all the rest of the switch ports to VLAN 200 (untagged), and you would plug all your LAN devices into them.

- Soekris net4501 (x86, 486-class CPU) (discontinued)

- PCEngines alix2d3 (x86, AMD Geode LX800) (discontinued)

- PCEngines APU (x86, AMD T40E) (my current router/firewall) (discontinued)

I'm also currently using an APU2 as one of my wireless access points (with hostapd).

All of these have been solid machines that have given me zero problems.

The next system I plan to use is going to be a Banana Pi R4 (ARM Cortex A73), it's a solid choice for a simple router/firewall/DNS/DHCP box. It has a built-in 4-port gigabit switch where each interface can be used as normal Linux interfaces, as well as 2 SFP+ ports that are capable of supporting up to 10 gig ethernet.

It's also one of the few systems that offers true hardware offloading for connection tracking, so things like netfilter flowtables don't have to use any main CPU processing.

I'm currently experimenting with a Banana Pi R4 as a Wifi7 access point (running Debian with hostapd), however the current state of the wifi7 module for it (BPI-R4-NIC-BE14) and Linux driver (mt7996e) is still pretty young and a bit buggy (i.e., limiting transmit power to 6 dBm without patching the driver to override it, and there's apparently a lack of RF shielding which can contribute to low SNR on the receiving end). With the proper patches in place it makes a decent Wifi 6 access point. I'm hoping these issues get ironed out in the future and I can use it as a true Wifi7 AP. frank-w is doing outstanding work to help support the open source community with this new hardware.

One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.

I recently purchased a Banana Pi 4 with the 802.11be Wi-Fi 7 module to be used as an access point. It generally works well as an AP and I'm getting full speeds. However, for some reason whenever I try to communicate directly with the router/firewall (separate device on the same network) through this AP, it will intermittently drop 3/4 packets. It only happens when communicating with the router/firewall device, and only over the wlan interface on the bpi-r4. I have a similar AP setup on another embedded system (PCEngines APU2) and this has never been an issue.

I suspect there's some sort of bug with the internal 4-port switch of the bpi-r4 not playing well with the wlan interface when they're all bridged together, but digging through the logs hasn't revealed anything obvious.

It's driving me nuts!

Say we want to create a report that determines how long a machine has been down, but we only want to count time during normal operational hours (aka operational downtime).

Normally this would be as simple as counting the time between when the machine was first reported down, to when it was reported to be back up. However, since we're only allowed to count certain time ranges within a day as operational downtime, we need a way to essentially "mask out" the non-operational hours. This can be done efficiently by finding the intersection of various time ranges and summing the duration of each of these intersections.

In the case of PostgreSQL, I would start by creating a tsrange (timestamp range) that encompases the entire time range that the machine was down. I would then create multiple tsranges (one for each day the machine was down), limited to each day's operational hours. For each one of these operational hour ranges I would then take the intersection of it against the entire downtime range, and sum the duration of each of these intersecting time ranges to get the amount of operational downtime for the machine.

PostgreSQL has a number of range functions and operators that can make this very easy and efficient. In this example I would make use of the '*' operator to determine what part of two time ranges intersect, and then subtract the upper-bound (using the upper() range function) of that range intersection with its lower-bound (using the lower() range function) to get the time duration of only the "overlapping" parts of the two time ranges.

Here's a list of functions and operators that can be used on range types:

https://www.postgresql.org/docs/9.3/functions-range.html

Hope this helps.