Network Configuration

Figure 5: Overall network port configuration procedure.

Crimson TNG boasts three network ports. The Management port is used to configure the device and the two SFP+ ports are used to send data. The default Crimson TNG network values are listed in Table 1. An example of a known functioning client networking configuration is shown in Table 2. Figure 6 has the same information displayed differently.

The Management port is used to configure the device, while the two SFP+ ports are used to send data. Each SFP+ data port is connected to a specific antenna port. To properly configure Crimson TNG, each port must be properly configured.

Table 1: Default Crimson TNG Interface Addresses, Including UDP Destination Ports for SFP+ Headers.
SFP+ A SFP+ B MGMT
Crimson TNG IP Address 10.10.10.2 10.10.11.2 192.168.10.2
Radio Channels A, C B, D -
Destination IP (Rx) 10.10.10.10 10.10.11.10 -
Rx UDP Ports 42820, 42822 42821, 42823 -
Source IP (Tx) any any -
Tx UDP Ports 42824, 42826 42825, 42827 -
Table 2: Example Host Computer Network Configuration for Crimson TNG Default Settings
SFP+ A SFP+ B MGMT
Host IP Address 10.10.10.10/24 10.10.11.10/24 192.168.10.3/24
Net Mask 255.255.255.0 255.255.255.0 255.255.255.0
Broadcast 10.10.10.255 10.10.11.255 192.168.10.255
MTU 9000 9000 1500
Figure 6: Default networking set up for Crimson TNG.

The destination IP addresses for receive ports may be modified using the web GUI. The default configuration sees information from Rx A sent to the destination IP address of 10.10.10.10.

Networking on Linux

This section is most relevant for most (Arch/ Debian/ Ubuntu/ Kubuntu) based distros. As you go about connecting your Crimson TNG to the network, you might want to consider tuning some of your network stack parameters.

Management IP Address

The Management port allows you to configure Crimson TNG through the web user interface. In order to access the web UI, you will need to configure your host IP address to share the same sub net (setting your machine to an IP of 192.168.10.4, and net mask of 255.255.255.0 should work), and then type the IP address into the browser; 192.168.10.2. This will bring up the default connection screen for Crimson TNG, as shown in below.

Note

You can reconfigure the ip address and host name by clicking on the «config» tab of the home page.

Note

You can also ssh into Crimson TNG with user name root. By default, there is no password set up.

Figure 7: Home page of Crimson TNG Web UI, accessible through connection to the management port.

Host IP address

Assign a static IP address in the console:

$ ip addr add XXX.XXX.XXX.XXX/YY broadcast ZZZ.ZZZ.ZZZ.ZZZ dev
<interface>

For example:

$ ip addr add 192.168.10.3/24 broadcast 192.168.10.255 dev eth0

To confirm that the network interface is enabled, type ip addr show. The following output is an example of what should appear indicating the link is up:

$ ip addr show

1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq
state UP group default qlen 1000 link/ether NN:NN:NN:NN:NN:NN brd
ff:ff:ff:ff:ff:ff

Now that you know the network interface is up, you can confirm that you have properly configured the Management IP address by pinging the MGMT port on Crimson TNG:

$ ping 192.168.10.2

PING 192.168.10.2 (192.168.10.2)56(84) bytes of data

64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=0.997 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=1.04 ms

...

SFP+ IP Addresses

Assuming that the 10GBASE-R network card has already been installed into your host computer, the following instructions will guide you in properly configuring the SFP+ ports. From here, we will assume that the SFP+ port A is named XXXNXY. The IP address for this port will need to be configured to 10.10.10.10.

Assign a static IP address in the console:

$ ip addr add XXX.XXX.XXX.XXX/YY broadcast ZZZ.ZZZ.ZZZ.ZZZ dev
<interface>

For example:

$ ip addr add 10.10.10.10/24 broadcast 255.255.255.0 dev XXXNXY

Next, set the MTU. This is an important step; without properly setting the MTU, transmission will not work properly.

$ ip link set dev XXXNXY mtu 9000

Type ip addr show into the console and the following output should appear to indicate that the link is up:

5: XXXNXY: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq
state UP group default qlen 1000 link/ether 6c:b3:11:3b:44:3d brd
ff:ff:ff:ff:ff:ff

Note

In most linux distributions the default TCP buffer size for sending and receiving packets is 128KB. To transmit and receive at higher speeds, we can decerease the latency in our system by setting the buffer size. To do this, we will need to alter the values for rmem_max and wmem_max.

This can be done as follows: bash $ sudo sysctl -w net.core.wmem_max=262144 $ sudo sysctl -w net.core.rmem_max=50000000

You can confirm the values are set by running the same command without the -w flag

Ping the Crimson TNG SFP+ port A address 10.10.10.2 to ensure proper operation:

$ ping 10.10.10.2

PING 10.10.10.2 (10.10.10.2) from 10.10.10.10 XXXNXY: 56(84)
bytes of data.

64 bytes from 10.10.10.2: icmp_seq=1 ttl=5 time=0.922 ms

64 bytes from 10.10.10.2: icmp_seq=2 ttl=5 time=1.03 ms

...

To configure SFP+ port B, repeat the instructions for SFP+ port A using the SFP+ port B IP addresses shown in Table 1. Remember to configure the correct device interface on your host computer.

Networking on Windows

The following describes the generic method of changing your IP address using a Windows machine.

  1. Go to Control Panel
  2. View Network Connections
  3. Right click on Local Area Connection and click on Properties
  4. Under the Networking tab select Internet Protocol Version 4 (TCP/IPv4) and click on Properties
  5. Select «Use the following IP address»
  6. Populate the IP address and subnet mask as described above
  7. Click OK

To confirm that you have successfully configured the Management port, type 192.168.10.2 into your web browser. If you have successfully configured the IP, you will be taken to the Crimson TNG web UI.

Verifying the setup

Testing the Management IP address

Prior to, and immediately after, making any changes to the IP address, you should test to ensure that communication to the device, and management port, is working properly. The best way to do this is to run a test sequence that attempts to ping the management port, is able to access the website on the management IP address, is able to successfully execute uhd_find_devices, and uhd_usrp_probe, and then tests the entire chain by running a simple gnuradio script.

The following tests are all completed from the host computer. This also serves to ensure that your host computer is correctly configured to access the device - just because you have correctly configured Crimson TNG, does not mean that you have correctly configured the host PC to communicate with Crimson TNG.

Ping test

This is the most basic test and serves to check if a route exists between your host computer and the specified IP address. Assuming the management IP address is W.X.Y.Z, then you can run this test by typing;

[host_pc]$ ping W.X.Y.Z -c 3

The output from a successful test, and the output from a failed test are both displayed below.

PING W.X.Y.Z (W.X.Y.Z) 56(84) bytes of data.
64 bytes from W.X.Y.Z: icmp_seq=1 ttl=64 time=0.912 ms
64 bytes from W.X.Y.Z: icmp_seq=2 ttl=64 time=0.917 ms
64 bytes from W.X.Y.Z: icmp_seq=3 ttl=64 time=0.917 ms

--- W.X.Y.Z ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2.746ms
rtt min/avg/max/mdev = 0.912/0.915/0.917/0.019 ms

Expected output from a failed ping test. In this figure, A.B.C.D is the IP address of the HOST PC interface used to send the request, and W.X.Y.Z, is the management IP address being tested. This result indicated that you are unable to reach the specified IP address. Check to ensure you are using the correct IP address on the host machine, that this IP address shares a netmask with the target Crimson TNG machine, and that you have correctly configured your host machine interface prior to continuing.

The output from a successful test should look similar to the following;

PING W.X.Y.Z (W.X.Y.Z) 56(84) bytes of data.
From A.B.C.D icmp_seq=1 Destination Host Unreachable
From A.B.C.D icmp_seq=2 Destination Host Unreachable
From A.B.C.D icmp_seq=3 Destination Host Unreachable

--- W.X.Y.Z ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss,
time 2013ms

Website test

The following test is used to determine whether you can access the website. This is helpful in ensuring that the IP address you are attempting to reach is, in fact, a Crimson TNG device. To run this test, simply open a browser, and attempt to access the website by typing in the management IP address.

If you are able to successfully access the website, then you have connected with a Crimson TNG device.

If you are unable to access the website, then double check to ensure that you have correctly specified the management IP address, or that your netmask is correctly assigned.

uhd_find_devices, uhd_usrp_probe tests

This is the first test to determine whether UHD is capable of finding the Crimson TNG device. It’s worth running this test twice; the first time by specifying the management IP address, and the second time without. In a correct configuration, with a single Crimson TNG device, you should be able to automatically find the device without specifying the address.

To run this test, and assuming the management IP address is W.X.Y.Z, type the following;

[host_pc]$ uhd_find_devices --args 'addr=W.X.Y.Z'

The output from a failed test will show the following output:

Linux; GNU C++ version 6.3.1 20170306; Boost_106300;
UHD_003.008.000-382-gef596087

--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: crimson_tng
addr: W.X.Y.Z
name:
serial: 001

This is an indication that UHD is unable to detect your radio. When this happens, the first thing to check is the wiring: make sure the device is plugged in correctly.

The output from a successful uhd_find_devices test test will show the following output:

Linux; GNU C++ version 6.3.1 20170306; Boost_106300;
UHD_003.008.000-382-gef596087

No UHD Devices Found

Expected output from a failed uhd_find_devices ping test: no UHD device was found, indicating that the network configuration does not work.

Linux; GNU C++ version 6.3.1 20170306; Boost_106300;
UHD_003.008.000-382-gef596087

Error: LookupError: KeyError: No devices found for ----->
Device Address:
addr: 192.168.10.2

Expected output from a failed uhd_usrp_probe test. No UHD device was found at the specified address, indicating that the network configuration does not work.

Modifying Crimson TNG Management IP Address

This procedure is broken down into three distinct sections: Adding the new IP address, removing the old one, and then making the modifications persistent. This is a bad section in which to try and take short-cuts: if you make a mistake, you’ll need to either mount the SD card file system on another computer to try and fix your changes, or else use a new SD card.

Warning

Laboratory Use Only READ THIS SECTION CAREFULLY Read section very carefully prior to changing device IP address. Failure to follow instructions may render your device unreachable, and may require you to manually edit the SD card file system or make a new SD card.

Add New Management IP address

Make sure that you’ve already configured the host IP address, following the instructions above. This will ensure that once you update Crimson TNG, you’ll be able to communicate with it.

To temporarily add a new IP address, SSH into crimson, and then add the new IP address using the IP tool;

[dev0@crimson]$ sudo ip addr add Y.Y.Y.Y/ZZ dev eth0

Then, log out of crimson, and, without powering down the unit, test to confirm that the new IP address works, and that your host can communicate. The best test series is to first attempt to ping the new management port, then to run uhd_find_devices, and uhd_usrp_probe, and then to run a simple gnuradio script that is known to work - and ensuring that you have also applied your final, intended, configuration on the host computer as well.

Removing Management IP address

Warning

Laboratory Use Only CAREFULLY TEST CHANGES TO NETWORK PARAMETERS, AND ENSURE FUNCTIONALITY, PRIOR TO MAKING THESE CHANGES PERSISTENT ACROSS REBOOTS Consider whether it is feasible to only add the new interface settings to Crimson TNG, without removing the existing interface. This provides a fall back mechanism to access the device in the event you misconfigure the interface, and helps avoid incorrectly configuring Crimson, thereby ensuring consistent operation.

To remove the default management IP address, first ADD the new one using the procedure above. Then, log out of crimson, and SSH back in, using the NEW ip address. This will prevent your session from being terminated once you delete the old address.

To delete the old address on Crimson TNG, we can again use the IP address tool;

[dev0@crimson]$ sudo ip addr del W.W.W.W/XX dev eth0

Again, log out of the machine, and ensure that you can ping the device, that the website is reachable, and that you can use uhd_usrp_probe and uhd_find_devices.

If you are unable to reach the website, or run any scripts, then STOP here and FIX the problem. At this point, your Crimson TNG device is effectively configured with the new address, but the change is not persistent. This means that if you have to debug problems, do so now.

Persistently Update Management IP address

Warning

Laboratory Use Only CAREFULLY TEST CHANGES TO NETWORK PARAMETERS, AND ENSURE FUNCTIONALITY, PRIOR TO MAKING THESE CHANGES PERSISTENT ACROSS REBOOTS Carefully test network settings, using the previously described procedures to temporarily set and remove IP address, prior to making those changes persistent. If you are not able to get the configuration working temporarily, then persistently applying these settings across reboots, shall prevent communication with Crimson TNG.

To ensure that the new IP address is persistent across reboots, SSH into Crimson TNG, and modify the file located at: /etc/network/interfaces

Make sure that you have tested ALL configuration settings PRIOR to writing them to this file. If you weren’t able to get your configuration working temporarily, using the previous two instructions, than making them persistent across reboots SHALL NOT work. Making a broken configuration persistent will only serve to rebooting the device to undo your changes and fix any earlier mistakes. Once you write to this file, the changes will be applied on the next reboot.

Now that your connected to the network, we can setup the software you will need to interface with your radio.

Footnotes