Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:babel_android [27.01.2019 14:49] – christf
+++ wiki:babel_android [16.06.2019 22:29] (aktuell) – [Nichts tun] christf
@@ Zeile 20: / Zeile 20: @@
 # Lösungsansätze
+## Nichts tun
+* Das Problem tritt nur auf (einigen?) Android < 8 auf. Sobald die weggealtert sind, gibt es keine signifikant große Nutzergruppe mehr die ein Problem mit IPv6-only Netzen hat.
+* Im Oktober 2018 https://de.statista.com/statistik/daten/studie/180113/umfrage/anteil-der-verschiedenen-android-versionen-auf-geraeten-mit-android-os/ - android hat im Januar 2019 85% Marktanteil bei mobilen Geräten. Die Hälfte davon ist vermutlich vom Problem betroffen.
+* Die Endgeräte sind kaputt, nicht das Netz. Es wäre der richtige Weg, die Clients zu reparieren statt im Netz workarounds zu finden.
+* Blöderweise, ist eine große Anzahl dieser Endgeräte im Umlauf - und es ist nicht realistisch, dass diese gepatcht werden.
+* Stand Juni 2019 sind 1/4 der Androids (Version < 8) betroffen.
 ## IPv4 Adresse zuweisen
@@ Zeile 25: / Zeile 33: @@
 Wir haben den Ansatz probiert - auf einigen Geräten geht das. Auf anderen überhaupt nicht.
-In der aktuellen Firmware wird den Endgeräten eine IPv4-Adresse zugewiesen und dabe /32 Subnet, DNS und NIS DHCP-Optionen gesetzt. Ein Gateway wird nicht per dhcp verteilt. Dadurch akzeptiert mein Sondy Android 5.1 die Verbindung und man kann das Internet nutzen. Ein Ausrufezeichen steht manchmal am Wifi Logo - das Netz ist unabhängig davon nutzbar.
+In der aktuellen Firmware wird den Endgeräten eine IPv4-Adresse zugewiesen und dabe /32 Subnet, DNS und NIS DHCP-Optionen gesetzt. Ein Gateway wird nicht per dhcp verteilt. Dadurch akzeptiert mein Sondy Android 5.1 die Verbindung und man kann das Internet nutzen. Ein Ausrufezeichen steht manchmal am Wifi Logo - das Netz ist unabhängig davon oft nutzbar. Oft auch nicht.
 ## Xlat mittels Kernelmodul
-## conntrack und ipset, clat auf Node
+* Vincent hat die Sache untersucht und auch schon Code.
+* Es läuft darauf hinaus ein out-of-tree Kernelmodul zu warten so lange das Netz in der Form betrieben wird und ipv4 für Endgeräte noch erforderlich ist. Diese Lösung ist damit eine Ergänzung zu "nichts tun" - Man baut eine Zwischenlösung, die mit Sicherheit funktionieren wird, allerdings aufwändig ist.
+## Routing von ipv4, Realisierung von Roaming mittels conntrack und ipset, kein xlat
@@ Zeile 77: / Zeile 88: @@
 werden.
+- Connection tracking passiert bei jedem HOP auf dem geroutet wird. Gemäß https://stackoverflow.com/questions/5662749/extending-packet-header-from-within-a-netfilter-hook?rq=1 kann man dne Header um LSRR Felder erweitern. Sofern an einem Node kein Mark gesetzt ist und das Paket nicht von einem lokalen Client kommt, muss das Mark anhand des LSRR-Felds gesetzt werden.
+##  Android Internetverbindungserkennung erkennen und das erwartete Verhalten am Node simulieren
+Wie findet ein Android den Weg ins Internet. (WLAN-Anmeldungsseite) Der Node könnte das von Android erwartete Verhalten simulieren und so dafür sorgen, dass Androiden nicht aus dem WLAN fallen und dann das ipv6-Netz nutzen.
+## Registrierung problematischer Geräte
+Nutzer von problematischen Geräten können deren MAC-Adresse an Netz-ZEntraler Stelle hinterlegen. Dadurch werden nur diesen Geräten eine IPv4-Adresse zugeteilt. Für diese Geräte wird CLAT genutzt. Roaming bricht dann für diese Geräte - stationärer Betrieb geht aber gut.