Sourcecode Fortschritt



  • version 0.0.1.157 - Rev: 734

    icmp.c/.h

    - ICMPAnswerPing(...), mit Statischen werten hinzugefügt und experimentiert, bisher ohne Erfolg.



  • version 0.0.1.157 - Rev: 735

    icmp.c/.h

    - ICMPAnswerPing(...), erweitert und getestet. Noch kein Erfolg.



  • Version 0.0.1.158:

    - Umstellung der IRQ/ISR-Nummern auf enum begonnen
    - Scheduler unterstützt nun waitForIRQ - Wait-Funktionen damit vorerst komplett
    - getch auf waitForIRQ umgestellt - Genauso Ressourcensparend, aber performanter (kein hlt das andere tasks ausbremst)
    - switch_context führt abhängig von der Anzahl der laufenden tasks hlt aus


  • Mod

    Version 0.0.1.158 ist fehlerhaft (memory leak), und icmp.c/.h noch ziemlich unbrauchbar. 😮

    http://codepad.org/0YDxC2n1 <-- Workaround von MrX



  • version 0.0.1.159 - Rev: 737

    keyboard.c/.h
    - Workaround von MrX implementiert (getch)

    ipTcpStack.c/.h
    - switch konstrukt für die Protokolle in IPheader hinzugefügt


  • Mod

    1. arp reply ohne adresse! (das war schon besser)
    2. icmp reply funktioniert nicht! (kommt in wireshark nicht an)


  • version 0.0.1.160 – Revision 738

    IP/ICMP

    - Header korrigiert
    - Checksummenfunktion korrigiert
    - ICMP-Ping-Reply-Funktion korrigiert
    => Wireshark zeigt korrekte Antwort an

    PS: Dass ping bei mir keine Antwort anzeigt, mag an meiner Netzwerkkonfiguration liegen (da bei Wireshark von MAC über IP bis hin zu Checksumme alles zu stimmen scheint).



  • Version 0.0.1.161 – Revision 739

    ICMP: Datenteil

    - ICMP-Pings enthalten einen Datenteil, den man zurückschicken sollte – was ab jetzt auch getan wird.


  • Mod

    http://img192.imageshack.us/img192/3690/pinght.png <--- erfolgsmeldung von Ideenlos. Gratulation! 👍


  • Mod

    "Ideenlos" war schneller als ich, der es nur mit hrPing und 56 byte Daten schaffte:

    hrping 192.168.10.97 -S -t -l 56
    

    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_161_PingReply.PNG

    Statistics for 192.168.10.97:
    Packets: sent=227, rcvd=153, error=0, lost=74 (32% loss) in 106.126180 sec
    RTTs of replies in ms: min/avg/max/dev: 67.929 / 12788.809 / 33029.268 / 8959.212

    <Tobiking>Das hrPing schickt Latein?

    😃


  • Mod

    Version 0.0.1.162 – Rev: 740

    etwas aufgeräumt im Netzwerk-Bereich

    Leider ist RXBUFTAIL ab und zu verschoben!



  • Version 0.0.1.163 – Revision 741

    rtl8139

    - wenn man die Empfangsdaten aus dem entsprechenden Puffer
    herauskopiert, werden anscheinend mehr Pakete korrekt empfangen.


  • Mod

    Das war entscheidend! (findet sich auch im programming guide)

    Nun läuft request und reply in wireshark sauber abwechselnd:
    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_163_PingRequestReply.PNG

    Beim PING-Absender-Programm kommt trotz dieses Ablaufes dennoch nur noch "timeout" an.


  • Mod



  • version 0.0.1.163 - Rev: 741

    TCP header hinzugefügt tcp.c/h

    icmpDebug, tcpDebug für eine besser veranschaulischung der jeweiligen Packete.



  • Version 0.0.1.165 – Revision 743

    IP/ICMP-Checksumme

    - Man sollte es mit dem Aufräumen nicht übertreiben (rev 740): das Checksummenfeld muss tatsächlich vor der Berechnung der Checksumme auf 0 gesetzt werden.

    PS: Das hier ist wirklich die 0.0.1.165 und die Rev 743, ich hatte beim letzten Mal nur vergessen, die Version in ckernel.c zu aktualisieren, deshalb hat internet eigentlich die 0.0.1.164 bzw. 742 committet.


  • Mod

    C:\hrPING>hrping 192.168.10.97 -n20 -l32 -S -s100
    This is hrPING v2.44 by cFos Software GmbH -- http://www.cfos.de
    
    Using source IP address 192.168.10.99 to send packets
    Pinging 192.168.10.97
    with 32 bytes data (60 bytes IP):
    
    Reply from 192.168.10.97: seq=0000 time=14.150ms TTL=128 ID=0000 - sent=1
    Reply from 192.168.10.97: seq=0001 time=5.801ms TTL=128 ID=0000 - sent=2
    Reply from 192.168.10.97: seq=0002 time=5.790ms TTL=128 ID=0000 - sent=3
    Reply from 192.168.10.97: seq=0003 time=5.813ms TTL=128 ID=0000 - sent=4
    Reply from 192.168.10.97: seq=0004 time=5.799ms TTL=128 ID=0000 - sent=5
    Reply from 192.168.10.97: seq=0005 time=5.808ms TTL=128 ID=0000 - sent=6
    Reply from 192.168.10.97: seq=0006 time=5.804ms TTL=128 ID=0000 - sent=7
    Reply from 192.168.10.97: seq=0007 time=5.828ms TTL=128 ID=0000 - sent=8
    Reply from 192.168.10.97: seq=0008 time=5.834ms TTL=128 ID=0000 - sent=9
    Reply from 192.168.10.97: seq=0009 time=5.805ms TTL=128 ID=0000 - sent=10
    Reply from 192.168.10.97: seq=000a time=5.805ms TTL=128 ID=0000 - sent=11
    Reply from 192.168.10.97: seq=000b time=5.800ms TTL=128 ID=0000 - sent=12
    Reply from 192.168.10.97: seq=000c time=5.804ms TTL=128 ID=0000 - sent=13
    Reply from 192.168.10.97: seq=000d time=5.805ms TTL=128 ID=0000 - sent=14
    Reply from 192.168.10.97: seq=000e time=5.830ms TTL=128 ID=0000 - sent=15
    Reply from 192.168.10.97: seq=000f time=5.834ms TTL=128 ID=0000 - sent=16
    Reply from 192.168.10.97: seq=0010 time=9.280ms TTL=128 ID=0000 - sent=17
    Reply from 192.168.10.97: seq=0011 time=5.844ms TTL=128 ID=0000 - sent=18
    Reply from 192.168.10.97: seq=0012 time=5.816ms TTL=128 ID=0000 - sent=19
    Reply from 192.168.10.97: seq=0013 time=5.820ms TTL=128 ID=0000 - sent=20
    
    Statistics for 192.168.10.97:
        Packets: sent=20, rcvd=20, error=0, lost=0 (0% loss) in 1.905816 sec
        RTTs of replies in ms: min/avg/max/dev: 5.790 / 6.403 / 14.150 / 1.980
    

    0% loss 👍

    PrettyOS hat die IP 192.168.10.97


  • Mod

    Noch zur checksum:

    ICMP Header Checksum. 16 bits.
    Checksum that covers the ICMP message. This is the 16-bit one's complement
    of the one's complement sum of the ICMP message starting with the Type field.

    The checksum field should be cleared to zero before generating the checksum.



  • Version 0.0.1.166:

    - Floppytreiber nutzt nun hlt während er auf ein IRQ wartet. (waitForIRQ geht nicht, weil wir dort ein timeout haben)
    - getch nutzt wieder waitForIRQ, Fehler behoben, keine task-Mutation mehr, Speicherleck weg.
    - Neues Feature zur Memory-Leak-Erkennung. (Aktivierung in os.h, Funktioniert derzeit nicht stabil)
    - Projektdatei aktualisiert
    - Kleinigkeiten


  • Mod

    PrettyOS 0.0.1.166 - Rev: 744

    Testumgebung         SCREEN (phys)     vbe  RTL8139  EHCI      Probleme 
    -----------------------------------------------------------------------------
    qemu-ehci            F2000000h         ok   ja       4 ports   nein
    VBox 3.2.6           E0000000h         ok   nein     8 ports   nein
    VMWare Player 3.0.1  (mit vbe)                                 invalid opcode bei 1A70h
    VMWare Player 3.0.1  (ohne vbe)        -    nein     6 ports   keine
    bochs 2.4.2          E0000000h         ok   nein     nein      keine
    VPC 6.0.192.0        00000000h                                 #PF (err 0, addr 107BC4h) 
    VPC 6.0.192.0        (ohne vbe)        -    nein     nein      keine 
    PC 1,4 GHz GeForce4  F4000000h         ok   ja       nein      keine
    

Anmelden zum Antworten