4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • M

    Version 0.0.2.156:

    - Netzwerk-API implementiert -> Userprogramme im Netzwerk mit TCP sind jetzt möglich
    - starwars.ELF als erstes Netzwerk-Userprogramm hinzugefügt

    0
  • E
    Mod

    version = "0.0.2.157 - Rev: 998"

    - Fehler (Parameterreihenfolge) berichtigt in tcp_usend
    - user program "browser.elf" beispielhaft erstellt (Zugriff auf Homepage ehenkes), um tcp_usend (kernel) aus dem user-land mittels syscall zu testen. Funktioniert nun prächtig!

    0
  • E
    Mod

    version = "0.0.2.158 - Rev: 999"

    - strg+i, strg+w, strg+x entfernt.

    - tcp..h/c: Nutzung von TCB entsprechend RFC 793 testweise für Active Open begonnen.

    Active open klappt noch. 🙂

    Literatur: http://www.systems.ethz.ch/education/past-courses/fs10/operating-systems-and-networks/material/TCP-Spec.pdf

    0
  • E
    Mod

    version = "0.0.2.159 - Rev: 1000" und
    version = "0.0.2.160 - Rev: 1001"

    Weiterentwicklung bei tcp.h/c gemäßt rfc 793.

    Problem: SEQs und ACKs beim Datentausch auf auf FIN offenbar noch falsch.
    Letzte korrekte Rev: 999

    0
  • E
    Mod

    version = "0.0.2.161 - Rev: 1002"

    Problem bei tcp.c:

    Mischung aus Rev. 1001 und rollback zu Rev. 999. Nun kann man systematisch den Logikfehler im Ablauf suchen.
    Ein Fehler war die Verwechslung zwischen length und tcpDataLength = -4 /* frame ? */ + length - (tcp->dataOffset << 2);
    Die -4 wird bis jetzt nicht verstanden!!!

    Die passive open Seite läuft leider nicht ok (Test-PC, strg+b, telnet: open geht, send blabla <--- ACK-Problem)

    0
  • E
    Mod

    version = "0.0.2.162 - Rev: 1003"

    Wesentliche Fehler beseitigt in tcp.c:
    - kein Erhöhen der SND.NXT beim Empfang bei ESTABLISHED (die +1 gilt nur für den 3-way-handshake)
    - dafür Erhöhen der SND.NXT beim eigenen Senden ^^

    Unklar nach wie vor:

    uint32_t tcpDataLength = -4 /* frame ? */ + length - (tcp->dataOffset << 2);

    Problem: passive open noch nicht in Ordnung!

    0
  • E
    Mod

    version = "0.0.2.163 - Rev: 1004"

    Nun gelingt auch passive open mit anschließendem Datentausch:
    Hierbei Test-PC verwenden, dafür #define QEMU_HACK auskommentieren.
    Für telnet (PrettyOS als Server) unbedingt #define _NETWORK_DATA_ aktivieren, damit man die ankommenden Daten sieht. Hier müsste jemand ein telnet-Server-Programm schreiben im user-land von PrettyOS. 😉

    0
  • M

    Version 0.0.2.164:

    - Funktion zum verschieben von Elementen zwischen Ringen implementiert: Scheduler verursacht weniger Speicherallokationen/Deallokationen
    - Code aufgeräumt, Änderung an dummy.c reverted.
    - rtl8139_eeprom.c/h gelöscht, da kein konkreter Anwendungszweck vorhanden (wurde ohne klaren Zweck mit Rev. 708 von bheide hinzugefügt)

    0
  • E
    Mod

    version = "0.0.2.165 - Rev: 1006"

    static bool IsSegmentAcceptable (tcpPacket_t* tcp, tcpConnection_t* connection, uint16_t tcpDatalength) hinzugefügt und im TCP-Datenempfang eingesetzt, um eingehende Pakete zu prüfen.

    beep ausgeschaltet

    0
  • E
    Mod

    version = "0.0.2.166 - Rev: 1007" (??)

    Codevereinfachungen in tcp.c

    0
  • E
    Mod

    version = "0.0.2.167 - Rev: 1007"

    SND.WND, RCV.WND. SEG.WND verwendet.

    Aktuell:

    Vorgabe:
    const uint16_t STARTWINDOWS = 8192; // Wert des Empfangspuffers

    Reduktion des Empfangspuffers nach Empfang (vor tcp_send):
    connection->tcb.SND.WND -= tcpDataLength;
    connection->tcb.SEG.WND = connection->tcb.SND.WND;

    Wiederherstellung des Empfangspuffers (mach tcp_send):
    connection->tcb.SND.WND = STARTWINDOWS; // Simuliert Weitergabe der Daten an user-App, z.B. unseren Browser.

    0
  • E
    Mod

    version = "0.0.2.168 - Rev: 1008"

    TCP: kleine Verbesserungen

    0
  • E
    Mod

    version = "0.0.2.169 - Rev: 1009"

    Funktion tcp_receive(...) wurde intern komplett umgebaut. Die erste Ordnungspriorität haben nun die Zustände (states) und nicht mehr die Flags.
    Damit lässt sich das Modul besser mit den Plänen in http://www.medianet.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf vergleichen.

    Tests: browser , starwars (beides active open) und telnet-server (passive open, zur Zeit nur mit Hardware testbar) gehen noch.

    0
  • E
    Mod

    version = "0.0.2.170 - Rev: 1010"

    Verbesserungen in tcp.c

    0
  • E
    Mod

    version = "0.0.2.171 - Rev: 1011"

    Verbesserungen tcp.c und network.h (nun kann einfacher zwischen Qemu und Hardware umgestellt werden)

    Anmerkungen :
    Will man Qemu als telnet-Server verwenden: _NETWORK_DATA_ aktivieren in os.h, damit die Daten angezeigt werden (vielleicht hat dies auch noch einen Seiteneffekt).

    Mit Qemu/TAP klappt es leider noch nicht korrekt. Es bleibt beim SYN (telnet) - SYN,ACK (PrettyOS) hängen.

    0
  • E
    Mod

    version = "0.0.2.172 - Rev: 1012"

    Farbschemata weiter angepasst, z.B. textColor(WHITE) durch textColor(TEXT) usw.

    0
  • E
    Mod

    version = "0.0.2.173 - Rev: 1013"

    #define _TCP_NETWORK_DATA_ geschaffen. Damit klappt dann auch der telnet-Server Hardwaretest. Offensichtlich ein Zeitproblem, bei Hardware nicht erstaunlich.

    0
  • E
    Mod

    version = "0.0.2.174 - Rev: 1014"

    Einige Fehler bei passive open in tcp.c behoben.
    tcp_data_Längenberechnung noch falsch. 🙄

    0
  • E
    Mod

    version = "0.0.2.175 - Rev: 1015"

    lastPacket erweitert, um die verbleibenden Datenlängen auf den einzelnen Stufen zu ermitteln

    Kette bei uns:

    EthernetRecv(buffer->adapter, (ethernet_t*)buffer->data, buffer->length);               // network.c
EthernetRecv(network_adapter_t* adapter, ethernet_t* eth, uint32_t length){...}         // ethernet.c

if ((eth->type_len[0] == 0x08) && (eth->type_len[1] == 0x00)) // IPv4                   // ethernet.c
{
     ipv4_received(adapter, (void*)(eth+1), length-sizeof(ethernet_t));
}

ipv4_received(struct network_adapter* adapter, ipv4Packet_t* packet, uint32_t length)   // ipv4.c

tcp_receive(adapter, (void*)(packet+1), packet->sourceIP, length-sizeof(ipv4Packet_t)); // ipv4.c
uint32_t tcpDataLength = -4 /* CRC ? */ + length - (tcp->dataOffset << 2);            // tcp.c

    Die -4 könnte die CRC sein, wenn diese im Paket noch dabei ist.
    TODO: das ganze verbleibende TCP-Paket zeigen in PrettyOS (in wireshark sieht man hinter den tcp-Daten nichts)

    0
  • E
    Mod

    version = "0.0.2.176 - Rev: 1016" (in ckernel.c zu hoch gedreht)

    Analyse des TCP Daten Pakets, dort hinten hängt noch ggf. PAD und 4 bytes CRC

    TODO: CRC und PAD müssen korrekt behandelt werden!

    Tests mit Cuervo (bei ihm klappts in qemu ohne TAP):

    Cuervo:
    mit pcnet:

    send 123456: 31 32 33 34 35 36 0D 0A
send 12345:  31 32 33 34 35 0D 0A

    mit rtl8139:

    send 1:      31 0D 0A 00 00 00 16 FC 7F A0

    also mehrere PADs möglich.

    Das PAD-Feld wird verwendet, um den Ethernet-Frame auf die erforderliche Minimalgröße von 64 Byte zu bringen. Das ist bei alten Übertragungsverfahren wichtig, um Kollisionen in der sogenannten Collision-Domain sicher zu erkennen. Präambel und SFD (8 Bytes) werden bei der erforderlichen Mindestlänge des Frames nicht mitgezählt, wohl aber ein VLAN-Tag. Ein PAD-Feld wird somit erforderlich, wenn als Nutzdaten weniger als 46 bzw. 42 Bytes (ohne bzw. mit 802.1Q-VLAN-Tag) zu übertragen sind. Das in Type angegebene Protokoll muss dafür sorgen, dass diese als Pad angefügten Bytes (auch „Padding Bytes“ genannt) nicht interpretiert werden, wofür es üblicherweise eine eigene Nutzdaten-Längenangabe bereithält.

    http://upload.wikimedia.org/wikipedia/de/a/aa/Ethernetpaket.svg

    testPC ehenkes:

    send 123456: 31 32 33 34 35 36 .. .. .. .. 
send 12345:  31 32 33 34 35 00 .. .. .. ..

    ⚠

    Cuervo: mit pcnet kommt die CRC nicht, mit rtl8139 schon (in qemu)

    Die Frage ist nun: wie analysiert man das ganz vorne in ethernet.c

    0
Anmelden zum Antworten