reference: http://code.google.com/p/ohmm-sw/wiki/LinuxTips#Connecting_to_Networks_on_the_Ubuntu_Command_Line
and : http://www.ccs.neu.edu/course/cs4610/
- Setting Up Your Own Linux Host
- Tweaks for a Virtual Machine on a Flash Drive
- Adding/Removing Users
- Connecting to Networks on the Ubuntu Command Line
- Passwordless SSH
- Remote X Window Display
- History
- The Old Way
- The Modern Way: Connecting from Server to Client
- The Modern Way: Connecting from Client to Server
Setting Up Your Own Linux Host
We recommend using Ubuntu Precise (12.04) hosts for working with OHMM. If you are using OHMM in a course, the provided Ubuntu installations should already be configured. However, if you want to use your own installation, the recommended packages are (install with sudo apt-get install):
build-essential yasm subversion avr-libc avrdude minicom ckermit screen openssh-server openjdk-6-jdk librxtx-java libcv-dev libcvaux-dev libhighgui-dev python-opencv libusb-1.0-0-dev freeglut3
Note: to fix a bug with current distributions of avrdude, sudo vi /etc/avrdude.conf and setchip_erase_delay to 55000 for m324p and m1284p. Or just run these commands (assuming you are running the defaultsh, bash, or dash shell) to make the edits automatically:
avrparts="m324p m1284p" for p in $avrparts; do sudo sed -i -e "/id.*=.*$p/,/part/ s/chip_erase_delay.*=.*/chip_erase_delay = 55000;/" /etc/avrdude.conf done
Some libraries, such as javacv, jscheme, and libpololu-avr that are needed by the OHMM code are not available from the standard repositories or require custom patches. We have packaged these as.deb packages for OHMM. You can install them by checking out the ohmm-sw open source repository and running these commands
cd ohmm-sw/ext make
This will install all the packages in subdirectories of ext, except those subdirectories which contain a file namedDISABLED, which are not currently needed.
Optional packages:
gcc-doc make-doc cpp-doc libstdc++6-4.5-doc cmake ant mercurial git-core ntp traceroute x2x lynx emacs23 eclipse gimp inkscape transfig pstoedit mplayer mencoder ffmpeg
Other configuration:
- The default permissions of newly created users on Unbuntu don't include some important group memberships. In particular, membership in theadm group confers the ability to run sudo; the uucp anddialout groups enable you to connect to serial ports (as you do to connect directly to the LLP with a USB cable or to use a USB-to-serial adapter to connect to the HLP); and thevideo and plugdev groups can be required for using USB webcams. Run these commands to add these and other useful groups to the default for new users (i.e. run these commands before you create new users), and also to add the extra groups to the user you are currently logged in as:
extragrps="dialout cdrom floppy audio video plugdev users adm lpadmin sambashare uucp" sudo sed -i -e "s/^[# ]*EXTRA_GROUPS.*=.*$/EXTRA_GROUPS=\"$extragrps\"/" $addusrcnf sudo sed -i -e "s/^.*ADD_EXTRA_GROUPS.*=.*/ADD_EXTRA_GROUPS=1/" $addusrcnf sudo usermod -a -G `echo "$extragrps" | sed -e "s/ /,/g"` `whoami`
- You may want to install the iptables-based firewall we provide:
cd ohmm-sw/hlp/scripts/firewall ./install.sh
- You may want to install the minicom and kermit scripts we provide:
cd ohmm-sw/hlp/scripts make kermitscr.install minicomscr.install
This will allow you to run commands like minicom acm1 to bring up a minicom serial terminal session on the /dev/ttyACM1 port to communicate directly to the LLP, or minicom usb0 to use the /dev/ttyUSB0 port for a USB-to-serial adapter connected to the HLP.
Tweaks for a Virtual Machine on a Flash Drive
If you specifically want to run ubuntu from a VMware virtual machine on a USB flash drive you may want to make a few optimizations that seem to significantly improve performance. These only apply to running from a flash drive; we do not recommend any of these for a regular virtual machine stored on your hard drive. First, set these values in the VMware VMX file:
mainMem.backing = "unnamed" mainMem.useNamedFile = "FALSE" logging = "FALSE" # suppress the "I moved it/I copied it question" (always moved) uuid.action = "keep"
Then boot the VM and make these edits in the indicated files:
/etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop" /etc/fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
The first one sets the "elevator" to "noop" which can help resolve stuttering behavior due to the default disk IO scheduler (elevator). The second puts/tmp on a ramdisk, which increases the speed of access to the temporary but frequently modified files that many programs automatically put there. Finally run
> sudo update-grub
and reboot.
Adding/Removing Users
To add a user:
> sudo adduser LOGIN
where LOGIN is the desired username. Note, use the command "adduser", not "useradd". If you make a mistake, you can remove a user with
> sudo userdel -r LOGIN
but be very careful doing that, of course (you may omit the -r to leave the user's files around at/home/LOGIN).
Connecting to Networks on the Ubuntu Command Line
You may be familiar with GUI tools, including NetworkManager in Ubuntu, to identify and connect to wireless networks. Normally you interact with NM graphically (via an icon in the task tray), but it is also possible to manipulate it from the command line. It runs as a daemon (background service) even when running headless (no GUI).
- Listing available connections: the command
> nmcli con list
will show a list of the "connections" that NM knows about. "Auto eth0" is the wired ethernet network; the remainder are wireless networks that NM remembers; we have pre-configured some of these to get you started. (NM usually sets the name of a wifi connection to "Auto FOO" where FOO is the network SSID; the "Auto " prefix seems to tell NM to automatically connect to that network whenever it is available, without asking for confirmation.)
- Checking the current connection: NM is designed to automatically find for the best available connection and use it; to see what it has selected, run
> nmcli con status
which will show the connection that NM has currently selected, and> ifconfigwhich will give the machine's IP address, if the connection was successful (look for inet addr in the section under wlan0 for a wireless connection, or eth0 for wired).
- Selecting a particular connection is done with the command
> nmcli con up id 'CONN'
where CONN is one of the connection names from con list, verbatim. (The quotes allow spaces in the connection name; for example, to connect to wired ethernet use 'Auto eth0'.) This will work for networks without security, or for those that use a "secret" (password) that is the same for all users of the network (in which case the secret is remembered along with the network). For networks that require username+password login, we have provided a script hlp/scripts/nm-connect-802-1x; run it at the command line to get a usage description. For networks that require you to click buttons or fill in forms on a web page, use lynx. To bring down a connection, replace up with down.
- checking wifi signal strength of nearby networks can be done on the command line with a command like this:
> sudo iwlist wlan0 scan | grep -e Quality -e ESSID -e Mode
- Adding new connections to NM on the command line is also possible, though somewhat arcane. We provide a scripthlp/scripts/nm-create-system-connection to make it more convenient. First install it withsudo hlp/scripts/nm-scripts/install.sh (if you are using one of the pre-configured Ubuntu installations for a course, the installation step should have already been done for you). Then you can runnm-create-system-connection to get usage information. Some basic examples:
# create a connetion to WPA protected network named ssid1, username foo, pass bar nm-create-system-connection wpa ssid1 foo bar # now connect to it nmcli con up id 'Auto ssid1' # create a connection to 802-1x protected network named ssid2 # credentials are per-user in this case nm-create-system-connection 802-1x ssid2 # now connect to it with username foo, pass bar nm-connect-802-1x 'Auto ssid2' foo bar
802-1x protected networks, which require per-user credentials vs a single global password for an entire (e.g.) WPA network, are often used in institutional settings. The commands to set the username and password without a GUI are also pretty arcane so we provide the nm-connect-802-1x script to help with that.
- If you do have the option to boot headful with a GUI, then instead of using thenm-create-system-connection command line script, you can use the more common NM graphical method to add a connection: click on the NM icon in the taskbar, select desired network from a list, and then enter your credentials. (You can also select "Connect to Hidden Wireless Network...", if the access point has been configured not to broadcast itself.) If you then go back to the NM icon and select Edit Connections -> Wireless ->connection -> Edit... -> Available to all users, NM will save the connection info to a file in/etc/NetworkManager/system-connections/, and it will automatically consider connecting to it at boot, even before any user has done a graphical login. This is called asystem connection (vs a user connection that would only be available to the currently logged-in user).
- Connecting the pandaboard HLP to a wifi network is a particularly important case for OHMM. One method to do that is to first attach a USB-to-serial adapter from the pandaboard to a PC or laptop. Bring up the connection in a serial terminal program likeminicom or kermit, log in to the pandaboard, and then you can run all the commands above to configure its wifi connection. Once it is connected note down its IP address.
We have also provided a script ohmm-sw/hlp/scripts/nm-scripts/nm-panda-wifi-helper that can help connect the panda to wifi networks automatically (it should also already be installed for you if you are using OHMM in a course). It watches the user pushbutton on the panda. This is right next to the reset button, so be careful.
When the button is held down for about 1 second it displays information about the currently connected network (including the panda's IP address) on the LCD display on the LLP (it takes a few seconds to gather the info and display it after you press the button). Holding it down for 3 seconds triggers a procedure to try to automatically connect to a list of preferred networks from the file /etc/nm-panda-wifi-helper/ohmm-preferred-networks, with report about the effects on the LCD. Note that this currently only works for networks that don't require per-user authentication. Also, the LCD display functionality won't work if you are running other code on the pandaboard which has already connected to the orangutan LLP.
Passwordless SSH
Say you want to ssh from a "client" machine, like your PC, to a "server", like the HLP on your robot.
- On the client machine run the command
> ssh-keygen -t dsa
If you have already done this at some point in the past, you do not want to do it again. If you are not sure, check if the file ~/.ssh/id_dsa.pub exists ( ~ is shorthand for your home directory) --- if it does, you had run ssh-keygen before.
- Copy the generated public key to the server. On the client machine, run the command
> scp ~/.ssh/id_dsa.pub SERVER:~/CLIENT-id_dsa.pub
whhere SERVER is the DNS name of the server and CLIENT is the hostname of the client.
- ssh in to the server (using your password still) and run the commands
> mkdir .ssh > cat CLIENT-id_dsa.pub >> ~/.ssh/authorized_keys > rm CLIENT-id_dsa.pub > chmod 700 .ssh > chmod 600 .ssh/*
The mkdir command will give an error message if ~/.ssh already exists, but this is harmless.
- Return to the client and try to ssh in to the server again --- you should not be prompted for a password.
Remote X Window Display
Because the onboard HLP typically runs headless (without a monitor, keyboard, and mouse attached), it can be very useful to run graphical programs on it that display on a remote computer. This is possible, though it can use a lot of network bandwidth. (For viewing images from the onboard camera we provide an HTTP image server that sends compressed JPEG or PNG images using much less bandwidth.)
History
The X.org display system now used in Linux is a descendant of a very old system calledX11, or just "X". A key design aspect of X is that it is fundamentally aclient-server architecture.
You may be used to thinking of interacting with web "servers" as remote machines, with your local desktop machine the "client". In X, theX server is a daemon (background service) program running on your desktop, i.e. on the computer with the monitor to which graphics should be displayed.X clients are programs that want to display graphics in windows: web browsers, terminal programs, video players, etc.
The Old Way
When you run an X client it implicitly checks the value of the DISPLAY environment variable, which has the format[server]:d[.s]; server can be the DNS name or IP address of the machine running the X server, which does not need to be the same as the machine running the client program. It can also be "localhost" or omitted, in the common case that both the X client and server are on the same machine. d and the optional s are integers that can be used to select which part of a multi-screen display should be targetted; they are usually both 0 unless you know you need something else.
So, it seems that if we want to run an X client program, like xterm, on one machine (let's call itclient), and have it display on (possily another) machine server, then it should suffice to run these two commands onclient:
> export DISPLAY=server:0.0 > xterm &
Once upon a time, that would have worked, almost. Even in the old days there was a security mechanism: on the server you would have had to run
> xhost +client
to indicate that incoming X connections from client should be accepted. (Here we are usingclient and server as standins for the corresponding DNS names.)
Unfortunately, nowadays increased security means that the above steps alone usually do not work.
Also, networks are now often relatively complex; the above example assumes that bothclient and server can "see" each other on the network. In practice, it is now common to have "local subnets" like 192.168.1 which appear to machines outside the subnet as a single address corresponding to a router machine runningnetwork address translation (NAT, which used to be called "IP Masquerading", possibly a more informative name). Machines inside a local subnet can see out, but unless special arrangements are made, they cannot be seen from the outside.
Remote X display is usually still possible despite these challenges.
The Modern Way: Connecting from Server to Client
The usual situation is that you are sitting at the machine running the X server (server, e.g. your PC), and you ssh from there toclient (e.g. the HLP on your robot; note that we are using the server and client terms to refer to the "backwards" X connection; the ssh connection is actually fromserver to client.) client needs to be visible from server (but not vice-versa), and client also needs to be running an ssh server.
Ubuntu desktop editions to not come with an ssh server installed by default, but it can be easily added simply by running
sudo apt-get install openssh-server
which both installs the ssh server and starts it, or does nothing if it's already installed and up to date. (If you're taking a course using OHMM and using one of the pre-configured Ubuntu installations, this step should have already been done for you.)
There are only two steps needed in this common server-to-client use case:
- Make sure X11Forwarding is set to yes in /etc/ssh/sshd_config onclient (this requires root perms on client to change, of course; it should have been done for you if you are using a pre-configured Linux installation as part of a course).
- On server run
> ssh -X -C [user@]client
which will log you in to client with X forwarding (and lossless compression) enabled. Then on client you can run> echo $DISPLAYwhich should return a value like localhost:10.0. This may seem confusing; what is happening is that ssh has arranged a tunnel so that when you run an X client program like> xterm &on client, it will connect to a special port on client that is tunneled back to the X server on server, all through the ssh connection.
The Modern Way: Connecting from Client to Server
It is less common, but possible, to do this all the other way around, i.e. to start onclient (e.g. your HLP), establish an ssh tunnel to server (e.g. your PC), and then run X client programs onclient that display on server. It is trickier to set this up. Here is a recipe:
- Make sure that server is visible over the network from client (i.e. you should be able to pingserver from client). If server is actually a virtual machine, you will either have to configure it to use "bridged" networking (not "NAT"; this is an easy switch in VMWare settings, and does not even require a reboot), or you can install a secondary network interface device, like a USB wifi dongle, that you ask VMWare to connect directly to the virtual machine. The first option requires that the VM have privlidges to connect directly to the external network (which will not work on managed networks like at many educational institutions unless the sysadmins to allow the virtual machines directly onto the network). The second option enables the VM to potentially connect to the same wifi router to whichclient (e.g. your HLP) is connected, thus putting them both on the same local subnet.
- Make sure that an ssh server is installed and running on server (see above).
- In a moment we are going to be opening the X server port and we don't want just anyone to be able to connect. If you're running Ubuntu then you can try the simple firewall we provide inohmm-sw/hlp/scripts/firewall, which plays nicely with the NetworkManager service; just run./install.sh there on your server (If you're taking a course using OHMM and using one of the pre-configured Ubuntu installations, this step should have already been done for you.).
- Log in graphically and run
> xhost +
on server (this will be forgotten when you log out). This step and the last two have opened the X server TCP port 6000, which would allow any X client to connect, if it were not for the firewall. The firewall only allows local X clients (i.e. those that appear as if they originate from server itself), but still allows incoming ssh connections.
- Finally, on client run
> ssh -f [user@]server -L 6010:server:6000 -N > export DISPLAY=localhost:10.0 > xterm &
The first command establishes an ssh tunnel from the X server port 6010 on client to that port on server; the second tells X client programs onclient to connect to that local port (the convention is that the port number is 6000+d whered is the display number, here 10), which will be tunneled back to server.