http://wiki.openmoko.org/api.php?action=feedcontributions&user=AudriusA&feedformat=atomOpenmoko - User contributions [en]2018-02-22T05:11:55ZUser contributionsMediaWiki 1.19.24http://wiki.openmoko.org/wiki/Marketing_MistakesMarketing Mistakes2009-10-03T22:08:47Z<p>AudriusA: /* From the view point of developer */</p>
<hr />
<div>The analysis of the marketing of OpenMoko Freerunner reveals the following problems:<br />
<br />
== From the view point of the inexperienced customer ==<br />
<br />
* Freerunner was shipped to the user as an experimental device and not as working device for everyday use for ''novice users''.<br />
* the only widely accepted distribution is QT extended distribution, so the OpenMoko should have a pre-installed ''QT extended improved'' distribution.<br />
* Developers are able to flash the freerunner to any other distrubtion they want to test, ordinary users have problems to do that, so this fact is also indicating that QT extended improved should be the distribution of choice that is pre-installed of the freerunner.<br />
* the big advantage of the freerunner is the open source concept - using OpenStreetMap in a ''car navigation system'' like navit on the device is really a unique selling position for the freerunner. This implies that the freerunner has a car-navigation system pre-installed e.g. 'navit' or 'roadmap' on the device and the wiki of OpenMoko has working tutorial with which an ordinary user can download and upload a map of his/her choice to the freerunner easily.<br />
* The wiki was not divided in an area for 'novice users' of the device and 'more advanced users' that have experience with linux systems.<br />
* this leads to maintainance of the wiki that has no working tutorial with which an ordinary user can:<br />
** synchronize PIM data (contacts, tasks, ...) of ''kontact, evolution'' ... on a linux box with the QT extended improved distribution (Mac OS, Win OS should be considered too)<br />
** download maps of choice to a pre-installed car-navigation system on a QT extended improved distribution<br />
** add new language modules for spanish, italian, ... easily on the device.<br />
* the freerunner could have two distributions installed at the same time with Qi and removing the SD card starts the second distribution e.g SHR or ship the freerunner with two SD cards so that the user can select the distribution just by exchanging the SD card (e.g. QT or SHR). <br />
<br />
'''Summary:''' if the shipped device and tutorials on the wiki are not tailored to novice users the sold numbers of freerunner will remain low, which would be bad, because a wonderful approach of the freerunner and the OpenMoko team should not die, because of these marketng mistakes that can be eliminated!<br />
<br />
== From the view point of developer ==<br />
* The student - developer was considered as a minor customer. The size of this market can be roughly estimated as the number of Neo 1973's sold (these were clearly developer devices) plus likely some more as it is not the only Linux device developers would buy. It seems that this segment was not actually tiny and deserved more attention.<br />
* Similarly, the market segment of the university teaching projects was not properly taken into consideration, no academic requirements were collected and there were student blogs on a web that the device performed poorly in this area.<br />
* After making Freerunner available, support for Neo 1973 has been aggressively dropped up till level of refusing to host the images for this device in the official OpenMoko website. Managers likely wanted to force developers to buy Freerunner ASAP but likely created a group of people who just stopped participating in development. The reasons for that are:<br />
** These devices are not exactly very cheap and not all developers can afford to change them on a yearly basis.<br />
** Free software folk just universally hate any aggressive manipulation by marketing people.<br />
* The on screen terminal that was available in the first releases has been dropped later, making pointless any porting of the command line software (that some developers would be using). With all respect to usability, problems should be solved by adding features, not by removing them.<br />
* Some developers with high reputation in the FOSS world that initially worked for Openmoko have left the development team. This created certain negative aura (not necessarily deserved). It was a responsibility of the marketing section to work on restoring the positive image rather than just choosing the dead silence instead.<br />
* Splitting very limited efforts between so many distributions shows the total absence of any priority management.<br />
<br />
In general, the existing segment of students and other enthusiasts was ignored, rushing into the mass user as into holly grail. The mass user is actually difficult to get: he is far more demanding to the quality of both software and hardware, he wants something really convenient and innovative and, the worst, the software freedom for that every single GNU hacker is ready to dial by typing TTY commands on the touch screen (talking with Morse code afterwards) may matter much less. This is not necessarily a tragedy, this is how Linux started and needed to get stronger before going into masses. It looks that going into masses with Freerunner as it was has just been premature.<br />
<br />
[[Category:Community]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Marketing_MistakesMarketing Mistakes2009-10-03T21:52:37Z<p>AudriusA: /* From the view point of developer */</p>
<hr />
<div>The analysis of the marketing of OpenMoko Freerunner reveals the following problems:<br />
<br />
== From the view point of the inexperienced customer ==<br />
<br />
* Freerunner was shipped to the user as an experimental device and not as working device for everyday use for ''novice users''.<br />
* the only widely accepted distribution is QT extended distribution, so the OpenMoko should have a pre-installed ''QT extended improved'' distribution.<br />
* Developers are able to flash the freerunner to any other distrubtion they want to test, ordinary users have problems to do that, so this fact is also indicating that QT extended improved should be the distribution of choice that is pre-installed of the freerunner.<br />
* the big advantage of the freerunner is the open source concept - using OpenStreetMap in a ''car navigation system'' like navit on the device is really a unique selling position for the freerunner. This implies that the freerunner has a car-navigation system pre-installed e.g. 'navit' or 'roadmap' on the device and the wiki of OpenMoko has working tutorial with which an ordinary user can download and upload a map of his/her choice to the freerunner easily.<br />
* The wiki was not divided in an area for 'novice users' of the device and 'more advanced users' that have experience with linux systems.<br />
* this leads to maintainance of the wiki that has no working tutorial with which an ordinary user can:<br />
** synchronize PIM data (contacts, tasks, ...) of ''kontact, evolution'' ... on a linux box with the QT extended improved distribution (Mac OS, Win OS should be considered too)<br />
** download maps of choice to a pre-installed car-navigation system on a QT extended improved distribution<br />
** add new language modules for spanish, italian, ... easily on the device.<br />
* the freerunner could have two distributions installed at the same time with Qi and removing the SD card starts the second distribution e.g SHR or ship the freerunner with two SD cards so that the user can select the distribution just by exchanging the SD card (e.g. QT or SHR). <br />
<br />
'''Summary:''' if the shipped device and tutorials on the wiki are not tailored to novice users the sold numbers of freerunner will remain low, which would be bad, because a wonderful approach of the freerunner and the OpenMoko team should not die, because of these marketng mistakes that can be eliminated!<br />
<br />
== From the view point of developer ==<br />
* The student - developer was considered as a minor customer. The size of this market can be roughly estimated as the number of Neo 1973's sold (these were clearly developer devices) plus likely some more as it is not the only Linux device developers would buy. It seems that this segment was not actually tiny and deserved more attention.<br />
* Similarly, the market segment of the university teaching projects was not properly taken into consideration, no academic requirements were collected and there were student blogs on a web that the device performed poorly in this area.<br />
* After making Freerunner available, support for Neo 1973 has been aggressively dropped up till level of refusing to host the images for this device in the official OpenMoko website. Managers likely wanted to force developers to buy Freerunner ASAP but likely created a group of people who just stopped participating in development. The reasons for that are:<br />
** These devices are not exactly very cheap and not all developers can afford to change them on a yearly basis.<br />
** Free software folk just universally hate any aggressive manipulation by marketing people.<br />
* The on screen terminal that was available in the first releases has been dropped later, making pointless any porting of the command line software (that some developers would be using). With all respect to usability, problems should be solved by adding features, not by removing them.<br />
* Some developers with high reputation in the FOSS world that initially worked for Openmoko have left the development team. This created certain negative aura (not necessarily deserved). It was a responsibility of the marketing section to work on restoring the positive image rather than just choosing the dead silence instead.<br />
* Splitting very limited efforts between so many distributions shows the total absence of any priority management.<br />
<br />
[[Category:Community]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Marketing_MistakesMarketing Mistakes2009-10-03T12:38:58Z<p>AudriusA: </p>
<hr />
<div>The analysis of the marketing of OpenMoko Freerunner reveals the following problems:<br />
<br />
== From the view point of the inexperienced customer ==<br />
<br />
* Freerunner was shipped to the user as an experimental device and not as working device for everyday use for ''novice users''.<br />
* the only widely accepted distribution is QT extended distribution, so the OpenMoko should have a pre-installed ''QT extended improved'' distribution.<br />
* Developers are able to flash the freerunner to any other distrubtion they want to test, ordinary users have problems to do that, so this fact is also indicating that QT extended improved should be the distribution of choice that is pre-installed of the freerunner.<br />
* the big advantage of the freerunner is the open source concept - using OpenStreetMap in a ''car navigation system'' like navit on the device is really a unique selling position for the freerunner. This implies that the freerunner has a car-navigation system pre-installed e.g. 'navit' or 'roadmap' on the device and the wiki of OpenMoko has working tutorial with which an ordinary user can download and upload a map of his/her choice to the freerunner easily.<br />
* The wiki was not divided in an area for 'novice users' of the device and 'more advanced users' that have experience with linux systems.<br />
* this leads to maintainance of the wiki that has no working tutorial with which an ordinary user can:<br />
** synchronize PIM data (contacts, tasks, ...) of ''kontact, evolution'' ... on a linux box with the QT extended improved distribution (Mac OS, Win OS should be considered too)<br />
** download maps of choice to a pre-installed car-navigation system on a QT extended improved distribution<br />
** add new language modules for spanish, italian, ... easily on the device.<br />
* the freerunner could have two distributions installed at the same time with Qi and removing the SD card starts the second distribution e.g SHR or ship the freerunner with two SD cards so that the user can select the distribution just by exchanging the SD card (e.g. QT or SHR). <br />
<br />
'''Summary:''' if the shipped device and tutorials on the wiki are not tailored to novice users the sold numbers of freerunner will remain low, which would be bad, because a wonderful approach of the freerunner and the OpenMoko team should not die, because of these marketng mistakes that can be eliminated!<br />
<br />
== From the view point of developer ==<br />
* The student - developer was considered as a minor customer. The size of this market can be roughly estimated as the number of Neo 1973's sold (these were clearly developer devices). It seems that this segment was not actually tiny and deserved more attention.<br />
* Similarly, the market segment of the university teaching projects was not properly taken into consideration, no academic requirements were collected and there were student blogs on a web that the device performed poorly in this area.<br />
* After making Freerunner available, support for Neo 1973 has been aggressively dropped up till level of refusing to host the images for this device in the official OpenMoko website. Managers likely wanted to force developers to buy Freerunner ASAP but likely created a group of people who just stopped participating in development. The reasons for that are:<br />
** These devices are not exactly very cheap and not all developers can afford to change them on a yearly basis.<br />
** Free software folk just universally hate any aggressive manipulation by marketing people.<br />
* The on screen terminal that was available in the first releases has been dropped later, making pointless any porting of the command line software (that some developers would be using). With all respect to usability, problems should be solved by adding features, not by removing them.<br />
* Some developers with high reputation in the FOSS world that initially worked for Openmoko have left the development team. This created certain negative aura (not necessarily deserved). It was a responsibility of the marketing section to work on restoring the positive image rather than just choosing the dead silence instead.<br />
* Splitting very limited efforts between so many distributions shows the total absence of any priority management.<br />
<br />
[[Category:Community]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2009-06-16T15:53:27Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel). This NMEA log is available in the project page]]<br />
<br />
{{Application|GPS Sight}}<br />
<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
GPS Sight is unusual as it reads NMEA pipe directly, not relying on the intermediate library layer like gpsd or gipsy. This allows the developer to have an experience of directly interacting with GPS chip. Direct communication is practical because NMEA is a plain text format the must follow the standard and it is easy to get just by reading from the known location in the filesystem. <br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. <br />
<br />
== Neo 1973 ==<br />
With Neo, the released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The first version were trying to read from the NMEA pipe in periodic scheduled calls but this results &quot;time travelling effect&quot;. Then 'select' function was involved that improved performance but created big loads on CPU. To reduce the loads, the incremental waiting time was introduced and finally we switched to using GTK built - in channel input library that can schedule call exactly when input from the pipe is available.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most of work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
&lt;onlyinclude&gt;<br />
{{ApplicationBox|<br />
Name=[[GPS Sight]]|<br />
Description=The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps).|<br />
Screenshot=Image-Gpv 0 0 screen shot 2.jpg|<br />
Homepage=http://projects.openmoko.org/projects/gpv|<br />
TestedOn=Neo 1973, FreeRunner|<br />
PackageName=gpssight_0.8.4_freerunner.armv4t.ipk (FreeRunner), gpssight_0.8.4_armv4t.ipk (Neo)<br />
}}<br />
&lt;/onlyinclude&gt;<br />
<br />
[[Category:GPS Applications]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2009-06-16T06:27:10Z<p>AudriusA: /* Project organization */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel). This NMEA log is available in the project page]]<br />
<br />
{{Application|GPS Sight}}<br />
<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. <br />
<br />
== Neo 1973 ==<br />
With Neo, the released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The first version were trying to read from the NMEA pipe in periodic scheduled calls but this results &quot;time travelling effect&quot;. Then 'select' function was involved that improved performance but created big loads on CPU. To reduce the loads, the incremental waiting time was introduced and finally we switched to using GTK built - in channel input library that can schedule call exactly when input from the pipe is available.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most of work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
&lt;onlyinclude&gt;<br />
{{ApplicationBox|<br />
Name=[[GPS Sight]]|<br />
Description=The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps).|<br />
Screenshot=Image-Gpv 0 0 screen shot 2.jpg|<br />
Homepage=http://projects.openmoko.org/projects/gpv|<br />
TestedOn=Neo 1973, FreeRunner|<br />
PackageName=gpssight_0.8.4_freerunner.armv4t.ipk (FreeRunner), gpssight_0.8.4_armv4t.ipk (Neo)<br />
}}<br />
&lt;/onlyinclude&gt;<br />
<br />
[[Category:GPS Applications]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2009-02-12T17:52:39Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel). This NMEA log is available in the project page]]<br />
<br />
{{Application|GPS Sight}}<br />
<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. <br />
<br />
== Neo 1973 ==<br />
With Neo, the released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The first version were trying to read from the NMEA pipe in periodic scheduled calls but this results &quot;time travelling effect&quot;. Then 'select' function was involved that improved performance but created big loads on CPU. To reduce the loads, the incremental waiting time was introduced and finally we switched to using GTK built - in channel input library that can schedule call exactly when input from the pipe is available.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most of work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
&lt;onlyinclude&gt;<br />
{{ApplicationBox|<br />
Name=[[GPS Sight]]|<br />
Description=The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps).|<br />
Screenshot=Image-Gpv 0 0 screen shot 2.jpg|<br />
Homepage=http://projects.openmoko.org/projects/gpv|<br />
TestedOn=|<br />
PackageName=<br />
}}<br />
&lt;/onlyinclude&gt;<br />
<br />
[[Category:GPS Applications]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-31T14:29:28Z<p>AudriusA: /* The shortest way */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions (Fedora, SuSE, Red Hat, Debian and others) and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt. The way assumes that you have the recent Linux distribution with USB networking enabled and also rather typical network setup. <br />
<br />
With the device connected configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
Do not forget to allow ssh (open the port 22) on your firewall so that you can connect to the device. If you suspect any firewall issues, the simplest way is to unplug the main Internet cable leaving only Neo connected and then temporary turn the firewall off.<br />
<br />
Also, some old or narrowly configured Linux distributions may not have USB networking support. For such cases the simple way might be just to upgrade.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
=== Changing the Neo IP address ===<br />
<br />
Like mentioned above, if the default Neo subnet 192.168.0.X is already used, it might be necessary to change the<br />
Neo [http://en.wikipedia.org/wiki/IP_address IP adress] and subnet.<br />
To achieve this, edit /etc/network/interfaces on the Neo (and reboot it).<br />
In the following example the Neo will use the IP address 192.168.100.1 (instead of the default 192.168.0.202)<br />
within the network 192.168.100.X (instead of 192.168.0.X),<br />
another [http://en.wikipedia.org/wiki/Private_network private] class C network.<br />
(The [http://en.wikipedia.org/wiki/Subnetwork#Binary_subnet_masks netmask] indicates that the first 3 bytes (all bits set) are used to determine the subnet<br />
and the last byte (no bits set) to determine the machine.)<br />
The gateway (the computer, the Neo is attached to) also has to be part of the subnet and is expected to be 192.168.100.254 (instead of 192.168.0.200) here.<br />
<br />
Modifications for /etc/network/interfaces:<br />
<br />
&lt;pre&gt;<br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.100.1<br />
netmask 255.255.255.0<br />
network 192.168.100.0<br />
gateway 192.168.100.254<br />
&lt;/pre&gt;<br />
<br />
(The network entry seems to be redundant information, since it can be derived from address and netmask?)<br />
Note that wiki articles usually expect default settings and you have to adjust the IP adress, gateway, etc entries according to your changes.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
&lt;tt&gt;/usr/local/etc/devd/cdce.conf&lt;/tt&gt; as:<br />
<br />
&lt;pre&gt;<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
&lt;/pre&gt;<br />
<br />
and &lt;tt&gt;/usr/local/etc/devd/cdce.sh&lt;/tt&gt; as:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
up iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
down iptables -D POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
) &amp;<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
;Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
&lt;/pre&gt;<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
&lt;/pre&gt;<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC9, FC8 &amp; FC5 ===<br />
<br />
edit file &lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt; to look like this:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from &lt;nowiki&gt;http://www.handhelds.org/moin/moin.cgi/UsbNet&lt;/nowiki&gt;<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
and restart networking service by typing:<br />
<br />
service network restart<br />
<br />
if your '''openmoko''' is connected when you restart network you should see system message:<br />
<br />
&lt;code&gt;Bringing up interface usb0 [OK]&lt;/code&gt;<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
./etc/init.d/functions<br />
cd /etc/sysconfig/network-scripts<br />
../network-functions<br />
[ -f ../network ] &amp;&amp; . ../network<br />
CONFIG=${1}<br />
need_config ${CONFIG}<br />
source_config<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
./etc/init.d/functions<br />
cd /etc/sysconfig/network-scripts<br />
../network-functions<br />
[ -f ../network ] &amp;&amp; . ../network<br />
CONFIG=${1}<br />
need_config ${CONFIG}<br />
source_config<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
&lt;pre&gt;<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
&lt;/pre&gt;<br />
<br />
Create a new init script:<br />
<br />
&lt;pre&gt;<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
&lt;/pre&gt;<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
&lt;pre&gt;<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
&lt;/pre&gt;<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
&lt;pre&gt;<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
&lt;/pre&gt;<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
<br />
&lt;tt&gt;<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
&lt;/tt&gt;<br />
<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
== sshfs ==<br />
You can use sshfs to mount the phones filesystem into the hosts filesystem. Make sure that fuse-sshfs is installed and that you are allowed to use fuse. Now run:<br />
<br />
sshfs 192.168.0.202:REMOTE_PATH LOCAL_MOUNT_POINT<br />
<br />
REMOTE_PATH can now be accessed through LOCAL_PATH.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-31T14:25:24Z<p>AudriusA: /* The shortest way */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions (Fedora, SuSE, Red Hat, Debian and others) and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt. The way assumes that you have the recent Linux distribution with USB networking enabled and also rather typical network setup. <br />
<br />
With the device connected configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device (ssh works on port 22 that must be opened). Also, some old or narrowly configured Linux distributions may not have USB networking support. For such cases the simple way might be just to upgrade.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
=== Changing the Neo IP address ===<br />
<br />
Like mentioned above, if the default Neo subnet 192.168.0.X is already used, it might be necessary to change the<br />
Neo [http://en.wikipedia.org/wiki/IP_address IP adress] and subnet.<br />
To achieve this, edit /etc/network/interfaces on the Neo (and reboot it).<br />
In the following example the Neo will use the IP address 192.168.100.1 (instead of the default 192.168.0.202)<br />
within the network 192.168.100.X (instead of 192.168.0.X),<br />
another [http://en.wikipedia.org/wiki/Private_network private] class C network.<br />
(The [http://en.wikipedia.org/wiki/Subnetwork#Binary_subnet_masks netmask] indicates that the first 3 bytes (all bits set) are used to determine the subnet<br />
and the last byte (no bits set) to determine the machine.)<br />
The gateway (the computer, the Neo is attached to) also has to be part of the subnet and is expected to be 192.168.100.254 (instead of 192.168.0.200) here.<br />
<br />
Modifications for /etc/network/interfaces:<br />
<br />
&lt;pre&gt;<br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.100.1<br />
netmask 255.255.255.0<br />
network 192.168.100.0<br />
gateway 192.168.100.254<br />
&lt;/pre&gt;<br />
<br />
(The network entry seems to be redundant information, since it can be derived from address and netmask?)<br />
Note that wiki articles usually expect default settings and you have to adjust the IP adress, gateway, etc entries according to your changes.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
&lt;tt&gt;/usr/local/etc/devd/cdce.conf&lt;/tt&gt; as:<br />
<br />
&lt;pre&gt;<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
&lt;/pre&gt;<br />
<br />
and &lt;tt&gt;/usr/local/etc/devd/cdce.sh&lt;/tt&gt; as:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
up iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
down iptables -D POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
) &amp;<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
;Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
&lt;/pre&gt;<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
&lt;/pre&gt;<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC9, FC8 &amp; FC5 ===<br />
<br />
edit file &lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt; to look like this:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from &lt;nowiki&gt;http://www.handhelds.org/moin/moin.cgi/UsbNet&lt;/nowiki&gt;<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
and restart networking service by typing:<br />
<br />
service network restart<br />
<br />
if your '''openmoko''' is connected when you restart network you should see system message:<br />
<br />
&lt;code&gt;Bringing up interface usb0 [OK]&lt;/code&gt;<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
./etc/init.d/functions<br />
cd /etc/sysconfig/network-scripts<br />
../network-functions<br />
[ -f ../network ] &amp;&amp; . ../network<br />
CONFIG=${1}<br />
need_config ${CONFIG}<br />
source_config<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
./etc/init.d/functions<br />
cd /etc/sysconfig/network-scripts<br />
../network-functions<br />
[ -f ../network ] &amp;&amp; . ../network<br />
CONFIG=${1}<br />
need_config ${CONFIG}<br />
source_config<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
&lt;pre&gt;<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
&lt;/pre&gt;<br />
<br />
Create a new init script:<br />
<br />
&lt;pre&gt;<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
&lt;/pre&gt;<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
&lt;pre&gt;<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
&lt;/pre&gt;<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
&lt;pre&gt;<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
&lt;/pre&gt;<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
<br />
&lt;tt&gt;<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
&lt;/tt&gt;<br />
<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
== sshfs ==<br />
You can use sshfs to mount the phones filesystem into the hosts filesystem. Make sure that fuse-sshfs is installed and that you are allowed to use fuse. Now run:<br />
<br />
sshfs 192.168.0.202:REMOTE_PATH LOCAL_MOUNT_POINT<br />
<br />
REMOTE_PATH can now be accessed through LOCAL_PATH.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-06T15:53:33Z<p>AudriusA: /* The shortest way */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions (Fedora, SuSE, Red Hat, Debian and others) and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt. The way assumes that you have the recent Linux distribution with USB networking enabled and also rather typical network setup. <br />
<br />
With the device connected configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device. Also, some old or narrowly configured Linux distributions may not have USB networking support. For such cases the simple way might be just to upgrade.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-06T15:52:19Z<p>AudriusA: /* The shortest way */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
&lt;!-- The idea is to keep the short way simple - it is for recent distributions and typical network setup. If you think it is necessary to add more, please explain in the talk page why --!&gt;<br />
This simple way has been tested with many Linux distributions (Fedora, SuSE, Red Hat, Debian and others) and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt. The way assumes that you have the recent Linux distribution with USB networking enabled and also rather typical network setup. <br />
<br />
With the device connected configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device. Also, some old or narrowly configured Linux distributions may not have USB networking support. For such cases the simple way might be just to upgrade.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-06T15:45:02Z<p>AudriusA: /* The shortest way */ rm addroute - never needed this under all distributions tested.</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-06T12:13:44Z<p>AudriusA: /* sftp */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browse the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-06T12:13:24Z<p>AudriusA: sftp</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
== sftp ==<br />
After you get the SSH connection working, it is possible to use Konqueror, Nautilus or another sftp - enabled tool to browser the phone filesystem and deploy the test applications. Just enter sftp://root@192.168.0.202 into address bar.<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-05T18:51:49Z<p>AudriusA: /* Simple Manual Linux Configuration */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-05T18:51:18Z<p>AudriusA: /* The more advanced way */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-12-05T16:17:47Z<p>AudriusA: /* Simple Manual Linux Configuration */</p>
<hr />
<div>= Openmoko Networking Setup =<br />
<br />
In order to communicate via TCP/IP to your FreeRunner, a basic understanding of the networking expectations is required. Each end of the USB connection forms a LAN (local area network) segment, with the FreeRunner's USB networking device at one end (default 192.168.0.202) and your laptop or desktop at the other end (192.168.0.200 in this guide).<br />
<br />
Normally, your desktop machine will know how to reach the Internet, having had its gateway (the IP address of the machine or device which knows how to send packets to machines beyond your subnet) configured via DHCP or statically (probably via a router). For the FreeRunner to reach the Internet, your desktop will have to be configured to route and masquerade (NAT) packets from it.<br />
<br />
Normally, none of this is an issue, but problems can arise when the subnet between the FreeRunner and your desktop overlap with the desktop to the router (which forms a second LAN), since your desktop might not know how to route traffic properly.<br />
<br />
In other words: if your existing router and desktop have addresses 192.168.0.(something) changing them to e.g. 192.168.1.(something) might save you a lot of troubleshooting later. A discussion of this is [http://lists.openmoko.org/pipermail/support/2008-August/thread.html#1277 here].<br />
<br />
= Simple Manual Linux Configuration =<br />
=== The shortest way ===<br />
This simple way has been tested with many Linux distributions and network configurations. It was even successfully applied to connect another Linux based handhelds like TDS Nomad and surely can be recommended as the first attempt.<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo (you do not need to be a root on the desktop host just to log in).<br />
# ssh root@192.168.0.202<br />
The default password is blank.<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.<br />
<br />
=== The more advanced way ===<br />
If the previously described simple approach does not work, you may try the more complex one.<br />
<br />
Try this first (as root on your desktop, with FreeRunner attached via USB cable and booted properly, not at the Boot Menu). If it works, then you can add permanent configuration or use more sophisticated setups below.<br />
<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
sysctl -w net.ipv4.ip_forward=1<br />
ip addr add 192.168.0.200/24 dev usb0&lt;/pre&gt;<br />
<br />
If your Internet connection is also in the range 192.168.0.x then instead you might want to use only:<br />
<br />
&lt;pre&gt;ip addr add 192.168.0.200/28 dev usb0&lt;/pre&gt;<br />
<br />
(This will just map the net from 192.168.0.192 to 192.168.0.207 onto usb0. If you get the error 'Cannot find device &quot;usb0&quot;', double-check that your FreeRunner is turned on and connected by USB. If that doesn't work, try unplugging and replugging the USB cable.)<br />
<br />
And in this case you should enable ARP proxy on internet facing interface INSTEAD of using iptables:<br />
<br />
&lt;pre&gt;sysctl net.ipv4.conf.eth2.proxy_arp=1&lt;/pre&gt;<br />
<br />
This assuming that eth2 is connected to ISP.<br />
<br />
Then<br />
&lt;pre&gt;ifconfig usb0 up&lt;/pre&gt;<br />
<br />
Then (ideally, not as root):<br />
<br />
&lt;pre&gt;ssh root@192.168.0.202&lt;/pre&gt;<br />
<br />
The default password is blank.<br />
<br />
Due to the fact that in most cases your Neo will use the same dns servers as your computer uses, you can automate the process of writing dns servers to your phone:<br />
<br />
&lt;pre&gt;#!/bin/sh<br />
/sbin/route add -host 192.168.0.202/32 dev usb0<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
iptables -P FORWARD ACCEPT<br />
sysctl -w net.ipv4.ip_forward=1<br />
su `whoami` -c &quot;scp /etc/resolv.conf root@192.168.0.202:/etc/resolv.conf&quot;&lt;/pre&gt;<br />
<br />
Again if your net already is 192.168.0.0, replace the POSTROUTING statement with<br />
&lt;pre&gt;iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/28&lt;/pre&gt;<br />
<br />
This simple script will set up routing for your Freerunner and than copy resolv.conf with dns addresses straight to the phone.<br />
All you have to do is connect phone to the computer, run the script and enjoy internet connection from your phone.<br />
<br />
= Linux Kernel Support =<br />
<br />
Your Linux desktop/laptop needs to have suitable support, in particular, you will need to have enabled full masquerading in the kernel and USB networking options enabled. For default kernels in many Linux distributions, this will already be the case. If not, you will need to enable:<br />
<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Both USB networking options are available in the<br />
<br />
''Device Drivers -&gt; USB support -&gt; USB Network Adapters''<br />
<br />
or<br />
<br />
''Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters -&gt; Multipurpose USB Networking Framework''.<br />
<br />
For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
Masquerading options (tested on Linux 2.6.26.3) are found in:<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;''<br />
<br />
To see the other options, enable<br />
<br />
* CONFIG_NETFILTER (''Network packet filtering framework (Netfilter)'')<br />
<br />
Then, from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
Core Netfilter Configuration ---&gt;''<br />
<br />
You need at least following options enabled as modules:<br />
<br />
* CONFIG_NF_CONNTRACK (''Netfilter connection tracking support'')<br />
* CONFIG_NF_CONNTRACK_FTP (''FTP protocol support'')<br />
* CONFIG_NETFILTER_XTABLES (''Netfilter Xtables support'')<br />
<br />
Rest of the needed options are found from<br />
<br />
''Networking ---&gt;<br />
Networking options ---&gt;<br />
[*] Network packet filtering framework (Netfilter) ---&gt;<br />
IP: Netfilter Configuration ---&gt;''<br />
<br />
You need to enable (again, as modules is fine):<br />
<br />
* CONFIG_NF_CONNTRACK_IPV4 (''IPv4 connection tracking support (required for NAT)'')<br />
* CONFIG_IP_NF_IPTABLES (''IP tables support (required for filtering/masq/NAT)'')<br />
* CONFIG_NF_NAT (''Full NAT'')<br />
* CONFIG_IP_NF_TARGET_MASQUERADE (''MASQUERADE target support'')<br />
<br />
= Firewall Issues =<br />
<br />
On some systems, you may have firewall rules which prevent this working - such as added by the iptables service on Fedora. You may care to stop these, and/or review any rules or policies you think might cause issues.<br />
<br />
The most relevant table is the nat table, which controls translation of addresses:<br />
<br />
iptables -L -t nat -v -n<br />
<br />
Unless you have a special setup, you'll want to see only the MASQUERADE rule that you apply below, and ACCEPT as the default policy. Also look at the filter table:<br />
<br />
iptables -L -t filter -v -n<br />
<br />
If this contains anything in the FORWARD chain, then this may prevent passing packets. It can be flushed with:<br />
<br />
iptables -t filter -F FORWARD<br />
<br />
= DNS =<br />
<br />
In addition to routing issues, to be practical, DNS will need to work. In some cases, you might already be running a DNS server on your desktop such as dnsmasq or bind9, which is the default assumption the FreeRunner makes. In other cases, you'll need to configure DNS to that of your router, or a DNS server further out on the internet such as that provided by your ISP.<br />
<br />
== Configure Default Neo DNS ==<br />
<br />
DNS is configured in /etc/resolv.conf on your FreeRunner.<br />
<br />
You should add the IP address of the DNS servers as provided by your ISP. Check your router's or PC's network status for the nameserver IP addresses.<br />
<br />
&lt;pre&gt;echo nameserver xxx.xxx.xxx.xxx &gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
You can also add the public DNS server called openDNS:<br />
&lt;pre&gt;echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
These settings will be lost on reboot. You can set the DNS for the next connect, by adding the following to the end of the usb0 setting in /etc/network/interfaces, right above the bluetooth networking section:<br />
&lt;pre&gt;up echo nameserver 208.67.222.222 &gt; /etc/resolv.conf<br />
up echo nameserver 208.67.220.220 &gt;&gt; /etc/resolv.conf&lt;/pre&gt;<br />
<br />
== Proxying DNS from Desktop/Laptop ==<br />
<br />
If you move about, making assumptions about the network may not be convenient, and it is possible to proxy DNS requests via your host laptop (which you are also taking with you), without running or installing a DNS server. There are a number of ways to do this:<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the DNS proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
<br />
Another easy setup is using a UDP forwarder like the one from http://www.tapor.com/udpf/ - use it with the command&quot;<br />
<br />
&lt;pre&gt;udpf-elf -p=53-f=`awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf`:53&lt;/pre&gt;<br />
<br />
=== Proxying with iptables ===<br />
<br />
It is possible to forward DNS requests with iptables using the DNAT target:<br />
<br />
&lt;pre&gt;iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1&lt;/pre&gt;<br />
<br />
Where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your router.<br />
<br />
Test if it works:<br />
&lt;pre&gt;ping www.google.com&lt;/pre&gt;<br />
<br />
If so, then this is sufficient for most internet access. But manual changes to resolv.conf are usually lost later if for example one uses DHCP, especially for WiFi, and so may not be convenient to configure manually.<br />
<br />
= Testing Your Connection =<br />
You should be able to connect to your Neo! Make sure you can ping your Neo to be sure.<br />
ping 192.168.0.202<br />
<br />
Then log into your Neo using ssh:<br />
ssh root@192.168.0.202<br />
The default password is blank (press enter).<br />
<br />
You can also [[scp]] files back and forth. You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.<br />
<br />
Now, make sure you can ping back to your desktop<br />
ping 192.168.0.200<br />
(Note that some systems like Vista, don't respond to ICMP ping by default)<br />
<br />
Try pinging the outside world (a Google IP address)<br />
ping 74.125.19.147<br />
This demonstrates that masquerading is working - your desktop is sending/receiving packets to the wider internet.<br />
<br />
Lastly, verify that DNS is correctly configured between the Neo &amp; Network:<br />
ping www.google.com<br />
<br />
= OS or Distro Specific &amp; Automatic Configuration =<br />
<br />
Based on [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] by Marcin 'Hrw' Juszkiewicz.<br />
These instructions should keep you from having to run the Simple Manual Linux Configuration every time you plug in and want to connect to an Openmoko device. One run and then you're done!<br />
<br />
If the Simple Manual Linux Configuration does not work for your OS or Distro (MacOS X, MS Windows, etc) there may be instructions here that work for you.<br />
<br />
== MacOS X ==<br />
See [[MacOS_X#USB_Networking|MacOS X USB Networking]].<br />
<br />
== Windows ==<br />
See [[Neo1973_and_Windows#USB_Ethernet_emulation|Windows USB Ethernet emulation for Neo1973]].<br />
<br />
There is also a very helpful tutorial for connecting with Vista at [http://sam.curren.ws/index.cfm/2008/7/14/Using-the-Neo-FreeRunner-with-Windows-XPVista].<br />
<br />
== FreeBSD ==<br />
You need to load the cdce kernel module (if it is not already linked into your kernel). As root do:<br />
<br />
# kldload cdce<br />
<br />
The Neo should then show up as cdce0 interface and you can handle the cdce0 interface just like the usb0 device under Linux. For more information see the cdce manpage. An easy way to assign the IP address to the cdce0 interface is using the devd(8) daemon. Create the following two files,<br />
<br />
/usr/local/etc/devd/cdce.conf as:<br />
<br />
notify 1 {<br />
match &quot;system&quot; &quot;IFNET&quot;;<br />
match &quot;subsystem&quot; &quot;cdce0&quot;;<br />
match &quot;type&quot; &quot;ATTACH&quot;;<br />
action &quot;/usr/local/etc/devd/cdce.sh $subsystem $type&quot;;<br />
};<br />
<br />
and /usr/local/etc/devd/cdce.sh as:<br />
<br />
#!/bin/sh<br />
case $2 in<br />
'ATTACH')<br />
ifconfig cdce0 192.168.0.200 netmask 255.255.255.0<br />
exit 0 ;<br />
;;<br />
esac<br />
exit 0<br />
<br />
Then restart the devd(8) daemon with:<br />
<br />
# /etc/rc.d/devd restart<br />
<br />
If you now plugin the FreeRunner into the USB port the cdce0 interface gets created and the IP addr will be assigned.<br />
<br />
<br />
== Debian, Ubuntu and others ==<br />
<br />
Edit /etc/network/interfaces and add:<br />
<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
<br />
&lt;/pre&gt;<br />
<br />
This is more sophisticated than the manual setup. The 'auto usb' stanza ties into the Linux hotplug system so that when the device appears and vanishes, as happens when the FreeRunner is connected via USB, this is run.<br />
<br />
In addition, the desktop-side netmask is limited to a much smaller range, so that overlapping subnets are less of a problem - Linux will use more specific routes first when deciding where to send packets.<br />
<br />
Another possible configuration that adds DNS forward and removes<br />
the iptables changes after unplugging:<br />
<br />
in /etc/network/interfaces add<br />
&lt;pre&gt;<br />
# freerunner<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.192<br />
post-up /etc/network/freerunner start<br />
pre-down /etc/network/freerunner stop<br />
&lt;/pre&gt;<br />
<br />
create file /etc/network/freerunner<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# configures the freerunner for internet<br />
#<br />
#<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
REMOTE_IPADDR=192.168.0.202<br />
NETMASK=255.255.255.0<br />
<br />
# get first ip for dns<br />
DNSIP=$(awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}' /etc/resolv.conf)<br />
<br />
case &quot;$1&quot; in<br />
start)<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -A PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -A PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ &quot;$(cat /proc/sys/net/ipv4/ip_forward)&quot; = &quot;0&quot; ]; then<br />
echo &quot;temoprarely allow ip_forward for openmoko&quot; &gt; /var/run/openmoko.ip_forward<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
stop)<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s $REMOTE_IPADDR<br />
iptables -D PREROUTING -t nat -p tcp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
iptables -D PREROUTING -t nat -p udp -s $REMOTE_IPADDR -d $IPADDR --dport domain -j DNAT --to-destination $DNSIP<br />
<br />
if [ -f /var/run/openmoko.ip_forward ]; then<br />
rm /var/run/openmoko.ip_forward<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
fi<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
Make /etc/network/freerunner executable with<br />
chmod +x /etc/network/freerunner<br />
<br />
It is possible to use network-manager to automatically connect to the Freerunner using udev. The process uses udev to run a script when the Frerunner is plugged in. The script uses the ip command to set the mac address of the usb network interface. To begin, create /etc/udev/rules.d/80-freerunner.rules :<br />
<br />
&lt;pre&gt;<br />
# This file causes programs to be run on device insertion.<br />
# See udev(7) for syntax.<br />
<br />
# rule to assign a fixed mac address specified in /<br />
KERNEL==&quot;usb[0-9]*&quot;, DRIVERS==&quot;cdc_ether&quot;, ACTION==&quot;add&quot;, RUN+=&quot;/usr/local/sbin/freerunner-usb-add.sh %k&quot;<br />
&lt;/pre&gt;<br />
<br />
Next, create the /usr/local/sbin/freerunner-usb-add.sh :<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
<br />
(<br />
busNum=$( printf %.2d $( expr match &quot;$1&quot; &quot;usb\([0-9]*\)&quot;) )<br />
<br />
ip link set &quot;$1&quot; address 00:00:22:55:bb:$busNum &amp;&gt; /dev/null<br />
<br />
) &amp;<br />
<br />
exit 0<br />
&lt;/pre&gt;<br />
<br />
Finally run &quot;chmod +x /usr/local/sbin/freerunner-usb-add.sh&quot; to make it executable. Now you can use network-manager with mac-address specific settings and get it to automatically connect.<br />
<br />
=== Ubuntu Issues ===<br />
<br />
Ubuntu 8.10 doesn't work as expected if you used /etc/network/interfaces to automate the connection. Network manager likes to latch onto the network device and add a default route through 192.168.0.202, breaking your network connection. Network manager also says you can't edit or remove this connection from its list. I'm going back to making the connection manually.<br />
<br />
Ubuntu Feisty, Gutsy and Hardy reportedly have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted. This is mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/130437<br />
<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules. Moving the DRIVERS==&quot;*?&quot; out of the top GOTO, to ACTION==&quot;add&quot; line fixes the problem.<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, DRIVERS==&quot;?*&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
&lt;/pre&gt;<br />
<br />
The bug is that the DRIVERS variable isn't set at all when the device is unplugged.<br />
<br />
This appears to be fixed in Ubuntu 8.04 [[User:Mattt|Mattt]] 11:38, 30 July 2008 (UTC)<br />
:Actually it appears that it's not fixed, but patching that file and disconnecting and reconnecting the phone works perfectly. --[[User:Johndoesacc|Johndoesacc]] 18:37, 20 August 2008 (UTC)<br />
:Well, yes, it must be fixed because it worked for me out-of-the-box without tweaking the udev rule on 8.04 --[[User:EtienneG|EtienneG]] November 26th, 2008<br />
=== Ubuntu Workaround ===<br />
Use [http://wicd.sourceforge.net/ wicd] instead of networkmanager:<br />
It is much further in development than networkmanager yet and doesn't make any problems with USB networking. You can use the &quot;normal&quot; settings in /network/interfaces.<br />
Note: Because of it's dependencies it deinstalls networkmanager.<br />
<br />
<br />
== Mandriva ==<br />
<br />
This first file configures the network system for the usb0 interface. Any time you plug in the FreeRunner the interface will be configured.<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/ifcfg-usb0&lt;/tt&gt;:<br />
<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.0.0<br />
BROADCAST=192.168.0.255<br />
ONBOOT=yes<br />
METRIC=10<br />
MII_NOT_SUPPORTED=no<br />
USERCTL=yes<br />
<br />
This next file configures the static routes that we need to communicate to the subnet. Since it has &quot;usb0&quot; in the name, the system will automatically apply these static routes any time that the usb0 interface is configured. (i.e. when you connect the FreeRunner)<br />
<br />
&lt;tt&gt;/etc/sysconfig/network-scripts/usb0-routes&lt;/tt&gt;:<br />
<br />
ADDRESS0=192.168.0.200<br />
NETMASK0=255.255.255.0<br />
<br />
Now we need to restart the network system to pick up the changes.<br />
<br />
service network restart<br />
<br />
<br />
This didn't work for me (Mandriva 2008.1), giving errors from Shorewall. However, simply using MCC, Network-&gt;Sharing Internet Access worked fine. You need to connect Neo when starting it. --[[User:Alih|Alih]] 18:50, 22 September 2008 (UTC)<br />
<br />
== SuSE ==<br />
<br />
/etc/sysconfig/network/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
<br />
For more information on getting USB networking up using YaST, see [[USB Networking with openSUSE]].<br />
<br />
== Fedora ==<br />
<br />
=== Option A - Tested with FC8 &amp; FC5 ===<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
<br />
=== Option B ===<br />
<br />
This setup is probably over-complex:<br />
<br />
/etc/sysconfig/network-scripts/ifcfg-usb0:<br />
<br />
DEVICE=usb0<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
<br />
/etc/sysconfig/network-scripts/ifup-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
/sbin/ip link set dev ${DEVICE} up<br />
/sbin/ip addr add dev ${DEVICE} ${IPADDR}/${NETBITS}<br />
<br />
/sbin/iptables -I POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
/sbin/sysctl net.ipv4.ip_forward=1<br />
/sbin/iptables -I FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -I FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
<br />
Set /etc/sysconfig/network-scripts/ifdown-usb:<br />
<br />
#!/bin/bash<br />
<br />
. /etc/init.d/functions<br />
<br />
cd /etc/sysconfig/network-scripts<br />
. ./network-functions<br />
<br />
[ -f ../network ] &amp;&amp; . ../network<br />
<br />
CONFIG=${1}<br />
<br />
need_config ${CONFIG}<br />
<br />
source_config<br />
<br />
NETBITS=`ipcalc -p ${IPADDR} ${NETMASK} | awk -F'=' '{print $2;}'`<br />
<br />
/sbin/iptables -D FORWARD -d ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/iptables -D FORWARD -s ${IPADDR}/${NETBITS} -j ACCEPT<br />
/sbin/sysctl net.ipv4.ip_forward=0<br />
/sbin/iptables -D POSTROUTING -t nat -j MASQUERADE -s ${IPADDR}/${NETBITS}<br />
<br />
/sbin/ip link set dev ${DEVICE} down<br />
/sbin/ip addr flush dev ${DEVICE} 2&gt;/dev/null<br />
<br />
If you are using NetworkManager, restart it and enable the usb device from its menu, otherwise it will disable your connection shortly after you enable it.<br />
<br />
/sbin/service NetworkManager restart<br />
=== Option C - tested on F9 ===<br />
(worked on FC8 too, can this be called &quot;tested&quot;?)<br />
<br />
Plug in the usb cable. NetworkManager should detect the phone automatically but you should ignore it.<br />
Open Network Configuration tool (System -&gt; Administration -&gt; Network) and perform following steps:<br />
# Click '''New''' button on top bar<br />
# Click '''Forward'''<br />
# Select OpenMoko from device list<br />
# Click '''Forward'''<br />
# Select 'Statically set IP address:' and enter address: 192.168.0.200, netmask 255.255.255.0 (or use 255.255.255.240 if you want only route ip range 192.168.0.192-192.168.0.207). Leave gateway empty.<br />
# Click '''Forward'''<br />
# Click '''Apply''' to close add dialog<br />
# Select newly added usb0 device from the device list.<br />
# Click '''Edit''' button on top bar<br />
# You might want to remove a tick from 'Activate device when computer starts' check box.<br />
# Click '''Ok''' to close window dialog.<br />
Save settings and close the window.<br />
<br />
Open Firewall Configuration (System -&gt; Administration -&gt; Firewall) and enable masquerading:<br />
# Select '''Masquerading''' from left panel<br />
# Check device(s) which you'd like to share internet connection. Typically eth0 or wlan0.<br />
# Click '''Apply''' and close application<br />
<br />
Open terminal and perform (as root user):<br />
# ifdown usb0<br />
# ifup usb0<br />
The first command will remove any existing settings given by the NetworkManager and second command brings the device up with appropriate settings.<br />
<br />
Now you should be able to ping e.g. 74.125.39.99 [www.google.com] from OpenMoko. Configure /etc/resolv.conf and you should have full a internet access.<br />
<br />
==== Troubleshooting ====<br />
If Network Configuration tool cannot see the the usb0 try to unplug the usb cable for a few seconds and wait until the NetworkManager finds it again.<br />
<br />
NetworkManager will assign a new ip address for the OpenMoko if link goes down for a while. You can fix this by issuing '''ifup usb0''' again.<br />
<br />
== Red Hat or Similar (tested with Workstation 5) ==<br />
<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command:<br />
<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
<br />
add<br />
<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
== Gentoo ==<br />
<br />
Open /etc/conf.d/net and add:<br />
<br />
# Neo<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
<br />
Create a new init script:<br />
<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
<br />
=== Manual Configuration ===<br />
<br />
Put iptables into use:<br />
<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
<br />
Store them:<br />
<br />
/etc/init.d/iptables save<br />
<br />
If you want the routing by default:<br />
<br />
rc-update add iptables default<br />
<br />
You must also inform the kernel, to start forwarding.<br />
<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
<br />
=== Automatic Configuration ===<br />
One way to automate all this is to create /etc/conf.d/net.usb0 as follows. It sets IP forwarding and the iptables rules all in one go. It removes the iptables rules and disables ip forwarding when the FreeRunner is unplugged.<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -D INPUT -s 192.168.0.202 -j ACCEPT<br />
iptables -D OUTPUT -s 192.168.0.200 -j ACCEPT<br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
return 0<br />
}<br />
<br />
== Slackware (tested with 12.1) ==<br />
<br />
Following is based on [http://www.enricozini.org/2008/tips/autodock-freerunner.html Enrico Zini's solution].<br />
<br />
Create a new udev rules file &lt;tt&gt;/etc/udev/rules.d/91-openmoko.rules&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;add&quot;, ATTRS{idVendor}==&quot;1457&quot;, ATTRS{idProduct}==&quot;5122&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} start&quot;<br />
SUBSYSTEM==&quot;net&quot;, ACTION==&quot;remove&quot;, ENV{INTERFACE}==&quot;usb[0-9]&quot;, RUN+=&quot;/sbin/om-usb $env{INTERFACE} stop&quot;<br />
&lt;/pre&gt;<br />
<br />
Then create the script &lt;tt&gt;/sbin/om-usb&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
INTERFACE=$1<br />
ACTION=$2<br />
<br />
# udev fails silently when the script fails, e.g. due to commands not<br />
# being found<br />
PATH=/usr/sbin:/sbin:/usr/bin:/bin<br />
<br />
case $ACTION in<br />
'start')<br />
# Put all your setup here<br />
;;<br />
'stop')<br />
# Put all your tear down here<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop}&quot;<br />
exit 1<br />
;;<br />
esac<br />
&lt;/pre&gt;<br />
<br />
The &lt;tt&gt;INTERFACE&lt;/tt&gt; will be &lt;tt&gt;usb0&lt;/tt&gt; in most cases.<br />
<br />
== Archlinux ==<br />
Following is based on [http://xenos.altervista.org/blogs/index.php?blog=3&amp;title=openmoko-usb-networking-su-archlinux furester's solution].<br />
<br />
Install package [http://aur.archlinux.org/packages.php?ID=20220 openmoko-usb-networking] from AUR:<br />
<br />
$ yaourt -S openmoko-usb-networking<br />
<br />
= SSH Extras =<br />
<br />
Reportedly, the ssh daemon (dropbear 0.49) on the FreeRunner appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
To avoid ssh adding a new line for every ssh host-key to your known_hosts you can add the following to the phone section in ~/.ssh/config (or see the snippet at : [[USB Networking#Changing_host_keys]] bellow)<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
== SSH Keys ==<br />
<br />
== From desktop to FreeRunner ==<br />
<br />
To generate ssh keys for use as a login mechanism type:<br />
<br />
user@host$ ssh-keygen -t rsa<br />
<br />
When prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh:<br />
<br />
root@phone# mkdir ~/.ssh<br />
<br />
Then from your desktop copy the '''.pub''' file to the phone.<br />
<br />
user@host$ scp ~/.ssh/id_rsa.pub root@phone:~/.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone without a password prompt using a command like 'ssh root@phone' from the account user@host because the public key in the file user@host:~/.ssh/id_rsa.pub is contained in the list of keys which have access in the file root@phone:~/.ssh/authorized_keys (since scp is used, only one key exists, but you can grant access to the phone from more than one account, for example user@host, user@laptop).<br />
<br />
To make ssh login as root by default, add the following lines to ~/.ssh/config:<br />
<br />
Host phone<br />
User root<br />
<br />
Replace ''phone'' with the hostname or ip of your phone. You should now be able to ssh into the phone without having to type ''root@'' every time.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to<br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
=== From FreeRunner to Desktop ===<br />
<br />
Generate the key:<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
=== Changing host keys ===<br />
<br />
If you reflash, your hosts keys will change. Try this ~/.ssh/config snippet:<br />
<br />
Host moko<br />
HostName 192.168.0.202<br />
StrictHostKeyChecking no<br />
UserKnownHostsFile /dev/null<br />
User root<br />
<br />
This is suggested because ssh on your desktop may complain if the key matching a certain IP changes (stored in .ssh/known_hosts). Now you have set this, you can issue the following command to connect to your moko :<br />
<br />
ssh root@moko<br />
<br />
== GUI on desktop through SSH ==<br />
<br />
To get the GUI on the FreeRunner onto the desktop via USB, you can use ssh as follows:<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Using this, run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
If you get an error like this:<br />
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to<br />
autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in.<br />
you need to set the DBUS_SESSION_BUS_ADDRESS environment variable to the value on the FreeRunner before launching the process from your desktop. You can find the value of this variable by using a command such as<br />
ps auxwwwwe | grep -m 1 DBUS_SESSION_BUS_ADDRESS<br />
Note that you must run that command on the FreeRunner. Back on your desktop, run the process you want with the ''env'' command like this:<br />
env DBUS_SESSION_BUS_ADDRESS=''dbus_address'' ''process'' #(isn't the &quot;env&quot; redundant here?)<br />
<br />
==Display Remote Applications on FreeRunner==<br />
<br />
To get desktop apps to show up on your FreeRunner, first log in:<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=openmoko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
==Automated setup network and mounting partitions==<br />
<br />
See [https://bugs.launchpad.net/ubuntu/+bug/289548 Ubuntu bug report in launchpad].<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt;<br />
{{Languages|USB Networking}}<br />
<br />
[[Category:USB]]<br />
[[Category:Implemented]]<br />
[[Category:Networking]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Talk:USB_NetworkingTalk:USB Networking2008-12-05T16:08:35Z<p>AudriusA: /* Simple alternative manual method to connect the device */</p>
<hr />
<div>= Driver options in kernel config =<br />
Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your<br />
desktop as a host are not in &quot;USB Support&quot; as the article says:<br />
&quot;Both options are available in the Device Drivers -&gt; USB support -&gt; USB Network Adapters. For more info see the usbnet driver homepage.&quot;<br />
Aren't the options in &lt;pre&gt;Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters&lt;/pre&gt;<br />
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)<br />
<br />
= Thoughts on USB networking in the final product =<br />
<br />
There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.<br />
<br />
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?)<br />
* 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)<br />
<br />
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.<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Suggested policies ==<br />
<br />
At this point I suggest, based on the aforementioned IRC discussion, the following policy:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Use cases ==<br />
<br />
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:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Open questions == <br />
<br />
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.<br />
<br />
=== Additional use cases ===<br />
<br />
There is another use cases I'd like to suggest for consideration:<br />
<br />
* 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).<br />
<br />
Suggested policy:<br />
* 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.<br />
<br />
= Operation on Gentoo =<br />
<br />
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:<br />
<br />
# Neo1973<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
postup() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -P FORWARD ACCEPT<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
predown() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
<br />
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.<br />
<br />
== Dealing with NetworkManager ==<br />
<br />
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<br />
RC_PLUG_SERVICES=&quot;!net.*&quot;<br />
to somehing like<br />
RC_PLUG_SERVICES=&quot;!net.eth* !net.wlan*&quot;<br />
<br />
(see http://gentoo-wiki.com/HOWTO_NetworkManager)<br />
<br />
= Rewrite =<br />
<br />
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). <br />
<br />
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.<br />
<br />
= Changing flow =<br />
<br />
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.<br />
<br />
== Overlapping subnets ==<br />
<br />
<br />
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.</div>AudriusAhttp://wiki.openmoko.org/wiki/Talk:USB_NetworkingTalk:USB Networking2008-12-05T16:04:47Z<p>AudriusA: /* Simple alternative manual method to connect the device */</p>
<hr />
<div>= Driver options in kernel config =<br />
Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your<br />
desktop as a host are not in &quot;USB Support&quot; as the article says:<br />
&quot;Both options are available in the Device Drivers -&gt; USB support -&gt; USB Network Adapters. For more info see the usbnet driver homepage.&quot;<br />
Aren't the options in &lt;pre&gt;Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters&lt;/pre&gt;<br />
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)<br />
<br />
= Thoughts on USB networking in the final product =<br />
<br />
There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.<br />
<br />
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?)<br />
* 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)<br />
<br />
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.<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Suggested policies ==<br />
<br />
At this point I suggest, based on the aforementioned IRC discussion, the following policy:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Use cases ==<br />
<br />
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:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Open questions == <br />
<br />
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.<br />
<br />
=== Additional use cases ===<br />
<br />
There is another use cases I'd like to suggest for consideration:<br />
<br />
* 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).<br />
<br />
Suggested policy:<br />
* 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.<br />
<br />
= Operation on Gentoo =<br />
<br />
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:<br />
<br />
# Neo1973<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
postup() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -P FORWARD ACCEPT<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
predown() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
<br />
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.<br />
<br />
== Dealing with NetworkManager ==<br />
<br />
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<br />
RC_PLUG_SERVICES=&quot;!net.*&quot;<br />
to somehing like<br />
RC_PLUG_SERVICES=&quot;!net.eth* !net.wlan*&quot;<br />
<br />
(see http://gentoo-wiki.com/HOWTO_NetworkManager)<br />
<br />
= Rewrite =<br />
<br />
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). <br />
<br />
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.<br />
<br />
= Changing flow =<br />
<br />
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.<br />
<br />
== Overlapping subnets ==<br />
<br />
<br />
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.<br />
<br />
= Simple alternative manual method to connect the device =<br />
The following alternative method has been described in this page for a long time, but recently it was replaced by to my opinion far more complex and sophisticated instructions. I have never had any problems with the previous method but at the same time these new updated instructions seem not working at all under my desktop. Hence I decided to move the old sequence of operations from the history into the talk page:<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo<br />
# ssh root@192.168.0.202<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.</div>AudriusAhttp://wiki.openmoko.org/wiki/Talk:USB_NetworkingTalk:USB Networking2008-12-05T16:04:00Z<p>AudriusA: /* Simple alternative manual method */</p>
<hr />
<div>= Driver options in kernel config =<br />
Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your<br />
desktop as a host are not in &quot;USB Support&quot; as the article says:<br />
&quot;Both options are available in the Device Drivers -&gt; USB support -&gt; USB Network Adapters. For more info see the usbnet driver homepage.&quot;<br />
Aren't the options in &lt;pre&gt;Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters&lt;/pre&gt;<br />
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)<br />
<br />
= Thoughts on USB networking in the final product =<br />
<br />
There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.<br />
<br />
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?)<br />
* 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)<br />
<br />
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.<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Suggested policies ==<br />
<br />
At this point I suggest, based on the aforementioned IRC discussion, the following policy:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Use cases ==<br />
<br />
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:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Open questions == <br />
<br />
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.<br />
<br />
=== Additional use cases ===<br />
<br />
There is another use cases I'd like to suggest for consideration:<br />
<br />
* 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).<br />
<br />
Suggested policy:<br />
* 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.<br />
<br />
= Operation on Gentoo =<br />
<br />
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:<br />
<br />
# Neo1973<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
postup() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -P FORWARD ACCEPT<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
predown() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
<br />
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.<br />
<br />
== Dealing with NetworkManager ==<br />
<br />
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<br />
RC_PLUG_SERVICES=&quot;!net.*&quot;<br />
to somehing like<br />
RC_PLUG_SERVICES=&quot;!net.eth* !net.wlan*&quot;<br />
<br />
(see http://gentoo-wiki.com/HOWTO_NetworkManager)<br />
<br />
= Rewrite =<br />
<br />
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). <br />
<br />
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.<br />
<br />
= Changing flow =<br />
<br />
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.<br />
<br />
== Overlapping subnets ==<br />
<br />
<br />
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.<br />
<br />
= Simple alternative manual method to connect the device =<br />
The following alternative method has been described in this page for a long time, but recently it was replaced by to my opinion far more complex and sophisticated instructions. I have never had any problems with the previous method but at the same time these new updated instructions seem not working at all under my desktop. Hence I decided to take the old sequence of operations, moving them into the talk page:<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo<br />
# ssh root@192.168.0.202<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.</div>AudriusAhttp://wiki.openmoko.org/wiki/Talk:USB_NetworkingTalk:USB Networking2008-12-05T16:03:38Z<p>AudriusA: alternative method</p>
<hr />
<div>= Driver options in kernel config =<br />
Hi, I didn't want to change it in case I was wrong, but I believe that the options to configure your<br />
desktop as a host are not in &quot;USB Support&quot; as the article says:<br />
&quot;Both options are available in the Device Drivers -&gt; USB support -&gt; USB Network Adapters. For more info see the usbnet driver homepage.&quot;<br />
Aren't the options in &lt;pre&gt;Device Drivers -&gt; Network Device Support -&gt; USB Network Adapters&lt;/pre&gt;<br />
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)<br />
<br />
= Thoughts on USB networking in the final product =<br />
<br />
There was some discussion on the #openmoko IRC channel on how to approach the USB networking automatic setup eventually in the final product.<br />
<br />
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?)<br />
* 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)<br />
<br />
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.<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Suggested policies ==<br />
<br />
At this point I suggest, based on the aforementioned IRC discussion, the following policy:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Use cases ==<br />
<br />
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:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Open questions == <br />
<br />
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.<br />
<br />
=== Additional use cases ===<br />
<br />
There is another use cases I'd like to suggest for consideration:<br />
<br />
* 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).<br />
<br />
Suggested policy:<br />
* 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.<br />
<br />
= Operation on Gentoo =<br />
<br />
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:<br />
<br />
# Neo1973<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
postup() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
iptables -P FORWARD ACCEPT<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
predown() {<br />
case &quot;${IFVAR}&quot; in <br />
&quot;usb0&quot;) <br />
iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0;;<br />
esac<br />
return 0<br />
}<br />
<br />
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.<br />
<br />
== Dealing with NetworkManager ==<br />
<br />
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<br />
RC_PLUG_SERVICES=&quot;!net.*&quot;<br />
to somehing like<br />
RC_PLUG_SERVICES=&quot;!net.eth* !net.wlan*&quot;<br />
<br />
(see http://gentoo-wiki.com/HOWTO_NetworkManager)<br />
<br />
= Rewrite =<br />
<br />
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). <br />
<br />
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.<br />
<br />
= Changing flow =<br />
<br />
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.<br />
<br />
== Overlapping subnets ==<br />
<br />
<br />
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.<br />
<br />
== Simple alternative manual method ==<br />
The following alternative method has been described in this page for a long time, but recently it was replaced by to my opinion far more complex and sophisticated instructions. I have never had any problems with the previous method but at the same time these new updated instructions seem not working at all under my desktop. Hence I decided to take the old sequence of operations, moving them into the talk page:<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo<br />
# ssh root@192.168.0.202<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
<br />
Do not forget to adjust your firewall so that you can connect to the device.</div>AudriusAhttp://wiki.openmoko.org/wiki/GpsdGpsd2008-07-13T09:04:55Z<p>AudriusA: /* Q: Can I get NMEA data from the GPS? */</p>
<hr />
<div>== What is GPS ==<br />
<br />
The Global Positioning System (GPS) is a a satellite positioning system, using a constellation of 31 satellites.<br />
<br />
GPS uses these as &quot;man-made stars&quot; to calculate positions to within a meter. With some forms of GPS. measurements accurate to better than a centimeter can be made.<br />
<br />
With advancing technology, receivers have shrunk from several dozen ICs and hundreds of other components, to one, and a handfull. <br />
<br />
This has drastically reduced costs.<br />
<br />
The reducing cost has enabled it to be easily integrated in phones, laptops, cameras, as well as more traditional apparatus such as farming equipment, navigation systems and construction equipment.<br />
<br />
(Another helpful overview [http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html Global Positioning System Overview])<br />
<br />
== [[Hardware:AGPS|AGPS]] ==<br />
is described on a [[Hardware:AGPS|page of its own]].<br />
<br />
== PMB 2520 Hammerhead ==<br />
The PMB 2520 Hammerhead is a one-chip solution for GPS that is produced by Infineon Technologies in cooperation with Global Locate. It allows the usage of assistance data by supporting A-GPS standards. <br />
<br />
(all infomation is coming from the datasheet of PMB 2520)<br />
[http://www.infineon.com/upload/Document/cmc_upload/documents/011/4061/pmb2520-pb-200505.pdf short datasheet]<br />
=== Modules of the Hammerhead===<br />
<br />
The Hammerhead consists of the following modules:<br />
*RF front-end with on-chip, high gain and low noise, LNA, I/Q mixers, on-chip polyphase complex IF filter, digitally controlled AGC, and 3-bits ADC for the I and Q paths.<br />
*Sigma-Delta RF PLL with on-chip PCO and on-chip loop filter.<br />
*Embedded PLL and NCO for baseband clock generation.<br />
*Multiple channels digital mixers and parallel correlator engines to enable real time correlation of the PRN code for up to 14 satellites.<br />
*Post processor including peak detection logic<br />
*SRAM for storing correlation results<br />
<br />
=== Host Interface ===<br />
<br />
The Hammerhead integrates 3 serial interfaces:<br />
*UART<br />
*I2C<br />
*SPI<br />
<br />
The UART in the Hammerhead is a full-duplex UART interface. It is fixed in 8N1(8 data bits, no parity, 1 stop bit) mode. On the GTA01, the host processor connect with the Hammerhead through the UART. In all models of Neo1973, this is connected to a serial port.<br />
<br />
=== Host software Architecture ===<br />
<br />
The Hammerhead driver software will be delivered as a binary, which can be interfaced to [http://gpsd.davisnetworks.com/bin/view/Main/GpsdHome gpsd] as it outputs NMEA information, as many serial GPSs do.<br />
<br />
The gps driver is [[Gllin|now available]]. (There were some problems in the past getting a license to distribute the binary. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html])<br />
<br />
The gpsd libraries provide the following infomation to the high level software:<br />
*Position data<br />
*Library status<br />
*Time-out and Packet Available<br />
<br />
The high level software sends the following messages to the plugin:<br />
*Assistance data<br />
*Positioning Commands<br />
*Configuration Commands<br />
<br />
Gpsd communicates with the system at the following part:<br />
*Communications Drivers<br />
*System Timer<br />
*NV storage<br />
*Log buffer<br />
<br />
== GPS on GTA01 ==<br />
<br />
At the GTA01, the host processor is a S3C2410.<br />
<br />
=== Hammerhead on the GTA01 ===<br />
<br />
On the GTA01, the Hammerhead are configured that connected with the host processor through the UART. The UART of data output/input is connected to the UART 1 of the SC2410. The UART of the hardware flow control is connected to the UART 2 of the SC2410.<br />
<br />
== GPS on GTA02 ==<br />
<br />
To get gpsd working on the Neo Freerunner you have to edit /etc/default/gpsd, change GPS_DEV=&quot;/dev/ttyS3&quot; to GPS_DEV=&quot;/dev/ttySAC1&quot;. that's it<br />
<br />
== Q &amp; A ==<br />
<br />
<br />
====Q: Can gpsd support Differential GPS.====<br />
*While the neo does not have any means of receiving [http://en.wikipedia.org/wiki/Differential_GPS DGPS] or WAAS/SCCM directly, it can be streamed from an internet server. <br />
*It may be possible to generate a global ionospheric model from stationary (charging?) neos that have GPS signal and cheap internet connections. This would enable very precise positions to be generated<br />
*This could generate positions accurate to well under a metre, compared to (probably) 2-3m without.<br />
*The gpsd plugin is the place that these corrections would need to be done, as they need to be performed on a per-satellite basis, before generating the position.<br />
*This is separate from AGPS - AGPS gives information on current satellite position, or computes your position for you. DGPS is a local minute by minute 'ionospheric weather' for your region.<br />
<br />
See also [[Server:A-GPS]].<br />
<br />
====Q: Can someone upload somewhere an strace of the interaction between gpsd, and the hammerhead chip?====<br />
*Ideally this would be requesting a GPS position every second, starting from 'cold', with no AGPS data, for at least half an hour, in an area where the reciever can see the sky.<br />
*To aid in reverse engineering efforts.<br />
*A reverse-engineering page has been created: [[Hammerhead/Protocol]]<br />
<br />
====Q: Can I get NMEA data from the GPS?====<br />
<br />
A: <br />
* The gpsd program 'gpspipe', with the -r switch will output NMEA data with the current position information. The right way to do it is to use libgpsd in your program if possible.<br />
* [[Gllin]] writes its NMEA data to the pipe by default, see [[getting GPS console output with gllin]] for more.<br />
* On FreeRunner, you can also read directly from the GPS chip by reading the file (communication pipe) from /dev/ttySAC1.<br />
<br />
{{Languages|Gpsd}}<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-07-13T07:43:16Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel). This NMEA log is available in the project page]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The first version were trying to read from the NMEA pipe in periodic scheduled calls but this results &quot;time travelling effect&quot;. Then 'select' function was involved that improved performance but created big loads on CPU. To reduce the loads, the incremental waiting time was introduced and finally we switched to using GTK built - in channel input library that can schedule call exactly when input from the pipe is available.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most of work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-07-13T07:34:39Z<p>AudriusA: /* About mediating libraries */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most of work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-07-13T07:33:32Z<p>AudriusA: /* GPS Sight as library */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== About mediating libraries ==<br />
Recently the talks started to appear that the &quot;true&quot; way to access GPS data is through some intermediate library rather than directly from the hardware. GPS Sight currently does not rely on any &quot;standard&quot; library. It has been written in times when the only &quot;supporting software&quot; available was the Linux cat command (cat /tmp/nmeaNP). Differently, we have spent a lot of time tuning our pipe reader that has big requirements for real time high precision positioning that Sight does. If you just read from it periodially, you get the &quot;time travelling effect&quot; when the coordinates shown are the coordinates from the past. If you spend too much in lopp waiting till the pipe is ready, this uses CPU power and drains the battery faster. If you check seldom, this makes the output unusable for some applications like tracking the player moving in the footbal field. The reader is where the most work has been spent and the most interesting contributions were received from various people. Our reader currently uses GTK channel support together with GTK timer functions - so it is packed with calls to default libraries already. And the simple GUI on top allows to test immediately how does performance is affected by changes in the algorithm. We expect to contribute that code to the standard GPS access library after it matures and gets many hours of direct testing by multiple users.<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Wishlist_-_Hardware_-_Novel_DevicesWishlist - Hardware - Novel Devices2008-07-12T17:56:48Z<p>AudriusA: /* Solar Panels */</p>
<hr />
<div>This page details hardware some would like in future OpenMoko devices that are very different from the [[Neo1973]]. DVD/media players, cameras, ...<br />
<br />
=== Hard Drive ===<br />
Providing a hard drive, will allow storing music, movies, etc. Add USB storage device capability to use the device as an external hard drive.<br />
<br />
=== OpenMoko-branded modem card ===<br />
<br />
A 3G modem card for use with other computing hardware, in particular PCs. Probably an internal expansion card such as an ExpressCard or Compact Flash card, with an alternative external (USB) unit for computers without internal slots. (In fact, a PCI-factor internal card for desktop computers might be reasonable too; see below.)<br />
<br />
There are already CardBus and external USB 3G modems available. In hardware terms, OpenMoko's modem could well be a simple rebranding of one of these existing products. But, at least in some areas, the 3G modem products available to end-users tend to be tied to a particular telco and bundled with that telco's software. They also have a mysterious tendency not to actually allow voice calls over the modem, even when the modem hardware appears to be quite capable of it. An OpenMoko modem that simply provided open drivers, no lock to a particular telco, good support for various operating systems, and simple support for voice and video calls over the modem, all out of the box, would already have some fairly unique selling points. (Since video conferencing is now taking off on personal computers, hardware that allows your desktop computer to make video calls to 3G mobile phones might well have a market, which is one reason why a PCI-factor card might not be so crazy.)<br />
<br />
But more than that, any software or services that OpenMoko develops to overcome the tricky problems of juggling and integrating different Internet and phone connections and different email, IM, VoIP and telephone-number identities on Internet-enabled phones would be available to users of the OpenMoko modem too. That would be a powerful selling point for the modem if and when OpenMoko has compelling solutions to these problems. In fact, the increased integration with PCs would make all OpenMoko devices more attractive. (&quot;Whenever I'm logged in to my laptop all my calls go there, even when I'm not in range of WiFi.&quot;)<br />
<br />
Since [[FIC]] already has well-established relationships in the PC world, it could presumably make good use of those connections in selling the modems.<br />
<br />
* Obviously the OpenMoko modem faces much the same problems with getting reasonably open access to 3G hardware that are delaying 3G for the [[Neo1973]] series <br />
<br />
* Naturally a 3G Neo1973 or other OpenMoko phone would (or should) be able to provide many of the same advantages when acting as a modem for a PC. But there will still be a place for dedicated modems, if only because yoking a full mobile phone to your computer isn't always the best solution <br />
<br />
* Just like full phones, modems would benefit from support for multiple SIMs (see [[Wish_List_-_Hardware#Ability_to_use_multiple_SIMs.2Fnetworks]]) if they're going to be used for (non-VoIP) voice<br />
<br />
* Bonus points if the hardware provides a POTS landline connection and the software can juggle it along with 3G and Internet connections...<br />
<br />
=== PCMCIA slot ===<br />
Extensibility would be nice. Standard pcmcia would be great for allowing wireless too. And pcmcia cards tend to be very low power.<br />
*1. can be used for a spare battery (is this possible?)<br />
*3. i can use my [http://www.echoaudio.com/Products/CardBus/IndigoIO/index.php Echo Audio Indigo I/O]<br />
*2. can be used for different cards around<br />
<br />
This is certain not to happen in a production phone, it's simply far too large, and requires complex support in hardware, which does not exist in most system on a chip devices as are used in phones. <br />
Even for the [[Expansion_Back]] it would be too large. --[[User:Speedevil|Speedevil]] 06:05, 28 February 2007 (CET)<br />
<br />
== Cameras &amp; Imaging ==<br />
==== See [[Wish_List_-_Hardware#Camera]] for additional/updated info on camera suggestions ====<br />
=== Interchangeable Camera Lenses ===<br />
<br />
A camera phone with a [http://en.wikipedia.org/wiki/Lens_mount lens mount] would allow swappable camera lenses and filters. Camera phones are usually stuck with tiny fixed lenses that don't allow focusing. Imaging being able to swap out the default lens with one that provides a better focus... or even a zoom! <br />
<br />
The C-Mount or [http://en.wikipedia.org/wiki/T-mount T-Mount] would be a good choice. Both are standard lens mount with many supporting lenses. Minolta, Canon, Nikon, Olympus, &amp; most other lens manufacturers also have [http://www.bhphotovideo.com/c/shop/300/Lens_Adapters_Mounts.html mount adapters] for their proprietary lenses. Then share lenses between your camera &amp; cell phone. The mount hole would need to be about 1 inch in diameter and go about 1/4 inch into the camera-phone (with the focal plane array chip at the bottom of this hole).<br />
<br />
CS-Mount would actually be better than a c mount because it requires 12.52mm from surface to imaging chip, instead of the 17.52mm required for c mounts.<br />
<br />
'''Added bonus If you work somewhere that doesn't allow cameras:'''<br />
The lens could be removed and a blank insert could be screwed in.<br />
The camera capability would be physically disabled!<br />
<br />
[[Image:Neo1973-ExpCamCS.png]] &lt;br /&gt;<br />
concept image from [[Hardware:Neo1973:Alternate_Cases:Camera]]<br />
<br />
<br />
=== Business Card Reader ===<br />
This is probably technically difficult if not impossible, maybe you could do it with the embedded camera hardware &amp; software<br />
<br />
I want to be able to place a business card face down on the the screen, and have the device automatically read the card and enter the info in the contacts.<br />
* There is no simple way of reading something placed on the screen, for the basic reason that the screen is in the way.<br />
* Of course you could always just take a picture of the card with a camera-phone. Then store it as it is or image recognition software could do character recognition &amp; extract the information.<br />
<br />
=== Solar Panels ===<br />
My old pocket calculator had solar panels, why not my phone?<br />
See also: [[Expansion_Back#Ideas which require slight modifications of the phone.]]<br />
<br />
Here is my Solar Panel Mod for the Neo1973(GTA01) <br />
[[Image:http://i98.photobucket.com/albums/l274/subfunction/PIC-0007.jpg]] --KrisAbsinthe<br />
<br />
May be not so bad idea when you are somewhere in mountains and cannot easily charge the battery. This may at least prolong the battery life. [[User:AudriusA|AudriusA]] 17:56, 12 July 2008 (UTC)<br />
<br />
=== Fuel Cell ===<br />
Some people want to put them in laptops &amp; fuel cells are the way of the future.<br />
<br />
===TV Out===<br />
With help of mouse and keyboard, a TV output may be very useful.<br />
Or to watch photos taken with a digital camera on holidays.<br />
Or for showing a slide presentation off.<br />
<br />
<br />
=== Larger Screen ===<br />
<br />
A model with a larger screen would be of use to many, especially with multi-touch. Higher resolution is probably less important than size until the DPI drops below 150 or so.<br />
<br />
<br />
=== Tiny Video Projector - &quot;Beamer&quot; ===<br />
<br />
At the [http://www.sid.org/conf/sid2007/sid2007.html DisplayWeek2007] several embeded video projectors for phones were presented. <br />
Those projecting devices are not much bigger than a cell phone. A LED-laser projects a sharp image at variable distance<br />
Could such a device be connected by bluetooth?<br />
[http://www.explay.co.il/ Explay] uses two a red and a green laser-LED as well as a conventional blue LED in its &quot;oio&quot;.<br />
Blue laser-LED are to expensive for customer products. The light passes a transmissive WVGA-LCD(640x480) and goes on <br />
to the screen. Its frequency is 60Hz and the projecting distance can be varied from 20cm(8inch) to 2m(80inch) with <br />
a sharp picture. It consumes about 5W and its light power is about 6 lumen. As the sharpness does not depend on<br />
distance, one can project the image on screens that are not plane. Like someones t-shirt.<br />
<br />
[http://www.microvision.com/ Microvistions] PicoProjektor however uses soley laser-LEDs. It is also 60Hz though 800x600px or 800x640.<br />
<br />
Potential problems might become the approval of a laser class 3 device.<br />
<br />
Final prices could be about $300.<br />
Taken from: http://www.heise.de/newsticker/meldung/90141 (german)<br />
<br />
===HMD===<br />
Possibility to use something like [http://www.aeinnovations.com/projects/ver0/ Eyeglass Mounted Display].<br />
<br />
Or a HUD for use in a car windscreen. Needs a small projector attached to the phone. The phone is placed in front of the steering wheel on the console and displays information projected against the windscreen.<br />
<br />
===Multi I/O adapter===<br />
*VGA, standard Jack (line in &amp; out), standard USB<br />
<br />
===Credit Card Swiper/Reader===<br />
*A credit card swipe function on the device, so that business operators can use the device to accept payments. In some markets a 'chip+pin' card reader may be an alternative. Existing devices are very expensive. Transaction information is sent over the internet, transaction &quot;hub&quot; services like 1stData could receive the data and reply with email receipts to the merchant, who could then forward the receipt to customer's email, or print a receipt on a bluetooth printer.<br />
<br />
===Modular hardware design / interchangeable components===<br />
It would be great to have several interchangeable components on the 'bus' of the device. Imagine opening the case and being able to add GPS to an empty internal bay or swap an Accelerometer for 3G support. <br />
Similar to the PCI hardware model of desktop PCs -- let savvy users swap and upgrade internal components by intentionally designing swappable components on some standardized bus.<br />
<br />
Unfortunately, this is a big problem for compact devices.<br />
To take the above examples. An accelerometer module may be 5mm*5mm*2mm. <br />
A 3G module 50mm*30mm*10mm, a GSM module 30mm*40mm*5mm and a GPS module 20mm*15mm*5mm. <br />
Apart from the wasted space problems, this means also that each module has to be custom-built for FIC. <br />
Then there is a second part - you have to have connectors and some way to clamp the module in place.<br />
<br />
This adds yet more weight and volume.<br />
--[[User:Speedevil|Speedevil]] 12:03, 29 June 2007 (CEST)<br />
<br />
==Unsorted==<br />
<br />
===Virtual laser keyboard===<br />
see...<br />
http://www.virtual-laser-keyboard.com/?an=google<br />
<br />
<br />
== Different Shapes &amp; Styles ==<br />
==== See [[Wish_List_-_Hardware#Casing]] for case suggestions &amp; case mods ==== <br />
The current shape is great and many people love it (and I myself plan on getting one). Still, different strokes for different folks &amp; we're allowed to muse about other options.<br />
<br />
<br />
===Dump the '''''egg-shaped''''' case design and go '''''rectangular''''' for more screen space===<br />
*I'm all for devices that look great and have great features - aside from that I really like the current design. Thus I'd like to comment that the design change request is probably not the majority's opinion. [[User:Abraxa|Abraxa]] 00:00, 18 February 2007 (CET)<br />
<br />
There will be many OpenMoko devices, of different designs. --[[User:Speedevil|Speedevil]] 06:19, 28 February 2007 (CET)<br />
<br />
<br />
===Clamshell===<br />
Nuff said<br />
<br />
===Twisting top===<br />
Perfect for a multi-directional camera phone (for easier self photos &amp; video conferencing)&lt;br /&gt;<br />
[[Image:Kg920phone.jpg]]&lt;br /&gt;<br />
<br />
===Alcohol Sensor===<br />
Alcohol sensor adjacent to microphone. It doesn't have to be accurate, just has to detect any amount of alcohol on the speaker's breath. I understand this is a very narrow market, but alcohol is on every parent's mind.<br />
<br />
I think those who drive cars might profit from this feature too. --[[User:Cedel|cedel]] 16:02, 20 February 2007 (CET)<br />
<br />
:Although this is a good idea, you have to be very careful about liability here. If it gives a false positive (i.e. you're not over the limit), and you have an accident, the OpenMoko team might be liable.<br />
<br />
::I guess the good alcohol sensor is very expensive, cheap very often give false outcome. However, they more often produce negative (no alcohol) while there is. And there's still the thing about guilt OpenMoko team would bear. --[[User:Tolein|tolein]] 18:01, 1 October 2007 (GMT+1)<br />
<br />
===Bottle opener===<br />
* including a bottle opener is very hard, but could be useful.<br />
* [http://www.bokonzept.de/php/images/462.jpg example]<br />
* It definitely is useful. A metal reinforced corner might be enough. While it is possible to open bottles with most cell phones, they don't look too good after opening a few cases.<br />
* Every multi-tool has to have a cork screw<br />
<br />
==Stackable Back Expansion plates==<br />
A reference specification for creating add-on devices. The phone has a back where other backs can be added and removed as the user desires depending on the function needed at the time supplied by each back expansion device. <br />
A USB 2.0 port which can use all usb devices such as a USB Storage or a Printer Etc.<br />
:Great idea, however it would require some other port, not USB. It should be thin, so it wouldn't take much space &quot;inside&quot; phone, and also should let you spin the add-on device, so it should be circular. --[[User:Tolein|tolein]] 18:02, 1 October 2007 (GMT+1)<br />
<br />
[[Category:User]]<br />
[[Category:Ideas| ]]<br />
[[Category:Hardware ideas]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-28T16:53:39Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (includes 3 intermediate stations and tunnel)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-28T16:52:35Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
[[Image:Gpssight train.jpg|thumb|right|Speed changes in the moving train (the straight black line is a tunnel)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/File:Gpssight_train.jpgFile:Gpssight train.jpg2008-06-28T16:51:12Z<p>AudriusA: Colored GPS trace, recorded in a moving trace, for GPS Sight project.
This picture has been released by its author under GNU GFDL</p>
<hr />
<div>Colored GPS trace, recorded in a moving trace, for GPS Sight project.<br />
<br />
This picture has been released by its author under GNU GFDL</div>AudriusAhttp://wiki.openmoko.org/wiki/File:Gpv_0_0_screen_shot.jpgFile:Gpv 0 0 screen shot.jpg2008-06-28T16:49:50Z<p>AudriusA: </p>
<hr />
<div>GPV 0.0.2 runs on the Neo1973<br />
<br />
This picture is released by its author, Audrius Meskauskas, under GNU GFDL.</div>AudriusAhttp://wiki.openmoko.org/wiki/File:Image-Gpv_0_0_screen_shot_2.jpgFile:Image-Gpv 0 0 screen shot 2.jpg2008-06-28T16:49:05Z<p>AudriusA: </p>
<hr />
<div>GPV trace tab<br />
This picture is released by its author, Audrius Meskauskas, under GNU GFDL.</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-28T16:45:25Z<p>AudriusA: /* Testing the device */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== GPS Sight as library ==<br />
GPS Sight maintains global variables with coordinates, speed and altitude, and also global array variables with the history on how these components were changing over time. Hence it has a potential to be a part of some other application that wants to be location - aware. Work is, however, needed to make a serious library from it. If anybody is interested in, can contribute.<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-28T16:38:40Z<p>AudriusA: /* FreeRunner */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
<br />
As FreeRunner is not currently available, it is difficult to test this piece of code. However we have tested by putting a file with NMEA content to /dev/ttySAC1, so the detection and switching works.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-28T16:36:38Z<p>AudriusA: /* Inside the project */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== FreeRunner ==<br />
GPS Sight should automatically detect FreeRunner GPS pipe (/dev/ttySAC1) and use it rather than /tmp/nmeaNP. FreeRunner does not need any GPS driver like gllin as its GPS chip generates standard NMEA directly.<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GpsdGpsd2008-06-09T20:05:56Z<p>AudriusA: /* Q: Can I get NMEA data from the GPS? */</p>
<hr />
<div>== What is GPS ==<br />
<br />
The Global Positioning System (GPS) is a a satellite positioning system, using a constellation of 31 satellites.<br />
<br />
GPS uses these as &quot;man-made stars&quot; to calculate positions to within a meter. With some forms of GPS. measurements accurate to better than a centimeter can be made.<br />
<br />
With advancing technology, receivers have shrunk from several dozen ICs and hundreds of other components, to one, and a handfull. <br />
<br />
This has drastically reduced costs.<br />
<br />
The reducing cost has enabled it to be easily integrated in phones, laptops, cameras, as well as more traditional apparatus such as farming equipment, navigation systems and construction equipment.<br />
<br />
(Another helpful overview [http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html Global Positioning System Overview])<br />
<br />
== [[Hardware:AGPS|AGPS]] ==<br />
is described on a [[Hardware:AGPS|page of its own]].<br />
<br />
== PMB 2520 Hammerhead ==<br />
The PMB 2520 Hammerhead is a one-chip solution for GPS that is produced by Infineon Technologies in cooperation with Global Locate. It allows the usage of assistance data by supporting A-GPS standards. <br />
<br />
(all infomation is coming from the datasheet of PMB 2520)<br />
[http://www.infineon.com/upload/Document/cmc_upload/documents/011/4061/pmb2520-pb-200505.pdf short datasheet]<br />
=== Modules of the Hammerhead===<br />
<br />
The Hammerhead consists of the following modules:<br />
*RF front-end with on-chip, high gain and low noise, LNA, I/Q mixers, on-chip polyphase complex IF filter, digitally controlled AGC, and 3-bits ADC for the I and Q paths.<br />
*Sigma-Delta RF PLL with on-chip PCO and on-chip loop filter.<br />
*Embedded PLL and NCO for baseband clock generation.<br />
*Multiple channels digital mixers and parallel correlator engines to enable real time correlation of the PRN code for up to 14 satellites.<br />
*Post processor including peak detection logic<br />
*SRAM for storing correlation results<br />
<br />
=== Host Interface ===<br />
<br />
The Hammerhead integrates 3 serial interfaces:<br />
*UART<br />
*I2C<br />
*SPI<br />
<br />
The UART in the Hammerhead is a full-duplex UART interface. It is fixed in 8N1(8 data bits, no parity, 1 stop bit) mode. On the GTA01, the host processor connect with the Hammerhead through the UART. In all models of Neo1973, this is connected to a serial port.<br />
<br />
=== Host software Architecture ===<br />
<br />
The Hammerhead driver software will be delivered as a binary, which can be interfaced to [http://gpsd.davisnetworks.com/bin/view/Main/GpsdHome gpsd] as it outputs NMEA information, as many serial GPSs do.<br />
<br />
The gps driver is [[Gllin|now available]]. (There were some problems in the past getting a license to distribute the binary. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html])<br />
<br />
The gpsd libraries provide the following infomation to the high level software:<br />
*Position data<br />
*Library status<br />
*Time-out and Packet Available<br />
<br />
The high level software sends the following messages to the plugin:<br />
*Assistance data<br />
*Positioning Commands<br />
*Configuration Commands<br />
<br />
Gpsd communicates with the system at the following part:<br />
*Communications Drivers<br />
*System Timer<br />
*NV storage<br />
*Log buffer<br />
<br />
== GPS on GTA01 ==<br />
<br />
At the GTA01, the host processor is a S3C2410.<br />
<br />
=== Hammerhead on the GTA01 ===<br />
<br />
On the GTA01, the Hammerhead are configured that connected with the host processor through the UART. The UART of data output/input is connected to the UART 1 of the SC2410. The UART of the hardware flow control is connected to the UART 2 of the SC2410.<br />
<br />
== Q &amp; A ==<br />
<br />
<br />
====Q: Can gpsd support Differential GPS.====<br />
*While the neo does not have any means of receiving [http://en.wikipedia.org/wiki/Differential_GPS DGPS] or WAAS/SCCM directly, it can be streamed from an internet server. <br />
*It may be possible to generate a global ionospheric model from stationary (charging?) neos that have GPS signal and cheap internet connections. This would enable very precise positions to be generated<br />
*This could generate positions accurate to well under a metre, compared to (probably) 2-3m without.<br />
*The gpsd plugin is the place that these corrections would need to be done, as they need to be performed on a per-satellite basis, before generating the position.<br />
*This is separate from AGPS - AGPS gives information on current satellite position, or computes your position for you. DGPS is a local minute by minute 'ionospheric weather' for your region.<br />
<br />
See also [[Server:A-GPS]].<br />
<br />
====Q: Can someone upload somewhere an strace of the interaction between gpsd, and the hammerhead chip?====<br />
*Ideally this would be requesting a GPS position every second, starting from 'cold', with no AGPS data, for at least half an hour, in an area where the reciever can see the sky.<br />
*To aid in reverse engineering efforts.<br />
*A reverse-engineering page has been created: [[Hammerhead/Protocol]]<br />
<br />
====Q: Can I get NMEA data from the GPS?====<br />
<br />
A: <br />
* The gpsd program 'gpspipe', with the -r switch will output NMEA data with the current position information. The right way to do it is to use libgpsd in your program if possible.<br />
* [[Gllin]] writes its NMEA data to the pipe by default, see [[getting GPS console output with gllin]] for more.<br />
<br />
{{Languages|Gpsd}}<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-06-09T06:12:48Z<p>AudriusA: </p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. Since the 0.0.4 release the program obtained two extra tabs where either altitude or velocity are shown in color in the covered path. GPS Sight concentrates on visualizing of the relative positioning data at the moment does not compete with the map based applications.<br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever. GTA2 uses a different pipe, but such adaptation would be a minor fix.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Neo_1973_GPSNeo 1973 GPS2008-06-09T06:08:39Z<p>AudriusA: /* Possible GPS programs */ + gps sight one of the most popular projects in projects.openmoko.org</p>
<hr />
<div>The Neo1973 device contains an integrated GPS. The particular device<br />
is marketed as an AGPS, and there is some [[Hardware:AGPS |<br />
discussion]] available as to what significance that &quot;A&quot; might have.<br />
<br />
Note that the GTA02 device contains u-blox ANTARIS 4 solution, you could find more hardware related information before GTA02 hardware page.<br />
<br />
Assisted GPS performance requirement also defined in GSM/GPRS 3GPP TS 25.171, CDMA 3GPP2 C.S0036-0&lt;br&gt;<br />
<br />
=== GTA01 GPS driver (gllin) ===<br />
''Main article - [[gllin]]''<br />
<br />
The GPS driver is available here: [http://3rdparty.downloads.openmoko.org/gllin/ http://3rdparty.downloads.openmoko.org/gllin/]. It is a command line tool that after starting writes the positioning data so that they can be read as if they were written to the file.<br />
<br />
And here the Mail from Michael Shiloh [http://lists.openmoko.org/pipermail/community/2007-November/011916.html http://lists.openmoko.org/pipermail/community/2007-November/011916.html]<br />
<br />
<br />
In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included <br />
in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device).<br />
This binary is called gllin and it is a oabi binary, i.e. it will only work in the 2007.1 OpenMoko environment. There is now a eabi binary, which works with 2007.2. <br />
<br />
There was an effort to write a Free Software<br />
program that could be used instead of this binary-only program, but this stalled after the decision to change GPS chips in GTA02.<br />
<br />
See [[Hammerhead/Protocol]] for details and the latest status.<br />
<br />
Some scripts for those with the binary are on [[Manually_using_GPS]]<br />
<br />
Please see the important information on [[Gllin]]!<br />
<br />
=== GTA02 GPS ===<br />
<br />
To turn on the GPS, echo 1 to the file ./devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron<br />
<br />
To read from the GPS, simply read /dev/ttySAC1.<br />
<br />
cat /dev/ttySAC1 will work fine.<br />
<br />
Before getting a fix, the GPS spits out lots of &quot;$GPTXT,01,01,01,NMEA unknown msg*58&quot;, though these stop once a fix is obtained. --[[User:Speedevil|Speedevil]] 11:52, 7 April 2008 (CEST)<br />
<br />
In Openmoko projects, you could find a GPS test program that could provide graphical and text dump of GPS information. This project called [http://svn.projects.openmoko.org/svnroot/openmoko-agpsui Openmoko AGPS UI project].<br />
<br />
=== Possible GPS programs ===<br />
<br />
As people develop more sophisticated GPS applications, please note them here.<br />
<br />
Here are some ideas for possibilities:<br />
<br />
* Cairo-based mapping<br />
* Routing<br />
* [[Openstreetmap]] a map viewer, annotation, and editing system.<br />
* [http://wiki.openstreetmap.org/index.php/Pyroute Pyroute] is a routing program written in Python by Ojw, and a mobile phone GUI for maps, GPS, and routing.<br />
* [[GPS-Trail]] a simple trail logger.<br />
* [[GPS_Navigation#roadmap|roadmap]] mapping system using freely available maps (US census TIGER, DGLib, shapefiles).<br />
* [[Geocaching]] paper chase for advanced users<br />
* Set Profile (Mute, etc.) to coordinates (ex. At work)<br />
* [[qpegps]] qtopia (arm PDA) based map viewer with gps features<br />
* [[Navit]] a car navigation system with routing engine.<br />
* [http://www.tangogps.org TangoGPS] works very well, downloads maps on demand and stores them for later use, very efficient. <br />
* [[QMapControl]] Qtopia based mapping widget. Displays maps and custom data, also other widgets can be bound to coordinates. GPS parser for the gllin output included.<br />
* [http://lists.openmoko.org/pipermail/community/2007-July/007252.html collection of ideas]<br />
* [http://www.kflog.org/cumulus/ Cumulus] GPS software for glider pilots (and pilots in general), has a port for Qtopia and pulls (world) maps from the KFLog flight planner project. I think someone has put a project like this on the projects website [http://projects.openmoko.org/projects/openvario/ here].<br />
* [http://svn.projects.openmoko.org/svnroot/openmoko-agpsui Openmoko AGPS UI project].<br />
* [[GPS Sight]], a popular OpenMoko project under LGPL.<br />
<br />
== Using the Neo's GPS on a Laptop ==<br />
<br />
*First be sure you have gllin installed on the Neo.<br />
*On host type: '''nc -vvn -l -p 5000 &gt; /tmp/nmeaNP'''<br />
*On the Neo type: '''nc 192.168.0.200 5000 &lt; /tmp/nmeaNP'''<br />
*<br />
*On the host PC install GPSD, your GPS is attached as /tmp/nmeaNP <br />
*start gpsd on host with: '''gpsd -p /tmp/nmeaNP'''<br />
*run your application! I used gpsdrive and it works better than my stand-alone GPS. <br />
*Tested with RoadNav.Works great!<br />
*<br />
*With this in mind if you have an unlimited data package you could export this over the internet.<br />
*the possibilities are limitless. <br />
<br />
== Bluetooth GPS relay ==<br />
<br />
To make your neo appear like a regular bluetooth GPS:<br />
<br />
*Power up the bluetooth radio<br />
*Run the gllin script<br />
*run '''sdptool add SP'''<br />
*run '''rfcomm watch 0 1 sh -c &quot;cat /tmp/nmeaNP &gt;/dev/rfcomm0&quot; &amp;'''<br />
<br />
<br />
[[Category:GPS]]<br />
<br />
[[category:Documentation]]<br />
[[category:Standard]]</div>AudriusAhttp://wiki.openmoko.org/wiki/File_transferFile transfer2008-06-08T11:13:13Z<p>AudriusA: </p>
<hr />
<div>The OpenMoko hardware and software offer several ways to transfer files to and from the system.<br />
<br />
== SCP ==<br />
client (find host pc ip-adress: scp &lt;hostLoginName&gt;@&lt;hostIP&gt;:/file .)<br />
<br />
server (on host pc: 'scp &lt;file&gt; root@192.168.0.202:/tmp/')<br />
<br />
== TFTP ==<br />
client ('tftp')<br />
<br />
server?<br />
<br />
== NFS ==<br />
client (on Neo: 'mount -t nfs ...' or edit /etc/fstab and '/etc/init.d/mountnfs.sh start')<br />
<br />
server?<br />
<br />
== HTTP ==<br />
client (on Neo: 'wget',web browser)<br />
<br />
== MicroSD ==<br />
It is possible to write data to micro SD on a desktop machine with the suitable writer and then have it accessible from inside the OpenMoko after the card is inserted into that device. To get this working, the micro SD must be formatted in some filesystem that both OpenMoko and host understand (ext2, for instance). <br />
<br />
The problem with this approach is that micro SD is difficult to access in the Neo. Both battery and even SIM card must be removed to reach it.<br />
<br />
== SFTP ==<br />
SFTP can be an excellent way to transfer files as it is supported by many possible clients on the desktop machine. After USB network is set up, it is possible to try to open sftp connection by entering sftp://192.168.0.202 into the address bar of the browser that supports sftp. <br />
<br />
The user name on the local host must match the name of the existing user account on the device, and the user password field must not be empty. <br />
<br />
== FTP ==<br />
FTP is currently considered insecure. There is no any reason to use FTP, SFTP should be used instead.<br />
<br />
== Common methods not supported ==<br />
*Bluetooth (except via other network methods)<br />
[[Category:Software]]<br />
[[Category:Applications]]<br />
[[Category:Openmoko]]</div>AudriusAhttp://wiki.openmoko.org/wiki/File_transferFile transfer2008-06-08T11:12:52Z<p>AudriusA: </p>
<hr />
<div>The OpenMoko hardware and software offer several ways to transfer files to and from the system.<br />
<br />
''WARNING: This information is based on personal account possibly using an old system (uname -a: Linux fic-gta01 2.6.20.7-moko8 #2 PREEMPT Wed May 2 14:45:45 CST 2007 armv4tl unknown)'' --kinscore<br />
<br />
== SCP ==<br />
client (find host pc ip-adress: scp &lt;hostLoginName&gt;@&lt;hostIP&gt;:/file .)<br />
<br />
server (on host pc: 'scp &lt;file&gt; root@192.168.0.202:/tmp/')<br />
<br />
== TFTP ==<br />
client ('tftp')<br />
<br />
server?<br />
<br />
== NFS ==<br />
client (on Neo: 'mount -t nfs ...' or edit /etc/fstab and '/etc/init.d/mountnfs.sh start')<br />
<br />
server?<br />
<br />
== HTTP ==<br />
client (on Neo: 'wget',web browser)<br />
<br />
== MicroSD ==<br />
It is possible to write data to micro SD on a desktop machine with the suitable writer and then have it accessible from inside the OpenMoko after the card is inserted into that device. To get this working, the micro SD must be formatted in some filesystem that both OpenMoko and host understand (ext2, for instance). <br />
<br />
The problem with this approach is that micro SD is difficult to access in the Neo. Both battery and even SIM card must be removed to reach it.<br />
<br />
== SFTP ==<br />
SFTP can be an excellent way to transfer files as it is supported by many possible clients on the desktop machine. After USB network is set up, it is possible to try to open sftp connection by entering sftp://192.168.0.202 into the address bar of the browser that supports sftp. <br />
<br />
The user name on the local host must match the name of the existing user account on the device, and the user password field must not be empty. <br />
<br />
== FTP ==<br />
FTP is currently considered insecure. There is no any reason to use FTP, SFTP should be used instead.<br />
<br />
== Common methods not supported ==<br />
*Bluetooth (except via other network methods)<br />
[[Category:Software]]<br />
[[Category:Applications]]<br />
[[Category:Openmoko]]</div>AudriusAhttp://wiki.openmoko.org/wiki/File_transferFile transfer2008-06-08T11:10:59Z<p>AudriusA: /* common methods not supported */</p>
<hr />
<div>The OpenMoko hardware and software offer several ways to transfer files to and from the system.<br />
<br />
''WARNING: This information is based on personal account possibly using an old system (uname -a: Linux fic-gta01 2.6.20.7-moko8 #2 PREEMPT Wed May 2 14:45:45 CST 2007 armv4tl unknown)'' --kinscore<br />
<br />
== SCP ==<br />
client (find host pc ip-adress: scp &lt;hostLoginName&gt;@&lt;hostIP&gt;:/file .)<br />
<br />
server (on host pc: 'scp &lt;file&gt; root@192.168.0.202:/tmp/')<br />
<br />
== TFTP ==<br />
client ('tftp')<br />
<br />
server?<br />
<br />
== NFS ==<br />
client (on Neo: 'mount -t nfs ...' or edit /etc/fstab and '/etc/init.d/mountnfs.sh start')<br />
<br />
server?<br />
<br />
== HTTP ==<br />
client (on Neo: 'wget',web browser)<br />
<br />
== MicroSD ==<br />
It is possible to write data to micro SD on a desktop machine with the suitable writer and then have it accessible from inside the OpenMoko after the card is inserted into that device. To get this working, the micro SD must be formatted in some filesystem that both OpenMoko and host understand (ext2, for instance). <br />
<br />
The problem with this approach is that micro SD is difficult to access in the Neo. Both battery and even SIM card must be removed to reach it.<br />
<br />
== SFTP ==<br />
SFTP can be an excellent way to transfer files as it is supported by many possible clients on the desktop machine. After USB network is set up, it is possible to try to open sftp connection by entering sftp://192.168.0.202 into the address bar of the browser that supports sftp. <br />
<br />
The user name on the local host must match the name of the existing user account on the device, and the user password field must not be empty. <br />
== common methods not supported ==<br />
*FTP<br />
*SFTP<br />
*Bluetooth (except via other network methods)<br />
[[Category:Software]]<br />
[[Category:Applications]]<br />
[[Category:Openmoko]]</div>AudriusAhttp://wiki.openmoko.org/wiki/File_transferFile transfer2008-06-08T11:02:35Z<p>AudriusA: /* MicroSD */ nonsens, works</p>
<hr />
<div>The OpenMoko hardware and software offer several ways to transfer files to and from the system.<br />
<br />
''WARNING: This information is based on personal account possibly using an old system (uname -a: Linux fic-gta01 2.6.20.7-moko8 #2 PREEMPT Wed May 2 14:45:45 CST 2007 armv4tl unknown)'' --kinscore<br />
<br />
== SCP ==<br />
client (find host pc ip-adress: scp &lt;hostLoginName&gt;@&lt;hostIP&gt;:/file .)<br />
<br />
server (on host pc: 'scp &lt;file&gt; root@192.168.0.202:/tmp/')<br />
<br />
== TFTP ==<br />
client ('tftp')<br />
<br />
server?<br />
<br />
== NFS ==<br />
client (on Neo: 'mount -t nfs ...' or edit /etc/fstab and '/etc/init.d/mountnfs.sh start')<br />
<br />
server?<br />
<br />
== HTTP ==<br />
client (on Neo: 'wget',web browser)<br />
<br />
== MicroSD ==<br />
It is possible to write data to micro SD on a desktop machine with the suitable writer and then have it accessible from inside the OpenMoko after the card is inserted into that device. To get this working, the micro SD must be formatted in some filesystem that both OpenMoko and host understand (ext2, for instance). <br />
<br />
The problem with this approach is that micro SD is difficult to access in the Neo. Both battery and even SIM card must be removed to reach it.<br />
<br />
== common methods not supported ==<br />
*FTP<br />
*SFTP<br />
*Bluetooth (except via other network methods)<br />
[[Category:Software]]<br />
[[Category:Applications]]<br />
[[Category:Openmoko]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-04-25T06:03:41Z<p>AudriusA: /* Testing the device */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. <br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. The distance meter also seems operating correctly.<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GPS_SightGPS Sight2008-04-25T06:03:08Z<p>AudriusA: /* Project organization */</p>
<hr />
<div>[[Image:Gpv 0 0 screen shot.jpg|thumb|right|The summary tab]]<br />
[[Image:Image-Gpv 0 0 screen shot 2.jpg|thumb|right|The map tab (walking forward and back through the same street)]]<br />
The GPS Sight is a GTK based project to create a usable GUI tool with the simple output (no maps). It detects GPRMC and GPGGA messages and constantly shows the following data on the screen:<br />
<br />
* Location.<br />
* Speed in kilometers per hour (converts from knots).<br />
* Altitude<br />
* Curved distance from the initially marked point (uses advanced IERC 2003 geodetic reference to convert degrees into kilometers).<br />
* Number of the satellites.<br />
* Time (UTM, not a local time).<br />
<br />
Since the 0.0.2 release the application also has the &quot;map&quot; tab which shows the covered path. The map adjusts its scale automatically. The horizontal and vertical scales of the map are equal. <br />
<br />
The source code of this project is available in the project page (http://projects.openmoko.org/projects/gpv/), under LGPL. The project uses GTK framework and C programming language.<br />
<br />
The GPS Preview program (gpv) is released either in .ipk file or in the form of the source code. The released installer still needs the [[gllin]] to run, but, if needed, can start it itself. Gllin could be replaced by any other driver that works with agreed pipe (currently /tmp/nmeaNP) and our dream is to drop the dependencies from that proprietary piece of software forever.<br />
<br />
== Inside the project ==<br />
The most interesting part of this project was to keep the external driver thread and GUI thread sufficiently happy together. We cannot just read from the pipe in a loop as this blocks the GUI repainting! Instead, the code schedules the GTK timer, and then it needs to check if any input from the pipe is available - again, without blocking the current thread for too long. This is done using select function which can check the given stream for the availability of input, passing the certain time-out duration. This time-out seems also tricky: if the value or 0.1 s or less is passed on the Neo, function never reports any input present. However too large values block GUI in the input check step. The code now has a kind of adaptation, gradually increasing the duration of this check if there is no input available for a while.<br />
<br />
The distance counter tries to track the curved distance, not the &quot;bird flight&quot; distance between two points. It adds the shifts in space, computing the length of the lat/long degrees into meters in accordance to the IERS 2003 goedetic reference - very new and not yet widely used in geography.<br />
<br />
It was some work to fullfil the natural requirement to have the equal scaling for the map. The length of the degree of the longitude (in meters) varies dramatically depending on the geographical location. This must be taken into consideration, computing the degree length first. The automatic scaling allows to use the map tab when working with relatively small distances (hundreds of meters of even less).<br />
<br />
== Testing the device ==<br />
The device has been tested outdoors where it shows the correct location and altitude. The speed indicator has been tested on the train, correctly showing the speed of about 100 km/h. <br />
<br />
Nobody yet tested, how accurate the distance counter is (please update this information if you ever tried).<br />
<br />
== Project organization ==<br />
The project uses CVS to host the most recent source code and all build environment and sometimes does releases of .ipk binaries and plain gzipped source code. Project also uses [http://projects.openmoko.org/plugins/wiki/index.php?id=108&amp;type=g Wiki page] to describe various technical aspects.<br />
<br />
[[Category:GPS]]</div>AudriusAhttp://wiki.openmoko.org/wiki/User_talk:AudriusAUser talk:AudriusA2008-04-24T19:46:03Z<p>AudriusA: </p>
<hr />
<div>Hello Audrius<br />
<br />
We are trying to get 10 people together for buying the &quot;10 pack&quot; of the new release, the freerunner. Therefore we wanted to ask if you intend to buy another openmoko.<br />
<br />
We entered our Info at the Group Sales page: http://wiki.openmoko.org/wiki/GroupSales (Switzerland, Zurich).<br />
<br />
Thanks and cu<br />
Markus<br />
::Sory, no. I already have one, it is good enough for learning purposes. [[User:AudriusA|AudriusA]] 21:46, 24 April 2008 (CEST)</div>AudriusAhttp://wiki.openmoko.org/wiki/Manually_using_BluetoothManually using Bluetooth2008-04-14T19:12:23Z<p>AudriusA: /* Bluetooth networking with a Linux system */ Removed shell part of the commands (must be discarded before copy pasting anyway) and added the note about bringing bnep up on the phone as well</p>
<hr />
<div>{{InProgress}}<br />
Bluetooth is one of the core functions of the Neo1973, however it is basically unimplemented on the software side at the moment.<br />
Hardware problems in the P1 phone mean that the CPU has to be active in order to wake on external bluetooth events, which will reduce the battery life to some 2 days at best in standby.<br />
<br />
This page details how to use bluetooth from the command line.<br />
We have quite a lot of plans about what exactly Bluetooth should be used for.<br />
<br />
== Power it up ==<br />
<br />
Power up the adapter by clicking on the bluetooth icon in the top bar and selecting power on.<br />
<br />
The old way to do it is a shell command (for kernels before 2.6.24):<br />
<br />
root@fic-gta01:~$ echo &quot;1&quot; &gt; /sys/bus/platform/devices/gta01-pm-bt.0/power_on<br />
<br />
For kernel 2.6.24 (or later) use<br />
<br />
root@fic-gta01:~$ echo &quot;1&quot; &gt; /sys/bus/platform/devices/neo1973-pm-bt.0/power_on<br />
<br />
At the shell, &quot;hciconfig&quot; should print information about the adapter if it powered up properly:<br />
<br />
hciconfig<br />
<br />
The devices should show as UP. If not you can use <br />
<br />
hciconfig &lt;device&gt; up<br />
<br />
== Bluetooth Functions ==<br />
<br />
===Configuring Bluetooth on OpenMoko 2007.2 (August 27 snapshot with kernel 2.6.21.6-moko11) ===<br />
<br />
In file /etc/bluetooth/hcid.conf you should change the passkey from BlueZ to something numeric. For testing you may use &quot;0000&quot;. Also, you can set the name to &quot;Neo (%d)&quot;.<br />
<br />
=== Scanning for bluetooth devices ===<br />
<br />
hcitool scan<br />
<br />
This will list the addresses of any discoverable bluetooth devices in the vicinity<br />
<br />
=== passkey agent example ===<br />
<br />
There should be a passkey agent built into openmoko, but for now you can start up the example passkey agent and set the pin code there. This will allow for new pairings to be made when you attempt a connection.<br />
<br />
passkey-agent --default 0000 &amp;<br />
<br />
Note: the passkey-agent is not required in OpenMoko 2007.2 with kernel 2.6.21.6 as of at least since August 27 (maybe earlier).<br />
<br />
=== HID (Human Input Device) ===<br />
<br />
==== Being able to use HID devices ====<br />
<br />
Using a bluetooth keyboard with the built-in terminal is a little funky... I can only type into the console using the bt keyboard if the onscreen keyboard is visible. Also, pressing &quot;p&quot; twice on the bt keyboard actually gives you a &quot;q&quot;.<br />
<br />
We want to be able to use a bluetooth keyboard to type into the various applications of our Neo1973.<br />
To use a Bluetooth Keyboard type: (11:22:33:44:55:66 is the Address of your BT-Keyboard)<br />
<br />
hidd --connect 11:22:33:44:55:66<br />
<br />
and press &quot;Connect&quot; on your BT-KB. Alternately, if you know that only one BT-Keyboard is within range, you can just:<br />
<br />
hidd --search<br />
<br />
to find and connect to any BT-Keyboard.<br />
<br />
Tested on:<br />
* [http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2166,CONTENTID=10717 Logitech Dinovo Edge]<br />
* [http://www.logitech.com/index.cfm/keyboards/keyboard_mice_combos/devices/164&amp;cl=us,en Logitech Dinovo Media Desktop (keyboard)]<br />
* [http://www.nokia.es/A4181580 Nokia SU-8W]. Switched on the BT keyboard, scanned for BT address and ran the connect statement above. Works fine.<br />
* [http://blog.russnelson.com/chordite Chordite]. This keyboard uses the Broadcom BCM2042 BT keyboard controller along with a custom driver.<br />
* [http://www.apple.com/keyboard/ Apple's Aluminum Keyboard]. You may have to add 'auth enable; encrypt enable;' to device {} in hcid.conf. Run the passkey agent the first time. --search works to pair and every time after.<br />
* [http://www.apple.com/support/keyboard/ Apple's white &quot;Wireless Keyboard (original)&quot;] - details may be the same as above. (tested some time ago)<br />
* [http://freedominput.com The freedom keyboard] and its many rebranded models (they look like this: [http://rabenfrost.net/openmoko/keyboard.jpg]) need 'modprobe uinput' to circumvent the 'Can't open input device: No such file or directory (2)' error of 'hidd --search'. It works as of february 7th 2008.<br />
* [http://www.nextag.com/Playstation-3-Logitech-Cordless-564345667/prices-html?nxtg=f8320a24052a-7789F8FE732FF6E3 Logitech Playstation 3 Keyboard] Works well, Mouse pad works.<br />
<br />
==== Acting as HID device ====<br />
<br />
We want to be able to use the Neo1973 as a HID device, being able to use it as controller for presentations.<br />
<br />
=== RFCOMM ===<br />
<br />
Here's how to connect to an external Bluetooth GPS and read NMEA data (Tested with a Holux GPSSlim236 and a Nokia LD-3W ).<br />
<br />
First, switch on the GPS and identify the BT address:<br />
<br />
hcitool scan<br />
<br />
Then, edit /etc/bluetooth/rfcomm.conf, which by default has all settings commented out, to something like this:<br />
<br />
rfcomm0 {<br />
# Automatically bind the device at startup<br />
bind no;<br />
# Bluetooth address of the device<br />
device 00:11:22:33:44:55;<br />
# RFCOMM channel for the connection (check your GPS docs for details)<br />
channel 1;<br />
# Description of the connection<br />
comment &quot;Bluetooth GPS&quot;;<br />
}<br />
<br />
Restart the BT services:<br />
<br />
root@neo:~$ /etc/init.d/bluetooth stop<br />
root@neo:~$ /etc/init.d/bluetooth start<br />
<br />
You should now be able to bind the GPS to /dev/rfcomm0, like this:<br />
<br />
root@neo:~$ rfcomm bind 0<br />
<br />
Confirm the connect:<br />
<br />
root@neo:~$ rfcomm<br />
rfcomm0: 00:11:22:33:44:55 channel 1 clean <br />
<br />
... and watch the NMEA strings coming from your GPS:<br />
<br />
root@neo:~$ cat /dev/rfcomm0 <br />
$GPGGA,111748.000,5907.6964,N,01121.1787,E,1,06,1.2,57.7,M,40.1,M,,0000*6F<br />
$GPRMC,111748.000,A,5907.6964,N,01121.1787,E,0.00,94.94,160807,,,A*50<br />
$GPVTG,94.94,T,,M,0.00,N,0.0,K,A*3D<br />
<br />
If you have nothing better to do, you can now pinpoint my office :-).<br />
<br />
=== OBEX ===<br />
<br />
=== Networking ===<br />
<br />
=== Bluetooth networking with a Linux system ===<br />
<br />
Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.<br />
<br />
'''On the laptop'''<br />
<br />
* Start bluetooth<br />
/etc/init.d/bluetooth start<br />
<br />
* Start pand as server<br />
pand -s<br />
<br />
* As soon as pand is started on the phone configure your IP address<br />
ip a add 10.0.0.1/24 dev bnep0<br />
ip l set bnep0 up<br />
<br />
* Configure IP forwarding and masquerading to your liking (see [[USB_Networking]]). You can even set up Udev rules to do this for you once the bnep0 interface appears.<br />
<br />
<br />
'''On the Neo'''<br />
<br />
* There is a little script that does the steps below (and retries the pand -c command; I had issues with it not working the first time every time) at [[Bt-net-script]] You shouldn't need the other steps below if you use the script.<br />
<br />
* Power on bluetooth (see above)<br />
<br />
* Scan for the laptop<br />
root@fic-gta01:~$ hcitool scan<br />
Scanning ...<br />
00:0E:6D:C0:0l:6A Sho<br />
00:20:E0:5A:FE:C8 BlueZ (0)<br />
<br />
* Connect to the laptop pand<br />
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8<br />
<br />
* Configure your IP address<br />
ip a add 10.0.0.2/24 dev bnep0<br />
ip r add default via 10.0.0.1<br />
<br />
* Sometimes you may need to bring up the bnep0 on the phone as well:<br />
ip l set bnep0 up<br />
* Enjoy<br />
<br />
=== Bluetooth networking with a MacOS X system ===<br />
<br />
Please refer to [[MacOS_X#Bluetooth_2]]<br />
<br />
For using the Neo as a dialup Bluetooth server and the Mac as the client, please see below at [[Manually_using_Bluetooth#PPP_Networking]]<br />
<br />
=== Bluetooth networking with a Windows XP system ===<br />
<br />
This was tested with a Windows XP SP2 on a IBM Thinkpad T41 with the Widcomm BT stack<br />
<br />
* Start bluetooth on Windows XP<br />
<br />
* Enable &quot;Network Access&quot; in the Bluetooth configuration<br />
<br />
* Scan for the Neo and pair with the Neo (right click, select pair)<br />
<br />
<br />
On the Neo<br />
<br />
* Enable PAN support on the Neo by changing Autostart from false to true in /etc/bluetooth/network.service<br />
<br />
* Power on bluetooth (see above)<br />
<br />
* Scan for the laptop<br />
root@fic-gta01:~$ hcitool scan<br />
Scanning ...<br />
&lt;laptop_bt_address&gt; Thinkpad<br />
...<br />
<br />
<br />
* Connect to the laptop pand<br />
pand -c &lt;laptop_bt_address&gt; -r PANU -d NAP -e bnep0 -A -E -S<br />
(add '-n' to see the pand status messages until you get it right)<br />
<br />
For some reason, I was not able to initiate PAN connections from the Neo, I got 'Permission denied (13)' even when I had explicitly allowed the Neo to connect (right click on Neo icon, set properties, on Authorization tab). But initiating 'PAN User' from Windows worked when executing on Neo:<br />
pand -l -r PANU -d NAP -e bnep0 -A -E -S<br />
(add '-n' to see the pand status messages until you get it right)<br />
<br />
<br />
* Configure your IP address. It should work like when connecting to Linux:<br />
ip a add 10.0.0.2/24 dev bnep0<br />
ip r add default via 10.0.0.1<br />
If this does not work, the IP stacks may have auto-assigned network addresses to themselves. You can look this up with 'ifconfig' on the Neo and with 'ipconfig' on Windows.<br />
<br />
<br />
* You should now be able to ssh/putty from Windows to your Neo. Enjoy!<br />
By setting up the Windows Bluetooth connection properly, it should also be possible to share the Internet Connection of the Windows box with the Neo.<br />
<br />
=== PPP Networking ===<br />
<br />
If you are unable to use the 'BNEP' method described above, you may be able to use [[PPP]] and a DUN (dialup-networking) emulation mode. On the Neo:<br />
<br />
* Edit the /etc/default/bluetooth file and set the following options:<br />
RFCOMM_ENABLE=true<br />
DUND_ENABLE=true<br />
DUND_OPTIONS=&quot;--listen --persist call dun&quot;<br />
<br />
* Create an /etc/ppp/peers/dun file with options like the following:<br />
115200<br />
192.168.2.202:192.168.2.200<br />
passive<br />
local<br />
noipdefault<br />
noauth<br />
nodefaultroute<br />
<br />
* Restart bluetooth (/etc/init.d/bluetooth stop ; /etc/init.d/bluetooth start)<br />
<br />
To connect from a MacOS 10.3 client:<br />
<br />
* Open &quot;Applications/Utilities/Bluetooth Serial Utility&quot;<br />
<br />
* Click on &quot;New&quot;<br />
<br />
* Choose a name, then click &quot;Choose Device&quot;<br />
<br />
* Locate your Neo, then select the &quot;LAN Access Point&quot; service. If your device is not found, or if this service does not show up, then you will need to troubleshoot and fix that before continuing. Bluetooth is designed for short-range communication, so make sure that the devices are physically close to each other. <br />
<br />
* Select &quot;Port type: RS-232&quot; and &quot;Show in Network Preferences&quot;. Click OK.<br />
<br />
* Open the Network Preferences page then &quot;Show: Network Port Configurations&quot;. Enable the new device that you defined in the previous step and drag it to the bottom of the device list (so that it will not interfere with your other network connections)<br />
<br />
* Choose &quot;Show: &lt;your-device-name&gt;&quot;, then click &quot;Modem&quot;<br />
<br />
* Select &quot;Null Modem 115200&quot; from the list of available devices. Uncheck &quot;Wait for dial tone&quot; and &quot;Enable error correction and compression in modem&quot;. Optionally check &quot;Show modem status in menu bar&quot;. <br />
<br />
* Click &quot;Connect&quot;. If everything worked, you will end up with a 'ppp0' device on your Mac with a local address of 192.168.2.200 and you will be able to access your Neo at 192.168.2.202.<br />
<br />
=== A2DP quickie ===<br />
<br />
It's now possible (if a little hackish) to stream mp3 to a bluetooth headset. It's a known problem that the playback rate changes (pitch varies). Timing issues are also likely the reason for gaps in playback.<br />
<br />
If the bluez packages are recent enough, you can use a shortcut. I'll document it here and leave the longer version below (the long version also demonstrates the API used by the GUI to manage headsets)<br />
<br />
Create /etc/asound.conf with your bluetooth headset's address filled in:<br />
<br />
pcm.!default {<br />
type bluetooth<br />
device &quot;xx:xx:xx:xx:xx:xx&quot;<br />
}<br />
<br />
then play a song<br />
<br />
madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay<br />
<br />
or for smoother results...<br />
<br />
madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:song.wav<br />
aplay song.wav<br />
<br />
=== A2DP ===<br />
<br />
If that doesn't work... all the more hackish... install required packages:<br />
<br />
echo &quot;src/gz python http://www.angstrom-distribution.org/unstable/feed/armv4t/python/&quot; &gt;&gt; /etc/ipkg/angstrom-python.conf <br />
echo &quot;src/gz base http://www.angstrom-distribution.org/unstable/feed/armv4t/base/&quot; &gt;&gt; /etc/ipkg/angstrom-base.conf<br />
ipkg update ; ipkg install python-core python-xml python-dbus bluez-utils bluez-utils-alsa<br />
<br />
Create /etc/asound.conf:<br />
<br />
pcm.!default {<br />
type bluetooth<br />
}<br />
ctl.!default {<br />
type bluetooth<br />
}<br />
pcm.bluetooth {<br />
type bluetooth<br />
}<br />
ctl.bluetooth {<br />
type bluetooth<br />
}<br />
<br />
Run the passkey agent (see above in this page)<br />
<br />
Fill in your bluetooth headset address below and execute the python script (with your headset turned on)<br />
<br />
#!/usr/bin/python<br />
import dbus<br />
bus = dbus.SystemBus()<br />
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')<br />
conn = manager.ActivateService('audio')<br />
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')<br />
path = audio.CreateDevice('00:0D:3C:44:33:22')<br />
audio.ChangeDefaultDevice(path)<br />
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')<br />
sink.Connect()<br />
<br />
FINALLY: play a song<br />
<br />
madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay<br />
<br />
=== Headset Audio ===<br />
<br />
[[Neo1973_Audio_Subsystem]] has detail about alsa settings and a proposal for audio scenario management.<br />
<br />
To try this out, follow the instructions in the a2dp section to install software and run the passkey agent.<br />
<br />
Remove or disable the stuff you put in asound.conf. When using a voice headset, the application uses the regular system audio device and it gets routed to bluetooth in the codec.<br />
<br />
Put the headset in pairing mode. Replace the bluetooth address below with your headset's and run the python script:<br />
<br />
#!/usr/bin/python<br />
import dbus<br />
bus = dbus.SystemBus()<br />
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')<br />
conn = manager.ActivateService('audio')<br />
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')<br />
path = audio.CreateHeadset('00:0B:2E:39:33:22')<br />
audio.ChangeDefaultHeadset(path)<br />
headset = dbus.Interface (bus.get_object(conn, path), 'org.bluez.audio.Headset')<br />
headset.Connect()<br />
headset.Play()<br />
<br />
Now place a call and try to route it to bluetooth (after it's in progress):<br />
<br />
alsactl -f /etc/gsmbluetooth.state restore<br />
<br />
You may also be able to listen to system audio given the right state file:<br />
<br />
alsactl -f /etc/systembluetooth.state restore<br />
madplay song.mp3<br />
<br />
=== Bluetooth networking with a Linux system - More secure way ===<br />
<br />
''Check this, probably needs some corrections''<br />
<br />
Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.<br />
<br />
On the laptop<br />
<br />
* check these options in /etc/bluetooth/hcid.conf<br />
security auto;<br />
passkey &quot;your pin&quot;;<br />
lm master;<br />
<br />
* Start bluetooth<br />
# /etc/init.d/bluetooth start<br />
<br />
* Start pand as server<br />
pand --listen --role NAP --encrypt<br />
<br />
* Add in /etc/network/interfaces (see [[USB_Networking]])<br />
auto bnep0<br />
iface bnep0 inet static<br />
address 192.168.1.1<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.1.0/24<br />
post-up echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
post-up iptables -P FORWARD ACCEPT<br />
<br />
On the Neo<br />
<br />
* Power on bluetooth (see above)<br />
<br />
* Scan for the laptop<br />
root@fic-gta01:~$ hcitool scan<br />
Scanning ...<br />
00:20:E0:5A:FE:C8 laptop<br />
<br />
* Set pin<br />
root@fic-gta01:~$ passkey-agent 'your pin' 00:20:E0:5A:FE:C8 &amp;<br />
<br />
* Connect to the laptop pand<br />
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8<br />
<br />
* Configure your IP address<br />
root@fic-gta01:~$ ifconfig bnep0 192.168.1.2<br />
root@fic-gta01:~$ route add default gateway 192.168.1.1<br />
<br />
* Enjoy<br />
<br />
<br />
== Further reading ==<br />
<br />
http://www.holtmann.org/papers/bluetooth/ols2006_slides.pdf<br />
http://wiki.bluez.org/wiki/Audio#org.bluez.Audio<br />
<br />
{{Languages|Manually_using_Bluetooth}}<br />
[[Category:Technical ]]<br />
[[Category:Software]]<br />
[[Category:Documentation]]<br />
[[Category:Bluetooth| ]]</div>AudriusAhttp://wiki.openmoko.org/wiki/GllinGllin2008-04-01T06:46:41Z<p>AudriusA: </p>
<hr />
<div>gllin is an userpsace driver for a hammerhead [[GPS]] chip. It was distributed on phase1 openmokos.<br />
<br />
Thanks to a tremendous amount of hard work by many people, we have ready<br />
a release of gllin, the GPS drives. Here is how you can get it:<br />
<br />
http://3rdparty.downloads.openmoko.org/gllin/<br />
<br />
Instructions, how to use the driver, are given at:<br />
<br />
http://lists.openmoko.org/pipermail/community/2007-November/011916.html. <br />
<br />
The similar instructions are described in more details at [[getting GPS console output with gllin]]. The downloaded .ipk package can be installed and works not just on OpenMoko but also on Qtopia.<br />
<br />
== /sys/ path issues with some kernel versions ==<br />
<br />
gllin expects to find the gps devices /sys/ interface in the path: <br />
'''/sys/bus/platform/devices/gta01-pm-gps.0/'''<br />
<br />
If your kernel does not create the path mentioned above but only i.e. <br />
'''/sys/bus/platform/devices/neo1973-pm-gps.0/'''<br />
you can try the following solution:<br />
<br />
As it is not possible to create symlinks in /sys/ or /proc/ and similar kernel virtual<br />
filesystems a different approach needs to be taken: bind-mounts.<br />
<br />
The old path .../gta01-pm-gps.0/ can be made avainable again to gllin by creating a bind mount with:<br />
<br />
&lt;pre&gt;<br />
echo &quot;/sys/bus/platform/devices/neo1973-pm-gps.0 /sys/bus/platform/devices/gta01-pm-gps.0 none bind 0 0&quot; &gt;&gt;/etc/fstab<br />
mount /sys/bus/platform/devices/neo1973-pm-gps.0<br />
&lt;/pre&gt;<br />
<br />
Other approaches using '''sed''' on gllin or some symlink approach were proposed but <br />
creating a simple bind mount seems to be the cleanest solution.<br />
<br />
--[[User:Spin|Spin]] 22:44, 26 March 2008 (CET)<br />
<br />
<br />
== gllin options ==<br />
<br />
The /home/root/gllin/gllin file installed by the new (legitimate!) .ipk package is really just a shell script. You can modify the options passed to gllin.real by editing that script. Here are the options:<br />
&lt;pre&gt;<br />
Usage:<br />
<br />
-help Help<br />
-board &lt;type&gt; Defines board type Ex: '-board matchbox'<br />
supported: matchbox, trident<br />
-com &lt;com port&gt; GPS com port; Ex: '-com com6'<br />
-baud &lt;baud rate&gt; Set baud rate; Ex: '-baud 115200'<br />
-rft &lt;RF type&gt; Set RF type; Ex: '-rft RF_LN22OUT'<br />
-freq &lt;freq plan&gt; | ? set frequency plan for GPS or show the list of all available plans<br />
Ex: '-freq FRQ_PLAN_OCXO_10000'<br />
Ex: '-freq ?' -- Show all available plans<br />
-g &lt;URL&gt; SUPL Server URL or IP address;<br />
Ex: '-g 216.15.9.46'<br />
-p &lt;port&gt; SUPL Server port number;<br />
Ex: '-p 9118'<br />
-udp &lt;port&gt; Local UDP port to send NMEA to.<br />
'-udp 6000' [default]<br />
-gsm_cell &lt;cell ID&gt; set GSM Cell ID information<br />
cell ID has the following format: '&lt;MCC&gt;.&lt;MNC&gt;.&lt;LAC&gt;.&lt;CI&gt;'<br />
Where:<br />
MCC - Mobile Country Code<br />
MNC - Mobile Network Code<br />
LAC - Location Area Code<br />
CI - Cell Identification<br />
Ex: '-gsm_cell 310.170.367.25732'<br />
-set_assisted_off disable SET assisted capability<br />
-set_based_off disable SET based capability<br />
-msisdn &lt;MSISDN&gt; set value for MSISDN (international phone number) as SET id<br />
Ex: '-msisdn 14081234567'<br />
-nai &lt;nai&gt; specify Network Access Identifier as SET id<br />
Ex: '-nai 12345@mywebsite.com'<br />
-periodic &lt;s&gt; make periodic request every s second (-1 to 64)<br />
-1 single shot: perform one fix, then quit<br />
0 native: perform fixes as fast as possible<br />
&lt;s&gt; timed: report a position every &lt;s&gt; seconds<br />
where &lt;s&gt; is 1 to 64<br />
-recover recover GLLIN after signaled exit<br />
-low [&lt;count&gt;] low level test. Default &lt;count&gt; is 1<br />
-low_debug Low level debug ON<br />
+low_debug Low level debug OFF<br />
-train &lt;count&gt; Send train data &lt;count&gt; times<br />
+pty | -pty Enable or disable NMEA output to pty &quot;/tmp/nmeaPTY&quot;<br />
Default is off [-pty]<br />
+np | -np Enable or disable NMEA output to named pipe &quot;/tmp/nmeaNP&quot;<br />
Default is on [-np]<br />
+nmea | -nmea Enable or disable NMEA output to log file<br />
Default is off [-nmea]<br />
+daemon | -daemon Become a daemon (or not)<br />
Default is -daemon<br />
-a2 | -a3 | -a0 Select a GTA01 board revision. Default is a3<br />
-batch &lt;st&gt; &lt;n&gt; &lt;fix&gt; perform batch test of &lt;n&gt; starts of type &lt;st&gt;<br />
&lt;st&gt; is hot, warm, cold, or SNR.<br />
Each start has &lt;fix&gt; fixes.<br />
-i start GLLIN command line<br />
+pnd optimize for PND<br />
-pnd look for low signal strength signals<br />
+sim using simulator so don't use almanac<br />
-sim not using simulator<br />
SNR manufacturing SNR test mode<br />
hot hot start [default]<br />
warm warm start<br />
cold cold start<br />
-v[n] Report GLLIN version string.<br />
n is 1234 to report selected versions.<br />
version 1.1.7<br />
&lt;/pre&gt;<br />
<br />
== Using gpsd with gllin ==<br />
<br />
ipkg install gpsd<br />
<br />
edit /etc/default/gpsd and set the GPS_DEV to /tmp/nmeaNP start gpsd before gllin.<br />
<br />
== Some notes: ==<br />
<br />
The listed defaults don't seem to be correct. By default it DOES generate NMEA data in log files. These log files are on your flash (/home/root/gllin/log/*) and are written to once every second. Ridiculous!<br />
<br />
To stop this, add the option &quot;-nmea&quot; to the second of the two gllin.real commands in the startup script.<br />
<br />
But note further that the startup script also spawns a command to 'cat' the output of the /tmp/nmeaNP named pipe to a gzipped file in /home/root. If you want this to stop, you can do one of two things:<br />
<br />
* cat to /dev/null instead of | gzip &gt;&gt; file<br />
<br />
* add &quot;-np&quot; to the second gllin.real command<br />
<br />
You can't just take the 'cat' command out of the script, because with the named pipe activated, gllin will QUIT if it doesn't see anybody taking the output from the pipe. To keep it going, either open that pipe or turn it off.<br />
<br />
You can use this [http://obri.sygroup.ch/gllin gllin initscript] to start and stop gllin.<br />
<br />
Another option:<br />
#!/bin/sh<br />
echo &quot;Starting gllin...&quot;<br />
<br />
killall cat<br />
killall gllin.real<br />
<br />
mknod /tmp/nmeaNP p<br />
cat /tmp/nmeaNP &gt; /dev/null &amp;<br />
cd /home/root/gllin<br />
lib/ld-linux.so.2 --library-path /home/root/gllin/lib:/home/root/gllin/usr/lib /home/root/gllin/gllin.real -low 5<br />
lib/ld-linux.so.2 --library-path /home/root/gllin/lib:/home/root/gllin/usr/lib /home/root/gllin/gllin.real -periodic 1 -nmea<br />
<br />
== More Initscripts ==<br />
<br />
The gllin package doesn't come with a very good set of initscripts, and gpsd is flexible enough to use gllin or some other source of GPS coordinates.<br />
<br />
For gpsd and gllin to run together well, upon boot, the following scripts have worked well for me:<br />
<br />
/etc/init.d/gpsd:<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# gpsd This shell script starts and stops gpsd.<br />
#<br />
# chkconfig: 345 90 40<br />
# description: Gpsd manages access to a serial- or USB-connected GPS<br />
# processname: gpsd<br />
<br />
# Source function library.<br />
#. /etc/rc.d/init.d/functions<br />
<br />
RETVAL=0<br />
prog=&quot;gpsd&quot;<br />
<br />
test -f /etc/default/${prog} &amp;&amp; . /etc/default/${prog}<br />
<br />
start() {<br />
# Start daemons.<br />
echo -n &quot;Starting ${prog}: &quot;<br />
# We don't use the daemon function here because of a known bug<br />
# in initlog -- it spuriously returns a nonzero status when <br />
# starting daemons that fork themselves. See<br />
# http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130629<br />
# for discussion. Fortunately:<br />
#<br />
# 1. gpsd startup can't fail, or at least not in the absence of<br />
# much larger resource-exhaustion problems that would be very obvious.<br />
#<br />
# 2. We don't need all the logging crud that daemon/initlog sets<br />
# up -- gpsd does its own syslog calls.<br />
#<br />
<br />
if [ -e &quot;${GPS_DEV}&quot; ]<br />
then<br />
${prog} -n ${GPSD_OPTS} ${GPS_DEV}<br />
RETVAL=$?<br />
echo &quot;success&quot;<br />
else<br />
# User needs to symlink ${GPS_DEV} to the right thing<br />
# Do it automatically if the name contains &quot;NP&quot;<br />
if echo ${GPS_DEV} | grep -q NP<br />
then<br />
mknod ${GPS_DEV} p<br />
${prog} -n ${GPSD_OPTS} ${GPS_DEV}<br />
RETVAL=$?<br />
echo &quot;success&quot;<br />
else<br />
RETVAL=$?<br />
echo &quot;No ${GPS_DEV} GPS device, aborting gpsd startup. Check /etc/default/${prog}&quot;<br />
fi<br />
fi<br />
[ $RETVAL -eq 0 ] &amp;&amp; touch /var/lock/subsys/gpsd<br />
return $RETVAL<br />
}<br />
<br />
stop() {<br />
# Stop daemons.<br />
echo -n &quot;Shutting down ${prog}: &quot;<br />
killall ${prog}<br />
RETVAL=$?<br />
echo<br />
if [ $RETVAL -eq 0 ]<br />
then<br />
test -e /var/lock/subsys/gpsd &amp;&amp; rm -f /var/lock/subsys/gpsd;<br />
fi<br />
return $RETVAL<br />
}<br />
<br />
# See how we were called.<br />
case &quot;$1&quot; in<br />
start)<br />
start<br />
;;<br />
stop)<br />
stop<br />
;;<br />
restart|reload)<br />
stop<br />
start<br />
RETVAL=$?<br />
;;<br />
condrestart)<br />
if [ -f /var/lock/subsys/gpsd ]; then<br />
stop<br />
start<br />
RETVAL=$?<br />
fi<br />
;;<br />
status)<br />
# status gpsd<br />
# RETVAL=$?<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop|restart|condrestart|status}&quot;<br />
exit 1<br />
esac<br />
<br />
exit $RETVAL<br />
&lt;/pre&gt;<br />
<br />
/etc/init.d/gllin:<br />
&lt;pre&gt;<br />
#!/bin/sh<br />
#<br />
# This shell script starts and stops gllin.<br />
#<br />
<br />
RETVAL=0<br />
prog=&quot;gllin&quot;<br />
GLLIN_PATH=/home/root/gllin<br />
<br />
test -f /etc/default/${prog} &amp;&amp; . /etc/default/${prog}<br />
<br />
start() {<br />
# Make fifo if it doesn't already exist<br />
if [ ! -p /tmp/nmeaNP ]<br />
then<br />
mknod /tmp/nmeaNP p<br />
fi<br />
<br />
# Check for gpsd ready (max 5 seconds)<br />
echo -n &quot;Waiting for gpsd . . . &quot;<br />
sleep 1<br />
if [ ! &quot;$(pidof gpsd)&quot; ]<br />
then<br />
sleep 4<br />
if [ ! &quot;$(pidof gpsd)&quot; ]<br />
then<br />
RETVAL=1<br />
echo &quot;failure.&quot;<br />
return $RETVAL<br />
fi<br />
fi<br />
<br />
# Start daemons.<br />
echo -n &quot;starting ${prog}: &quot;<br />
cd $GLLIN_PATH<br />
sleep 1<br />
if [ -e $GLLIN_PATH/${prog}.real ]<br />
then<br />
$GLLIN_PATH/lib/ld-linux.so.2 --library-path $GLLIN_PATH/lib $GLLIN_PATH/${prog}.real -low 5 &gt; /dev/null<br />
$GLLIN_PATH/lib/ld-linux.so.2 --library-path $GLLIN_PATH/lib $GLLIN_PATH/${prog}.real -periodic 1 +daemon<br />
else<br />
$GLLIN_PATH/lib/ld-linux.so.2 --library-path $GLLIN_PATH/lib $GLLIN_PATH/${prog} -low 5 &gt; /dev/null<br />
$GLLIN_PATH/lib/ld-linux.so.2 --library-path $GLLIN_PATH/lib $GLLIN_PATH/${prog} -periodic 1 +daemon<br />
fi<br />
echo &quot;success.&quot;<br />
RETVAL=$?<br />
echo<br />
return $RETVAL<br />
}<br />
<br />
stop() {<br />
# Stop daemons.<br />
echo -n &quot;Shutting down ${prog}: &quot;<br />
pkill ld-linux.so.2 <br />
RETVAL=$?<br />
echo &quot;success.&quot;<br />
return $RETVAL<br />
}<br />
<br />
# See how we were called.<br />
case &quot;$1&quot; in<br />
start)<br />
start<br />
;;<br />
stop)<br />
stop<br />
;;<br />
restart|reload)<br />
stop<br />
start<br />
RETVAL=$?<br />
;;<br />
status)<br />
# RETVAL=$?<br />
;;<br />
*)<br />
echo &quot;Usage: $0 {start|stop|restart|condrestart|status}&quot;<br />
exit 1<br />
esac<br />
<br />
exit $RETVAL<br />
&lt;/pre&gt;<br />
<br />
These scripts allow you (or init, if you have them numbered in rcX.d appropriately) to start gpsd *before* gllin. This way, gpsd starts listening on /tmp/nmeaNP immediately, and gllin doesn't need to send output to /dev/null in order to stay alive.<br />
<br />
This version of the gpsd script will create the named pipe (if the device name includes &quot;NP&quot; in the filename) if it doesn't exist.</div>AudriusAhttp://wiki.openmoko.org/wiki/FAQFAQ2008-02-16T21:29:32Z<p>AudriusA: /* Q: I'm a ____ expert, can I join/help OpenMoko? */ +http://projects.openmoko.org/</p>
<hr />
<div>Frequently Asked Questions... with answers included!<br />
<br />
==Introduction== <br />
<br />
=== Q: What is OpenMoko? What is the Neo 1973? What is the Neo Freerunner? ===<br />
A: [[OpenMoko]] is a software platform and the world's first completely open mobile phone software stack. It is based on Linux and allows users and enthusiasts great freedom to customise their phone.<br />
* The [[FIC]] [[Neo1973]] is the first fully supported OpenMoko phone. <br />
* The FIC [[Neo FreeRunner]] is the second Openmoko phone although it is not released as of yet (Feb08)<br />
<br />
=== Q: I'm a ____ expert, can I join/help OpenMoko? ===<br />
<br />
We would love to hear from you.<br />
<br />
* If you are interested in joining OpenMoko as a software developer, please visit http://www.openmoko.com/contact-index.html and send us an e-mail. <br />
* Or register some your project at http://projects.openmoko.org/<br />
* Or simply join the Openmoko Community - more info here http://wiki.openmoko.org/wiki/OpenMoko:Community_Portal<br />
<br />
=== Q: When and where can I buy a [[Neo1973]]? ===<br />
<br />
A: The OpenMoko Neo 1973 is now sold out (11 Feb 2008) as you can see at the [https://direct.openmoko.com/ web shop]. You must wait til the Neo FreeRunner is released...<br />
<br />
=== Q: When can I buy a [[Neo FreeRunner]]? ===<br />
<br />
A: Spring 2008, maybe March. Watch the [[OpenMoko:Community Portal|Community Portal]] for further updates<br />
<br />
=== Q: What are the new features that the Neo Freerunner will have? ===<br />
<br />
It will retain many good features from the Neo1973 such as the very high resolution touch screen and integrated GPS unit.<br />
<br />
It adds the following features<br />
* WiFi - 802.11 b/g - for high speed internet<br />
* Faster processor operating at 400Mhz (up from 266Mhz) - for faster operation<br />
* * SMedia Glamo3362 Graphics Accelerator - for improved graphical performance<br />
* 2 3D Accelerometers - the phone applications will know which way the phone is oriented<br />
* 256MB Flash - larger memory to run bigger applications<br />
* LED's illuminating the 2 external buttons on the phone<br />
<br />
<br />
<br />
=== Q: How much? === <br />
<br />
A: Neo1973 (Internal code name GTA01B_v04): $300 for Neo Base, $399 for Neo Advanced. Available now. See [[Neo1973]] for what is included.<br />
<br />
A: Freerunner (Internal code name GTA02): $450 for Neo Base, $600 for Neo Advanced. See [[Neo1973]] for list of hardware.<br />
<br />
=== Q: What can I do with the Neo1973? ===<br />
<br />
A: For long answer see [[Developer preview]]<br />
<br />
A: The Neo1973 is a Phase 1 phone and aimed at software developers only. It is not suitable for end users, it will have basic functionality as a touchscreen phone. Little else will work, software development will continue till mass market release. Here are one developer's thoughts about the possibilities [http://blog.syntaxpolice.org/isaac/technology/linuxPhones.html]<br />
<br />
Those interested should:<br />
<br />
* Know that there will be a device with faster cpu, gsm system etc in the spring of 2008.<br />
* Have fun hacking devices.<br />
* Be able to find their way through prototype software and hardware without much documentation.<br />
* Share the dream of a device powered by free software.<br />
* Not expect a consumer-level device.<br />
* Come up with new ideas for exploring the age of mobile computing.<br />
* Have $300.<br />
<br />
Ideally they also:<br />
<br />
* Can spot bugs and submit patches.<br />
* Love to cooperate with a community improving the software.<br />
<br />
=== Q: What will I be able to do with the Neo Freerunner? ===<br />
<br />
A: The Neo Freerunner is the first phase 2 (mass release) phone from the Openmoko project and is designed for everyday use by end users and continued software development and improvements by the Openmoko team and the Openmoko community.<br />
<br />
A: The question is almost what can you NOT do with this phone - eventually there will be a huge range of free software applications allowing both end users and developers to get much more out of this phone than a standard &quot;locked&quot; mobile phone using features like the integrated GPS, bluetooth, wifi and accelerometers.<br />
<br />
=== Q: Do I need the Neo 1973 Advanced (or in due course the Neo Freerunner Advanced)? === <br />
<br />
End users or power users should buy the &quot;base&quot; unit.<br />
<br />
Software developers may wish to buy the &quot;advanced&quot; model.<br />
<br />
With Neo 1973 Base or Neo Freerunner Base you can do:<br />
* Kernel development.<br />
* Application development.<br />
* Updating u-boot (equivalent to PC BIOS) using a tested image.<br />
* Replace a non-booting kernel and/or rootfs using [[Dfu-util]].<br />
<br />
With Neo 1973 Advanced or Neo Freerunner Advanced you can additionally do:<br />
* U-boot development.<br />
* Use the kernel console.<br />
* Unbrick your device if you flash a wrong or non-working u-boot image.<br />
<br />
=== Q: I have a shipping related question === <br />
<br />
For Neo1973<br />
* See [[SH1_FAQ|Shipment 1 FAQ]].<br />
<br />
For FreeRunner<br />
* Shipping and distribution arrangements will be announced later<br />
<br />
=== Q: What does the [[Neo1973]] look like? ===<br />
<br />
* See the original launch [[Artwork|artwork]]<br />
* Collected images from google [[http://images.google.co.uk/images?q=neo+1973&amp;ie=UTF-8&amp;oe=utf-8&amp;rls=com.ubuntu:en-GB:official&amp;client=firefox-a&amp;um=1&amp;sa=N&amp;tab=wi]]<br />
<br />
=== Q: What does the [[Neo FreeRunner]] look like? ===<br />
<br />
* It uses the same case and dimensions as the Neo1973 (as announced at CES Jan08)<br />
<br />
=== Q: What else do I need to know? ===<br />
<br />
* Both Neo 1973 and Neo Freerunner are tri-band GSM phones. <br />
* The Neo Freerunner is expected to be offered in an 850/1800/1900MHz version for North America and an 900/1800/1900MHz version for the rest of the world. <br />
* The Neo1973 is an 900/1800/1900Mhz version only and may not work well in some rural parts of North America.<br />
<br />
=== Q: What are the benefits of an &quot;open&quot; phone over a &quot;closed&quot; phone ===<br />
<br />
A: In a conventional closed phone, the handset maker and the mobile network operator work together to provide a service to you that best suits their business model. The capabilities of a modern smartphone equipped with GPS, Wifi and bluetooth are amazing and the result is that many features are &quot;locked down&quot; because they do not suit the network operator. Up until now it has been difficult to buy a phone on which you have freedom to install sofware which is not controlled by the network operators - [[Openmoko]] changes that!<br />
<br />
A: A list of examples of &quot;closed&quot; behaviour has been started here - [[Problems of typical &quot;closed&quot; phones]]<br />
<br />
==Software==<br />
<br />
<br />
=== Q: Can the software do/connect to/... ===<br />
A: At the moment, the answer is in almost all cases no. The phone is at the moment a small linux box with a touchscreen, a working dialer and some prototype apps. <br />
Most do not function in any way that would be suitable for users.<br />
If you want to add a feature or application request, then look over the existing applications and either add one, or add a feature request to the applications page.<br />
<br />
===What software is on the phone?===<br />
At the moment, almost no 'end-user' applications are present and working in a usable state.<br />
It is possible to make and receive calls in some software revisions, this frequently breaks though.<br />
<br />
====What software can be installed on the phone?====<br />
<br />
=== Q: Is there description and list of OpenMoko software? ===<br />
<br />
A: See [[OpenMoko]] and [[OpenMokoFramework]]<br />
<br />
=== Q: Is it completely free software/open source? ===<br />
<br />
A: User space [[Gpsd]] will use binary plugin (to be released soon) for [[:Category:Neo1973 Hardware#AGPS|Hammerhead AGPS]] and [[:Category:Neo1973 Hardware#GSM.2FGPRS|GSM modem]] is separate subsystem connected to S3C2410 UART1. Otherwise it is completely free software. See [[MokoMakefile]] and [[Development resources]].<br />
<br />
=== Q: How do I install and manage software on OpenMoko? ===<br />
<br />
A: ipkg: http://handhelds.org/moin/moin.cgi/Ipkg<br />
<br />
=== Q: How can I compile programs for the Neo1973? ===<br />
<br />
A: See [[Toolchain]].<br />
<br />
=== Q: Is there an emulator available for OpenMoko? ===<br />
<br />
For a lot of testing and development work, you don't actually need emulation as you can run OpenMoko on a normal PC too. The emulators also aren't 100% accurate. That being said, there are several emulation options as described in the following.<br />
<br />
====QEMU====<br />
QEMU can now emulate the Neo1973 device. The [[MokoMakefile]] has support for automatically building, flashing, and running [[OpenMoko under QEMU|the Neo1973 emulator]].<br />
<br />
“make qemu” will build qemu-neo1973, download the latest official openmoko images, flash the images into the virtual NAND flash, and run the emulator.<br />
<br />
====Xoo====<br />
Another is [http://projects.o-hand.com/xoo Xoo]. Koen says: &quot;Xoo should be enough for most apps people will develop, since most don't need access to the gsm uart directly. If you're hardcore you could use qemu + xoo, but that still doesn't emulate all the hardware quirks (e.g. unaligned access)&quot;.<br />
<br />
Update: Stefan Schmidt has resized the [[Neo1973]] Mock-up and written a small description for xoo. In his words:<br />
<br />
It's not really useable at all, as you need a really high screen resolution to fit the whole picture on your screen. And of course the dpi are wrong. Even no buttons because I can't remember where they are at the case.<br />
<br />
http://www.datenfreihafen.org/~stefan/OpenMoko/neo1973-xoo-device.tar.bz2<br />
<br />
Start with 'xoo --device /path/to/neo1973.xml'<br />
<br />
Some more details [[Getting_Openmoko_working_on_host_with_Xoo|here]].<br />
<br />
====Xephyr====<br />
Or use Xephyr directly with locally compiled programs (e.g. matchbox svn + openmoko):<br />
Xephyr -screen 480x640 -nolisten tcp -ac :1 &amp;<br />
export DISPLAY=:1<br />
export LD_LIBRARY_PATH=/usr/local/lib<br />
matchbox-window-manager -display $DISPLAY -use_titlebar no \<br />
-use_super_modal yes -use_lowlight yes -use_dialog_mode static \<br />
-use_cursor yes &amp;<br />
matchbox-panel --geometry=480x44 --end-applets=clock &amp;<br />
openmoko-footer &amp;<br />
openmoko-taskmanager &amp;<br />
<br />
=== Q: Where can I find some type of tutorial for a 'Hello, world' on OpenMoko? ===<br />
<br />
A: This should get you started:<br />
http://www.gtk.org/tutorial/<br />
<br />
=== Q: Can PalmOS apps applications be ported to run on OpenMoko? ===<br />
<br />
A: Making legacy apps written for the &quot;Garnet&quot; OS (née &quot;Palm OS&quot;) run on Linux<br />
is decidedly non-trivial.<br />
<br />
PalmOS apps are in general very hard to simply 'port'. Particularly well-designed programs may make it possible.<br />
<br />
The ACCESS Linux Platform will include Garnet on Host (GHost), a PalmOS emulator that will support M6800 (68k) and ARM PalmOS applications. This part (GarnetVM and the .prc loader) will however be closed-source and likely under a restrictive license (fact confirmed by ACCESS Co. employees), making it rather unusable. In addition GarnetVM depends on Hiker and other packages.<br />
<br />
It is possible that POSE, an emulator that simulates a Palm device on a Linux host could be used to allow 68k based applications to run. This emulator has been around a long time; one expects that it will also run on OpenMoko, but this has to be considered a short-term bandaid rather than a long-term solution.<br />
<br />
The soon-to-be-released [http://www.palm.com/foleo/ Palm Foleo], which runs a Linux port developed by Palm Inc. independently of ALP, contains a PalmOS compatibility environment that runs PalmOS apps, supposedly all of them and supposedly seamlessly. Little is known about how it works but if it's not too kludgy it should run unmodified on any ARM linux. It is not known what license it will be distributed under.<br />
<br />
Hopefully emulation will be necessary only for M68000 code (pre-PalmOS 5) while native ARM programs can run natively under Linux, provided a proper set of PalmOS libraries and a .prc executable loader.<br />
<br />
=== Q: Does it have Java? ===<br />
A: It will have eventually, if you help us to get it working. Some good places to keep track of would be [http://projects.openmoko.org/projects/java-pkg/ projects.openmoko.org] and [https://phoneme.dev.java.net/ PhoneME].<br />
<br />
Project [[https://wiki.evolvis.org/jalimo/index.php/Jalimo Jalimo]] is a project aiming to provide a Java stack on mobile devices. This project supports OpenMoko.<br />
<br />
=== Q: What are the relevant X11 details? ===<br />
<br />
A: See [http://lists.openmoko.org/pipermail/community/2007-January/001353.html xdpyinfo output].<br />
<br />
=== Q: Does OpenMoko run on any other hardware? ===<br />
<br />
You can run it on your [[How_to_run_OpenMoko_Apps_on_PC|PC]]. There is work going on with [http://www.datenfreihafen.org/~stefan/weblog//archives/2007/02/#e2007-02-18T15_27_07.txt OpenEZX and HTC]. It's running on [http://dominion.kabel.utwente.nl/koen/cms/openmoko-running-on-an-ipaq iPaq hx4700], on a [http://hackndev.com/node/701 Palm TX] and on [http://blog.mikeasoft.com/2007/07/01/openmoko-on-a-treo-650/ PalmOne's Treo 650].<br />
<br />
=== Q: What are the requirements to the hardware to run OpenMoko? (Would it run on the IXI ogo?) ===<br />
<br />
=== Q: Why do you not build on top of the Maemo platform instead? ===<br />
<br />
While I can't speak for the OpenMoko team, it's worth noting that maemo is fixed resolution only. That will, I've heard, change in the future, but it hasn't yet. Maemo's current layout is also optimized for wide screens, not tall narrow ones. Most third party maemo applications that are out there will need to be modified to work at different sizes. Finally, a number of the software components of the Nokia 770 and N800 are not open source. --gopi<br />
<br />
To add up on that, according to Nokia, Maemo is designed to bring the &quot;Desktop&quot; experience to an Internet Tablet. A lot of Desktop paradigms just won't work on a phone. However, we really share a lot of the base-technology (gtk, dbus, eds, gconf, to name a few) with Maemo, so we are definitely not a reinvent-the-wheel team.<br />
<br />
=== Q: Will it be possible to use popular VoIP applications such as Skype on the OpenMoko platform? ===<br />
<br />
A: Perhaps. Hardware issues mean that it won't work well on the Neo1973. (the typical latency of GPRS is far too high). Also, Skype is a closed source application, which does not provide binaries that would be suitable to run on OpenMoko. Skype's vendor could of course choose to provide binaries for OpenMoko phones. However, many telephone providers' terms of service agreements preclude running VoIP over their baseline GSM service.<br />
<br />
=== Q: Same question for Instant Messaging applications such as MSN Messenger? ===<br />
<br />
A: Very probably. MSN is closed source and will only run where Microsoft wants you to run it. But there are many Open Source IM clients, many of which have a plugin architecture and so support the use of more than one IM protocol, even simultaneously. One example is [http://www.pidgin.im Pidgin, formerly called GAIM]. GPRS does induce a certain amount of latency but that should not be a problem for simple, text-oriented chat between parties. And the GTA02's WiFi will make it even better.<br />
<br />
==Neo1973 Hardware== <br />
<br />
=== Q: Is there description of [[:Category:Neo1973 Hardware | Neo1973 Hardware]] ? ===<br />
<br />
A: See [[:Category:Neo1973 Hardware | Neo1973 Hardware]] and [[Disassembling Neo1973]]<br />
<br />
=== Q: What are the dimensions? ===<br />
<br />
A: 120.7 x 62 x 18.5 mm, It would fit entirely in a coke can. (4.75 * 2.4 * 0.72 &quot;)<br />
<br />
=== Q: How heavy is it? ===<br />
<br />
A: 185g, (6.5 ounces).<br />
<br />
=== Q: Does it have a camera? ===<br />
<br />
A: No, see [[:Category:Neo1973 Hardware | Neo1973]] for details on what it does include (and [[Wish List - Hardware]] for what some want in the future.) See also [[FAQ#USB]].<br />
<br />
=== Q: Does it have Wifi? ===<br />
<br />
A: The currently available [[Neo1973]] does not have WiFi. There was no suitable Wifi device available when it was designed. The next version will have WiFi. See also [[FAQ#USB]].<br />
<br />
=== Q: Does it have bluetooth? ===<br />
<br />
A: Yes! Bluetooth 2.0.<br />
<br />
=== Q: Does it come with a stylus? ===<br />
<br />
A: Yes, but there's no holder for it on the phone.<br />
<br />
<br />
=== Q: Where are the buttons? ===<br />
<br />
[[Neo1973 Power Button|The power button]] is a small circular button, just next to the USB connector. <br />
[[Neo1973 AUX Button|The Auxiliary button]] is a rectangular button on the top left of the edge of the phone. (on black phones it looks just like an IRDA port).<br />
<br />
=== Q: How do I input text? ===<br />
<br />
A: Use provided keyboard app.<br />
<br />
A: Use Bluetooth keyboard.<br />
<br />
A: For more methods and ideas see [[Wishlist:Text_Input]].<br />
<br />
=== Q: Can I record calls and/or play audio files in calls? ===<br />
<br />
A: Yes, audio path from GSM to/from mic and speakers is completely controllable by user. For example recording calls (both sides) and implementing an [[Answering Machine]] is possible. Also using text-&gt;speech should be possible or modifying outgoing voice. Currently there is no software bundled in phone to do this.<br />
There are only 2 A/D inputs and three D/A outputs (one dedicated to the earpiece). This means that stereo audio playback cannot happen at the same time as the [[Answering Machine]] functionality, amongst other things. See the audio page. [[Neo1973_Audio_Subsystem|Neo1973 Audio Subsystem]]<br />
<br />
=== Q: What is the battery life? ===<br />
<br />
A: There has been no word on this so far, but see [[Neo1973 Power Management#Approximate_power_draw_of_various_subsystems|these estimates]] for a rough idea. More information about the battery [[Neo1973 Battery|here]].<br />
<br />
=== USB ===<br />
<br />
==== Q: What can I do with the USB port on the Neo1973? ====<br />
A: Charge the phone, communicate with it over USB-serial, or USB-networking.<br />
<br />
A: Plug external devices, such as wifi, cameras, or mass-storage devices in. The &quot;Mass Market&quot; version of the phone will have wifi integrated.<br />
<br />
==== Q: What can't I do with the USB? ====<br />
<br />
The only limitation on current hardware seems to be no usb 2.0 support, which means slower communication with 2.0 devices.<br />
<br />
==== Q: Why is only USB 1.1 provided? ====<br />
<br />
A: The processor has USB 1.1 built in. One with USB2 built in would have been more expensive.<br />
<br />
==== Q: Can the Neo charge and use devices on a USB hub at the same time? ====<br />
<br />
A: <br />
*When the Neo is connected to a device port on a USB hub, it will start charging. If the hub is a powered hub, then it will charge fast (3h), otherwise around 12h.<br />
<br />
*If you plug the Neo into the host port of a USB hub you can use devices on that hub but the Neo will not charge. (Some/many USB hubs will not accept an unpowered host as valid, hence the need for the below cable.)<br />
*This is because the host socket on USB hubs is not powered.<br />
<br />
FIC product development is looking into providing something that<br />
conveniently solves this problem.<br />
<br />
The USB port on the Neo is not a properly compliant USB host port, all USB host ports must provide 5V - though powered devices or hubs may not draw any current from this, they may refuse to work. (The Belkin Tetrahub is an example of a hub that will not work.)<br />
<br />
One solution is a three headed cable.<br />
<br />
One end plugs into the Neo. One end plugs into a device port of a powered hub, or the Neo charger. One end plugs into the host port of a hub.<br />
<br />
The Charger/USB device plug only has +5V and 0V connected in the simple cable, which are connected to the other ends.<br />
<br />
For a more complex cable, when the host socket is not plugged in, the cable acts as a simple USB cable.<br />
<br />
==== Q: What are the details of the USB port on the [[Neo1973]]? How does it compare to USB On-The-Go? ====<br />
<br />
A: The [[Neo1973]] will have mini-USB-B, and will be able to function as either a host or a device. It will NOT be USB On-The-Go. OTG is a complex specification, and it comprises way more than just<br />
a AB socket, but also electrical and software components which cannot be provide by the S3C2410.<br />
<br />
You will need a special Mini-B to regular-B cable (note that this won't actually comply with the USB standard: a compliant cable has to have an A or Mini-A plug on one end, and B or Mini-B on the other).<br />
<br />
=== Q: Are there any LEDs on the Neo 1973? ===<br />
<br />
A: The [[Neo1973]] P1/P2 will have no LEDs besides the screen backlight.<br />
<br />
=== Q: Will a JTAG port be made available? ===<br />
<br />
A: Included with purchase of The &quot;Hacker's Lunchbox&quot; (Advanced version).<br />
<br />
There are [[Neo1973_Hardware#Changes_from_GTA01Bv3|exposed I2C, SPI and debug board connectors]] inside case in all versions and [[Debug Board|Debug Board v2]] (JTAG and serial console) in Advanced version. [[Connecting Neo1973 with Debug Board v2]] explains how to connect it to the phone.<br />
<br />
=== Q: Will the JTAG interface that comes with GTA01 be compatible with GTA02? ===<br />
<br />
A: Yes<br />
<br />
=== Q: What can we expect in future versions? ===<br />
<br />
A: A faster CPU, faster GSM (EDGE?) perhaps even powered USB port, USB2, wifi, and camera. No details have been released yet. More details of hardware upgrades should be available sometime in May. There will also be 5 more OpenMoko devices - some not phones in the traditional sense - announced by FIC in September.<br />
<br />
==Networking/Connectivity==<br />
<br />
=== Q: What kind of connectivity? ===<br />
<br />
A: Tri-band GSM (commonly known as &quot;European tri-band&quot;, 900/1800/1900 MHz), GPRS Class12/CS4 2.5G (Not EDGE), Bluetooth 2.0 EDR, USB in all versions. WiFi: Atheros AR6K in [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]]. (No 3G in year 2007 models)<br />
<br />
=== Q: Can I bridge to an Ethernet (wired or unwired) network via a suitable Bluetooth enabled router? ===<br />
<br />
A: Yes - see [http://gentoo-wiki.com/HOWTO_Configure_a_bluetooth_network_access_point this howto for how to configure a linux computer to act as such a router] and [[Bluetooth Support]].<br />
<br />
=== Q: What providers provide the GSM required for Neo1973? ===<br />
<br />
A: See [[Neo1973 compatible cellphone providers]]<br />
<br />
=== Q: Will OpenMoko &quot;Just Work&quot; with Mac OS X? ===<br />
<br />
A: There has been some discussion of this on the mailing list. There is motivation, and there are interested developers. <br />
Not being a Mac OS X user, I don't know enough<br />
to summarize the discussion to answer this question. Can someone please fill in?<br />
<br />
A: For IP over USB cable connectivity, it is planned to improve/adapt the AJZaurusUSB driver, allowing ssh into the OpenMoko.<br />
<br />
A: It is expected that (Bluetooth/UB) SyncML based interoperation for<br />
contacts and events can easily be achieved by a patch<br />
to the Apple iSync configuration tables.<br />
<br />
A: There is an open source implementation of Cocoa (GNUstep) that aims to run MacOS X compatible applications (sort of<br />
PPC/x86/ARM universal binaries) on OpenMoko devices: mySTEP.<br />
<br />
==Misc==<br />
<br />
=== Q: On the lists on lists.openmoko.org, should replies be added above or below the original text? ===<br />
<br />
A: Please reply UNDER post.<br />
<br />
=== Q: How can I find out if a question or topic has already been discussed on the mailing lists? ===<br />
<br />
A: By searching the mailing list archives. For example, using Google searches:<br />
<br />
site:openmoko.org text<br />
<br />
For example, to search for accelerometer:<br />
<br />
site:openmoko.org accelerometer<br />
<br />
If you only want to read the &quot;official&quot; mails from FIC people or from OpenMoko people:<br />
<br />
site:openmoko.org text &quot;at fic.com.tw&quot;<br />
site:openmoko.org text &quot;at openmoko.org&quot;<br />
<br />
For example to search for &quot;release date&quot; from FIC people:<br />
<br />
site:openmoko.org &quot;release date&quot; &quot;at fic.com.tw&quot;<br />
<br />
Alternatively you can use the [http://www.google.com/coop/cse?cx=018430699993342716089%3Aszsaurhronw custom OpenMoko search engine] that is using [http://www.google.com/coop/ Google Co-op].<br />
<br />
=== Q: how many dead pixels may the LCM have before calling it defect? ===<br />
<br />
A: the answer for the display used in GTA01 and GTA02 is '2'<br />
<br />
=== Q: Can I has some money for a Neo1973? ===<br />
<br />
A: No.<br />
<br />
{{Languages|FAQ}}<br />
<br />
[[Category:Information]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Neo_1973_vs_Neo_FreeRunnerNeo 1973 vs Neo FreeRunner2008-02-16T11:10:05Z<p>AudriusA: Sold out</p>
<hr />
<div>== Comparison between the Neo 1973 (GTA01Bv4) and Neo Freerunner ([[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]]) hardware revisions ==<br />
<br />
<br />
{| border=&quot;1&quot;<br />
!Feature<br />
!<br />
!<br />
|-<br />
|FIC Internal Codename<br />
|GTA01Bv4<br />
|GTA02<br />
|-<br />
|Public or Commercial Name<br />
|Neo 1973<br />
|Neo Freerunner<br />
|-<br />
|Sale<br />
|Sold out<br />
|Not ready yet. See http://wiki.openmoko.org/wiki/Community_Updates<br />
|-<br />
|Dimensions&lt;br /&gt;(no differences) <br />
|120.7 x 62 x 18.5 mm<br />
|120.7 x 62 x 18.5 mm<br />
|-<br />
|Weight<br />
|184 g<br />
|184 g (unconfirmed)<br />
|-<br />
|Screen&lt;br /&gt;(no differences)<br />
|2.8&quot; 480x640 at 285 ppi, <br />
|2.8&quot; 480x640 at 285 ppi,<br />
|-<br />
|[[Neo1973_Hardware#microSD-Card|Storage]]<br />
|64 MB integrated flash memory (expandable with [http://lists.openmoko.org/pipermail/community/2007-February/003156.html any size microSD or MicroSDHC memory cards])<br />
| [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html 256 MB] integrated flash memory.<br />
Expandable with [http://www.techtree.com/India/News/Samsung_Readies_8GB_microSD_Card/551-81172-581.html any size microSD or microSDHC memory cards]<br />
|-<br />
|[[Neo1973_Hardware#Processor|CPU]]<br />
|Samsung s3c2410 SoC @ 266 MHz ([http://lists.openmoko.org/pipermail/announce/2007-January/000000.html Source])<br />
|[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&amp;partnum=SC32442&amp;&amp;ppmi= Samsung 2442] SoC @ 400 MHz <br />
|-<br />
|Graphics Accelerator<br />
|<br />
|[http://www.smediatech.com/product3362.htm SMedia 3362 2D/3D Graphics Accelerator] [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html lists.openmoko.org announcement]<br />
|-<br />
|[[Neo1973_Hardware#RAM|RAM]]<br />
|128 MB<br />
|128 MB<br />
|-<br />
|Wireless<br />
|Tri-band GSM 800/1800/1900, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (Not EDGE), Bluetooth 2.0 EDR<br />
|Tri-band GSM 800 or 850/1800/1900, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (Not EDGE), Bluetooth 2.0 EDR; WiFi: [http://lists.openmoko.org/pipermail/announce/2007-April/000012.html Atheros AR6K] (See also [[AR6K]]) (802.11 b/g)<br />
|-<br />
|Embedded devices<br />
|Assisted GPS, 2 buttons<br />
|Assisted GPS, 2 backlit buttons; 2x3D [[Accelerometer]]s<br />
|-<br />
|GPS Hardware<br />
|Global Locate (now Broadcom) Hammerhead<br />
|u-blox/Atmel ATR0635 [http://lists.openmoko.org/pipermail/community/2007-October/011013.html]<br />
|-<br />
|Sound<br />
|Built-in stereo speakers, stereo handset<br />
|Built-in mono speaker, stereo jack for output to headset/earphones<br />
|-<br />
|WiFi<br />
|no<br />
|yes<br />
|-<br />
|Accelerometer<br />
|no<br />
|yes<br />
|-<br />
|Software<br />
|Extremely buggy. Most software needs to be added or made to work.<br />
|Basic PDA included. Software can be created by normal users.<br />
|-<br />
|Battery<br />
|Replaceable [[Neo1973_Battery|1200mAh battery]] charged via USB 1.1<br />
|Replaceable [[Neo1973_Battery|1200mAh battery]] charged via USB 1.1, or wall charger supplying 1000mA[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=956]. Also has a coulomb counter for accurate charge reading[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=957]<br />
|-<br />
|USB Host Support<br />
|Yes, but external +5V is required<br />
|Yes, powered port [http://lists.openmoko.org/pipermail/neo1973-hardware/2007-October/000280.html]<br />
|-<br />
|Ready for use<br />
|Not really. [[Developer_preview|What to expect from the Developer preview GTA01]].<br />
|Yes, when released(!)<br />
|-<br />
|Price &lt;br /&gt; (not including shipping costs and applicable taxes for your country)<br />
|USD 300 (base model), USD 399 including additional development hardware. (All units are shipped from the U.S.)<br />
|USD 450 (base model), USD 600 including additional development hardware.<br />
|-<br />
|}<br />
<br />
{{Languages|Neo1973: GTA01Bv4 versus GTA02 comparison}}<br />
<br />
[[Category:Neo1973 Phase 1 related]]<br />
[[Category:Neo1973 Phase 2 related]]<br />
[[Category:Information]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Neo_FreeRunnerNeo FreeRunner2008-02-16T11:07:52Z<p>AudriusA: The name of the operating system should be from the capital letter</p>
<hr />
<div>The Neo FreeRunner (internal codename GTA02) is the second phone designed to run Openmoko software and is the direct descendant of the earlier [[FIC]] [[Neo1973]]. Hardware specs are [[Neo FreeRunner GTA02 Hardware|here]].<br />
<br />
=== Finding out status before FreeRunner is released ===<br />
<br />
To be emailed when it is released sign up to the announce mail list here http://lists.openmoko.org/mailman/listinfo/announce. For frequently asked questions please check [[FAQ]]. Approximately, twice a month an Openmoko team member writes an update to the project here [[Community Updates]].<br />
<br />
No official launch date will be given until the phone is ready.<br />
<br />
=== Intended use and users ===<br />
<br />
The Neo FreeRunner is a Linux based touch screen smart phone aimed at general consumer use as well as Linux desktop users and Linux software developers.<br />
<br />
General phone users will appreciate the high spec and performance of the phone and the wide range of free and custom software packages that you are free to install to make the maximum use of the hardware for your particular needs. Note that software tweaks and improvements will continue after launch as both the Openmoko team developers and the wider linux community work together.<br />
<br />
Linux users and software developers will appreciate the total freedom they have to use and design software for the FreeRunner<br />
<br />
=== What are the specs ===<br />
<br />
The specs share some features with the previous [[Neo1973]] such as<br />
<br />
* A very high resolution touch screen (1.7&quot; x 2.27&quot; - 43mm x 58mm) 480x640 pixels<br />
* 128MB SDRAM memory to allow operation of many applications at once<br />
* Internal GPS module for map and tracking programs<br />
* Bluetooth for local data exchange<br />
* Physical appearance will be the same as the Neo1973. See openmoko.com for more.<br />
<br />
but will gain the additional features of<br />
<br />
* 802.11 b/g WiFi for fast web browsing and data transfer<br />
* A faster 400Mhz processor (up from 266MHz)<br />
* A hardware Graphics Accelerator chip allowing fast graphics including video playback<br />
* 2 accelerometers so that the phone can know its orientation for example switching to landscape mode automatically<br />
* 2 LEDs illuminating the two buttons on the rim of the case<br />
* Tri-band GSM and GPRS for North America (850/1800/1900 Mhz) and the rest of the world (900/1800/1900 Mhz)<br />
* USB Host function with 100mA power allowing you to power USB devices for short periods (will drain the FreeRunner battery faster)<br />
<br />
A full list of the hardware specs and components of the Neo FreeRunner (internal codename GTA02xxx) can be found here [[Neo FreeRunner GTA02 Hardware]]<br />
<br />
A comparison between Neo 1973 and Neo FreeRunner is [[Neo1973: GTA01Bv4 versus GTA02 comparison|here]]<br />
<br />
=== What is the price? ===<br />
<br />
It will be available in two versions <br />
* FreeRunner Base (for almost all users) and <br />
* Freerunner Advanced (for some software developers).<br />
Further details to follow<br />
<br />
We will sell this device through multiple channels. Direct from openmoko.com, the price will be $450 for the FreeRunner Base and $600 for the FreeRunner Advanced.<br />
<br />
[[Category:Neo1973 Phase 2 related| ]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Neo_FreeRunnerNeo FreeRunner2008-02-16T11:07:13Z<p>AudriusA: /* Intended use and users */</p>
<hr />
<div>The Neo FreeRunner (internal codename GTA02) is the second phone designed to run Openmoko software and is the direct descendant of the earlier [[FIC]] [[Neo1973]]. Hardware specs are [[Neo FreeRunner GTA02 Hardware|here]].<br />
<br />
=== Finding out status before FreeRunner is released ===<br />
<br />
To be emailed when it is released sign up to the announce mail list here http://lists.openmoko.org/mailman/listinfo/announce. For frequently asked questions please check [[FAQ]]. Approximately, twice a month an Openmoko team member writes an update to the project here [[Community Updates]].<br />
<br />
No official launch date will be given until the phone is ready.<br />
<br />
=== Intended use and users ===<br />
<br />
The Neo FreeRunner is a Linux based touch screen smart phone aimed at general consumer use as well as linux desktop users and linux software developers.<br />
<br />
General phone users will appreciate the high spec and performance of the phone and the wide range of free and custom software packages that you are free to install to make the maximum use of the hardware for your particular needs. Note that software tweaks and improvements will continue after launch as both the Openmoko team developers and the wider linux community work together.<br />
<br />
Linux users and software developers will appreciate the total freedom they have to use and design software for the FreeRunner<br />
<br />
=== What are the specs ===<br />
<br />
The specs share some features with the previous [[Neo1973]] such as<br />
<br />
* A very high resolution touch screen (1.7&quot; x 2.27&quot; - 43mm x 58mm) 480x640 pixels<br />
* 128MB SDRAM memory to allow operation of many applications at once<br />
* Internal GPS module for map and tracking programs<br />
* Bluetooth for local data exchange<br />
* Physical appearance will be the same as the Neo1973. See openmoko.com for more.<br />
<br />
but will gain the additional features of<br />
<br />
* 802.11 b/g WiFi for fast web browsing and data transfer<br />
* A faster 400Mhz processor (up from 266MHz)<br />
* A hardware Graphics Accelerator chip allowing fast graphics including video playback<br />
* 2 accelerometers so that the phone can know its orientation for example switching to landscape mode automatically<br />
* 2 LEDs illuminating the two buttons on the rim of the case<br />
* Tri-band GSM and GPRS for North America (850/1800/1900 Mhz) and the rest of the world (900/1800/1900 Mhz)<br />
* USB Host function with 100mA power allowing you to power USB devices for short periods (will drain the FreeRunner battery faster)<br />
<br />
A full list of the hardware specs and components of the Neo FreeRunner (internal codename GTA02xxx) can be found here [[Neo FreeRunner GTA02 Hardware]]<br />
<br />
A comparison between Neo 1973 and Neo FreeRunner is [[Neo1973: GTA01Bv4 versus GTA02 comparison|here]]<br />
<br />
=== What is the price? ===<br />
<br />
It will be available in two versions <br />
* FreeRunner Base (for almost all users) and <br />
* Freerunner Advanced (for some software developers).<br />
Further details to follow<br />
<br />
We will sell this device through multiple channels. Direct from openmoko.com, the price will be $450 for the FreeRunner Base and $600 for the FreeRunner Advanced.<br />
<br />
[[Category:Neo1973 Phase 2 related| ]]</div>AudriusAhttp://wiki.openmoko.org/wiki/Wish_List_-_HardwareWish List - Hardware2008-02-14T07:19:37Z<p>AudriusA: /* Galileo/GLONASS/GPS receiver */</p>
<hr />
<div>This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].<br />
<br />
Related pages are:<br />
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices. <br />
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any OpenMoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.<br />
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973 <br />
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.<br />
<br />
This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.<br />
==Processor==<br />
===A FPGA===<br />
A FPGA is a general purpose reconfigurable logic device.<br />
See [[Wish List - Hardware:FPGA]] for more details.<br />
<br />
===Samsung S3C2443===<br />
*[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&amp;partnum=S3C2443&amp;&amp;ppmi=1427 Samsung S3C2443] Up to 533 MHz, can act as a USB 2.0 device.<br />
<br />
==Internal Memory==<br />
===RAM===<br />
128MB Dedicated for open files, running software etc., not for storage, or 256MB at all would be really nice and enough for any future software.<br />
<br />
===ROM===<br />
Enough to Hold O/S and a fair number of applications and their settings. Persistent Storage with XIP capability. About 128 MB.<br />
<br />
===Storage===<br />
An internal Micro SDHC should be used for users' files and additional software<br />
<br />
==Wireless data networking==<br />
<br />
===WiMAX support===<br />
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex. In South Korea, 2.3Ghz is available for WiMAX, known as WiBro. WiMAX Forum sets heart on 2.5 GHz for global use.<br />
----<br />
Two campuses of the University of California have just completed a deal with a WiMAX service provider to lease UC's ITFS/EBS spectrum to provide WiMAX in the SF Bay Area. Bidding was aggressive between Nextwave, Sprint-Nextel, and Clearwire. Other UC campuses have awarded other contracts throughout California to various of the three contenders. The point here is: these three companies are competing aggressively for spectrum in the 2.5-2.7 GHz range, and it's not limited to CA. At a National ITFS Association meeting in 2005, representatives from Intel said they would be ready to release a WiMAX chipset compatible with these frequencies in 2007, for inclusion in laptops. I assume the folks at [[FIC]] know much more about it that I do! Based on these and other clues, I think WiMAX is coming in the 2.5-2.7 GHz band in the near future... I'll be surprised if I do not see some offerings by early 2009. <br />
<br />
-[[User:Tzf|Tzf]] 21:54, 24 November 2007 (CET)<br />
<br />
<br />
===LTE support===<br />
[http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution Long Term Evolution (LTE)] is a high-speed data service, similar to WiMax, but designed to be more compatible with existing GSM systems. While Sprint &amp; Clearwire are currently testing WiMax deployment in the US, AT&amp;T and Verizon appear to be in preference of LTE.<br />
<br />
While the project is ongoing and general in scope, it has set itself some specific goals, many of which are oriented around upgrading UMTS to a so-called fourth generation mobile communications technology, essentially a wireless broadband Internet system with voice and other services built on top.<br />
<br />
===Emerging Protocols===<br />
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)<br />
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)<br />
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)<br />
<br />
==Camera==<br />
<br />
* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, buisness card reading, healthcare, servicing, and more.<br />
<br />
* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful or leave the camera chip in place and have a removable lens assembly and replacement backcover.<br />
*See [[Hardware:Neo1973:Alternate_Cases:Camera | Alternate Cases:Camera]] for phone casing suggestions.<br />
<br />
* See [[Wishlist:Camera]] for a more detailed wishlist.<br />
<br />
==Display==<br />
===Multitouch screen===<br />
<br />
''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''<br />
<br />
See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.<br />
<br />
A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])<br />
<br />
*Use examples: [http://www.youtube.com/watch?v=UcKqyn-gUbY&amp;mode=related&amp;search= Multi-touch interface (from Adobe TED)], [http://www.youtube.com/watch?v=1ftJhDBZqss&amp;mode=related&amp;search= Multi Touch (new touchscreen technology)]<br />
<br />
===Bigger and better screen===<br />
2.8&quot; widescreen (like in [http://etencorp.com E-ten] PDA/smartphones), or 3.5&quot; widescreen (like in [http://www.expansys.ie/d.aspx?i=134944 Fujitsu Siemens LOOX N560]).<br />
<br />
262k or 16.7M colurs for displaying images and especially videos.<br />
<br />
OLED for better contrast, more rich colours, and less energy consumption.<br />
<br />
Maybe the [http://www.sharpsme.com/Page.aspx/europe/en/part/LS037V7DW01/ LS037V7DW01] by Sharp could be a solution. It has nearly the same specs as the currently used, but 3,7&quot; -- [[User:Wedge | Wedge]]<br />
<br />
===Distance sensing touchscreen===<br />
{{Main|Hardware:NearlyTouchScreen}}<br />
TouchKo's (now Wacom Company Ltd.) spatial capacitive &quot;touchscreen&quot;, can sense fingers at a small distance, so you do not get your display greasy, and can unlike some touchscreens, be operated with gloves.<br />
<br />
===&lt;s&gt;Video acceleration&lt;/s&gt;===<br />
Hardware acceleration for video playback and 2D/3D accelleration will be present in [[Neo1973 GTA02]].<br />
<br />
===EPD===<br />
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].<br />
<br />
Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption. <br />
<br />
Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.<br />
<br />
===Transreflective===<br />
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...<br />
<br />
===&quot;Slightly&quot; Larger Screen===<br />
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mm instead of the 3:4 aspect ratio would be even cooler (if one could be found).<br />
<br />
===Second Display===<br />
A 32x32 OLED display possibly on the back for camera framing or on an edge so it can be viewed like a pager.<br />
This could be used to display any number of alerts (from any installed software) the alerts could have a dynamic prioritisation which means during the work day a message from the boss has high priority but lower at home (could be GPS/Time controlled?) multiple alerts shrink the icons to a 3x3 grid higher priority messages get more space.<br />
<br />
===Micro Projector===<br />
[http://www.engadget.com/media/2006/02/digismartphone2.jpg Like the one shown here], new cellphones are now coming out with a small, low power projector. This can be used to show movies from your cell phone with 0.5m high image on a while wall for example...<br />
<br />
==Input devices==<br />
<br />
===No Dependence on Stylus===<br />
The Neo's basic functionality should be completely usable without a stylus, Like the iPhone but with stylus use for precision work.<br />
<br />
===A laser projection keyboard===<br />
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.<br />
<br />
===Just a few more Buttons===<br />
<br />
2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.<br />
<br />
With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.<br />
<br />
===D-Pad and Buttons===<br />
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)<br />
<br />
Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games. <br />
<br />
Here is a concept drawing of a possible neo1973 gaming version: <br />
(This has a 4-way direction pad, 8 way may be better for gaming)<br />
&lt;br/&gt;<br />
[[Image:Neogame90.jpg]]<br />
&lt;br/&gt;<br />
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.<br />
&lt;br/&gt;<br />
:''Note'' : The [http://en.wikipedia.org/wiki/Tapwave_Zodiac Tapwave Zodiac] Palm PDA / Game console hybrid had a similar setup - with an analog stick on the left (also used for quick selection using a radial main menu when working as a PDA), 4 buttons on the right (also configurable for shortcuts when using the device as PDA), and 2 shoulder buttons. Also it had and still has an enthusiastic scene of homebrew development (almost any console emulator for PalmOS can also take advantage of the additional buttons and graphic power of the device). If we also take into account the success encountered by the [http://en.wikipedia.org/wiki/GP32 GP32] in the past and the [http://en.wikipedia.org/wiki/GP2X GP2X] currently on the homebrew scene, it's not unreasonable to plan a future OpenMoko device with both a SmartPhone/PDA functionnality ''and'' hand-held console targeting homebrew development.<br />
<br />
===Thumb keyboard or keyboard attachment accessory===<br />
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.<br />
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).<br />
*Cheap clippable miniusb keyboard<br />
*One of the layouts proposed in [[Hardware:Keyboards]]<br />
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]<br />
<br />
===Analogue Controllers===<br />
<br />
====Trackball====<br />
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry&amp;reg; models.<br />
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.<br />
<br />
====Analog Joystick====<br />
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.<br />
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?<br />
<br />
====Dual analogues====<br />
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.<br />
<br />
===TV/radio receiver===<br />
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is widely available in the world, though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.<br />
A good start would be an FM tuner, since it's one of the most widely used formats of radio broadcasting in the world.<br />
<br />
Here's a selection of chips, though it's not clear if the drivers are open source. http://www.sigmatel.com/products/portable/wireless/fmtuner.aspx#fragment-14<br />
http://www.st.com/stonline/products/families/automotive/am_fm_tuners.htm<br />
<br />
===Accelerometer=== <br />
This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.<br />
<br />
See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.<br />
<br />
In some cases integrated gyroscopes may also be needed. A [[#Digital compass]] can even be of more use since it gives absolute rotation so slow rotations could also be measured. A 3D compass would be nicest, but a simple 2D compass already is a helpful addition to the accelerometers.<br />
<br />
*[[Wishlist:3D Viewport|3D Viewport]]<br />
*[[Wishlist:Computer Mouse|Computer Mouse]]<br />
*[[Wishlist:Determine Position|Determine Position]]<br />
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]<br />
*Change media player playlist when jogging vs walking. <br />
*Attempt to use to stabilise any future camera.<br />
<br />
This feature is scheduled for inclusion in the phase 2 Neo1973, GTA02.<br />
<br />
===Side-Mounted Touch Strip===<br />
Add a &quot;touch strip&quot; sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size.<br />
*With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.<br />
*With a few OLED screens beneath the strip it could be used as dynamic configurable buttons/alerts eg. zoom/flash/shutter with a camera application and SMS/Email/Voicemail alerts in standby<br />
<br />
===Heart Rate Compatibility=== <br />
<br />
An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.<br />
<br />
Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.<br />
<br />
===Digital compass=== <br />
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low. Also could be used to make the accelerometer data more exact.<br />
<br />
Very small [[I2C]] sensors like [http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass] (6.5 x 6.5 x 1.5 mm) are very appropriate for this.<br />
<br />
*[[Wishlist:Auto Align Map]]<br />
<br />
See [[Wishlist - Hardware: Digital compass]] for more information<br />
<br />
===Thermometer===<br />
An electronic thermometer might become handy for some users.<br />
<br />
There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].<br />
(Could just be cheap and use the thermometer from the battery, thats how they did it in the nokia 5140's). Also is integrated in a barometer/altimeter like the SMD500 mentioned in [[Wish List - Hardware - Atmospheric]].<br />
::But if you carry it in your pocket it is unlikely to show the correct air temperature anyway. [[User:AudriusA|AudriusA]] 17:12, 12 January 2008 (CET)<br />
<br />
===Barometer and Variometer (Altimeter)===<br />
<br />
A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.<br />
<br />
These are also common on high end GPS units. This is a great feature for walkers as you can tell how far you have got on any ascent/decent.<br />
<br />
See [[Wish List - Hardware - Atmospheric]] for more information.<br />
::The GPS device [[Manually using GPS|outputs the altidude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)<br />
<br />
===Finger print sensor===<br />
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&amp;Dept=computers Sony UX17].<br />
<br />
Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.<br />
<br />
===Barcode Scanner===<br />
*less cpu intensive and more reliable than camera+ocr<br />
*though, bluetooth-enabled readers are already available.<br />
<br />
===Light Sensor===<br />
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue&lt;.1 then Ring Quietly.<br />
<br />
===Wheel===<br />
A navigation wheel like on a sony/ericsson 810i would be nice.<br />
<br />
===Proximity Sensor===<br />
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.<br />
<br />
=== Make ''all'' unlocking of phone, password protected===<br />
<br />
When my (current non-neophone) phone is in my pocket and I have it locked, it sometimes accidentally unlocks itself since only two keystrokes in the correct order are necessary to unlock it. When it's unlocked and still in my pocket it sometimes calls someone without my knowledge. All phones I've seen today have a press-just-one-button bypass to answer an incoming call even when the phone is locked. I suggest making the locking mechanism let the user configure it so that the user has to enter a password even for answering incoming calls. The likeliness of the phone accidentally runbbing against my car keys, hitting a ten character long password, unlocking the phone without my knowledge and consent is low enough even for us most unlucky users.<br />
<br />
==Expansion==<br />
===Positioning of Buttons, Connections and ports===<br />
<br />
Ideally any cable ports such as charging, USB, audio, docking should not get in the way of your hand or fingers when holding it in it's normal orientation. For the sake of SDIO cards an external SD slot should be on the top edge. IR for remote control software and ease of inter-device communication should be on the corner so that it is facing away from you for both orientations. Buttons obviously are positioned for finger control. An example of how '''not''' to do this would be the HTC Universal<br />
<br />
===Storage===<br />
<br />
====MMC/SD/SDIO slot (rather than?) miniSD or microSD====<br />
*Cheaper, more durable cards in a widely accepted format.<br />
*Much much larger storage capacity, [http://blog.scifi.com/tech/archives/2007/08/23/toshiba_unleash_1.html even 32GB]<br />
*Cards are harder to lose<br />
*Wider selection of accessories, including SDIO accessories.<br />
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)<br />
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].<br />
<br />
====Two SD slots====<br />
*Micro SDHC for /home partition. Keep like current design underneath SIM card<br />
*Hot swappable externally accessible normal size SDHC/SDIO slot<br />
<br />
=== Internal Communication Bus ===<br />
*A standard and/or documented internal communication bus of some sort could simplify adding new hardware modules.<br />
*Serial USB or I2C connector internal to case towards the top<br />
*Several digital I/O pins that operate at TTL levels<br />
*A few analogue I/O pins attached to a A/D converter<br />
*Documentation of Debug board connector could provide some of this functionality.<br />
<br />
I2C is used on the Neo with some details of resources already in use documented!<br />
Please see [[I2C | Neo I2C Devices]] for more information &amp; a list of devices &amp; the addresses currently in use &amp; documented for the Neo1973.<br />
<br />
===Local Communication===<br />
<br />
====USB====<br />
* 5V Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host. Provide a maximum current to drive a basic USB keyboard/memory stick/mouse/webcam/astrowebcam. This could be done by adding a small cheap power converter like the [http://www.national.com/pf/LM/LM2753.html LM2753]<br />
* USB 2.0 <br />
* Standard type A socket for quick &amp; easy insertion of memory sticks etc.<br />
* OTG, to be able connect usb keyboard like [http://www.mobile-review.com/pda/review/cherry-kb-en.shtml Cherry G84-4321 SUNRG]<br />
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.<br />
* Protection against incorrectly wired USB ports: some USB ports are wired incorrectly; if the +5V and GND are swapped, the device would get -5V when it's expecting +5V, which could burn some chips. A reverse-biased diode between +5V and GND, D+ and GND, D- and GND, and (if used) ID and GND, with a low enough forward voltage drop (to limite the negative voltages to what the chips can withstand), would protect the device by tripping the port's short circuit protection.<br />
<br />
====Wireless USB support====<br />
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (&lt;3 meter). Chipsets suitable for a phone are likely to take some time to be available.<br />
<br />
====SIR/FIR transceiver (Serial Infrared) / IR remote control====<br />
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones. <br />
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.<br />
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway. <br />
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros. <br />
**reduces clutter, particularly in the living room.<br />
**inceases the neo's practical status as an 'always-have' device. <br />
<br />
Other uses.<br />
*Detecting reflections from inside of a caddy, and switching from active mode.<br />
*FIR would be a nice option, as it's some 40 times faster than SIR.<br />
<br />
===Other===<br />
<br />
====Video Out====<br />
*Through a docking port<br />
**S-Video/Composite Out<br />
**DVI Out<br />
**HDMI Out<br />
**Display Port<br />
<br />
==Output devices==<br />
<br />
===LED===<br />
*The Neo1973 GTA02 will have LEDs of some sort behind at least one button. [http://lists.openmoko.org/pipermail/community/2007-July/008458.html]<br />
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....<br />
**An alternative to this would be for one small part of the LCD to be separately backlit.<br />
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.<br />
**A Small OLED Screen could be used and display much more information than a LED with minimal power usage.<br />
<br />
*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.<br />
<br />
**The LED and button ideas could be combined: illuminated buttons.<br />
**It must be possible to completely disable the LED to save power or other personal preferences.<br />
<br />
=== Flashlight ===<br />
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.<br />
This is really well done in Nokia 5500.<br />
<br />
-I second this one. The most used feature in my Nokia 5140 after the calling and sms features is the flashlight. It's just one simple LED, but powerful enough to see with if it's really dark. If it ain't dark, you won't need the light anyway. :)<br />
<br />
Also, Who hasn't lost their keys and opened up their cell phone to use as a flashlight?<br />
<br />
=== FM transmitter ===<br />
Small FM transmitter to output to car, and other nearby radios.<br />
<br />
Fix the biggest flaw in the iPod before Apple does!<br />
<br />
=== Infrared Transmitter w/ universal remote software ===<br />
Infrared LED on top of device with universal remote software so you can control televisions, DVDs etc.<br />
[http://www.novii.tv/ Here] is an example of universal remote software.<br />
<br />
:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.<br />
<br />
:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.<br />
<br />
:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.<br />
<br />
===HAC Compliance===<br />
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.<br />
<br />
==Mobile Communication options==<br />
<br />
===Generic Access Network / Unlicensed Mobile Access===<br />
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type OpenMoko device.<br />
<br />
Note that this features requires more advanced access to the GSM modem. <br />
Special messages needs to be exchanged with the network.<br />
<br />
===Faster/better mobile connectivity.===<br />
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. An incremental improvement would be a radio with [http://en.wikipedia.org/wiki/EDGE EDGE ] support. EDGE is an evolved GSM standard and, like GPRS, it operates on the same frequency as voice. This means a quad-band EDGE radio will have near-complete worldwide coverage. <br />
<br />
[http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe and being deployed in the US, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.<br />
It is unlikely that all of these will be supported initially, but it is a goal. These faster standards operate in different frequencies from GSM/GPRS/EDGE. Which frequency exactly will depend on the carrier and country. For UMTS in the US, AT&amp;T uses 850/1900 MHz but T-Mobile will use 2100/1700 MHz for example.<br />
<br />
Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.<br />
<br />
===Ability to use multiple SIMs/networks===<br />
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.<br />
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...<br />
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.<br />
* A second/dual GSM module would allow full use of both sims at all times.<br />
* As a hack, [http://wiki.openmoko.org/wiki/Wish_List#Bluetooth_powered_Multi-SIM_support use another mobile via BT].<br />
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.<br />
* Dual SIM card support will be especially welcome by the women. They just love to talk on the phone.<br />
<br />
===PMR446/FRS Radio===<br />
* Include a PMR/FRS Radio.<br />
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).<br />
<br />
===[[DECT]]===<br />
* Include a [[DECT]] GAP/CAT-iq transceiver so you can use your home and/or office PSTN line<br />
** Ability to use Alcatel phonebook stuff (like provided by the eventphone.de phone equipment) would be very nice too<br />
<br />
===[[SIP phone]]===<br />
Make stripped down (and thus cheaper) version of the Neo1973 phone for use as a SIP phone. Remove GPS, GSM, accelerometers, stylus.<br />
<br />
Addition of an centimeters-precise location system [http://en.wikipedia.org/wiki/Real_Time_Location_Systems RTLS] would be nice, as it will allow highly sensible indoor context detection. Imagine putting the phone next to your mirror (where you shave daily) and watch it automatically switch to news radio channel. Or put it next to your bed and see it automatically switch to &quot;sleeping&quot; mode, when only calls from predefined numbers are accepted.<br />
<br />
=='''Casing'''==<br />
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.<br />
<br />
=== [[Hardware:Neo1973:Alternate_Cases:Expansion_Module_Casing | Expansion Module Casing]] ===<br />
Longer case (150-160mm+) with space in the top to put expansion modules, including test &amp; hobby hardware. Would require use of a standard internal power &amp; communications bus. Could be left empty with blank cover or house cameras, solar panels, a crank powered charger, special transmitters/recievers, or anything else imaginable.<br />
<br />
[http://www.likeasecret.com/Neo1973/Neo1973-Exp.mov Neo1973 Expansion Module Quicktime rendering]&lt;br /&gt;<br />
[[Image:Neo1973-Exp.png]]<br />
<br />
=== Expansion Back Casing ===<br />
Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...<br />
<br />
===[[Hardware:Neo1973:Alternate_Cases:Expansion_Front_Casing|Expansion Front Casing]]===<br />
Replacement fronts with e.g. extra buttons.<br />
<br />
=== Space efficient Lanyard ===<br />
The hole at the bottom of the phone takes a lot of space. A [http://en.wikipedia.org/wiki/Kensington_Security_Slot Kensington Security Slot] could be used instead.<br />
<br />
=== Rugged version ===<br />
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display, maybe aluminium case. The big ugly pseudo military version.<br />
<br />
=== Transparent ===<br />
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.<br />
<br />
That makes sense to me. I second that idea!<br />
<br />
=== Blank ===<br />
Even though the transparent case would work too, I would like to see a blank case of pure black or white so people could have the option of air-brushing,painting or even drawing on the case.<br />
<br />
==Misc==<br />
===Galileo/GLONASS/GPS receiver===<br />
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.<br />
<br />
=== GPS antena ===<br />
The current GPS device seems even dependent on weather and may not work in heavy rain or snow. It seems necessary to think how to improve the reliability. The small portable GPS antena may be an option.<br />
<br />
===X10 RF Remote===<br />
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.<br />
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).<br />
<br />
===RFID tag/RFID Reader===<br />
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]<br />
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.<br />
* Say you have RFID tags on your personal belongings: cellphone, keys... Neo could be programmed to remember the last recorded GPS location before it lost contact with the respective RFIDs. It'd be trivial to check where you left your cellphone, get directions from a map...or beep when the phone gets out of RFID range.<br />
<br />
*I agree with this idea, a great idea and you have to do it (Jackcday)<br />
<br />
===NFC chip===<br />
*A Near Field Communication chip, with this chip it will be possible to pay with your phone (like a credit card)in the near future, see [http://www.nokia.com/A4305081 Nokia]for details<br />
*NXP is a chip fabricator which provides NFC chips [http://nxp.com NXP] direct link&gt;&gt; www.nxp.com/#/pip/cb=[type=product,path=/53420/53424]|pip=[pfp=53424][0] their chips also support the above RFID reading<br />
<br />
===Less weight===<br />
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary &quot;user&quot; may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common bussiness or multimedia phones.<br />
{|border=&quot;1&quot;<br />
| Neo1973 || Fujitsu-Siemens LOOX N560 || E-Ten Glofiish X500+ || Sony Ericsson P990i || iPhone || Nokia E65 <br />
|- <br />
| 184 g || 160 g || 146 g || 150 g || 135 g || 115 g <br />
|-<br />
|}<br />
<br />
===Make it smaller===<br />
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!<br />
<br />
===Standard 3.5mm headphone jack===<br />
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. A 2.5mm jack is the most common for headsets. <br />
<br />
There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones. Adapters to 2.5mm are of course available and this 3.5mm jack is much more robust.<br />
<br />
Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone. Other expanded plugs might allow remote controls.<br />
<br />
Other uses might be better met using bluetooth, or USB audio.<br />
<br />
===Laser Pointer===<br />
Include a built in laser pointer. Everything is better with lasers.<br />
<br />
===Completely free hardware===<br />
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.<br />
<br />
=== Consider economy / inexpensive / less featured edition ===<br />
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.<br />
<br />
One big suggestion in this area is a b/w lower res display instead of the big color display.<br />
<br />
=== Inductive Charger ===<br />
<br />
It would be nice if it was possible to charge the phone without having to connect a cable. I'd like to have a simple docking station with an inductive charger like the type that's used for electric toothbrushes [http://home.howstuffworks.com/question292.htm ]. The charger itself could get its power from a standard wall-wart power supply, or it could be USB/Firewire powered.<br />
<br />
=== Solarpanel/dynamo Charger===<br />
<br />
It would be very nice to be able to charge the phone outside of the electric grid (for example on hikes and boating trips). A combined solarpanel and muscle empowered (rotational etc.) charger would do the trick nicely.<br />
<br />
'''some mobile Solarpanels'''<br />
<br />
[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01011&amp;k_id=1400&amp;hot=0 Off-Grid Systems Sunbag L]<br />
<br />
[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01001&amp;k_id=1400&amp;hot=0 Off-Grid Systems Sunbag S]<br />
<br />
[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01011&amp;k_id=1400&amp;hot=0 Silva Solar I]<br />
<br />
[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01012&amp;k_id=1400&amp;hot=0 Silva Solar II]<br />
<br />
[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sol01011&amp;k_id=1400&amp;hot=0 Solarc e-Go Professional]<br />
<br />
[http://www.heise.de/mobil/suche/ergebnis?rm=result;q=solar;url=/mobil/artikel/74142/;words=solar Solarc e-Go *] <br />
<br />
[http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Solar%20solar;q=solar;url=/newsticker/meldung/91536/ Solar JKT]<br />
<br />
<br />
- I think a dynamo charger (&quot;share charger&quot;, rotational, ...) would be more practical as a peripheral, connected through the USB-interface using the same principle cellphones now charge when connected to an USB-port. You could very easily hack this together. [http://www.metacafe.com/watch/449950/hack_a_flashlight_to_power_your/ flashligh recharge hack]&lt;br /&gt;&lt;br /&gt;Random thought; Why not create some merchandise toys with a small lithium battery which charge through centrifugal force allowing to recharge the phone with a small &quot;general&quot; connector.<br />
<br />
[http://www.heise.de/mobil/artikel/61368/0 Article about aome mobile power-sources]<br />
<br />
=== Plastic Solar/Back side on the Neo===<br />
<br />
Sollar cells from Plastic, on the reverse side of the Neo 1973<br />
modified and intergreated in the batery backcover/flap,<br />
like an energy source when the display is in standby mode.<br />
Thats can be use also as alternate charge method's and also helps in emergency.<br />
<br />
==Related Hardware==<br />
See [[Related Hardware]]<br />
<br />
[[Category:Hardware ideas| ]]<br />
[[Category:User]]</div>AudriusAhttp://wiki.openmoko.org/wiki/USB_NetworkingUSB Networking2008-02-09T12:19:22Z<p>AudriusA: /* Red Hat or similar */ + tested with</p>
<hr />
<div>= Neo1973 side =<br />
<br />
== Name resolution ==<br />
<br />
By default Neo1973 has usb0 interface working due to Ethernet gadget (g_ether) compiled into kernel.<br />
<br />
On the Neo, if you want to reach out to the internets using full qualified hostnames, you need to define your DNS server. Create a file /etc/resolv.conf with at least one line saying<br />
<br />
nameserver xxx.xxx.xxx.xxx<br />
<br />
e.g. nameserver 192.168.1.1<br />
<br />
Then you can also easily update your 2007.2 OpenMoko packages with &quot;ipkg update &amp;&amp; ipkg upgrade&quot; on the Neo.<br />
&lt;br&gt;&lt;br&gt;<br />
A better approach is it edit: /etc/network/interfaces and modify the line:&lt;br&gt;&lt;br&gt;<br />
&lt;code&gt;<br />
up echo nameserver 192.168.0.200 &gt;/etc/resolv.conf<br />
&lt;/code&gt;&lt;br&gt;<br />
to specify your preferred DNS server instead of 192.168.0.200.<br />
&lt;br&gt;&lt;br&gt;<br />
example: &lt;code&gt;up echo nameserver 4.2.2.2 &gt;/etc/resolv.conf&lt;/code&gt;<br />
<br />
<br />
Another approach is to symlink (NOW OBSOLETE?)<br />
<br />
ln -s /var/run/resolv.conf /etc/resolv.conf<br />
<br />
and fill the file at bootup with a script /etc/network/if-up.d/08setupdns containing:<br />
<br />
#!/bin/sh -e<br />
echo nameserver 192.168.0.200 &gt; /var/run/resolv.conf<br />
<br />
this way the file is correctly handled from ppp package when dialing into gprs.<br />
<br />
== Routing ==<br />
<br />
You need a additional route for traffic to the internet. This traffic can be routed through your pc (see below) if the pc is the default route destination. you can achieve this by adding<br />
<br />
gateway 192.168.0.200<br />
<br />
to your /etc/network/interfaces in the usb0 section.<br />
<br />
= Desktop side =<br />
<br />
== Manual method ==<br />
<br />
With the device connected, modprobe usbnet module and configure usb0 interface (as root):<br />
&lt;pre&gt;<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
&lt;/pre&gt;<br />
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:<br />
<br />
1. ping the Neo with<br />
# ping -I usb0 192.168.0.202<br />
2. add a route to your Neo:<br />
# /sbin/route add -host 192.168.0.202/32 dev usb0<br />
3 log in to the Neo<br />
# ssh root@192.168.0.202<br />
<br />
If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:<br />
* CONFIG_USB_USBNET<br />
* CONFIG_USB_NET_CDCETHER<br />
Both options are available in the Device Drivers -&gt; USB support -&gt; USB Network Adapters. For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].<br />
<br />
== Automatic method ==<br />
<br />
Took from [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] post by Marcin 'Hrw' Juszkiewicz.<br />
<br />
=== Debian or similar ===<br />
Edit /etc/network/interfaces:<br />
&lt;pre&gt;<br />
allow-hotplug usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
post-up echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
post-up iptables -P FORWARD ACCEPT<br />
&lt;/pre&gt;<br />
<br />
=== Ubuntu (Tested with Feisty and Gutsy) ===<br />
Edit /etc/network/interfaces:<br />
&lt;pre&gt;<br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.0.200<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
up echo 1 &gt; /proc/sys/net/ipv4/ip_forward &amp;<br />
up iptables -P FORWARD ACCEPT &amp;<br />
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &amp;<br />
&lt;/pre&gt;<br />
<br />
If you are doing the echo 1 &gt; /proc/... command manually, sudo may not be enough, then you will have to execute it from a sudo bash.<br />
<br />
Ubuntu Feisty and Gutsy appear to have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted.<br />
One can patch /etc/udev/rules.d/85-ifupdown.rules, editing the two lines at the end of the file:<br />
&lt;pre&gt;<br />
SUBSYSTEM==&quot;net&quot;, DRIVERS==&quot;?*&quot;, GOTO=&quot;net_start&quot;<br />
GOTO=&quot;net_end&quot;<br />
<br />
LABEL=&quot;net_start&quot;<br />
<br />
# Bring devices up and down only if they're marked auto.<br />
# Use start-stop-daemon so we don't wait on dhcp<br />
ACTION==&quot;add&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}&quot;<br />
<br />
LABEL=&quot;net_end&quot;<br />
<br />
ACTION==&quot;remove&quot;, RUN+=&quot;/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}&quot;<br />
&lt;/pre&gt;<br />
<br />
the bug is that the LABEL=&quot;net_end&quot; is at the wrong position<br />
=== SuSE ===<br />
/etc/sysconfig/network/ifcfg-usb0<br />
# USB configuration for PDAs (openmoko)<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
STARTMODE=onboot<br />
=== Fedora (Tested with FC8) ===<br />
/etc/sysconfig/network-scripts/ifcfg-usb0<br />
&lt;pre&gt;<br />
# USB configuration for PDAs (openmoko)<br />
# from http://www.handhelds.org/moin/moin.cgi/UsbNet<br />
DEVICE=usb0<br />
BOOTPROTO=none<br />
IPADDR=192.168.0.200<br />
NETMASK=255.255.255.0<br />
ONBOOT=yes<br />
&lt;/pre&gt;<br />
<br />
=== Red Hat or similar (tested with Workstation 5) ===<br />
Edit /etc/sysconfig/network-scripts/net.hotplug:<br />
<br />
After this command<br />
&lt;pre&gt;<br />
case $INTERFACE in<br />
# interfaces that are registered after being &quot;up&quot; (?)<br />
&lt;/pre&gt;<br />
add<br />
&lt;pre&gt;<br />
usb0)<br />
ifconfig usb0 192.168.0.200 netmask 255.255.255.0<br />
route add 192.168.0.202 usb0<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
exit 0<br />
;;<br />
&lt;/pre&gt;<br />
<br />
=== Gentoo ===<br />
* Open /etc/conf.d/net and add:<br />
# Neo1973<br />
config_usb0=( &quot;192.168.0.200 netmask 255.255.255.0&quot; )<br />
routes_usb0=( &quot;192.168.0.202/32 via 192.168.0.200&quot; )<br />
* Create a new init script:<br />
cd /etc/init.d<br />
ln -s net.lo net.usb0<br />
* Put iptables into use:<br />
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT<br />
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT<br />
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24<br />
* Store them<br />
/etc/init.d/iptables save<br />
* If you want the routing by default:<br />
rc-update add iptables default<br />
* You must also inform the kernel, to start forwarding. One way to automate this is to create /etc/conf.d/net.usb0 as follows<br />
<br />
preup() {<br />
echo 1 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0<br />
}<br />
<br />
postdown() {<br />
echo 0 &gt; /proc/sys/net/ipv4/ip_forward<br />
return 0<br />
}<br />
<br />
This way, packet forwarding will be turned on when Neo is plugged in, and off when it's not.<br />
<br />
=== MacOS X ===<br />
See the [[MacOS_X#USB_Networking|USB Networking section in the MacOS X article]].<br />
<br />
= Mobile development =<br />
<br />
== Proxying DNS requests ==<br />
<br />
If, like me, you move about quite a lot, connecting to various networks as you go and getting your ip via dhcp, you'll probably be annoyed at having to constantly update your resolv.conf on the Neo 1973.<br />
<br />
To get round this, as part of my setup script, I run a proxy dns on the ip address the neo comes in on at the usb0 port. This means that my Neo /etc/resolv.conf only contains:<br />
<br />
nameserver 192.168.0.200 <br />
<br />
and my laptop will proxy all dns requests based on it's own /etc/resolv.conf<br />
<br />
'''note that we only run the dns proxy on the usb0 interface so that we don't break any other networking'''<br />
<br />
=== Proxying with dnrd ===<br />
<br />
The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the dns proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available from my site. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.<br />
<br />
=== Proxying with a UDP forwarder ===<br />
Another easy setup is using a udp forwarder like the one from http://www.tapor.com/udpf/ - is use it with the command<br />
<br />
udpf-elf\<br />
-p=53\<br />
-f=`cat /etc/resolv.conf|awk '$1 == &quot;nameserver&quot;{print $2; exit(0);}'`:53<br />
<br />
=== Proxying with iptables ===<br />
Its is possible to forward DNS requests with iptables using the DNAT target<br />
<br />
iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1<br />
<br />
where &lt;tt&gt;192.168.0.1&lt;/tt&gt; is the IP of your residential gateway (router). This is the easiest method, but its not recommended if you have a direct connection to the Internet as ISP DNS servers can change, and this does no load-balancing.<br />
<br />
= Connecting to phone =<br />
<br />
Then &lt;tt&gt;ssh root@192.168.0.202&lt;/tt&gt; with empty password to get into phone.<br />
<br />
NOTE: the ssh daemon (dropbear 0.49) on the OpenMoko appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.<br />
<br />
===SSH Extras===<br />
<br />
If you get fed up with typing root@192.168.0.202, on your PC edit /etc/hosts and add an entry for 'phone'<br />
<br />
192.168.0.202 phone<br />
<br />
then edit ~/.ssh/config (or create it) and add<br />
<br />
host phone<br />
user root<br />
<br />
then all you need to do is type <br />
<br />
# ssh phone<br />
<br />
To avoid ssh added a new line for every ssh host-key to you known_hosts you can add the following to the phone section in ~/.ssh/config<br />
<br />
UserKnownHostsFile /dev/null<br />
<br />
You might want to use keys to bypass the login prompt too.<br />
<br />
===SSH Keys===<br />
====From host to phone====<br />
<br />
To generate ssh keys for use as a login mechanism type<br />
<br />
ssh-keygen -t rsa<br />
<br />
when prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh<br />
<br />
# mkdir ~/.ssh<br />
<br />
then from your PC copy the '''.pub''' file to the phone.<br />
<br />
# scp ~/.ssh/id_rsa.pub phone:.ssh/authorized_keys<br />
<br />
You should now be able to ssh directly into the phone.<br />
<br />
To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:<br />
<br />
DROPBEAR_EXTRA_ARGS=<br />
<br />
to <br />
<br />
DROPBEAR_EXTRA_ARGS=&quot;-s&quot;<br />
<br />
You will need to restart dropbear for this to take effect.<br />
<br />
====From phone to host====<br />
Generate the key<br />
<br />
dropbearkey -t rsa -f id_rsa<br />
<br />
The output will look something like this:<br />
<br />
Will output 1024 bit rsa secret key to 'id_rsa'<br />
Generating key, this may take a while...<br />
Public key portion is:<br />
ssh-rsa AAAAB3Nza[...]<br />
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8<br />
<br />
Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).<br />
<br />
From the phone, ssh with -i:<br />
<br />
ssh -i id_rsa user@host<br />
<br />
This works for me. I ripped off these instructions from: [[http://forum.openwrt.org/viewtopic.php?pid=53705]]<br />
<br />
===GUI on desktop through SSH===<br />
<br />
If you need to get the GUI on the phone onto the desktop via usb, you can use ssh as follows<br />
<br />
ssh -l root -X -v 192.168.0.202<br />
<br />
Login, and run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.<br />
<br />
===Remote apps on neo===<br />
<br />
To get desktop apps to show up on your neo, first log in to the phone<br />
<br />
ssh -l root 192.168.0.202<br />
<br />
Then once inside, run:<br />
<br />
DISPLAY=:0 xhost +192.168.0.200<br />
<br />
After this you can close the ssh session. Back on the desktop computer, run:<br />
<br />
DISPLAY=moko:0 xclock<br />
<br />
Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:<br />
<br />
DISPLAY=:0 xhost -192.168.0.200<br />
<br />
&lt;span id=&quot;bottom&quot;&gt;&lt;/span&gt; <br />
{{Languages|USB Networking}}<br />
<br />
[[Category:Hardware]]<br />
[[Category:Implemented]]</div>AudriusA