WebOS Internals - User contributions [en]

Ip forward

2010-03-02T04:27:19Z

Smoofra:

You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0.

There are three places I've found that cause this to happen. First is /etc/network/options. Go
in there and change the line
<pre>ip_forward=no
</pre> to
<pre>
ip_forward=yes
</pre>

Next is /etc/pmnetconfig/if-down. Comment out the lines

<pre>
${LOG} "${ECHO} 0 >/proc/sys/net/ipv4/ip_forward"
${ECHO} 0 >/proc/sys/net/ipv4/ip_forward
</pre>

Last and not least, is the binary /usr/bin/PmNetConfigManager. First, make a fake place for it to write to

<pre>
mount -o remount,rw /
mkdir-p /media/cryptofs/fake/sys/net/ipv4
ln -s /media/cryptofs/fake /fake
echo 0 >/fake/sys/net/ipv4/ip_forward
mount -o remount,ro /
</pre>

Next, patch /usr/bin/PmNetConfigManager so it writes to /fake/sys/net/ipv4/ip_forward instead of /proc/sys/net/ipv4/ip_forward. Just open it up in a hex editor, find that path, and change "proc" to "fake". Make sure you only change those four bytes. You should probably also make sure you have a backup of the original binary. After you replace PmNetConfigManager, restart it.

<pre>
stop PmNetConfigManager
start PmNetConfigManager
</pre>

Another way to solve this problem is to make /proc/sys/net/ipv4/ip_forward innaccessable. As PuffTheMagic_ put it:
<pre>
<PuffTheMagic_> smoofra: mount -o bind /dev/null over ip_forward
<PuffTheMagic_> then mount proc in a new directory
<PuffTheMagic_> and set it to 1 from that new dir
<PuffTheMagic_> ;)
</pre>

Ip forward

2010-03-02T04:26:55Z

Smoofra:

You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0.

There are three places I've found that cause this to happen. First is /etc/network/options. Go
in there and change the line
<pre>ip_forward=no
</pre> to
<pre>
ip_forward=yes
</pre>

Next is /etc/pmnetconfig/if-down. Comment out the lines

<pre>
${LOG} "${ECHO} 0 >/proc/sys/net/ipv4/ip_forward"
${ECHO} 0 >/proc/sys/net/ipv4/ip_forward
</pre>

Last and not least, is the binary /usr/bin/PmNetConfigManager. First, make a fake place for it to write to

<pre>
mount -o remount,rw /
mkdir-p /media/cryptofs/fake/sys/net/ipv4
ln -s /media/cryptofs/fake /fake
echo 0 >/fake/sys/net/ipv4/ip_forward
mount -o remount,ro /
</pre>

Next, patch /usr/bin/PmNetConfigManager so it writes to /fake/sys/net/ipv4/ip_forward instead of /proc/sys/net/ipv4/ip_forward. Just open it up in a hex editor, find that path, and change "proc" to "fake". Make sure you only change those four bytes. You should probably also make sure you have a backup of the original binary. After you replace PmNetConfigManager, restart it.

<pre>
stop PmNetConfigManager
start PmNetConfigManager
</pre>

Another way to solve this problem is to make /proc/sys/net/ipv4/ip_forward innaccessable. As PuffTheMagic_ put it:
<pre>
<PuffTheMagic_gt; smoofra: mount -o bind /dev/null over ip_forward
<PuffTheMagic_gt; then mount proc in a new directory
<PuffTheMagic_gt; and set it to 1 from that new dir
<PuffTheMagic_gt; ;)
</pre>

USBnet Setup

2010-03-02T01:07:29Z

Smoofra: /* Windows 7 RC Build 7100 (64-bit) */

USBnet allows you to create an IP network over the USB cable. This will allow you to talk to your Pre without WiFi or Bluetooth, and it keeps the battery charged.

This page is a duplicate of [[USBnet networking setup]]

== With Linux Access ==

run

'''usbnet enable'''

as root and then restart the device as instructed. When it comes back up, run 'ifconfig' and verify you now have a usb0 interface. Mine had the IP of 192.168.0.202. The IP can be changed in /etc/network/interfaces. After a change, bounce the usb0 interface: ifdown usb0; ifup usb0

== Optional Setup to enable DHCP (so you don't have to set the IP address below) ==

#Edit /etc/dnsmasq.palm.conf
#Add interface=usb0 below the existing interface line
#Add dhcp-range=192.168.0.11,192.168.0.12,12h below the existing dhcp-range
#Restart the dnsmasq process: stop dnsmasq; start dnsmasq

== On Windows XP ==

#Download the driver here: [http://gitorious.org/webos-internals/usbnet-pre/blobs/raw/master/windows/usbnet-pre.inf usbnet-pre windows driver(32 bit)] or [http://gitorious.org/webos-internals/usbnet-pre/blobs/raw/master/windows/usbnet-pre-64.inf usbnet-pre windows driver(64 bit)] and save the file to disk as usbnet-pre.inf
#Plug the Pre into your computer. The Add New Hardware Wizard should come up, asking to install an ethernet gadget.
#Follow detailed instructions (screenshots and all) here if you are unfamiliar with installing drivers: [http://docwiki.gumstix.org/index.php/Windows_XP_usbnet Windows XP USBnet install]
#When you finish, you should have a network setup. Goto "Network Connections" via Network Places or the Control Panel
#If you have previously installed Novacom on this machine, bring up Windows Task Manager before proceeding. You may find discover a conflict between USBnet and novacomd where the novacomd process will consume lots of CPU and your machine will become very unresponsive. Since you have Task Manager up already, you can easily use it to kill novacomd if this occurs.
#Right-click on the new network, which probably be named Local Area Connection 2
#Select Properties
#Double click on Internet Protocol (TCP/IP)
#Click Advanced
#UNCheck Automatic metric, put 100 in its place. This will keep Windows from attempting to [http://support.microsoft.com/default.aspx/kb/299540 route] traffic over the Pre (it won't work anyway). Note: 100 may be too high. If it seems that network traffic is being routed to the pre (IE - your internet connection apparently dies), try setting this to something lower (like 60).
#Click OK
#If you did not enable DHCP, you will need to set an IP address manually:
##Set your IP address as 192.168.0.203 ( could be anything except 192.168.0.202, assuming this is the Pre's address)
##Subnet mask: 255.255.255.0
##Default Gateway: 192.168.0.202 (your Pre's address for the usb0 interface)
##Set DNS to your preferred servers. Addresses are not currently resolving for me, regardless of the server I use
#Hit OK

The network should now be setup. To verify, ssh to 192.168.0.202, and you should be prompted for a login.

== Notes: ==

*This has only been tested on Windows XP 32 bit. For Windows 2000, you will need an additional download from Microsoft. The link is in the header of the INF file.

- From zinge: I have several confirmations via the precentral forums that this only works on XP sp3. Sp2 gives "error code 10, the device cannot start". Has anyone followed this process and had it work on XP sp2? Update: Upgraded to SP3 on my laptop, and it immediately started working.

*The 64 bit driver is unverified at this point, but I think it works.
*wayne47: I was having all kinds of issues with this on my WinXP notebook. Clicking on the safely remove hardware icon in the tray indicated two devices associated with the Pre: Novacom and a USB drive. Stopping the Novacom service resolved the issues. Note that I need to do this each time that I attach the Pre via USB.

== On Mac OS X ==

*[http://www.wikidot.com/user:info/mdklein mdklein] notes that as of 1.0.4 the g_composite driver appears to only operate usbnet in rndis mode which is not the method OS-X includes. He has made a version that implements CDC-ECM, but it breaks a few other things. Working on this.

*Allegedly, Mac OS X 10.4 should create a usb0 interface after you plug in a usbnet enabled pre. 10.5 needs a modified driver, which is not working for me (and carazy) yet.
See [http://bugcommunity.com/wiki/index.php/Start_Guide_Mac_OS_X_10.5 this page] for more details.

*I don't know of anyone that has gotten USBNet driver to work on Mac OSX at all so for the time being, count it as unsupported. If anyone can figure it out please shed some light on us.

== Windows Vista (64-bit) ==

*If driver/device fails to come online in network sharing center, simply click start->right click computer-> properties … Click Device manager and look for the device "Linux USB Ethernet/RNDIS Gadget" you can then right click disable/enable the device. That's all.
*This device/driver can also be cycled with MS Windows own [http://support.microsoft.com/kb/311272 DevCon] application.

== Windows 7 (64-bit) ==

* Windows 7 has the driver it needs already, but it won't set it up by itself. The driver you want is under "Microsoft Corporation" > "Remote NDIS based Internet Sharing Device.". See http://mytether.net/#other for complete directions.

== Windows 7 RC Build 7100 (64-bit) ==

*User lars47 confirms this is working on Windows 7 x64. Wrestled with the driver installation at first, it would not install, Windows complained of a file in use. I rebooted, and the next time I plugged in the Pre via USB, it "just worked". Unsure if I caused the problem, or if a reboot is required/recommended.

== Linux Support ==

* Once usbnet was enabled on the Pre, my Ubuntu 9.04 (64 bit) immediately identified the Pre in the NetworkManager and worked without modification to the OS. It seems to already have a driver that works.
* In order to prevent Ubuntu Linux from automatically trying to connect to the internet while the phone is connected via USBnet:
** In the Network Manager icon, click "Edit Connections"
** Select the usb0 interface and select "Edit"
** Uncheck the box that says "Connect Automatically" (this is optional, but could prevent headaches)
** Under IPv4 Settings select Routes
*** Check the box next to "Use this connection only for resources on its network"
** Click Ok, Apply. Now you should be able to access your regular wifi/lan/internet

Ip forward

2010-03-02T00:04:45Z

Smoofra:

Ip forward

2010-03-02T00:02:15Z

Smoofra:

You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0.

There are three places I've found that cause this to happen. First is /etc/network/options. Go
in there and change the line
<pre>ip_forward=no
</pre> to
<pre>
ip_forward=yes
</pre>

Next is /etc/pmnetconfig/if-down. Comment out the lines

<pre>
${LOG} "${ECHO} 0 >/proc/sys/net/ipv4/ip_forward"
${ECHO} 0 >/proc/sys/net/ipv4/ip_forward
</pre>

Last and not least, is the binary /usr/bin/PmNetConfigManager. First, make a fake place for it to write to

<pre>
mount -o remount,rw /
mkdir /media/cryptofs/fake/sys/net/ipv4/ip_forward
ln -s /media/cryptofs/fake /fake
mount -o remount,ro /
</pre>

Next, patch /usr/bin/PmNetConfigManager so it writes to /fake/sys/net/ipv4/ip_forward instead of /proc/sys/net/ipv4/ip_forward. Just open it up in a hex editor, find that path, and change "proc" to "fake". Make sure you only change those four bytes. You should probably also make sure you have a backup of the original binary. After you replace PmNetConfigManager, restart it.

<pre>
stop PmNetConfigManager
start PmNetConfigManager
</pre>

Ip forward

2010-03-01T23:58:08Z

Smoofra:

Ip forward

2010-03-01T21:05:16Z

Smoofra:

You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0. If you go into
/etc/network/options and change the line
<pre>ip_forward=no
</pre> to
<pre>
ip_forward=yes
</pre> the problem seems to go away.

Ip forward

2010-03-01T21:04:23Z

Smoofra: New page: You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0. If you go into /etc/network/options and change the line ip_forward=no to ip_forward=yes, the problem se...

You might have noticed that /proc/sys/net/ipv4/ip_forward keeps getting reset to 0. If you go into /etc/network/options and change the line ip_forward=no to ip_forward=yes, the problem seems to go away.

Avahi

2009-10-09T15:07:51Z

Smoofra: /* Avahi Installation */

=Avahi=
[http://avahi.org Avahi] is a Linux service for providing multicast-DNS/DNS-SD (also known as [http://en.wikipedia.org/wiki/Bonjour_%28software%29 Bonjour] or mDNS/DNS-SD). Avahi allows for simple service discovery and advertisement on a local network and provides name resolution for all hosts running a mDNS/DNS-SD service.

Using Avahi allows for easy SSH access over a local wireless network. Once installed and started, users can ssh to their device using their mDNS assigned hostname.

==Avahi Installation==

First, mount the root filesystem as writable and install the Avahi ipkg.

$> sudo mount -o remount,rw /
$> sudo /opt/bin/ipkg-opt install avahi

Avahi currently attempts to access a different dbus system socket than the one provided by the Pre's dbus, so we need to turn off dbus access for the time being. Edit <tt>/opt/etc/avahi/avahi-daemon.conf</tt> and make the following change:

Replace this line:
#enable-dbus=yes

With this line:
enable-dbus=no

Avahi seems to want to run as a user named "avahi". To create the user, run the following command:

$> adduser -h /opt/var/run/avahi avahi

At this point, the Avahi daemon can be started with the following command:

$> sudo /opt/sbin/avahi-daemon -D

If you would like Avahi to start up at boot, create the following two files:

'''/opt/etc/init.d/S60avahi'''
#!/bin/sh

[ -e /opt/etc/default/avahi ] && . /opt/etc/default/avahi

if [ "$AVAHI_ENABLE" = "no" ]; then
exit
fi

if [ -n "`pidof /opt/sbin/avahi-daemon`" ]; then
killall /opt/sbin/avahi 2>/dev/null
fi

/opt/sbin/avahi-daemon -D

'''/opt/etc/default/avahi''':
AVAHI_ENABLE=yes

Make sure you set the startup script to executable:

$> sudo chmod 755 /opt/etc/init.d/S60avahi

Alternatively, you can create an upstart script at '''/etc/event.d/avahi''':

start on started PmConnectionManager

console output

exec /opt/sbin/avahi-daemon -D
respawn

NOTE: This script is not being stored in the /opt directory. You may have to replace it after an update, and it may cause problems with your Pre.

==Connecting via SSH using mDNS==

mDNS uses the system's hostname and appends it to the <tt>local.</tt> domain. Using the Pre's default <tt>castle</tt> hostname, the following command would be used to SSH to your Pre on port 222:

$> ssh -P 222 castle.local.

'''Note: The system that you are connecting from MUST have a mDNS service also running, else the hostname will not resolve'''

==Current Issues==

* The ipkg binary of Avahi attempts to find the dbus socket at <tt>/opt/var/run/dbus/system_bus_socket</tt>, but the Pre's dbus socket is at <tt>/var/run/dbus/system_bus_socket</tt>. I haven't investigated tying these two together too much, but the expanded functionality of accessing mDNS via dbus is preferred.
* The avahi-daemon seems to have issues keeping the mDNS name resolution running for more than a few minutes. I don't know if this is a power management issue or something else at this point.