I am trying to get Ethernet over USB working for my Nexus S. I am running Ice Cream Sandwich v4.0.3 and have rebuilt the kernel with USB Gadget support turned on. When I connect the phone to my Linux box and run ifconfig -a, usb0 shows up both on the phone and the Linux box. I run ifconfig to set both sides up and everything looks correct but I cannot ping from either side:
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 Unreachable
I also have a N900 running Maemo Linux that does allow Ethernet over USB. I compared output of ethtool, ifconfig, route, and arp between the N900 and the Nexus S and all are very similar except the arp output. It shows (incomplete) for the HWaddress for the Android connection:
Address HWtype HWaddress Flags Mask Iface
10.1.3.1 ether 00:1B:17:05:30:13 C eth0
192.168.22.2 (incomplete) usb0
The only other clue I have is that ifconfig shows on the Linux side:
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)
and on the Android side:
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)
Notice the dropped packets on the Android side.
It seems like I am almost there.. any suggestions?
EDIT:
I rebuilt the kernel with a gadget kernel module (I have tried both g_cdc and g_ether) instead of built in support. I am not sure if the following is due to that or just being out of sync in my earlier post. If I run ping on either side, the TX and RX numbers actually match on both sides, but the Android side is dropping them for some reason.
Host side 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)
Android side 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)
ANOTHER EDIT!!
After using arp on the host side and ip on the android side to manually add entries, the Destination Host Unreachable errors went away but still no ping response. I ran Wireshark on the host and the messages from the device are not correct. The displayed mac addresses do not look right and the protocol is unknown so just displayed as 0x7aab. After looking at the actual data in the message it appears that there are two zero bytes prepended to the message. If those were removed it looks like everything would line up and work. Has anyone ever seen this or know where in the code this can be fixed ?
YET ANOTHER EDIT!!!
After booting everything up this morning, I did not create the fake ARP entries and ran the pings again. According to Wireshark there was an ARP message coming from the host and an unknown message coming from the Droid, but they were identical lengths. After examining the contents of the messages, the Droid was sending what appeared to be a valid ARP message as well but it was shifted by 2 bytes - two extra bytes at the beginning and the last two chopped off.