4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • 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
  • E
    Mod

    version = "0.0.2.177 - Rev: 1017"

    tcp.c: Test auf PADs im Ethernet-Paket zur Korrektur von tcpDataLength
    Erläuterung: bei Ethernet-Paketen < 64 byte (ohne VLAN tag gerechnet, aber mit CRC) wird mit Nullen aufgefüllt. Wir setzen uns genau auf das letzte mit tcpDataLength ermittelte Byte, dann klappern wir die Bytes ab. Bei 0x00 (padding) wird tcpDataLength jeweils um 1 verkürzt.

    uint32_t tcpDataLength = tcpDataLength = length - (tcp->dataOffset << 2) - 4; /* FCS */;
uint8_t PadCount = 0;
for (uint16_t i=tcpDataLength-1; i>=0; i--)
{
    if ( (*(uint8_t*)((uintptr_t)tcp + (tcp->dataOffset << 2) + i) ) == 0x00 )
    {
        PadCount++;
    }
    else
    {
        break;						
    }
}
tcpDataLength -= PadCount;

    Damit erzielen wir gültige ACKs. 🙂

    version = "0.0.2.177 - Rev: 1018"

    ohne lästiger Stop 😉

    0
Anmelden zum Antworten