Espresso-hole – EspressoBin-based personal router with ad blocking | Hacker News Reader

Espresso-hole – EspressoBin-based personal router with ad blocking

github.com

73 pointsric3rcar39 comments

Oh the Espressobin. The poor thing has a dozen or so variants, and each one requires a different u-boot image. Fortunately they ship with the u-boot image on SPI flash, so in theory you could just let it be and not worry about the variants... except for the massive security issue where the stock u-boot bridges all ethernet ports.

With a stock u-boot, from the time the bootloader brings up the ethernet switch until Linux takes over it with dsa and bridge-utils, your LAN ports are directly bridged with your WAN port.

I gave up using mine as a firewall and just run pihole + samba w/ a couple of drives on it.

I tried to rebuild u-boot from source w/o the network boot code since the latest Linux Kernel has drivers for the Topaz switch now, but no matter what I tried I couldn't get it to boot.

The documentation leaves a lot to be desired....

I’m really curious, as someone with little knowledge of these kinds of security considerations, why is it bad to have the wan port and the lan ports bridges?

some ISPs will happily assign public IPs to any hardware address that sends a DHCP request. This means while the network segments are bridged, all local devices are potentially obtaining public IP addresses and are exposed to the internet at large.

This is problematic if you have home network devices with vulnerabilities or services running on hosts with the assumption that the host will only ever be on a private network (unauthenticated file servers, etc)

There is also an issue with the number of devices exposed to the ISP -- many will issue an address to the first device they see on a link, then ignore all other devices until the lease expires or is released. That means your PS4 may get a lease before the espressobin's Linux takes over, and the ISP will ignore the subsequent dhcp request from the espressobin.

wan = outside firewall

lan = inside firewall

You don't want to bridge them because then it just bypasses the firewall.

That's not true.

LAN traffic is still going through the router, where the firewall supposedly runs.

Regardless of other devices having a public IP, if the router blocks forwarding packets (which is one of the main functionalities of a firewall), then the device(s) behind it are just as protected as if they had private IPs.

It's just a bit easier to setup forwarding as it doesn't require NAT, and it's also easier to open up by accident but having a public IP does not bypass the firewall.

Depends, a typical use case of this device would be a router, or a firewall, so the point GP makes is very much valid.

the entire reason the devices get public a public IP is because the firewall effectively isn't there. from the time u-boot inits the topaz chip, until linux controls the chip, it behaves like a dumb ethernet switch.

I still prefer having the bootloader in SPI - worst case I can just chain load another newer / custom u-boot from TFTP or SD card.

At the moment I've got an unbootable Rockchip RK3399 board on my desk because at some point the bootloader image format has changed and rkdeveloptool refuses to let me boot from or flash the image to the device.

Do you know of any patches that keep the NIC turned off until Linux is ready?

https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/...

That's the init code for the network chip. I tried removing it, the code compiles, but the board won't boot w/ it(I imagine due to something unrelated).

If I knew of any such patches, I couldn't share them for Reasons, but suggest poking around mv88e6xxx_initialize in u-boot.

Throwaway account. Proceed with caution. This board was the only one which fitted our requirements for a commercial product. We actually found it more stable than for instance the people on the Armbian forums. But in the end we've moved on.

Lesson learned (probably sounds obvious, but hey): SBCs are nothing without software. The quality and commitment of the developer to kernel support is everything. All boards have issues, and they can be worked around in software.

The espressobin got a lot of community support, but even with that it still isn't quite enough.

We need more boards like this that aren't just a copy of the raspberry pi. For personal use I would buy one of these tomorrow.

With hard core documentation and support this thing could have been the start of something great. Lets hope that can still happen.

Not to take anything away from the hard working folk who are currently supporting this. And from Marvell. Your efforts are greatly appreciated. I just hope there is a way to get you more resources

Totally agree. The espressobin community has been very active for a while, but documentation is lacking even for basic functionalities like GPIO pinout usage.

How about this one?

http://www.banana-pi.org/r2.html

Looks promising but lacks official support from ARMBIAN, which was crucial for choosing the espressobin.

As someone who has an espressobin at home, and uses it as a personal router, this device is great.

However, after enough configuration ( vlans, etc ), you'll find that it is not capable of routing gigabit traffic.

Mine is currently CPU bound ( ksoftirq ) at approximately 300 mb/s.

I don't know a ton about single board computers. Can anyone comment whether the use of an EspressoBin board here has some significance over, say, a Raspberry Pi?

the espressobin(2xA53) is way less powerful than an rpi3(4xA53), let alone 4(4xA72), but has a minipcie slot enabling you to add a WiFi card of your choice.

Additionally, the Espressobin has a Topaz ethernet switch onboard with 4 ports (1 to the SoC, 3 as gigabit ethernet rj45). This is both really spiffy and scary (see my other post). The spiffiness is that the switch can be controlled by Linux and is integrated with bridge-utils. It looks and mostly behaves like a software bridge, but the packets never hit the CPU, only the topaz chip.

The RPi 4 is the first one with an Ethernet interface that isn't connected over USB. All the earlier RPis are seriously handicapped for networking usage by that limitation.

sure, but the espressobin has a gigabit switch onboard. and that switch is controllable from Linux, and treated as a bridge device, easily manipulated from brctl.

while the rpi3 spanks the espressobin on CPU, the espressobin destroys pretty much every other dev board (including rpi4) in the price range with regard to network functionality.

Also a SATA port, though they put the wrong gender 4 pin molex power connector on the board so you either have to break out a soldering iron, or commit a perversion of a Y cable.

This is cool, but I would not even bother with the WiFi dongle, just get a proper AP wired to it.

I wouldn't touch EspressoBin products with a mile long pole if I could. The board is a mess and as undocumented as it can get to the point where even labels on the board don't match what the uboot images is flashed to it. Even when using their suggested images for ubuntu, the board is unstable and cannot run without kernel panicking every 15-30 minutes.

Flashing new uboot image is a mess too. Sometimes it works. Sometimes it doesn't. Why? Who knows. Since boards are often mislabeled, flashing most of the time does brick the board making it useless paperweight that eats 12V5A power supply.

All in all, stay away from it if you can. There are much better SBCs on the market.

Sure, my experience with custom kernels or the suggested Ubuntu version were totally frustrating as well. I would stay away from these. However, ARMBIAN is stable and the board becomes fully usable.

Surely this doesn't actually use 60W right?

This would be a really fun weekend that I would soon curse as I have to support it for years after I forgot everything about how I set it up. Just like my Pi DNS server that uses PiHole backed by a DNS over HTTPS server. I think...

I read about a project once - maybe anyone here can help me find the name of it again. As I recall:

- popular in Europe, particularly Germany or the Netherlands?

- some kind of mesh routing, but connected to the Internet

- reports of people using it having better connectivity to the Internet at large than just by connecting to their ISP unaugmented. If I recall correctly, this was because the "magic" mesh detected routing problems (such as censor blocks) and routed traffic through other nodes

Did I dream this up or does this ring a bell with anyone?

Hi!

Think Freifunk[1] is what you're looking for, it's rather cool in anycase!

1. https://en.wikipedia.org/wiki/Freifunk

It is rather cool. But I don't think that was it. Maybe it was http://guifi.net/en/ which seems similar to Freifunk.

You might have been thinking either of cjdns or Yggdrasil https://yggdrasil-network.github.io/

It would be optimal if it includes a local DNS over HTTPS resolver. Otherwise it becomes a choice of running a separate local resolver upstream or avoiding DoH for the sake of ad blocking.

Does anyone know if pi-hole supports TLS SNI?

I have one of these. While the device is great, be advised that if you upgrade your kernel you'll most likely hit a cpu bug. The only way to avoid this is by limiting cpu freq at 600mhz.

With ARMBIAN I keep updating the kernel without any problems.

Wonder if DPI/IDS could be setup on this or if it is too slow, I've been looking for a cheap DIY IDS.

It's pretty slow TBH. I use mine to run pihole and samba and samba will max out the CPU.

I tried to use mine as a firewall for my Google Fiber but w/ just basic rules enabled it would max out around 500mbps, I imagine I could probably get 50-100mbps out of it running a decent IPS ruleset, but I haven't tried.

The Topaz switch chip uses the RGMII 1gbps uplink to the CPU so even though there's 3 1gbps ethernet ports you'll only ever get 1gbps through the device if you have to do any software level processing.

Haven't tried myself, but there's a thread discussing this: forum.level1techs.com/t/firewall-on-espressobin/131206/9

I know it’s more but sg-1100 is this device but the extra $ helps fund pfsense and you can support. I just really like pfsense but never tried pi hole so not making a comparison.

Seems like a little much to sell the same hardware for triple the price.

Edit: Is this contraversial? It is literally the same hardware with pfsense installed and a case. $155 for an ARM A53 is a crazy markup.

Reply on news.ycombinator.com