Sourcecode Fortschritt
-
version = "0.0.2.36 - Rev: 875"
ethernet.c umgebaut auf Erkennung des Ethernet Type (bei Ethernet 2):
0x0800 IP
0x0806 ARPLeider klappt das momentan nicht mit ping oder hrping, landet beides als ARP in PrettyOS, komischerweise wird dies auch in Wireshark so angezeigt.
Bitte um Ratschläge, woran das liegen kann.
-
Version 0.0.2.37:
- IP wird nun zur Laufzeit abgefragt
-
version = "0.0.2.38 - Rev: 877"
Eingabe der IP mit gets in der letzten Version führte in qemu-EHCI und auf PC zu
#PF (page not present) at 08200837h - EIP: 0010EADBh
in der Zeile "Attached Disks" bei RAMDisk.
Daher wieder statische Zuordnung der IP in network.c. Eingabecode auskommentiert.
gets steht in util.c. Die Eingabe funktioniert auch. Fehlerursache unklar.
-
version = "0.0.2.39 - Rev: 878"
Transmit klappt noch nicht bei rtl8139, Zwischenstand zur besseren Kontrolle des OWN Bits.
-
version = "0.0.2.40 - Rev: 880"
OWN Bit bei Tx von RTL8139 wird gewaltsam auf 1 gesetzt, denn nur 1->0 startet den PCI-Prozess zum Senden. Es funktioniert aber noch nicht. Fehlerursache unklar.
Bitte um Mithilfe, damit das Senden bald klappt.
-
version = "0.0.2.41 - Rev: 881"
Netzwerk senden funktioniert noch nicht
Fehler unklar
malloc bei Tx-Puffer im Verdacht, früher hatten wir da ein statisches ArrayMrX teilt im chat mit, das rev. 873 noch mit Transmit OK arbeitet, also hat sich bei der neu implementierten Network-Schnittstelle ein Bug eingeschlichen.
-
Version 0.0.2.42:
- Senden funktioniert wieder
- Sendefunktion für AMD PCnet hinzugefügt
-
Ist leider nicht funktionsfähig.
Kleine Verbesserung bei qemu mit statischem Array. Dann sowohl bei ARP Req. als auch bei Ping Req. ein Tx OK, kommt aber nix an, auch nicht in wireshark.
rtl8139.c:
global:// Transmit uint8_t Tx_network_buffer[4096] __attribute__ ((aligned (4))); // Testbei install:
// device->TxBuffer = malloc(4096, 4, "RTL8139-TxBuf"); device->TxBuffer = Tx_network_buffer; // global array instead of mallocBei real PC leider kein Tx OK.
adapter-> kann durch device->device-> ersetzt werden.
Wir werden hier nochmal von der stabilen und funktionierenden Revision 873 ausgehen und in kleinen Schritten vorwärts gehen mit Tests auf einem echten PC mit RTL8139 im LAN mit Router. Das Problem entsteht beim Einbau der abstrakten Schnittstelle.
-
Version 0.0.2.43:
- Zweiten Fehler beim Senden behoben (length & (0x3F0000 | 256<<11); war schuld)
-
Hardware-Tests mit RTL 8139 Karte positiv. Sowohl ARP reply als auch ICMP reply bei zwei unabhängigen Testern.
hrping -S -t IP (geht bis -s 20, bei -s 10 bricht die Hardware zusammen)
-
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