monitor 1.9.0 - aber richtig :)

[Max K.]

Hi,

wollte eben mal monitor installieren!
Klappt auch, bis ich es starten will:

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.


In der /proc/asound/cards sagt er:

0 [A5451 ]: ALI5451 - ALI 5451
ALI 5451 at 0x8400, irq 5

Also Soundkarte ist vorhanden (und hat mit dem "alten" monitor ja auch funktioniert.)

Ne Idee?

[Buebchen]

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.
Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.

[nepomuck]

ich habe mal ein minimales Frontend gebaut

Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

[Buebchen]

Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

Das telnet machst Du vom gleichen Client aus ? Ansonsten wartet der monitord auf einen Login. Das kannst Du in der monitord.xml anpassen.

[mdi]

Moin,

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt (das kann das Ding nicht).

Also sehe ich als sinnvoll an, folgende ToDos zu erkennen:
a) Das Mini-Frontend muss Username und Passwort abfragen und sich entsprechend am monitord anmelden können.
b) Der monitord muss zum Login auffordern.

a) baue ich ein, wie wäre b)? Ich selber bin auch schon mehrmals an der Sache gescheitert, dass ich eine IP-Einstellung falsch gesetzt habe und mir der monitord nicht kund tut, dass ein Login notwendig wäre, von daher hielte ich den Hinweis durch den monitord für eine gute Sache, was meint Ihr dazu?

Martin

[nepomuck]

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt

Korrekt, das war mein Fehler

Der monitord muss zum Login auffordern.

Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

[Buebchen]

Korrekt, das war mein Fehler


Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

[nepomuck]

So, jetzt habe ich auch mal ein paar Zeilen Code geschrieben!
Der ist zwar nicht besonders toll, sollte uns aber beim Entwickeln etwas helfen.

ftp://andi.rw-labs.de/pub/bosix/poni.pl

"Poni", das Perl Monitor Frontend, stellt eine Verbindung zu einem Monitor-Server her und gibt die ankommenden Alarme in lesbarer Form auf der Kommandozeile aus -- mehr macht das Tool im Moment nicht.

Bei den Tests mit Poni (und dem BOS-Tool auf der Gegenseite) ist mir was aufgefallen:

Pocsac geht hier nur mit 512 Baud, 1200 Baud-Alarme werden nicht angezeigt.
Bei nummerischen Pocsac-Alarmen übermittelt Monitor die Ziffern im Klartext und nicht Hex-Kodiert. Der Client kann aber nicht wissen, ob was Alphanummerisches (Hex-codiert) oder was nummerisches (nicht HEX-codiert) ankommt.
Hier sollte Monitor auch die nummerische Ausgabe HEX-Kodieren, dann können die Clients das Text-Feld pauschal durch den HEX-Dekodierer jagen.
Oder wir müssen ein zusätzliches Feld "Alarmtype" beim Kommando 320 einführen, so dass der Client weiss was ihn erwartet.

viele Grüße,
Andreas

[nepomuck]

Schlechten Perl-Code schreiben macht Spass!

Ich habe gleich noch was nachgelegt: einen Mini-Client der Alarme im CSV-Format in separate Dateien schreibt und eine kompakte Darstellung auf dem Schirm ausgibt.

Das Perl-Programm ponilog.pl wertet die poni.cfg-Datei aus, um die Infos zum Server, Port etc. zu erhalten. Tool und Demo-Config liegen auf
ftp://andi.rw-labs.de/pub/bosix/

viele Grüße,
Andreas

[Max K.]

Hi,

zuerst mal danke für die Antwort!

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.

Ja, existiert.

Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

Kann eigentlich auch nicht sein, ein "cat /proc/asound/oss/sndstat" bringt:

Installed drivers: 
Type 10: ALSA emulation

Card config: 
ALI 5451 at 0x8400, irq 5

Audio devices:
0: ALI 5451 (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices: NOT ENABLED IN CONFIG

Timers:
7: system timer

Mixers:
0: Conexant Cx20468 rev 1,Conexant

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.

Selber Fehler leider. :(

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

[Buebchen]

Hi,

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

Müßte da jetzt nicht /dev/snd/pcmC0D0c stehen ? Muss mir mal den Linux Alsa Teil angucken ... Da scheint die Konfig nicht zu funktionieren.

[Max K.]

Hi,

klar, stehts auch. ;-) Habe nur die Fehlermeldung ausm 1. Beitrag kopiert, damit der Bezug schnell ersichtlich ist.

[Buebchen]

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

So. Versuche da jetzt mal beim Login weiter zu kommen. Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Ich könnte jetzt zwei Wege gehen:

a) Im configure.ac werden nur noch Zahlen mit einer Nachkommastelle als Programmversion genutzt
b) Wir lassen als Programmversion auch Text zu und können auch wie bisher svn / stable / dev / beta / sonstige Text als Version im configure.ac eintragen.

Spontan halte ich sowas für einen reinen Infotext. Oder wird der Client jemals mit dem "Versionswert" rechnen ? Interessant ist doch die Protokollversion für ihn. Ob das nun ein 2.1a oder 2.2svn monitord ist ist doch eher uninteressant und mehr etwas als Information für den Benutzer, oder ?

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ? Denn das ist im Moment noch nicht weiter definiert und ich möchte mich noch nicht festlegen, wie und wo die Modulnamen festgelegt sind.

Wenn nicht, ist die Antwort vorläufig:

111:5:"[leer]"

[Buebchen]

Kleiner Fehler in der Protokollversion 0.3 (Seite 3, Beispiel für Logins):

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

[nepomuck]

Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ?

So hatte ich das gedacht. 111:5 kann entfallen oder mehrfach vorkommen. Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas