Homebrew Network Card With No CPU

April 10, 2024 by Al Williams 16 Comments

A modern normal network card will have onboard an Ethernet controller which, of course, is a pre-programmed microcontroller. Not only does it do the things required to keep a computer on the network, it can even save the primary CPU from having to do certain common tasks required for communicating. But not [Ivan’s]. His homebrew computer — comprised of 7 colorful PCBs — now has an eighth card. You guessed it. That card connects to 10BASE-T Ethernet.

There’s not a microcontroller in sight, although there are RAM chips. Everything else is logic gates, flip flops, and counters. There are a few other function chips, but nothing too large. Does it work? Yes. Is it fast? Um…well, no.

He can ping others on the network with an 85 ms round trip and serve web pages from his homebrew computer at about 2.6 kB/s. But speed wasn’t the goal here and the end result is quite impressive. He even ported a C compiler to his CPU so he could compile uIP, a networking stack, avoiding the problems of writing his own from scratch.

Some compromises had to be made. The host computer has to do things you normally expect a network card to do. The MTU is 1024 bytes (instead of the more common 1500 bytes, but TCP/IP is made to expect different MTU sizes, which used to be more common when more network interfaces looked like this one).

Even on an FPGA, these days, you are more likely to grab some “IP” to do your Ethernet controller. Rolling your own from general logic is amazing, and — honestly — the design is simpler than we would have guessed. If you check out [Ivan]’s blog, you can find articles on the CPU design, its ALU, and even a VGA video card all from discrete logic. The whole design, including the network card is up on GitHub.

We love the idea of building a whole computer system soup to nuts. We wish we had the time. If you need a refresher on what’s really happening with Ethernet, our [Arya Voronova] can help.

A Network Card For The Trash-80

February 11, 2019 by Brian Benchoff 16 Comments

Around these parts, [Peter] is well-known for abusing the TRS-80 to do things it should never do. You can read Wikipedia on the TRS-80, you can look at Google Images, and you can browse the web. As with any retrocomputer, there are limitations for what you can do. To browse Wikipedia, [Peter] had to set up an AWS instance which translated everything and used serial to IP converters. It can be done, but it’s hard.

Now, after seeing a few interesting projects built around the ESP32, [Peter] built a network card for the TRS-80. It’s called the trsnic, and it’s a working network card for almost all the TRS-80s out there, with the eventual goal of supporting the TRS-80 Model I / II / III / 4 / 12 / 16 / 16B and 6000.

The idea for the trsnic comes from [Arno Puder]’s RetroStoreCard, a device that plugs into the TRS-80 Model III and connects it to a ‘personal cloud’ of sorts that hosts and runs applications without the need for cassettes or floppys. It does this with an ESP32 wired up to the I/O bus in the Model III, and it’s all completely Open Source.

[Peter] took this idea and ran with it. Thanks to the power found in the ESP32, real encrypted Internet communication can happen, and that means HTTPS and TLS.

Right now, documentation for the trsnic is limited, but the project does exist and building it is as easy as stuffing some headers and DIP sockets in a PCB and soldering them on. There’s a bit of work to do on the ESP32 code, but if you’re looking for a network card for your Trash-80, this is the one that works now.

35C3: Safe And Secure Drivers In High-Level Languages

December 31, 2018 by Sven Gregori 12 Comments

Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.

With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.

At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.

Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages” →

34C3: Roll Your Own Network Driver In Four Simple Steps

January 1, 2018 by Christian Trapp 7 Comments

Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.

Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.

Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps” →

UDP Between STM32-F4 Discovery Boards

February 15, 2013 by Mike Szczys 24 Comments

stm32-f4-udp

[The Backwoods Engineer] tested out a new accessory kit for the STM32-F4 Discovery board. The image above shows two boards communicating with the UDP protocol. Notice the extra PCB into which each Discovery board has been plugged. This is a third-party add-on which adds Ethernet, RS-232, SD card slot, and a connector for LCD or Camera. We’ve had one of these F4 Discovery boards on hand for a while and haven’t figured out a good way to connect external hardware to the huge dual pin-headers. This doesn’t solve the problem — the base board also includes dual headers to break-out all the pins — but having Ethernet, serial, and SD certainly reduces the need to add all that much more. The other drawback to the hardware is that the sample firmware is targeted at the IAR Embedded Workbench which is neither free, nor in the realm of affordable for hobbyists.

The NIC used on the baseboard has auto-crossover capabilities so the boards were connected using a regular Cat6 patch cable. This example has the boards constantly sending UDP packets with the module on the right reporting status information to a terminal via the serial connection.

Stepping Beyond The Ethernet Shield

July 8, 2010 by Mike Szczys 22 Comments

We’ve said it time and again, the Arduino is a prototyping platform. In that spirit, [Doug Jackson] shows you how to conserve the expensive Arduino board and Ethernet shield by building your own Arduino Ethernet module. You may remember the ENC28j60 as a NIC for your microcontrollers. [Doug’s] board makes use of that chip and adds an ATmega168 with a crystal, power regulator, breakout pins, and even a few DIP switches which can come in quite handy.

Black Hat 2008: NIC Based Rootkit

August 13, 2008 by Eliot 11 Comments

While Black Hat and Defcon have both concluded, we’re going to post a few more talks that we think deserve attention. [Sherri Sparks] and [Shawn Embleton] from Clear Hat presented Deeper Door, exploiting the NIC chipset. Windows machines use NDIS, the Network Driver Interface Specification, to communicate between the OS and the actual NIC. NDIS is an API that lets programmers talk to network hardware in a general fashion. Most firewalls and intrusion detection systems monitor packets at the NDIS level. The team took a novel approach to bypassing machine security by hooking directly to the network card, below the NDIS level.

The team targeted the Intel 8255x chipset because of its open documentation and availability of compatible cards like the Intel PRO/100B. They found that sending data was very easy: Write a UDP packet to a specific memory address, check to make sure the card is idle, and then tell it to send. The receive side was slightly more difficult, because you have to intercept all inbound traffic and filter out the replies you want from the legitimate packets. Even though they were writing low level chipset specific code, they said it was much easier to implement than writing an NDIS driver. While a certainly a clever way to implement a covert channel, it will only bypass an IDS or firewall on the same host and not one on the network.

[photo: Big Fat Rat]