> I needed a hardware MAC address filtering.
What I really love is the stack trace of reasoning, that's very pedagogical, and that you either worked out lots of things from first principles or felt the need to explain them is if from naive perspective.
Also, while impractical for real world networking I don't think this is just idle play. What with backdoors turning up in over-complex network network chips you may find a more serious readership/project motive in the future.
You might be able to persuade a FTDI-style USB device to bit-bang 10base2 Ethernet for you. You'd implement a "PHY" side which translates the wire traffic to a clean bitstream and aligns the frame start and then just have the PC handle all of it in software for you.
Regarding USB: CDC-NCM isn't hard to implement in any MCU but implementing a USB HS PHY basically requires ASIC hardware.
If you use a $0.30 USB HS ULPI PHY, one could implement USB CDC-NCM in an FPGA pretty easily.
Retirement is not something desirable for me, so maybe that's when I'll spend my time on hardware and software projects like this.
https://mirror.math.princeton.edu/pub/oldlinux/Linux.old/net...
IIRC it over-wrote the buffer the CPU tried to read with new packets from the network or something like that. I had it for a while in Linux and the performance really was bad. :-D
It's amazing how much stuff is hidden from view by drivers and firmware updates.
Mine is better because it has two buffers :) But still, only one received frame is kept.
Interesting. I just wrote a packet decoder and I specifically verify at each layer that the lower layer length matches. So for IP, in my decoder the IP datagram length must match exactly the ethernet frame length + link layer header. I didn't do this to be pedantic but rather to detect short frames, and then I decided that long frames were also errors.
You (author) are using uIP but I wonder what Linux or any other modern OS does. You don't specifically mention interoperability but I wonder if you've tested that.
Impressive stuff.
I've dabbled wuth making my own ISA and softcore CPU in FPGA, but getting C code to compile has been a bit of a blocker.
I know there are some compilers one could try to port but my ISA is kinda esoteric so not straight forward, and so I considered just writing from scratch like you have.
Longest 18 months of my life.
But reading (https://qdiv.dev/posts/eth-to-spi/) about somebody that made that chip from basic components is really awesome.
Thanks a lot !
You’ve got me curious of the use case, is it fascination or some other reason? From a security perspective, it seems straightforward to just encrypt the bytes before sending to the drive. That would ensure you can detect data being maliciously changed and/or protect against the drive somehow misusing the data.
All set to learn what a discrete logic network was.
I just went back and reread the 10BASE-T write up as well.
That’s super cool you can even get 2.6kB out of it.
In practice, it means using multiple components. In a strict sense it means no integrated circuits at all, I suppose. But it's also a relative thing. So while a 7400 series chip is not a "discrete" component as most would think of it, using a hundred 7400 series chips to implement a processor is relatively more discrete than a microprocessor. (It's certainly not as integrated.)
Since the early 1980s, Ethernet interfaces have used used custom chips, because the amount of logic required would need dozens of gate-level chips otherwise (as seen here!)
The software required to run a TCP/IP stack was also large, limiting the system to a handful of active sockets, and consuming large parts of the available CPU power to run something like Telnet or FTP.
It took a few years for CPUs to get more powerful, more RAM to become affordable, and for network hardware to become integrated onto the smaller boards like ISA or NuBus.
Which is exactly what "discrete logic" means.
Even RISC-V based switches like the Vega use proprietary switch chips (Wuhan China designed FSL91030M specifically), which is no better.
You can verify input/output to a certain extent, but this doesn’t preclude a timer based function call or a tailored packet activation.
I wonder why our society tolerates these unknowns. With the push towards WiFi replacing the majority of home networking, I’m not confident it will change any day soon.
Sorry to throw a Rumsfeld at you, but I think these are "unknown unknowns".
If people were aware of the presence and significance of such critical knowledge voids I do not believe they would tolerate them.
I see it as the job of civic cybersecurity to bring precisely these sorts of things to wider attention and educate folk on why they are are problematic.
They browse the web, do their banking, and share photos on SM after checking their mail and searching for Tiramisu recipes.
The existential threat to themselves is low, so they don’t dig further into the ramifications. Journalists, whistleblowers, activists, “undesirables”, those are the primary concerned parties.
The civic cybersecurity aspect needs to lay out a clear benefit to free speech and oppression which makes tangible sense to day to day life. I’m not quite sure how to spread this level of awareness, or highlight the importance of such measures in a way that hits home.
How much L3+ logic is in the NIC? Pretty sure by the time a packet hits the NIC it is encrypted. The lowest level (closest to hardware) encryption I know of happening is in the Linux kernel but isn't currently in production exactly because of security concerns.
If you are sending unencrypted packets on the network I can think of much more reasonable attack vectors for an attacker to try than planting a backdoor in the NIC firmware.
How would this not get detected by modern DPI?
And I don't know much about the internals of Palo Alto / Cisco etc network security appliances but I'm pretty sure they do have custom ASICs/ FPGAs for their switching logic purely because of this attack vector.
My conclusion: 1. Your home router is significantly more vulnerable 2. Your IoT devices are significantly more vulnerable 3. Any network packet going through the NIC is also going to the internet at large generally or see point 1 and 2. 4. The ISP hardware isn't exposed to this attack vector
Feel free to help my understanding, I could be wrong.
Society tolerates an infinite number of unknowns because it's impossible to know everything, or even a microscopic corner of "everything". The tradeoff for every society larger than a subsistence farming village is things you can't see happening over your horizon that you have to trust. Or trust in the vague hope that someone else is checking and would notice if things went bad.
> Wuhan
I had to look this up, and the business address is of course Shenzen, where you'd expect. https://milkv.io/about gives a Romanized address of "1603, Block B, FengHuang Zhigu Building No.50 Tiezai Road, Xixiang, Baoan Shenzhen, 518102 China", which is in a different administrative area from Wuhan and five hundred miles away. Not that it matters.
Nobody has perfect knowledge of their world. All we have are heuristics that work well enough to get by. It’s by definition impossible to anticipate out-of-context events that barge in like the Vogons.
Excession by Iain Banks is a fun exploration of this concept. It’s set in his “Culture” universe, where a hybrid human/AI culture enjoys an interstellar empire. Excession imagines that powerful civilization encountering a phenomenon that is as far beyond them as they are beyond us, or we are beyond the subsistence farmer.
Only nitpick I'd have is that author decided to use a custom-design cpu.
Ok, "discrete logic only!" is a valid choice. And then keeping complexity to a minimum weighs heavily. But the downsides of that choice are also considerable:
-No interrupts (which are very useful)
-No existing software base to tap from. Somewhat-useful C compiler helps.. somewhat.
But who am I to question author's choices for a hobby project like this? Great stuff in any case.
74xx series ICs (eg. 74ACT family in case of the cpu, if I read correctly).
More generally, it may refer to "basic logic elements whose function is easily inspected".
> Why would this prevent interrupts?
Not at all - in theory.
In practice, interrupt support tends to complicate cpu designs. Complicate = more logic = more ICs. So builder decided against it & chose not to implement interrupts on the cpu.
