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.

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)

Missing parts in the descriptions

The automatic method (for Ubuntu) is missing the "route add -host 192.168.0.202/32 dev usb0" command, without it, I don't get a connection via ssh and "ssh: connect to host 192.168.0.202 port 22: No route to host", for /etc/network/interfaces you would add (Ubuntu):

up route add -host 192.168.0.202/32 dev usb0

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).

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.

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:

Views

Personal tools

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)

Missing parts in the descriptions

The automatic method (for Ubuntu) is missing the "route add -host 192.168.0.202/32 dev usb0" command, without it, I don't get a connection via ssh and "ssh: connect to host 192.168.0.202 port 22: No route to host", for /etc/network/interfaces you would add (Ubuntu):

up route add -host 192.168.0.202/32 dev usb0

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.

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: