Eigenes OS - Networking



  • Hallo,
    ich versuche vergeblich Material zum Thema "Eigenes Betreibssystem und Netzwerkprogrammierung" zu finden.
    Ziel soll es sein, einen eigenen kleinen Minikernel zu booten und Datenpakete übers Internet zu verschicken.

    Ideen?
    Danke.



  • Also die erste Idee wäre, dafür nicht Assembler zu nehmen. 😉



  • ^^ da gibts verschiedene möglichkeiten, ...
    (1) wenn dein internetanschluss über ethernet/WLAN funzt, dann brauchste zuerst mal dafür software (treiber) um dein netzwerk-interface anzusprechen und PPP(oE).
    (2) wenn modem, surfstick, GSM-modul etc: internet-einwahl über AT-befehle, d.h. du brauchst die doku, wie das mit deiner hardware konkret geht und PPP
    (3) wenn der router die einwahl macht: du brauchst nur 'nen hardware treiber für dein eth- oder WLAN-interface, kein PPP.
    3 ist am besten, weil auf PPP verzichtet werden kann (PPP ist sehr komplex).
    dann geh' am besten über kabel (ethernet), WLAN-treiber können auch sehr komplex sein, erst recht, wenn verschlüsselung gefordert ist.
    um pakete ins internet zu schicken, brauchste noch UDP (für 3 leider auch noch ARP, um IP-adressen in eth-adressen umzusetzen). aber UDP und ARP sind recht trivial. für alle protokolle findeste fertiges zeug im internet, musst es natürlich anpassen
    alles in allem haste dir viel vorgenommen, ist aber nicht unmöglich. viel glück.
    🙂



  • Ich glaube, 3 kommt bei mir in Frage. Ich habe ne FRITZ!Box WLAN 3131 Kiste.
    Aber selbst wenn ich wüsste, wo ich nen Treiber herkriege, wüsste ich nicht wie ich den anpassen kann.
    :p



  • n00b++ schrieb:

    Aber selbst wenn ich wüsste, wo ich nen Treiber herkriege, wüsste ich nicht wie ich den anpassen kann.
    :p

    Das ist ja auch nix für n00bs!



  • Dieser Thread wurde von Moderator/in Nobuo T aus dem Forum Assembler in das Forum Projekt: OS-Development verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.


  • Mod


  • Mod

    Im übrigen verfügt PrettyOS inzwischen über ein rudimentäres Networking Modul.


  • Mod

    DHCP wäre ein möglicher nächster Schritt. 🙂


  • Mod

    Source     Dest        Source     Dest              Packet
       MAC addr   MAC addr    IP addr    IP addr           Description
       -----------------------------------------------------------------
       Client     Broadcast   0.0.0.0    255.255.255.255   DHCP Discover
       DHCPsrvr   Broadcast   DHCPsrvr   255.255.255.255   DHCP Offer
       Client     Broadcast   0.0.0.0    255.255.255.255   DHCP Request
       DHCPsrvr   Broadcast   DHCPsrvr   255.255.255.255   DHCP ACK
    

    So kann DHCP rudimentär ablaufen.


  • Mod

    Ich denke wir sollten diesen Thread nutzen für die Diskussion bezüglich Netzwerk-Code. DHCP Discover gelingt bereits problemlos. Uns fehlt bisher eine Testumgebung, in der ein Server daraufhin DHCP Offer ausführt. Es ist bisher nicht verständlich, warum der LAN-Router bzw. der Qemu-Server das noch nicht leisten, obwohl wir - gemäß wireshark analysiert - sauber anfragen. Uns fehlen Werkzeuge, um den Gesamtvorgang zu analysieren. Wir sehen nur via wireshark die (nicht) gesendeten Pakete aber nicht die Ursachen dafür, z.B. am Server/Router.


  • Mod

    Eine Frage tauchte in einer Diskussion auf: Gehört Netzwerk zu OSDev? Erster Blick in den Tanenbaum zeigt, dass dieses Thema dort (oberflächlich, d.h. weitgehend theoretisch) behandelt wird. Es gibt allerdings eine Menge Bücher über verteilte Betriebssysteme. Netzwerke und Internet als verlängerte Netzwerke spielen heute eine so wesentliche Rolle, dass Treiber für verschiedene Netzwerkkomponenten und für die Netzwerkprotokolle m.E. zu einem user-orientierten OS moderner Ausrichtung dazu gehören. Daher werden wir diese Thematik weiter verfolgen, auch wenn man in OSDev Communities und Foren hierzu wenig Unterstützung erfährt.


  • Mod

    Der klassische DHCP-Ablauf: http://www.henkessoft.de/OS_Dev/Bilder/rev936.PNG

    Dies sind die Momente, die für das "Spec" Lesen und viele Fehlversuche entschädigen. DHCP ist nun weitgehend eingetütet.

    Nun ist das nächste Ziel TCP.


  • Mod

    Hier die Software-Simulation von MrX für die korrekte TCP checksum:
    (Das TCP-Paket stammte aus wireshark)

    Version für MSVC++:

    #include <fstream>
    #include <iostream>
    #include <cstdint>
    
    uint16_t internetChecksum(void* addr, size_t count, uint32_t pseudoHeaderChecksum)
    {
        uint32_t sum  = pseudoHeaderChecksum;
        uint8_t* data = (uint8_t*)addr;
    
        while (count > 1) // inner loop
        {
            sum   += (data[0] << 8) | data[1]; // Big Endian
            data  += 2;
            count -= 2;
        }
    
        if (count > 0) // add left-over byte, if any
        {
            sum += data[0] << 8;
        }
    
        while (sum >> 16) // fold 32-bit sum to 16 bits
        {
            sum = (sum & 0xFFFF) + (sum >> 16);
        }
    
        return ~sum & 0xFFFF;
    }
    #pragma pack(1)
    typedef struct {
    	uint8_t src[4];
    	uint8_t dest[4];
    	uint8_t res;
    	uint8_t prot;
    	uint16_t length;
    } pseudo_t;
    
    #define htons(v) ((((v) >> 8) & 0xFF) | (((v) & 0xFF) << 8))
    
    uint16_t udptcpCalculateChecksum(void* p, uint16_t length, uint8_t srcIP[4], uint8_t destIP[4], uint16_t protocol)
    {
    	pseudo_t pseudo;
        for (uint8_t i=0; i<4; i++)
        {
    		pseudo.src[i] = srcIP[i];
    		pseudo.dest[i] = destIP[i];
    	}
    	pseudo.length = htons(length);
    	pseudo.prot = protocol;
    	pseudo.res = 0;
    
        uint32_t pseudoHeaderChecksum = 0;
        uint8_t  count = 12; // pseudo header contains 12 byte
    
        uint8_t* data = (uint8_t*)&pseudo;
    
        while (count > 1)
        {
            // pseudo header contains 6 WORD
            pseudoHeaderChecksum += (data[0] << 8) | data[1]; // Big Endian
            data   += 2;
            count  -= 2;
        }
    
        return internetChecksum(p, length, pseudoHeaderChecksum); // util.c
    }
    
    // Should: 0xf96f
    uint8_t src[4] = {192,168,1,97};
    uint8_t dest[4] = {192,168,1,23};
    int main() 
    {
    	uint8_t packet[] = {00, 0x17, 0x06, 0x07, 0x00, 0x00, 0x00, 0x00, 0x1c, 0xb3, 0x0f, 0xc9, 0x50, 0x12, 0xff, 0xff, 0, 0, 0x00, 0x00};
    	uint16_t checksum = udptcpCalculateChecksum(packet, 20, src, dest, 6);
    	printf("%X\n", checksum);
    	system("PAUSE");
    }
    

    Eine übertragene version für code::blocks findet man im Repo.


  • Mod


  • Mod

    Mit dieser Version kann man bereits sehr schön bezüglich TCP experimentieren:
    http://www.c-plusplus.net/forum/p2082954#2082954


  • Mod

    Das erste user-program mit TCP: starwars.elf (thx to MrX) 🙂 👍
    http://www.c-plusplus.net/forum/p2084431?sid=e87c6e3575b25c6a7266509a9b3b2cf8#2084431 🙂

    userlib.h:

    uint32_t tcp_connect(IP_t IP, uint16_t port); 
    void     tcp_send(uint32_t ID, void* data, size_t length);
    void     tcp_close(uint32_t ID);
    

  • Mod

    http://www.henkessoft.de/OS_Dev/OS_Dev4.htm#mozTocId358796

    Eine Zusammenfassung zum Thema Netzwerk im Tutorial, Teil 4.


  • Mod

    Der IRC Client entwickelt sich schon ganz nett. Man müsste die eingehenden "Umlaute und Sonderzeichen" noch für die Bildschirmausgabe übersetzen und alle Eingaben wahlfrei machen.


  • Mod

    Das tcp-Modul schafft ganz schön Aufwand. Momentan fehlt noch der dup-ack Mechanismus und der timer für das Vernichten der Connection aus dem Zustand TIME_WAIT heraus. Wir versuchen, hierfür die todo_list in erweiterter Form einzusetzen.

    Rückblende:
    Wenn man bedenkt, dass das gesamte Internet weitgehend auf dieser Norm rfc 793 aus 1981 basiert, da staunt man schon. Diejenigen, die diese "arpanet" rfc geschrieben haben, wussten das damals nicht, was sie da Wichtiges machen.Alles basiert auf dem engen Ethernet frame von insgesamt 1500 byte, damals ziemlich viel, heute eher wenig. 1981 gab es gerade mal den IBM PC, der noch keine Festplatte sein eigen nannte, sondern lediglich ein oder zwei Floppys kannte. Er wurde ab 1981 fast 6 Jahre lang unverändert gebaut und war der Quasi-Standard schlechthin. Ab 1983 kam der IBM PC XT, 1984 der IBM PC AT (mit Festplatte und 6 MHz CPU). Der "AT" kostete damals über 20000 DM, daran kann ich mich erinnern, selbst für Großfirmen ein stolzer Betrag. 😉

    Auf der anderen Seite werden heute immer noch PCs gebaut mit diesem Prozessortyp x86 und den damit verbundenen lästigen Mechanismen, die noch jeder Pentium-PC (und kompatible) mit sich herum schleppt.


Log in to reply