Problem mit FBF WLAN hinter Bintec X1200

charley · 4 Okt 2005

Hi,

ich versuche seit Samstag, die FBF mit der neuen Fw hinter meinem X1200 zum Laufen zu bringen.

Nach etlichen Stunden habe ich meinen 1&1-Account nicht als 1&1 sondern als sonstiger Anbieter konfiguriert und dabei auch noch die 49 vor der Nummer weggelassen. Danach hat sich die FBF bei 1&1 registriert und ich konnte ausgehende und einkommende Gespräche führen. Die Registrierung blieb über mehrere Stunden erhalten. Seit gestern jedoch registriert sich die FBF nicht mehr bei 1&1. Fehlergrund: Gegenstelle antwortet nicht. Zeitüberschreitung. Auch Konfiguration als 1&1 bringt keine Änderung.

Beim Account bei messagenet.it registriert sich die FBF sofort nach dem hochfahren. Die FBF nimmt jedoch keine Gespräche auf diesem Account an; Anrufer erhalten die deutsche (!) Ansage, dass der Anschluss vorübergehend nicht erreichbar ist. Nach etwa 10 bis 20 Minuten ist die Registrierung beendet und kann wieder durch Neustart der FBF erreicht werden.

Am Samstag noch war es möglich, sich bei sipgate.de und bei sipgate.co.uk zu registrieren. Inzwischen registriert sich die FBF nur noch bei sipgate.de. Sipgate.co.uk bringt Fehlergrund: Gegenstelle antwortet nicht. Zeitüberschreitung. In beiden Fällen war es jedoch bisher nicht möglich, eingehende Gespräche entgegenzunehmen oder abgehende Gespräche zu führen. Anrufe bei den beiden Nummern ergeben ein Belegtsignal; abgehende Anrufe werden mit Fehlergrund 503 quittiert. Auf der Sipgate-Website wurden immer die korrekten IP-Adressen für die registrierte FBF angezeigt. Auch die Sipgate-Registrierungen blieben jeweils nur maximal für 20 Minuten erhalten, danach war Neustart notwendig.

Im X1200 sind sämtliche relevanten Ports zur FBF weitergeleitet (NAT requested from outside); im Log des X1200 sind keinerlei abgelehnte Connections verzeichnet. SIF ist nicht aktiviert.

Die diversen Postings zum X1200 habe ich gelesen; sie haben mich aber bisher nicht weitergebracht. Was ich jetzt brauche, ist ein ganz heißer Tip.

Viele Grüße
Charley

14dima · 14 Okt 2005

Hi,
das gleiche Problem mit meinem BinTec X1200 habe ich auch.
Wenn ich die FBF als alleinstehende Anlage konfiguriere und
dann die Einstellungen um FBF hinter Bintec zu betreiben ändere, funzt alles soweit ok, bis die FBF neu gestartet wird. Dann können die VoIP Accounts von 1und1 nicht mehr registriert werden... :?:

charley · 16 Okt 2005

FBF zurückgesetzt

Jetzt habe ich erstmal die FBF direkt am DSL-Anschluss eingesteckt und als Router konfiguriert. Der Internetzugang funktioniert, nicht jedoch VoIP.

Als nächstes habe ich die FBF wieder hinter dem X1200 angeschlossen. Zur Sicherheit FBF auf Werkseinstellungen gesetzt, Firmware 86 neu eingespielt und alle Einstellungen neu eingegeben. Ohne Erfolg. Bei allen VoIP-Accounts Zeitüberschreitung. Internetzugang funktioniert aber. WLAN funktioniert. Alles funktioniert. Außer VoIP. Im X1200 werden keine verweigerten Connections angezeigt. Ich bin der Verzweiflung nahe.

Gruß
Charley.

RB · 16 Okt 2005

Moin!

Dummerweise verfüge ich nicht über eine FBF, so daß ich das jetzt nicht nachvollziehen kann.

@charley
Im Bintec kannst Du doch per Telnet und "debug all" eine Ausgabe der gesamten Aktivitäten des Routers erhalten. Wenn Du das zum passenden Zeitpunkt mitloggst und dann mal durchforstest, sollte man dem Geschehen doch auf die Schliche kommen können. Parallel dazu dann noch ein Log der FBF wäre auch nicht schlecht...

charley · 17 Okt 2005

X1200-Debug

Hi,

@Ralf

Ich habe ein Debug-Listing meines X1200 von der versuchten sipgate-Registrierung gemacht. Ich kann darin aber nichts verdächtiges finden:

Code:

## FBF 10.50.1.83

07:44:25 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 57107 "_stun._udp.1und1.de." 33 1
07:44:25 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 57107 to 217.237.151.161:53 id 13914 "_stun._udp.1und1.de." 33
07:44:25 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 49376 "_sip._udp.sip.1und1.de." 33 1
07:44:25 DEBUG/INET: dnsd: cache neg for _sip._udp.sip.1und1.de.
07:44:25 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 49376 "_sip._udp.sip.1und1.de." 33 0/0/0
07:44:25 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33101 -> 217.237.151.161:53
07:44:25 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 49987 "sip.1und1.de." A 1
07:44:25 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 49987 to 217.237.151.161:53 id 13915 "sip.1und1.de." A
07:44:25 INFO/INET: dnsd: error parsing name
07:44:25 INFO/INET: dnsd: error parsing question
07:44:25 INFO/INET: dnsd: error parsing dns packet
07:44:25 INFO/INET: dnsd: invalid rsp from 217.237.151.161:53 len -1
07:44:25 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13915 "sip.1und1.de."A 0 1/0/0
07:44:25 INFO/INET: dnsd: cache add 212.227.15.197 for sip.1und1.de.
07:44:25 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 49987 "sip.1und1.de." A 1/0/0
07:44:25 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33102 -> 212.227.15.197:5060
07:44:25 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.51.74:5060/84.162.50.74:5060 <- 212.227.15.197:5060
07:44:25 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 212.227.15.197:5060/84.162.50.74:33103 -> 94.178.51.74:5060
07:44:27 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 46009 "_stun._udp.1und1.de." 33 1
07:44:27 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 46009 to 217.237.151.161:53 id 13916 "_stun._udp.1und1.de." 33
07:44:27 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13916 "_stun._udp.1und1.de." 33 0 1/0/0
07:44:27 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 46009 "_stun._udp.1und1.de." 33 1/0/0
07:44:27 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 34123 "stun.1und1.de." A1
07:44:27 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 34123 to 217.237.151.161:53 id 13917 "stun.1und1.de." A
07:44:27 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13917 "stun.1und1.de." A 0 1/0/0
07:44:27 INFO/INET: dnsd: cache add 212.227.15.200 for stun.1und1.de.
07:44:27 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 34123 "stun.1und1.de." A 1/0/0
07:44:27 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33104 -> 212.227.15.200:3478
07:44:27 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 57196 "_sip._udp.1und1.de." 33 1
07:44:27 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 57196 to 217.237.151.161:53 id 13918 "_sip._udp.1und1.de." 33
07:44:27 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33105 -> 217.10.79.9:5060
07:44:27 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13918 "_sip._udp.1und1.de." 33 0 3/0/0
07:44:27 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 57196 "_sip._udp.1und1.de." 33 3/0/0
07:44:27 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33104/84.162.50.74:33104 <- 212.227.15.197:5060
07:44:28 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33104/84.162.50.74:33104 <- 217.10.79.9:5060
07:44:30 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 57107 to 217.237.151.161:53 id 13914 "_stun._udp.1und1.de." 33
07:44:30 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13914 "_stun._udp.1und1.de." 33 0 1/0/0
07:44:30 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 57107 "_stun._udp.1und1.de." 33 1/0/0
07:44:47 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:135 <- 84.162.200.114:3165
07:44:48 INFO/INET: NAT: denied incoming session on ifc 10002 prot 17 84.162.50.74:1026 <- 202.99.172.160:48662
07:44:57 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33104 <-> 212.227.15.200:3478
07:45:00 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33101 <-> 217.237.151.161:53
07:45:12 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33104/84.162.50.74:33104 <-> 212.227.15.197:5060
07:45:12 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33104/84.162.50.74:33104 <-> 217.10.79.9:5060
07:45:16 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 6 10.50.1.5:92/84.162.50.74:92 <- 84.177.59.15:64891
07:45:23 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 94.178.51.74:5060/84.162.50.74:5060 <-> 212.227.15.197:5060
07:45:23 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 212.227.15.197:5060/84.162.50.74:33103 <-> 94.178.51.74:5060
07:45:26 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33102 <-> 212.227.15.197:5060
07:45:26 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33105 <-> 217.10.79.9:5060
07:45:36 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 6 10.50.1.1:2368/84.162.50.74:33943 -> 83.220.144.22:110
07:45:36 DEBUG/INET: TX: clamp mss 1460 ==> 1452
07:45:36 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 6 10.50.1.1:2369/84.162.50.74:33944 -> 83.220.144.22:110
07:45:36 DEBUG/INET: TX: clamp mss 1460 ==> 1452
07:45:36 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 6 10.50.1.1:2370/84.162.50.74:33945 -> 83.220.144.22:110
07:45:36 DEBUG/INET: TX: clamp mss 1460 ==> 1452
07:45:36 DEBUG/INET: RX: clamp mss 1460 ==> 1452
07:45:36 DEBUG/INET: RX: clamp mss 1460 ==> 1452
07:45:36 DEBUG/INET: RX: clamp mss 1460 ==> 1452
07:45:53 DEBUG/INET: NAT: delete session on ifc 10002 prot 6 10.50.1.1:2370/84.162.50.74:33945 <-> 83.220.144.22:110
07:45:53 DEBUG/INET: NAT: delete session on ifc 10002 prot 6 10.50.1.1:2369/84.162.50.74:33944 <-> 83.220.144.22:110
07:45:53 DEBUG/INET: NAT: delete session on ifc 10002 prot 6 10.50.1.1:2368/84.162.50.74:33943 <-> 83.220.144.22:110
07:45:54 DEBUG/INET: NAT: delete session on ifc 10002 prot 6 10.50.1.5:92/84.162.50.74:92 <-> 84.177.59.15:64891
07:46:28 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 36780 "_stun._udp.stun.sipgate.net:10000." 33 1
07:46:28 DEBUG/INET: dnsd: cache neg for _stun._udp.stun.sipgate.net:10000.
07:46:29 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 36780 "_stun._udp.stun.sipgate.net:10000." 33 0/0/0
07:46:29 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 30352 "stun.sipgate.net:10000." A 1
07:46:29 DEBUG/INET: dnsd: cache 217.10.79.2 for stun.sipgate.net:10000.
07:46:29 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 30352 "stun.sipgate.net:10000." A 1/0/0
07:46:29 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33106 -> 217.10.79.2:3478
07:46:29 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 22960 "_sip._udp.sipgate.de." 33 1
07:46:29 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 22960 to 217.237.151.161:53 id 13919 "_sip._udp.sipgate.de." 33
07:46:29 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33107 -> 217.237.151.161:53
07:46:29 INFO/INET: dnsd: error parsing name
07:46:29 INFO/INET: dnsd: error parsing question
07:46:29 INFO/INET: dnsd: error parsing dns packet
07:46:29 INFO/INET: dnsd: invalid rsp from 217.237.151.161:53 len -1
07:46:31 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 35958 "_sip._udp.sipgate.de." 33 1
07:46:31 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 35958 to 217.237.151.161:53 id 13920 "_sip._udp.sipgate.de." 33
07:46:31 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13920 "_sip._udp.sipgate.de." 33 0 1/0/0
07:46:31 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 35958 "_sip._udp.sipgate.de." 33 1/0/0
07:46:31 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 39840 "sipgate.de." A 1
07:46:31 DEBUG/INET: dnsd: cache 217.10.79.9 for sipgate.de.
07:46:31 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 39840 "sipgate.de." A 1/0/0
07:46:31 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33108 -> 217.10.79.9:5060
07:46:31 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33106/84.162.50.74:33106 <- 217.10.79.9:5060
07:46:34 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 22960 to 217.237.151.161:53 id 13919 "_sip._udp.sipgate.de." 33
07:46:34 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13919 "_sip._udp.sipgate.de." 33 0 1/0/0
07:46:34 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 22960 "_sip._udp.sipgate.de." 33 1/0/0
07:46:59 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33106 <-> 217.10.79.2:3478
07:47:04 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33107 <-> 217.237.151.161:53
07:47:09 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33106/84.162.50.74:33106 <-> 217.10.79.9:5060
07:47:27 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33108 <-> 217.10.79.9:5060
...
07:47:50 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 43000 "_stun._udp.stun.sipgate.net:10000." 33 1
07:47:50 DEBUG/INET: dnsd: cache neg for _stun._udp.stun.sipgate.net:10000.
07:47:50 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 43000 "_stun._udp.stun.sipgate.net:10000." 33 0/0/0
07:47:50 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 57345 "stun.sipgate.net:10000." A 1
07:47:50 DEBUG/INET: dnsd: cache 217.10.79.2 for stun.sipgate.net:10000.
07:47:50 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 57345 "stun.sipgate.net:10000." A 1/0/0
07:47:50 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33109 -> 217.10.79.2:3478
07:47:50 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 22947 "_sip._udp.sipgate.de." 33 1
07:47:50 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 22947 to 217.237.151.161:53 id 13921 "_sip._udp.sipgate.de." 33
07:47:50 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33110 -> 217.237.151.161:53
07:47:50 INFO/INET: dnsd: error parsing name
07:47:50 INFO/INET: dnsd: error parsing question
07:47:50 INFO/INET: dnsd: error parsing dns packet
07:47:50 INFO/INET: dnsd: invalid rsp from 217.237.151.161:53 len -1
07:47:52 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 16273 "_sip._udp.sipgate.de." 33 1
07:47:52 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 16273 to 217.237.151.161:53 id 13922 "_sip._udp.sipgate.de." 33
07:47:52 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13922 "_sip._udp.sipgate.de." 33 0 1/0/0
07:47:52 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 16273 "_sip._udp.sipgate.de." 33 1/0/0
07:47:52 DEBUG/INET: dnsd: qry from 10.50.1.83:7077 id 54484 "sipgate.de." A 1
07:47:52 DEBUG/INET: dnsd: cache 217.10.79.9 for sipgate.de.
07:47:52 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 54484 "sipgate.de." A 1/0/0
07:47:52 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33111 -> 217.10.79.9:5060
07:47:52 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33109/84.162.50.74:33109 <- 217.10.79.9:5060
...
07:47:55 DEBUG/INET: dnsd: fwd 10.50.1.83:7077 id 22947 to 217.237.151.161:53 id 13921 "_sip._udp.sipgate.de." 33
07:47:55 DEBUG/INET: dnsd: rsp from 217.237.151.161:53 id 13921 "_sip._udp.sipgate.de." 33 0 1/0/0
07:47:55 DEBUG/INET: dnsd: rsp to 10.50.1.83:7077 id 22947 "_sip._udp.sipgate.de." 33 1/0/0
07:48:20 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33109 <-> 217.10.79.2:3478
07:48:25 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.100:1026/84.162.50.74:33110 <-> 217.237.151.161:53
07:49:04 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33112 -> 217.10.79.2:3478
07:49:06 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33112/84.162.50.74:33112 <- 217.10.79.9:5060
07:49:07 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33109/84.162.50.74:33109 <-> 217.10.79.9:5060
07:49:35 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33112 <-> 217.10.79.2:3478
...
07:49:43 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:135 <- 84.161.224.206:3036
...
07:49:49 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33112/84.162.50.74:33112 <-> 217.10.79.9:5060
...
07:49:57 DEBUG/INET: NAT: new outgoing session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33113 -> 217.10.79.2:3478
07:49:57 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 10.50.1.83:33113/84.162.50.74:33113 <- 217.10.79.9:5060
07:50:27 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33113 <-> 217.10.79.2:3478
07:50:41 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:33113/84.162.50.74:33113 <-> 217.10.79.9:5060
07:50:55 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/844.162.50.74:33113 <-> 217.10.79.9:5060
07:50:55 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.50.74:33111 <-> 217.10.79.9:5060
07:51:24 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:135 <- 84.217.2.211:4085
07:51:27 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:135 <- 84.217.2.211:4085
07:51:33 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:445 <- 84.162.232.102:3618
07:51:36 INFO/INET: NAT: denied incoming session on ifc 10002 prot 6 84.162.50.74:445 <- 84.162.232.102:3618

Auch das FBF-Log zeigt mir nichts auffälliges, außer daß die Registrierung fehlschlägt:

Code:

## FBF 10.50.1.83
## X1200 10.50.1.100


voipd: stopped.
#
# Oct 17 07:47:38 cltmgr[312]: box_led_update_status
Oct 17 07:47:38 cltmgr[312]: got led event 20
Oct 17 07:47:39 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:47:39 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:47:39 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
Oct 17 07:48:10 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:48:10 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:48:10 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:48:10 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd -f
voipd: csock: using poll
voipd: startup (AVM FRITZ!Box Fon WLAN 7050 14.03.86 AVM SIP v3.01.18 Sep 30 2005 12:56:15)
voipd: using capi controller 5
voipd: using b1 protocol 1
voipd: tel: supported
voipd: ENUM NOT enabled
voipd: enumdomain: e164.arpa
voipd: enumdomain: e164.org
config: VAD off/10000, HandleCAPIUnderrun on, Jitter (auto on, 50 ms, 0 packets
voipd: 2: [email][email protected][/email] configured (STUN)
voipd: 1 useragent configured
voipd: INFO led: off (value=0)
voipd: priority is -20
voipd: encaplen 14
voipd: brutto speed 6624000/448000 voip speed 432000
voipd: connstatus 0 -> 5
voipd: second - NOT running (voip=0)
voipd: 0: connected    vcc 0/0/RBE/14 stay online 1
voipd: dns: _stun._udp.stun.sipgate.net:10000: query
voipd: PCMA: 98933 bits/second (encaplen=14,30ms)
voipd: PCMU: 98933 bits/second (encaplen=14,30ms)
voipd: G726-32: 56533 bits/second (encaplen=14,30ms)
voipd: G726-40: 70666 bits/second (encaplen=14,30ms)
voipd: G726-24: 56533 bits/second (encaplen=14,30ms)
voipd: iLBC: 63600 bits/second (encaplen=14,30ms)
voipd: PCMA: 106000 bits/second (encaplen=14,20ms)
voipd: PCMU: 106000 bits/second (encaplen=14,20ms)
voipd: G726-32: 63600 bits/second (encaplen=14,20ms)
voipd: G726-40: 84800 bits/second (encaplen=14,20ms)
voipd: G726-24: 63600 bits/second (encaplen=14,20ms)
voipd: iLBC: 63600 bits/second (encaplen=14,20ms)
Oct 17 07:48:30 cltmgr[312]: box_led_update_status
voipd: dns; _stun._udp.stun.sipgate.net:10000: not found
voipd: dns: stun.sipgate.net:10000: query
voipd: dns: stun.sipgate.net:10000: 217.10.79.2 ttl=44383 from 10.50.1.100.
Oct 17 07:48:30 cltmgr[312]: got led event 16
voipd: STUN: udp 5060 -> 84.162.50.74:33109
voipd: ip address changed 10.50.1.83:5060 -> 84.162.50.74:33109
voipd: 19xxxx3: my address 84.162.50.74:33109
voipd: [email][email protected][/email]: REGISTER starting
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: dns: _sip._udp.sipgate.de: query
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: dns: _sip._udp.sipgate.de: "0 0 5060 sipgate.de" ttl=1610 from 10.50.1.100.
voipd: dns: sipgate.de: query
voipd: dns: sipgate.de: 217.10.79.9 ttl=4230 from 10.50.1.100.
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
Oct 17 07:48:40 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:48:41 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:48:41 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:48:41 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
Oct 17 07:49:11 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:49:12 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:49:12 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:49:12 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: [email][email protected][/email]: REGISTER end
voipd: [email][email protected][/email]: REGISTER failed 5 status 0 (try again in 10 seconds)
voipd: EVENT(73): Anmeldung der Internetrufnummer 19xxxx3 ist gescheitert. Fehlergrund: Gegenstelle antwortet nicht. Zeit³berschreitung.
Oct 17 07:49:42 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:49:42 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:49:42 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:49:42 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd: is_register_allowed - NOT running (voip=0)
voipd: 0: connected    vcc 0/0/RBE/14 stay online 1
voipd: STUN: udp 5060 -> 84.162.50.74:33112
voipd: ip address changed 84.162.50.74:33109 -> 84.162.50.74:33112
voipd: 19xxxx3: my address 84.162.50.74:33112
voipd: [email][email protected][/email]: REGISTER starting
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
Oct 17 07:50:13 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:50:13 websrv[329]: 10.50.1.83:80: POLLHUP
voipd: >>> Request: REGISTER sip:sipgate.de
Oct 17 07:50:13 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:50:13 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:50:13 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd: [email][email protected][/email]: REGISTER end
voipd: [email][email protected][/email]: REGISTER failed 5 status 0 (try again in 20 seconds)
voipd: EVENT(73): Anmeldung der Internetrufnummer 19xxxx3 ist gescheitert. Fehlergrund: Gegenstelle antwortet nicht. Zeit³berschreitung.
voipd: is_register_allowed - NOT running (voip=0)
voipd: 0: connected    vcc 0/0/RBE/14 stay online 1
voipd: STUN: udp 5060 -> 84.162.50.74:33113
voipd: ip address changed 84.162.50.74:33112 -> 84.162.50.74:33113
voipd: 19xxxx3: my address 84.162.50.74:33113
voipd: [email][email protected][/email]: REGISTER starting
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
Oct 17 07:50:44 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:50:44 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:50:44 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: >>> Request: REGISTER sip:sipgate.de
voipd: [email][email protected][/email]: REGISTER end
voipd: [email][email protected][/email]: REGISTER failed 5 status 0 (try again in 40 seconds)
voipd: EVENT(73): Anmeldung der Internetrufnummer 19xxxx3 ist gescheitert. Fehlergrund: Gegenstelle antwortet nicht. Zeit³berschreitung.
Oct 17 07:51:14 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:51:14 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:51:15 cltmgr[312]: sipX/connect - SipConnStatusGet (0) returns 0
Oct 17 07:51:15 cltmgr[312]: sipX/connect - SipConnStatusGet (1) returns 0
Oct 17 07:51:15 cltmgr[312]: sipX/connect - SipConnStatusGet (2) returns 1
Oct 17 07:51:21 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:51:27 websrv[329]: 10.50.1.83:80: POLLHUP
Oct 17 07:51:30 cltmgr[312]: AOLVoIP_Autodetect_Stop
Oct 17 07:51:30 cltmgr[312]: Now doing actions: ActionMask is 0x10
Oct 17 07:51:33 websrv[329]: 10.50.1.83:80: POLLHUP
voipd: Signal: termination
voipd: signal detected, shutdown now
voipd: INTERNET led value = 0
#

Aber in einem der beiden logs müsste doch zu finden sein, was falsch ist?

Freundliche Grüße
Charley

RB · 17 Okt 2005

Moin!

Also ich sehe da schon so diverse Merkwürdigkeiten! Als Beispiel im Bintec-Log:

07:47:50 DEBUG/INET: NAT: new outgoing session ... prot 17 10.50.1.83:5060/84.162.50.74:33109 -> 217.10.79.2:3478 STUN
...
07:47:52 DEBUG/INET: NAT: new outgoing session ... prot 17 10.50.1.83:5060/84.162.50.74:33111 -> 217.10.79.9:5060 REGISTER
07:47:52 DEBUG/INET: NAT: new incoming session ... prot 17 10.50.1.83:33109/84.162.50.74:33109 <- 217.10.79.9:5060 RESP. REGISTER

Dazu passend in der FBF:

voipd: STUN: udp 5060 -> 84.162.50.74:33109
voipd: ip address changed 10.50.1.83:5060 -> 84.162.50.74:33109
voipd: 19xxxx3: my address 84.162.50.74:33109

Das versuche ich jetzt mal zu interpretieren...

Dir FBF versucht per STUN die eigene externe IP-Adresse sowie den dazupassenden Port rauszubekommen. Das mit der IP-Adresse gelingt ja auch. Das Problem ist der Port! Der STUN-Server meldet der FBF auch den Port, von dem er die Anfrage erhalten hat (hier 33109/UDP). Das merkt die FBF sich anscheinend als extern zugänglichen SIP-Controlport für das REGISTER. Im REGISTER werden sowohl öffentliche IP-Adresse als auch externer Port als Header-Einträge (das sind hier Nutzdaten! Nicht verwechseln mit IP-Header o.ä.) mitgeschickt. Der Registrar verwendet dann diese Daten, um Antworten, INVITEs usw zu schicken.

In der zweiten Zeile sieht man dann das REGISTER. Hier wird wieder abgehend von 5060/UDP gesendet, aber diesmal mit Zielport ebenfalls5060/UDP. Außerdem geht das an eine andere Ziel-IP (217.10.79.9) als die für STUN (217.10.79.2). Durch die andere Ziel-IP wird ein neuer NAT-Eintrag erzeugt, der natürlich auch einen anderen externen Port zur Folge hat (33111/UDP).

Die Antwort des Registrars (RESP. REGISTER)erfolgt dann wieder auf Port 33109, weil die FBF ihm das im REGISTER so mitgeteilt hat.

Bis hierhin ist alles erklärbar ein Fehler in der STUN-Verarbeitung. Ob nun auf Seiten der FBF oder auf Seiten von Sipgate ist hier nicht ganz eindeutig. Als Anmerkung hier noch, daß die Anfrage auf den Standard-STUN-Port 3478/UDP ging und nicht auf den Sipgate-STUN-Port 10000/UDP ?!

Das für mich größte Rätsel ist das Verhalten des Bintec in der letzten Zeile des obigen Log-Auszugs. Ich hätte erwartet, daß dort irgendwo ein Fehler der Art "INFO/INET: NAT: denied incoming session..." für diese Antwort auf das REGISTER auftauchen würde! Diese Kombination IP-Adresse/externer Port ist ja so eigentlich gar nicht in der NAT-Tabelle enthalten, dürfte also auch gar nicht durchgelassen werden!

Eigentlich sollte die STUN-Abfrage durch die FBF folgendes Ergebnis liefern:
Ich habe die-und-die externe IP, bin aber nicht von einer anderen IP als der des STUN-Servers von draußen über den externen Port der STUN-Anfrage erreichbar (weil symmetrisches NAT), schalte also diese ganzen Tricks ab und hoffe auf vernünftige Port-Forwardings im Router, die mein Herrchen/Frauchen gemacht haben sollte...

Genau eine solche Erkenntnis wird aber seitens FBF nicht gezogen, sondern stattdessen immer wieder eine neue STUN-Abfrage gestartet, die wiederum einen neuen externen Port zu Folge hat, da der alte NAT-Eintrag inzwischen seine maximale Lebensdauer erreicht hat und gelöscht wurde. Es wird also ein neuer NAT-Eintrag mit einem neuen externen Port erstellt.

Und das gleiche Spielchen wiederholt sich immer weiter...

Offen bleibt die Frage, ob der STUN-Server auf Seiten Sipgate nicht die richtigen Antworten an die FBF liefert oder die FBF die richtigen Antworten falsch verwurstet.

Ich habe ähnliche Probleme gehabt, allerdings nicht genau die gleichen, da bei mir keiner STUN macht (Mein Cisco-Telefon kann sowas gar nicht). Irgendwelche Port-Tricksereien sind aber bei einigen Registraren inzwischen üblich. Diese Tricks gehen bei höherwertigen Routern (mit symmetric NAT) aber regelmäßig schief! Daher habe ich zur Umgehung dieser Geschichten bei mir auch ein Port-Forwarding von intern nach extern gemacht, um sicherzustellen, daß Port 5060/UDP intern auch immer auf Port 5060/UDP extern rauskommt. Dadurch laufen die ganzen Port-Tricksereien der Registrare ins Leere

So - das war jetzt eine recht lange (aber wenigstens schön bunte

) Antwort. Ich hoffe, sie war auch verständlich...

charley · 18 Okt 2005

FBF vs. X1200

Hi Ralf,

erst mal recht herzlichen Dank für deine sehr ausführlichen Informationen. Jetzt, wo du mich drauf hingewiesen hast, sehe ich das Problem auch. Ich werde jetzt mal in der Richtung experimentieren und dann berichten.

Viele Grüße
Charley

charley · 18 Okt 2005

FBF vs. X1200

Hi Ralf,

Das für mich größte Rätsel ist das Verhalten des Bintec in der letzten Zeile des obigen Log-Auszugs. Ich hätte erwartet, daß dort irgendwo ein Fehler der Art "INFO/INET: NAT: denied incoming session..." für diese Antwort auf das REGISTER auftauchen würde! Diese Kombination IP-Adresse/externer Port ist ja so eigentlich gar nicht in der NAT-Tabelle enthalten, dürfte also auch gar nicht durchgelassen werden!

Da hast du recht. Ich hatte anfangs gemerkt, dass ständig einkommende Connections von sipgate abgewiesen wurden und habe daraufhin den betreffenden Portbereich zur FBF freigeschaltet. Ich habe diesen Eintrag jetzt wieder entfernt und die Connections werden prompt wieder abgewiesen.

Daher habe ich zur Umgehung dieser Geschichten bei mir auch ein Port-Forwarding von intern nach extern gemacht, um sicherzustellen, daß Port 5060/UDP intern auch immer auf Port 5060/UDP extern rauskommt.

Das habe ich jetzt auch gemacht, jedoch ohne dass sich eine Änderung ergeben hätte.

Was mich am meisten irritiert ist, dass ich in der Telefonie-Konfiguration als STUN-Server stun.sipgate.net:10000 angegeben habe und die FBF diese Angaben anscheinend völlig ignoriert.

Dank deiner ausgezeichneten Erklärungen verstehe ich jetzt, was falsch läuft. Allerdings scheint dieses Wissen noch immer nicht auszureichen, VoIP zum Laufen zu bringen. Ich werde aber mal weiter versuchen.

Viele Grüße
Charley

charley · 18 Okt 2005

Portforwarding intern->extern bei X1200

Hi,

das mit dem Portforwarding von intern nach extern funktioniert nicht so, wie ich mir das vorstelle:

Ich habe als Protokoll udp angegeben und als Remote Port, External Port ind Internal Port jeweils 5060. Interne Adresse ist die Adresse meiner FBF. Trotzdem verwendet mein X1200 bei ausgehenden Connections von Port 5060 als externen Port eine Portnummer im 30000er-Bereich und an die schickt sipgate dann die Response.

Irgendwie muss ich doch den X1200 zwingen können, als externen Post 5060 zu verwenden?

Gruß
Charley

RB · 18 Okt 2005

Moin!

Also bei mir funktioniert das seit dieser Maßnahme gut. Ich hänge mal einen Screenshot von PuTTY an, in dem eine solche Einstellung bei mir zu sehen ist.

Im Gegensatz zu Dir habe ich den Remote Port nicht spezifiziert. Eventuell liegt da der Hund im Pfeffer, oder so ähnlich.

charley · 19 Okt 2005

NAT von intern nach extern

Hi,

Im Gegensatz zu Dir habe ich den Remote Port nicht spezifiziert. Eventuell liegt da der Hund im Pfeffer, oder so ähnlich.

@Ralf
Du hast recht. So funktioniert es. Jetzt registriert sich die FBF bei allen VoIP-Accounts und bleibt auch über den ganzen Tag registriert.

Bei deinem Screenshot fiel mir auf, dass du das NAT dem Interface EN3 zugeordnet hast. Ich habe das NAT immer dem Interface 1000x (1&1 DSL) zugeordnet. Ist da ein wesentlicher Unterschied, ob ich das NAT auf dem physikalischen Interface EN3 oder auf dem logischen Interface 1000x zuordne?

Auswärtsgespräche funktionieren jetzt auch.

Einkommende Gespräche für 1&1-Accounts funktionieren auch. Andere einkommende Gespräche werden jedoch nicht entgegengenommen. Der Grund hierfür ist etwas seltsam:

Code:

Incoming Calls for ...

MESSAGENET.IT:
20:23:57 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.5.112:5060/84.162.4.112:5060 <- 212.97.59.76:5061
20:23:57 DEBUG/INET: new session, 212.97.59.76:5061->94.178.5.112:5060 prot: 17parent: false
20:23:57 DEBUG/INET: SIF: No Rule ignore  212.97.59.76:5061 -> 94.178.5.112:5060 Proto:17
20:24:08 DEBUG/INET: TIMEOUT Session expired: 10.50.1.6:138->10.50.1.255:138 prot=17
20:24:08 DEBUG/INET: destroy session, 10.50.1.6:138->10.50.1.255:138 prot: 17
20:24:08 DEBUG/INET: destroy session, 10.50.1.255:138->10.50.1.6:138 prot: 17


SIPGATE.DE:
20:26:00 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.5.112:5060/84.162.4.112:5060 <- 217.10.79.9:5060
20:26:00 DEBUG/INET: new session, 217.10.79.9:5060->94.178.5.112:5060 prot: 17 parent: false
20:26:00 DEBUG/INET: SIF: No Rule ignore  217.10.79.9:5060 -> 94.178.5.112:5060Proto:17
20:26:38 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 94.178.5.112:5060/84.162.4.112:5060 <-> 217.10.79.9:5060
20:26:38 DEBUG/INET: TIMEOUT Session expired: 217.10.79.9:5060->94.178.5.112:5060 prot=17
20:26:38 DEBUG/INET: destroy session, 217.10.79.9:5060->94.178.5.112:5060 prot:17
20:26:38 DEBUG/INET: destroy session, 94.178.5.112:5060->217.10.79.9:5060 prot:17


SIPGATE.CO.UK
20:30:27 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.5.112:5060/84.162.4.112:5060 <- 217.10.79.219:5060
20:30:27 DEBUG/INET: new session, 217.10.79.219:5060->94.178.5.112:5060 prot: 17 parent: false
20:30:27 DEBUG/INET: SIF: No Rule ignore  217.10.79.219:5060 -> 94.178.5.112:5060 Proto:17
20:30:36 DEBUG/INET: NAT: delete session on ifc 10002 prot 17 10.50.1.83:5060/84.162.4.112:5060 <-> 212.227.15.197:5060
20:30:36 DEBUG/INET: TIMEOUT Session expired: 10.50.1.83:5060->212.227.15.197:5060 prot=17
20:30:36 DEBUG/INET: destroy session, 10.50.1.83:5060->212.227.15.197:5060 prot: 17
20:30:36 DEBUG/INET: destroy session, 212.227.15.197:5060->10.50.1.83:5060 prot: 17


10.50.1.83:        FBF
84.162.4.112:    External IP

212.97.59.76:    messagenet.it
217.10.79.9:     sipgate.de
217.10.79.219: sipgate.co.uk

94.178.5.112:  ??????

Wenn ein Gespräch sich anmeldet, wird eine Incoming Connection versucht aufzubauen. Die Destination-IP ist jedoch in allen Fällen eine IP, die in unserem Netz völlig unbekannt ist und mit der IP der FBF nichts zu tun hat. Selbstverständlich wird diese Connection abgewiesen, so dass es nicht zur Annahme des Calls kommen kann.

Da scheint doch die FBF bei der Registrierung eine falsche IP-Adresse weiterzugeben. Oder woher kann diese sonst kommen?

Viele Grüße
Charley

RB · 20 Okt 2005

charley schrieb:
Bei deinem Screenshot fiel mir auf, dass du das NAT dem Interface EN3 zugeordnet hast. Ich habe das NAT immer dem Interface 1000x (1&1 DSL) zugeordnet. Ist da ein wesentlicher Unterschied, ob ich das NAT auf dem physikalischen Interface EN3 oder auf dem logischen Interface 1000x zuordne?

Ich habe keinen Einwahl-Anschluß (DSL oder ISDN), daher gibt es bei mir auch kein logisches Interface 1000x. Mein Router hängt an einem Kabelmodem (ish) und bekommt seine IP-Adresse über DHCP (also kein PPPoE o.ä.)

Zu der merkwürdigen IP-Adresse:

Das gleiche Phänomen ist mir schon bei Deinem ersten Logauszug aufgefallen. Ich habe es nur erstmal ignoriert, weil die anderen Sachen sowieso vorrangig zu lösen waren. Hier mal den Auszug aus dem ersten Debug, darunter aus dem neuen Debug...

07:44:25 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.51.74:5060/84.162.50.74:5060 <- 212.227.15.197:5060

20:23:57 DEBUG/INET: NAT: new incoming session on ifc 10002 prot 17 94.178.5.112:5060/84.162.4.112:5060 <- 212.97.59.76:5061

Da scheint aber ein System drin zu sein: Die Differenz zwischen echter externer IP-Adresse und der mysteriösen anderen Adresse ist wohl konstant, und zwar 10.16.1.0 :shock:

Eine echte Erklärung dafür kann ich allerdings erstmal nicht geben. Da müsste man wohl noch ein paar Experimente anstellen.

Ich würde jetzt mal eine Versuchsreihe starten, mit unterschiedlichen Anrufquellen, soweit möglich. Vielleicht lässt sich da ein System finden. Z.B. Anrufe vom Festnetzt oder von einem anderen VoIP-Teilnehmer, vielleicht noch einen weiteren Provider versuchen, ...

Da kann man erstmal nur die Phantasie spielen lassen :roll:

charley · 20 Okt 2005

Seltsame interne IP

Hi,

ich habe jetzt mehrere Versuche gemacht.

Egal, welcher VoIP-Account angewählt wird: das Ergebnis ist das selbe. Tatsächlich ist die Differenz zwischen der aktuellen externen Adresse und der angewählten "seltsamen" internen Adresse immer 10.16.1.0. Das Problem hat also nichts mit dem VoIP-Provider zu tun.

Bei einigen Anwählversuchen war es möglich, eingehende Gespräche entgegenzunehmen. Dann wurde zwar auch ein incoming call auf die "seltsame" IP abgewiesen; kurz darauf wurde aber eine Anfrage auf Port 53 an den VoIP-Server geschickt und dann eine outgoing session aufgebaut.

Viele Grüße
Charley

hubbelpink · 21 Okt 2005

hallo,
ich bin zwar kein Profi aber vielleicht hilft dir das weiter:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=28299&highlight=

Inzwischen hab ich auch feste IP´s vergeben. Das hatte vorher nie hingehauen. Vielleicht müssen sie aus dem Adressbereich 192.168.181... sein , da der LAN A der FB den Adressbereich 192.168.181.2-250 hatt, oder gilt das nur für DHCP ?
Fritzbox : 192.168.181.2 Gateway Und DNS Server 192.168.181.3
Draytek : 192.168.181.3

Gateway bei beiden Routern und PC`s 192.168.181.3
Statusinformationen über UPN hab ich wieder aktiviert.
so funktioniert es jedenfalls bei mir

charley · 21 Okt 2005

Adressbereich der FBF

Hi,

in unserem Netz hat die FBF die IP 10.50.1.83 und der Router X1200 hat die 10.50.1100. Dies ist in der FBF-Konfiguration so eingegeben und das funktioniert ja in den meisten Bereichen inzwischen problemlos.

Ich habe schon die ar7.cfg und die voip.cfg der FBF durchkämmt aber keine Hinweise darauf gefunden, woher meine "seltsame" IP-Adresse kommen könnte.

Bei der Registrierung der FBF beim VoIP-Provider ist der Aufbau einer incoming session notwendig; dies funktioniert jetzt; die session wird korrekt zur FBF geroutet. Bei einem eingehenden Telefonat wird ebenfalls vom gleichen Provider mit den gleichen Registrierungsdaten eine incoming session angefordert. Und bei dieser stimmt die interne Adresse nicht mit der Folge, dass die session nicht zur FBF geroutet wierden kann.

Viele Grüße
Charley

@hubbelpink
Wäre es möglich, dass du deine Konfiguration im Profil angibst?

RB · 21 Okt 2005

@charley
Hast Du die Möglichkeit auf irgendeine Weise einen Mitschnitt einer Registrierung und eines Anrufs von extern zu machen? Ich weiß nicht genau, ob die FBF solche Möglichkeiten hat. Ggf könnte man Ethereal oder ähnliche Tools einsetzen.

Es dreht sich um die Inhalte der SIP-Telegramme. Vielleicht findet sich ja dort ein Hinweis. Es wäre wichtig zu wissen, ob die mysteriöse IP-Adresse im REGISTER vielleicht irgendwie von der FBF mitgeschickt wird. Wenn sie denn tatsächlich von außen kommt!

Wobei ich mich allerdings frage, wie das möglich ist. Ein UDP-Paket hat nur genau eine IP-Zieladresse. Es wäre also höchstens denkbar, daß das Paket auf der Ethernet-Schicht die Ethernet-Adresse (MAC-Adresse) des Routers als Ziel eingetragen hat, aber auf der IP-Schicht dann die "Geister"-Adresse :shock:Ein höchst unwahrscheinliches Szenario! Die andere, noch weitaus unerfreulichere Erklärung wäre, daß der Bintec eine Fehler macht :?

Wenn die IP-Adresse konstant wäre, gäbe es evtl noch eine mögliche Erklärung - wenn die en3 womöglich noch eine weitere IP-Adresse konfiguriert hätte. Aber ich wüsste nicht, wie ich das zu einem Offset führen sollte...

==> Eventuell sollte man vor dem Bintec einen Hub plazieren und über den dann per Ethereal alles mithorchen.

charley · 23 Okt 2005

Seltsame interne Adresse

Egal, welcher VoIP-Account angewählt wird: das Ergebnis ist das selbe. Tatsächlich ist die Differenz zwischen der aktuellen externen Adresse und der angewählten "seltsamen" internen Adresse immer 10.16.1.0. Das Problem hat also nichts mit dem VoIP-Provider zu tun.

Nach jetzt sehr vielen Versuchen hat sich gezeigt, dass neben der Adressdifferenz 10.16.1.0 auch mit etwa gleicher Häufigkeit die Differenz 10.16.0.0 auftaucht. Diese Differenz bleibt gleich, solange die externe IP gleich bleibt. Erst bei neuer Einwahl und Zuteilung einer neuen externen IP ändert sich manchmal diese Adressdifferenz.

Freundliche Grüße
Charley

charley · 24 Okt 2005

Net-Scanner

Hi,

ich habe bisher mit meiner 3Com-Karte und dem Programm Network Activ PIAFCTM alle Pakete im Netz scannen können. Seit dem Austausch des Mainboards und dem Einsatz eines SiS900-NIC funktioniert es nicht mehr. Der NIC ist offenbar nicht im promiscuous mode. Der SiS900 beherrscht ihn gemäß Specifikation zwar, ich weiß aber nicht, wie ich diesen Mode unter Win2k aktivieren kann.

Gruß
Charley

RB · 25 Okt 2005

Moin!

Das ist natürlich blöd!

Vielleicht kann die FBF sowas? Da müsste sich mal einer der Spezis zu äußern. Ich könnte mir denken, daß man darauf sowas wie tcpdump laufen lassen kann.

BrownEyes · 6 Okt 2006

Mit großem Interesse habe ich diesen Thread gelesen und habe es geschafft dass sich meine FritzBox registriert.
Ich kann jetzt auch schon Leute anrufen, aber ich kann niemanden hören.
Laut GMX-FAQ muss man einige Ports freischalten. Das habe ich nach bestem Wissen gemacht, trotzdem kann ich niemanden hören.

Viel. hat noch jemand eine Idee. Hier meine Konfiguration:
Bintec-Router X1200
FritzBoxFonWlan

Bei einem Debug auf dem Router sehe ich folgenden Output:

Code:

HRS68:> debug -t all
10:32:39 DEBUG/INET: NAT: delete session on ifc 10001 prot 50 213.157.26.85:0/213.157.26.85:0 <-> 193.26.194.12:0
10:32:39 DEBUG/INET: NAT: delete session on ifc 10001 prot 50 213.157.26.85:0/213.157.26.85:0 <-> 193.26.194.12:0
10:32:40 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.102.100:5060/213.157.26.85:5060 -> 212.227.15.200:3478
10:32:40 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.102.100:7078/213.157.26.85:33951 -> 212.227.15.200:3478
10:32:40 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.102.100:7079/213.157.26.85:33952 -> 212.227.15.200:3478
10:32:40 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.102.100:5060/213.157.26.85:5060 -> 212.227.15.197:5060
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972
10:32:41 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 213.157.26.85:33951 <- 62.53.226.11:16972

Telefonieren kann ich, nur nichts hören.
Das Freischalten der Port 30.000 bis 50.000 verhindert zwar die Meldung refused incoming session, behebt aber nicht das Problem.
Gruß
Patrick

Problem mit FBF WLAN hinter Bintec X1200

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Anhänge

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Statistik des Forums