Liebe AVM, …

… 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*.