Mein Android 5.1 hat Schwierigkeiten über das Babel-Freifunk auf das Internet zuzugreifen.
# Symptom
* Netzwerkkommunikation scheint manchmal zu gehen (ich bin mir allerdings unsicher ob die Inhalte dann aus einem Cache kommen) * Der node an dem das Gerät angeschlossen ist erkennt alle IPv6-Adressen des Androiden * Der Android zeigt neben dem wifi-Symbol ein Ausrufezeichen * ping6 auf die ll-Adresse von nextnode führt zu "Network is unreachable" * ping auf google.de führt zu "unknown host" * ip -6 ru s zeigt eine rule die bei outbound wlan0 interface die routing table 1046 nutzt. * ip -6 r s t 1046 zeigt 2 routen auf fe80::0/64 auf das wlan0 interface und die default route über die ll-adresse des nextnode. * die Nextnode-IP ist vom Android aus nicht erreichbar * Android antwortet auf pings von einem anderen Gerät im Freifunk-Netz auf seinen beiden IPv6-Adressen * Die Routen zu den IP-Adressen des Geräts sind im Netz verteilt.
# Ziel Babel-Freifunk soll mit android 5.1 nutzbar werden.
# 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
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 oft nutzbar. Oft auch nicht.
## Xlat mittels Kernelmodul
* 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
Diese wird als IP-Adresse auf dem Gateway-Interface gesetzt. Das Gateway-Interface, das mit dem Client-Interface in einer Bridge hängt, hat auf allen Nodes die gleche MAC-Adresse.
Das heißt jede Gateway hat eine eindeutige Routingtable-Nummer (wir können die z.B. aus der per DDHCP verteilten IP-Adresse berechnen).
Was auch immer für eine MARK gesetzt wurde, speichere sie als MARK für diese Connection iptables -A POSTROUTING -t mangle -j CONNMARK –save-mark
- Dann müssen wir nur noch dafür sorgen, dass die Pakete, die mit den jeweiligen MARKs versehen sind, in den richtigen Routingtabellen landen: Für jede globale Gateway setzen wir ip rule add fwmark $GWMARKNUMMER lookup table $GWTABELLE
- Damit bei einem Roaming-Vorgang die Connection entries des Clients übernommen werden, muss l3roamd diese von der vorherigen Node mittels nfconntrack abfragen und setzen.
- Damit in der Zwischenzeit ein Client nicht einen neuen Connection entry generiert, droppen wir alle Pakete in der INPUT chain, für die wir noch keine rules haben: ipset –create roamed hash:mac iptables -A INPUT -i $GATEWAYINTERFACE -m set –match-set \!roamed src -j DROP Wenn wir dann für einen Client erfolgreich die Roamingdaten erhalten haben und die Einträge mittels nfconntrack gesetzt haben, oder ein timeout erhalten, weil die alte Node nicht erreichbar ist, fügen wir den Client in die Liste hinzu: ipset –add roamed $CLIENTMAC Das ist der netzwerktechnisch korrektere Weg, auch wenn die Pakete kurze Zeit gedroppt werden.
- Wenn wir nicht wollen, dass die Pakete gedroppt werden, können wir später statt -j DROP -j NFQUEUE benutzen und ein Userspace-Programm schreiben, das jede X Zeiteinheiten guckt, ob jetzt ein ipset-Eintrag für das Paket verfügbar ist oder der Timeout ausgelaufen ist. Dann winkt es das Paket durch. Wenn der Timeout ausgelaufen ist, setzt es einen ipset-Eintrag, damit neue Pakete nicht mehr in der Queue landen und winkt das Paket durch. Würde die Queue mal vollaufen, würden die Pakete auch einfach gedroppt 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.