4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    version = "0.0.2.194 - Rev: 1039"

    tcp ausgaben stark vereinfacht

    0
  • E
    Mod

    version = "0.0.2.195 - Rev: 1040"

    Fehler in TCP korrigiert (z.B. window Steuerung)

    0
  • E
    Mod

    version = "0.0.2.196 - Rev: 1041"

    Eigenes Ping, also ICMP_echoRequest, eingebaut, und Empfang auf den ICMP_echoReply erweitert. leider funktioniert das auf der VM Qemu bisher noch nicht. Daher sollte man zunächst auf Hardware testen.

    Hier das Ergebnis auf strg+p:

    case 'p':
{
  IP_t destIP; // www.henkessoft.de
  destIP.IP[0] =    82; destIP.IP[1] =   100; 
  destIP.IP[2] =   220; destIP.IP[3] =    68;

  network_adapter_t* adapter = network_getFirstAdapter();
  if (adapter)
  {
    ICMP_echoRequest(adapter, destIP);
  }
  break;
}

    Folgendes tauscht dann als Analyse des Echos in PrettyOS wieder auf:

    ICMP_echoReply:  ID: AFFE seq: 1 
PrettyOS ist das Betriebssystem der Projektgru
ppe "OS-Development" im deutschsprachigen C++-Forum ...

    (Anmerkung: string wird noch nicht korrekt ausgelesen. Zeichen danach?)

    aus wiki: Das „Daten“-Feld kann jedoch auch dazu missbraucht werden, um Nutzdaten zu übertragen (ICMP-Tunneling). 😉 Werbung für PrettyOS und c++.de 😉
    hrping hat Cäsars de bello Gallico als Datensatz. 😃

    Macht man dies mit dem qemu hack, so taucht beim Versuch des Erreichens des Host-Subnets eine ICMP Botschaft in wireshark auf, die wir bisher noch nicht analysieren: "destination unreachable".

    264 27.444422 10.0.2.15 192.168.1.1 ICMP 2187 Echo (ping) request id=0xaffe, seq=1/256, ttl=128
    265 27.444593 10.0.2.2 10.0.2.16 ICMP 120 Destination unreachable (Port unreachable)

    ICMP bietet hiermit einen vielleicht guten Weg, um das qemu subnet 10.0.2.x und den Zusammenhang zum Host subnet (hier 192.168.1.x) zu analysieren und qemu so einzurichten, dass wir letztendlich auch unter Windows auf den störenden qemu hack verzichten können.

    siehe: http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol

    0
  • M

    Version 0.0.2.197:

    - BL1 und BL2: Code aufgeräumt/optimiert, Hotfixes gesichtet und ggf. entfernt.
    - memcpy, memset und memsetw weiter verbessert; Zwei Bugs entfernt.
    - Weitere Funktionen in Standardlib implementiert

    0
  • E
    Mod

    version = "0.0.2.198 - Rev: 1043"

    - ICMP weiter vervollständigt

    strg+p: wir versuchen uns selbst zu "pingen": http://www.henkessoft.de/OS_Dev/Bilder/rev.1043_ICMP_PING.PNG "Destination port unreachable"

    Anmerkung: der ARP request erscheint sinnlos.

    0
  • E
    Mod

    version = "0.0.2.199 - Rev: 1044"

    - Kleine Korrekturen im Netzwerkbereich

    0
  • E
    Mod

    version = "0.0.2.200 - Rev: 1045"

    - #defines ... in os.h getestet und Fehler beseitigt (nun können alle geöffnet werden. Code compiliert, aber das Programm ist nicht mehr wirklich lauffähig. 😉 )
    - icmp.c Zahlen gegen die defines ausgetauscht aus icmp.h
    - Ausgaben bei Netzwerk verfeinert (z.B. nur eigenes tcp-window beim Senden)
    - tcp-window-Steuerung verbessert

    TODO: tcp In-Buffer freigeben nach Weitergabe an die Application

    0
  • E
    Mod

    version = "0.0.2.200 - Rev: 1046"

    starwars:
    Bildschirmlöschen eingebaut (vielleicht muss man noch Pakete zusammenfassen)

    0
  • E
    Mod

    version = "0.0.2.201 - Rev: 1047"

    - NetBIOS hinzugefügt
    - tcp Out Buffer versuchsweise verwendet (log-Fkt. eingebaut)
    - strg+p pingt jetzt 10.0.2.x (x = 0 ... 254)

    0
  • E
    Mod

    version = "0.0.2.202 - Rev: 1048"

    Fehler korrigiert in tcp.c, der zu #PF führte (malloc ...)

    tcp_showOutBuffers(connection,true); <--- testweise in tcp.c, zeile 460

    0
  • E
    Mod

    version = "0.0.2.203 - Rev: 1049"

    Netzwerk: Fehlerbeseitigung, Verfeinerung

    0
  • E
    Mod

    version = "0.0.2.204 - Rev: 1050"

    bei tcp_showOutBuffers werden bereits per ACK bestätigte Daten grün und die anderen braun angzeigt.

    Idee: Die grün angezeigten Daten können gelöscht werden, weil bereits angekommen und bestätigt. Die braun angezeigten Daten werden nach einer gewissen Zeit erneut gesendet. Hierbei wird keine Sinnfrage gestellt.

    0
  • E
    Mod

    version = "0.0.2.205 - Rev: 1051"

    - Zeiterfassung packet sent und packet acknowledged eingebaut, RTT-Bestimmung ( http://de.wikipedia.org/wiki/Paketumlaufzeit )

    0
  • E
    Mod

    version = "0.0.2.206 - Rev: 1052"

    - Verbesserte Version für RTT

    0
  • M

    Version 0.0.2.207:

    - tcp_findConnection verbessert: Mit tcp_findConnectionListen zusammengeführt, beachtet beim passiven Verbinden die Angabe des Ports
    - Angefangen, lastPacket zu entfernen. Nur noch der derzeit nötige Teil ist vorhanden
    - Zahlreiche Codestyle-Anpassungen. Bitte Styleguide beachten: Leerzeichen statt Tabs, keine Leerzeichen am Zeilenende.

    0
  • E
    Mod

    version = "0.0.2.208 - Rev: 1054"

    - RTO wird bestimmt nach RFC 2988 und aufgerundet auf 1000 msec (typische RTT sind ca. 100 ms ins Internet)
    - #define SYSTEMFREQUENCY 100 in timer.h (nicht mehr versteckt in ckernel.c) 🙂

    0
  • E
    Mod

    version = "0.0.2.209 - Rev: 1055"

    - retransmission eingefügt (rfc2988)

    version = "0.0.2.210 - Rev: 1056"

    - Fehler korrigiert bei retransmit (seq.nxt anstelle alte seq wurde in tcp_send geschickt)

    version = "0.0.2.211 - Rev: 1057"

    - Testwert für RTO in tcp.c entfernt. Jetzt wieder check auf time > RTO.

    0
  • E
    Mod

    version = "0.0.2.212 - Rev: 1058"

    Vereinfachungen im Code von tcp.c, z.B. send_ACK(...)

    0
  • E
    Mod

    version = "0.0.2.213 - Rev: 1059"

    - Fehler in RTO calculation (in letzter Versioin versehentlich eingebaut) wieder behoben

    0
  • E
    Mod

    version = "0.0.2.214 - Rev: 1060"

    - Eigenen tcp-Log auf die serielle Schittstelle 1 implementiert, der empfangene und gesendete Pakete mit relativen seq-/ack-Numbers dokumentiert
    - Fehler korrigiert (mit Hilfe des serial Logs aufgefallen!) 🙂

    Einfügen in qemu-Batch: -serial file:serielleSchnittstelle1.txt (nicht com1.txt verwenden. Das wird bereits unsichtbar verwendet, kann also nicht erstellt werden.)

    Bsp. mit "browser":

    send:  SYN	    seq:	0	  seq nxt:	1
recv:  SYN ACK	seq:	0	  rcv nxt:	1	  ack:	1
send:  ACK	    seq:	1	  seq nxt:	1	  ack:	1		 SND.UNA:	0

send:  ACK	    seq:	1	  seq nxt:	82	 ack:	1
recv:  ACK PSH	seq:	1	  rcv nxt:	248	ack:	82		SND.UNA:	82
send:  ACK	    seq:	82	 seq nxt:	82	 ack:	248
recv:  ACK PSH	seq:	248	rcv nxt:	755	ack:	82		SND.UNA:	82
send:  ACK	    seq:	82	 seq nxt:	82	 ack:	755
recv:  ACK PSH	seq:	248	rcv nxt:	755	ack:	82		SND.UNA:	82
send:  ACK	    seq:	82	 seq nxt:	82	 ack:	755

send:  RST	    seq:	82	 seq nxt:	82

    Reihenfolge der Pakete stimmt so wie oben (dort manuell sortiert) in der Ausgabe noch nicht, liegt noch am Sourcecode, da wir dort noch sofort senden, den serial_log gebe ich erst am Ende der tcp_receive aus. Sollte noch sinnvoll umgebaut werden. Die Abläufe funktionieren noch nicht komplett RFC793ff. konform.

    0
Anmelden zum Antworten