4. Sourcecode Fortschritt

Sourcecode Fortschritt

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

    version = "0.0.2.180 - Rev: 1023"

    #define MAX_EVENTS 2000 <--- damit der IRC Client funktioniert (ist nun auf max. 667 Zeichen beschränkt, da drei Events pro Zeichen: EVENT_KEY_DOWN, EVENT_KEY_UP und EVENT_TEXT_ENTERED)

    Nicht perfekt, aber eine Zwischenlösung.

    0
  • E
    Mod

    version = "0.0.2.181 - Rev: 1024"

    list und ring mit ASSERT gesichert (list.c), damit fehlerhafte Parameter sichtbar werden.

    0
  • M

    Version 0.0.2.182:

    - PCI: pci_deviceSentInterrupt implementiert, PCI-Bars 2-6 nur ausgelesen, wenn headerType 0
    - listHead_t in list_t umbenannt
    - CRC nun im RTL8139-Treiber aus empfangenen Paketen entfernt.
    - Dummy.c: Schon wieder reverted. Das ist keine Spielwiese! Zum testen einfach eine neue .c-Datei in other_userprogs anlegen. Das funktioniert viel besser, weil die dann automatisch übersetzt und auf die Floppy gepackt wird.
    - fdir-Anzeige überarbeitet, Code verständlich gemacht
    - Kleinigkeiten

    0
  • E
    Mod

    version = "0.0.2.183 - Rev: 1026" (in ckernel.c: versehentlich 1025)

    tcp: in/out Buffer angefangen

    arp: nicht table, sondern cache (führt zu cache->table, besser als table->table)

    user-prg:
    irc.elf etwas weiter entwickelt.

    0
  • E
    Mod

    version = "0.0.2.184 - Rev: 1027"

    tcpIn_t, tcpOut_t, ... hinzu gefügt.

    Problem: tcp.c, Zeile 432 ff.: Fill in-buffer list arbeitet zu langsam.
    Aktiviert man memcpy(In->data, ...), dann bleibt der starwars-Empfang in Qemu hängen (Test auf einen hohen Dateninput). Kann man event.buffer und In->data (dauerhaft auf dem Heap) kombinieren und das doppelte memcpy sparen?

    Vielleicht benötigen wir auch ein schnelleres memcpy in Assembler.

    beep weg (sehr lästig beim Testen)

    Code läst sich bis -O2 compilieren, dann gehen auch beide memcpy, allerdings nicht mit -O3, dort kommt ein Fehler bei der checksum-Routine.

    0
  • E
    Mod

    Lösungsvorschlag:

    uint16_t udptcpCalculateChecksum(void* p, uint16_t length, IP_t srcIP, IP_t destIP, uint16_t protocol) 
{ 
    updtcpPseudoHeader_t pseudo = { srcIP, destIP, 0, protocol, htons(length) }; 
    uint32_t pseudoHeaderChecksum = 0; 

    for(uint32_t i = 0; i < sizeof(updtcpPseudoHeader_t); i+=2) 
    { 
        pseudoHeaderChecksum += htons(((uint16_t*)&pseudo)[i]); 
    } 

    return internetChecksum(p, length, pseudoHeaderChecksum); 
}
    0
  • M

    Den O3-Fehler kenne ich. Ist afaik ein Bug in GCC 4.4.0, der in gcc 4.4.4? gefixt wurde. Da es aber keinen Grund gibt, mit -O3 zu kompilieren, denke ich, dass ein Workaround nicht nötig ist.

    0
Anmelden zum Antworten