Skip to content

CMASS DNS and Diagnostics Server

Jump to bottom Edit New page
Nick Walker edited this page Oct 11, 2017 · 1 revision

CMASS was developed in its own git repo, which can be found here.

Overview

CMASS was built to replace and extend DNS Server - smallDNS. It provides mapping from robot names to IP addresses like smallDNS, but uses a system that can also send other information.

The system consists of two parts:

A 2-part client that runs on a robot:

Part 1: ROS node

  • Subscribes to ROS topics
  • Periodically sends information gathered from topics to the server via HTTP requests.

Part 2: IPUpdater.py

  • Runs periodically as a cron job
  • Sends a HTTP request to update the robot's IP if it has changed.

These are split up so that if a robot is on but not running the segbot code, it will still have an up-to-date IP for SSH purposes.

A server that runs on nixons-head:

  • Listens for HTTP traffic
  • Updates its information on the robot based on requests received from robots
  • Serves its information on the robots

Security

If the server is running in secure mode, it will only process updates that include a valid token. Tokens are automatically generated by the ROS client and the IP Updater.

The security process begins by constructing a string (robot diagnostics) in the form of URL parameters. A salt, stored in /home/bwilab/.cmasskey, is appended to the parameter string and fed into a SHA-256 hash function. The salt is applied to the result of the hash and it is fed back into the hash function until 1000 hashes have been performed. (Why so many?) The result of the 1000th hash is the token, which is added to the string as an additional parameter. The string is now ready to sent to the server for evaluation.

When the server receives a request, it parses the URL into a string. The token is removed from the string and saved, which then leaves the original parameters. The hashing process is repeated on the server using its own .cmasskey. The result of the server's hash and the token received in the request are then compared; if they match, the request is valid and the server will update the robot status accordingly. If they don't, disregard the request.

A timestamp is added to the parameters to make the tokens expire. The server checks the received timestamp, if it is older than 5 seconds old or in the future, it is disregarded. This timestamp is used purely for time-sensitivity, the “Time Last Alive” field in the robot display is assigned when the server has already verified the token and is updating the robot's status.

Installing the client

  1. The CMASS package is included in the robot code (bwi_common/bwi_cmass), most of the installation is taken care of in a standard robot code install.
  2. Copy the cron job from crontab.entry into the system-wide crontab (by running crontab -e).

Installing the server

  1. Make sure Go is installed on the system
  2. Switch to the desired directory
  3. Clone the CMASS repository by running git clone https://github.com/PLACEHOLDER

Running the server

  1. Log in as bwilab ssh -p 40 [email protected]
  2. Switch to CMASS server directory
  3. Start a screen session: screen -S cmass
  4. Run go run server.go
  5. Detach screen by pressing with Ctrl+A D
  6. Log out

By default, the server runs in “secure” mode, meaning it doesn't process updates that don't provide a valid token. Additional information can be found in the README.md

Stopping the server

  1. locate the process lsof -i : (take note of the process's PID)
  2. kill the process kill

Stopping the process can be confusing; if you just search for the file name, you'll find a process. But when you kill it, server stays up! Go creates an executable in go/bin and runs it there, so that also has to be killed.

Add a custom footer
Clone this wiki locally