Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
rec memExtWriteInd adr:EF CD AB 00
number: 32
data: A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1
Noch wird der Ack nicht erkannt das muss ich mir noch anschauen. Sobald es läuft mache ich einen PR.
Ich hab mir gestern bis spät in die Nacht an dem Problem gesessen.
Das erste Problem war das der Kaenx.Konnekt die L_Data.con mit APCI 0x1FB nicht parsen konnte. Da hab ich erst beim debuggen bemerkt dass hier eine relativ aufwändige Logik dahintersteckt. https://github.com/thewhobox/Kaenx.K...Parser.cs#L102
Hier geht der Parser in den case 7 fällt dann aber beim else raus - daher wird dann der default-zweig nicht mehr behandelt.
wenn das dann läuft kommt auch das Ack und der thesing/knx Stack antwortet (auch ohne VerifyMode,, wie man ganz klar im Code sieht) mit einem ExtMemoryWriteResponse (0x1fc).
Das "coole" an diesem Response ist im Gegensatz zum MemoryWriteResponse, der die Daten ja spiegelt, eine Überprüfung per CRC. Damit kann man arbeiten.
Schade dass man die AN177 nirgends findet die Infos hab ich nur aus dem thesing/knx stack und wireshark...
Was jetzt auf jeden Fall noch rein soll ist ein (optionales) Warten und auswerten des xMemoryRespone, egal ob Ext oder nicht. Das fehlt noch komplett wenn ich das richtig sehe, oder?
Die Logik kommt daher, dass die APCIs ja unterschiedliche Bit-Längen haben.
Bei GroupValueWrite sind es nur 4, bei nem DeviceDescriptorRead hingegen schon 10 und ein MemoryWrite hat nur 6.
Die restlichen Byte können dann schon wieder Nutzerdaten enthalten.
Ja das stimmt leider. Klaus meinte damals man kann sich auch den Download in ein Secure-Gerät anschauen, da diese auf jeden Fall den MemoryExtWrite unterstützen.
Acks sende ich aktuell nur, wenn ein Response angekommen ist. Hier könntest eigene Logik einbauen, wann er den Ack bestätigen soll.
Da fehlt dann ein TunnelAck.
Ist jetzt aber nur geraten.
Bisher wird die Response nur geprüft, wenn der VerifyMode an ist. (Wenn der Modus nicht unterstütz wird, wird nochmal ein MemoryRead geschicht und verglichen)
Der Code stammt allerdings nicht von mir und konnte ihn nicht testen.
Acks sende ich aktuell nur, wenn ein Response angekommen ist. Hier könntest eigene Logik einbauen, wann er den Ack bestätigen soll.
Da fehlt dann ein TunnelAck.
Ist jetzt aber nur geraten.
Ich glaube nicht dass es mit den Acks ein Problem gibt - aber vielleicht doch?
2021-09-24 09_55_12-Aufzeichnen von Ethernet.png
Kaenx sendet MemExtWriteRequest
Modul schickt ein Ack
Modul schickt ein MemExtWriteResponse
Modul schickt 3x ACK ??? Warum?
(müsste nicht hier Kaenx ein ACK schicken (kein Tunnelack, die kommen ja)
Bisher wird die Response nur geprüft, wenn der VerifyMode an ist. (Wenn der Modus nicht unterstütz wird, wird nochmal ein MemoryRead geschicht und verglichen)
Der Code stammt allerdings nicht von mir und konnte ihn nicht testen.
Ah, das muss ich mir ansehen. Ich hab bisher einfach das property manuell vor dem memwrite gesetzt.
zumindest abgefragt wird da aber standardmäßig nichts.
muss ich mal durchdebuggen.
ah - das feature ist ja brandneu, hab ich noch gar nicht in meinem lokalen repo...
Da solltest du recht haben.
Bisher musste ich auf jede Response ein Ack schicken, dass dann wiederrum das Interface mit einem Ack bestätigt.
So wie beim PropValueResp oben drüber.
Ich hab leider kein Gerät zum Testen da, sonst würde ich mir das auch mal anschauen.
In Zeile 619 wird es dann verglichen. Oder was meinst du?
ich meinte meine aktuelle Kaenx.Konnekt Applikation fragt das busdevice nicht nach property 0,14.
Das lag aber daran, dass ich beim repo noch nicht auf dem letzten STand war.
Mittlerweile konnte ich MemoryWrite mit VerfyMode testen und so wie es aussieht läuft es.
kleiner Bug ist drin, wenn man vor dem memorywrite keinen devicedescriptorread macht gibts eine exception weil features null ist...
jetzt muss ich das ganze noch für MemoryExtWrite adaptieren.. aber mit Blaupause ist das VIEL einfacher großartig, macht Spaß wieder mal etwas C# zu machen.
Stimmt. Den Anwendungsfall hatte ich noch nie, da ich über die Kaenx immer vorher ein DeviceDescriptorRead machen muss^^
Den Bug könnte man höchstens abfragen, aber faktisch muss vorher immer ein DeviceDescriptorRead erfolgen, da sonst Maskenversion und somit Features nicht bekannt sind.
Ing-Dom Hey, hast du schon mal den AuthorizeRequest ausprobiert?
Wollte grad selbst mal wieder testen und der AuthorizeReq wird mir in WireSahr immer als Fehlerhaft angezeigt.
Das ist quasi der BAU Schlüssel. Eine alte Funktion um das unberechtigte Parametrieren zu verhindern.
Manche Geräte setzen das Autorisieren vor dem Schreiben in den Speicher voraus, auch wenn der Standard Schlüssel verwendet wird.
Edit: Hab es gefixt bekommen.
Zuletzt geändert von thewhobox; 25.09.2021, 10:00.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
großartig, macht Spaß wieder mal etwas C# zu machen.
Kommentar