4. Sourcecode Fortschritt

Sourcecode Fortschritt

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

    version = "0.0.2.178 - Rev: 1019"

    Farbkorrektur bei ARP Cache: ... (thx to Cuervo)

    0
  • E
    Mod

    version = "0.0.2.178 - Rev: 1020"

    irc.c hinzugefügt, experimentalstatus, aber es gelang damit der eintritt in den euirc chat #PrettyOS

    Meilenstein IRC! 🙂

    0
  • E
    Mod

    version = "0.0.2.179 - Rev: 1021"

    connection->tcb.SEG.SEQ = connection->tcb.SND.NXT;

    ergänzt in tcp.c bei tcp_send(...) für ESTABLISHED

    0
  • E
    Mod

    version = "0.0.2.179 - Rev: 1022"

    irc.c weiter entwickelt, man kann texte bis max. 7 zeichen (gets oder event Problem?) eingeben. Diese werden in den channel #PrettyOS gesendet.

    Problem:
    <Pretty00001>1234567 sieben zeichen gehen
    bei 12345678 (Eingabe) bleibt das User-Programm hängen.

    0
Anmelden zum Antworten