Sourcecode Fortschritt
-
Ergänzende Versuche, die jedoch nicht zu DHCP OFFER führten:
- DHCP Options:
// options packet.options[0] = 99; // MAGIC packet.options[1] = 130; // MAGIC packet.options[2] = 83; // MAGIC packet.options[3] = 99; // MAGIC packet.options[4] = 53; // MESSAGE TYPE packet.options[5] = 1; // Length packet.options[6] = 1; // (data) packet.options[7] = 55; // packet.options[8] = 6; // Length packet.options[9] = 1; // SUBNET MASK packet.options[10] = 3; // ROUTERS packet.options[11] = 6; // DOMAIN NAME SERVER packet.options[12] = 15; // DOMAIN NAME packet.options[13] = 28; // BROADCAST ADDRESS packet.options[14] = 42; // Network Time Protocol (NTP) SERVERS packet.options[15] = 57; // MAX MESSAGE SIZE packet.options[16] = 2; // Length packet.options[17] = 2; // (data) packet.options[18] = 64; // (data) packet.options[19] = 255; // end- Next Server IP eingetragen:
for(uint8_t i = 0; i < 4; i++) { packet.ciaddr[i] = 0; packet.yiaddr[i] = 0; // packet.siaddr[i] = 0; packet.giaddr[i] = 0; } // next server IP packet.siaddr[0] = 192; packet.siaddr[1] = 168; packet.siaddr[2] = 10; packet.siaddr[3] = 1;Die Versuche wurden analog mit qemu ausgeführt.
Auch ein Versuch mit
#define IP_1 0 #define IP_2 0 #define IP_3 0 #define IP_4 0zu starten führt bei realer Hardware zu nichts.
Leider kein Erfolg bezüglich DHCP Offer.
------------------------------------------------------
Hier ein erfolgreicher DHCP-Vorgang eines anderen Rechners:
http://www.henkessoft.de/OS_Dev/Bilder/DHCPDiscover01a.PNG (Abfolge, zeitlich seltsam)
http://www.henkessoft.de/OS_Dev/Bilder/DHCPDiscover01.PNG (DHCP Discover)
http://www.henkessoft.de/OS_Dev/Bilder/DHCPDiscover01b.PNG (Options)
-
version = "0.0.2.75 - Rev: 914"
IP 0.0.0.0 als source, andere Options, DHCP Autoconfig
Für qemu konfiguriert.
Leider noch kein Offer. Gute Ideen sind gesucht.
-
Einen weiteren PC probiert mit einer RTL8139C, eingestellter IP 192.168.10.96 und natürlich anderer MAC:
ebenfalls kein DHCP OFFER als AntwortErgänzung:
- kein zugang zum router http://www.c-plusplus.net/forum/287416-60
- IP ... 97 MAC ... ist fest dort eingetragen
jetzt habe ich noch einen testrechner mit passender netzwerkkarte gefunden mit anderer MAC, und da konnte ich nun auch mit 0.0.0.0 starten, hat aber auch keine OFFER gebracht. Nun läuft es aber so, wie es wohl sein soll, nämlich dass die sourceIP 0.0.0.0 ist.
Fazit: wir stecken fest.
Routing? DNS? Gateway?
-
version = "0.0.2.76 - Rev: 915"
- DHCP Discover: Options bearbeitet, z.B. Wunsch-IP. AFFE00xx als laufende xid gebaut, damit man mehrere Messages auseinander halten kann.
- showARPTable optisch verbessert
- bootscreen unterdrückt (macht bei manchen Maschinen Probleme: freeze)
Leider noch kein OFFER
-
version = "0.0.2.77 - Rev: 916"
in rtl8139.c:
sleepMilliseconds(...) durch delay(...) getauscht, weil ein Testrechner dort >50% hängen blieb (endless loop, freeze). Merkwürdiger Fehler, da es ja ab und zu klappte, also kein systematisches Ereignis.
-
version = "0.0.2.78 - Rev: 917"
- Systemfrequenz von 250 Hz (Linux) auf 100 Hz zurückgesetzt, weil es auch bei delay zu Problemen kam (Danke an MrX für diesen Hinweis).
- Options auf 340 Byte erweitert, damit die DHCP-Gesamtgröße von 576 erreicht wird.
- sname und file komplett genullt (sieht in wireshark besser aus ^^)
DHCP Discover sieht in wireshark absolut korrekt aus.
==> bisher kein DHCP OFFER
-
version = "0.0.2.79 - Rev: 918"
- DHCP_INFORM ergänzt
- IP (beim start), SIP (server), RIP (requested) nach vorne in network.h==> bisher weder OFFER noch ACK (allerdings erhielt auch ein anderer PC keine Antwort auf sein gesendetes INFORM)
... kann alles an meinem Router, DHCP server liegen
... Qemu + TAP ist noch verstockter
-
Version 0.0.2.80:
- Verbesserungen an Netzwerktreibern (PCNet und RTL8168): Ausgaben im Interrupt-Handler hinter Makro versteckt.
- Memoryleak beseitigt: Mutex der Keyqueues wurde nicht gelöscht, wenn die keyqueue gelöscht wird.
- userPT und userPD werden nicht mehr "doppelt" freigegeben.
- Überflüssige Membervariablen von task_t entfernt
- Kleinigkeiten/Codestyle.
-
Version 0.0.2.81:
- Bugfix unter Bochs
- bochs.bxrc geupdated
-
version = "0.0.2.82 - Rev: 921"
- Kleinere Formatierungen in task.h/c, kernelStackSize in die Implementierungsdatei verlegt (kein #define)
- Kommentar in arp.cTest mit Emulatoren Bochs, VBox, MS VPC, VMware Player, Qemu verlaufen alle positiv. Herzlichen Dank hierfür an alle Developer und Tester.
Wir hatten auch schon andere Zeiten.
-
version = "0.0.2.83 - Rev: 922"
dma.h/c und executable.h/c Formatierung
-
version = "0.0.2.84 - Rev: 923"
- udp checksum auf 0 (Hinweis von cefour aufgrund RFC), allerdings war hier beim DHCP-Einloggen des Notebooks eine udp checksum voranden: http://www.henkessoft.de/OS_Dev/Bilder/DHCPDiscover01.PNG
- Auf DHCP Discover erfolgte Antwort des Servers an den Client (67 an 68), leider noch ohne Debug (in wireshark nicht sichtbar ?!)
Wir wissen also noch nicht, was uns der DHCP server auf unser DHCP_Discover mitteilt.Beweisfoto: Screenshot (strg+s)
PrettyOS [Version 0.0.2.84 - Rev: 923] -------------------------------------------------------------------------------- packet sent. DHCP Discover sent. EthernetSend: length: 618. >>> Transmission starts <<< Physical Address of Tx Buffer = 014051D8h packet sent. DHCP Discover sent. EthernetSend: length: 618. >>> Transmission starts <<< Physical Address of Tx Buffer = 014051D8h packet sent. Length: 594 MAC Receiver: 00h 10h A7h 0Fh 0Ah 0Ch MAC Transmitter: 00h 22h CFh 36h 9Dh 1Ch Ethernet: type 2, Type: 08h 00h Ethernet 2. Ethernet type: IP. IPv4 packet received. We are not the addressee. Length: 594 MAC Receiver: 00h 10h A7h 0Fh 0Ah 0Ch MAC Transmitter: 00h 22h CFh 36h 9Dh 1Ch Ethernet: type 2, Type: 08h 00h Ethernet 2. Ethernet type: IP. IP version: 4, IP Header Length: 20 byte UDP. UDP Header information: +--------------+----------------+ | 67 | 68 | (source port, destination port) +-------------------------------+ | 556 | 5338h | (length, checksum) +-------------------------------+ UDP Bootstrap Protocol (BOOTP) Client, also used by DHCP Client Screenshot to Floppy (Thread)Einstellungen:
#define IP_1 0 #define IP_2 0 #define IP_3 0 #define IP_4 0 // server IP #define SIP_1 192 #define SIP_2 168 #define SIP_3 1 #define SIP_4 1 // requested IP #define RIP_1 192 #define RIP_2 168 #define RIP_3 1 #define RIP_4 97Nächste Aufgabe: Funktion DHCP_Debug schreiben
Vorbild (?): http://www.koders.com/c/fid179E56E3C11D80DFE25DD6D819369416B3BF583D.aspx
-
version = "0.0.2.85 - Rev: 924"
Wir haben ein erstes DHCP-Paket vom Server. Ein "ACK" auf ein "INFORM".
DHCP_AnalyzeServerMessage:
-------------------------------------------------------------------------------- Monday, June 06, 2011, 22:44:17 141 s runtime. CPU: 1399 MHz \ PrettyOS [Version 0.0.2.85 - Rev: 924] -------------------------------------------------------------------------------- UDP. UDP Header information: +--------------+----------------+ | 67 | 68 | (source port, destination port) +-------------------------------+ | 556 | 5338h | (length, checksum) +-------------------------------+ UDP BOOTP/DHCP Client op: 2 htype: 1 hlen: 6 hops: 0 xid: 0AFFE003h secs: 0 flags: 0000h cIP: 0.0.0.0 yIP: 0.0.0.0 sIP: 0.0.0.0 gIP: 0.0.0.0 MAC: 00h-10h-A7h-0Fh-0Ah-0Ch 63h 82h 53h 63h 35h 01h 05h 36h 04h C0h A8h 01h 01h 01h 04h FFh FFh FFh 00h 03h 04h C0h A8h 01h 01h 06h 04h C0h A8h 01h 01h 0Fh 0Bh 6Ch 6Fh 63h 61h 6Ch 64h 6Fh 6Dh 61h 69h 6Eh 2Ch 08h 00h 00h 00h 00h 00h 00h 00h 00h FFh 00h 00h 00h 00h 00hÜbersetzung / Analyse:
0AFFE003 ist die Kennung für das von mir per strg+n gesendete DHCP_INFORM
MAC: 00h-10h-A7h-0Fh-0Ah-0Ch <--- mein test-PC
63h 82h 53h 63h magic35h 01h 05h: 53dec len:1 data:5
DHCP message type: 5 DHCPACK36h 04h C0h A8h 01h 01h Server Identifier: C0h A8h 01h 01h = 192.168.1.1
01h 04h FFh FFh FFh 00h subnet 255.255.255.0
03h 04h C0h A8h 01h 01h listet alle router auf (s.o., 192.168.1.1)
06h 04h C0h A8h 01h 01h DNS macht er auch ^^
0Fh 0Bh 6Ch 6Fh 63h 61h 6Ch 64h 6Fh 6Dh 61h 69h 6Eh ist der Domain-Name, insgesamt 11 Zeichen lang: "localdomain"
2Ch 08h 00h 00h 00h 00h 00h 00h 00h 00h NetBIOS over TCP/IP name server
FFh happy end!
Dafür benötigen wir eine Funktion.
-
Version 0.0.2.86:
- gdt.c und descriptor_tables.c zusammengeführt und aufgeräumt
- PageDirectory wird nur noch bei Bedarf gewechselt (d.h. wenn der neue Task ein anderes hat als der Alte)
- task_switch greift nun über Funktionen auf TSS zu und nicht mehr direkt
- delayedInitTasks durch kernel_idleTasks ersetzt
-
version = "0.0.2.87 - Rev: 926"
DHCP Options Analyse begonnen.
-
version = "0.0.2.88 - Rev: 927"
Ausgabe der daten bei Options verbessert
Screenshot eines DHCP_ACK vom router / dhcp server:
PrettyOS [Version 0.0.2.88 - Rev: 927] -------------------------------------------------------------------------------- +--------------+----------------+ | 67 | 68 | (source port, destination port) +-------------------------------+ | 556 | 8DB2h | (length, checksum) +-------------------------------+ UDP BOOTP/DHCP Client op: 2 htype: 1 hlen: 6 hops: 0 xid: 0AFFE003h secs: 0 flags: 0000h cIP: 0.0.0.0 yIP: 0.0.0.0 sIP: 0.0.0.0 gIP: 0.0.0.0 MAC: 00h-30h-84h-2Bh-F2h-55h MAGIC OK Message Type: 5 Server IP: 192 168 1 1 Subnet Mask: 255 255 255 0 Routers: 192 168 1 1 DNS IP: 192 168 1 1 Domain name: localdomain NetBIOS over TCP/IP Name Server: 0 0 0 0 0 0 0 0 END OF OPTIONS
-
version = "0.0.2.89 - Rev: 928"
DHCP OFFER mit qemu (Windows, TAP) erreicht:
http://www.henkessoft.de/OS_Dev/Bilder/rev928_DHCP_OFFER.PNG 
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
Wichtiger Hinweis zum Testen:
Es gibt noch irgendwie Blockaden unter Windows bei TAP. Diese kann man umgehen, indem man andere virtuelle Netzwerkadapter (z.B. anderes TAP, VBox oder VMware Adapter) aktiviert oder deaktiviert. Hierdurch "lösen" sich die aufgestauten DHCP_OFFER-Pakete des qemuservers und sie "purzeln" mehrfach auf den Bildschirm.Man kann das OFFER nicht via wireshark (neueste Vers. 1.6.0) empfangen.
-
version = "0.0.2.90 - Rev: 929"
Startet nur mit DHCP_REQUEST hoch ohne DHCP_DISCOVER (ergibt DHCP_ACK bei qemu)
DHCP_REQUEST_and_DHCP_ACK: http://www.henkessoft.de/OS_Dev/Bilder/DHCP_REQUEST_and_DHCP_ACK.PNG
Die angezeigte lease time 0 1 81 128 (big endian) ist 86400 sec = 24 * 3600 sec = 1 Tag
Eingebaute Befehle:
strg+n = DHCP_DISCOVER
strg+i = DHCP_INFORM
strg+r = DHCP_REQUESTMit einer Änderung (weg von qemu) zum Test-PC und in network.c:
// Try to get an IP by DHCP
DHCP_Discover(adapter);
delay(1000000);
DHCP_Request(adapter);erhält man in wireshark: http://www.henkessoft.de/OS_Dev/Bilder/rev929a_DHCP_REQUEST_DHCP_NAK.PNG
PrettyOS zeigt das NAK:
PrettyOS [Version 0.0.2.90 - Rev: 929] -------------------------------------------------------------------------------- MAC Receiver: FFh FFh FFh FFh FFh FFh MAC Transmitter: 00h 22h CFh 36h 9Dh 1Ch Ethernet: type 2, Type: 08h 00h Ethernet 2. Ethernet type: IP. IP version: 4, IP Header Length: 20 byte UDP. UDP Header information: +--------------+----------------+ | 67 | 68 | (source port, destination port) +-------------------------------+ | 556 | 2ED4h | (length, checksum) +-------------------------------+ UDP BOOTP/DHCP Client op: 2 htype: 1 hlen: 6 hops: 0 xid: 0AFFE002h secs: 0 flags: 0000h cIP: 0.0.0.0 yIP: 0.0.0.0 sIP: 0.0.0.0 gIP: 0.0.0.0 MAC: 00h-30h-84h-2Bh-F2h-55h MAGIC OK Message Type: 6 Server IP: 192 168 1 1 END OF OPTIONSRequest mit XID: 0AFFE002 erhält ein DHCP_NAK:
1 = DHCP Discover message (DHCPDiscover).
2 = DHCP Offer message (DHCPOffer).
3 = DHCP Request message (DHCPRequest).
4 = DHCP Decline message (DHCPDecline).
5 = DHCP Acknowledgment message (DHCPAck).
6 = DHCP Negative Acknowledgment message (DHCPNak).
7 = DHCP Release message (DHCPRelease).
8 = DHCP Informational message (DHCPInform).
Dies ist in diesem Fall klar, da diese MAC bereits unter einer anderen IP im DHCP lease des Servers eingetragen ist.
Nun haben wir bereits mit Message Type 1, 2, 3, 5, 6, 8 experimentiert. Fehlt nur noch DHCPRelease und DHCPDecline.
Nun sollte ein Ablauf etwa wie hier aufgebaut werden: http://www.tcpipguide.com/free/diagrams/dhcpfsm.png
-
version = "0.0.2.91 - Rev: 930"
DHCP_State eingebaut:
network.c:
// Try to get an IP by DHCP adapter->DHCP_State = START; DHCP_Discover(adapter);dhcp.c:
DHCP_AnalyzeOptions(adapter, dhcp->options); if(adapter->DHCP_State == OFFER) { printf("\n >>> PrettyOS got a DHCP OFFER. <<<"); DHCP_Request(adapter); } if(adapter->DHCP_State == ACK) { printf("\n >>> PrettyOS got a DHCP ACK. <<<"); useDHCP_IP(adapter, dhcp); } if(adapter->DHCP_State == NAK) { printf("\n >>> DHCP was not successful (NAK). <<<"); }static void useDHCP_IP(network_adapter_t* adapter, dhcp_t* dhcp) { for(uint8_t i = 0; i < 4; i++) adapter->IP_address[i] = dhcp->yiaddr[i]; }Discover - Offer - Request - ACK (Erfolgreicher Hardwaretest mit Testrechner)
In der DHCP-Lease-Übersicht des Router/DHCP-Servers wurde der Testrechner mit seiner Wunsch-IP hinzugefügt. Wireshark auf einem Rechner im LAN zeigt leider nur die Anfragen von PrettyOS, aber nicht die Antworten des DHCP-Servers.
Damit ist DHCP in grundlegender Form nun in PrettyOS implementiert.
Mit Qemu/TAP ist das Aufzeigen der ganzen Kette unter Windows bisher nicht gelungen.
PS: In keyboard.c wurde DHCP_Discover(...) und DHCP_Request(...) entfernt. strg+n sendet wie zuvor ein UDP-Paket mit aufgesetztem Freitext für UDP-Experimente. strg+i sendet DHCP_Inform.
-
version = "0.0.2.92 - Rev: 931"
- DHCP Release ergänzt, z.Z. strg+f (gibt bei meinem Router allerdings noch nicht frei)
- Lease Time Daten auch in Std. angezeigt
