.titleBar { margin-bottom: 5px!important; }

fritzbox zu fritzbox geht nicht mehr

Dieses Thema im Forum "Asterisk auf FBF" wurde erstellt von lipperreiher, 16 Sep. 2008.

  1. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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
     
  2. dynamic

    dynamic Aktives Mitglied

    Registriert seit:
    1 Apr. 2006
    Beiträge:
    1,154
    Zustimmungen:
    0
    Punkte für Erfolge:
    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
     
  3. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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
     
  4. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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
     
  5. dynamic

    dynamic Aktives Mitglied

    Registriert seit:
    1 Apr. 2006
    Beiträge:
    1,154
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    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 ...
     
  6. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo dynamic,

    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
     
  7. dynamic

    dynamic Aktives Mitglied

    Registriert seit:
    1 Apr. 2006
    Beiträge:
    1,154
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    #7 dynamic, 18 Sep. 2008
    Zuletzt bearbeitet: 18 Sep. 2008
    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
     
  8. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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 ........
     
  9. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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
     
  10. dynamic

    dynamic Aktives Mitglied

    Registriert seit:
    1 Apr. 2006
    Beiträge:
    1,154
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    #10 dynamic, 18 Sep. 2008
    Zuletzt bearbeitet: 18 Sep. 2008
    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
     
  11. bodega

    bodega Aktives Mitglied

    Registriert seit:
    6 Juni 2006
    Beiträge:
    1,980
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    Ort:
    NRW
    Versuch auch vorher mal ein:
    Code:
    export LD_LIBRARY_PATH="/lib" 
    
    Das kommt mir bekannt vor.
     
  12. lipperreiher

    lipperreiher Neuer User

    Registriert seit:
    25 Jan. 2005
    Beiträge:
    75
    Zustimmungen:
    0
    Punkte für Erfolge:
    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:772@192.168.0.1>;tag=3117808203
    To: <sip:772@192.168.0.1>
    Call-ID: 73100F1D426B65F4@169.254.1.1
    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:772@192.168.0.1:5061 SIP/2.0
    Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK3CF59D4404D2EC55
    From: <sip:772@192.168.0.1>;tag=996922801
    To: <sip:772@192.168.0.1:5061>
    Call-ID: 05B9D2ADB5BA8494@192.168.0.2
    CSeq: 5 SUBSCRIBE
    Contact: <sip:772@192.168.0.2;uniq=7440BFE23520F2921736CCB3335DA>
    Authorization: Digest username="772", realm="asterisk", nonce="614a090a", uri="sip:772@192.168.0.1: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