Zitat von bambam
Beitrag anzeigen
was da passiert, ist kein Fehler - zumindest nicht von uns:-) Das hat was mit der ETS-Kommunikation zu tun und ist ein sehr kompliziertes Thema.
Bei den Telegrammlängen, die zur Verfügung stehen (theoretisch 254 Byte, wir nutzen nur 240) bekomme ich ein Suchergebnis von 7 Fingern hin. Wenn mehr Finger auf dem Gerät gespeichert sind, werden die ersten 7 gefundenen Finger dargestellt und es kommt ein Hinweis, dass mehr da sind und man die Filterkriterien weiter einengen muss.
Was bei Dir passiert, ist leider eine Lücke in der ETS (ich will nicht Bug sagen), die wir so nicht erwartet hatten. Ich muss weiter ausholen:
Die Telegrammlängen sind nicht konstant. Jedes IP-Interface, jeder Router, jeder LK - die können alle unterschiedliche Telegrammlängen. Manche werben dafür, dass sie jetzt Secure-fähig sind, manche sprechen von Long Frames, aber alle machen "irgendwas" <=254. Der Begriff ist APDU.
Wenn die ETS ein Gerät programmieren will, dann geht das grob gesagt folgendermaßen (Gerät hat die PA 2.3.4, ETS hat den Tunnel 1.1.250 von der Schnittstelle 1.1.5):
- ETS Fragt die Schnittstelle 1.1.5 (die stellt den Tunnel 1.1.250 bereit) nach der APDU, bekommt z.B. 220 zurück, das ist die bisher ermittelte APDU
- Um zu 2.3.4 zu kommen, muss sie jetzt den LK 1.1.0 nach der APDU fragen => 254, neue APDU ist MIN(254, 220) = 220
- Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der Router 1.0.0, dessen APDU ist 160, neue APDU ist MIN(160, 220) = 160
- Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der Router 2.0.0, dessen APDU ist 160, neue APDU ist MIN(160, 160) = 160
- Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der LK 2.3.0, dessen APDU ist 213, neue APDU ist MIN(213, 160) = 160
- Jetzt wird noch das Gerät 2.3.4 nach seiner APDU gefragt, ist 63, die sich ergebende APDU ist dann MIN(63, 160) = 63.
Warum erzähle ich das alles? Weil wir im Log der ETS gesehen haben, dass sie genau diese Ermittlung auch für die Kommunikation bei JavaScript macht und wir davon ausgingen, dass damit auch die Paketierung vorgenommen wird --> das ist aber leider nicht der Fall. Und noch schlimmer: Wir bekommen in JavaScript keine Information darüber, welche APDU zur Verfügung steht. Das selber zu ermitteln geht von JS aus nicht bzw. nur als große Krücke. Und natürlich findet man so was erst raus, nachdem es fertig implementiert und rausgerollt ist, denn wir haben alle Geräte mit großer APDU > 240 Byte.
Alle Schritte oben selber zu machen ist ein irrer Aufwand - trotzdem sprechen wir darüber, ob und wie wir das hinbekommen können. Das blöde ist, dass man noch nicht mal eine Fehlermeldung im JavaScript bekommt, wenn die APDU nicht stimmt, die ETS bricht einfach ab (wie bei Dir).
Was bleibt Dir übrig? Du musst - wenn so ein Fehler kommt - die Suchanfrage stärker einschränken, dass max. 6 Einträge zurückkommen. Ich bekomme einfach keine (programmatische) Kontrolle mehr, wenn die APDU überschritten wird, ich kann hier nichts machen.
Die einzige andere Möglichkeit, die ich sehe, ist die Suchfunktion wieder auszubauen. Aber da ich die selber sehr gerne nutze, will ich das nicht. Und wenn wir es wirklich schaffen, die Paketierung selber zu machen, werden wir natürlich umstellen.
Gruß, Waldemar


Einen Kommentar schreiben: