Telnet und Verbose an, trotzdem keine Meldungen in der Konsole

[KvR]

Telnet habe ich über das Telefon eingeschaltet und Verbose steht auf "yes". Trotzdem werden in der Konsole keinerlei Meldungen ausgegeben. Woran liegt das?

 

[KvR]

Entweder wurde das Problem nicht verstanden oder ich bin der Einzige, bei dem es mit den Meldungen immer noch nicht funktioniert.

Bei den ältereren Firmware-Versionen liefen im Telnet-Fenster Logmeldungen wie diese durch:

# Aug 13 17:09:24 voipd[436]: incoming(5:appl=5 plci=0x1105 ncci=0x0 incoming): 10 0049711xxxx <- 0
Aug 13 17:09:24 voipd[436]: telapp_incoming - running (voip=0)
Aug 13 17:09:24 voipd[436]: 0: connected    vcc 1/32/PPPoE/32 stay online 1
 Aug 13 17:09:24 voipd[436]: 0: ip 217.9.27.154/217.9.24.1 mtu 1492 dns 217.9.16.25/217.9.16.24
Aug 13 17:09:24 voipd[436]: VoIP led value = 18
 Aug 13 17:09:24 voipd[436]: allowed bandwidth 80000 for sip:[email protected]
Aug 13 17:09:24 voipd[436]: [email protected]: bandwidth left 80000
 Aug 13 17:09:24 voipd[436]: >>>UDP Request: INVITE sip:[email protected]
Aug 13 17:09:24 voipd[436]: <<<UDP Status: 407 Proxy Authentication Required
 Aug 13 17:09:24 voipd[436]: >>>UDP Request: ACK sip:[email protected]
 Aug 13 17:09:24 voipd[436]: allowed bandwidth 80000 for sip:[email protected]
Aug 13 17:09:24 voipd[436]: [email protected]: bandwidth left 80000
 Aug 13 17:09:24 voipd[436]: >>>UDP Request: INVITE sip:[email protected]
Aug 13 17:09:24 voipd[436]: <<<UDP Status: 100 trying -- your call is important to us
Aug 13 17:09:25 voipd[436]: <<<UDP Status: 488 Not acceptable here
 Aug 13 17:09:25 voipd[436]: >>>UDP Request: ACK sip:[email protected]
Aug 13 17:09:25 voipd[436]: VoIP led value = 1
Aug 13 17:09:25 voipd[436]: ocfree: fail 0 normal 0 small 0 large 0
Aug 13 17:09:25 voipd[436]:         underrun 0 max_ackqueuelen 0
Aug 13 17:09:25 voipd[436]:         small packets merged 0, output 0 and consumed from CNG 0
Aug 13 17:09:25 voipd[436]: ocmode: normal 0 merged 0 delayed 0
Aug 13 17:09:25 voipd[436]: dropped 0 packets with 0 samples and one sample in 0 packets
Aug 13 17:09:25 voipd[436]: generated noise: oben 0/unten <=0
Aug 13 17:09:25 voipd[436]: CONNECT_RESP with sip value 488
 Aug 13 17:09:25 voipd[436]: call to sip:[email protected] terminated (488)
Aug 13 17:09:25 voipd[436]: EVENT(78): Internettelefonie mit 0049711xxxx ³ber sipsnip.com war nicht erfolgreich. Ursa
che: Not acceptable here (488)
Aug 13 17:09:26 voipd[436]: <<<UDP Status: 488 Not acceptable here
 Aug 13 17:09:26 voipd[436]: >>>UDP Request: ACK sip:[email protected]
Aug 13 17:09:28 voipd[436]: <<<UDP Status: 488 Not acceptable here
 Aug 13 17:09:28 voipd[436]: >>>UDP Request: ACK sip:[email protected]
Aug 13 17:09:32 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:32 voipd[436]: no transaction for status: 488 Not acceptable here
Aug 13 17:09:35 voipd[436]: disconnected(appl=5 plci=0x1105 ncci=0x0 incoming): remote: 0x3490 (0x0000) -
Aug 13 17:09:36 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:36 voipd[436]: no transaction for status: 488 Not acceptable here
Aug 13 17:09:40 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:40 voipd[436]: no transaction for status: 488 Not acceptable here
Aug 13 17:09:44 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:44 voipd[436]: no transaction for status: 488 Not acceptable here
Aug 13 17:09:48 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:48 voipd[436]: no transaction for status: 488 Not acceptable here
Aug 13 17:09:52 voipd[436]: <<<UDP Status: 488 Not acceptable here
Aug 13 17:09:52 voipd[436]: no transaction for status: 488 Not acceptable here

Bei den neueren Firmware-Versionen kommt nur noch dieses:

BusyBox v1.8.2 (2008-11-26 13:15:43 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
#

Hat wirklich niemand eine Lösung?

 

[hohony]

Ich krame mal diese recht alte und unbeantwortete Frage aus dem Schlamm

Seit einigen AVM-Firmware Versionen sind die -v Optionen von einigen
Daemons (z.B. voipd oder multid) NOT SET.

options:
-? - print this help
-f - run in forground. (NOTSET)
-s - stop daemon. (NOTSET)
-v - verbose. (NOTSET)
-p STRING - Pidfile. ("/var/run/voipd.pid")
-o INTEGER - osip2 debug. (0)
-M STRING - log memory debug to .... (NULL)
-C INTEGER - capi trace. (0)
-N - no higher priority. (NOTSET)
-R - tell voipd to register now. (NOTSET)
-U - tell voipd to unregister and disconnect all calls now. (NOTSET)
-B INTEGER - overwrite output bandwidth. (0)
-T - Test. (NOTSET)
-8 - CAPI nur mit 8 kHz. (NOTSET)
-A - Send AOC to CAPI. (NOTSET)
-D STRING - switch debug logs on. (NULL)

Das erschwert die Fehlersuche in einigen Fällen ungemein.

Hat jemand eine Idee?

 

[KvR]

Es wundert mich, dass nur wir zwei anscheinend ein Problem mit den fehlenden Optionen des voipd-Daemons haben. Bist Du schon weiter gekommen?

 

[RalfFriedl]

Vermutlich generiert die neue Version einfach keine Meldungen mehr, zumindest nicht mehr im normalen Ablauf.

Wenn die Meldungen hauptsächlich für AVM zur Fehlersuche dienen (was wahrscheinlich ist, weil kein Anwender, der die Box normal nutzt, diese jemals zu sehen bekam), dann wäre es plausibel für AVM, diese wegzulassen, sobald die Programme zuverlässig funktionieren. Ein weitere Argument dafür ist, daß man damit Platz in der Firmware spart, und bekanntlich sind die neueren Versionen ja deutlich größer und der Platz ist sehr knapp.

 

[csb]

Hi!
Habe das gleiche Problem - bekomme kein log auf der Konsole.
Dabei ist mir aufgefallen, dass die Funktionen -f, -s -R und -U funktionieren. Auch wenn man verbose=yes in voip.cfg einstellt, kommt "SET" bei dem verbose-Parameter.

Also, offensichtlich hat das "SET" "NOTSET" erstmal nur die Bedeutung, dass aktuell das Flag nicht gesetzt ist ... aber prinzipiell implementiert ist.

Warum ich kein log bekomme, und ihr auch nicht, weiß ich natürlich trotzdem nicht ...

Mein eigentliches Problem ist, dass sich der voipd mit der lokalen(!) IP 192.168.1.1 beim registrar (lancom) registriert ... args. Also kein Verbindungsaufbau, wenn jemand anruft ...

Gruß,
Sebastian

 

[voipd]

Yo, da kann ich mir nur anschliessen.

Habe eine 7240 mit der aktullen 73.05.05 und das Problem dass die 2 Accounts ueber "route_always_over_internet = yes;" irgendwann nicht mehr registriert sind.

Man kann den voipd mit "voipd -s" stoppen. "voipd -" gibt die Hilfe aus:

# voipd -        
option missing after '-'
usage: voipd voipd [options]
options:
  -?                 - print this help
  -f                 - run in forground. (NOTSET)
  -s                 - stop daemon. (NOTSET)
  -v                 - verbose. (NOTSET)
  -p STRING          - Pidfile. ("/var/run/voipd.pid")
  -o INTEGER         - osip2 debug. (0)
  -M STRING          - log memory debug to .... (NULL)
  -C INTEGER         - capi trace. (0)
  -N                 - no higher priority. (NOTSET)
  -R                 - tell voipd to register now. (NOTSET)
  -U                 - tell voipd to unregister and disconnect all calls now. (NOTSET)
  -B INTEGER         - overwrite output bandwidth. (0)
  -T                 - Test. (NOTSET)
  -8                 - CAPI nur mit 8 kHz. (NOTSET)
  -A                 - Send AOC to CAPI. (NOTSET)
  -D STRING          - switch debug logs on. (NULL)
#

Wenn man nun

# voipd -s
und dann
# voipd -v
oder
# voipd -v -f

eingibt kommen leider keine Meldungen!

Wie der "-D DEBUG" switch funktioiert weiss ich auch nicht!

Wer Infos hat moege sie mittteilen.

Danke

voipd.

 

[Joe_57]

Wie der "-D DEBUG" switch funktioiert weiss ich auch nicht!
Wer Infos hat moege sie mittteilen.

Du meist sicherlich den Modus -D STRING...
Dabei kannst du dich an dem Beispiel bei -p STRING orientieren.

voipd -D "/var/tmp/debug.txt"

Joe

 

[voipd]

Hallo Joe,

danke fuer die Hinweis. Leider hilft dieser Trick auch nicht weiter.

Ein voipd -v -D "/var/tmp/debug.txt" wird angenommen, aber keine Datei geschrieben. Zumindest nicht beim normalen telefonieren.

voipd.

 

[sf3978]

Schau mal ob:

cat /dev/debug | grep voipd

etwas anzeigt.

 

[voipd]

Hallo sf3978,

danke fuer den Tip. Daran hatte ich auch schon gedacht. ;-)
Dabei kommt leider nichts sinnvolles raus. "cat" bricht immer ab wenn das device "leer" gecattet ist, was meistens nach ein paar Zeilen der Fall ist.

Was zur Anzeige hilft ist das: tail -f /dev/debug. Das bleibt dauerhaft bestehen.

Leider kommen dort aber nur einge Systemparameter (mem, sysxxx oder sonstiges) vorbei. Die Ausgabe aendert sich nicht, auch wenn man voipd mit -v gestartet hat. Kann jeder mal ausprobieren.

voipd.

 

[sf3978]

Dabei kommt leider nichts sinnvolles raus. "cat" bricht immer ab wenn das device "leer" gecattet ist, was meistens nach ein paar Zeilen der Fall ist.

Dann evtl. so versuchen, wie es cando mit NHIPT macht:

Wenn es um die Log - Funktion von NHIPT geht: sie macht weiter nichts,  als die Ausgaben von /dev/debug in eine Log-Datei umzuleiten:
[COLOR=red][B]cat /dev/debug > /var/tmp/system.log[/B][/COLOR]
Die datei wird in einem zweiten Schritt durchsucht, und nur die iptables Einträge in die endgültige FW-Logdatei umkopiert.

 

[voipd]

Hallo sf3978,

das hilft leider nichts, da in /dev/debug nichts verwertbare steht. Ein umkopieren mit anschliessendem Durchsuchen ist dementsprechend auch sinnlos.

Viele Gruesse

voipd.

 

[ciapecki]

Gibt es vielleicht mittlerweile irgendeine Moeglichkeit Verbose Log von voipd zu bekommen?

 

[tigerix]

Bin auch sehr an einer Lösung für dieses Problem interessiert.
Würde nämlich gerne sehen, warum eine Nummer via PSTN und nicht wie gedacht via ENUM angerufen wird.

FRITZ!Box Fon WLAN 7270 v3 FRITZ!OS 05.21