Connecting wifi from the command line, ubuntu or embedding ubuntu

ref: How to Connect WiFi from Terminal on Ubuntu 16.04 (added on Dec, 2019)

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/

LinuxTips

Updated Yesterday (24 hours ago) by martyv...@gmail.com

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
> ifconfig
which will give the machine's IP address, if the connection was successful (look forinet addr in the section under wlan0 for a wireless connection, oreth0 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, uselynx. To bring down a connection, replaceup 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 runssh-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 onclient you can run
> echo $DISPLAY
which should return a value like localhost:10.0. This may seem confusing; what is happening is that ssh has arranged atunnel 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 onserver, 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.).

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