FAQ
Testbed Usage
How do I get access to the testbed ?
This is explained on the Getting Started page
Which default images are provided for the CityLab testbed ?
See the Disk Images page.
Where can I find a list of which nodes are present/available in the Testbed
I can't create links to/from nodes in the CityLab testbed in the JFed interface.
We are painfully aware of this limitation, and fixing this is at the top of our TODO list. In the mean time, take a look at the GRE Tunnels page for a workaround.
Why do I get a 'network connection' error when I try to start a test ?
The most likely reason for this is that your host network is blocking outbound TCP connections to port 12369. You can easily work around this by enabling the JFed Proxy. Click here for more information on how to do so.
Do I need to enable the JFed SSH Proxy to be able to login to the nodes ?
Under normal circumstances this should not be required. All nodes have a public IPv4 and IPv6 address and inbound SSH-connections are allowed by our firewall. The only reason you may have to enable the JFed SSH Proxy is if your host network blocks outgoing SSH-connections.
Take a look at the JFed documentation. It's quite extensive and should answer most of your questions.
Network Connectivity
Why Is the MTU on the wired (control) interface 1462 instead of 1500 bytes ?
The Emulab testbed management software we use to manage the testbed expects all test nodes to be connected to a single L2-segment (VLAN). As can be seen on the node map website however the CityLab nodes are installed on different buildings in the City Center and therefore also connected to different L3-networks. To resolve this issue, the L2 traffic from the individual nodes is tunneled to a concentrator in our server room using a setup not unlike the one discussed here.
This does however incur a 38-byte tunnelling overhead for each packet. To prevent fragmentation of the (outer) IP-packet, the MTU inside the tunnel, and therefore the entire L2 segment, is capped to 1462 bytes.
UDP packets get lost and TCP sessions hang when I bridge a GRE-Tunnel to a WiFi interface.
This is probably because the MTU configured on the WiFi clients does not match the MTU of the GRE Tunnel. See this page for more information on how to solve this.
The throughput over the wired interface is much lower than I expected. Why ?
In contrast to many other JFed-testbeds (such as for instance w.iLab-2), the nodes of the CityLab testbed are not connected to a single Gigabit-ethernet switch. Instead, they are connected to whatever network is available in the buildings on which they are deployed. Moreover, because of the L2/L3 issue discussed above, all traffic from the nodes needs to be tunnelled to a central concentrator which currently has an uplink of 1GBps.
As a result, the throughput that can be achieved between two nodes not only depends on the capacity and the uplink of the network to which the nodes are connected but also on how much traffic is generated by other nodes.
Embedded Radios
How do I know which serial interface (/dev/ttyUSBX) is connected to what device?
If you use one of the 'CoT' Disk Images, symlinks are automatically created in '/dev' that will allow you to identify each serial port:
- OpenUSB:
/dev/ttyOPENUSB - EZRUSB@433 MHz:
/dev/ttyEZR433 - EZRUSB@868 MHz:
/dev/ttyEZR868 - EFM32GG+LoRa:
/dev/ttyLORA
By referring to these symlinks instead of the /dev/ttyUSBX-devices directly you can be sure that you are talking to the correct device.
If you are not using one of the 'CoT' images, you can add the necessary udev-rules needed to to do by copying /etc/udev/rules.d/50-persistent-usb.rules from one of the 'CoT' images to your own image.
How can I flash/erase the EZRUSB devices ?
If you use one of the 'CoT' Disk Images, the EZRUSB devices can be programmed using the flash_ezr script.
This script can be invoked as follows:
flash_ezr <device> <elf-file>
Where:
<device>is one of 'EZR433' or 'EZR868', depending on whether you want to flash the 433MHz or 868MHz device<elf-file>is the ELF-image to flash to the device.
Likewise, the erase_ezr script can be used to erase an EZRUSB device. This script is invoked in exactly the same way as the flash_ezr script, except that no ELF-image file is specified.
Even if you are not using one of the 'CoT' images, you are strongly advised to use the flash_ezr and erase_ezr scripts since these scripts contain the logic required to ensure that the 'correct' device is flashed/erased.
You can add these scripts to your own image by simply copying them from the /usr/local/bin directory from one of the 'CoT'-images to your own image, but to run them OpenOCD (0.9.0 or later) does need to be installed.
How can I flash/erase the LoRa device ?
The 'LoRa' device is basically a Giant Gecko starter kit equipped with an RFM95W LoRa module. (See [Node Specifications]). This module is equipped with an on-board J-Link debugger, so debugging/programming/erasing this board is done in exactly the same way as it is for any other SiLabs MCU. (See here for the offical 'Getting Started' guides.
To make things a bit easier, all 'CoT' disk images already contain the necessary J-Link software as well as a few helper scripts.
Flashing the 'LoRa'-device can be done using the flash_lora script.
This script is invoked as follows:
flash_lora <device> <elf-file>
Where:
<elf-file>is the ELF-image to flash to the device.
Likewise, the erase_lora script can be used to erase the 'LoRa-'device. This script is invoked in exactly the same way as the flash_lora script, except that no ELF-image file is specified.
If you are not using one of the 'CoT'-images, you first need to install the J-Link Software And Documentation Pack for your specific operating system. Once this package is installed you can add the flash_lora and erase_lora scripts to your image to make flashing and erasing the device a bit easier. These scripts can be found in the /usr/local/bin directory in any of the 'CoT' disk images.
Miscellaneous
I have a question and I can't find the answer on the Wiki
Please send your question to . We'll be happy to help you along and update the documentation where necessary.