USB Networking troubles

michael cole mjcole137 at
Fri Aug 8 12:32:00 CEST 2008

Hi Andrew,

First thanks to all for replying.

These changes worked.

The essence of the change is rather simple -- move the Freerunner to a
different network from the LAN's netwrok
1)  (in my case from to
2) allow the desktop machine to talk to
3) do the masquerading to the 192.168.2.* network.

So on my Freerunner /etc/network/interfaces includes:

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
auto usb0
iface usb0 inet static
# orig:
#	up echo nameserver >/etc/resolv.conf
# using home (
	up echo nameserver >/etc/resolv.conf

on the desktop  /etc/network/interfaces includes:
allow-hotplug usb0
iface usb0 inet static
        post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -P FORWARD ACCEPT
        pre-down iptables -D POSTROUTING -t nat -j MASQUERADE -s

The page at Openmoko on USB Networking should be updated to make clear
the selection of the network for the desktop-freerunner connection
should be different than the rest of the LAN.

Thanks again to everyone.


Is this a typo on the page @ Openmoko

On Thu, Aug 7, 2008 at 6:39 PM, Andrew C. Dingman
<andrew+openmoko at> wrote:
>> This is posted with the hope someone can look at the current state of
>> my Freerunner connection to the desktop and just see something that is
>> not right. I am sure the answer is simple and am reluctant to ask the
>> community for non-FR help but perhaps others are struggling with
>> similar network issues in getting their FR hooked up to the Internet.
>> My basic setup:
>> router -
>> desktop -
>> freerunner -
> You mean it looks something like this:
> router--------switch-------desktop----------freerunner
>             /
>            /
>       other_stuff
>       192.168.1.x
> and everything on the left has a netmask of
> If that's so forget about the FreeRunner talking to anything but the
> desktop. In fact, be suprised and grateful if it's doing that much. The
> routing table you gave is horrible and it will stop working if you
> re-start the non-usb network interface on your machine. You need
> different subnets on the two desktop NICs to have any hope. The only
> possible way around this fact is to use ethernet bridging instead of
> routing on the desktop, and that's such an ugly hack that I refuse to
> work up directions for configuring it. I've never seen it done on a
> network that worked right.
> Your desktop needs to act as a ROUTER for the FreeRunner. A router by
> definition is connected to two or more *different* networks. From the
> perspective of the stuff on the left, the subnet the
> FreeRunner is on is not a different network - it's a few addresses on
> the same network. (This is what netmasks are about. Basically, they tell
> the computer how big the neighborhood is.) Which means they aren't
> sending packets for the FreeRunner through the desktop, they're just
> ARPing and expecting the FreeRunner to respond, but since it's on a
> different network, it can't hear the ARPs. Packets from the FreeRunner
> probably do reach their destinations, but the reply packets don't come
> back, which means you don't get a ping response and can't establish any
> kind of connection.
> The easiest way to fix this is probably to use your half-working setup
> to SSH into the FreeRunner and reconfigure it to use, say,
>, then do the same with the desktop side of the USB
> ethernet connection. Then kill the iptables rules in your nat table
> POSTROUTING chain. You can either:
> 1) Leave them gone and put a static route to in your
> router, specifying your desktop's 192.168.1.x address as the gateway
> OR (exclusive, do not do both of these things)
> 2) specify on the desktop an iptables rule to NAT all packets coming
> from the USB network - something like 'iptables -t nat -A POSTROUTING -s
> Whichever you choose, you'll need the FORWARD chain in the filter table
> in its current permissive state. You'll also want to double-check that
> sysctl net.ipv4.ip_forward=1. The simplest way to check this is
> 'cat /proc/sys/net/ipv4/ip_forward'.
> Hope that helps.
> _______________________________________________
> support mailing list
> support at

Michael Cole
mjcole137 at

More information about the support mailing list