pak9rabid

You can still use the iptables interface for nftables rules if you'd like, but I think you miss out on things like atomic application of rulesets, ranges, lists, and variables (not shell variables).

I've gone through quite a few embedded devices for exactly this use case. So far I've used:

- 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.

Hell, you could do this with a single NIC if you have a VLAN-aware switch.

Cool post, I love a good firewall story.

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.

Vegas should start taking bets

I hope this at least resulted in some equity of this project for you.

Have we already forgotten about Edward Snowden & the NSA?

Here's a fun one that I still haven't figured out:

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!

Never I hope

This is kind of a complicated example, but here goes:

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.

Migrations are kind of a different beast. In that case I just stand up a test environment in Docker that does what it needs, then just trash it once things have been tested/verified.

Bingo...this is how I get around that.

I was able to accomplish this by doing each test within its own transaction session that gets rolled-back after each test. This way I'm allowed to modify the database to suit my needs for each test, then it gets magically reset back to its known state for the next test. Transaction rollbacks are very quick.

Range types are a godsend when you need to calculate things like overlapping or intersecting time/date ranges.

Back when video games separated the men from the boys.

Damn, that was a walk down memory lane.

Well, look at how Microsoft tried to hijack the JVM back in the 90s. I think the big fear is that somebody creates a "mostly compatible" product, that in fact isn't 100% compatible, and tries to market it as the same thing as the original, which in fact isn't the original.

Yes, a VM with extremely tight integration with the Windows environment to make things that would otherwise require lots of time to setup a breeze. I use it as my daily driver for dev work (at work, since we're required to use Windows :( ) and to be honest it's quite pleasant most of the time.

That's the difference between an engine and game developer.

I'm guessing none of these diehards were running domain controllers.

Dialing-up a friend to play Quake, there essentially was no lag.

Dialing-up to the Internet to play Quake via TCP/IP...shit tons of lag (150+ ms).

Win95 had its own stack, codenamed Wolverine

The Coastal aged cheddar that Costco sells has these. And she's right, it makes the cheese much more enjoyable.

Not to mention the liability of hosting users' media, which would have needed costly moderation to ensure nothing too illegal made its way in.

That sure is a lot of words to say Milkdrop

I hear this

Well, thank you for that. That's a great weight off me mind.

Yes is horrible, this idea.

Exactly. Using base64 as an obfuscation tool, or (shudder) encryption is seriously misusing it for what it was originally intended for. If that's what you need to do then avoid using base64 in favor for something that was designed to do that.

The SIP "redphones" is an idea I really like. My wife managed to get a SIP IP phone from one of her buy-nothing groups that I've been meaning to setup an Asterisk server for just to mess with. Maybe stick it upstairs where my kid likes to play & let him get the experience of using a "real" phone.