Sourcecode Fortschritt
-
Version = "0.0.2.67 - Rev: 907";
(von cefour eingespielt)
PING PONG über router läuft nicht mehr.
23:39:08.264789 192.168.10.103 192.168.10.97 ICMP Echo (ping) request
23:39:08.273097 UnexTech_0f:0a:0c Broadcast ARP Gratuitous ARP for 192.168.10.97 (Request)"pingender Rechner schickt an den Router, und Router tauscht mac-addresse im Paket gegen seine eigene aus" (cefour)
Hat bisher nur geklappt, weil wir die MAC-Adresse geliefert haben.
-
version = "0.0.2.68 - Rev: 908"
- Formatierungen
- Ver./Rev. korrigiert
- IP 192.168.10.97 (für Hardware-Test)
- Frequenz auf 250 Hz eingestellt wie bei Linux 2.6.13
http://de.wikipedia.org/wiki/Linux_(Kernel)#Neuerungen_im_Kernel_2.6Routing-Tabelle fehlt noch
http://de.wikipedia.org/wiki/RoutingtabelleBeispiel: Aufruf mit netstat -r
Routingtabelle =========================================================================== Schnittstellenliste 0x1 ........................... MS TCP Loopback interface 0x2 ...00 13 d4 11 27 a5 ...... Intel(R) PRO/1000 PM Network Connection - Paketplaner-Miniport =========================================================================== =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl 0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.103 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.10.0 255.255.255.0 192.168.10.103 192.168.10.103 20 192.168.10.103 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.10.255 255.255.255.255 192.168.10.103 192.168.10.103 20 224.0.0.0 240.0.0.0 192.168.10.103 192.168.10.103 20 255.255.255.255 255.255.255.255 192.168.10.103 192.168.10.103 1 Standardgateway: 192.168.10.1 =========================================================================== Ständige Routen: Keine
Anzahl = Metrik
-
"0.0.2.69 - Rev: 909"
Arp Tabelle, finden eines Eintags war Fehlerhaft.
Wurde durch Integer vergleich anstatt string vergleich behoben
-
Version 0.0.2.70:
- strncmp durch memcmp ausgetauscht im Netzwerkcode
- Userlib: Weitere Funktionen implementiert
- Bugfix: strncmp repariert
-
version = "0.0.2.71 - Rev: ..." (nicht committed)
- UDPSend korrigiert (src- und destPort mit htons gedreht)
- Funktion ergänzt in network.c: network_adapter_t* network_getAdapter(uint8_t IP[4]);
- In keyboard.c die Erzeugung eines Netzwerkpakets per Tastendruck strg+n für Experimente ergänzt:if(retchar == 'n') // If you want to test something in networking { uint8_t sourceIP_address[4] ={192,168,10,97}; uint8_t destIP_address[4] ={192,168,10,103}; network_adapter_t* adapter = network_getAdapter(sourceIP_address); printf("network adapter: %X\n", adapter); // check uint16_t srcPort = 40; // unassigend uint16_t destPort = 40; if (adapter) { UDPSend(adapter, "PrettyOS says hello", strlen("PrettyOS says hello"), srcPort, adapter->IP_address, destPort, destIP_address); } return 0; }
Kontrolle mittels wireshark: http://www.henkessoft.de/OS_Dev/Bilder/rev911_UDPsend_TEST.PNG
-
version = "0.0.2.72 - Rev: 911" (ACHTUNG: in ckernel.c versehentlich 912)
- Weiterer Fehler in UDPSend behoben (Länge)
void UDPSend(network_adapter_t* adapter, void* data, uint32_t length, uint16_t srcPort, uint8_t srcIP[4], uint16_t destPort, uint8_t destIP[4]) { udpPacket_t* packet = (udpPacket_t*)((uintptr_t)data -sizeof(udpPacket_t)); packet->sourcePort = htons(srcPort); packet->destPort = htons(destPort); packet->length = htons(length + sizeof(udpPacket_t)); packet->checksum = packet->checksum = udpCalculateChecksum(packet, length + sizeof(udpPacket_t), srcIP, destIP); ipv4_send(adapter,packet,length + sizeof(udpPacket_t),destIP,17); }
Foto des Wireshark-Pakets: http://www.henkessoft.de/OS_Dev/Bilder/rev912_UDPsend_TEST.PNG
PS: Man muss zuvor PrettyOS pingen, damit die IP/MAC Kombination der destIP in der arp table unseres OS steht.
Nachdem UDPSend funktioniert, kann man sich an DHCPDiscover heran wagen.
An htons denken!
-
Version 0.0.2.73:
- UDPSend repariert. (Gefährliches Spiel mit Pointern entfernt)
- Ansatz für DHCP_Discover
- 255.255.255.255 statisch in ARP-Tabellen eingetragen
-
version = "0.0.2.74 - Rev: 913"
Meilenstein: Erfolgreicher DHCP Discover
Thanks to: MrX, cefourFoto (wireshark): http://www.henkessoft.de/OS_Dev/Bilder/DHCPDiscover.PNG
// 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; // DHCP message type packet.options[5] = 1; // Length packet.options[6] = 1; // data: DHCP Discover packet.options[7] = 255; // end
Options: code/tag, length, data
http://www.networksorcery.com/enp/protocol/bootp/options.htm
-
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 0
zu 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 97
Nächste Aufgabe: Funktion DHCP_Debug schreiben
Vorbild (?): http://www.koders.com/c/fid179E56E3C11D80DFE25DD6D819369416B3BF583D.aspx