Hallo an alle,

ein Freundin von mir hat seit ein paar Wochen urplötzlich (vielleicht nach einem automatischen Sicherheits-Update?) ein äußerst seltsames Problem beim Tethering (und nur dann) zwischen iPhone und MacBook Pro: Die Tethering-Verbindung steht (angezeigt durch die beiden verschränkten Ringe in der Menüleiste von macOS), übers Terminal ist das Internet auf dem MacBook Pro erreichbar (probiert habe ich Abfragen bei Nameservern via host und dig), aber Safari und Mail behaupten, es bestünde keine Internet-Verbindung. Auf dem iPhone selbst funktioniert alles.

iPhone SE 2. Generation, iOS 17.3.1
MacBook Pro 14" (2023), M2 Pro, Ventura 13.6.4.

Ich dachte zunächst an ein DNS-Problem, aber das ist nicht der Fall: Auch wenn ich auf dem MacBook Pro in Safari eine Website mit ihrer IP-Adresse statt des Domainnamens aufzurufen versuche, kommt die Meldung, es bestünde keine Internet-Verbindung.

Was kann das für ein Netzwerkfehler sein, der nur beim Tethering auftritt und nur (generalisiert) bei GUI-Apps auf dem MacBook Pro, aber nicht auf der Kommandozeile/Terminal auf dem MacBook Pro und überhaupt nicht auf dem iPhone? Ich habe keine Idee.

Hat vielleicht jemand von Euch eine? Vielen Dank schonmal!

Trotzdem kann man die Seite auch per IP aufrufen, wenn man die entsprechende Warnung quittiert.

Wie weiter oben geschrieben, leg doch mal eine neue Umgebung bei den Netzwerken an.

Btw sehe ich nicht Google in deiner dig-Abfrage, sondern Cloudflare (1.1.1.1)

Die Ratschläge, auf dem iPhone ist was falsch eingestellt sind ziemlich abwegig, eher hängt das Problem mit dem MAC zusammen. Lösungen dazu gibt es eigentlich nicht, nur Vermutungen, woran es liegen kann.
Hier eine Übersicht, wer es noch nicht gelesen hat:
"https://iboysoft.com/de/anleitung/mac-verbindet-sich-mit-wifi-aber-kein-internet.html"

Werde auf dem MAC Reset machen und alles neu aufsetzen.
Wenn WLAN am MAC angezeigt wird und die Verbindung funktioniert, wie "ifconfig" an der Console, dann "fehlt", nicht funktioniert, die "Schnittstelle", Treiber, Einstellungen, für die Browser, oder was auch immer und warum auch immer.
Ist doch bekannt, das Apple Updates mutwillig manche Einstellungen ändern.

Danke, aber NEIN DANKE.

Ich denke aber, ich sollte Apple und diverse andere Tec-Firmen dringend anschreiben, dass sie sich Dich umgehend bei Dir melden, damit Du Ihnen erklären kannst, wie das alles richtig heißt und sie die völlig sinnbefreiten Bezeichnungen wie bspw. »Personal Hotspot« im macOS ändern. Entschuldige bitte, dass wir anderen so blöd sind. Ihr Samsung-Jünger habt natürlich (immer) Recht und Android auf SmartPhones ist natürlich ach so fortschrittlich, so ganz ohne bspw. Viren oder andere Schadsoftware…

Keine Sorge, war die letzte Nachricht an Dich. Ist mir ganz im Allgemeinen ehrlicherweise zu blöd, mich in meiner Lebenszeit mit so etwas zu beschäftigen.

Greetings, C.

Guten Morgen weia.

so ähnlich hatte ich das ehrlicherweise schon fast vermutet, daher auch der Ausschlußtest des SIM-Karten-Tausches. Geht natürlich auch mit mehreren iPhones. Dennoch wäre es – habe ich es überlesen ?? – in meinen Augen wichtig, wenn sie die eine SIM-Karte in eines ihrer vielen iPhones steckt und testet, ob es dann eben mit dieser einen SIM darüber geht – oder der Fehler mitwandert.
Sind das alles SIMs aus einem Vertrag ( also MutliSIM ) oder einzelne Verträge ?? Die Provider können ja ganz allgemein – so wie bei SMS – einzelnen Karten einzelne Dienst zuweisen. Falls da also etwas querhängt, kannst Du halt in iOS oder macOS lange suchen…

Würde ich versuchen auszuschliessen. Dann schauen wir weiter.

Greetings, C.

Guten Morgen Weia,

Bitte mit gedrückter Option Taste auf das Link Symbol oben rechts klicken und die IP des Routers merken (bei mir 172.20.10.1) die IP-Adresse sollte dazu passen (bei mir .14).
Dann Einstellungen Suchfeld oben links „DNS“ eingeben und in der Liste „DNS-Server, Server“ klicken.
In dem Fenster das auf geht sollte die IP des Routers oben stehen.

Könntest du das bitte prüfen.

Viele Grüße

Nur an "Anather MacUser", danke für die Belehrung und der Vorschlag. In einem Thread um Sinn von 5G ist um eine Erfahrung mit Starlink berichtet worden. Wo man das Ethernet Tethering von der Starlink über ein USB-C LAN Adapter an ein Handy angeschlossen, von dort als Hotspot betreiben kann. Allerdings nicht als, was allgemein Hotspot genannt wird, aber mit einer der 3 Funktionen am Handy: Bluetooth, USB, hier als Ethernet Tethering, was auch WLAN Tethering genannt wird.
Wahrscheinlich hat auch iPhone 15 Pro diese Funktion, bei den Samsungs ist die eigentlich immer vorhanden. Das auch, wenn jemand der Sinn der Funktion bezweifelt. Klar kann man auch ein WLAN Router mit RJ45 Anschluss benutzen, der Adapter kostet aber unter 20 Euro. Starlink kostet, ein Kontinent, mit Daten ohne Limit, 59 Euro je Monat, das ist für Mobil herum Reisen nicht viel.

Schauen wir doch, was Wikipedia zu "Tethering" schreibt Weia gebraucht das Wort Tethering exakt in diesem Sinne und fast alle haben es genau so verstanden.
Also, Quantas, erinnere Dich an eine Weisheit der Dakota-Indianer: "Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!"

Mensch, hab' ich doch schon zitiert… Jetzt bin ich aber echt mugsch, dass hier niemand meine Posts liest… :'( :'(

Und Q ( assoziiert jemand etwas dazu, wenn ich noch »Captain Picard« akustisch mit in diese Raumzeit werfe ?? ) hat's nicht für relevant erachtet. »Why me ?«, meinte Jean Luc mal dazu…

So – und nun ist gut, wir wollen ja nicht alle immer nur rumstänkern. Lasst uns weia und seiner Freundin helfen.

Happy Day, C.

Leider hat das heute mit den weiteren Tests nicht geklappt; schlimmstenfalls muss ich bis Freitag warten, bis ich wieder berichten kann.

So, endlich konnte ich wieder testen. Ich hoffe, ich vergesse jetzt nichts, was wir probiert haben (war wie immer sehr hektisch).
An der Apple-ID liegt es definitiv nicht. Meine Freundin hat nämlich noch ein altes iPhone, das sie nur noch selten nutzt, aber natürlich mit derselben Apple-ID. Und mit diesem iPhone funktioniert das Tethern.
Mittlerweile geht USB; keine Ahnung, was zuvor klemmte. Und siehe da: Mit USB statt WLAN funktioniert das Tethern.
Mir ist eingefallen, dass zwar nicht Wireguard, aber Tunnelblick installiert ist, eine VPN-GUI-App zum Zugriff auf eine Webdisk. Die geht nicht (ist ja auch eine GUI-App), aber bietet ein ausführliches Fehlerprotokoll. Die Datenmassen muss ich aber erstmal durchwühlen und berichte dann getrennt.
Das haben wir jetzt gemacht, mit ihren beiden iPhones, von denen das alte geht und das neue nicht. Ergebnis: Es liegt nicht an der SIM-Karte. Durch einen Tausch der SIM-Karte ändert sich gar nichts, das alte iPhone kann nach wie vor tethern, das neue nach wie vor nicht.
Die Antwort war vielleicht uneindeutig. Also nochmal: Safari meldet in der Tat wörtlich Es besteht keine Verbindung zum Internet. Diese Seite kann nicht angezeigt werden, da dein Computer gerade offline ist, aber es ist eben nicht der Fall, dass keine Verbindung zum Router oder zum Internet besteht. Nur die Namensauflösung funktioniert nicht.
Nö:
Also wie ssh, ping & Co.
Nö, nur testweise. Normalerweise OpenDNS (208.67.220.220, 208.67.222.222).
Definitiv nein. Kein Proxy konfiguriert.
Keine.
Ja, das stimmt natürlich, erzeugt aber unnötig zusätzliche Fehlermeldungen im Testszenario.
Dazu finde ich in Ventura keine Möglichkeit mehr.
Ja, ich verwechsle 1.1.1.1 und 8.8.8.8 notorisch. Getestet habe ich beides.
Einzelne Verträge.
Die IP-Adressen passen zusammen.Nö, da stehen die beiden als Nameserver eingestellten OpenDNS-Adressen. Aber das tun sie immer, bei regulärem WLAN, bei Tethering mit dem funktionierenden iPhone und bei Tethering mit dem nicht funktionierenden iPhone.

Das ist in meinen Augen ein DNS Problem, ggf. gemischt mit IPv6.
Ich würde empfehlen einmal die Standard DNS Einstellungen zu verwenden. D.h. das iPhone auch als DNS Server mit IPv4 und IPv6.
Welche beiden Adressen sind denn aktuell eingestellt?

Du kannst ggf. davor einmal im Terminal eingeben:


Und die Ausgabe hier posten.

Viele Grüße

Netzwerkumgebungen anlegen unter Ventura

Vllt mal einen neuen Benutzer auf dem Mac einrichten und gucken, ob es mit diesem funktioniert.

Vielen Dank für die neuen Testvorschläge. Wie immer muss ich um etwas Geduld bitten, bis ich sie umsetzen kann.

Nun zu der Auswertung der Log-Dateien von Tunnelblick. Manches hätte man wohl auch völlig unabhängig von Tunnelblick einfach im Terminal testen können, nur leider kenne ich mich mit Netzwerk-Protokollen in dieser Detailliertheit nur rudimentär aus, weshalb die Log-Dateien hilfreich waren.

Aus dem riesigen Datenwust habe ich zunächst mal die mit ifconfig erstellten Angaben zur Netzwerkkonfiguration herausgesucht, die möglicherweise hilfreich sind. Getestet habe ich 3 Fälle:

• Normales WLAN (abgekürzt WLAN)
• funktionierendes Tethering mit dem alten iPhone (abgekürzt TetherOK)
• nicht funktionierendes Tethering mit aktuellen iPhone (abgekürzt TetherNOT)

Hier die ifconfig-Ausgaben. Ich habe nicht die Code-Ansicht gewählt, um die Unterschiede zwischen den einzelnen Varianten farblich markieren zu können.

Zunächst WLAN und TetherOK im Vergleich; Differenzen gibt es nur für en0; sie sind rot markiert:

WLAN:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 5c:e9:1e:8f:b6:21
inet6 fe80::88d:25ad:4b9f:d5a0%en0 prefixlen 64 secured scopeid 0xf
inet 192.168.178.35 netmask 0xffffff00 broadcast 192.168.178.255
inet6 2a02:6d40:300c:6e01:189d:b76f:3c92:a663 prefixlen 64 autoconf secured
inet6 2a02:6d40:300c:6e01:2140:ec25:3b91:9f0c prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active

TetherOK:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 5c:e9:1e:8f:b6:21
inet6 fe80::88d:25ad:4b9f:d5a0%en0 prefixlen 64 secured scopeid 0xf
inet6 2a01:599:441:cbec:84b:346a:afcb:9997 prefixlen 64 autoconf secured
inet6 2a01:599:441:cbec:e4ee:bb92:5c34:2cc6 prefixlen 64 autoconf temporary
inet 172.20.10.9 netmask 0xfffffff0 broadcast 172.20.10.15
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active

Für mein Verständnis sind das einfach die unterschiedlichen IP-Adressen und sonst nichts. Also ein völlig trivialer Unterscheid und prinzipiell völlig identisch, führt ja auch zum selben Ergebnis.

Und dazu im Vergleich TetherNOT. Hier gibt es neben den unterschiedlichen IP-Adressen weitere Abweichungen bei en0 und ganz am Ende der ifconfig-Ausgabe einen zusätzlichen Eintrag. Die Unterschiede zu TetherOK sind rot markiert, neu hinzugekommene Zeilen violett und die zusätzlichen Unterschiede zu WLAN (wohl wieder nur die andere IP-Adresse) türkis.

TetherNOT:
en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 5c:e9:1e:8f:b6:21
inet6 fe80::88d:25ad:4b9f:d5a0%en0 prefixlen 64 secured scopeid 0xf
inet6 2a01:599:411:3f8d:187e:e5b6:dee1:48b4 prefixlen 64 autoconf secured
inet6 2a01:599:411:3f8d:b16a:9730:e92c:fb1e prefixlen 64 autoconf temporary
inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
inet6 2a01:599:411:3f8d:443:ac61:f5db:3a82 prefixlen 64 clat46
nat64 prefix 64:ff9b:: prefixlen 96
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active

Und wie gesagt ganz am Ende der Ausgabe:
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::8b37:bb82:325d:1031%utun0 prefixlen 64 scopeid 0x12
nd6 options=201<PERFORMNUD,DAD>
[…]
utun7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::e31b:d033:fe76:eeed%utun7 prefixlen 64 scopeid 0x19
nd6 options=201<PERFORMNUD,DAD>
utun9: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::abd6:288b:ebae:c557%utun9 prefixlen 64 scopeid 0x1f
nd6 options=201<PERFORMNUD,DAD>
utun8: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.9.0.10 –> 10.9.0.9 netmask 0xffffffff


Das soll für den Anfang reichen. Kann jemand damit etwas anfangen?

192.0.0.2 als IP alleine find ich schon merkwürdig und gleichzeitig als Broadcast-Adresse noch viel merkwürdiger.
Normal für den persönlichen Hotspot ist eine IP aus 172.20.10.0/28
Kannst du beim nächsten mal auch einfach nur ifconfig vergleichen und posten?
Im Netz findet man zu 192.0.0.2, dass es was mit IPv4/IPv6 zu tun hat
Ist in den Netzwerkeinstellungen am MacBook "IPv6 konfigurieren" auf automatisch gestellt?
Alternativ die IPv4 nicht per DHCP vergeben lassen, sondern einfach mal fest konfigurieren und bei Bedarf umschalten - was über unterschiedliche Netzwerkumgebungen möglich wäre

Die Netzmaske 0xffffffff klingt ebenfalls seltsam. Würde mich nicht wundern, wenn damit zusammenhinge, dass Safari meint, es gäbe keine Verbindung zum Internet.
Das habe ich de facto doch getan?
Oh, das klingt nach einer heißen Spur!
Ich werde wohl morgen Abend wieder testen können.

Bedeutet, dass es ein Netzwerk mit nur einer Adresse ist.
192.0.0.2/32 - hier kann es nur ein Gerät geben, daher ist die Adresse Netz und Broadcast Adresse zugleich.

Die Adresse en0 müsste auch mit dem Wert im Netzwerk bei gedrückter Option Taste übereinstimmen:



Kannst du bitte folgende Einstellungen posten:

Einstellungen WLAN "Details" und dort die Fenster TCP/IP und DNS

So, nächste Testrunde, diesmal mit vorläufiger Lösung.
Das bestätigt nur, wie verquer die aktuelle Konfiguration war. Auch für nslookup gilt nämlich: es existiert zugleich und zugleich nicht („Schrödinger’s Cat-Tethering“):
Sowas habe ich überhaupt noch nie gesehen …
Nö, ändert gar nix.
Hmmpfff, noch besser verstecken konnte Apple das nicht? Die Suchfunktion ist in den neuen Systemeinstellungen 🤮 meist meine einzige Rettung, und die findet die Netzwerk-Umgebungs-Einstellung nicht, wenn man nach Umgebung sucht.

Und Bingo, das war’s! Neue Umgebung angelegt und alles flutscht wieder. Ich hätte ja vermutet, dass das Zurücksetzen der Netzwerkeinstellungen dasselbe bewirken würde wie eine neue, jungfräuliche Umgebung, aber nein, offenbar nicht. 😤

Im Tunnelblick-Log ist zu erkennen, dass in der neuen Umgebung nur 2 Netzwerkanschlüsse aktiviert sind (Thunderbolt Bridge und Wi-Fi) statt 6 (Thunderbolt Ethernet, Thunderbolt Bridge, Thunderbolt FireWire, Wi-Fi, iPhone USB und iPhone 2) und auch in der ifconfig-Ausgabe gibt es mehr Änderungen gegenüber TetherNOT (siehe oben):

en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 5c:e9:1e:8f:b6:21
inet6 fe80::88d:25ad:4b9f:d5a0%en0 prefixlen 64 secured scopeid 0xf
inet6 2a01:599:411:3f8d:187e:e5b6:dee1:48b4 prefixlen 64 autoconf secured
inet6 2a01:599:411:3f8d:b16a:9730:e92c:fb1e prefixlen 64 autoconf temporary
inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
inet6 2a01:599:411:3f8d:443:ac61:f5db:3a82 prefixlen 64 clat46
nat64 prefix 64:ff9b:: prefixlen 96
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
awdl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether ae:b0:1f:be:e1:f1
inet6 fe80::acb0:1fff:febe:e1f1%awdl0 prefixlen 64 scopeid 0x10
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
llw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether ae:b0:1f:be:e1:f1
inet6 fe80::acb0:1fff:febe:e1f1%llw0 prefixlen 64 scopeid 0x11
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: inactive

Was da nun welche Bedeutung für das Problem hat, vermag ich auf Anhieb nicht zu überblicken.

Ich werde mir aber baldmöglichst mal ansehen, welche Unterschiede man auf GUI-Ebene zwischen den beiden Umgebungen erkennen kann, um das Problem einzugrenzen.

Ich habe mir nun wie versprochen angesehen, wie sich die funktionierende von der nicht funktionierenden Umgebung auf GUI-Ebene in den Systemeinstellungen unterscheidet und das Ergebnis ist irgendwie ernüchternd.

Pragmatisch ist die Lösung am Ende simpel: Der ausschlaggebende Unterschied ist einzig, ob in Systemeinstellungen → Netzwerk → Details … → DNS → DNS-Server IP-Adressen von irgendwelchen Nameservern eingetragen sind, völlig egal, welchen. Sobald das der Fall ist, funktioniert Tethering nicht mehr. Sobald man sämtliche Einträge mit der Minus-Taste gelöscht hat und ausgegraut die IP-Adresse des Routers angezeigt wird, funktioniert Tethering wieder.

Technisch ist allerdings Etliches völlig ungeklärt:

• Warum funktioniert plötzlich Tethering mit dedizierten Nameservern nicht mehr, nachdem es das jahrelang tat und von der Sache her auch tun müsste? Ist das ein Bug oder ein schräges, undokumentiertes Feature in unbekannter Absicht?
• Was ist ursächlich für das plötzliche Auftreten des Phänomens? Ein iOS-Update oder ein macOS-Update?
• Warum gehen GUI-Apps fälschlicherweise von unterbrochenem Internet statt korrekt von nicht erreichbaren Nameservern aus (und können konsistenterweise auch keine URLs mit numerischer IP-Adresse erreichen), während Kommandozeilenprogramme ebenfalls keine Domainnamen auflösen können, mit numerischen IP-Adressen aber wunderbar funktionieren, also mithin Zugang zum Internet haben?
• Warum führt Tethering (und zwar sowohl nicht funktionierend mit dedizierten DNS-Einträgen in den Systemeinstellungen als auch funktionierend ohne DNS-Einträge!) zu der seltsamen, oben beschriebenen Existenz/Non-Existenz von nslookup? (Ja, dieses ultraschräge Phänomen tritt bei Tethering immer auf, auch bei ansonsten funktionierendem!)

Keine dieser Fragen könnte ich im Augenblick beantworten. Da wabern irgendwelche Inkonsistenz-Abgründe in den Tiefen von macOS und/oder iOS.

Leidtragende sind jetzt u.a. Mac-Nutzer, die öfters auf der Unix-Ebene arbeiten und FRITZ!Boxen nutzen. Wegen des unsäglichen fritz.box-Hacks im DNS-Server der FRITZ!Boxen, der bis heute nicht durch eine standardkonforme mDNS-Implementation ersetzt wurde, können netzwerkaffine Unix-Programme nämlich durchdrehen, wenn der DNS-Server einer FRITZ!Box benutzt wird statt eines anderen, korrekt implementierten, in den DNS-Einstellungen eingetragenen. Das zwingt solche Nutzer jetzt zu mindestens 2 unterschiedlichen Umgebungen, eine für WLAN-Verbindungen zu einer FRITZ!Box und eine fürs Tethering.

Hier für die Nachwelt nochmals die Schrödingers Katze-Existenz von nslookup während einer Tethering-Verbindung zum Internet in all ihrer skurrilen Glorie:

Wenn ich automatisch die DNS-Server eintragen lasse, stehen dort zwei IP-Adressen von der Pi-hole. Offenbar übermittelt mein Router korrekt diese Adressen die bei IPv4 DHCP (192.168.1.242) und IPv6 DHCP (fd87:9ffc:...) in meinem Synology Router eingetragen sind.
Wechsle ich auf Tethering dann ändert sich diese Eintragung auf die IPv6-Adresse fe80::6083:....
Wäre also dort in den Netzwerkeinstellungen etwas fest eingetragen, könnte diese automatische Änderung nicht durchgeführt werden.

Ich möchte mich nochmals herzlich bedanken für all die engagierten, hilfreichen Beiträge, um dem Problem auf die Spur zu kommen! Und ganz besonders natürlich bei caMpi, der den entscheidenden Tipp hatte!

Nö, natürlich nicht. Das ist ja gerade der Sinn fester DNS-Server-Einträge, dass immer dieselben DNS-Server verwendet werden, egal, über welchen Router die Anbindung ans Internet läuft. Das dürfte aber kein Problem verursachen und tat es bislang ja auch nicht.

Das hängt davon ab, ob eine externe IP wie 8.8.8.8 von Google eingetragen ist oder eine interne IP vom Router. Mit der internen IP vom Router könnte das Mobiltelefon im Mobilfunknetz nichts anfangen.

OK, das ist klar. Ich bezog mich auf externe IPs.