Konfiguration eines neuen Netzwerk-Interfaces in Android

[u.k-f]

Jetzt kann ich mal die Gelegenheit nutzen, und mich als SUPER-NOOB präsentieren:

Angeregt von dem kleinen Module-Komplier-Exkurs vorhin habe ich mir mal flott die Sourcen für einen AX88179 USB-LAN Adapter Treiber gezogen und ein ko erstellt.

Das Problem an der Geschichte ist jetzt das, dass ich von Linux-Netzwerk genau keine Ahnung habe

Was ich hinbekommen habe:

insmod /system/lib/modules/ax88179_178a.ko
busybox ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0A:CD:20:FB:55
          BROADCAST MULTICAST  MTU:1488  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

war nicht, was ich erwartet hätte. Ich dachte eigentlich, eth0 wäre reserviert, und ich bekäme als neuen Netwerk-Device eth1 zugewiesen (aber an der MAC-Addresse 00:0A:CD:20:FB:55 kann ich ganz klar erkennen, dass das mein Asix AX88179 ist.)

Nach zuweisung einer festen IP-Addresse, einer Route zum default Gateway und eines DNS

busybox ipconfig eth0 192.168.x.y netmask 255.255.255.0
route add default gw 192.168.x.z dev eth0
setprop net.eth0.dns1 192.168.x.z

busybox ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0A:CD:20:FB:55
          inet addr:192.168.x.y  Bcast:192.168.x.255  Mask:255.255.255.0
          inet6 addr: xxxxxxxxxxxxxxxxxxx Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1488  Metric:1
          RX packets:881 errors:1 dropped:0 overruns:0 frame:1
          TX packets:891 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:564704 (551.4 KiB)  TX bytes:181855 (177.5 KiB)

hatte ich Internetzugang über mein LAN...

Aber ich wollte eigentlich, das das ganze über DHCP geht.

Mein (zugegeben unausgereifter) Plan war, in der init.picasseo_e2.rc (Mein Board heisst picasso_e2) einfach die Einträge für wlan0 zu nehmen und als eth1 zu kopieren (Da ich dachte, mein neuer Netzwerk-Adapter würde als eth1 auftauchen), nur sind in der init.picasso_e2.rc shon Einträge für eth0 drin, aber die unterscheiden sich von den für wlan0:

service dhcpcd_wlan0 /system/bin/dhcpcd -BK
    class main
    disabled
    oneshot

service dhcpcd_eth0 /system/bin/dhcpcd -ABKL -f/system/etc/dhcpcd/dhcpcd.conf
     class main
     disabled
     oneshot

service dhcpcd_p2p /system/bin/dhcpcd -aABKL
     class main
     disabled
     oneshot

service iprenew_wlan0 /system/bin/dhcpcd -n
    class main
    disabled
    oneshot

service iprenew_eth0 /system/bin/dhcpcd -n
    class main
    disabled
    oneshot

service iprenew_p2p /system/bin/dhcpcd -n
    class main
    disabled
    oneshot

Ich wäre jetzt nicht so dreist, einfach 'gestrichen:PapaMama perpe' zu fragen, was ich machen kann, aber über hilfreiche Hinweise auf geeignete Tutorials wäre ich schon dankbar...:blushing:

Und wenn es nich gar zu unverschämt wäre erlaube ich mir mal die Frage, was es bei Android eigentlich mit dem eth0 auf sich hat, warum ist denn dieser Netzwerk-Device schon vorkonfiguriert?

Grüsse Uwe

Der ursprüngliche Beitrag von 01:51 Uhr wurde um 03:24 Uhr ergänzt:

Wenn ich nach dem anstöpseln von dem LAN-Adapter eingebe

netcfg eth0 dhcp
setprop net.dns1 $(getprop net.eth0.dns1)

bekomme ich vom dhcp eine IP-Adresse, eine Route zum Default-Gateway und auch einen DNS-Server (Leider nur in net.eth0.dns1, muss ihn von Hand nach net.dns1 kopieren)

Aber leider nicht automatisch.

Daran muss noch gearbeitet werden...(Auch da wäre ich dankbar für Tipps...)

Grüsse Uwe

 

[perpe]

Ich dachte eigentlich, eth0 wäre reserviert, und ich bekäme als neuen Netwerk-Device eth1 zugewiesen

eth0 ist nur reserviert, wenn du eine Netzwerkkarte hast, sie ist dann eth0. Die Bezeichnung ist immer in der Reihenfolge der Bereitstellung und fängt bei 0 an. Da dein Tablet keine Ethernet Karte hat, gibt es auch kein belegtes eth0, da es frei ist, bekommt dein Adapter eth0.
Bei manchen Adapter Modulen kann man eine Wunschbezeichnung als Option beim Laden des Modules mitgeben. Ob das bei deinem möglich ist, müsstest du mit modinfo herausfinden.

Mein (zugegeben unausgereifter) Plan war, in der init.picasseo_e2.rc

Wenn du das immer noch willst, dann bedenke das die init.picasseo_e2.rc Teil der Ramdisk (in der boot.img) ist und daher Änderungen nicht dauerhaft gespeichert werden, außer natürlich du erstellst dir eine neue boot.img mit der veränderten init.picasseo_e2.rc und flashst sie.

nur sind in der init.picasso_e2.rc shon Einträge für eth0 drin, aber die unterscheiden sich von den für wlan0:

was die Einstellungen bedeuten findest du z.B. auf dhcpcd.8 Für dich interessant sind z.B. AL, beide schalten IPv4LL (Zeroconf) ab, wodurch dein eth0 keine ip vom Server bezieht und du es manuell konfigurieren musst.

aber über hilfreiche Hinweise auf geeignete Tutorials wäre ich schon dankbar...

Zu erst solltest du schauen, was in der /system/etc/dhcpcd/dhcpcd.conf drin steht, da sie die Konfigurationdatei für dein eth0 ist. Sie kannst du mit root ändern ohne eine neue boot.img zu erstellen Dabei kannst du auch testen, ob die Einstellungen in der Konfigurationsdatei auch die vorgegebenen Einstellungen in der init.picasseo_e2.rc überschreiben. Dann würde ein Ändern der init.picasseo_e2.rc komplett entfallen.

was es bei Android eigentlich mit dem eth0 auf sich hat, warum ist denn dieser Netzwerk-Device schon vorkonfiguriert?

Warum das so ist, kann ich dir nicht mit Sicherheit sagen, aber ein paar Theorien:
1. eth0 wird im Android Emulator als virtuelle Netzwerkkarte erstellt, damit man sowohl von Emulator die Verbindung des Rechner nutzen kann als auch vom Rechner mit dem Emulator kommunizieren kann. Können also Reste vom AOSP sein, die dein Hersteller nicht rausgenommen hat
2. Die Hersteller schreiben nicht alles selber sondern nehmen neben dem AOSP Code auch vorbereiteten Code der SoC Hersteller, ändern daraus nur das was sie müssen. eth0 ist z.B. auf vielen Tegra Geräten vorkonfiguriert, auf Snapdragon Geräten ehr seltener.
3. Dein Hersteller wollte nett sein und schon mal eine Basis für Ethernetadapter Nutzung schaffen. Machen viele Hersteller der China Tablets, bei manchen ist der Adapter sogar beigelegt.

Such dir also eins aus. Ich tendiere auf 1 und 2. Ändere soviel wie nötig, so wenig wie möglich, wozu sich sinnlose Arbeit machen?

Hoffe habe nichts vergessen.




PS: Also wenn, dann bitte "Mama perpe"

 

[u.k-f]

Danke für die umfassende Erklärung, Du hast mich einen grossen Schritt weitergebracht!

Und: Ich bitte um Entschuldigung, ich hätte es ja schon an Deinem Avatar sehen können :blushing:

Grüsse Uwe

Der ursprüngliche Beitrag von 19:55 Uhr wurde um 20:11 Uhr ergänzt:

Noch ein kleiner Nachtrag zum Thema boot.img ändern:

Ich bin biete einen CustomKernel an: Kiwi++Kernel. Daher war für mich bis vor kurzem das boot.img das einzige, was ich ausgeliefert habe und somit durchaus eine Stelle, an der ich gerne Änderungen vorgenommen habe. Aber zugegeben, das ist nicht die Stelle, wo normal geändert wird...

Erst wegen den Tools, die ich inzwischen mit ausliefere, bin ich auf ein CWM installierbares ZIP umgestiegen.

Grüsse Uwe

 

[perpe]

Wenn du schon eine App zum Verwalten der Einstellungen hast, ist evt. eine andere Lösung besser.
init.picasseo_e2.rc wird nur beim Boot ausgeführt, du nutzt noch init.d, daher brauchtest in der init.picasseo_e2.rc auch nichts ändern. Ob eine Änderung dort was bringt, ist wohl auch fraglich, da der Adapter sicher beim Boot meist nicht angeschlossen ist und die Konfiguration für eth0 ins Leere läuft.

Besser wäre, wenn es mit der App genutzt wird, in deine App ein USB Accessory Service einzubauen. Die lässt du starten, wenn Geräte mit Vendor id und Product id (am besten alle auflisten, die vom Modul unterstützt werden) des Adapters angeschlossen werden, dann kannst du in dem Service dein Modul laden und eth0 konfigurieren.

 

[u.k-f]

...was die Einstellungen bedeuten findest du z.B. auf dhcpcd.8 Für dich interessant sind z.B. AL, beide schalten IPv4LL (Zeroconf) ab, wodurch dein eth0 keine ip vom Server bezieht und du es manuell konfigurieren musst.


Zu erst solltest du schauen, was in der /system/etc/dhcpcd/dhcpcd.conf drin steht, da sie die Konfigurationdatei für dein eth0 ist. Sie kannst du mit root ändern ohne eine neue boot.img zu erstellen Dabei kannst du auch testen, ob die Einstellungen in der Konfigurationsdatei auch die vorgegebenen Einstellungen in der init.picasseo_e2.rc überschreiben. Dann würde ein Ändern der init.picasseo_e2.rc komplett entfallen.
...

Ich habe die Einstellung so angepasst, dass eigentlich ein Service laufen sollte, der auf Änderungen im eth0 reagiert, aber der tut nicht wirklich, was er sollte. Ich stecke da aber auch nicht zuviel Energie rein denn:

Wenn du schon eine App zum Verwalten der Einstellungen hast, ist evt. eine andere Lösung besser.
init.picasseo_e2.rc wird nur beim Boot ausgeführt, du nutzt noch init.d, daher brauchtest in der init.picasseo_e2.rc auch nichts ändern. Ob eine Änderung dort was bringt, ist wohl auch fraglich, da der Adapter sicher beim Boot meist nicht angeschlossen ist und die Konfiguration für eth0 ins Leere läuft.

Besser wäre, wenn es mit der App genutzt wird, in deine App ein USB Accessory Service einzubauen. Die lässt du starten, wenn Geräte mit Vendor id und Product id (am besten alle auflisten, die vom Modul unterstützt werden) des Adapters angeschlossen werden, dann kannst du in dem Service dein Modul laden und eth0 konfigurieren.

Ich denke diesen Ansatz werde ich weiter verfolgen, denn ich brauche ja auch eine Konfigurationmöglichkeit für eth0, wenn kein DHCP läuft (Ist ja nicht wegen mir, sondern weil ein paar User meines Kernels gerne einen USB-LAN Adapter wollten, und da weis ich nicht, ob die einen DHCP haben...

Und es gehört ja auch zur Vollständigkeit dazu, eine Konfig anzubieten...

ggf muss ja auch ein Proxy für eth0 eingestellt werden können...

Noch eine andere Geschichte. Der Google-Playstore hat die unangenehme Eigenschaft, dass er zwar zum Suchen und zum anzeigen jeden verfügbaren Netzwerk-Adapter nutzt, aber beim Download will er nur wlan0 (oder ggf eine UMTS/GPRS Verbindung) nutzen. Hasst Du dazu eine Idee?

Grüsse Uwe

 

[perpe]

Wie du das Problem lösen kannst, weiß ich nicht, jedoch vielleicht ein Anhaltspunkt:
Wenn man am Tab einen UMTS Stick anschließt verhält sich der Play Store genauso, da die Verbindung keine offizielle ist.
Mit der App UMTS Manager ist das so (sofern es nicht zwischenzeitlich gefixt wurde)
Der Entwickler der App PPP Widget hat in seiner App das Problem umgangen und Downloads aus dem Play Store funktionieren.

Die Lösung von PPP Widget ist evt. auch auf eine LAN Verbindung übertragbar, wie der Entwickler das gelöst hat, musst du jedoch selber rausfinden oder den Entwickler kontaktieren. So ganz unmöglich scheint es also nicht zu sein.

 

[u.k-f]

Ein Arbeitskollege sagte mir, er hätte einen Artikel gelesen, in dem stand, dass der Download des Playstores eine Bibliotheksfunktion verwenden würde, die die verfügbaren Internet-Verbindungen auflisten würde. Wenn das so wäre, könnte man die entsprechende lib ggf patchen. Leider konnte der Kollege den entsprechenden Artikel nicht mehr finden.

Grüsse Uwe

 

[perpe]

Ich weiß ja nicht wieviel Arbeit du dir machen möchtest und ob das ganze dann in eine AOSP ROM kommt oder mit einer auf Stock basierenden ROM funktionieren soll.
Wenn du jedoch System Dateien/Bibliotheken Patchen willst, dann schau dich beim Android-x86 Projekt um. Für ICS haben sie einen Patch für Ethernet, die Einstellungen kann man dann direkt in den Android Einstellungen tätigen und Play Store funktioniert damit auch.
Ist jedoch für x86. Das Android-x86 Projekt basiert zwar auf AOSP haben jedoch ihre eigenen Repos, da sehr viel verändert wurde. Du müsstest also den Patch vor dem Anwenden kompatibel mit dem offiziellen AOSP Code machen.

Den Patch findest du auf Ethernet patch for the 4.0.4 ics-x86 variants (GoogleGroups) im ersten Beitrag.

(Edit: Ist schon lang her, dass ich mit Android x86 gespielt hatte, wenn ich mich recht entsinne, musste man wlan ausmachen, damit es dann auch funktionierte... irgend sowas war da noch)

 

[u.k-f]

Ich habe jetzt letztlich die Lösung gewählt, dass ich einen Service geschrieben habe, der im Hintergrung läuft und den Netzwerk status überwacht, da ich auf verschiedene Situationen reagieren muss, die nicht nur vom USB Status abhängen:

Wenn der USB-Adapeter schon angeschlossen ist, aber kein LAN-Kabel reingesteckt ist, kann ich noch nicht netcfg eth0 dhcp aufrufen.

Wenn das LAN-Kabel abgezogen wird, muss ich die DHCP Einstellung als ungültig markieren und wenn das Kabel wieder angesteckt wird, muss ich erneut anfragen, das der Adapter ja in ein anderes Netzwerk eingesteckt werden könnte, wo andere IP Einstellungen gelten.

Ich habe noch nicht die Behandlung für alle möglichen Fälle implementiert, bin aber dran...

Grüsse Uwe