Hello, Guest the thread was viewed933 times and contains 7 replies

last post from Retro-Rentner at the

Brauche Hilfe bei Wireshark zwecks debugging einer X-Modem Übertragung

    Hallo zusammen ich hoffe jemand von euch kann mir weiterhelfen, bzw. mich in die richtige Richtung bringen.


    Folgendes Problem:

    Ich versuche vom Linux Rechner eine Datei mittels XMODEM aus dem lrzsz Paket an mein Ultimate64 zu senden auf dem ein Terminal Programm läuft, das X-ModemCRC, 1K, YModem und das alte X-Modem mit 1 Byte Checksum kann.

    Das Kommando zum senden ist wie folgt: lsz --tcp-client url:port -Xbv Dateiname

    Danach gibt es ein RING am U64 Terminal Programm, ich antworte mit "ATA", der Transfer läuft los, aber nach dem ersten tranferrierten Block, egal ob 128 Byte CRC oder 1024 Byte 1K, ist Ende und es gibt nur Fehlermeldungen.

    Mein erster Gedanke war, Mist Bug im Transferprotokoll auf dem U64. Also nochmal mit CGTerm gegengeprüft, 1x mit XmodemCRC und 1x mit Xmodem1K Übertragung -> läuft.

    Zweiter Gedanke, Mist lrzsz hat nen Bug, also am Linux Rechner mal deinstalliert, aus den Quellen neu installiert, nächster Versuch, geht wieder nicht.

    Dritter Gedanke, OK also debug-Versuch mit 2. C64 mit tcpser, Silversurfer Card im TurboChameleon, Striketerm 2014 als Terminal Programm und dieses Mal an den 2. C64 senden -> geht ! Also CRC geht, 1K geht, Zmodem geht, Ymodem geht.

    ???

    Nun versuche ich den Datenstrom vom Linux Rechner zum Ultimate64 zu analysieren, bin aber kein Profi was das angeht. Von Hörensagen kenne ich das Programm Wireshark als Netzwerkanalyse Tool (Sniffer).

    Ich bin aber irgendwie überfordert mit diesem Tool.


    Wie kann ich mit Wireshark oder alternativ auch mit einem anderen LINUX Tool den Datenstrom bei der Übertragung zum U64 mitschneiden, damit ich ansatzweise sehen kann warum lrzsz und das X-Modem Protokoll am U64 sich nicht so ganz verstehen.

    Meine Vermutung liegt an der Checksumme, aber raten bringt mich nicht weiter.


    Für Hife / Tipps wäre ich echt dankbar.

    Um den Datenstrom abzugreifen bin ich nun über das Programm tcpdump gegangen und habe den Datenstrom in eine Datei geschrieben.

    Dieses Dumpfile habe ich nun in Wireshark eingelesen und versuche nun aus den Daten schlau zu werden.

    Zum Vergleich der Daten wurde die selbe Datei zum 2. C64 mit tcpser / Striketerm / XModemCRC geschickt.

    Da die Datenübertragung bereits am ersten XModem Transferblock scheitert, konnte ich nun so beide Datenströme mit einander vergleichen.


    Hier der Datenstrom von lrzsz zum Ultimate64 128 Bytes + Xmodem Daten (STX ($01) für 128 Bytes CRC, Start Block $01, complement $FE, payload 128 Bytes, 2 Bytes Checksum $eb und $56.

    Der Interessante Teil startet hier ab Byte $36 mit der Bytefolge $01 $01 $FE (siehe oben):

    und als Vergleich der vom lrzsz zum Striketerm, aufgezeichnet mit tcpser, was am Ende noch mit einem ACK (also HEX 06) für eine erfolgreiche Übertragung des ersten Xmodem Datenblocks bestätigt wird:

    Code
    1. |0000|01 01 fe 01 08 0d 08 0a 00 9e 28 32 30 36 33 29|..........(2063)|
    2. |0010|00 00 00 ea 4c 35 09 00 00 40 08 b3 bd 00 00 00|....L5...@......|
    3. |0020|00 00 01 08 91 34 91 34 91 34 00 a0 00 a0 00 a0|.....4.4.4......|
    4. |0030|0a 00 00 00 00 08 00 00 00 08 00 00 00 00 24 00|..............$.|
    5. |0040|08 00 00 00 00 00 00 19 00 00 03 4c 00 00 00 00|...........L....|
    6. |0050|00 00 00 00 00 00 00 00 8c 00 00 08 0f 00 00 00|................|
    7. |0060|8c 80 c0 00 00 00 00 00 05 a3 e6 7a d0 02 e6 7b|...........z...{|
    8. |0070|ad 0c 08 c9 3a b0 0a c9 20 f0 ef 38 e9 30 38 46|....:... ..8.08F|
    9. |0080|e1 ff a2 eb 56 |....V |
    10. |0000|06 |. |

    Beim genauen hinsehen fällt auf, dass am Ende der Daten, kurz vor den beiden Checksum Bytes oben das Byte $FF 2x gesendet wurde, bei der (erfolgreichen) Übertragung aber nur 1x.

    Schaut man sich die Datei die übertragen werden soll im DirMaster an, dann ist dort auch nur 1x das Byte $FF (letzte Zeile $e1 $ff $a2...).



    Wenn ich den Datenstom vom PC zum U64 in Wireshark mir weiter ansehe, dann finde ich dort 1 bis 2 TCP Pakete weiter ein $15 was ein NAK ist, also die Meldung vom XModem Empfänger Block wurde nicht ackknowledged.

    Die Frage ist nun, wieso kommt da das $ff doppelt rein.

    Das ist auch kein Zufall. Kein einziger Übertragungsversuch hat bisher funktioniert. Das wurde auch mit einem anderen BBS getestet (danke an den SysOp dafür), auch da keine erfolgreiche Übertragung nach dem ersten XModem Block.

    Was könnte der Grund dafür sein ? Ich stehe gerade etwas auf'm Schlauch.

    Tja die Ursache hatte ich gestern bereits gefunden, nun kenne ich auch den Grund dafür. Was ich bisher nicht erwähnt hatte ist, dass ich vom PC zum U64 den Transfer über KERMIT mache, also xmodem als Externes Protokoll innerhalb eines CKERMIT Scripts. Ich dachte das wäre nicht so wichtig zu erwähnen. Falsch gedacht.

    Auf meinem LINUX Rechner ist eine Version von Kermit aus den Distro Paketen installiert, die einen Bug hat. Nämlich wenn xmodem als externes Protokoll für den Filetransfer genutzt wird und in der Datei ein 0xFF vorkommt. Siehe oben... aus einem 0xFF werden zwei, bumm Fehler und Ende.

    Leider gibt es von der Distro kein Update zu CKERMIT weswegen ich den Kram nun aus den Quellen übersetzen darf. Danke dafür.... OK ich könnte mal meinen PC ein aktuelles LINUX verpassen...


    Auch wenn ich hier mal wieder Alleinunterhalter für mich selbst bin, vielleicht kommt ja jemand in 10 Jahren um die Ecke und hat das gleiche Problem :)


    Quelle: https://github.com/KermitProject/ckermit

    Quote
    Code
    1. C-Kermit 9.0.305 Alpha.05 14 Dec 2021
    3. New support for 1,500,000bps serial port speed for platforms that offer
    4. it. Numerous adjustments to APIs, header files, and C compilers that
    5. changed out from under C-Kermit. A file-transfer bug fixed that resulted in
    6. the truncation of the filename when using ultra-short packets. Also a
    7. problem was fixed that occured when transferring any file that contained
    8. 0xff bytes through an external Xmodem protocol. Most notably we have
    9. successful builds on modern VMS operating system versions on various
    10. hardware platforms.

    Wireshark wäre nicht so das Problem, ich mache damit aber eher SIP, DNS & TCP.

    Von dem Rest Deiner Erklärungen habe ich leider kaum was verstanden, damit hatte ich bisher nichts zu tun.


    Ich nehme an, es gibt keinen Dissector für XMODEM und habe den Eindruck,

    dass Du genau der richtige Mensch bist, um einen solchen zu erstellen! ;)

    Ernsthaft: Würde das spätere Analysen nicht vereinfachen?

    Könntest Du sowas erstellen?

    Quote from Retro-Rentner

    Ich nehme an, es gibt keinen Dissector für XMODEM und habe den Eindruck,

    dass Du genau der richtige Mensch bist, um einen solchen zu erstellen! ;)

    Öhmm, ja Dissector ? Was muss ich da tun ? Wie geht das ?

    Letzten Endes habe ich Wireshark nur missbraucht um den mit tcpdump aufgezeichneten Datenstrom zu untersuchen.

    Zum Glück kenne ich mich inzwischen etwas mit den Protokollen XModem, Ymodem und Punter aus, wodurch ich relativ einfach den Beginn der Xmodem Übertragung finden konnte und dadurch dann durch einen Vergleich der Datenströme auf den Fehler gestoßen bin.

    Wenn ich mir das so anschaue, dann glaube ich ist es sinnvoller wenn ich euch die Infos liefere dir ihr braucht, damit ihr einen Dissector bauen könnt.

    Ich bin weder (ausgebilderter) Programmierer, noch habe ich tiefgreifende Kenntnisse über das was bei TCP/IP etc. "im Hintergrund" abläuft.

    Bis ich mich da reingefuchst habe bin ich wahrscheinlich in Rente :D