Talk:USB Networking

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(additional use case / suggestions)
(Driver options in kernel config)
 
(30 intermediate revisions by 15 users not shown)
Line 1: Line 1:
 +
= Yet another suggestion for USB Networking =
 +
Hi. I suggest using:
 +
* /etc/udev/rules.d/70-persistent-net.rules to rename eth* to usb0 (afterwards restarting udev), e.g. on recent Ubuntus:
 +
# USB device 0x1457:0x5122 (usb)
 +
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:11:01:3b:93" ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="usb0"
 +
* Then use e.g. the network-manager in user space to configure the device "usb0" as proposed by others, e.g. 192.168.0.200 with 192.168.0.192/26, or similarly, or with a different IP, if you want.
 +
* Then make a link /etc/network/if-up.d/freerunner to /usr/local/bin/freerunner.sh and similarly from /etc/network/if-up.d/freerunner with content of the script:
 +
#!/bin/sh
 +
MY_IFACE="usb0"
 +
MY_NETWORK="192.168.0.0/24"
 +
 +
if [ "$IFACE" != "$MY_IFACE" ]; then
 +
    exit 0
 +
fi
 +
 +
IPNET=$MY_NETWORK
 +
# alternatively:
 +
#ret1(){ echo $1;}
 +
#IPNET=`ret1${IP4_ADDRESS_0}`                       
 +
 +
case "$MODE" in
 +
    start)
 +
        /sbin/iptables -A POSTROUTING -t nat -j MASQUERADE -s $IPNET
 +
        /sbin/sysctl -w net.ipv4.ip_forward=1
 +
[ $VERBOSITY -gt 0 ] && logger "added freerunner routing"
 +
;;
 +
    stop)
 +
        /sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s $IPNET
 +
/sbin/sysctl -w net.ipv4.ip_forward=0
 +
[ $VERBOSITY -gt 0 ] && logger "removed freerunner routing"
 +
;;
 +
    *) exit 0
 +
esac
 +
* This will set up the masquerading, as others proposed it, and will remove it on usb-network down events.
 +
 +
What do you think? --[[User:Factor4|Factor4]] 00:52, 6 January 2010 (UTC)
 +
 +
= Driver options in kernel config =
 +
Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your
 +
desktop as a host are not in "USB Support" as the article says:
 +
"Both options are available in the Device Drivers -> USB support -> USB Network Adapters. For more info see the usbnet driver homepage."
 +
Aren't the options in <pre>Device Drivers -> Network Device Support -> USB Network Adapters</pre>
 +
Can someone confirm this? I don't want to send people in the wrong direction, but that is the way it is in my system. Thanks. [[User:Mmanjos|Mmanjos]] 15:36, 4 November 2007 (CET)
 +
 
= Thoughts on USB networking in the final product =
 
= Thoughts on USB networking in the final product =
  
Line 4: Line 48:
  
 
The Neo's IP will probably need to remain static, and chosen, as it is now, from some local address space. I would personally suggest to change to using an address higher in the 192.168.0.0 space, say, 192.168.19.73 (ehhehe) to reduce chance of conflicts. (Or use link-local space?)
 
The Neo's IP will probably need to remain static, and chosen, as it is now, from some local address space. I would personally suggest to change to using an address higher in the 192.168.0.0 space, say, 192.168.19.73 (ehhehe) to reduce chance of conflicts. (Or use link-local space?)
 +
* I don't think the 192.168.0.0 space is very problematic if network is configured as 192.168.0.192/26 instead of 192.168.0.0/24, as explained in the Debian example I've just enhanced in the page. [[User:OlivierBerger|OlivierBerger]] 07:35, 25 July 2008 (UTC)
  
 
Anyway, for the casual user, and even comfort-seeking geeks, OpenMoko will need to provide DHCP service. It will probably be also a good idea to run a DNS proxy, since that way the host doesn't need to care about changing DNS servers, and the caching is a good idea anyway for high latency GPRS. I'd suggest dnsmasq, which is simple and can handle both tasks. I assume the Neo will do IP masquerading for the USB host when it's acting as its default gateway.
 
Anyway, for the casual user, and even comfort-seeking geeks, OpenMoko will need to provide DHCP service. It will probably be also a good idea to run a DNS proxy, since that way the host doesn't need to care about changing DNS servers, and the caching is a good idea anyway for high latency GPRS. I'd suggest dnsmasq, which is simple and can handle both tasks. I assume the Neo will do IP masquerading for the USB host when it's acting as its default gateway.
Line 41: Line 86:
 
How to deal with Bluetooth and WiFi routing (for GTA02) in conjuction? Probably you'd not want to serve up default gateway per default if you're BT tethered, however, user might want to have one device BT tethered and another USB tethered. So perhaps best to leave the option open to share the connection via USB even if BT tethering is active, though especially in this case the option shouldn't be obtrusive; it'd probably be a rare use case.
 
How to deal with Bluetooth and WiFi routing (for GTA02) in conjuction? Probably you'd not want to serve up default gateway per default if you're BT tethered, however, user might want to have one device BT tethered and another USB tethered. So perhaps best to leave the option open to share the connection via USB even if BT tethering is active, though especially in this case the option shouldn't be obtrusive; it'd probably be a rare use case.
  
== Additional use cases ==
+
=== Additional use cases ===
  
 
There is another use cases I'd  like to suggest for consideration:
 
There is another use cases I'd  like to suggest for consideration:
Line 50: Line 95:
 
* Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.
 
* Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.
  
== additional use case / suggestions ==
+
= Operation on Gentoo =
  
There is another use cases I'd  like to suggest for consideration:
+
One way of doing routing and NAT was recently added to the Wiki.  I followed the lead of the other examples and did it this way:
  
* Bertrand (who has a good broadband connection at home) lives in Expensive GPRS Country and has no Bluetooth / WLAN. He wants to plug his phone into his computer and run ipkg updates via his broadband connection. His PC is serving as a DHCP server and/or bridges all traffic through its interfaces (with STP preventing loops).
+
  # Neo1973
 +
  config_usb0=( "192.168.0.200 netmask 255.255.255.0" )
 +
  postup() {
 +
    case "${IFVAR}" in  
 +
        "usb0")
 +
            iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
 +
            echo 1 > /proc/sys/net/ipv4/ip_forward
 +
            iptables -P FORWARD ACCEPT
 +
            return 0;;
 +
    esac
 +
    return 0
 +
  }
 +
  predown() {
 +
    case "${IFVAR}" in
 +
        "usb0")
 +
            iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
 +
            echo 0 > /proc/sys/net/ipv4/ip_forward
 +
            return 0;;
 +
    esac
 +
    return 0
 +
  }
  
Suggested policy:
+
If the intent is to have the NATing and routing turn on and off as the neo is plugged and unplugged, this is probably an approach that is more like that than the other way.
* Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.
+
 
 +
== Dealing with NetworkManager ==
 +
 
 +
NetworkManager (the default for [http://www.sabayonlinux.org/ sabayon]) bypasses /etc/conf.d/net.usb0 by default. You need to modify /etc/conf.d/rc (or /etc/rc.conf on OpenRC) from
 +
RC_PLUG_SERVICES="!net.*"
 +
to somehing like
 +
RC_PLUG_SERVICES="!net.eth* !net.wlan*"
 +
 
 +
(see http://gentoo-wiki.com/HOWTO_NetworkManager)
 +
 
 +
= Rewrite =
 +
 
 +
I have rewritten this page for accuracy and clarity.  I took out redundant stuff, and tried to make it much clearer based upon my networking experience and discussions with users having problems in the #openmoko IRC channel.  I tried to avoid and remove first person comments (although made some myself). 
 +
 
 +
The first section is very deliberate, since the ordering of this page was illogical, having gathered many random comments.  This allows user to step through the parts and make sure each is right before moving on.  There are further explanations that could be added - instead of a subnet, an explicit device route could be added for the .202 host, over USB. which avoids most routing problems (unless your desktop is also .202).  I hope though even without that, this covers most scenarios.  I intend to rewrite some of the other pages in the same way.
 +
 
 +
= Changing flow =
 +
 
 +
Miohtama, I'm not entirely happy about your unjustified reordering.  The page was structured in order to carefully explain to new users how to make it work, and for it be a very precise guide for helping those on IRC having problems - users I deal with. I don't believe that your changes really facilitate that.  Putting stuff together because it seems to might superficially seem like a good idea, but it's not always.
 +
 
 +
== Overlapping subnets ==
 +
 
 +
 
 +
Please don't keep adding assertions that overlapping subnets don't work, or that assumptions are being made that they are different.  It does work, with a sufficiently small subnet for the FR (as the examples show).  Adding comments about insisting that users change their LAN subnets is unnecessary, and makes it that much harder for users - where this page was originally.
 +
 
 +
 
 +
== Latest changes ==
 +
I found out that with my Kubuntu 8.10 without the «auto usb0» option in /etc/network/interfaces the USB networking wasn't able to work automatically.
 +
Adding that line makes everything work fine: plug-in the NEO, it gets recognized, give ssh openmoko and you're done. No problems with default networkmanager.
 +
So my question is: why do you think that option should not be there?
 +
 
 +
 
 +
== displaying desktop application on freeruner ==
 +
If you consider, that you want to see your desktop application on Freerunner you have to install openssh-ssh server instead dropbear and then you can
 +
<pre>
 +
ssh -X login@192.168.0.200
 +
xclock
 +
</pre>
 +
 
 +
==Script==
 +
sudo iptables -F <br>
 +
sudo ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br>
 +
sudo route add 192.168.0.202 usb0<br>
 +
sudo iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br>
 +
sudo iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br>
 +
sudo iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br>
 +
sudo echo 1 > /proc/sys/net/ipv4/ip_forward<br>
 +
 
 +
== no inet in interfaces ==
 +
I think the inet label in interfaces for eth1 (when openmoko is on eth1 like Ubuntu 9.04) causes the host (laptop) to try to make a connection to the internet via the openmoko device. This could be just the opposite of what you want. I'm not an expert on this but removing inet in interfaces for the openmoko devices fixed my problem. Any comments on this? [[User:Pander|Pander]] 08:49, 16 June 2009 (UTC)
 +
 
 +
I merely checked on /etc/udev/rules.d which interface would be used ( eth1 ) Then went to System/Administration/Network and there gave the address netmask and the default gateway for eth1 -- simple and no problem. The default GW is the gateway of the system. On laptop like you did. All works well Internet for laptop and contact with Freerunner.
 +
 
 +
Did not check yet if i can go to the internet from the Freerunner  via eth1, wlan is OK
 +
 +
Carig Philippines --[[User:Frank|frank]] 14:50, 17 June 2009 (UTC)
 +
 
 +
= Ubuntu Instructions =
 +
 
 +
I find the 8.10 instructions clearer and more to the point than the 9.04 ones. Moreover, the 9.04 ones don't feature actual routing, so I'd suggest deleting the 9.04 section, and adding a note to the 8.10 sections that with Qi, it's eth1 and not usb0. Also, one question: does anyone know if the routing given by the iptables commands in the 8.10 section can also be achieved just by using the System > Administration > Network > eth1 > IPv4 Settings > Routes dialog? --[[User:Ockham|Ockham]] 18:55, 5 July 2009 (UTC)
 +
 
 +
==Using network-manager on systems using udev==
 +
following these steps i found that iptables is not set correctly (cannot reach the web from FR) i tried manually executing
 +
sudo /usr/local/sbin/freerunner-usb-add.sh
 +
and everything i got was
 +
Cannot find device "00:00:22:55:bb:00"
 +
what's wrong?
 +
 
 +
--[[User:Dareus|Dareus]] 15:24, 14 July 2009 (CET)
 +
 
 +
 
 +
==Experience on SHR in Version 209-05-02 / OpenSuse 11.1==
 +
my route before hacking was without router:
 +
 
 +
(route add default dev usb0)
 +
 
 +
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
 +
192.168.0.0    0.0.0.0        255.255.255.0  U    0      0        0 usb0
 +
0.0.0.0        0.0.0.0        0.0.0.0        U    0      0        0 usb0
 +
... and (in my oppinion) should work, but did'nt route anything further than to my host 10.0.0.1
 +
 
 +
(which is on a router(10.0.0.254) to outside in an Class A Network 10.0.0.0/8)
 +
 
 +
i changed that to:
 +
 
 +
(route add default gw 192.168.0.200 dev usb0)
 +
 
 +
and got the working variant:
 +
 
 +
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
 +
192.168.0.0    0.0.0.0        255.255.255.0  U    0      0        0 usb0
 +
0.0.0.0        192.168.0.200  0.0.0.0        UG    0      0        0 usb0
 +
So maybe, the order in which /etc/network/interfaces configures usb0 seems to be the problem:
 +
 
 +
i changed it to:
 +
 
 +
auto usb0
 +
iface usb0 inet static
 +
        address 192.168.0.202
 +
        network 192.168.0.0
 +
        netmask 255.255.255.0
 +
        gateway 192.168.0.200
 +
 
 +
this works fine here on SHR [[without any firewall/nat/masquerade/routing]] etc.

Latest revision as of 01:52, 6 January 2010

Contents

[edit] Yet another suggestion for USB Networking

Hi. I suggest using:

  • /etc/udev/rules.d/70-persistent-net.rules to rename eth* to usb0 (afterwards restarting udev), e.g. on recent Ubuntus:
# USB device 0x1457:0x5122 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:11:01:3b:93" ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="usb0"
  • Then use e.g. the network-manager in user space to configure the device "usb0" as proposed by others, e.g. 192.168.0.200 with 192.168.0.192/26, or similarly, or with a different IP, if you want.
  • Then make a link /etc/network/if-up.d/freerunner to /usr/local/bin/freerunner.sh and similarly from /etc/network/if-up.d/freerunner with content of the script:
#!/bin/sh 
MY_IFACE="usb0"
MY_NETWORK="192.168.0.0/24"

if [ "$IFACE" != "$MY_IFACE" ]; then
    exit 0
fi

IPNET=$MY_NETWORK
# alternatively:
#ret1(){ echo $1;}
#IPNET=`ret1${IP4_ADDRESS_0}`                         

case "$MODE" in
    start)
        /sbin/iptables -A POSTROUTING -t nat -j MASQUERADE -s $IPNET 
        /sbin/sysctl -w net.ipv4.ip_forward=1
	 [ $VERBOSITY -gt 0 ] && logger "added freerunner routing"
	 ;;
    stop)
        /sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s $IPNET
	 /sbin/sysctl -w net.ipv4.ip_forward=0
	 [ $VERBOSITY -gt 0 ] && logger "removed freerunner routing"
	 ;;
    *) exit 0
esac
  • This will set up the masquerading, as others proposed it, and will remove it on usb-network down events.

What do you think? --Factor4 00:52, 6 January 2010 (UTC)

[edit] Driver options in kernel config

Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your desktop as a host are not in "USB Support" as the article says: "Both options are available in the Device Drivers -> USB support -> USB Network Adapters. For more info see the usbnet driver homepage."

Aren't the options in
Device Drivers -> Network Device Support -> USB Network Adapters

Can someone confirm this? I don't want to send people in the wrong direction, but that is the way it is in my system. Thanks. Mmanjos 15:36, 4 November 2007 (CET)

[edit] Thoughts on USB networking in the final product

There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.

The Neo's IP will probably need to remain static, and chosen, as it is now, from some local address space. I would personally suggest to change to using an address higher in the 192.168.0.0 space, say, 192.168.19.73 (ehhehe) to reduce chance of conflicts. (Or use link-local space?)

  • I don't think the 192.168.0.0 space is very problematic if network is configured as 192.168.0.192/26 instead of 192.168.0.0/24, as explained in the Debian example I've just enhanced in the page. OlivierBerger 07:35, 25 July 2008 (UTC)

Anyway, for the casual user, and even comfort-seeking geeks, OpenMoko will need to provide DHCP service. It will probably be also a good idea to run a DNS proxy, since that way the host doesn't need to care about changing DNS servers, and the caching is a good idea anyway for high latency GPRS. I'd suggest dnsmasq, which is simple and can handle both tasks. I assume the Neo will do IP masquerading for the USB host when it's acting as its default gateway.

Now, the DHCP server should obviously serve up a local address to the USB host when connected (assuming here most hosts will use DHCP by default to configure the USB network device, which I think is a valid assumption, and if some don't, we can't help things automagically anyway).

What's more complicated is when to give a default gateway and a DNS server address. You don't want to do it all the time, that would screw with simple use cases (detailed more below).

[edit] Suggested policies

At this point I suggest, based on the aforementioned IRC discussion, the following policy:

1) If the device is plugged into a host, and the device is not on-line with GPRS, do not go on-line, and only give a private address (no default route/dns) to host.

2) If the phone is told to go on-line with GPRS (or, in the future, other mobile protocols) and it's presently hooked up to a USB host with only a local network connection, query the user if they want to use the Internet also from the computer. If yes, run the interface down, then up again, thus triggering the host to make a new DHCP query. Now serve up default gateway and dns information too.

3) If the phone is told to go off-line while routing a network connection to a USB host, cycle the interface again and only serve up a local address. Possibly ask if the user really wants to disconnect considering the tether.

4) If the phone is presently on-line with GPRS, and it's plugged into a host, initialize with only the local network connection, query the user (with a dialog or less obtrusively with a suitable panel button or panel GPRS menu changing appearance) whether they want to use the connection from the computer too. If yes, cycle interface, serve up default gateway and dns. Remove the query if usb disconnected.

[edit] Use cases

The rationale for not serving up a default route too eagerly is that this device charges from USB, people will probably sync it via USB, and they don't want any hassle doing that. Use cases to demonstrate:

1) John wants to sync addressbooks between his home desktop and the Neo. He uses USBnet for this, because where he lives, GPRS is crazy expensive, and besides, he doesn't want to have internet-visible servers on the desktop. He hooks the Neo up, and only wants local data transfer capabilities. What he doesn't want is to lose access to his broadband, so serving up default gateway and DNS would make him angry.

2) Shirley has CommunitasticoMoko installed on her Neo, and thus is on-line via GPRS pretty much constantly. (Yes, Shirley lives in some more GPRS-friendly area.) Shirley wants to load up new music from her desktop to the phone, so she hooks the Neo up. Even though GPRS is on-line for CommunitasticoMoko, she doesn't want the desktop to suddenly lose her home broadband access. She gets asked (in the more or less obtrusive ways above) if she'd like to provide Internet access to the host. She doesn't care about the question, just transfers the files, unhooks, and is on the go. The query disappears, not bothering her anymore.

3) Shirley's CommunitasticoMoko buddy Roxanne hooks the Neo up to her laptop. As she is also on-line via GPRS, she gets the query. She first thinks to only sync up the address books of her laptop and the Neo, but while doing that, she decides to go surfing for a bit too. Up till now, she's had a local network between the devices, but as she acknowledges to the Neo that yes, she wants on-line, the laptop will get a default gateway and a DNS server, and surfing she goes.

4) Matt just wants to charge his Neo up. He couldn't care less about any networking, let alone the Neo interfering with his existing network connections. He hooks the Neo up, and the local network is initialized. That's of little consequence to Matt, but he gets the phone charged.

5) Tom is charging his Neo via his laptop at home, when his home broadband is cut off by a road crew. He has reasonable GPRS pricing, so he wants it up as a backup. He tells the Neo to go on-line, whereupon he is asked, since the Neo is already plugged in, if he wants to share the connection to his laptop. And yes he does. The Neo cycles the interface, and the laptop gets an Internet connection.

[edit] Open questions

How to deal with Bluetooth and WiFi routing (for GTA02) in conjuction? Probably you'd not want to serve up default gateway per default if you're BT tethered, however, user might want to have one device BT tethered and another USB tethered. So perhaps best to leave the option open to share the connection via USB even if BT tethering is active, though especially in this case the option shouldn't be obtrusive; it'd probably be a rare use case.

[edit] Additional use cases

There is another use cases I'd like to suggest for consideration:

  • Bertrand (who has a good broadband connection at home) lives in Expensive GPRS Country and has no Bluetooth / WLAN. He wants to plug his phone into his computer and run ipkg updates via his broadband connection. His PC is serving as a DHCP server and/or bridges all traffic through its interfaces (with STP preventing loops).

Suggested policy:

  • Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.

[edit] Operation on Gentoo

One way of doing routing and NAT was recently added to the Wiki. I followed the lead of the other examples and did it this way:

 # Neo1973
 config_usb0=( "192.168.0.200 netmask 255.255.255.0" )
 postup() {
   case "${IFVAR}" in 
       "usb0") 
           iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
           echo 1 > /proc/sys/net/ipv4/ip_forward
           iptables -P FORWARD ACCEPT
           return 0;;
   esac
   return 0
 }
 predown() {
   case "${IFVAR}" in 
       "usb0") 
           iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
           echo 0 > /proc/sys/net/ipv4/ip_forward
           return 0;;
   esac
   return 0
 }

If the intent is to have the NATing and routing turn on and off as the neo is plugged and unplugged, this is probably an approach that is more like that than the other way.

[edit] Dealing with NetworkManager

NetworkManager (the default for sabayon) bypasses /etc/conf.d/net.usb0 by default. You need to modify /etc/conf.d/rc (or /etc/rc.conf on OpenRC) from

RC_PLUG_SERVICES="!net.*"

to somehing like

RC_PLUG_SERVICES="!net.eth* !net.wlan*"

(see http://gentoo-wiki.com/HOWTO_NetworkManager)

[edit] Rewrite

I have rewritten this page for accuracy and clarity. I took out redundant stuff, and tried to make it much clearer based upon my networking experience and discussions with users having problems in the #openmoko IRC channel. I tried to avoid and remove first person comments (although made some myself).

The first section is very deliberate, since the ordering of this page was illogical, having gathered many random comments. This allows user to step through the parts and make sure each is right before moving on. There are further explanations that could be added - instead of a subnet, an explicit device route could be added for the .202 host, over USB. which avoids most routing problems (unless your desktop is also .202). I hope though even without that, this covers most scenarios. I intend to rewrite some of the other pages in the same way.

[edit] Changing flow

Miohtama, I'm not entirely happy about your unjustified reordering. The page was structured in order to carefully explain to new users how to make it work, and for it be a very precise guide for helping those on IRC having problems - users I deal with. I don't believe that your changes really facilitate that. Putting stuff together because it seems to might superficially seem like a good idea, but it's not always.

[edit] Overlapping subnets

Please don't keep adding assertions that overlapping subnets don't work, or that assumptions are being made that they are different. It does work, with a sufficiently small subnet for the FR (as the examples show). Adding comments about insisting that users change their LAN subnets is unnecessary, and makes it that much harder for users - where this page was originally.


[edit] Latest changes

I found out that with my Kubuntu 8.10 without the «auto usb0» option in /etc/network/interfaces the USB networking wasn't able to work automatically. Adding that line makes everything work fine: plug-in the NEO, it gets recognized, give ssh openmoko and you're done. No problems with default networkmanager. So my question is: why do you think that option should not be there?


[edit] displaying desktop application on freeruner

If you consider, that you want to see your desktop application on Freerunner you have to install openssh-ssh server instead dropbear and then you can

ssh -X login@192.168.0.200
xclock

[edit] Script

sudo iptables -F
sudo ifconfig usb0 192.168.0.200 netmask 255.255.255.0
sudo route add 192.168.0.202 usb0
sudo iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT
sudo iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT
sudo iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
sudo echo 1 > /proc/sys/net/ipv4/ip_forward

[edit] no inet in interfaces

I think the inet label in interfaces for eth1 (when openmoko is on eth1 like Ubuntu 9.04) causes the host (laptop) to try to make a connection to the internet via the openmoko device. This could be just the opposite of what you want. I'm not an expert on this but removing inet in interfaces for the openmoko devices fixed my problem. Any comments on this? Pander 08:49, 16 June 2009 (UTC)

I merely checked on /etc/udev/rules.d which interface would be used ( eth1 ) Then went to System/Administration/Network and there gave the address netmask and the default gateway for eth1 -- simple and no problem. The default GW is the gateway of the system. On laptop like you did. All works well Internet for laptop and contact with Freerunner.

Did not check yet if i can go to the internet from the Freerunner via eth1, wlan is OK

Carig Philippines --frank 14:50, 17 June 2009 (UTC)

[edit] Ubuntu Instructions

I find the 8.10 instructions clearer and more to the point than the 9.04 ones. Moreover, the 9.04 ones don't feature actual routing, so I'd suggest deleting the 9.04 section, and adding a note to the 8.10 sections that with Qi, it's eth1 and not usb0. Also, one question: does anyone know if the routing given by the iptables commands in the 8.10 section can also be achieved just by using the System > Administration > Network > eth1 > IPv4 Settings > Routes dialog? --Ockham 18:55, 5 July 2009 (UTC)

[edit] Using network-manager on systems using udev

following these steps i found that iptables is not set correctly (cannot reach the web from FR) i tried manually executing

sudo /usr/local/sbin/freerunner-usb-add.sh

and everything i got was

Cannot find device "00:00:22:55:bb:00"

what's wrong?

--Dareus 15:24, 14 July 2009 (CET)


[edit] Experience on SHR in Version 209-05-02 / OpenSuse 11.1

my route before hacking was without router:

(route add default dev usb0)

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 usb0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 usb0

... and (in my oppinion) should work, but did'nt route anything further than to my host 10.0.0.1

(which is on a router(10.0.0.254) to outside in an Class A Network 10.0.0.0/8)

i changed that to:

(route add default gw 192.168.0.200 dev usb0)

and got the working variant:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 usb0
0.0.0.0         192.168.0.200   0.0.0.0         UG    0      0        0 usb0

So maybe, the order in which /etc/network/interfaces configures usb0 seems to be the problem:

i changed it to:

auto usb0
iface usb0 inet static
       address 192.168.0.202
       network 192.168.0.0
       netmask 255.255.255.0
       gateway 192.168.0.200

this works fine here on SHR without any firewall/nat/masquerade/routing etc.

Personal tools

Thoughts on USB networking in the final product

There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.

The Neo's IP will probably need to remain static, and chosen, as it is now, from some local address space. I would personally suggest to change to using an address higher in the 192.168.0.0 space, say, 192.168.19.73 (ehhehe) to reduce chance of conflicts. (Or use link-local space?)

Anyway, for the casual user, and even comfort-seeking geeks, OpenMoko will need to provide DHCP service. It will probably be also a good idea to run a DNS proxy, since that way the host doesn't need to care about changing DNS servers, and the caching is a good idea anyway for high latency GPRS. I'd suggest dnsmasq, which is simple and can handle both tasks. I assume the Neo will do IP masquerading for the USB host when it's acting as its default gateway.

Now, the DHCP server should obviously serve up a local address to the USB host when connected (assuming here most hosts will use DHCP by default to configure the USB network device, which I think is a valid assumption, and if some don't, we can't help things automagically anyway).

What's more complicated is when to give a default gateway and a DNS server address. You don't want to do it all the time, that would screw with simple use cases (detailed more below).

Suggested policies

At this point I suggest, based on the aforementioned IRC discussion, the following policy:

1) If the device is plugged into a host, and the device is not on-line with GPRS, do not go on-line, and only give a private address (no default route/dns) to host.

2) If the phone is told to go on-line with GPRS (or, in the future, other mobile protocols) and it's presently hooked up to a USB host with only a local network connection, query the user if they want to use the Internet also from the computer. If yes, run the interface down, then up again, thus triggering the host to make a new DHCP query. Now serve up default gateway and dns information too.

3) If the phone is told to go off-line while routing a network connection to a USB host, cycle the interface again and only serve up a local address. Possibly ask if the user really wants to disconnect considering the tether.

4) If the phone is presently on-line with GPRS, and it's plugged into a host, initialize with only the local network connection, query the user (with a dialog or less obtrusively with a suitable panel button or panel GPRS menu changing appearance) whether they want to use the connection from the computer too. If yes, cycle interface, serve up default gateway and dns. Remove the query if usb disconnected.

Use cases

The rationale for not serving up a default route too eagerly is that this device charges from USB, people will probably sync it via USB, and they don't want any hassle doing that. Use cases to demonstrate:

1) John wants to sync addressbooks between his home desktop and the Neo. He uses USBnet for this, because where he lives, GPRS is crazy expensive, and besides, he doesn't want to have internet-visible servers on the desktop. He hooks the Neo up, and only wants local data transfer capabilities. What he doesn't want is to lose access to his broadband, so serving up default gateway and DNS would make him angry.

2) Shirley has CommunitasticoMoko installed on her Neo, and thus is on-line via GPRS pretty much constantly. (Yes, Shirley lives in some more GPRS-friendly area.) Shirley wants to load up new music from her desktop to the phone, so she hooks the Neo up. Even though GPRS is on-line for CommunitasticoMoko, she doesn't want the desktop to suddenly lose her home broadband access. She gets asked (in the more or less obtrusive ways above) if she'd like to provide Internet access to the host. She doesn't care about the question, just transfers the files, unhooks, and is on the go. The query disappears, not bothering her anymore.

3) Shirley's CommunitasticoMoko buddy Roxanne hooks the Neo up to her laptop. As she is also on-line via GPRS, she gets the query. She first thinks to only sync up the address books of her laptop and the Neo, but while doing that, she decides to go surfing for a bit too. Up till now, she's had a local network between the devices, but as she acknowledges to the Neo that yes, she wants on-line, the laptop will get a default gateway and a DNS server, and surfing she goes.

4) Matt just wants to charge his Neo up. He couldn't care less about any networking, let alone the Neo interfering with his existing network connections. He hooks the Neo up, and the local network is initialized. That's of little consequence to Matt, but he gets the phone charged.

5) Tom is charging his Neo via his laptop at home, when his home broadband is cut off by a road crew. He has reasonable GPRS pricing, so he wants it up as a backup. He tells the Neo to go on-line, whereupon he is asked, since the Neo is already plugged in, if he wants to share the connection to his laptop. And yes he does. The Neo cycles the interface, and the laptop gets an Internet connection.

Open questions

How to deal with Bluetooth and WiFi routing (for GTA02) in conjuction? Probably you'd not want to serve up default gateway per default if you're BT tethered, however, user might want to have one device BT tethered and another USB tethered. So perhaps best to leave the option open to share the connection via USB even if BT tethering is active, though especially in this case the option shouldn't be obtrusive; it'd probably be a rare use case.

Additional use cases

There is another use cases I'd like to suggest for consideration:

  • Bertrand (who has a good broadband connection at home) lives in Expensive GPRS Country and has no Bluetooth / WLAN. He wants to plug his phone into his computer and run ipkg updates via his broadband connection. His PC is serving as a DHCP server and/or bridges all traffic through its interfaces (with STP preventing loops).

Suggested policy:

  • Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.

additional use case / suggestions

There is another use cases I'd like to suggest for consideration:

  • Bertrand (who has a good broadband connection at home) lives in Expensive GPRS Country and has no Bluetooth / WLAN. He wants to plug his phone into his computer and run ipkg updates via his broadband connection. His PC is serving as a DHCP server and/or bridges all traffic through its interfaces (with STP preventing loops).

Suggested policy:

  • Before the phone assigns itself a local address, it asks for a DHCP address. If that fails, a link local address according to RFC 3927 is assigned.