I came across the tweet about this "Evil" dongle and instantly recognized it as the exact same thing I worked on before... It's not evil, it's just annoying.
In my case I disabled the SPI flash module to have it not appear as a CD drive, the author of this post actually found some documentation about the SPI being optional. Funnily enough this post now also gives you all the tooling to make an actual evil RJ45 dongle by reflashing one :D
What happened to U3 at the top left in the image of the flash chip?
Looks like they had a footprint for a diode in a 3-pin SOT23 package and found they didn't have stock of the special part, so they installed a SOD323 diode at a 30 degree angle across two pins...
> Funnily enough this post now also gives you all the tooling to make an actual evil RJ45 dongle by reflashing one :D
Ironic! I'm convinced most security problems are caused by well-meaning people breaking down hard- and software and explaining how to "hack" things. I mean if that's unintentional than at best it was security by obscurity to begin with which should be exposed so people don't rely on it.
If you think some curious spare-time white-hat hackers are the main cause of most security problems, you grossly underestimate the size and skillset of the black-hat hacking industry, and the unlimited profit-potential available in that field...
Shorting almost any two of the communication lines of the flash chip will corrupt the communication enough that the ethernet controller thinks there's no flash installed at all.
I have no idea about S0 but CS is usually chip select. It should be sufficient to short it to prevent the chip from being selected. However CS is frequently inverted and you would have to pull it up to prevent the chip selection, so maybe S0 is always high and inhibit CS
I'm very much aware of Gentoo...but if you're going to compare basically any distribution is "poor man's Gentoo" because it's a collection of packages built from source files.
The main advantage of Gentoo is not building from source. One could argue that's the main disadvantage of Gentoo.
An ordinary Linux can be configured by installing pre-compiled packages. The system either has the package or not. Gentoo allows the package itself to be configured. Think of package ./configure arguments; they're abstracted as "USE flags" in Gentoo and allow tweaking the package internal configuration. It also allows modifying the environment variables used during the build. Setting CFLAGS/CXXFLAGS allows optimizing for the system's CPU instead of doing a generic x86-64 build.
You are rebuilding Alpine packages on top of LFS while using glibc. So I guess you want a minimal system with OpenRC.
Gentoo will give you that with proper package management including on the system part without having to do the weird dance you are making with abuild with a nicer experience if you want to patch and update your packages later and significantly better tracking on what you have done.
I have a hard time seeing anything starting from LFS which wouldn’t be better actually starting from Gentoo.
Using wrappers doesn't really help that much because the difficulties are in the things that aren't covered anyway. Proot doesn't help for these issues, there's a long-standing open issue for that one.
Using docker would make the mixing and nesting of native and foreign architecture chroots only more difficult
> Using wrappers doesn't really help that much because the difficulties are in the things that aren't covered anyway. Proot doesn't help for these issues, there's a long-standing open issue for that one.
Could I ask for more details? I could certainly believe that podman doesn't do something that's needed, but I'm pretty sure it does everything that this particular article spends time setting up out of the box. And I can't find anything about proot; https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/i... gives me nothing and a web search only gives me https://gitlab.com/postmarketOS/pmbootstrap/-/issues/2052#no... which is... either they're wrong (because faking mounts is definitely something proot does), they were right but it's changed (I don't know when that was added), or I'm misunderstanding the problem (maybe pmbootstrap dynamically changes mounts?).
> Using docker would make the mixing and nesting of native and foreign architecture chroots only more difficult
Would it? I'm not intimately familiar with how postmarketos is doing it now, but I have done qemu-user-static with docker and it's easy to work with; you can either do the whole thing in docker with https://github.com/multiarch/qemu-user-static , or I think you can enable qemu on the host and it automatically works in containers.
EDIT: Oh hang on, I might have it - doing that with docker needs --privileged so probably doesn't work if you're running without root. I personally would shrug and say that running this one command as root is fine but if we want zero sudoing then yeah that's a problem.
I've also spend a bit of time thinking about recipe formats because I wanted to write down some recipes for my website. Ended up making a custom yaml-based format after looking at the available options and after a while scrapped that again to make a new toml-based format to make it a bit easier to write.
Some notable features is a mini DSL to refer to ingredients in the instruction text and also have parse-able times and temperatures so on the frontend it's easy to switch units with javascript. This is combined with a simple database of ingredient IDs which contains (translated) names and for some of them the density so you can swap the recipe between volume and weight measurements.
I just quickly tried to fit the whole rp2040+ethernet phy in the WIZ850io formfactor (mainly because I already used that module in some projects before) and have not yet been able to make it fit without using the more expensive jlcpcb features like burried vias. It would be very cool to have though since the W5500 really needs an update.
I'm unable to respond to your deeper comment, but I don't see any issue at all with this. Your concern about the vias doesn't make sense as you just tent the vias anywhere you are concerned about shorts. I'm 100% certain you can fit both chips, all passives, etc, in this formfactor. If the flash size is a concern, RP2350 (the new version of the 2040) has integrated flash for some of their packages. Or just use a chip scale (or similar) flash instead of the one normally used on RP2040 designs.
A 4-layer in that form factor should be pretty doable with no fancy features like blind vias. The RP2040 and W5500 are the same size, and ethernet PHYs can be found in about 3x3mm or even smaller. There should be about 20x25mm of usable space in that module form factor (even conservatively, like 18x23).
I don't have the time to give it a shot myself, but I could try to help if needed.
The issue is more the space needed by all the passives, the crystal, the massive flash chip. I can just about make it fit but now I have the issue that the phy needs some vias to the center pad for gnd but that's always right at the point where my ethernet jack is on the other side.
I have a stack of them here, they are great to work with for their intended purpose but they are not that great if you want to run custom software.
I also grabbed a RB2011 diagram because it's a simple diagram that explains it well I think, the RB1100AHx4 is a better example technically since it's using the same switch chip but it's more confusing because they use the two CPU ports together and claim it's a 2.5Gbps link while it's two 1.25Gbps link and they ignore the encoding overhead.
The reason why I build this from scratch is that it that the expense is reasonable and this should end up in the FOSDEM video recording boxes and it has to fix a few issues specific to that design like it needing to expose 4 network ports to the front panel of the case but also be connected to the internal SBC. There's simply not that much space in the case to put passthroughs in the case to a switch to not have an external loop cable for the SBC and with a dumb switch the system can't be monitored anymore. Since quite a few of these boxes are built this becomes a reasonable solution (if you ignore design time, but this is volunteer work)
STP is "slow" STP, and RSTP is a degenerate case of MSTP!
MSTP is Multiple spanning trees ie you can group VLANs and prefer paths for those groups of VLANs. That means if you have say two links between two bridges (switches) you can prefer some to use one link and the rest to use the other, that means you are not "wasting" a standby link. They will fail over to the surviving link on failure. STP and RSTP will only consider one link as a whole, so two ports are "wasted" when not in use: in the case of a two bridge, two links example.
Old school STP without the Rapid part hasn't really been a thing for several decades. I can't think of why you wouldn't use RSTP in general but if you need to make best use of your forwarding capacity then a 50/50 MSTP may be indicated. That's where you look at your traffic flows across VLANs and try to bundle them up into a 50/50% collection. One lot prefers link A and the rest get link B. Obviously you can get really creative as the number of VLANs and links mount up. Bear in mind that dot1Q is a simple version of QinQ!
Sorry, got a bit carried away there.
For nearly all intents and purposes, RSTP is STP. If you plug in a network cable between two devices and it does not start working within say five seconds then you are living in the 1990s.
I meant, where did you find that this specific Linux-managed network switch supports MSTP? Because the Linux bridge networking code, last time I looked, only supported STP; you had to run a separate daemon to even get RSTP.
https://blog.brixit.nl/making-a-usb-ethernet-adapter-work-sr...
In my case I disabled the SPI flash module to have it not appear as a CD drive, the author of this post actually found some documentation about the SPI being optional. Funnily enough this post now also gives you all the tooling to make an actual evil RJ45 dongle by reflashing one :D
reply