wiki:babel_android [Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
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 


  * Wir haben eine global identische Gateway IP-Adresse, die per DDHCP als Gateway an die Clients verteilt wird.
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.
  * Die Clients bekommen ein Lease per DDHCP mit dieser Gateway IP-Adresse.
  * Jede "echte" Gateway kriegt eine einzigartige IPv4-Adresse per DDHCP in einem dafür vorgesehenem Adressbereich und wird als einzige default Route in einem eigenem routing Table gesetzt (Babel beherrscht Routingtabellen).
Das heißt jede Gateway hat eine eindeutige Routingtable-Nummer (wir
können die z.B. aus der per DDHCP verteilten IP-Adresse berechnen).
  * Wir setzen folgende iptables rules:
      * Setze das entsprechende MARK, wenn es schon einen connection entry für den Client gibt: iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
      * Wenn es noch kein MARK gibt, setze das MARK von der von dieser Node bevorzugten Gateway mit iptables -A PREROUTING -t mangle -m mark --mark 0x0 -j MARK --set-mark XXX
    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.