Difference between revisions of "FAQ"
| (34 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | == How do I get access to the testbed ? == | + | == Testbed Usage == |
| − | == | + | |
| − | == I can' | + | === How do I get access to the testbed ? === |
| − | == How do I know which serial interface (/dev/ttyUSBX) is connected to what device? == | + | |
| − | == How can I flash/erase the EZRUSB devices ? == | + | This is explained on the [[Getting Started]] page |
| − | == How can I flash/erase the LoRa device ? == | + | |
| − | == I have a question and I can't find the answer on the Wiki == | + | === Which default images are provided for the CityLab testbed ? === |
| − | Please send your question to {{SafeMailTo|admin| | + | |
| + | See the [[Disk Images]] page. | ||
| + | |||
| + | === Where can I find a list of which nodes are present/available in the Testbed === | ||
| + | |||
| + | * [[Nodes | Node Locations]] | ||
| + | * [https://doc.lab.cityofthings.eu/nodemap/ https://doc.lab.cityofthings.eu/nodemap/] | ||
| + | |||
| + | === When I create links between two nodes in the CityLab testbed in the JFed interface I either get an error or the link doesn't work === | ||
| + | |||
| + | At this point, the CityLab Testbed ''only'' supports ''gre-tunnel'' and ''egre-tunnel'' links between nodes. Moreover, the ''egre-tunnel'' link type only works with the 'CoT' disk images ([[GRE_Tunnels#EGRE-tunnels only work with 'CoT' disk images| more information]] here). | ||
| + | |||
| + | Starting from JFed 5.9, the ''gre-tunnel'' link type is automatically selected for you but this is not the case for older versions of JFed GUI. In that case you need to set the link type manually. More information on how to do this can be found [[GRE Tunnels#Creating Links between nodes through the JFed interface|here]] | ||
| + | |||
| + | === Can I create an L2 (Ethernet) link between two CityLab testbed nodes ? === | ||
| + | |||
| + | Yes, you can. Set the type of your link to ''egre-tunnel'' in JFed and an Ethernet-in-IP GRE tunnel will be automatically created (instead of an IP-in-IP GRE tunnel). Please note however that this will only work if you are using one of the provided 'CoT' disk images (see [[Disk Images]]). More information can be found [[GRE Tunnels#Creating Links between nodes through the JFed interface|here]]. | ||
| + | |||
| + | === Can I create a *native* Ethernet link between two CityLab testbed nodes ? === | ||
| + | |||
| + | Not at this point, but it is on the TODO list. | ||
| + | |||
| + | === 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 [[Getting_Started#Working around connectivity issues| 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 to the CityLab nodes. | ||
| + | |||
| + | === How can I create a custom disk image ? === | ||
| + | |||
| + | See: [http://doc.ilabt.iminds.be/ilabt-documentation/diskimage.html http://doc.ilabt.iminds.be/ilabt-documentation/diskimage.html] | ||
| + | |||
| + | === I have another JFed-related question === | ||
| + | |||
| + | Take a look at the [http://doc.ilabt.iminds.be/jfed-documentation-5.9/ 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 [https://doc.lab.cityofthings.eu/nodemap/ 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 [[GRE Tunnels#Creating a link between three or more nodes|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 [[GRE Tunnels#Reduced MTU|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 [http://doc.ilabt.iminds.be/ilabt-documentation/wilabfacility.html#w-ilab-2-setup w.iLab-2]), the nodes of the CityLab testbed are ''not'' connected to a dedicated 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''': <code>/dev/ttyOPENUSB</code> | ||
| + | * '''EZRUSB@433 MHz''': <code>/dev/ttyEZR433</code> | ||
| + | * '''EZRUSB@868 MHz''': <code>/dev/ttyEZR868</code> | ||
| + | * '''EFM32GG+LoRa''': <code>/dev/ttyLORA</code> | ||
| + | |||
| + | 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 <code>/etc/udev/rules.d/50-persistent-usb.rules</code> 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 <code>flash_ezr</code> script. | ||
| + | This script can be invoked as follows: | ||
| + | |||
| + | <code>flash_ezr <device> <elf-file></code> | ||
| + | |||
| + | Where: | ||
| + | * <code><device></code> is one of 'EZR433' or 'EZR868', depending on whether you want to flash the 433MHz or 868MHz device | ||
| + | * <code><elf-file></code> is the ELF-image to flash to the device. | ||
| + | |||
| + | Likewise, the <code>erase_ezr</code> script can be used to erase an EZRUSB device. This script is invoked in exactly the same way as the <code>flash_ezr</code> 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 <code>flash_ezr</code> and <code>erase_ezr</code> 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 <code>/usr/local/bin</code> 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 [https://www.silabs.com/products/development-tools/mcu/32-bit/efm32-giant-gecko-starter-kit starter kit] equipped with an RFM95W LoRa module. (See [[Node Specifications]]). This module is equipped with an on-board [https://www.segger.com/products/debug-probes/j-link/ 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 [https://www.silabs.com/support/getting-started/microcontrollers/efm32-mcu 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 <code>flash_lora</code> script. | ||
| + | This script is invoked as follows: | ||
| + | |||
| + | <code>flash_lora <bin-file></code> | ||
| + | Where: | ||
| + | * <code><bin-file></code> is the BIN-image to flash to the device. | ||
| + | |||
| + | '''Important''': the image needs to be in ''binary'' format (and not ELF). | ||
| + | |||
| + | Likewise, the <code>erase_lora</code> script can be used to erase the 'LoRa-'device. This script is invoked in exactly the same way as the <code>flash_lora</code> script, except that no BIN-image file is specified. | ||
| + | |||
| + | If you are not using one of the 'CoT'-images, you first need to install the '''[https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack J-Link Software And Documentation Pack]''' for your specific operating system. Once this package is installed you can add the <code>flash_lora</code> and <code>erase_lora</code> scripts to your image to make flashing and erasing the device a bit easier. These scripts can be found in the <code>/usr/local/bin</code> 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 {{SafeMailTo|admin|lab.cityofthings.eu}}. We'll be happy to help you along and update the documentation where necessary. | ||
Latest revision as of 07:54, 20 January 2020
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
When I create links between two nodes in the CityLab testbed in the JFed interface I either get an error or the link doesn't work
At this point, the CityLab Testbed only supports gre-tunnel and egre-tunnel links between nodes. Moreover, the egre-tunnel link type only works with the 'CoT' disk images ( more information here).
Starting from JFed 5.9, the gre-tunnel link type is automatically selected for you but this is not the case for older versions of JFed GUI. In that case you need to set the link type manually. More information on how to do this can be found here
Can I create an L2 (Ethernet) link between two CityLab testbed nodes ?
Yes, you can. Set the type of your link to egre-tunnel in JFed and an Ethernet-in-IP GRE tunnel will be automatically created (instead of an IP-in-IP GRE tunnel). Please note however that this will only work if you are using one of the provided 'CoT' disk images (see Disk Images). More information can be found here.
Can I create a *native* Ethernet link between two CityLab testbed nodes ?
Not at this point, but it is on the TODO list.
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 to the CityLab nodes.
How can I create a custom disk image ?
See: http://doc.ilabt.iminds.be/ilabt-documentation/diskimage.html
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 dedicated 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 <bin-file>
Where:
<bin-file>is the BIN-image to flash to the device.
Important: the image needs to be in binary format (and not ELF).
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 BIN-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.