4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • M

    Version 0.0.2.34:

    - Treiber für AMD PCNet III hinzugefügt.

    0
  • M

    Version 0.0.2.35:

    - Netzwerkschnittstelle implementiert, PCnet- und 8139-Treiber angepasst
    - Treiberansatz für RTL8168 (vermutlich auch für RTL8169 verwendbar)

    0
  • E
    Mod

    version = "0.0.2.36 - Rev: 875"

    ethernet.c umgebaut auf Erkennung des Ethernet Type (bei Ethernet 2):
    0x0800 IP
    0x0806 ARP

    Leider 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.

    0
  • M

    Version 0.0.2.37:

    - IP wird nun zur Laufzeit abgefragt

    0
  • E
    Mod

    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.

    0
  • E
    Mod

    version = "0.0.2.39 - Rev: 878"

    Transmit klappt noch nicht bei rtl8139, Zwischenstand zur besseren Kontrolle des OWN Bits.

    0
  • E
    Mod

    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. 🙄

    0
  • E
    Mod

    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 Array

    MrX teilt im chat mit, das rev. 873 noch mit Transmit OK arbeitet, also hat sich bei der neu implementierten Network-Schnittstelle ein Bug eingeschlichen. 🙄

    0
  • M

    Version 0.0.2.42:

    - Senden funktioniert wieder
    - Sendefunktion für AMD PCnet hinzugefügt

    0
  • E
    Mod

    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))); // Test

    bei install:

    // device->TxBuffer = malloc(4096, 4, "RTL8139-TxBuf");
   device->TxBuffer = Tx_network_buffer; // global array instead of malloc

    Bei 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.

    0
  • M

    Version 0.0.2.43:

    - Zweiten Fehler beim Senden behoben (length & (0x3F0000 | 256<<11); war schuld)

    0
  • E
    Mod

    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)

    siehe: http://linux-ip.net/html/ether-arp.html

    0
  • M

    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
  • E
    Mod

    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
  • E
    Mod

    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).

    0
  • M

    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).

    0
  • M

    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

    0
  • E
    Mod

    Version 0.0.2.49 - rev. 889:

    Einträge in ARP Tabelle funktionieren nun bei ARP Req./Reply 🙂

    0
  • E
    Mod

    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.

    0
  • E
    Mod

    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

    0
Anmelden zum Antworten