fritzbox zu fritzbox geht nicht mehr

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

folgendes Szenario ging bis heute mittag bei mir wunderbar und jetzt leider nicht mehr:

Auf der "HauptFritzBox" (7050, Version 14.04.15 mit 2.4er Kernel) habe ich ein Asterisk installiert, das auch herzallerliebst funktioniert. Alle möglichen Geräte können sich dagegen registrieren. Diese Box hat auch den Zugang zum Internet, fungiert also als Router. Der Asterisk horcht natürlich auf Port 5061, weil 5060 schon durch hauseigenes voip belegt.

Die "ZweitFritzbox" hängt hinter der Ersten, sozusagen als Client im LAN (auch 7050, aber schon mit 2.6er Kernel, Version: 14.04.33)

Nun krieg ich es nicht mehr gebacken, dort den Account 772 zu registrieren. Die Box meldet immer "Gegenstelle antwortet nicht. Zeitüberschreitung".

Netzmäßig können sich beide Fritzboxen erreichen (ping geht auf beiden Boxen durch).

Bis heute mittag hat das eigentlich gut gefunzt, aber nach einem Reboot der Zweitfritzbox geht es nicht mehr. Das einzige, was ich zwischendurch mal probiert hatte, war, dass ich auf der Zweitfritzbox probehalber den asterisk-server von spblinux installiert habe. Habe ihn danach aber sofort wieder runtergeschmissen und sofort danach den reboot.
Passiert da irgendetwas, was zu so einem Fehler führen könnte?

Komisch ist allerdings, daß ein Account auf meinem vServer im Internet sich registrieren läßt. Somit scheint es kein grundsätzliches Problem der Box zu sein.

Hier der Auszug aus der sip.conf
Code:
[general]

bindport=5061                   ; UDP Port to bind to (SIP standard port is 5060
externhost=www.meineurl.no-ip.com
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)  
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls      
language=de

[772]                                                                     
context=sip772                                                            
callerid="TestSIP 772" <772>                                              
host=dynamic                                                              
domain=0.0.0.0                                                           
;nat=yes                       ; X-Lite is behind a NAT router           
type=friend                                                              
user=772                                                      
secret=secret                                                 
;mailbox=772                                                  
;canreinvite=no                ; Typically set to NO if behind NAT
                                                                  
;regexten=1234                 ; When they register, create extension 1234
;username=xlite1                                                          
disallow=all                                                              
allow=gsm                     ; GSM consumes far less bandwidth than ulaw 
allow=ulaw                                                                
allow=alaw
Zurück auf Werkseinstellung habe ich auch schon versucht, ohne Erfolg.
Auf dem asterisk sehe ich keinerlei Aktivität, wenn ich versuche mich zu registrieren.

Ich schnall dat nich mehr? Was mach' ich falsch?

Hoffe auf kreative Ideen

Gruß

lipperreiher
 

dynamic

Aktives Mitglied
Mitglied seit
1 Apr 2006
Beiträge
1,154
Punkte für Reaktionen
0
Punkte
36
Nach einem Reboot ist eigentlich alles von der Asterisk Installation weg und ich glaube kaum, dass darin die Ursache liegt.

Starte Deinen Asterisk auf der FBF1 mal mit hoher Verbosität, um am CLI-Log zu sehen ob der SIP Request am Asterisk ankommt.

Auf der FBF2 kannst Du via "voipd -R" und "voipd -U" die Reistirerung/De-Registrierung gezielt anstossen, um zu beobachten, was am FBF1 passiert.

Gruß
dynamic
 

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Moin, moin,

Auf der FBF1 habe ich "set verbose 20" gesetzt und auf der FBF2 die Registrierung/Deregistrierung durchgeführt.

Leider ist auf der FBF1 nichts zu sehen. Es sieht so aus, als ob die FBF2 gar nicht versucht, die FBF1 zu kontaktieren oder eine falsche Adresse nutzt.
Ist es vielleicht ein netzwerktechnisches Problem?

Hier mal die Ausgabe von ifconfig:

Code:
eth0      Link encap:Ethernet  HWaddr 00:04:0E:A7:7E:73
          UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:79 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18610 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:256
          RX bytes:8560 (8.3 KiB)  TX bytes:1514147 (1.4 MiB)

eth1      Link encap:Ethernet  HWaddr 00:04:0E:A7:7E:74
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:98653 errors:0 dropped:25 overruns:0 frame:25
          TX packets:98443 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:256
          RX bytes:10726122 (10.2 MiB)  TX bytes:12650042 (12.0 MiB)
          Base address:0x2800

lan       Link encap:Ethernet  HWaddr 00:04:0E:A7:7E:73
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:98606 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98364 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9345450 (8.9 MiB)  TX bytes:12641482 (12.0 MiB)

lan:0     Link encap:Ethernet  HWaddr 00:04:0E:A7:7E:73
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2985 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2985 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:287467 (280.7 KiB)  TX bytes:287467 (280.7 KiB)

usbrndis  Link encap:Ethernet  HWaddr 00:04:0E:A7:7E:77
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Wozu ist eigentlich das "lan:0" gut?

Die IP-Adresse der FBF1 ist: 192.168.0.1
Die IP-Adresse der FBF2 ist: 192.168.0.2 (mit 192.168.0.1 als default-GW)

Auf meinem vServer sehe ich übrigens die Reg-bzw. Dereg-Aktivitäten der FBF2 sehr gut, nur auf der FBF1 kommt überhaupt nichts an ..... ;-(

Noch irgendwelche Ideen?

Gruß

lipperreiher
 

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Einen Workaround habe ich jetzt geschaffen:

Code:
ifconfig lan:0 down (Deaktivieren des überflüssigen Netzwerkdevices)
voipd -s (Stoppen des Voip-Dämons)
voipd     (Starten des Voip-Dämons)
Sofort nach dem "voipd" kann ich auf der FBF1 die Registrierung sehen und alles ist schön.

Es scheint demnach also tatächlich ein Problem netzwerktechnischer Natur zu sein.

Was ich nicht verstehe: die Erreichbarkeit (zumindest per ping) ist doch gegeben.

Weiß jemand, wie dieses lan:0-device überhaupt zustande kommt, und dann noch mit so'ner merkwürdigen IP-Adresse?
Die scheint auf jeden Fall der Grund für mein Problem zu sein ..............??!!

Gruß

lipperreiher
 

dynamic

Aktives Mitglied
Mitglied seit
1 Apr 2006
Beiträge
1,154
Punkte für Reaktionen
0
Punkte
36
Weiß jemand, wie dieses lan:0-device überhaupt zustande kommt, und dann noch mit so'ner merkwürdigen IP-Adresse?
Es handelt sich dabei um eine art "Emergency Interface", welches auf allen FBF existiert. Über diese IP kannst Du Deine FBF regulär erreichen, auch dann, wenn z.B. DHCP nicht funktioniert und Dein PC keine IP erhalten hat ( denn auch Dein PC verhält sich ähnlich und hat in einem solchen Fall eine "merkwürdige IP" aus der gleichen Netz-Klasse )

Dass das Runterfahren dieses Interfaces Dein Problem löst, ist schon komisch. Irgendwie scheint Deine NW-Konfig "durcheinander" zu sein.

Vielleicht rebootest Du auch mal die FBF1 ...
 

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Hallo dynamic,

Vielleicht rebootest Du auch mal die FBF1 ...
Ja, das hab' ich zwischendurch auch schon gemacht ... ohne Erfolg :-(

Das ist wirklich komisch, dass das Deaktivieren der Schnittstelle mein Problem löst, aber ich konnte es mehrmals reproduzieren. Immer wenn lan:0 aktiv war, kam auf meiner FBF1 nichts an.

Vielleicht starte ich mal komplett bei Null (mit recovery.exe) ...., bei meiner FBF2

Gruß

lipperreiher
 

dynamic

Aktives Mitglied
Mitglied seit
1 Apr 2006
Beiträge
1,154
Punkte für Reaktionen
0
Punkte
36
Wenn ich das richtig sehe ist der Zustand wie folgt, richtig ?

1) FBF2 -> SIP -> FBF1-Asterisk : NOK
2) FBF2 -> SIP -> vServer-Asterisk : OK
3) vServer -> SIP -> FBF1-Asterisk: OK

Wenn dem so ist, kann es auch sein, dass das Problem an der FBF1 liegt, weil es evtl. auf Port 192.168.0.1 nicht horcht ( und stattdessen lediglich Pakete am 169.254.1.1 und am externen Interface annimmt, was erklären würde warum das lan0 Interface auf Deiner FBF2 zu Problemen führt, da gleiche IP ).

Versuche daher mal auf Deiner FBF1 bindaddr im sip.conf gezielt auf Dein lan Interface 192.168.0.1 der FBF1 zu setzen:
Code:
bindaddr=192.168.0.1
 
Zuletzt bearbeitet:

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Code:
1) FBF2 -> SIP -> FBF1-Asterisk : NOK
2) FBF2 -> SIP -> vServer-Asterisk : OK
3) vServer -> SIP -> FBF1-Asterisk: OK
Zustand 1 und 2 sind richtig dargestellt. Zustand 3 habe ich noch gar nicht ausprobiert, die Variante mit dem "bindaddr=192.168.0.1" hingegen schon, auch ohne Erfolg.

Ich bin aber nach wie vor der Meinung, dass das Problem auf der FBF2 liegt, und zwar konkret an der IP-Adresse "169.254.1.1".
Wenn ich mit "ifconfig lan:0 192.168.178.200 netmask 255.255.255.0" dem Device einen andere IP-Adresse zuweise, und anschließend "voipd -s;voipd" mache, klappt die Registrierung sofort.

Ich versteh's zwar nicht, aber so ist es.
Hier mal die Ausgabe von "route -n" (vor der Änderung des lan:0-Devices):

Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         192.168.0.1     0.0.0.0         UG    9      0        0 lan
Danach sollte eigentlich klar sein, dass die FBF2 die Verbindung zur FBF1 via Default-GW erreicht, und ein gegenseitiger ping geht auch problemlos durch ........
 

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Solange ich die Ursache meines Problems nicht kenne, möchte ich meinen Workaround wenigstens automatisieren, so dass nach einem Neustart der FBF2 die Registrierung funktioniert. Dazu habe ich die folgenden Zeilen in die /var/flash/debug.cfg hinzugefügt:

Code:
###
### Workaround fuer Registrierproblem
###

ifconfig lan:0 192.168.178.200 netmask 255.255.255.0

cd
MY_LOG=/var/tmp/output-voipd.txt
echo "#######################################################" >>$MY_LOG
/bin/voipd -s >>$MY_LOG 2>&1
echo `date` >>$MY_LOG
echo "#######################################################" >>$MY_LOG
sleep 20
echo "" >>$MY_LOG
/bin/voipd >>$MY_LOG 2>&1
echo `date` >>$MY_LOG
echo "#######################################################" >>$MY_LOG
Weder das Stoppen noch das Starten scheint zu funktionieren. Das erzeugte Logfile sieht wie folgt aus:

Code:
#######################################################
voipd: still running (445)
Thu Sep 18 10:50:17 CEST 2008
#######################################################

voipd: Couldn't load shared library  libavmssl.so - File not found - Success (0)
Thu Sep 18 10:50:37 CEST 2008
#######################################################
Eigentlich mach ich nichts anderes als ich auf der Konsole auch mache. Was muß denn noch beachtet werden beim Verskripten, irgendwelche Pfade oder ähnliches?
Was ist mit der library, die nicht gefunden wird?

Gruß

lipperreiher
 

dynamic

Aktives Mitglied
Mitglied seit
1 Apr 2006
Beiträge
1,154
Punkte für Reaktionen
0
Punkte
36
Funktioniert Dein Script, wenn Du es im Normalbetrieb ausführst, z.B. via:
Code:
. /var/flash/debug.cfg
Wenn ja, solltest Du in Deiner debug.cfg eine Schleife ( z.B. warten bis Internet usw. verfügbar sind ) einbauen
Code:
while !(ping -c 1 [URL="http://www.irgendeine_url.com"]www.irgendeine_url.com[/URL]); do
 sleep 5
done
bevor Du Deine Anweisungen ausführst.
Gruß
dynamic
 
Zuletzt bearbeitet:

bodega

Aktives Mitglied
Mitglied seit
6 Jun 2006
Beiträge
1,980
Punkte für Reaktionen
2
Punkte
0
lipperreiher schrieb:
Was ist mit der library, die nicht gefunden wird?
Versuch auch vorher mal ein:
Code:
export LD_LIBRARY_PATH="/lib"
Das kommt mir bekannt vor.
 

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Moin zusammen,

tja, also die while-Schleife ist in dem debug.cfg bereits weiter oben eingebaut, daran kann's nicht liegen.

Der Tipp mit dem LD_LIBRARY_PATH hat leider auch nicht geholfen.

Ich löse das Problem zur Zeit so, dass ich auf der FBF1 eine weitere virtuelle Schnittstelle "lan:1" definiere u. zwar mit der folgenden IP-Adresse: 169.254.1.2
Somit können sich die beiden Boxen wieder verständigen.

Ich habe das debug auf der FBF1 mit "sip debug ip 192.168.0.2" mal ein wenig geschwätziger gemacht.
Es kommt doch etwas an, wenn die FBF2 versucht, sich zu registrieren:

Code:
(none)*CLI>
<-- SIP read from 192.168.0.2:5060:
REGISTER sip:192.168.0.1 SIP/2.0
Via: SIP/2.0/UDP 169.254.1.1:5060;branch=z9hG4bKBBD2E44A098FC4B4
From: <sip:[email protected]>;tag=3117808203
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7050 14.04.33 (May 10 2007)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
Wie man sehen kann, funkt die 169er IP-Adresse irgendwie dazwischen (Via: SIP ...., Call-ID: ......)


Sobald ich auf der FBF1 die zusätzliche IP-Adresse aktiviere, geht die Registrierung durch.
Dann sieht der output vom debug wie folgt aus:

Code:
<-- SIP read from 192.168.0.2:5060:
SUBSCRIBE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK3CF59D4404D2EC55
From: <sip:[email protected]>;tag=996922801
To: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 5 SUBSCRIBE
Contact: <sip:[email protected];uniq=7440BFE23520F2921736CCB3335DA>
Authorization: Digest username="772", realm="asterisk", nonce="614a090a", uri="sip:[email protected]:5061", response="b83087db9d269435db393867823223d1"
Event: message-summary
Expires: 3600
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7050 14.04.33 (May 10 2007)
Allow: NOTIFY
Accept: application/simple-message-summary
Content-Length: 0
Jetzt ist auch nichts mehr von der 169er IP-Adresse zu sehen.
(Ich guck auf'm Tich: kein Fleich, kein Fich, KOMICH, NICH?)

Versteht das jemand??

Gruß

lipperreiher
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
232,891
Beiträge
2,027,805
Mitglieder
351,017
Neuestes Mitglied
mucfaber