Hallo Moritz,

Zitat von H0lok im Beitrag #24

---

wenn man den Datenverkehr zwischen RR und CS mit Wireshark betrachtet sieht es für mich so aus als würde RR in den Datenverkehr zwischen CS und MS2 eigene Config Data Stream Pakete einstreuen.

---

Hallo zusammen,
anbei ein Bild und ein aufbereitetes Log. Im Bild ist rot die CS2 und blau RR!

CS2->RocRail	00 40 27 7f 08 6c 6f 6b 6e 61 6d 65 6e	-> Config Data Anfrage Teil 1 mit Inhalt "lokname"
CS2->RocRail	00 40 27 7f 08 30 20 32 00 00 00 00 00	-> Config Data Anfrage Teil 2 mit Inhalt "0 2"
CS2->RocRail	00 41 fb 35 08 30 20 32 00 00 00 00 00	-> Config Data Antwort mit Inhalt "0 2"
RocRail->CS2	00 42 27 7f 06 00 00 00 20 f7 ea 00 00	-> Config Data Stream Beginn (32 Byte) von RocRail (Das ist falsch! Am CAN darf es nur ein Hauptgerät geben und das ist aktuell die CS2!)
CS2->RocRail	00 42 27 7f 06 00 00 00 4e 5f 44 00 00	-> Config Data Stream Beginn (78 Byte) von der CS2
RocRail->CS2	00 42 27 7f 08 5b 6c 6f 6b 6f 6d 6f 74	-> Config Data Stream Paket mit Inhalt "[lokomot" (falsch)
CS2->RocRail	00 42 27 7f 08 5b 6c 6f 6b 6f 6d 6f 74	-> Config Data Stream Paket mit Inhalt "[lokomot"
CS2->RocRail	00 42 27 7f 08 69 76 65 5d 0a 6c 6f 6b	-> Config Data Stream Paket mit Inhalt "ive]\nlok"
CS2->RocRail	00 42 27 7f 08 0a 20 2e 6e 61 6d 65 3d	-> Config Data Stream Paket mit Inhalt "\n .name="
CS2->RocRail	00 42 27 7f 08 43 53 32 20 44 43 43 20  -> Config Data Stream Paket mit Inhalt "CS2 DCC "
RocRail->CS2	00 42 27 7f 08 69 76 65 5d 0a 6e 75 6d	-> Config Data Stream Paket mit Inhalt "ive]\nnum" (falsch)
CS2->RocRail	00 42 27 7f 08 33 0a 6c 6f 6b 0a 20 2e	-> Config Data Stream Paket mit Inhalt "3\nlok\n ."
CS2->RocRail	00 42 27 7f 08 6e 72 3d 31 0a 20 2e 6e	-> Config Data Stream Paket mit Inhalt "nr=1\n .n"
CS2->RocRail	00 42 27 7f 08 61 6d 65 3d 45 20 35 30	-> Config Data Stream Paket mit Inhalt "ame=E 50"
CS2->RocRail	00 42 27 7f 08 20 30 34 35 0a 6e 75 6d	-> Config Data Stream Paket mit Inhalt " 045\nnum"
RocRail->CS2	00 42 27 7f 08 6c 6f 6b 73 0a 20 2e 77	-> Config Data Stream Paket mit Inhalt "loks\n .w" (falsch)
CS2->RocRail	00 42 27 7f 08 6c 6f 6b 73 0a 20 2e 77	-> Config Data Stream Paket mit Inhalt "loks\n .w"
CS2->RocRail	00 42 27 7f 08 65 72 74 3d 36 0a 00 00	-> Config Data Stream Paket mit Inhalt "ert=6\n\0\0"
RocRail->CS2	00 42 27 7f 08 65 72 74 3d 30 0a 00 00	-> Config Data Stream Paket mit Inhalt "ert=0\n\0\0" (falsch)
 

Von RocRail verbreiteter Dadensatz (32 Byte)

[lokomotive]
numloks
 .wert=0
\0\0
 

Von CS2 verbreiteter Datensatz (78 Byte)

[lokomotive]
lok
 .name=CS2 DCC 3
lok
 .nr=1
 .name=E 50 045
numloks
 .wert=6
 
 

Im RocRail Forum bin ich nicht unterwegs, habe nur heute interessehalber RR heruntergeladen und mir das Verhalten in Kombination CS2+MS2 angeschaut!
Viele Grüße,
Moritz

Hallo Zusammen,

ich habe im RR-Forum eine Aussage von Rob gefunden:

https://forum.rocrail.net/viewtopic.php?p=188500#p188500

Um das hier zusätzlich für diejenigen zu zitieren, die dort nicht
angemeldet sind, habe ich bisher nicht um Erlaubnis gefragt.

Es geht darum, dass RR auch in der Lage ist, einer anfragenden
Slave-MS die Lokliste von RR zuzusenden.

Vielleicht meint RR, es ist (noch) keine CS da und antwortet
der anfragenden MS2 in derselben Art und Weise wie die CS
selber. Dann bekommt die anfragende MS2 die zusammengemixte
Antwort von zwei Sendern, der CS und von RR.
Vorstellen könnte ich mir das, wenn RR da keine
Plausbilitätsabsicherung drin hat.

Gruß est2fe

Hallo CRC-Geplagte,

ich schreibe euch hier die Lösung parallel so wie ich auch im RR-Forum geantwortet habe.

Denk ich an RocRail in der Nacht, bin ich um den Schlaf gebracht.

Das ist heute Nacht eindeutig der Fall.
Ich kann einfach nicht einschlafen, weil ich nach längerem darüber Nachdenken im Bett eindeutig die Lösung gefunden habe.

Sherlock Holms lässt grüßen!

So jetzt bin ich noch mal aufgestanden und habe den Rechner eingeschaltet, um diese Antwort hier zu schreiben.

Als ich diese Aussage hier gelesen habe, war mir gleich, dass sie an der Lösung beteiligt ist.

https://forum.rocrail.net/viewtopic.php?p=188500#p188500

Dann habe ich mir meine eigenen Logs noch mal vor Augen geführt und scharf darüber nachgedacht. An Schlaf war jetzt nicht mehr zu denken! Es könnte doch sein dass ...

Jetzt noch mal in mein Log geschaut und tata...

Ja und genau so ist es!
Mir viel es tatsächlich wie Schuppen von den Augen!

Die MS2 stellt im System die Anfrage, ob nicht jemand ihr die Lokliste bzw. die Loknamen von Anfang also mit Offset 0 zusenden kann und zwar 2 Loknamen (weil die MS2 nur 2 Loknamen gleichzeitig untereinander in deiner Liste darstellen kann).

Daraufhin fühlt sich die CS und gleichzeitig RR angesprochen und beide beginnen die 2 Loknamen jeweils ihrer Lokliste der MS2 als Datenstream zu zu senden. Und genau das kann ich in meinem
Logfile eindeutig sehen. Es werden jeweils die Start-Frames von beiden Loklisten gesendet mit DLC = 6 (natürlich unterschiedlich für jeden Sender) und dann kommen munter durcheinander gemischt die Streamdaten mit dem Inhalt von CS und RR. In meinem Fall sendet die CS ihre 2 Loknamen und RR seine 2 Loknamen, die in diesem Fall eindeutig und auch unterschiedlich sind.
Im GutFall, wenn nur die CS ihre Daten als Stream sendet, sollen 82 Bytes übertragen werden. Das entspricht 11 Frames, und beim letzten Frame werden 6 Bytes gepadded. So kann ich es auch im Logfile sehen.

RR sendet einen Stream mit 88Bytes. Das entspricht auch 11 CAN-Frames mit jeweils 8 Bytes, ohne padden zu müssen.
Und genau das passiert auch, wenn RR aktiv ist. Es werden dann in Summe 22 Stream-Frames gesendet, 11 Frames von der CS und 11 Frames von RR, beides bunt durcheinander gemischt.
Ich kann da die 4 unterschiedlichen Loknamen auch erkennen.

Klar, dass sich die MS2 da die Augen reibt und verschlafen nur noch CRC-Fehler melden kann! Die Daten sind Schrott und werden nicht übernommen, so zumindest in meinem Fall.

Also bitte in RR eine Abfrage einbauen, dass wenn sich eine Master-CS im System befindet, diese auf Lokanfragen einer MS2 antwortet und RR dann seine Antwort unterdrückt.

Qed.

Nächtlicher Gruß von Sherlock Holms

in der Hoffnung, dass ich jetzt endlich einschlafen kann ...

Hallo est2fe,

Respekt, ich bin beeindruckt.

Hallo,

so, ich habe es vor ca. 1/2h ausprobiert, die CRC-Fehler sind ab der V2533 weg.

Gruß est2fe

Hallo estefe,

Zitat von est2fe im Beitrag #31

---

so, ich habe es vor ca. 1/2h ausprobiert, die CRC-Fehler sind ab der V2533 weg.

---

Zitat von est2fe im Beitrag #23

---

Hallo Checksumen-Fehler-Geplagte,
wie ich oben schon geschrieben habe, ist da meines Erachtes RR vermutlich nicht schuld, weil es _nach_ dem Anmelden sich passiv verhält.

---

Zitat von est2fe im Beitrag #18

---

doch bei mir ist das mit RR auch so!
Es ist eindeutig reproduzierbar.

Aber, RR meldet sich an und ist dann komplett passiv! Was da schief läuft kann ich bisher nur sagen, dass da viele Frames von der CS2 zur MS2 unterschlagen werden.

---

Zitat von vikr im Beitrag #32

---

.Gratulation, damit hast Du Deine ersten Annahmen (mit ein wenig Hilfe von Rob) sehr konstruktiv widerlegt...

---

Hallo Andreas,

Zitat von Andreas85 im Beitrag #33

---

* kein Sturkopf ist
* lernfähig ist
* analytisch Denken kann
* Biss hat
* ziemlich hartnäckig sein kann

---

Hallo vik, Andreas, Moritz und andere,

Zitat von vikr im Beitrag #32

---

Gratulation, damit hast Du Deine ersten Annahmen (mit ein wenig Hilfe von Rob) sehr konstruktiv widerlegt...

---

Hoi, lieber est2fe

Für reine Anwender wie mich bist Du ein Segen. Ich hätte allein Rob den Beweis nicht erbringen können, war aber überzeugt, dass Rocrail irgendetwas zu tun damit hat, da der Fehler ausschliesslich in Zusammenhang mit Rocrail auftrat. Da zeigte sich Rob vorerst nicht kooperativ, weil er streng auf den Beweis wartet - welchen ich natürlich nicht erbringen kann.

Herzlichen Dank Dir!

lg
alex

Hoi Alex,

ich fragte mich am Anfang auch, wie man das beweisen kann,
genau so wie du auch.
Das ist, gerade in diesem Fall, wo der Hashwert immer dem des
Empfängers ist, in unserem Fall also der Hash der MS2, gar nicht so
einfach. Da sieht man nämlich nicht, wer die Info versendet hat.
Das hatte mich zu Anfang, bis ich es in der CAN-Spec nachgelesen
hatte, auch sehr irritiert. Aber nun hat es ja ein gutes Ende ge-
nommen. Ja, manchmal ist es nicht einfach, einen stichhaltigen
Beweis zu liefern. Zum Glück haben uns die Stummis dabei sehr
geholfen.

Gruß est2fe