… ich bin grade etwas unentspannt. Ich habe zwei SpeedPort W900V, umgefritzt auf (GT) Firmware-Version 29.04.70 bzw. (B) 29.04.80. Gut, vielleicht nicht ganz die Verwendung, wie Gott AVM sie vorsah, aber notfalls hätte ich auch zwei »echte« 7170 da, um den Gegenbeweis anzutreten, daß es nicht an der Hardware/Hardware-mit-nicht-vorgesehener-Software liegt …
Die FB GT ist von der Firmware erweitert, auf ihr läuft nämlich u. a. noch Asterisk und OpenVPN. Über OpenVPN hält sie (über T-VDSL, worüber ein Tunnel ins DC läuft) einen Tunnel zu einem Server in einem DataCenter aufrecht. Über diesen Tunnel werden Pakete zur FB B geroutet:
# traceroute 193.26.120.30 traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets 1 192.168.44.9 (192.168.44.9) 42.956 ms 43.792 ms 46.191 ms 2 dockstar-4.vpn.uu.org (192.251.226.178) 201.827 ms 203.244 ms 199.464 ms 3 dhcp-14.berlin.uu.org (193.26.120.30) 215.253 ms 204.320 ms 201.604 ms
Der Rückweg funktioniert auch:
# traceroute 192.168.44.8 traceroute to 192.168.44.8 (192.168.44.8), 30 hops max, 38 byte packets 1 gw.berlin.uu.org (193.26.120.17) 0.878 ms 0.603 ms 0.562 ms 2 gw-dockstar-4.vpn.uu.org (192.251.226.177) 166.290 ms 158.050 ms 169.237 ms 3 192.168.44.8 (192.168.44.8) 199.720 ms 191.813 ms 199.749 ms
Die Hardware in B ist einfacher, derzeit der umgefrizte SpeedPort, der an einem Linux-Server (Seagate DockStar unter UBIFS-Debian-Lenny) mit USB-3G-Modem (Huawei E160) hängt. Der DockStar macht DHCP sowie hält einen OpenVPN-Tunnel zum besagten Rechner in einem DC:
# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.251.226.254 193.26.120.17 255.255.255.255 UGH 0 0 0 lan 195.71.106.44 193.26.120.17 255.255.255.255 UGH 0 0 0 lan 193.26.120.16 0.0.0.0 255.255.255.240 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 193.26.120.17 0.0.0.0 UG 0 0 0 lan
Bei der FritzBox in GT ist das etwas komplexer:
# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.44.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 192.0.2.46 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.251.226.30 192.168.5.2 255.255.255.255 UGH 0 0 0 lan 192.251.226.176 192.168.44.9 255.255.255.252 UG 0 0 0 tun1 192.0.2.40 192.0.2.46 255.255.255.248 UG 0 0 0 tun0 193.26.120.16 192.168.44.9 255.255.255.240 UG 0 0 0 tun1 192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 lan 192.168.44.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1 192.168.45.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1 192.0.2.0 192.0.2.46 255.255.255.0 UG 0 0 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan 0.0.0.0 192.168.5.253 0.0.0.0 UG 0 0 0 lan
Tja; eigentlich hängt die FB B als SIP-Nebenstelle an der FB GT. Nur leider funktioniert bei der Kommunikation weder bei Rufaufbau von der FB B über die FB GT ins D2-Netz (über T-ISDN an FB GT) noch bei der Anwahl der MSN der FB GT, die für den SIP-Client der FB B reserviert ist, die Tonkommunikation von FB GT zu FB B; alles, was vom DECT-Mobilteil der FB B gesendet wird, kann auf der anderen Seite des Anrufs der FB GT empfangen werden …
Ton kommt also nur, egal, in welche Richtung der Verbindungsaufbau stattfindet, von FB B zur FB GT durch. Man davon abgesehen, daß die IP-Adresse, von der aus die SIP-Pakete verschickt werden, etwas zufällig scheint (die Konfiguration wurde entsprechend angepaßt), fällt im tcpdump auf dem Tunnelterminator in der Mitte folgendes auf:
23:43:33.525597 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1098 23:43:33.587540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 422 23:43:33.827940 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 387 23:43:33.998078 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259 23:43:34.136540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 325 23:43:34.144963 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856 23:43:34.147179 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.151491 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.183467 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.215715 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.240745 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.273582 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.333663 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.384559 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.411361 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.440857 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.473160 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.503695 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.528700 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259 23:43:34.529783 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.561528 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252 23:43:34.574796 IP 193.26.120.30 > 192.168.44.8: icmp 288: 193.26.120.30 udp port 7078 unreachable 23:43:34.604628 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856
Sprich: FB GT möchte die FB B auf UDP Port 7078 ansprechen, bei FB B lauscht da aber schein’s nixe. Das würde dann auch erklären, warum kein Ton von FB GT zur FB B geht … Was ich aber auch überhaupt nicht ralle: warum sind da keine UDP-Pakete von der 193.26.120.30 (FB B) zur 192.168.44.8 (FB GT)? Einen Routingfehler kann ich eigentlich ausschließen:
dockstar-4:~# ip route show 10.64.64.64 dev ppp0 proto kernel scope link src 10.171.175.224 192.251.226.177 dev azrael proto kernel scope link src 192.251.226.178 192.251.226.30 dev ppp0 scope link 193.26.120.16/28 dev eth0 proto kernel scope link src 193.26.120.17 193.26.120.0/24 via 192.251.226.177 dev azrael 192.251.226.0/24 via 192.251.226.177 dev azrael 192.168.0.0/16 via 192.251.226.177 dev azrael 0.0.0.0/1 via 192.251.226.177 dev azrael 128.0.0.0/1 via 192.251.226.177 dev azrael default dev ppp0 scope link
Irgendwie macht das alles keinen Spaß *sigh*.