monitor 1.9.0 - aber richtig :)

[Buebchen]

@dove : gerne

@dove & buebchen : koennte man diese funktion nicht auch noch optional in den monitord miteinbauen?

Ist ja mein Reden :-)

Deswegen auch schon mal als Option vorgesehen.

[Buebchen]

So, ZVEI sollte jetzt keine so langen Pausen mehr machen. Meine Test sehen da auf jeden Fall besser aus (telnet auf FMS32 Port < 5 Sekunden, wenn kein Weckton folgt).

Ausserdem muss man sich für FMS32Pro nun mit "PASS:" anmelden.

Es wird gegen einen Login mit dem festen Namen "fms32pro" das Passwort (ohne spitze Klammern) geprüft.

[Medic]

Äh Buebchen...FMS32Pro hat keinerlei Passwort-Authentisierung mit drin. Der Crusader ja, aber nicht FMS32Pro

[Buebchen]

Oh.. Wer war das denn mit dem PASS:

Dann habe ichs gerade falschrum gemacht :-)

Sollte einfach nicht mehr so spät arbeiten ...

[nepomuck]

Dann habe ichs gerade falschrum gemacht :-)

Im Code scheint's zu stimmen. Habe die source von heute früh 8 Uhr bei JHR geladen und die funzt mit FMS32 ohne Probleme.

Andreas

[Buebchen]

Das kann ja auch am "whitelist" liegen. Das geht auf jeden Fall immer. Ansonsten war es trotzdem falsch. FMS32Pro kennt kein PW. Der Crusader schon.

Habe das jetzt auch korrigiert und im SVN aktualisiert.

[nepomuck]

So, ZVEI sollte jetzt keine so langen Pausen mehr machen.

Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.

Andreas

[jhr-online]

Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.

Wenn ich jetzt aufgepasst habe, war das nicht drin. Ich habe eben neu exportiert. Man kann jetzt die aktuelle Fassung (15:43 Uhr) als tar.bz runterladen.

[MacLeod]

hi!
ich muß da noch mal nachhaken....
wenn ich also "telnet >server-ip< 9333" auf der dos-box meines clienten eingebe soll eine welcome message erfolgen?
also bei mir ists so, dass die box dann gelöscht wird und oben links in der ecke blinkt der dos-promt. nix mit meldung oder so. danach erfolgt rein gar nichts...
mache ich da nun was falsch, oder habe ich irgendwas übersehen?

MacLeod

[Buebchen]

hi!
ich muß da noch mal nachhaken....
wenn ich also "telnet >server-ip< 9333" auf der dos-box meines clienten eingebe soll eine welcome message erfolgen?
also bei mir ists so, dass die box dann gelöscht wird und oben links in der ecke blinkt der dos-promt. nix mit meldung oder so. danach erfolgt rein gar nichts...
mache ich da nun was falsch, oder habe ich irgendwas übersehen?

MacLeod

Generell beantwortet der monitord alle Verbindungsanfragen mit der welcomeMessage. Egal ob man sich von dieser IP aus überhaupt einloggen kann. Ggf. ein Problem mit ner Firewall ?

[MacLeod]

Generell beantwortet der monitord alle Verbindungsanfragen mit der welcomeMessage. Egal ob man sich von dieser IP aus überhaupt einloggen kann. Ggf. ein Problem mit ner Firewall ?

hm...
firewall ist nicht aktiv.
was ich auch mache, er spricht nicht mit mir.
ubuntu 6.10 server lüppt auf der kiste.

edit
hab mal per vmware nen ubuntu 6.10 client gestartet und dadrauf monitord gestartet. dort bekomme ich :
110:monitord 2.0.0 READY

komisch...

[Buebchen]

Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.

Andreas

Werde mir das mit dem FMS32Pro Client mal prüfen. Am ZVEI Timing liegt es defintiv nicht.

[Edit:]
So, habe jetzt mal ein bisschen mit dem BOS-Tool gespielt. Auf den ersten Blick kapier ich nicht, warum das bei Dir so seltsam aussieht.

Ist das Verhalten denn NUR beim ZVEI so ?

[nepomuck]

Ist das Verhalten denn NUR beim ZVEI so ?

Ja, aber mit dem Build von gestern Nachmittag sieht das ganze Besser aus.

Dafür habe ich jetzt einen anderen ZVEI-Fehler gefunden:

...
300:1183802454:4d6f6e69746f7264:4b616e616c2032:210 24:0:756E6B6C617265204175736C2073756E67
300:1183802455:4d6f6e69746f7264:4b616e616c2032:210 24:0:756E6B6C617265204175736C2073756E67
300:1183802456:4d6f6e69746f7264:4b616e616c2032:10261023:0:756E6B6C617265204175736C2073756E67
300:1183802457:4d6f6e69746f7264:4b616e616c2032:210 23:1:4D656C6465726175736C2073756E67
...
300:1183813665:4d6f6e69746f7264:4b616e616c2032:210 31:0:756E6B6C617265204175736C2073756E67
300:1183813666:4d6f6e69746f7264:4b616e616c2032:210 31:0:756E6B6C617265204175736C2073756E67
300:1183813667:4d6f6e69746f7264:4b616e616c2032:10331056:0:756E6B6C617265204175736C2073756E67
300:1183813668:4d6f6e69746f7264:4b616e616c2032:210 56:0:756E6B6C617265204175736C2073756E6
....

8-stellige 5-Ton-Alarmierungen sind mir bislang undbekannt :-)

Der Fehler kommt auf Port 9333 und 9300 an.

viele Grüße,
Andreas

[Buebchen]

So, crusader muss sich jetzt auch anmelden. Da es dort keine Benutzernamen gibt habe ich das so integriert:

Es wird nach einem Benutzer "crusader" gesucht. Mit dessen Passwort kann sich der Crusader anmelden (in der Standard-Version ist das Passwort "pw"). So habe ich es auch in der monitord.xml hinterlegt.

@Nepomuck:
Auch nicht schlecht :-) Werde mir das mal anschauen. Sieht ein bisschen so aus, als ob da irgendein Zähler nicht zurück auf "Null" geht. Die letzten 4 Ziffern stimmen ja vermutlich dann wieder.

[MacLeod]

hm..
nun steigt er mir beim make aus:

-Wno-deprecated SocketServer.cpp -o SocketServer.o
SocketServer.cpp: In member function âvoid SocketThread::checkLoginCrusader(std::string)â:
SocketServer.cpp:709: error: no match for âoperator<<â in âstd::operator<< [with _Traits = std::char_traits]...
...
eam<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits]
make[1]: *** [SocketServer.o] Error 1
make[1]: Leaving directory `/home/macleod/2.1/monitord'
make: *** [all] Error 2