Estoy intentando que funcione Ethernet por USB para mi Nexus S. Estoy ejecutando Ice Cream Sandwich v4.0.3 y he reconstruido el kernel con el soporte de USB Gadget activado. Cuando conecto el teléfono a mi caja de Linux y ejecuto ifconfig -a, aparece usb0 tanto en el teléfono como en la caja de Linux. Ejecuto ifconfig para configurar ambos lados y todo se ve correcto pero no puedo hacer ping de ningún lado:
PING 192.168.22.2 (192.168.22.2) 56(84) bytes of data.
From 192.168.22.1 icmp_seq=1 Destination Host Unreachable
From 192.168.22.1 icmp_seq=2 Destination Host UnreachableTambién tengo un N900 corriendo Maemo Linux que permite Ethernet sobre USB. Comparé la salida de ethtool, ifconfig, route y arp entre el N900 y el Nexus S y todas son muy similares excepto la salida arp. Se muestra (incompleta) para la dirección HW para la conexión Android:
Address HWtype HWaddress Flags Mask Iface
10.1.3.1 ether 00:1B:17:05:30:13 C eth0
192.168.22.2 (incomplete) usb0La única otra pista que tengo es que ifconfig aparece en el lado de Linux:
usb0 Link encap:Ethernet HWaddr 66:E4:64:10:D1:A9
inet addr:192.168.22.1 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::64e4:64ff:fe10:d1a9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:9039 (8.8 KiB)y en el lado de los Androids:
usb0 Link encap:Ethernet HWaddr 7A:78:28:52:9C:A0
inet addr:192.168.22.2 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::7878:28ff:fe52:9ca0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:202 errors:0 dropped:202 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47294 (46.1 KiB) TX bytes:1728 (1.6 KiB)Fíjese en los paquetes lanzados en el lado de los Androids.
Parece que ya casi estoy allí ¿Alguna sugerencia?
EDITAR:
Reconstruí el kernel con un módulo de kernel gadget (he probado tanto g_cdc como g_ether) en lugar de tener soporte integrado. No estoy seguro de si lo siguiente se debe a eso o simplemente a estar fuera de sincronía en mi anterior post. Si ejecuto ping en cualquiera de los dos lados, los números TX y RX coinciden en realidad en ambos lados, pero el lado Android los está dejando caer por alguna razón.
Lado del anfitrión ifconfig:
usb0 Link encap:Ethernet HWaddr 12:23:34:45:56:67
inet addr:192.168.22.1 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::1023:34ff:fe45:5667/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:734 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1140 (1.1 KiB) TX bytes:37684 (36.8 KiB)Lado Android ifconfig:
usb0 Link encap:Ethernet HWaddr 5E:89:C6:D8:BC:08
inet addr:192.168.22.2 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::5c89:c6ff:fed8:bc08/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:734 errors:0 dropped:734 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:27408 (26.7 KiB) TX bytes:1602 (1.5 KiB)¡OTRA EDICIÓN!
Después de usar arp en el lado del host e ip en el lado de Android para añadir entradas manualmente, los errores de "Host de destino inalcanzable" desaparecieron pero aún no hay respuesta de ping. Corrí Wireshark en el host y los mensajes del dispositivo no son correctos. Las direcciones mac no se ven bien y el protocolo es desconocido, así que sólo se muestra como 0x7aab. Después de mirar los datos reales en el mensaje parece que hay dos cero bytes preparados para el mensaje. Si esos fueran eliminados parece que todo se alinearía y funcionaría. ¿Alguien ha visto esto o sabe en qué parte del código se puede arreglar?
¡¡¡OTRA EDICIÓN MÁS!!!
Después de arrancar todo esta mañana, no creé las entradas falsas del ARP y volví a ejecutar los pings. Según Wireshark había un mensaje ARP que venía del anfitrión y un mensaje desconocido que venía del droide, pero eran de idéntica longitud. Después de examinar el contenido de los mensajes, el droide estaba enviando lo que parecía ser un mensaje ARP válido también, pero fue desplazado por 2 bytes - dos bytes extra al principio y los dos últimos cortados.
