Exploring Your Node
So you just got your node running. You think. How can you tell what is going on in your node?
Remote Shell
You can use SSH to login to the node, but it is much less user friendly than the web interface. It is recommended that you use the web interface if at all possible.
To login over SSH, you should use the user name "guest" and the password "guest". If you were logging in from the command line, it would look like "ssh guest@10.A.B.254". The default root password is "changeme", but remote root login is disabled. If you are logged in as guest and you want root privileges, you can use the "su root" command.
Here is a list of fun commands for rooting out information about the node and network:
cat /var/run/dmesg.boot: This will print out all of the boot messages.ifconfig -a: This displays information about all interfaces in the system.netstat -rn -f inet: This displays your current routing table.
Changing Your Root Password
When you download one of the publicly available builds of CUWiNware, there is a standard root password "changeme". As requested, it is a good idea to change the root password to prevent others from doing interesting things to your node without your permission. Unfourtunately, any changes made to the system will be erased upon reboot unless you make the changes in writable memory. If you are using flash media, you can make the changes in "/permanent/" and they will be preserved. The following guide was taken from the forums.
$ su root: Gain root privileges.Password:: "changeme"# mount | head -1: Display how the current file system is mounted./dev/wd0a on / type ffs (read-only, local): Hrm, read-only. That will need to be changed.# mount -u -w /: Change the status of the filesystem at / (the root file system) to be read and write.# mount | head -1: Display current file system again./dev/wd0a on / type ffs (local): It's not read-only anymore.# passwd: Change the password for the current user.Changing local password for root.New password:: Find a creative password that no one will guess. "password" or "12345" are not good passwords.Retype new password:# cp /etc/master.passwd /permanent/etc: Copy the password files to the permanent directory.# cp /etc/spwd.db /permanent/etc# cp /permanent/etc/spwd.db /permanent/etc/garbage: Work around for old bug when writing to flash.# mount -u -r /: Change the root file system to be read-only again.# mount | head -1: Display that the file system is, in fact, read-only./dev/wd0a on / type ffs (read-only, local)# reboot: Reboot the node.
At this time, you cannot make changes to nodes booted from CD-ROM (ROM stands for Read Only Memory). There is talk about using a floppy drive to allow users to configure a node, but at this time (v0.5.8) no one has written the code for that.
Nodeconfig: A Web Interface
The easiest way to see how your node is set up is to view the web interface of your node.
If you are using your node as a router, you can type the address "http://192.168.0.1/" into your web browser to load the web interface. Currently the only feature for understanding your node is RouteViz. You can also use the web interface to configure your node.
To view the web interface on a remote node, you can use the command "ssh -L 8000:localhost:80 guest@10.0.A.B" to log in to the remote node. Replace "10.0.A.B" with the IP address of the ethernet interface of the remote node. When you are logged in, you can visit the URL "http://localhost:8000" on the machine that you logged in from to view the remote web interface.
Route Visualization
When you view the "RouteViz" page you will be shown a virtual map of the network as the current node sees it. This map is built from HSLSd's adjacency database. HSLSd one of the important programs used to build the routing table.
Unless you customize the installation of CUWiNware with a special local map file for the area around your community network, the layout of nodes will simply be what "looks good". RouteViz will attempt to make a best guess at where nodes are located based on the quality of the signal between each node. Walls (especially metal) greatly degrade the wireless signal, while open spaces will let a signal travel a long distance. Because the node has no way of determining the terrain around it, the locations of nodes on the RouteViz map may be skewed and are simply a best guess.
Click on a node to get information about it.
The links between nodes show the current link quality as measured by ETX. Red links are nodes a ways down the street, while green links are your near neighbors (in a wireless sense). If a node has only red links connected to it, it should be investigated to increase the quality of its connection to the mesh.
Configuring a node
Compact flash nodes and CD-ROM nodes with a floppy drive installed can be configured via a web-interface and clicking on "Config".
Configurable values are:
channel
This can be any valid channel for the protocol being used. For 802.11b this is any integer between 1 and 11. Every node in a given mesh must be on the same channel.
wired interface
This can be set to "auto", "dhcpd", or "dhclient". Depending on the setting the node will either act as a DHCP client or a DHCP server. If it is a DHCP client then it will act as an "internet connected node". The default is "auto".
hostname
This is the name by which this host identifies itself.
latitude, longitude
The latitude and longitude for use by the visualization engine. Do not set these unless you have also custom configured RouteViz with a local map and it's latitude and longitude corners.
nameservers
A comma separated list of nameservers that will be used locally and given out to DHCP clients to use for their lookups. You should choose something local to your ISP or a public DNS server.
ssid
A unique identifier for the whole mesh cloud, this must be the same one all machines that wish to be part of the mesh.
Configuring a node creates the file /etc/cuw_config on a node. That file which is simply a flat file containing variable assignments. You can untar an upgrade image, replace it's cuw_config file, then retar it and then apply it as an upgrade. This is an easy way to create a localized distribution from the standard builds.
Troubleshooting Guide
The visualization tool is the best way to start troubleshooting.
From the viz page you can test the connection between you and the node. You can also test the connectivity along the route to the internet. If the local network has packet loss then the problem is probably with your Wireless Access Point or your LAN rather than with the CUWiN wireless mesh network. If your path to the internet has packet loss then it is time to investigate the viz map for bad links. If you can't access the software at all then either the node is down or you have found a bug in the node code.
If you identify a problem on the mesh as the reason for your network outage, please send the text from the Test Local Network and Test Internet Connectivity links to cu-wireless-support@cuwireless.net along with a description of the problem that you are having.
If your node has been completely knocked offline, you will most likely need to climb up on the roof and check it out. Nodes have been known to fill with water when there is a leak in the top, but no leak in the bottom. Lightning strikes also occur.
What follows is a list of helpful commands that are useful in troubleshooting the network.
df -h
Shows all of the mounted partitions; -h makes numbers easy to read. Use this to show the memory space. If nfs is small, programs will be unable to run.
netstat -rn -f inet
Shows routing tables.
ifconfig -av
All the information about your network interfaces will be displayed in verbose mode.
ping -n google.com
Tests to see if the node can use the network to reach google.com
traceroute -n google.com
Documents the route that a packet to reach google.com
The following is a list of important files that you will want to use the less command to look at:
less /var/db/linkstates
Shows all the linkstate information.
less /var/log/daemon*
Demonstrates exactly what hsls is doing.
less /var/log/messages*
Registers all error messages
To see what Zebra is up to:
telnet localhost 2601
password: wireless
show ip route
Shows zebra routes.
How-to Guides
CUWiN is always seeking ways to help people use our software and hardware. To that end, we are committed to providing the how-to documents that break things down in the simplest possible manner. We have started this part of the manual with two documents: how-to build a CUWiN Metrix node and how-to PXEboot a Soekris 4526 using NetBSD. These documents are dynamic in that we are constantly changing the way we build wireless networks to take advantage of new technologies, new hardware, and the software that we develop. Therefore, if you having a problem with a particular document, check back to make sure that it has been updated. If it hasn't been updated, email us, giving as much detail as possible about the place in the document where you are having trouble.
Since we have a limited staff and always seem to have about ten more irons in the fire than we can possibly deal with, we encourage you to develop your own how-to guides and submit them to us via email. We are always happy to add new things that can help people do it themselves.
Flashing a Meraki Mini
Flashing the Meraki Mini with NetBSD
NOTE: This process will clobber the load of Linux on this unit. I have not been able to successfully save the original image, but that was probably largely due to my own pilot error -- it turns out that Linux uses the entire flash memory.
First, you must have an image compiled. Redboot prefers to load srecords, and the default kernel builds an srecord file.
% ./build.sh -m evbmips-eb kernel=MERAKI We're going to use HTTP to load the files. I just put the resulting netbsd.srec file into the root htdocs on my server. You could probably put it somewhere else too.
% cp sys/arch/evbmips/compile/obj/MERAKI/netbsd.srec \ /var/apache/htdocs Next we need to connect to the Mini via a serial line. I set up a line called "usb" in /etc/remote, so that I can tip in like this:
% tip -115200 usb
connected However you connect, its 115200 8N1. Once you power up the unit, you'll see something like this:
Ethernet eth0: MAC address 00:18:0a:01:06:d1 IP: 192.168.84.1/255.255.255.0, Gateway: 0.0.0.0 Default server: 192.168.84.9 RedBoot(tm) bootstrap and debug environment [ROMRAM] Release, version V1.04 - built 12:24:00, Apr 17 2006 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: Meraki Mini RAM: 0x80000000-0x82000000, [0x8003d110-0x80fe1000] available FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each. == Executing boot script in 2.000 seconds - enter ^C to abort Quickly press Control-C to interrupt the boot. Run "fconfig" to update the configuration data flash.
RedBoot> fconfig Now it will prompt you for all the flash parameters. You might want to record the old parameters in case you want to restore them. I didn't bother.
The following is what I entered, I have the Mini configured as 192.168.251.93 and I have a HTTP server providing the srecord image on 192.168.251.21. It is possible that BOOTP could be used too, but I've not tested it. Redboot isn't particularly robust.
Run script at boot: false Use BOOTP for network configuration: false Gateway IP address: 192.168.251.1 Local IP address: 192.168.251.93 Local IP address mask: 255.255.255.0 Default server IP address: 192.168.251.21 Console baud rate: 115200 GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Erase from 0xa87d0000-0xa87e0000: . ... Program from 0x80ff0000-0x81000000 at 0xa87d0000: . Next we reset the board, so the new parameters will take effect.
RedBoot> reset Wait a short bit (~2 secs or less) for the unit to reboot. It will not autoboot this time, instead going right to the prom property.
Ethernet eth0: MAC address 00:18:0a:01:06:d1 IP: 192.168.251.93/255.255.255.0, Gateway: 192.168.251.1 Default server: 192.168.251.21 RedBoot(tm) bootstrap and debug environment [ROMRAM] Release, version V1.04 - built 12:24:00, Apr 17 2006 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: Meraki Mini RAM: 0x80000000-0x82000000, [0x8003d110-0x80fe1000] available FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each. RedBoot> Now we load our netbsd.srec file. The following assumes the path to it on your HTTP server is /netbsd.srec. Adjust accordingly if you need to.
RedBoot> load -m http /netbsd.srec Entry point: 0x80041000, address range: 0x80041000-0x80202350 At this point, if you just type "go", the NetBSD kernel you loaded will boot. This is the safest way to run NetBSD on the Meraki, becuase it never disrupts flash.
=========== | WARNING | =========== Proceeding from this point will erase the flash on your unit, and might leave it unusable. Proceed at your own risk. If you're still here, you must want to write NetBSD to flash. It is instructive to look at what is already in flash:
RedBoot> fis list Name FLASH addr Mem addr Length Entry point RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000 stage2 0xA8030000 0x80100000 0x00020000 0x80100000 FIS directory 0xA87D0000 0xA87D0000 0x0000F000 0x00000000 RedBoot config 0xA87DF000 0xA87DF000 0x00001000 0x00000000 Note that the flash starts at 0xA8000000. Allocation is done in flash sector sizes of 64K at a time. (I.e. except for the RedBoot config, all flash addresses should end in 0000 when displayed in hex.)
Unfortunately, the Linux code doesn't properly allocate everything in RedBoot. It turns out that stage2 is the Linux bootloader. There is a JFFS2 image located at 0xa8050000 thru 0xa8150000. The Linux kernel is located at 0xa8150000 through 0xa8490000. I mistakenly believed the data between 0xa849000 and 0xa87d0000 to be free. But I was wrong. Pretty much the whole flash is used.
I have not tested this theory, but it should be possible to read the flash data that we are going to overwrite, and save it in a file. Then in theory we could restore it. I only had the one unit, and I neglected to perform this step. Doh!
Anyway our kernels are always under 2MB, so we allocate based on that. (If you put an mfs in your kernel, it will be bigger, and you might need to change some parameters appropriately. I recommend leaving the first 320K of flash alone. You _must_ leave the first 192K alone, because it is used by RedBoot, and the 128K after that is useful if you ever want to restore Linux. I'm not sure if the Meraki Linux code drop includes the source for this bit.)
Recall our kernel load from above (if you do it again, its harmless):
RedBoot> load -m http /netbsd.srec Entry point: 0x80041000, address range: 0x80041000-0x80202350 So, lets write it to flash. The fis create command below should all be typed on one line, but to facilitate display, I've broken it up and used a backslash "\" to indicate that the data should continue unbroken. Don't type the backslash.
The results look like this (it will take a while to do this, maybe a couple of minutes, the SPI flash is not fast):
RedBoot> fis create -b 0x80041000 -l 0x200000 -f 0xa8490000 \ -e 0x80041000 -r 0x80041000 netbsd ... Erase from 0xa8490000-0xa8690000: ................................ ... Program from 0x80041000-0x80241000 at 0xa8490000: ................................ ... Erase from 0xa87d0000-0xa87e0000: . ... Program from 0x80ff0000-0x81000000 at 0xa87d0000: . RedBoot> Notice that it did two erases/programs. That's because we also updated the RedBoot directory in upper flash. In case you were wondering:
-b indicates the source address to copy from
-l indicates the image length (2 MB)
-f indicates the destination flash address
-e indicates the entry address when the image is loaded
-r indicates the image load address when the image is loaded
netbsd is the image name (you could name it something else!)
If you change the flash destination address and length, you can store a larger kernel. I recommend never starting your flash address lower than 0xa8150000 and you must not let the image extend beyond 0xa87d0000.
Here's the image listing in flash:
RedBoot> fis list Name FLASH addr Mem addr Length Entry point RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000 stage2 0xA8030000 0x80100000 0x00020000 0x80100000 netbsd 0xA8490000 0x80041000 0x00200000 0x80041000 FIS directory 0xA87D0000 0xA87D0000 0x0000F000 0x00000000 RedBoot config 0xA87DF000 0xA87DF000 0x00001000 0x00000000 Lets reset and make sure that we can use it.
RedBoot> reset Ethernet eth0: MAC address 00:18:0a:01:06:d1 IP: 192.168.251.93/255.255.255.0, Gateway: 192.168.251.1 Default server: 192.168.251.21 RedBoot(tm) bootstrap and debug environment [ROMRAM] Release, version V1.04 - built 12:24:00, Apr 17 2006 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: Meraki Mini RAM: 0x80000000-0x82000000, [0x8003d110-0x80fe1000] available FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each. RedBoot> Now lets try loading the NetBSD image from flash:
RedBoot> fis load netbsd It will take a few seconds to load the image from flash. Now lets boot!
RedBoot> go [ netbsd boots... dmesg begins...MIPS32/64 params: cpu arch: 32... That's it. After this, the rest is just normal NetBSD. If you want to set this up automatically, you can setup an automatic boot script using fconfig. The commands you want to setup in the script are just:
fis load netbsdgo Enjoy.
No comments:
Post a Comment