Sourcecode Fortschritt
-
"Ideenlos" war schneller als ich, der es nur mit hrPing und 56 byte Daten schaffte:
hrping 192.168.10.97 -S -t -l 56
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_161_PingReply.PNG
Statistics for 192.168.10.97:
Packets: sent=227, rcvd=153, error=0, lost=74 (32% loss) in 106.126180 sec
RTTs of replies in ms: min/avg/max/dev: 67.929 / 12788.809 / 33029.268 / 8959.212<Tobiking>Das hrPing schickt Latein?
-
Version 0.0.1.162 – Rev: 740
etwas aufgeräumt im Netzwerk-Bereich
Leider ist RXBUFTAIL ab und zu verschoben!
-
Version 0.0.1.163 – Revision 741
rtl8139
- wenn man die Empfangsdaten aus dem entsprechenden Puffer
herauskopiert, werden anscheinend mehr Pakete korrekt empfangen.
-
Das war entscheidend! (findet sich auch im programming guide)
Nun läuft request und reply in wireshark sauber abwechselnd:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_163_PingRequestReply.PNGBeim PING-Absender-Programm kommt trotz dieses Ablaufes dennoch nur noch "timeout" an.
-
Folgendes ist mir noch aufgefallen: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_163_PingRequestReply_badChecksum.PNG
Bad checksum im IP-header und im ICMP!
bitte damit vergleichen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-postdays-is-0-and-postorder-is-asc-and-start-is-777.html
-
version 0.0.1.163 - Rev: 741
TCP header hinzugefügt tcp.c/h
icmpDebug, tcpDebug für eine besser veranschaulischung der jeweiligen Packete.
-
Version 0.0.1.165 – Revision 743
IP/ICMP-Checksumme
- Man sollte es mit dem Aufräumen nicht übertreiben (rev 740): das Checksummenfeld muss tatsächlich vor der Berechnung der Checksumme auf 0 gesetzt werden.
PS: Das hier ist wirklich die 0.0.1.165 und die Rev 743, ich hatte beim letzten Mal nur vergessen, die Version in ckernel.c zu aktualisieren, deshalb hat internet eigentlich die 0.0.1.164 bzw. 742 committet.
-
C:\hrPING>hrping 192.168.10.97 -n20 -l32 -S -s100 This is hrPING v2.44 by cFos Software GmbH -- http://www.cfos.de Using source IP address 192.168.10.99 to send packets Pinging 192.168.10.97 with 32 bytes data (60 bytes IP): Reply from 192.168.10.97: seq=0000 time=14.150ms TTL=128 ID=0000 - sent=1 Reply from 192.168.10.97: seq=0001 time=5.801ms TTL=128 ID=0000 - sent=2 Reply from 192.168.10.97: seq=0002 time=5.790ms TTL=128 ID=0000 - sent=3 Reply from 192.168.10.97: seq=0003 time=5.813ms TTL=128 ID=0000 - sent=4 Reply from 192.168.10.97: seq=0004 time=5.799ms TTL=128 ID=0000 - sent=5 Reply from 192.168.10.97: seq=0005 time=5.808ms TTL=128 ID=0000 - sent=6 Reply from 192.168.10.97: seq=0006 time=5.804ms TTL=128 ID=0000 - sent=7 Reply from 192.168.10.97: seq=0007 time=5.828ms TTL=128 ID=0000 - sent=8 Reply from 192.168.10.97: seq=0008 time=5.834ms TTL=128 ID=0000 - sent=9 Reply from 192.168.10.97: seq=0009 time=5.805ms TTL=128 ID=0000 - sent=10 Reply from 192.168.10.97: seq=000a time=5.805ms TTL=128 ID=0000 - sent=11 Reply from 192.168.10.97: seq=000b time=5.800ms TTL=128 ID=0000 - sent=12 Reply from 192.168.10.97: seq=000c time=5.804ms TTL=128 ID=0000 - sent=13 Reply from 192.168.10.97: seq=000d time=5.805ms TTL=128 ID=0000 - sent=14 Reply from 192.168.10.97: seq=000e time=5.830ms TTL=128 ID=0000 - sent=15 Reply from 192.168.10.97: seq=000f time=5.834ms TTL=128 ID=0000 - sent=16 Reply from 192.168.10.97: seq=0010 time=9.280ms TTL=128 ID=0000 - sent=17 Reply from 192.168.10.97: seq=0011 time=5.844ms TTL=128 ID=0000 - sent=18 Reply from 192.168.10.97: seq=0012 time=5.816ms TTL=128 ID=0000 - sent=19 Reply from 192.168.10.97: seq=0013 time=5.820ms TTL=128 ID=0000 - sent=20 Statistics for 192.168.10.97: Packets: sent=20, rcvd=20, error=0, lost=0 (0% loss) in 1.905816 sec RTTs of replies in ms: min/avg/max/dev: 5.790 / 6.403 / 14.150 / 1.980
0% loss
PrettyOS hat die IP 192.168.10.97
-
Noch zur checksum:
ICMP Header Checksum. 16 bits.
Checksum that covers the ICMP message. This is the 16-bit one's complement
of the one's complement sum of the ICMP message starting with the Type field.The checksum field should be cleared to zero before generating the checksum.
-
Version 0.0.1.166:
- Floppytreiber nutzt nun hlt während er auf ein IRQ wartet. (waitForIRQ geht nicht, weil wir dort ein timeout haben)
- getch nutzt wieder waitForIRQ, Fehler behoben, keine task-Mutation mehr, Speicherleck weg.
- Neues Feature zur Memory-Leak-Erkennung. (Aktivierung in os.h, Funktioniert derzeit nicht stabil)
- Projektdatei aktualisiert
- Kleinigkeiten
-
PrettyOS 0.0.1.166 - Rev: 744
Testumgebung SCREEN (phys) vbe RTL8139 EHCI Probleme ----------------------------------------------------------------------------- qemu-ehci F2000000h ok ja 4 ports nein VBox 3.2.6 E0000000h ok nein 8 ports nein VMWare Player 3.0.1 (mit vbe) invalid opcode bei 1A70h VMWare Player 3.0.1 (ohne vbe) - nein 6 ports keine bochs 2.4.2 E0000000h ok nein nein keine VPC 6.0.192.0 00000000h #PF (err 0, addr 107BC4h) VPC 6.0.192.0 (ohne vbe) - nein nein keine PC 1,4 GHz GeForce4 F4000000h ok ja nein keine
-
0.0.1.167 - Rev. 745:
- Gratuitous ARP Request abgefragt und dargestellt
http://wiki.wireshark.org/Gratuitous_ARP
A gratuitous ARP request is an AddressResolutionProtocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff.
-
Version 0.0.1.168:
- Ausgabe bei Strg+t und co nun in kernelkonsole
- test-results.txt beigelegt
- Kleinigkeiten
-
version 0.0.1.168 - Rev: 747
- Aufgeräumt
- Die #defines in icmp.h um ICMP_ erweitert.Keyboard.c
- Die getch() Funktion sieht im moment so aus.char getch() { char retVal = keyboard_getChar(); while(retVal == 0) { waitForIRQ(1); // not working on realPC ---> Broken Free // sti();hlt(); retVal = keyboard_getChar(); } return(retVal); }
Link zur Darstellung des OSI-7-Modells
http://upload.wikimedia.org/wikipedia/de/1/14/OSI7Layer_model_3.1.svg
-
0.0.1.169 - Rev: 748
Readcache (rev. 580) in devicemanager.c auskommentiert und auf die alte Version (rev. 579) umgestellt.
Reale Lesevorgänge können nun übergangsweise quälend langsam vonstatten gehen, da wir dank fgetc jedes Zeichen einzeln ziehen und dabei jeweils den ganzen Sektor lesen.
Der Schreibcache ist bereits im FAT-Modul eingebaut.
Dafür klappt nun wieder der für Dokumentationen wichtige Screenshot (floppy: strg+s, usb: strg+u).
-
0.0.1.170 - Rev: 749
readcache teilweise (wieder) in betrieb genommen, aber noch nicht genutzt wegen fehler beim schreiben
-
0.0.1.171:
- Optimierungen und Änderungen, die ehenkes und ich ausgebrütet haben (hauptsächlich task.c)
- Readcache aufgeräumt, aber Ergebnis unverändert.
- Weitere Testergebnisse ergänzt
-
0.0.1.172 - Rev: 751
Lesecache aktiviert, für screenshot ausgeschaltet
-
0.0.1.173 - Rev: 752
readcache weiter optimiert, auch bei mehrfacher Abfrage des Puffers werden die 512 Byte zur Sicherheit kopiert (Korrektheit wichtiger als Performance). Beim Anlegen des Cache eines Sektors werden alle validen Dubletten eliminiert (Korrektheit).
-
version 0.0.1.174 - Rev: 753
VBE erweitert, man kann jetzt zwischen 3 Auflösungen wählen
1. 640x480x256 (Bild verschoben)
2. 800x600x256 (Bild verschoben)
3. 1024x768x256 (wird fast korrekt angezeigt)
default: 1024x768x256ckernel.c
- Switch Konstrukt für den gewählten VideoMode hinzugefügt.vbe.c/.h
- switchToVideomode(...) um einen übergabe parameter erweitert, für den zu setzenden VideoMode.vidswitch.asm
- video_mode und ModeInfoBlock, für die 3 jeweiligen oben genannten Bildschirm Auflösungen hinzugefügt.