Standortvernetzung mit Fritzbox VPN – zu viel verlangt? (Updated)

So übermäßig anspruchsvoll ist es eigentlich gar nicht, was ich versuche. Es geht um eine ganz normale Vernetzung von verschiedenen Standorten per VPN. Allerdings soll aus $Gründen eine Vernetzung über die VPN-Funktionalität der Fritzboxen (IPsec) stattfinden, nicht (mehr) über z. B. OpenVPN. Zu diesem Zweck sollten die Fritzboxen die PPPoE-Session terminieren/direkten Internetzugang haben (sonst ist das mit IPsec ggf. Essig).
Im Prinzip tut das bei AVMs Fritzboxen auch schnuckelig – zumindest, was die direkt verbundenen Netze angeht. Mein aktuelles Problem: die Verbindung 7270 (Berlin) zu 7570 (Gütersloh) funktioniert, auch von den angeschlossenen Netzen; von einem komischeen Effekt des Fritz-IPsec-VPNs abgesehen — die Antworten kommen immer von der Ziel-IP. Aber im Prinzip funktioniert’s:

(VoIP-Fritzbox in GT) # traceroute greebo.berlin.uu.org
traceroute to greebo.berlin.uu.org (193.26.120.116), 30 hops max, 38 byte packets
1 192.168.5.245 (192.168.5.245) 11.873 ms 0.912 ms 0.612 ms
2 FB-DSL-GTSO.uu.org (192.168.177.1) 2.016 ms 1.029 ms 0.919 ms
3 greebo.berlin.uu.org (193.26.120.116) 62.780 ms 65.228 ms 58.857 ms
4 greebo.berlin.uu.org (193.26.120.116) 60.892 ms 83.577 ms 59.314 ms
5 greebo.berlin.uu.org (193.26.120.116) 59.414 ms 80.942 ms 59.454 ms
wusel@greebo.berlin.uu.org:~$ traceroute 192.168.5.229
traceroute to 192.168.5.229 (192.168.5.229), 64 hops max, 40 byte packets
1 gw.berlin.uu.org (193.26.120.113) 0 ms 0 ms 0 ms
2 fritz.box (192.168.178.1) 1 ms 1 ms 1 ms
3 FB-7170-1.uu.org (192.168.5.229) 74 ms 59 ms 59 ms
4 FB-7170-1.uu.org (192.168.5.229) 62 ms 59 ms 61 ms
5 FB-7170-1.uu.org (192.168.5.229) 74 ms 60 ms 59 ms

Was derzeit aber nicht funktioniert, ist die zweite Verbindung an der 7570, also die der 7170 im Office mit der 7570 zu Hause:

(VoIP-Fritzbox in GT) # traceroute 192.168.45.25
traceroute to 192.168.45.25 (192.168.45.25), 30 hops max, 38 byte packets
1 192.168.5.245 (192.168.5.245) 0.816 ms 0.616 ms 0.615 ms
2 FB-DSL-GTSO.uu.org (192.168.177.1) 1.174 ms 1.065 ms 1.160 ms
3 HP4050N.sld.tld (192.168.45.25) 76.193 ms 76.462 ms 75.250 ms
4 HP4050N.sld.tld (192.168.45.25) 107.226 ms 78.095 ms 101.281 ms
(FB 7170 im Office) # traceroute -m 8 192.168.5.229
traceroute to 192.168.5.229 (192.168.5.229), 8 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *

Verbinden zur 7170 kann ich mich, auch aus den hinter der 7570 liegenden Netzen. Aus dem Office allerdings: Pustekuchen. Konsequenterweise geht auch die SIP-Registrierung der Office-FB an meiner VoIP-FB nicht, was einerseits Sinn der Übung war und dafür spricht, daß der Traffic nicht durchgelassen wird. Nur: wo wird das geblockt‽ Ich sehe jetzt den Wald vor lauter Bäumen nicht mehr – oder die 7170 ist grundlegend anders als die 72er-Serie (7570 ist 7270+VDSL-Modem). Auch der Versuch, nur 1 VPN in der 7570 zu definieren (7170-7570) änderte nichts am Verhalten, sodaß ich davon ausgehe, daß es damit nichts zu tun hat. Plöd, das; die erste Verbindung war richtig flott aufgesetzt, langwierig war nur, das Konfigurationsprogramm mit WINE an den Start zu bekommen.
Vielleicht sieht ja wer einen/den(?) offensichtlicht(??) Fehler – aus der VPN-Konfiguration der 7170:

 phase2localid {
ipnet {
ipaddr = 192.168.45.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.177.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.177.0 255.255.255.0",
"permit ip any 192.168.5.0 255.255.255.0";

Die 7570 hat für jene Verbindung:

 phase2localid {
ipnet {
ipaddr = 192.168.177.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.45.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.45.0 255.255.255.0"; 

Nachtrag, 2012-02-27, 21:30: Nach längerem Suchen habe ich eine erste Verbindung zu einem StrongSwan auf Debian Lenny von der 7170 hinbekommen — und ich glaube, die Nebel lichten sich langsam: die 7170 scheint per VPN mit der 169.254.2.1 rauszugehen, die sie auf dem DSL-Interface aus mir unbekannten Gründen konfiguriert hat; tcpdump -n -i eth0 zeigt auf dem Server im RZ:
21:24:18.526026 IP 169.254.2.1 > 192.251.226.129: ICMP echo request, id 9222, seq 1, length 64
21:24:18.530029 IP 169.254.2.1 > 192.251.226.129: ICMP echo request, id 9222, seq 2, length 64

Und das paßt auch zur Interfacekonfiguration auf der 7170:

dsl Link encap:Point-to-Point Protocol
inet addr:169.254.2.1 P-t-P:169.254.2.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:17440 errors:0 dropped:0 overruns:0 frame:0
TX packets:17445 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1450267 (1.3 MiB) TX bytes:1845896 (1.7 MiB)
lan Link encap:Ethernet HWaddr 00:15:0C:XX:XX:XX
inet addr:192.168.5.229 Bcast:192.168.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:514615 errors:0 dropped:0 overruns:0 frame:0
TX packets:57351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:87867018 (83.7 MiB) TX bytes:15078398 (14.3 MiB)
lan:0 Link encap:Ethernet HWaddr 00:15:0C:XX:XX:XX
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

Diese Box macht »Internet über LAN1« und dort dann PPPoE, den Alice-IAD als DSL-Modem mißbrauchend. Aber die »7570« (ok, ich habe etwas geschwindelt: noch ist es ein Speedport 300HS und ein Speedport W530V, auf 7240 gefrizt; der W920V mit 7570-Firmware liegt noch »bei der IT zur Konfiguration«, sprch: ich teste den noch und übertrage die Konfiguration händisch) nutzt ebenfalls PPPoE über LAN1 (wo ein VDSL-Modem hängt), sieht aber gänzlich anders aus:

dsl Link encap:Point-to-Point Protocol
inet addr:192.168.177.1 P-t-P:192.168.177.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:4890641 errors:0 dropped:0 overruns:0 frame:0
TX packets:2489927 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1675787479 (1.5 GiB) TX bytes:333784871 (318.3 MiB)
lan Link encap:Ethernet HWaddr 00:1A:4F:XX:XX:XX
inet addr:192.168.177.1 Bcast:192.168.177.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:2544270077 errors:0 dropped:0 overruns:0 frame:0
TX packets:381956968 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1403890285 (1.3 GiB) TX bytes:2941953283 (2.7 GiB)
lan:0 Link encap:Ethernet HWaddr 00:1A:4F:XX:XX:XX
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

WTF‽ Weitere Vergleiche ergaben entsprechende Einträge in der ar7.cfg:

 dslinterface {
name = "dsl";
dhcp = no;
- ipaddr = 169.254.2.1;
- netmask = 255.255.255.255;
- dstipaddr = 169.254.2.1;
+ ipaddr = 0.0.0.0;
+ netmask = 0.0.0.0;
+ dstipaddr = 0.0.0.0;
dhcpenabled = yes;
dhcpstart = 0.0.0.0;
dhcpend = 0.0.0.0;
+ no_dnsd_static = no;
}

Fragt sich nur, wo das herkommt, richtig SInn macht es nicht. Vielleicht einmal zu selten den Factory-Reset ausgeführt? Narf, das hat mich jetzt sicher einen Tag am Wochenende gekostet\:-(
Nachtrag, 2012-02-27, 23:30: So, nach einem Abstecher zur dann doch noch abgeschossenen Fritzbox – die Einstellung von 192.168.45.1/255.255.255.0 auf dem DSL-Interface in der ar7.cfg war dann doch zu viel des Guten, die FB mochte zwar noch eine Verbindung aufbauen, nur routen, das war jetzt out –, tut es nun, wie es soll (fast, bis auf das komische ICMP-Handling):

wusel@death:~$ traceroute 192.168.45.25
traceroute to 192.168.45.25 (192.168.45.25), 64 hops max, 40 byte packets
1 albert.uu.org (192.251.226.33) 0 ms 0 ms 0 ms
2 FB-DSL-GTSO.uu.org (192.168.177.1) 1 ms 0 ms 0 ms
3 HP4050N.sld.tld (192.168.45.25) 73 ms 70 ms 71 ms
4 HP4050N.sld.tld (192.168.45.25) 81 ms 76 ms 75 ms
(FB 7170 im Office)# traceroute death.uu.org
traceroute to death.uu.org (192.251.226.52), 30 hops max, 38 byte packets
1 death.uu.org (192.251.226.52) 85.860 ms 76.241 ms 72.894 ms
2 death.uu.org (192.251.226.52) 73.421 ms 74.253 ms 72.283 ms
3 death.uu.org (192.251.226.52) 75.041 ms 81.484 ms 74.811 ms

Scjön ist anders … und mein VoIP-Problem, was ich seinerzeit (um 2009) hatte mit falschen Absende-IPs könnte auch an diesem komischen Eintrag für »dsl« gelegen haben. Naja, sei’s drum; erst einmal funktioniert die Kopplung per SIP zwischen den Fritzboxen, das was das Ziel.
Was noch nicht richtig funzt ist die Verbindung zu StronSwan:

# traceroute 192.251.226.129
traceroute to 192.251.226.129 (192.251.226.129), 30 hops max, 38 byte packets
1 * * *
2 gw.mobile.uu.org (192.251.226.129) 43.732 ms 36.009 ms 35.763 ms

Allerdings klappt der Verbindungsaufbau bislang nur vom Server im DC, ein /etc/ipsec.conf und Hinweise, was in die /etc/ipsec.secrets zu schreiben ist bei einer Fritzbox mit dynamischer IP (und DynDNS-Eintrag zu jenem) wäre sehr willkommen.
(Und, ernsthaft, daß dieses IPsec-Geraffel keine Interfaces mitbringt und somit auch keine sauberen Routen verfügbar sind, ist schon ziemlich doof. Schon auf der Fritzbox fand ich es nervig, keinen Einblick zu haben, aber unter »normalem Linux« ist das ja auch nicht besser. »ipsec status all« ist auch nur ein schwacher Trost:

000 "fb-office": 192.251.226.128/28===195.xx.xx.xx @host.sld.tld @fb-office.dyn.sld.tld erouted; eroute owner: #4
000 "fb-office": ike_life: 14400s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "fb-office": dpd_action: hold; dpd_delay: 30s; dpd_timeout: 75s;
000 "fb-office": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 28,24; interface: eth0:5;
000 "fb-office": newest ISAKMP SA: #3; newest IPsec SA: #4;
000 "fb-office": IKE algorithms wanted: 7_128-2-2,
000 "fb-office": IKE algorithms found: 7_128-2_160-2,
000 "fb-office": IKE algorithm newest: AES_CBC_256-SHA-MODP1024
000 "fb-office": ESP algorithms wanted: 12_128-2,
000 "fb-office": ESP algorithms loaded: 12_128-2_160,
000 "fb-office": ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<Phase1>
000
000 #4: "fb-office" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3153s; newest IPSEC; eroute owner
000 #4: "fb-office" ah.c7cf3de0@78.xx.xx.xx ah.cf02ba84@195.xx.xx.xx esp.46e496b1@78.xx.xx.xx (198 bytes, 84s ago) esp.a1010464@195.xx.xx.xx (228 bytes, 84s ago) comp.69bb@78.xx.xx.xx comp.1fba@195.xx.xx.xx; tunnel
000 #3: "fb-office" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3152s; newest ISAKMP; DPD active

Irgendwie finde ich OpenVPN, auch wenn es »nur« ein SSL-VPN ist, mehr denn je cooler, einfacher und flexibler — von der Möglichkeit, über TCP und/oder durch Proxies zu gehen, mal ganz abgesehen. Aber jetzt habe ich Blut geleckt und würde gerne eine Verbindung Fritz<>StrongSwan hinbekommen — and Hits are appreciated! Als Kür möchte ich dann das Ganze auf den gleichen Rechner, wo schon der L2TP/IPsec-Kram mit OpenSwan läuft, umziehen. (Wahrscheinlich wegen des %any landete da aber die Fritzbox-Verbindung immer in einem L2TP-Korsett, was wohl Windows und Android so machen, Fritzboxen aber nicht. Wenn ich daran denke, wird mir auch schwindelig; da nutzt man ggf. L2TP, PPP und IPsec über DSL, was in sich schon PPPoE und Ethernet auf ATM-Basis ist. Frage mich, wie viele VPN-Tunnel verschachteln kann, bis die MTU auf 8 geschumpft ist ;-))

Alice (Spharion) IAD 3231 durch Fritzbox ersetzt – und es ward' Licht!

Vor knapp drei Jahren wunderte und ärgerte ich mich schon einmal über Alice’ IAD, was mich ein Jahr später in Berlin ja dennoch nicht davon abhielt, den Zukauf meines schon damals Ex-Brötchengebers als DSL-SP zu nehmen.
Im Zuge der IPsec-Ver-VPN-ung allerdings mußte nun ich ein weiteres Mal feststellen, daß vom ISP gestellte Hardware nicht zwingend das Kundeninteresse wiederspiegelt. IPsec von der FB in der Praxis jedenfalls schaffte es nicht zur bei T-Entertain beheimateten Fritzbox. Und so zog ich los auf eine weitere Google-Odyssee, um letztlich das IAD zum DSL-Modem und NTBA zu degradieren (NGN-Anschluß => Telefonie ist VoIP, und bei Hansenet/Alice geht das nur mit deren Hardware). Und es hätte auch alles remote klappen können – wenn, ja wenn, nicht Alice schon 2009 einen groben Fehler gemacht hätte und die Alice-Office-Einwahldaten mit @alice-dsl.de-Kennung kommuniziert hätte — statt @alice-office-dsl.de, wie schon damals erst per telefonischer Rückfrage rauskam. Nach einer Stunde des Haareraufens, innerlichen Fluchens und Wunderns, warum PPPoE-Passthru bei den ganzen Forenbewohnern angeblich “einfach so” klappte.dämmerte es mir endlich: War da nicht was mit den Einwahldaten, hatte Alice da nicht Scheiße verschickt? Und so war es dann auch.
Alice’ IAD 3231 ist jetzt nur noch NGN-NTBA (terminiert Alice’ ISDN-Offerte) und DSL-Modem – nach vormals schon Telefonie ist nun endlich auch für IP einzig die FritzBox zuständig — und wie durch Geisterhand klappen auch wieder Tracees (s. zum Vergleich das Posting aus 2009):

# traceroute blogdoch.net
traceroute to blogdoch.net (192.251.226.27), 30 hops max, 38 byte packets
1 lo1.br61.dus.de.hansenet.net (213.191.64.40) 27.489 ms 27.104 ms 26.755 ms
2 ae1-252.pr50.dus.de.hansenet.net (62.109.68.129) 27.809 ms 26.328 ms 27.206 ms
3 rmwc-dsdf-de02-xe-0-1-3-0.nw.mediaways.net (195.71.243.245) 33.944 ms 33.660 ms 33.854 ms
4 rmwc-gtso-de02-ge-0-0-0-0.nw.mediaways.net (195.71.254.45) 33.595 ms 35.234 ms 33.765 ms
5 xmws-gtso-de11-vlan-2.nw.mediaways.net (195.71.10.195) 34.874 ms 34.455 ms 34.019 ms
6 195.71.109.220 (195.71.109.220) 34.867 ms 35.638 ms 34.066 ms
7 blogdoch.net (192.251.226.27) 34.271 ms 34.339 ms 34.033 ms

Da nun die Fritzbox PPPoE spricht, gibt’s auch so interessante Infos wie daß hier noch immer QSC statt Telefonica als DSL-Lieferant verwendet wird (gut, darauf deutet auch der erste Hop in Düsseldorf statt Gütersloh/Bielefeld hin):

25.02.12 19:09:43 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 78.xx.xx.xx, DNS-Server: 213.xx.xx.xx und 62.xx.xx.xx, Gateway: 213.xx.xx.xx, Breitband-PoP: bsn.qsc

So richtig ist Alice doch noch nicht bei o2 angekommen :-)

Kundenbindung á la o2 (Alice)

Ist schon super. o2 sendet mir Werbemails, aber auf die eine Aktion, die mich interessiert hätte, die ‘Community Flat’, da stolpere ich erst zufällig und zu spät drüber — wenige Wochen zu spät, aber ausreichend zu spät, als das Alice es nicht mehr und o2 nur mit rd. 10 EUR/Monat teurerem DSL-Vertrag anbietet. Super.

Statt also mit Frau und K1 (beide von mir ins o2-Netz gezogen) von meinem Berliner Alice-Anschluß und meinen Alice- und o2-Postpaid-SIMs kostenlos telefonieren zu können, was ja ein echter Bindungsfaktor wäre, gibt’s nix. Nicht ohne 10,– mehr zu bezahlen an o2 für die identische Alice-Leistung (16 MBit plus ISDN); ggf. sogar schlechtere Leistung, falls o2 mich auf NGN umstellte (=> keine Nutzung meiner Fritzbox als Modem mehr, also auch keine Kontrolle der Einwählen und Bandbreite). Gewagtes Spiel bei Verträgen ohne Laufzeit (DSL wie Mobilfunk), finde ich …

Post im 20,5ten Jahrhundert

-1049550818

Packstation ist – bislang – cool, und DHL ist weiterhin schnell, 1 Tag für ein normales Päckchen durch die Republik ist mehr als ok.

Kürze wäre jetzt, wenn man statt eines Ortes ‘98765 Fernauswahl’ angeben und ein Paket an einen beliebigen Ort mit Packstation – oder gar eine Straßenadresse – umleiten könnte. Einziges Hindernis – die Adressenlesesysteme sollten ja in der Lage sein, ein Pattern durch einen anderen Wert zu ersetzen, der aus einer Datenbank stammt – dürfte die finale Auslieferung sein: für den humanoiden Zusteller muß/sollte wohl eine konkrete Adresse auf dem Päckchen stehen (wobei das durch Scanner auch ersetzt werden könnte).

DHL, are you listening?

Geolocation …

(Blogged via flickr)

… ist auch so eine Geschichte voller Mißverständnisse. Warum zum Beispiel das N9 trotz A-GPS mich schon in Gütersloh wähnt, statt korrekt zwischen Wolfsburg und Hannover verortet, und warum die Panasonic DMC-ZS10 trotz angeblich daueraktivem GPS-Chip immer gefühlte Stunden unter freiem Himmel für die (Neu-) Positionierung benötigt … Man weiß es nicht.

Your tunnel just caved in

75788333

Did I mention that I consider IPsec bloated and overly complicated? Well, stressing the L2TP/IPSEC connection during a train ride it just proved my point — whereas the OpenVPN between Laptop and the datacenter is lossy (when there is no GSM connectivity) but rock solid, Androids multilayer complex solution just dies every now and then, leading myself reducing the password, needed to be entered each time, to just ‘.’ – standard behaviour of humans if technology suck big time, as does Androids VPN solution.

Will reconsider rooting and dumping OpenVPN on the phones instead …

Android and VPN — it finally works

Oh yeah. After I recently discovered that OpenVPN on the Fritzbox was the cause of all the grief I had with trying to connect two Fritzboxes via SIP over the Internet (tunneled, of course), and got rid of that (on the FB; my VPN-of-choice is still OpenVPN) and now even did a native Fritz-VPN link between two of them, I though, “hey, why not linking my Android to it as well?” Few I knew, back then, on how impossible this is with current, i. e. 2.3-ish, Android — the Fritzbox only does IPsec, Android only does L2TP/IPsec.

To cut a long (two nights, that is) story short: thanks to the awesome howto of Philip Bailey I got this going in next to no time — on a fresh Debian box, that is:

wusel@greebo:~$ traceroute dyn-130.mobile.uu.org
traceroute to dyn-130.mobile.uu.org (192.251.226.130), 64 hops max, 40 byte packets
 1  gw.berlin.uu.org (193.26.120.113)  0 ms  0 ms  0 ms
 2  gw-alice-b.vpn.uu.org (192.251.226.173)  27 ms  27 ms  33 ms
 3  quoth.uu.org (195.71.106.48)  28 ms  31 ms  28 ms
 4  dyn-130.mobile.uu.org (192.251.226.130)  101 ms  99 ms  101 ms

Cool stuff is: I now can happily start my VPN on the Android, start a SIP client and connect to my Fritzbox at home to take calls or make some — from my fixed line number, that is. I’m still not certain if I keep it this way or once again bring up my Asterisk. But for now it “just works” with two Fritzboxes, connected via a VPN (in this case, the FB in Berlin is the one hooked to DSL, the one doing SIP2ISDN in Gütersloh is actually a second one, as I seem to have some cabling issue on the ISDN side of the one in Gütersloh that does the PPPoE stuff) but not, this seems to be the important part, running OpenVPN locally.

I really would liked to connect directly to a Fritzbox from Android, but as I did not want to neither root nor custom-firmware all the Androids in my family, providing just a Android-compatible VPN gateways is the only approach.

Bezeichnend, oder: o2 can do

1026191257

Die einzigen Kosten, mal von dem Faulheitsanruf vom Festnetz nach 0179 abgesehen, sind die von meinem Anruf bei der [censored] Alice-Hotline, weil deren versiffter PPPoE-Server mal wieder für signifikante Zeit unpäßlich war — und die ‘Gesprächszeit’ war zu 90% nervige Warteschleife.

Schon geil, wie Alice/o2 sich da refinanzieren: Server wiederholt kaputtgehen lassen, damit den Service nicht erbringen — und die Kunden in der kostenpflichtigigen Warteschleife abzocken. IMHO ‘o2 can do’ in Reinform :-(