Sourcecode Fortschritt
-
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.
-
Version 0.0.2.63:
- Großer Netzwerkprotokollumbau
-
Dickes Lob an MrX!
-
Version 0.0.2.64:
- ELF-Loader setzt nun R/W-Privilegien bei der Speicherallokation
- Konsolen unterstützen nun SCROLL_BEGIN
- Anpassungen an arp wegen Netzwerkumbau in 0.0.2.63
- Kleinigkeiten
-
Version 0.0.2.65:
- Ausgaben des RTL8139-Handlers hinter Makro verborgen
- Analyse der Netzwerkpakete in Kernel-Idle-Schleife verlegt
- Erkennung des Adressaten einer Nachricht (MAC, IP) -> TODO: Warum funktioniert das bei ICMP nicht zuverlässig?
-
Version = "0.0.2.66 - Rev: 906";
Netzwerk Interface überarbeitet
udpSend eingebaut
-
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.