WLAN-Netzwerk mit geänderter MAC-Adresse nicht erreichbar

Ich habe kürzlich ein Nexus 7 gekauft, um es als Demo-Client für ein System zu verwenden, das ich gerade entwickle. Bis auf Weiteres benötigt das System eine bestimmte MAC-Adresse des Clients, um zu funktionieren. Ich habe das Nexus gerootet (immer noch mit dem Stock-ROM von Android 4.4) und verwende ip linkzum Ändern der Hardwareadresse von wlan0. Mir ist bewusst, dass dies beim Neustart zurückgesetzt wird, aber da ich meinen Android-Kernel jetzt lieber nicht neu kompilieren möchte, ist das in Ordnung.

Das Problem, das ich sehe, ist, dass ich mit einer geänderten MAC-Adresse keine IP-Adresse von meinem (offenen) WLAN-Netzwerk erhalten kann. Wenn ich eine statische IP einstelle, kann ich mich erfolgreich mit der geänderten Adresse verbinden, aber es kommen keine Pakete durch.

Hoffentlich wird das folgende Transkript etwas Licht darauf werfen, was genau nicht funktioniert und was ich versucht habe.

Zuerst "vergesse" ich meine WLAN-Verbindung und starte mein Gerät neu, um von vorne zu beginnen. Dann:

$ adb shell
shell@flo:/ $ su
root@flo:/ # ip link | grep -A1 wlan0
22: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 100
    link/ether ac:22:0b:9f:37:f7 brd ff:ff:ff:ff:ff:ff
root@flo:/ # ip link set dev wlan0 addr ac:22:0b:9f:37:f0

Hier verbinde ich mich mit dem drahtlosen Netzwerk. Wenn DHCP ausgewählt ist, wird mir einfach "Obtaining IP address" angezeigt, bis die Verbindung fehlschlägt. Wenn ich eine statische IP einstelle, wird das Netzwerk als verbunden angezeigt, aber:

root@flo:/ # ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.113: icmp_seq=1 Destination Host Unreachable
From 192.168.1.113: icmp_seq=2 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1004ms
pipe 2
1|root@flo:/ # ip route
default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.113 
192.168.1.1 dev wlan0  scope link 
1|root@flo:/ # ip n
192.168.1.1 dev wlan0  INCOMPLETE
255|root@flo:/ # ip n change 192.168.1.1 lladdr 10:0D:7F:4D:1C:D0 dev wlan0
root@flo:/ # ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

Also immer noch keine Verbindung. Mal sehen, was passiert, wenn ich meine MAC-Adresse wieder auf die echte ändere, ohne auch nur die Verbindung zum drahtlosen Netzwerk zu trennen:

root@flo:/ # ip link set dev wlan0 addr ac:22:0b:9f:37:f7
root@flo:/ # ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=13.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=9.82 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=9.49 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.491/10.793/13.061/1.609 ms

Hat jemand eine Ahnung, was hier los sein könnte?

Für das, was es wert ist, führe ich DD-WRT auf meinem Router aus, es ist keine MAC-Filterung aktiviert und es sollten keine anderen "seltsamen" Regeln festgelegt sein.

UPDATE: Nach einigen weiteren Untersuchungen habe ich festgestellt, dass das Nexus 7 die gefälschte Adresse überhaupt nicht verwendet, wenn es mit meinem AP spricht. Ich habe die MAC-Filterung aktiviert und nur die gefälschte Adresse zugelassen und dann adb logcateine CTRL-EVENT-ASSOC-REJECTMeldung angezeigt. Ich frage mich, ob dies irgendwie mit dieser wpa_supplicant-Frage zusammenhängen könnte, aber auch dort gab es keine Antworten ...

Hast du eine Möglichkeit, das vom Router aus zu überprüfen (Logs o.ä.)? Haben Sie versucht, ob adb logcatetwas Licht ins Dunkel bringt? Das sind die einzigen zwei Dinge, die mir sofort einfallen (obwohl es noch mehr geben könnte, wie zB die Verwendung einiger Analyse-Apps).
adb logcatsagt nur DHCP-Timeout mit The spoofed MAC. Der Router gibt leider nur sehr begrenzte Informationen,
Sehen Sie den gefälschten MAC in der ARP-Tabelle?
Nein, die ARP-Tabelle des Routers zeigt den gefälschten MAC nicht an. In der Liste "Wireless Clients" wird das Gerät auch mit seiner Standard-MAC aufgeführt, wenn ich eine Verbindung mit statischer IP erzwinge. Dies scheint zu implizieren, dass sich der MAC nicht wirklich ändert, aber wenn das der Fall wäre, warum verbindet er sich nicht?
Ist die statische Lease dem Stock-MAC oder dem Spoof-MAC zugewiesen? Sieht die Arp-Tabelle gleich aus, wenn Sie die statische Lease löschen, den MAC auf Ihrem Gerät erneut fälschen und dann die Verbindung erneut herstellen? Ich glaube nicht, dass Ihr Gerät Frames korrekt erstellt, nachdem es versucht hat, den MAC zu fälschen. Wenn Ihr Router Frames von Ihrem Gerät mit einem falschen oder fehlenden Quell-MAC empfängt, weiß er nicht, wie er zurücksprechen soll. Das könnte erklären, warum Sie sehen, dass sich Ihr Gerät mit dem Router "verbindet" (wenn es versucht, die IP-Adresse zu beanspruchen), Sie aber keinen Datenverkehr weiterleiten können.
@Mr.Buster Die statische IP wird beim Verbinden auf dem Gerät eingestellt, nicht auf dem Access Point. Da ich mich mit der gefälschten IP verbinde, sind die mit der Standard-IP gesendeten Frames diejenigen, die falsch sein sollten, oder?
Dein Router läuft mit DHCP, richtig? Leitet Ihr Gerät Datenverkehr im "normalen" Zustand weiter: keine statische IP, Standard-MAC? Was ist mit keiner statischen IP, gespooftem MAC? Können Sie Ihren MAC fälschen und sich dann erfolgreich mit einem anderen WAP verbinden, wieder ohne statische IP? Die Beantwortung dieser Fragen hilft Ihnen dabei, festzustellen, ob Sie ein Problem der Ebene 2 oder 3 haben. Denken Sie daran, dass IP-Adressen keine Rolle spielen, wenn Layer-2-Frames nicht korrekt erstellt werden. Es ist jedoch möglich, dass Sie einfach vergessen haben, diese IP auf Ihrem Router zu reservieren (mit einem statischen Lease).
Wie in der Frage erklärt, ja, alles funktioniert korrekt mit Stock MAC. Bei einem gefälschten MAC muss ich die IP statisch auf dem Gerät einstellen, um eine Verbindung herstellen zu können, was auf ein L2-Problem hindeutet. Der Teil, den ich nicht herausfinden kann, ist, warum ich die L2-Konnektivität verlieren würde, indem ich den MAC ändere , bevor ich mich mit dem Netzwerk verbinde.
Nach einigen weiteren Untersuchungen habe ich festgestellt, dass das Nexus 7 die gefälschte Adresse überhaupt nicht verwendet, wenn es mit meinem AP spricht. Ich habe die MAC-Filterung aktiviert und nur die gefälschte Adresse zugelassen und adb logcatzeigt dann eine CTRL-EVENT-ASSOC-REJECT...

Antworten (3)

Nach langem Suchen bin ich auf diesen Thread im xda-developers-Forum gestoßen, wo die Leute scheinbar das gleiche Problem mit einem Nexus 4 haben. Nachdem ich mehrere der vorgeschlagenen Lösungen in diesem Thread ausprobiert hatte, stieß ich auf eine, die funktionierte!

Es stellt sich heraus, dass Android eine permanente Aufzeichnung des MAC in /persist/wifi/.macaddr. Aus irgendeinem Grund besteht es darauf, den MAC in dieser Datei zu verwenden, wenn es sich mit einem drahtlosen Netzwerk verbindet. Wenn Sie sich jedoch auf einem gerooteten Gerät befinden, können Sie es mit einem beliebigen MAC überschreiben. Interessanterweise bleibt diese Änderung auch nach Neustarts bestehen !

Also, ohne weiteres Umschweife, hier ist, wie Sie den MAC dauerhaft auf einem Android-Gerät ändern ( durch den gewünschten MAC ersetzen112233445566 ):

computer $ adb shell
android $ su
android # cd /persist/wifi
android # echo -n "112233445566" > .macaddr
android # ^D
android $ ^D
computer $ adb reboot
Die .macaddr-Datei enthält keine Zeichen. Es enthält 6 Bytes, die die MAC-Adresse darstellen. Wenn Sie beispielsweise die MAC-Adresse ändern möchten, müssen Sie die Bytes 0x00 0x11 0x22 0x33 0x44 0x55 in die .macaddr-Datei schreiben. Sie können dies in Bash tun mit: echo -e "\x00\x11\x22\x33\x44\x55" > /persist/wifi/.macaddr
Das ist interessant ... Auf meinem Gerät war es notwendig , die ASCII-Darstellung zu verwenden, nicht die Hex ...
Ich weiß nicht, warum diese Antwort abgelehnt wurde, aber es funktioniert tatsächlich, mein Telefon ist Nexus 4, das gerootet ist.

Jons Antwort auf die versteckte .macaddr gab mir genügend Hinweise, um die Mac-Adresse auf meinem gerooteten LG VS450PP (es hat die Softwareversion VS450PP1) vorübergehend zu ändern.

Die Mac-Adresse für WLAN ist in einer Datei fest codiert (notieren Sie sich die Eigentümer- und Berechtigungsinformationen der Datei).

/data/misc/wifi/WCNSS_qcom_wlan_nv.bin

Es wird offensichtlich sein, sobald Sie einen Hexdump machen. Ich scpte die Datei auf einen normalen Linux-Rechner und generierte mit xxd den Hex-Dump im Text, änderte die Mac-Adresse und generierte die neue bin-Datei. Sie müssen es nur zum Telefon zurücksenden und sicherstellen, dass Sie über die richtigen Eigentumsrechte / Berechtigungen verfügen, WLAN deaktivieren / erneut aktivieren, und Sie sollten bereit sein.

Wenn Sie das Telefon neu starten, wird die Änderung rückgängig gemacht. Ich habe nicht herausgefunden, wie ich den Mac dauerhaft ändern kann.

Ich glaube nicht, dass Ihr Gerät tatsächlich den MAC ändert. Das statische Codieren einer IP auf Ihrem Router wird Ihnen nicht viel nützen, wenn Sie keine L2-Konnektivität haben.

Ich hatte einen Weg gefunden, den MAC auf meinem 2012 N7 zu ändern, indem ich busybox und den Befehl ifconfig verwendete. Versuchen Sie, busybox zu installieren , trennen Sie die Verbindung zum WLAN und führen Sie dann Folgendes als root aus (wobei Sie natürlich Ihren MAC ersetzen).

busybox ifconfig wlan0 hw ether 00:00:00:00:00:00

busybox iplink show wlan0

Funktioniert das für dich?

Die Verwendung ip linkist im Grunde dasselbe wie die Verwendung von ifconfig, also glaube ich nicht, dass es das ist, was es tut ...
Trotzdem einen Versuch wert. Hat für mich funktioniert.
Habe es jetzt probiert. Das Einstellen des MAC mit ifconfig wlan0 hw ethererzeugt leider genau das gleiche Verhalten.
WLAN-Netzwerk mit geänderter MAC-Adresse nicht erreichbar
AntwortenHierDatenschutz-Bestimmungen1y, 0v