- Mitglied seit
- 11 Mrz 2007
- Beiträge
- 9
- Punkte für Reaktionen
- 0
- Punkte
- 0
In meinem Beitrag "Ärger mit S450 IP und Asterisk nach Firmware Update (Anmeldung nicht erfolgreich)" habe ich mich ja schon mal mit dem Problem auseinandergesetzt. Inzwischen bin ich der Ursache schon mal was näher gekommen und möchte gerne über das Problem berichten.
Fassen wir das Problem nochmals zusammen: Hin und wieder ist das Telefon nicht mehr erreichbar. Das Display des Telefons zeigt dann "Provider Anmeldung nicht erfolgreich". Gleiches sieht man in der Web Basierten Administration.
Manchmal verschwindet es von alleine ziemlich schnell, manchmal will er einfach zum Verrecken nicht mehr. Das ganze scheint ziemlich zufallsgesteuert zu sein.
Den einen oder anderen Tip, der mir aus meiner letzten Message zugekommen ist, habe ich mit wechselndem aber nicht dauerhaften Erfolg eingesetzt.
Inzwischen habe ich in einer Debug-Session aus reinen Zufall zumindest mitbekommen, was da wirklich passiert.
Kommen wir also erst mal zu der Konfiguration der Ports:
Als heute das Telefon mal wieder seinen schlechten Tag hatte, passierte folgendes bei der Anmeldung an die Telefonanlage:
Die Antwort 401 Unauthorized spricht klare Worte. Die Reaktion des Telefons darauf ist dann auch korrekt. Aber warum meldet die Asterisk das Telefon also nicht an? Da muss doch was im REGISTER Requests des Telefons falsch sein.
Ist es auch! Als nämlich das Telefon sich entschieden hat, mal wieder brav zu sein und sich korrekt anzumelden, sah das ganze dann so aus:
Was ist nun passiert? Man braucht sich eigentlich nur den Request des Telefons anzusehen, um sofort etwas ganz wichtiges zu merken:
Der Fehlerhafte Request hat 12 Headers, der erfolgreiche hingegen 13. Welcher Header fehlt?
BINGO! Es fehlt der mit dem Passwort! Ist ja kein Wunder, daß die Asterisk das Telefon dann nicht reinlässt.
Warum zickt das Telefon also so rum? Ich erlaube mir jetzt erst mal mit meiner langjährigen Erfahrung als Softwareentwickler folgende Hypothese aufzustellen, die ich in den nächsten Wochen versuchen werde experimentell zu belegen.
Die Hypothese basiert auf folgende Annahmen:
Ich nehme also jetzt mal an, daß der interne Speicher für den Realm ein char[16] oder ein char[16+1] (Null Terminierung!) ist. Ich nehme weiterhin an, daß wie so oft üblich, der Entwickler vergessen hat mit strncpy statt strcpy zu arbeiten. Folglich überschreibt mein Realm den maximalen Speicherbereich für den String und saut irgendwo in irgendwelchen Werten rum. Was dann passiert, kann keiner mehr sagen, ohne den Quellcode gesehen zu haben. Daß ein System dann anfängt nach einem undurchsichtigen Muster zu handeln, liegt auf der Hand.
Das ganze würde auch erklären, wieso viele davon verschont sind. Das könnten dann die Leute sein, die einen Realm kurzer als 16 oder 15 haben.
Ich werde also nun folgende 2 Dinge tun:
Fakt ist, daß das Telefon bei der Anmeldung irgendwie rumschlampt.
Ich werde meine zukünftigen Erkenntnisse in diesem Thread posten.
Fassen wir das Problem nochmals zusammen: Hin und wieder ist das Telefon nicht mehr erreichbar. Das Display des Telefons zeigt dann "Provider Anmeldung nicht erfolgreich". Gleiches sieht man in der Web Basierten Administration.
Manchmal verschwindet es von alleine ziemlich schnell, manchmal will er einfach zum Verrecken nicht mehr. Das ganze scheint ziemlich zufallsgesteuert zu sein.
Den einen oder anderen Tip, der mir aus meiner letzten Message zugekommen ist, habe ich mit wechselndem aber nicht dauerhaften Erfolg eingesetzt.
Inzwischen habe ich in einer Debug-Session aus reinen Zufall zumindest mitbekommen, was da wirklich passiert.
Kommen wir also erst mal zu der Konfiguration der Ports:
Code:
[sip-phone1]
type=friend
context=incoming-internal
username=sip-phone1
secret=xxxxxxx
host=dynamic
insecure=invite
qualify=no
nat=no
disallow=all
allow=alaw
allow=ulaw
dtmfmode=inband
callerid="Gigaset Leo 1" <15>
callgroup=1
pickupgroup=1
canreinvite=noAls heute das Telefon mal wieder seinen schlechten Tag hatte, passierte folgendes bei der Anmeldung an die Telefonanlage:
Code:
REGISTER sip:xxxxxxx.xxxxxx.xxx SIP/2.0
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKccbbd0af59937b5e52c21771fc7c28ca;rport
From: sip-phone1 <sip:[email protected]>;tag=3491533357
To: sip-phone1 <sip:[email protected]>
Call-ID: 733320857@192_168_65_20
CSeq: 6361 REGISTER
Contact: "sip-phone1" <sip:[email protected]:5060>
Max-Forwards: 70
User-Agent: S450 IP020590000000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO
Content-Length: 0
--- (12 headers 0 lines) ---
Using latest REGISTER request as basis request
Sending to 192.168.65.20 : 5060 (NAT)
Transmitting (no NAT) to 192.168.65.20:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKccbbd0af59937b5e52c21771fc7c28ca;received=192.168.65.20;rport=5060
From: sip-phone1 <sip:[email protected]>;tag=3491533357
To: sip-phone1 <sip:[email protected]>
Call-ID: 733320857@192_168_65_20
CSeq: 6361 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0
---
Transmitting (no NAT) to 192.168.65.20:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKccbbd0af59937b5e52c21771fc7c28ca;received=192.168.65.20;rport=5060
From: sip-phone1 <sip:[email protected]>;tag=3491533357
To: sip-phone1 <sip:[email protected]>;tag=as5aa3dd20
Call-ID: 733320857@192_168_65_20
CSeq: 6361 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
WWW-Authenticate: Digest algorithm=MD5, realm="xxxxxxx.xxxxxx.xxx", nonce="61ff892f"
Content-Length: 0Die Antwort 401 Unauthorized spricht klare Worte. Die Reaktion des Telefons darauf ist dann auch korrekt. Aber warum meldet die Asterisk das Telefon also nicht an? Da muss doch was im REGISTER Requests des Telefons falsch sein.
Ist es auch! Als nämlich das Telefon sich entschieden hat, mal wieder brav zu sein und sich korrekt anzumelden, sah das ganze dann so aus:
Code:
REGISTER sip:xxxxxxx.xxxxxx.xxx SIP/2.0
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKe303ee84ec28183237e1b1f48c5f27f6;rport
From: sip-phone1 <sip:[email protected]>;tag=1004802865
To: sip-phone1 <sip:[email protected]>
Call-ID: 3002548897@192_168_65_20
CSeq: 6238 REGISTER
Contact: "sip-phone1" <sip:[email protected]:5060>
Authorization: Digest username="sip-phone1", realm="xxxxxxx.xxxxxx.xxx", algorithm=MD5, uri="sip:xxxxxxx.xxxxxx.xxx", nonce="xxxxxxxx", response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Max-Forwards: 70
User-Agent: S450 IP020590000000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO
Content-Length: 0
--- (13 headers 0 lines) ---
Using latest REGISTER request as basis request
Sending to 192.168.65.20 : 5060 (NAT)
Transmitting (no NAT) to 192.168.65.20:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKe303ee84ec28183237e1b1f48c5f27f6;received=192.168.65.20;rport=5060
From: sip-phone1 <sip:[email protected]>;tag=1004802865
To: sip-phone1 <sip:[email protected]>
Call-ID: 3002548897@192_168_65_20
CSeq: 6238 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0
---
Transmitting (no NAT) to 192.168.65.20:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.65.20:5060;branch=z9hG4bKe303ee84ec28183237e1b1f48c5f27f6;received=192.168.65.20;rport=5060
From: sip-phone1 <sip:[email protected]>;tag=1004802865
To: sip-phone1 <sip:[email protected]>;tag=as2cff62d6
Call-ID: 3002548897@192_168_65_20
CSeq: 6238 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 180
Contact: <sip:[email protected]:5060>;expires=180
Date: Thu, 05 Apr 2007 12:12:42 GMT
Content-Length: 0Was ist nun passiert? Man braucht sich eigentlich nur den Request des Telefons anzusehen, um sofort etwas ganz wichtiges zu merken:
Der Fehlerhafte Request hat 12 Headers, der erfolgreiche hingegen 13. Welcher Header fehlt?
BINGO! Es fehlt der mit dem Passwort! Ist ja kein Wunder, daß die Asterisk das Telefon dann nicht reinlässt.
Warum zickt das Telefon also so rum? Ich erlaube mir jetzt erst mal mit meiner langjährigen Erfahrung als Softwareentwickler folgende Hypothese aufzustellen, die ich in den nächsten Wochen versuchen werde experimentell zu belegen.
Die Hypothese basiert auf folgende Annahmen:
- Der Realm meiner Asterisk lautet xxxxxxx.xxxxxx.xxx (OK. Nicht wirklich so, aber die Anzahl der Zeichen und die Position der Punkte stimmt).
- Die Länge dieser Zeichenkette ist 18 Zeichen. Übliche Realms sind meistens kürzer (Beispiel: sipgate.de, messagenet.it, freenet.de oder sogar eine TCP/IP Adresse).
- Bei der Programmierung von Embedded Applikationen (das S450IP ist eine solche) versuchen Programmierer sorgfältig mit den sehr knappen Ressourcen (Speicher/Prozessor) umzugehen. Dynamische Strings sind deshalb oft verpönt.
- C und Assembler Programmierer neigen dazu statische Strings meistens in der Länge einer Zweier-Potenz zu definieren.
Ich nehme also jetzt mal an, daß der interne Speicher für den Realm ein char[16] oder ein char[16+1] (Null Terminierung!) ist. Ich nehme weiterhin an, daß wie so oft üblich, der Entwickler vergessen hat mit strncpy statt strcpy zu arbeiten. Folglich überschreibt mein Realm den maximalen Speicherbereich für den String und saut irgendwo in irgendwelchen Werten rum. Was dann passiert, kann keiner mehr sagen, ohne den Quellcode gesehen zu haben. Daß ein System dann anfängt nach einem undurchsichtigen Muster zu handeln, liegt auf der Hand.
Das ganze würde auch erklären, wieso viele davon verschont sind. Das könnten dann die Leute sein, die einen Realm kurzer als 16 oder 15 haben.
Ich werde also nun folgende 2 Dinge tun:
- Ich konfiguriere meine Asterisk um und benutze einen sehr kurzen Realm. Mal sehen, ob die Probleme dann noch auftauchen.
- Ich melde das ganze Siemens und schaue mal, ob es hier eine Reaktion gibt.
Fakt ist, daß das Telefon bei der Anmeldung irgendwie rumschlampt.
Ich werde meine zukünftigen Erkenntnisse in diesem Thread posten.
Zuletzt bearbeitet:
