Selectric/Polarion Rapid Call nur eine RIC wird angezeigt

[Kater 9]

ist auch nicht notwendig und somit kein herausragendes Feature irgendeiner Verschlüsselung..... ist wieder eine Antwort die total irreführend ist....

und sowas wird dann den Kunden erzählt.... Boscrypt die eierlegende Wollmilchsau....

Offensichtlich gibt es Anwender die eine Separierung der Dienste auf Kryptoebene wollen und deshalb zwei Text RIC, vermutlich dann auch mit zwei Schlüsselsätzen, nutzen.
Ohne diese zwei Schlüsselsätze ist die Separierung, zumindest bei der SW -IDEA Implementierung, eh wertlos. Wenn ich diese Unterscheidung als Anwender will, ist es für mich dann eben doch ein herausragendes Feature der Verschlüsselung. Und das ist bei BOSKRYPT eben systemimanent.

[FunkerVogth]

seh ich nicht so.

[alex]

Mit den Drecks Polarion-Dingern habe ich eben zwei Probleme:
1. Ich kann nur eine Textric programmieren
2. Ich empfange nur eine alarmierte TON-RIC, auch wenn ich mehrere im Profil aktiv habe.

Das hat aber absolut nichts mit der Verschlüsselung zu tun, sondern an der schlechten Firmware..

Punkt 1 wird bei einer Doppelmitgliedschaft zwar doof, aber der Alarm kommt trotzdem an. Zumindest werden bei uns RD und FW in getrennten Alarmsätzen alarmiert. Punkt 2 ist aber wirklich beschissen und erfordert eben im Notfall eine ganz andere RIC-Struktur als man es bisher gemacht hat.
Wir haben bei jedem Alarm nur 1 RIC, die alarmiert wird. Somit weiß zumindest unsere Databox, welche RIC alarmiert wurde und kann das entsprechend ausgeben.
.. Ist natürlich gelogen, denn mittlerweile gibts auch eine Tagesalarm-RIC, die schon zu Problemen bei der Anzeige geführt hat... (Aber zu verkraften)
Doppelmitglieder, die bei FW sind, die Tagsüber gemeinsam ausrücken, haben aber ein gewaltiges Problem und ich finde es lächerlich..
Die ersten FW setzen mittlerweile eine Handy-("Zusatz")-alarmierung ein und berichten von neuen Höchstzahlen bei der Tagesalarmverfügbarkeit! Gab wohl einige, die den Melder nie mitgenommen haben und erst jetzt zeitnah von einem Einsatz erfahren. Kann man dazu stehen, wie man will, aber bisher erledigen die Handyapps den Job der Melder besser, zuverlässiger, billiger, mit weit mehr Features als der Polariondreck.. (Inklusive Rückmeldung, Alarmverfügbarkeit, Parallelalarm,....).

Achja: Stürze resultierten bereits mehrfach zu einer ausgebrochenen Gehäuseschraube oder dem kompletten Aufbrechen der Gehäuseschalen... Und ich rede hier nicht von spektakulären Stürzen wie 1-2 Stockwerte die Uni-Treppe runter, die der Hurricane überlebt hat, sondern aus Gürtelhöhe auf Fließen- oder Teppichboden, die selbst das Smartphone bereits überlebt hat!

@Kater9: Mit den Polarion kann ich nur eine einzige EA-Text programmieren. (EA ~= RapidCall, wie es bei den Polarions genannt wird)

[Kater 9]

.....

Das hat aber absolut nichts mit der Verschlüsselung zu tun, sondern an der schlechten Firmware..
.....
@Kater9: Mit den Polarion kann ich nur eine einzige EA-Text programmieren. (EA ~= RapidCall, wie es bei den Polarions genannt wird)

Die Aussage bzgl. Verschlüsselung ist anderst herum zu verstehen. Weiter vorne wurde behauptet, dass es Bereiche gibt die aufgrund der Schwächen der Swissphone IDEA Implementierung mit mehr als einem Text RIC im Netz arbeiten. Dann hatte ich nur ergänzt, dass diese "Klimmzüge" nicht nötig wären, wenn man BOSKRYPT einsetzen würde.

[elsterine]

Es wird nicht aufgrund von Schwächen der IDEA Implementierung mit mehreren Text-RIC gearbeitet, sondern einfach aus taktischen Gründen.

Und das finde ich recht gut.

[Kater 9]

Es wird nicht aufgrund von Schwächen der IDEA Implementierung mit mehreren Text-RIC gearbeitet, sondern einfach aus taktischen Gründen.

Und das finde ich recht gut.

Ok mag sein. Erläutere uns dann doch mal welche "Taktik" damit verfolgt werden soll?
Welche Vorteile haben mehrere Text RIC noch außer die oben bestrittene Implementierungsschwäche zur Erreichung der Dienstetrennung?

[alex]

Ok mag sein. Erläutere uns dann doch mal welche "Taktik" damit verfolgt werden soll?
Welche Vorteile haben mehrere Text RIC noch außer die oben bestrittene Implementierungsschwäche zur Erreichung der Dienstetrennung?

Nun, so können Feuerwehrmelder nicht so programmiert werden, dass sie z.B. reine Rettungsdiensteinsätze anzeigen/ausgeben. Damit wird zumindest die Gruppe der möglichen "Mitleser" weiter verkleinert..

[FunkerVogth]

Leute das sind 0,1 Prozent von wirklich wichtigen Anforderungen.... irre..... und wieder wird hier eine Verschlüsselungsschwäche als Grund für fie o. g. Programmierung hereingefaselt..... junge junge so ein Blödsinn......

Die eigentliche Schwäche die ich hier sehe, ist das ein gewisses Grüppchen im Existenzkampf genug Klinken geputzt hat um mit ner 256 Bit Aes Verschlüsselung zu retten was noch zu retten ist.

Wenn man sie dann fragt warum sie in den letzten Jahrzehnten kaum vertreten waren..... tja dann ist wahrscheinlich immer IDEA Schuld. Aber bei sich selber fangen die nicht an zu suchen.....

Alles Heuchelei und mittlerweile Desinformation..... und das auch in Foren wie hier und Feuerwehr. de

.... und das mit gewerblichem Hintergrund!!!!

Natürlich ist es sinnvoll eine einheitliche Verschlüsselung für gesamt BOS zu haben, aber die wahren Hintergründe liegen halt nicht nur in eben dieser Sinnhaftigkeit.

[EIB-Freak]

Beispiel aus unserem Kreis: Der Rett.-Dienst und die Feuerwehr erhalten komplett andere Textinhalte in der Meldung. Beim Rett.-Dienst z.B. vollständiger name, Anschrift und Diagnoseschlüssel. Bei der Feuerwehr sieht das dann ganz anders aus: "F BMA: Ort-Teilort, Straße, Hausnummer, bei FREITEXT". Freitext kann der Disponent frei eingeben (wie der Name schon sagt ;-) ), alles andere generiert das ELS (Dalles 2) aus den verfügbaren Daten (alle Objekte im Kreis sind im ELS hinterlegt und Georeferenziert, auch wegen RescueTrack im Rett.-Dienst).

Da auch die Feuerwehr auf IDEA-EA umstellt/umgestellt hat/umstellen wird, gibt es folglich 2 EA-IDEA-Text-RIC im Kreis. Eine eben für Weiss/Rote Autos, und eine für Rote autos (bzw. deren Besatzung).

EDIT: Was die Schlüsselverwaltung angeht - bisher hat die Leitstelle alle Melder für den RD programmiert und jede Feuerwehr ihre eigenen. Jetzt, mit IDEA-EA, erhalten die Feuerwehren die schluessel.IDEAC-Datei - dort sind alle Schlüssel unleserlich hinterlegt und können von der jeweiligen Feuerwehr auf die Melder geschrieben werden.
Schlüsselumschaltung per OAP erfolgt momentan noch nicht.

[FunkerVogth]

ist auch ok so..... hier ergibt sich aber ein anderes Szenario und das liegt in den unterschiedlichen Texten .... auch das ist nicht unüblich, gibts hier auch...... nur ist es hier nicht notwendig 2 unterschiedliche Schlüssel zu versorgen..... der Schwerpunkt liegt auf dem Informationsinhalt..... und nicht ob ich verhindern will das die FW RD-Texte lesen kann oder nicht. Wer mit sowas zu den Kunden geht und das als unheimlich wichtiges Feature nach oben auf die Liste setzt, dem kann ich auch nicht mehr helfen.

[sschaebe]

@FunkerVogth
Datenschutz wird immer wichtiger. Auch im Alarmierungsbereich. Stell Dir vor Du bist Landrat und weil alle den gleichen Schlüssel haben, können rein theoretisch alle Melder auch unberechtigt empfangene Meldungen anzeigen. Z.B. das Du als Landrat gerade einen Herzinfarkt hast. Willst Du dass?
Dienstetrennung mit jeweils eigenen Schlüsseln sehe ich vielleicht nicht ganz oben (da würde eher Alarmierungssicherheit, Geschwindigkeit, etc. stehen), aber dann kommt das ziemlich schnell Datenschutz, etc.

[elsterine]

Stell dir vor, du wärst Bürgermeister [emoji2]

[FunkerVogth]

ich bins doch..... wusstest du das nicht.....

natürlich kann man das so ausweiten und umsetzen...... man kann es auch übertreiben...... sorry.
Datenschutz...... das ist im Bos Bereich intern wie extern ein Widerspruch in sich.......und wenn wir schon soweit sind das RD und FW sich z. b. datenschutzmässig so zueinander verhalten müssen...... wie die gesamte BOS gegenüber den Lauschern..... dann prost.

Übrigens im Falle Deines Landrates oder in meinem Falle ( leider nur Bürgermeister) bekommt es halt irgendein RDler mit, der aber auch in der FW ist. Und der erzählt es dann weiter..... bzw. irgendeiner erzählt es eh immer weiter..... nie zu verhindern, und theoretisch kann ich mit jedem Melder die schönsten Dinge machen, wenn ich danach gehe sollten wir wieder auf Sirenenalarm und Telefonkette umstellen, daher:

Es wäre für mich kein Muss-Kriterium in der Ausschreibung...... aber wie gesagt, gibt ja hier Leute die reden den Kunden auch die unwichtigste Sache noch Schmackhaft.

[redfrog]

Und da genau passiert jetzt der falsche Weg.

Habt ihr in der Ausschreibung eine Art Express Alarm-Funktion (ich nenn das jetzt mal so) klar gefordert?

Ich bin nur Endanwender und wurde vor vollendete Tatsachen gestellt. Ich kann dir nicht sagen was in der Ausschreibung stand. Kater9 scheint es aber zu wissen...

[sschaebe]

natürlich kann man das so ausweiten und umsetzen...... man kann es auch übertreiben...... sorry.
Datenschutz...... das ist im Bos Bereich intern wie extern ein Widerspruch in sich.......und wenn wir schon soweit sind das RD und FW sich z. b. datenschutzmässig so zueinander verhalten müssen...... wie die gesamte BOS gegenüber den Lauschern..... dann prost.

Nur weil es andere Schwachstellen gibt, darfst Du nicht einfach den Datenschutz komplett vernachlässigen.

Übrigens im Falle Deines Landrates oder in meinem Falle ( leider nur Bürgermeister) bekommt es halt irgendein RDler mit, der aber auch in der FW ist. Und der erzählt es dann weiter..... bzw. irgendeiner erzählt es eh immer weiter..... nie zu verhindern, und theoretisch kann ich mit jedem Melder die schönsten Dinge machen, wenn ich danach gehe sollten wir wieder auf Sirenenalarm und Telefonkette umstellen, daher:

Hier würde sich der RDler gegen seine abgegebene Verschiegenheitserklärung im Rahmen der BOS-Sprechfunkausbildung verstoßen. Ich bin mir leider nicht sicher, ob das "nur" eine Ordnungswiedrigkeit oder sogar eine Straftat ist, werde jedoch mal in meiner Verschiegenheitserklärung nachschauen.