Auf einen sehr unschönen Bug sind wir bei einem neuen Android-Handy Samsung Galaxy 3 i5800 gestoßen. Es handelt sich um einen reproduzierbaren Bug bei der Einbuchung des Handys in ein WLAN-Netz. Doch der Reihe nach und zuerst ein bischen anschauliche Netzwerktechnik:
In privaten (WLAN-)Netzen werden normalerweise sogenannte private IP-Adressen verwendet, also IP-Adressen, die nicht für öffentliche Server vergeben sind und in klar definierten Bereichen liegen. Sehr bekannt sind z.B. 192.168.1.xxx. Ein anderer Bereich ist der 10-er-Bereich, von 10.0.0.0 bis 10.255.255.255. Hierbei handelt es sich um ein gesamtes sogenanntes Class-A-Netz, also der gesamte 10-er-Bereich, der nach eigenem Ermessen in Subnetze unterteilt werden kann. Wir nutzen z.B. für uns ein Class-C-Subnetz und haben vielen unserer Kunden, oder auch für uns selbst, in den verschiedenen Subnetzen in den Rechenzentren nicht überschneidende, andere Class-C-Subnetze zugewiesen. Auf diese Weise sind die einzelnen zu wartenden Rechner problemlos erreichbar. Ein Class-C-Subnetz geht z.B. von 10.1.1.1 bis zu 10.1.1.254, ein anderes von 10.1.2.1 bis 10.1.2.254. Die Rechner in einem Subnetz unterscheiden sich durch die letzte Zahl.
Kennzeichen für ein Subnetz ist aber vor allem, dass sich die Rechner in einem Subnetz jeweils direkt, also ohne einen Router, erreichen können. Hierfür gibt es das sogenannt ARP, also das „Address-Resolution-Protokoll“ welches bildlich dargestellt wie folgt abläuft: Nehmen wir an, Rechner A möchte Rechner B eine IP-Nachricht senden:
- A hat z.B. die IP-Adresse 10.1.1.7 und möchte eine Nachricht an den Rechner 10.1.1.61 senden.
- A schaut sich seine Netzmaske an, diese lautet im Class-C-Netz: 255.255.255.0
- Somit stellt A fest: Die Zieladresse 10.1.1.61 unterscheidet sich von der eigenen Adresse nur an einer Stelle, die in der Netzmaske eine 0 hat, somit liegt der Zielrechner im eigenen Subnetz. Hier wird in der Realität bitweise vergleichen, aber der Anschauung halber bleiben wir „menschlich“ dezimal.
- Weil der Zielrechner im gleichen Netz liegt, „schreit“ unser Rechner ins lokale Netz: „Wer hat die Adresse 10.1.1.61“ und der richtige Rechner antwortet „ich bis“.
- Nun kann unser Rechner das Paket zielgerichtet an den Zielrechner zustellen.
In diesem Fall sind also eigentlich drei Dinge wichtig:
- Wie lauten die Adressen (hier die eigene Adresse mit 10.1.1.7 und die Zieladresse mit 10.1.1.61)
- Wie lautet meine Subnetzmaske (hier die 255.255.255.0), damit ich feststellen kann, ob ich den Zielrechner direkt erreichen kann.
- An wen schicke ich meine Pakete, falls ich den Rechner nicht direkt erreichen kann. Dieser „Vermittler“, also der Router, muss natürlich dann direkt erreichbar sein.
Kommt unser Android „Samsung Galaxy“ in ein neues WLAN, fragt es als erstes: „Hier bin ich, ich brauche eine IP-Adresse und wie ist die Subnetzmaske und wer ist der Router?“. Diese Informationen werden ihm dann vom sogenannten DHCP-Server zugeteilt. Hat es dann diese Daten, so kann es Pakete an Rechner im eigenen Netzwerk (Subnetz) direkt zustellen und für Pakete aus und ins Internet fragt es den Router an, der ja im Subnetz als Tor zu Welt vorhanden ist.
Und genau an dieser Stelle liegt der Fehler: Das Galaxy bekommt in einem privaten Class-C-Subnetz mit einem 10-er-Anfang die korrekte Maske 255.255.255.0 mitgeteilt, beachtet diese jedoch nicht, sondern nutzt eine Maske „255.0.0.0“. Möchte unser Handy, analog zum obigen Beispiel habe es selbst die Adresse 10.1.1.7, einen Rechner 10.1.8.20 erreichen, so müsste es eigentlich merken, dass dieser Rechner in einem andern Subnetz liegt, schließlich unterscheiden sich die Adressen ja nicht nur in der letzten, sondern auch in der vorletzten Zahl. Und weil es ja ein anderes Subnetz ist, müsste das Galaxy die Daten dem Router zur Weiterverarbeitung geben.
Überwacht man jedoch den Netzwerkverkehr – wir haben das mit dem Programm „tcpdump“ gemacht, so stellt man fest, dass das Galaxy ins Netzwerk fragt: „War hat die Adresse 10.1.8.20?“ – und dann natürlich keine Antwort bekommt. Im Ergebnis, sind also vom Galaxy aus sämtliche Rechner in einem andern 10-er-Subnetz nicht erreichbar, ein schwerwiegender Fehler.
Dies betrifft zumindest die Version 2.1 des Android-Betriebssystems auf dem Galaxy 3 i5800.
Trägt man die IP-Adressen im Handy statisch ein, funktioniert übrigens der Datenverkehr problemlos – nur dass man dann bei jedem WLAN-Wechsel die Adressen manuell ändern muss.
Siehe auch die Ergänzung: http://blog.imagmbh.de/index.php/2010/12/27/erganzung-zu-android-samsung-galaxy-3-i5800-dhcp-bug/
[…] sind die Weihnachtsfeiertage vorbei und ich habe die Zeit ein bischen genutzt, dem Bug ein bischen näher auf den Grund zu gehen. Das Telefon ist inzwischen “gerooted” […]
[…] […]