Sourcecode Fortschritt
-
version 0.0.1.155 - Rev: 732
icmp.c/.h
- hinzugefügtInformationen zum ICMP-Protokoll
http://tools.ietf.org/html/rfc1071 <--- internet checksum
http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol <--- icmp Protocol
-
Version 0.0.1.156:
- task.c: cli/sti-Änderungen gesichtet, Fehler behoben und wieder reingenommen
- Aufgeräumt
- Projektfile aktualisiert
-
version 0.0.1.157 - Rev: 734
icmp.c/.h
- ICMPAnswerPing(...), mit Statischen werten hinzugefügt und experimentiert, bisher ohne Erfolg.
-
version 0.0.1.157 - Rev: 735
icmp.c/.h
- ICMPAnswerPing(...), erweitert und getestet. Noch kein Erfolg.
-
Version 0.0.1.158:
- Umstellung der IRQ/ISR-Nummern auf enum begonnen
- Scheduler unterstützt nun waitForIRQ - Wait-Funktionen damit vorerst komplett
- getch auf waitForIRQ umgestellt - Genauso Ressourcensparend, aber performanter (kein hlt das andere tasks ausbremst)
- switch_context führt abhängig von der Anzahl der laufenden tasks hlt aus
-
Version 0.0.1.158 ist fehlerhaft (memory leak), und icmp.c/.h noch ziemlich unbrauchbar.
http://codepad.org/0YDxC2n1 <-- Workaround von MrX
-
version 0.0.1.159 - Rev: 737
keyboard.c/.h
- Workaround von MrX implementiert (getch)ipTcpStack.c/.h
- switch konstrukt für die Protokolle in IPheader hinzugefügt
-
- arp reply ohne adresse! (das war schon besser)
- icmp reply funktioniert nicht! (kommt in wireshark nicht an)
-
version 0.0.1.160 – Revision 738
IP/ICMP
- Header korrigiert
- Checksummenfunktion korrigiert
- ICMP-Ping-Reply-Funktion korrigiert
=> Wireshark zeigt korrekte Antwort anPS: Dass ping bei mir keine Antwort anzeigt, mag an meiner Netzwerkkonfiguration liegen (da bei Wireshark von MAC über IP bis hin zu Checksumme alles zu stimmen scheint).
-
Version 0.0.1.161 – Revision 739
ICMP: Datenteil
- ICMP-Pings enthalten einen Datenteil, den man zurückschicken sollte – was ab jetzt auch getan wird.
-
http://img192.imageshack.us/img192/3690/pinght.png <--- erfolgsmeldung von Ideenlos. Gratulation!
-
"Ideenlos" war schneller als ich, der es nur mit hrPing und 56 byte Daten schaffte:
hrping 192.168.10.97 -S -t -l 56http://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.9800% 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.
