Eine Website auf einem 8-Bit-Mikrocontroller hosten

 (maurycyz.com)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde eine Website nur mit einem AVR64DD32-8-Bit-MCU gehostet, die in einer kleinen Umgebung mit 24-MHz-CPU, 8 KB RAM und 64 KB Flash läuft
  • Um Ethernet-Signale direkt zu erzeugen, ist selbst 10BASE-T noch zu schnell, daher wird eine USB-Seriell-Verbindung per von Linux unterstütztem SLIP wie eine Netzwerkschnittstelle verwendet
  • SLIP ist ein einfaches Verfahren, das Pakete mit 0xC0 einrahmt und Sonderbytes maskiert, und eignet sich daher gut, um einen MCU mit modernem Linux zu verbinden
  • IP wurde dank deaktivierter Fragmentierung einfacher, aber die TCP-Implementierung erforderte Verbindungszustände, Neuübertragungen und Ausnahmebehandlung, dauerte mehrere Tage und enthält noch Bugs
  • Der externe Zugriff erfolgt über eine Umgehungskonstruktion mit VPS, WireGuard und Proxy, die nur Anfragen an /mcu weiterleitet; die Kosten für öffentlich erreichbares IPv4 und das Fehlen von IPv6 erwiesen sich als zentrale Einschränkungen

Aufbau zum Hosting einer Website auf einem 8-Bit-AVR

  • Der AVR64DD32 ist ein 8-Bit-MCU der AVR-Familie, ähnlich dem durch Arduino bekannten Atmega328, ist bei gleicher Speicherklasse günstiger und bietet einen einzelnen Programmier-Pin sowie bessere Peripherie
    • Ein einzelner 8-Bit-AVR-Kern mit bis zu 24 MHz
    • 8 KB statisches RAM, 64 KB Flash, 256 Byte EEPROM
    • Spannungsbereich von 1,8 bis 5,5 V, Preisbereich von $1 bis $2
  • Um nur mit dem MCU direkt mit dem Internet verbunden zu sein, müssten Ethernet-Signale erzeugt werden, aber selbst das langsamste 10BASE-T ist für diese Umgebung zu schnell
    • 10BASE-T arbeitet mit 10 Mbit/s, und durch Manchester-Codierung werden auf der Leitung effektiv 20 Mbit/s daraus
    • Die CPU des AVR64DD32 kann bis 24 MHz erreichen, aber Peripherie und IO-Pins unterstützen maximal einen 12-MHz-Takt, weshalb eine direkte Signalerzeugung schwierig ist
    • Die Standardlösung wäre ein dedizierter Ethernet-Chip, aber für den Abschluss des Projekts hätte man mehrere Wochen warten müssen
  • Als Alternative wird SLIP (Serial Line Internet Protocol, RFC 1055) verwendet, um Netzwerkverkehr über eine serielle Verbindung zu transportieren
    • Die Pakete werden vorne und hinten mit dem Byte 0xC0 eingerahmt
    • 0xC0 innerhalb eines Pakets wird zu 0xDB 0xDC, ein vorhandenes 0xDB wird zu 0xDB 0xDD, um Mehrdeutigkeiten zu vermeiden
    • Das knüpft an die frühere Arbeitsweise von Einwahlmodems an, die serielle Verbindungen über Telefonleitungen aufbauten, während der Rechner darauf das Networking verarbeitete
    • Auch modernes Linux unterstützt SLIP, sodass sich ein USB-Seriell-Adapter als Netzwerkschnittstelle nutzen lässt
    • Verwendungsbeispiele sind stty -F /dev/ttyUSB0 115200 raw cs8, slattach -m -F -L -p slip /dev/ttyUSB0
  • Die Hardware auf MCU-Seite ist einfach und funktioniert auch ohne externe Bauteile
    • www.c: Quellcode
    • www.elf: Vorab kompiliertes Binärprogramm
    • Es wurden eine LED und eine Diode zum Schutz vor verpolter Stromversorgung hinzugefügt
    • Der Stromverbrauch liegt bei nur wenigen mW, sodass der Server allein über die 5-V-Schiene des USB-Seriell-Adapters betrieben werden kann

Protokollimplementierung und öffentlicher Zugriff

  • Die IP-Implementierung wurde durch die Einschränkungen moderner Umgebungen vereinfacht
    • Damit eine Webseite den Rechner des Nutzers erreicht, müssen Pakete mehrere Netzwerke durchlaufen, und jedes Paket benötigt einen 40 Byte großen IP-Header mit Quell- und Zieladresse sowie weiteren Informationen
    • Früheres IP benötigte wegen Funktionen wie Paketfragmentierung viel Speicher, um korrekt verarbeitet zu werden
    • Moderne Betriebssysteme deaktivieren Fragmentierung, und IPv6 hat Fragmentierung entfernt, sodass dies nicht direkt behandelt werden muss
    • Wenn Quell- und Zieladresse vertauscht und der TTL-Zähler zurückgesetzt werden, lässt sich damit ein Antwort-Header erzeugen
  • Die TCP-Implementierung war deutlich schwieriger, weil Verbindungszustände verfolgt, verlorene Pakete neu übertragen und verschiedene Ausnahmesituationen behandelt werden müssen
    • Es dauerte mehrere Tage, bis eine benutzerdefinierte TCP-Implementierung ausreichend funktionierte, und einige Bugs sind noch vorhanden
    • HTTP wurde nicht separat implementiert; stattdessen sendet der Server dem Client immer eine fest einkodierte „Antwort“
    • Für eine Website mit nur einer URL funktioniert dieser Ansatz ausreichend gut
    • Der Ladevorgang ist in Video 3 zu sehen
  • Für den externen Zugriff ist eine öffentlich routbare IPv4-Adresse erforderlich, aber Kosten und die Qualität des heimischen Internetanschlusses wurden zum Hindernis
    • Die Maschine mit einer öffentlich routbaren Adresse ist ein VPS in einem Rechenzentrum nahe Helsinki
    • Mit WireGuard unter Linux wird ein virtueller Netzwerk-Link über das Internet aufgebaut, der auch funktioniert, wenn eine Seite hinter CGNAT sitzt
    • Dadurch verbindet sich eine Linux-Router-Box mit dem VPS, um eine geeignetere Internetanbindung zu erhalten
  • Da der MCU weiterhin keine eigene öffentliche IP hat, würden bei einer Weiterleitung aller Anfragen an die VPS-Adresse die bestehende Website kaputtgehen
    • Stattdessen wurde der Server so konfiguriert, dass nur Anfragen unter /mcu unter Verwendung eines lokalen Adressblocks an den MCU-Server weitergeleitet werden
    • Besucher verbinden sich damit nicht direkt mit dem TCP/IP-Stack des MCU, aber es funktioniert ähnlich wie beim Vape Server
    • Dadurch ist es etwas schwieriger, den Dienst mit SYN-Paketen kaputtzumachen, aber faktisch läuft der Server über eine Verbindung, die fast einem Einwahlzugang entspricht, und ist daher anfällig für DDoS
  • Das Fehlen von IPv6 bleibt die grundlegende Ursache für die gesamte Umgehungskonstruktion

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Vor mehr als 25 Jahren gab es einen protzigen Wettbewerb darum, den kleinsten Webserver zu bauen: https://web.archive.org/web/20000815063022/http://www-ccs.cs...
    Gewonnen hat jemand mit einem ACE1101-Mikrocontroller; den Originalartikel finde ich nicht, aber es gibt noch so etwas hier: https://conceptlab.com/fly/
    Es war ein Webserver auf einer Fliege

    • Ich habe die ACE1101-Version gebaut und vorprogrammierte Chips per Post an einen Künstler in Saskatoon geschickt. Die ursprüngliche Beschreibung ist noch auf Archive.org erhalten: https://web.archive.org/web/20020605032321/http://d116.com/a...
      Das Kürzen des Codes hat wirklich Spaß gemacht, und nachdem ich ping entfernt hatte, war genug Platz für bitgebangtes I2C und UDP-Uploads ins EEPROM, und trotzdem blieb alles unter 1024 Byte
    • Ich musste erst vor ein paar Tagen wieder an diesen winzigen Webserver denken und habe ihn auch hier gepostet, aber es gab kaum Reaktionen. Ich finde ihn damals wie heute ziemlich beeindruckend

  • Ich mag die AVR-DD-, EA- und EB-Serien, aber die neuesten Chip-Veröffentlichungen von Microchip wirken auf AVR-Fans etwas besorgniserregend: https://www.microchip.com/en-us/products/microcontrollers/32...
    PIC32 CM bietet die meisten Funktionen des AVR DD – Event-System, MVIO, 5V-Betrieb usw. – und dazu einen größeren, standardmäßigeren ARM-32-Bit-M0+-Kern
    Deshalb frage ich mich, ob AVR DD inzwischen etwas veraltet ist. AVR EA und AVR EB scheinen mit ihren 12-Bit-ADCs mit 16-fach programmierbarer Verstärkung und einer Empfindlichkeit bis etwa 50 Mikrovolt trotz etwas Rauschen als absurd gute ADCs/Stromsensoren auf der sicheren Seite zu sein
    Andererseits könnte das die AVR-Familie auch populärer machen. Ich frage mich, ob die Tatsache, dass es pinkompatible ARM32-Cortex-M0+-Varianten gibt, die Wahrscheinlichkeit erhöht oder senkt, auf der AVR-Plattform aufzubauen
    Für mich sind Peripheriegeräte am wichtigsten. AVR DD hat möglicherweise einen geringeren Stromverbrauch, insbesondere bei 1,8V-Betrieb, aber ich weiß nicht, ob das ausreicht
    Das Projekt selbst ist sehr interessant, und AVR DD ist so oder so ein großartiger Chip, daher ist es schön, ihn einmal tatsächlich im Einsatz zu sehen
    10BASE-T läuft mit 10 Megabit/s, und wegen Manchester-Codierung sind es auf der Leitung 20 Megabit; AVR EB hat einen x2-PLL-Timer, also könnte man mit genug Aufwand vielleicht sogar Manchester-Codierung ausgeben
    Mit der Kombination aus LUT, UART-Peripherie und per PLL hochgetakteter Timerlogik könnte man vielleicht schnelle Manchester-Codierung herausschieben, aber ob das bis 20 Mbit reicht, müsste ich mir noch genauer überlegen

    • Microchip ist dafür bekannt, Chips länger zu unterstützen als die meisten anderen Unternehmen. Solange es Nachfrage gibt, werden sie faktisch weiterproduziert, und die Dx-Serie ist ebenfalls noch ziemlich neu
      Dass man am Cortex-M0-Pfad herumspielt, könnte ein Zeichen dafür sein, dass man nach Dx keine weiteren Generationen der 8-Bit-Plattform mehr entwickeln möchte. Wenn dieselben Funktionen einfach auf einen anderen CPU-Kern übertragen werden, finde ich das in Ordnung

  • Mir gefällt, dass man sehen kann, wie HTML in Echtzeit gestreamt wird. Das erinnert an die Einwahlzeit, als Bilder sich langsam von oben nach unten aufgebaut haben

    • Das weckt Erinnerungen. Das miserable Modem in der Schule war im Vergleich zu den 128er-ISDN-Anschlüssen am Arbeitsplatz meines Vaters unerträglich langsam
      Dort konnte man pro Verbindung mehrere Songs von FTP und später von Napster herunterladen

  • Beim Titel war mein erster Gedanke: „Viele Embedded-/IoT-Geräte machen doch genau so etwas“
    Hier ist ein Beispiel für einen 8051 mit integriertem 10/100 Ethernet: https://www.asix.com.tw/public/index.php/en/product/Microcon...

  • Zwei Dinge fand ich interessant. Erstens gibt es ein Erratum von 2025 zu RFC 1055, das hier in www.c noch nicht enthalten ist. Dieses Erratum zeigt ziemlich überzeugend, wie sich dadurch der Decodieralgorithmus ändert, und in diesem Fall ist die Gegenstelle der Verbindung tatsächlich Linux
    Zweitens ist das nächste Ziel vermutlich RFC 1144

  • Die Kombination ENC28J60 + PIC18 war genau die Konfiguration, die Microchip vor 20 Jahren in häufig verteilten Demos für genau solche Aufgaben verwendet hat

  • Mir gefällt, dass der Proxy den server:-Header der Seite nicht überschrieben hat

  • Ich habe früher einmal etwas Ähnliches mit einem Arduino Mega gebaut. Überraschend war, wie überzeugend das wirken konnte, weil der Client einen Großteil der Arbeit übernimmt und der Controller im Grunde nur Inhalte von einer uSD-Karte ausliefert