Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
wiki:babel_android [04.11.2018 19:49] – christf | wiki:babel_android [16.06.2019 22:29] (aktuell) – [Nichts tun] christf | ||
---|---|---|---|
Zeile 4: | Zeile 4: | ||
# Symptom | # Symptom | ||
- | * NEtzwerkkommunikation | + | * Netzwerkkommunikation |
* Der node an dem das Gerät angeschlossen ist erkennt alle IPv6-Adressen des Androiden | * Der node an dem das Gerät angeschlossen ist erkennt alle IPv6-Adressen des Androiden | ||
* Der Android zeigt neben dem wifi-Symbol ein Ausrufezeichen | * Der Android zeigt neben dem wifi-Symbol ein Ausrufezeichen | ||
Zeile 13: | Zeile 13: | ||
* die Nextnode-IP ist vom Android aus nicht erreichbar | * 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 | * 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 | # Ziel | ||
Babel-Freifunk soll mit android 5.1 nutzbar werden. | 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:// | ||
+ | * 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, | ||
+ | * 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 " | ||
+ | |||
+ | ## 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, | ||
+ | * Die Clients bekommen ein Lease per DDHCP mit dieser Gateway IP-Adresse. | ||
+ | * Jede " | ||
+ | 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, | ||
+ | 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:// | ||
+ | |||
+ | |||
+ | ## 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. |