Sourcecode Fortschritt
-
Version 0.0.2.44:
- RTL8139-Treiber überspringt nun die ersten 4 Bytes eines empfangenen Paketes (weil sie RTL8139-spezifische Daten enthalten)
- Analyse der Pakete nach ethernet.c ausgelagert
-
0.0.2.45 - Rev: 885
// set transmit FIFO threshhold to 48*32 = 1536 bytes to avoid tx underrun (gefunden in open solaris) *((uint32_t*)(adapter->MMIO_base + RTL8139_TXSTATUS0 + 4 * rAdapter->TxBufferIndex)) = length | (48 << 16);
Das OWN bit 13 wird dabei wohl automatisch auf 0 gesetzt durch die Länge, könnte man evtl. noch separat ergänzen.
IP: 192.168.10.97
-
0.0.2.46 - Rev: 886
Zusätzlich zu IPv4 und ARP wurde noch IPv6 als ethernet type 0x86DD hinzugefügt bei der Analyse des Ethernet-Protokolls (ethernet.c).
-
Version 0.0.2.47:
- ARP-code nach arp.c/h ausgelagert
- Bugfix: Richtige Größe beim senden eines ARP-Paketes eingetragen (vorher: Größe des zuvor empfangenen Paketes).
- Bugfix: Senden von Paketen < 60 Bytes funktioniert nun wieder mit RTL8139 (Teile des Pufferinhalts wurden in dem Fall versehentlich gelöscht).
-
Version 0.0.2.48:
- strncmp im Kernel eingebaut
- Funktionen für Arp-Tabelle eingebaut. (Weitgehend ungetestet). Keyboard-Shortcut STRG+A, um den Inhalt der Tabelle anzuzeigen
- Liste aller Netzwerkkarten eingebaut
-
Version 0.0.2.49 - rev. 889:
Einträge in ARP Tabelle funktionieren nun bei ARP Req./Reply
-
Version 0.0.2.50 - rev. 890:
- IP beim network-adapter hinzugefügt, beim Ausdruck aber noch 0.0.0.0 (bei qemu: 111.112.112.121)
- IP/MAC wird manchmal doppelt eingetragen- Systemfehler beim Empfang: "Time lag" (mit der Zeit stecken immer mehr Pakete im Rohr fest. Müssen erst nach vorne gedrückt werden durch neue Pakete?! )
Bei qemu (server 10.0.2.2) mit TAP (10.0.2.16) kam ein ARP reply zum ARP request von TAP durch:
11 00:24:27.671763 Plus_12:12:12 Plus_12:12:11 ARP 10.0.2.15 is at 00:12:12:12:12:12
(Quelle: wireshark)
(10.0.2.15 / 00:12:12:12:12:12 ist PrettyOS)
In der ARP Tabelle von PrettyOS auf qemu findet sich nur der Eintrag von TAP.
-
Hinweis zum ARP Cache:
Der ARP-Cache enthält eine vierspaltige Tabelle, die im Allgemeinen aus <Protokolltyp, Protokolladresse des Senders, Hardware-Adresse des Senders, Eintragszeitpunkt> besteht. Das Zeitintervall, nachdem ein Eintrag aus dem ARP-Cache gelöscht wird, ist implementierungsabhängig. So verwerfen aktuelle Linux-Distributionen Einträge nach ca. 5 Minuten. Sobald ein Eintrag in der Tabelle genutzt wird, wird dessen Ablaufzeit verlängert.
Quelle: http://de.wikipedia.org/wiki/Address_Resolution_Protocol
-
Erhard Henkes schrieb:
Hinweis zum ARP Cache:
Der ARP-Cache enthält eine vierspaltige Tabelle, die im Allgemeinen aus <Protokolltyp, Protokolladresse des Senders, Hardware-Adresse des Senders, Eintragszeitpunkt> besteht. Das Zeitintervall, nachdem ein Eintrag aus dem ARP-Cache gelöscht wird, ist implementierungsabhängig. So verwerfen aktuelle Linux-Distributionen Einträge nach ca. 5 Minuten. Sobald ein Eintrag in der Tabelle genutzt wird, wird dessen Ablaufzeit verlängert.
Quelle: http://de.wikipedia.org/wiki/Address_Resolution_Protocol
Done.
Version 0.0.2.51:
- Bugfix: STRG+A zeigt nun richtige eigene IP-Adresse an
- Zeitstempel in ARP-Tabelle werden bei Zugriff aktualisiert
- Bootscreen optimiert -> Kein Flackern mehr.
-
0.0.2.52 - Rev: 892
arp.c überarbeitet:
- doppeltes arp_checkTable entfernt
- addTableEntry nur an einer Stelle für request und reply
-
0.0.2.53 - Rev: 893
Noch Fehler beim Eintrag in die ARP, aber keine doppelten Einträge mehr.
-
0.0.2.54 - Rev: 894
Nun korrekter Code bei arp.c für die ARP tables (dank Hinweis von cefour)
Hinweis von MrX im IRC:
<MrX>Der Zeitstempel wird noch aktualisiert, das stimmt.
<MrX>Wenn sich aber eine bereits bekannte IP mit anderer MAC meldet, wird die MAC in der Tabelle nicht mehr geändert.Der Code ist also noch nicht ok. Es kommt leider auch noch zu Doppeleinträgen mit der gleichen IP/MAC Kombination.
-
0.0.2.55 - Rev: 895
Gratuitous ARP eingebaut beim Installieren der Netzwerkadapter.
for (int i=0; i<10; i++) { arp_sendGratitiousRequest(adapter); // show PrettyOS' IP and MAC to the LAN sleepMilliSeconds(1000); }
Mein Entwicklungsrechner im LAN trägt diese IP/MAC aber nicht ein in seiner ARP Tabelle wegen möglichen ARP spoofings.
-
Version 0.0.2.56:
- PCNet-Treiber: Besser kommentiert, Verbesserte Ausgaben. Senden funktioniert nun unter Qemu (falsche Konstante war Schuld)
- Gratious-ARP auskommentiert (funktioniert i.d.R. nicht, weil viele Betriebssysteme solche ARPs ignorieren, um ARP-Spoofing zu vermeiden. Unter Qemu funktionierte ARP dadurch überhaupt nicht mehr)
-
version = "0.0.2.57 - Rev: 897"
tcp.h/tcp.c erkennung / zerlegung überarbeitet
Ports stimmen, Rest leider noch falsch
-
version = "0.0.2.58 - Rev: 898"
tcp.h und tcp.c weiter verbessert
6 Flags (nun uint8_t anstelle bool) werden noch nicht richtig angezeigt
(Tests mit telnet und wireshark)Wichtiger Hinweis:
Mit dem qemu-EHCI (Vers. 0.11.5) klappt der ARP reply nur sporadisch (man kann es mit arp -s 10.0.2.15 00-12-12-12-12-12 statisch eintragen).
Bei qemu 14.1 klappt der ARP reply auf Anhieb.
http://qemu-buch.de/d/QEMU_unter_Microsoft_Windows#QEMU_unter_.C3.A4lteren_Microsoft_Windows-Versionen
-
version = "0.0.2.59 - Rev: 899"
TCP Debug nun ok
http://tools.ietf.org/html/rfc793#page-15 (TCP header)
-
version = "0.0.2.60 - Rev: 900"
Schalter _NETWORK_DATA_ in os.h eingeführt, um die Ausgaben etwas übersichtlicher zu machen. Die einzelnen Bytes - und ihre Bedeutung - kann man besser in wireshark analysieren.
-
Version 0.0.2.61:
- Verbesserungen am RTL8168-Treiber
- Verbesserungen an UDP-Funktionsprototypen
- Kleinigkeiten
-
version = "0.0.2.62 - Rev: 902"
Sende-Funktion in UDP aktualisiert:
void UDPSend(struct network_adapter* adapter, void* data, uint32_t length);
Noch nicht getestet.