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