Sourcecode Fortschritt
-
version 0.0.1.140 - Rev: 713
erste Sendeversuche zum experimentieren
-
Version 0.0.1.141 - Rev: 714
Korrektur bei MAC-Adresse bei Tx
Klappt aber noch nicht
-
Version 0.0.1.142 - Rev: 715
Korrektur bei Tx: Interrupt TOK klappt jetzt
qemu batch:
qemu.exe -fda FloppyImage.img -soundhw pcspk -net nic,model=rtl8139,addr=1A,macaddr=00:12:12:12:12:12 -net tap,ifname=TAP2 -net user -localtime -usb -usbdevice disk:format=raw:dummy.bin
TAP2 mit IP 192.168.10.50 konfiguriert.
Mit qemu kommt es auch an (Kontrolle mit wireshark):
arp-request: "5","2.110467","52:55:0a:00:02:02","Broadcast","ARP","Who has 192.168.10.50? Tell 10.0.2.2" arp-reply: "6","2.110475","Plus_12:12:12","52:55:0a:00:02:02","ARP","192.168.10.50 is at 00:12:12:12:12:12"
Ethernet II, Src: Plus_12:12:12 (00:12:12:12:12:12), Dst: 52:55:0a:00:02:02 (52:55:0a:00:02:02)
Type: ARP (0x0806)
Address Resolution Protocol (reply)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (0x0002)
Is gratuitous: False
Sender MAC address: Plus_12:12:12 (00:12:12:12:12:12)
Sender IP address: 192.168.10.50 (192.168.10.50)
Target MAC address: 52:55:0a:00:02:02 (52:55:0a:00:02:02)
Target IP address: 10.0.2.2 (10.0.2.2)
-
Version 0.0.1.143 - Rev: 716
HOTFIX: in task.c , zeile 305: den reboot verhindert
if(currentTask == kernelTask) // TODO: Handle termination of shellTask { // systemControl(REBOOT); }
Wenn ich das richtig sehe, sind die plötzlichen "reboots" weg, allerdings tauchen dennoch #GPF auf.
Da kann zwar der pid 0 (also kernel task) "verschwinden" (siehe strg+t), aber dennoch läuft es stabiler. Seit Version 0.0.1.131 (MrX) spielen da einige Sachen leider "verrückt".
Fazit: hat nicht geholfen, es müssen die cli/sti sein, die MrX "aufgeräumt" hat.
-
0.0.1.144 - Rev: 717
in task.c cli()/sti() wieder eingefügt, um den reboot zu überwinden!
EDIT: #GPF (kernel) und #PF (user) tauchen immer noch auf. Richtig übel! Ich schlage einen Roll-back bei task.h/c (und damit zusammenhängende) vor.
Ich schlage vor, dass wir ein abgestimmtes Test-Szenario entwicklen und für jeden developer vorgeben, das ein Commit im Regelfall durchlaufen muss, um solche Folgen wie bei 0.0.1.131 zu verhindern.
-
0.0.1.145 - Rev: 718
cli/sti noch etwas nachgebessert in task.c
erneuter #GPF: error code: 0 (!), anschließend reboot
es tauchen aber auch andere #GPF auf: GPF err code: 64912 eip: 113D50h
(intel (june 2010) 3A, 6-13: EXT=0 IDT=1 segment selelctor index: 00100010 = 0x22 = 34)sieht immer noch nicht gut aus!
-
Nun reicht es wirklich!
Roll-back bezüglich task.h/c (Version von 0.0.1.130 - Rev. 701 eingebaut, weitere Anpassungen waren glücklicherweise nicht notwendig)
0.0.1.146 - Rev: 719
qemu läuft.
VBox und VMware machen Probleme mit vbe (also 's'), VBox auch beim Überspringen von vbe noch GPF. Das konnten wir schon besser!
-
version 0.0.1.147 - Rev: 720
vbe.c/.h
typedef struct { uint16_t x, y; } CursorPosition_t;
Hinzugefügt und mit DrawChar(...) newline experimentiert.
erstmal bewusst nicht aus video.h genommen um erstmal eine strikte trennen zwischen Textmodus und VESA zu halten.
-
Version 0.0.1.148:
- Schäden behoben, cli/sti-Änderungen aus task.c wieder ausgebaut, andere Änderungen eingebaut. Funktioniert wohl nun wieder alles.
- Patch für VM86.c von Ideenlos
- Codeformatierungen
-
Revision 722
Bootloader-stage2
- So verändert (arbeitet jetzt im UnrealMode), dass der Kernel theoretisch beliebig groß werden kann.
-
version 0.0.1.150 - Rev: 723
Ordner Struktur in Kernel um network und netprotocol erweitert, entsprechende Dateien dorthin verschoben.
-
version 0.0.1.150 - Rev: 724
udp.c/.h
- UDP Header Hinzugefügt.
-
Version 0.0.1.151 - Rev. 726
Senden verbessert (length)
Testen: wireshark
-
Version 0.0.1.152 - Rev. 727
Senden verbessert (korrekte mac-adresse verwendet)
Testen: anpingen und mit arp -a im arp-cache des senders nachschauen
Verfolgen: wireshark
-
Version 0.0.1.153 - Rev. 730 (einige rev. bewusst übersprungen wegen commit-fehler)
Nun klappt die antwort auf arp-requests spezifisch und korrekt!
Bitte stellt eure spezifische IP-Adresse statisch in dem neuen Header myOwnData.h ein, bei mir z.B:
#ifndef MYOWNDATA_H #define MYOWNDATA_H #define My_IP 0xC0A80A61 // 192.168.10.97 #endif
-
version 0.0.1.154 - Rev: 731
dhcp.c/.h
- Grundlegende Idee hinzugefügt.upd.c/.h
- erweitert
-
checksum für ipv4, also auch ping:
// Compute Internet Checksum for "count" bytes beginning at location "addr". uint32_t checksumIPv4(uint32_t count, uintptr_t addr) { register uint32_t sum = 0; while( count > 1 ) // This is the inner loop { sum += *(uint16_t)addr++; count -= 2; } if (count > 0) // Add left-over byte, if any { sum += *(uint8_t*)addr; } while (sum>>16) // Fold 32-bit sum to 16 bits { sum = (sum & 0xFFFF) + (sum >> 16); } return (~sum); }
-
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.