Prob bei FHZ 1300 WLAN Kommunikation und Dektop-Firewalls

Bugreports und Updatewünsche an die Firma contronics
Keine allgemeinen Fragen!

Moderator: Co-Administratoren

Antworten
gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Prob bei FHZ 1300 WLAN Kommunikation und Dektop-Firewalls

Beitrag von gwanjek » 20.12.2006, 14:49

Hallo,
ich besitze eine 1300 WLAN und habe dieses Teil erfolgreich mit der Studio-SW im neuesten Patchlevel im Einsatz. Näheres dazu bei Bedarf hier.

Probleme bereitet allerdings, dass das WLAN-Modul offenbar zur Kommunikation mit der Software permanent die Kommunikation initiieren muß. Zumindest sobald die Studio-SW nicht gestartet ist (und ich benutze meinen PC nunmal auch für anderes und werde das auch weiterhin tun :-) ), schlägt meine Firewall (McAfee Desktop FW) zu und erkennt -aus ihrer Sicht völlig korrekt- einen SYN-Flood-Angriff und sperrt die Kommunikation mit der IP-Adresse des WLAN-Moduls. Das ist natürlich unbefriedigend, da ich meinen PC nicht global ungeschützt gegen diese Art von Angriffen belassen will.

Die Ursache ist eindeutig und durch Positiv-FW-Logs reproduzierbar nachweisbar.

Ich sehe dass auch nicht als Problem der FW, erwarte hingegen künftig weitere daraus resultierende Probleme, u.a. durch Einführung der MS-Produkte Defender, Forefront usw. bzw. denke, daß bestimmte FW-Produkte "im Stillen" diese Kommunikation blocken werden und nichtmal wie bei meiner die Möglichkeit geben, das SYN-Flood-Szenario dediziert zu deaktivieren.

Andererseits sehe ich in der Konfiguration des WLAN-Moduls, daß es aus Sicht des Moduls offenbar neben dem Aktiven auch einen Passiv-Modus der IP-Kommunikation gibt, die sogar parallel aktivierbar sind. ("Verbindungen" "Modul soll Verbindung automatisch starten:"=aktiv-Modus, "Eingehende Verbindung automatisch annehmen:"=passiv-Modus?)

M.E. kann eine Lösung -auch ohne Änderung der WLAN-Komponenten, dortiger Firmware o.ä.- nur darin bestehen, daß die laufende(!) SW ihrerseits die Kommunikation initiiert, und sei es notfalls im Polling.

Fragen:
Wieso bekomme ich in diesen Passiv-Modus keine Kommunikation mit der Studio-SW? Ist das generell nicht möglich oder liegt nur ein -egal welcher- Konfigurationsfehler bei mir vor? Meine Zielstellung: Deaktivieren der Checkbox in der WLAN-Webkonfig-Seite unter "Verbindungen" vor der entsprechenden Option, nur noch die darunterliegende passiv-Einstellung der Konfiguration aktiv. --> keine Paketflut mehr an den PC, sobald Studio-SW nicht aktiv ist.

Oder interpretiere ich die Optionen in der WLAN-Konfigurationsseite falsch?

Wenn die Ursache einzig auf Seiten der Studio-SW liegen sollte, die das nicht unterstützt: Dringender Update-Weihnachtswunsch :-) ...ok, dürfte wohl eher mindestens Ostern werden...

Falls der jetzige Zustand aber aus lizenzrechtlichen Gründen so gewollt sein sollte, bitte auch das dann ehrlich so sagen. Dann weiss man zumindest bescheid. Zumindest längerfristig muß es m.E. hier aber dann trotzdem eine Änderung geben, um nicht durch angreifertypisches Verhalten Kommunikationsprobleme beim Anwender zu generieren.

Mir ist natürlich völlig klar, daß es durch eine entsprechende Änderung dann auch möglich ist, gleichzeitig von mehreren Softwareinstallationen auf mehreren PCs auf ein WLAN-Modul zuzugreifen. Allerdings sehe ich das nicht als Nachteil oder echten Hinderungsgrund, denn naturgemäß enthält jedes Kommunikationsprotokoll die Adressen beider Partner.

Notfalls, z.B. für zeitverzögerte Antwortreaktionen in Form neuer Kommunikations-Bursts (also: irgendwann, evtl. Minuten später komemn Antworten auf vorher angefragtes), können diese doch trotzdem an alle beteiligten laufenden SW-Installationen weitergeleitet werden, denn die Software "weiß ja, ob sie das angefragt hat" und ob sie dann auf eingehende Pakete reagiert. Allerdings fällt mir im Moment keine praktische Anwendung im Zusammenhang mit der SW ein, die wirklich darauf angewiesen sein dürfte, oder?

Wenn das dann funktionieren würde, könnte man damit sogar einige weitere bisherige Nachteile ausschalten:

1. Es ist einfach nur lästig, so man "als Admin" mehrere Standorte hat, ständig in die WLAN-Modul-Konfiguration gehen zu müssen, um die Kommunikation zwischen den jeweiligen Computern durch Änderung der Partner-IP-Adresse umzuschalten. Das wiederum per Klick z.B. durch ein kleines Perlscript auf der jeweiligen Maschine "in Fernbedienung der WLAN-Konfig-Webseite" zu tun ist irgendwie ...hmmm... gelinde gesagt "extrem indirekt" um nicht zu sagen: ganz schön krank, aber z.B. über solche Wege trotzdem sowieso jetzt schon möglich.

2. Ich kann mich an Anfragen erinnern, wo gefragt wurde, wie ein möglichst originales Abbild des endlich optimal konfigurierten Studio-Projektes auf den Webserver zu übertragen ginge. Natürlich ist der Hintergrund, es von mehreren Standorten aus betreiben zu können. Nun, das originalste Abbild dürfte sie Software und die Projektdatei selbst sein, oder?

Wie ist dazu die Meinung des Herstellers / anderer Betreiber? Ok, kann mich irren. Aber das ist nur mal so eine Idee von mir, möglichst gleich mehrere Übel an der Wurzel zu erschlagen... :-)

contronics-RK
Beiträge: 954
Registriert: 18.07.2006, 15:58

Beitrag von contronics-RK » 21.12.2006, 16:07

danke für den ausführlichen Problems- und Konfigurationsbericht.
Das WLAN-Modul kommt von der Firma avisaro, wir werden aufgrund der Hinweise zusammen mit avisaro überlegen wie die Konfiguration verbessert und sicherer gemacht werden kann.
Leider gibt es bei der Browser-Konfiguration unnötige Optionen, die gar nicht unterstützt werden. Das soll in künftigen Versionen geändert werden.
Der Verbindungsaufbau muss letztlich von der FHZ ausgehen, da die PC-Software den Server darstellt. Wir werden prüfen inwieweit das Problem über Konfigurationsoptionen gelöst werden kann.
Zum WEB-Server-Thema:
Es wird nächstes Jahr eine neue erweiterte Version geben. Die Visualsierung des Programms zu verwenden wird allerdings auch in dieser Version nicht möglich sein. Das ist nicht so einfach machbar, da reichen die Browsermöglichkeiten nicht.
Wahrscheinlich wird es aber möglich sein sich einen Screenshot der normalen Visualisierung im Browser anzeigen zu lassen.
Um an mehreren Stellen im Netzwerk auf die Originaloberfläche zuzugreifen ist es sinnvoller normale Remote-Control-Software zu verwenden (z.B. VNC).

Freundliche Grüsse
contronics - Ralph Krapoth

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 22.12.2006, 09:24

contronics-RK hat geschrieben:danke für den ausführlichen Problems- und Konfigurationsbericht.
Bitte. Gern doch. Es soll ja allen Seiten letztlich helfen.
contronics-RK hat geschrieben:Zum WEB-Server-Thema:
Es wird nächstes Jahr eine neue erweiterte Version geben. Die Visualsierung des Programms zu verwenden wird allerdings auch in dieser Version nicht möglich sein. Das ist nicht so einfach machbar, da reichen die Browsermöglichkeiten nicht.
Völlig klar und unbestritten. Ich hatte auch anderes im Sinn (Webserver ist daneben eine WEITERE Möglichkeit)

Wenn im WLAN-Modul nicht mehr die IP-Adresse des Kommunikationspartners fest angegeben werden muß, sondern diese wirklich auf Anforderungen des FHZ-Servers mit der Studio-SW lauscht, ist es doch möglich, es mit MEHREREN FHZ-Servern mit je einer installierten Studio-SW kommunizieren zu lassen!

Damit könnte dann einfach eine Projektdatei auf den anderen PC kopiert werden und ebenfalls von diesem aus laufen. Konvertierungs- und Darstellungsprobleme zwischen Studio-SW und HTML-Darstellung (die ich nur zu gut kenne) können dann gar nicht erst auftreten. Die notwendige Lösung wäre auch schon da: die Studio-SW selber... Mir schweben da so je Etage im Treppenaufgang an der Wand hängende (Touch-)Flatscreens mit integriertem Mini-PC vor...

Wenn man diesen Gedanken noch etwas weiter spinnt: Die Kommunikation zwischen Studio-SW und WLAN-Modul ist ja reinrassig IP. Also auch routbar, und sei es per VPN. Nicht nur die PCs mit den Screen per Etage, auch die Laptop-Installation der Studio-SW wäre DIREKT betreibbar, sogar aus dem viele km entfernten Büro... Und die Lösung ist eigentlich schon fertig da, nur die Kommunikationsrichtung zwischen Software und FHZ-WLAN-Modul wäre einmal zu ändern...

Ok, ist Weihnachts- und Wunschzettelzeit, und es sei mir vergeben, wenn zu nativ gedacht. Aber warum nicht? Klar kann das Probleme machen, z.B. Makros mehrfach ausführen, lokale Variableninhalte je PC usw. Trivialer Lösungsansatz: Master/Slave-Verhalten durch Abschaltbarkeit der Makro-Engine, also einer ist echter Server, die anderen nur Anzeigen. Gegenseitige Übernehmbarkeit der Master-Rolle, damit auch lizenzrechtlich sauber, da nur einmal parallel bedienbar...

Der Webserver-Ansatz sollte sicher ebenso dringend weiter ausgebaut werden, um dann da auch noch parallele Bedienbarkeit bzw. Integration anderer Komponenten (Cams usw.) mit den "Standardtechnologien" HTML, XML usw. zu ermöglichen. Aber erfahrungsgemäß dauert sowas, bis die Funktionalität (klar: anders gelöst, aber eben funktional identisch) ebenfalls stabil und vollständig bereitsteht. Aber es gibt ja schon die Studio-SW, die ja sicher auch weiter gepflegt werden wird und eigentlich bzgl. Kommunikation zur Hardware per WLAN-Modul ebenso IP-fähig ist.

Und denkt man dann NOCH einen (letzten) Schritt weiter, geht es DOCH, die Studio-SW direkt ins Web zu integrieren. Stichwort: in Seite eingebettetes IP-fähiges XML-Objekt... ok, da wären wir wohl bei 2009 oder so :-) ..oder auch nicht, denn um eine lokal installierte Applikation im Browser zu integrieren, muß ich nur den MIME-Typ da ergänzen, und das ginge sofort ohne irgendwelche dafür notwendigen Programmänderungen.

Gruß und allen ein frohes Fest / Danke für dieses Forum und das Feedback hier
Gerd
Zuletzt geändert von gwanjek am 22.12.2006, 10:02, insgesamt 1-mal geändert.

contronics-RK
Beiträge: 954
Registriert: 18.07.2006, 15:58

Beitrag von contronics-RK » 22.12.2006, 10:02

In einem System mit Zentrale (hier das PC-Programm) kann es grundsätzlich immer nur eine Zentrale geben, sonst geht es durcheinander. Es würden zwar alle Progarmme Sensormeldungen empfangen, hätten aber keine Infos über von anderen Programmen geschaltete Aktoren, virtuelle Objekte und Variablen. Also muss letztlich zur Visualsierung immer auf einen zentralen PC (egal ob mit WEB-Server oder Remote-Programm) zugegriffen werden.
Um Visualsierung und Steuerung von mehreren PCs vornehmen zu können, müssten diese alle auf eine Zentrale zugreifen, in der das Steuerungsprogramm läuft.
Warten wir mal ab was nächstes Jahr so alles an Neuheiten kommt....


Freundliche Grüsse
contronics - Ralph Krapoth

Kosch
Beiträge: 8
Registriert: 20.09.2007, 18:39

Beitrag von Kosch » 22.09.2007, 10:03

Alternativ einfach Java Webstart für die Konfiguration über Webseiten verwenden.
Bei meinem Arbeitgeber verwenden wir (nicht ich persönlich, ich entwickel Serverkomponenten) Webstart um Krankenhausabteilungen zu visualisieren.
(Dort kann man ersehen, welches Personal sich gerade wo befindet, wie die OPs belegt sind, Pläne konfigurieren etc. pp. Wir arbeiten mit RFID, daher ist eine Positionierung gut möglich.
Wir hatten dort genau das gleiche Problem wie ihr hier, wir haben eine Desktopanwendung, welche aber nicht ausreichte, da die Touchscreens, welche die Schwestern benutzen nur über Browser abreiten. Und
dort sieht man im Prinzip in dem Bereich auch nur ein Grundriss des jeweiligen Stockwerks/Abteilung.)

Durch Java Webstart lösten gleich mehrere Probleme:
- Durch Webstart war das Problem der Softwareaktualisierung auf den einzelnen Terminals vom Tisch. (Bei lokal installierter Software ist das
umständlich, man müsste dann Autoupdates o.ä. implementieren = mehr Aufwand = höheres Risiko)
- Einige Ärzte wollten auf ihren Mac nicht verzichten, damit wurden auch diese unterstützt.

Antworten

Zurück zu „homeputer Studio / Standard: Bugs & Updatewünsche“