Update 4.70

[jcmerg]

Ok, gesagt getan, hab einen in perl geschrieben (mit prowl, sms, mysql support und der möglichkeit RIC's zu filtern) der soweit auch klappt, sobald es eine Alpha gibt post ich das hier ;) Aber danke für die Antwort.

Btw. Ist euch evtl. klar warum der FMS Crusader mit einer Java Exception abschmiert wenn (trotz korrekt geschlossenem Socket) der Client beendet wird und dann wieder versucht zu verbinden ? Desweiteren gibt es dann auch keine Initialdaten mehr und es muss der ganze Crusader neu gestartet werden bevor wieder irgendwas über den tcp Socket kommt.

Es sieht für mich anhand der FIN_WAIT states im netstat so aus als ob er nicht bemerkt dass der Socket zu ist und dann beim senden der Message in eine Exception läuft:

SocketException gefunden
java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
        at java.util.Vector.elementAt(Unknown Source)
        at de.FMSCrusader.Server.Server.transferTelegram(Server.java:309)
        at de.FMSCrusader.Server.TelegramManager$NewTelegramRunnable.run(TelegramManager.java:161)
        at de.FMSCrusader.Server.TelegramManager.setNewTelegram(TelegramManager.java:64)
        at de.FMSCrusader.Server.Channel.setNewTelegram(Channel.java:2042)
        at de.FMSCrusader.Server.Channel.setPOCSAG(Channel.java:2339)
        at de.FMSCrusader.Server.Channel.poccreate(Channel.java:2180)
        at de.FMSCrusader.Server.Channel.pocsagbuild(Channel.java:2140)
        at de.FMSCrusader.Server.Channel.run(Channel.java:191)
        at de.FMSCrusader.Server.TelegramCapture$Capture.run(TelegramCapture.java:582)
        at java.lang.Thread.run(Unknown Source)

netstat:

tcp        0      0 127.0.0.1:53360         127.0.0.1:7778          FIN_WAIT2  
tcp6       9      0 127.0.0.1:7778          127.0.0.1:53360         CLOSE_WAIT

EDIT: Dann evtl. die Möglichkeit die Ausgaben des Crusaders, wenn man Ihn per -SNF startet in ein Logfile zu schreiben, bzw. Ihn zu "daemonizen". Aktuell lassen sich relativ schlecht init scripte für den Crusader (Smartserver und normal) schreiben.

EDIT2: Ah, und ist es korrekt so, nach dem connect "PASS:kennwort" für die Authentifizierung zu senden ? Ich hab das Verhalten des original Clients mit tcpdump gesnifft, war mir aber auch nicht zu 100% sicher. Aktuell klappt es so, aber nicht das dies die o.g. Probleme verursacht.