Difference between revisions of "Troubleshooting N310/N320 Device Discovery Issues"
(→Revision History) |
|||
(121 intermediate revisions by the same user not shown) | |||
Line 8: | Line 8: | ||
!Details | !Details | ||
|- | |- | ||
− | |style="text-align:center;"| | + | |style="text-align:center;"| 2020-01-23 |
|style="text-align:center;"| Sam Reiter | |style="text-align:center;"| Sam Reiter | ||
|style="text-align:center;"| Initial creation | |style="text-align:center;"| Initial creation | ||
Line 14: | Line 14: | ||
==Introduction== | ==Introduction== | ||
− | + | This guide will serve as a troubleshooting guide for users who have run into N3xx connectivity / device discovery issues while following the [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide USRP N3xx Getting Started Guide]. If you haven't seen the getting started guide up to this point, you should start there. | |
− | + | There are several methods of connecting a USRP N3xx device to a host PC (MGMT Ethernet, Serial, SFP+, and QSFP+), the troubleshooting of which are covered in this guide. We will be using a Linux machine (Ubuntu 19.10) for the following steps, but the troubleshooting steps can be generalized across other operating systems. While this guide is applicable to N300, N310, N320, and N321, several of the sections will be applicable to E3xx devices as well. | |
==Aligning Software Versions on Host and USRP== | ==Aligning Software Versions on Host and USRP== | ||
− | On MPM-based devices, like the N3xx, there are several pieces of software that need to be version-aligned to allow for communication. | + | On MPM-based devices, like the N3xx, there are several pieces of software that need to be version-aligned to allow for communication. Irrespective of your connectivity issues, start your troubleshooting by completing this list: |
+ | <OL> | ||
+ | <LI>Install UHD on the Host Machine (required to interface with N3xx and to download FPGA images) | ||
<UL> | <UL> | ||
− | + | <LI>'''Linux (source): ''' [https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux] | |
− | + | <LI>'''Windows (binaries): ''' https://files.ettus.com/binaries/uhd/ | |
− | + | </UL> | |
+ | <LI>Install the same version of UHD on the N3xx | ||
+ | <UL> | ||
+ | <LI>'''Option 1:''' [https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card Writing the USRP File System Disk Image to a SD Card] | ||
+ | <LI>'''Option 2:''' [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_file_system_with_Mender Updating the N3xx file system with Mender] | ||
+ | <UL> | ||
+ | <LI> Note: you will have to establish communication over Ethernet/*SFP+ to update the N3xx file system using Mender | ||
+ | </UL> | ||
+ | </UL> | ||
+ | <LI> Install the corresponding version of MPM on the N3xx | ||
+ | <UL> | ||
+ | <LI>This is taken care of by completing the N3xx filesystem update above. Skip if you completed steps 1 and 2. | ||
+ | <LI>'''Update MPM only:''' [https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_mpm_native Compiling MPM Natively] | ||
+ | <UL> | ||
+ | <LI> Note: you will have to establish communication over Ethernet/*SFP+ to compile MPM on the N3xx | ||
+ | </UL> | ||
+ | </UL> | ||
+ | <LI>Update the FPGA on the N3xx | ||
+ | <UL> | ||
+ | <LI> '''UHD Manual:''' [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_fpga_update Updating the FPGA] | ||
+ | <LI> '''KB Page:''' [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_FPGA_Image Embedded and Network Mode FPGA update instructions] | ||
+ | <UL> | ||
+ | <LI> Note: This is required for streaming, but you will have to establish communication before you can update the FPGA. | ||
+ | </UL> | ||
+ | </UL> | ||
+ | </OL> | ||
− | + | ==MGMT Port Ethernet Connection== | |
− | + | Getting Started Guide Page: [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH Connecting to the ARM via SSH] | |
− | + | ||
− | + | USRP Manual Page: [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_ssh N3xx Getting Started SSH] | |
− | + | N3xx devices all have an RJ45 port intended for communications with the device. This interface is called the management (mgmt) port and is suitable for SSH, file transfer, and device discovery, but '''not''' CHDR packet streaming (including <code>uhd_usrp_probe</code>): | |
− | + | ||
− | + | ||
− | + | ||
− | + | <center> | |
− | + | <div><ul> | |
− | + | <li style="display: inline-block;"> [[File:N310 back mgmt.png|thumb|1000px|center|Figure 1: N310 Rear Panel with MGMT port emphasized.]] </li> | |
+ | </ul></div> | ||
+ | </center> | ||
+ | <OL> | ||
+ | <LI> <u>Issue: The N3xx doesn't check out a DHCP address from my </u><code>dnsmasq</code><u> server</u> | ||
+ | <UL> | ||
+ | <LI> Ensure your USRP is powered on. | ||
+ | <LI> Ensure your host network and dnsmasq server are configured correctly: | ||
+ | <UL> | ||
+ | <LI> Host interface must be configured for a static connection. A subnet of <code>255.255.255.0</code> is recommended. | ||
+ | <LI> Make sure you're specifying the appropriate host interface in <code>-i <ETHERNET_ADAPTER_NAME></code>. Available interfaces can be found by running <code>ip a</code> on a host machine. | ||
+ | <LI> Make sure the first 3 octets of your <code>--dhcp-range <LOWER IP>-<UPPER IP></code> match the first 3 octets of your interface's static IP (assuming you're using the subnet <code>255.255.255.0</code>). | ||
</UL> | </UL> | ||
+ | <LI> For network changes to take effect, it's often necessary to reset the network interface. This can be done by physically disconnecting the Ethernet cable from the host's RJ45 port. | ||
+ | <LI> Try using a new Ethernet cable. | ||
+ | <LI> If the N3xx still won't check out an IP, try connecting it to an existing network (company wired network, router RJ45 port, etc.). From here, you can [https://vitux.com/find-devices-connected-to-your-network-with-nmap/ search your network with nmap] to discover the device. If this is successful, consult the [http://manpages.ubuntu.com/manpages/bionic/man8/dnsmasq.8.html dnsmasq man page] to correct your configuration. | ||
+ | <LI> If communication with the MGMT port is still unsuccessful, try connecting via Serial Console (below). From there, you can investigate <code>/etc/systemd/network/eth0.network</code> to ensure it has the [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations correct default settings]. | ||
+ | </UL> | ||
+ | </OL> | ||
− | = | + | <OL start="2"> |
+ | <LI> <u>Issue: I am unable to SSH into the device using the MGMT Port</u> | ||
<UL> | <UL> | ||
− | + | <LI> Ensure your USRP has successfully checked out an IP from your <code>dnsmasq</code> server. Use this IP to <code>ssh root@<N3xx_DHCP_IP></code> | |
− | + | <LI> If you are given a notice about host identification (see example below), follow the instructions to remove given by ssh <code>ssh-keygen -f "/home/$USER/.ssh/known_hosts" -R "<N3XX_IP>"</code> | |
+ | <pre> | ||
+ | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | ||
+ | @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ | ||
+ | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | ||
+ | IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! | ||
+ | Someone could be eavesdropping on you right now (man-in-the-middle attack)! | ||
+ | It is also possible that a host key has just been changed. | ||
+ | The fingerprint for the ECDSA key sent by the remote host is | ||
+ | SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. | ||
+ | Please contact your system administrator. | ||
+ | Add correct host key in /home/$USER/.ssh/known_hosts to get rid of this message. | ||
+ | Offending ECDSA key in /home/$USER/.ssh/known_hosts:13 | ||
+ | remove with: | ||
+ | ssh-keygen -f "/home/$USER/.ssh/known_hosts" -R "192.168.1.234" | ||
+ | ECDSA host key for <N3XX_IP> has changed and you have requested strict checking. | ||
+ | Host key verification failed. | ||
+ | </pre> | ||
+ | <LI> If you are still unable to ssh into a device that has checked out an IP address, try uninstalling and reinstalling <code>ssh</code> on your machine | ||
</UL> | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="3"> | ||
+ | <LI> <u>Issue: </u><code>uhd_find_devices</code><u> doesn't return or returns:</u> | ||
+ | <pre>No UHD Devices Found</pre> | ||
+ | <UL> | ||
+ | <LI> Ensure your USRP is powered on and has checked out an IP address from your <code>dnsmasq</code> instance. | ||
+ | <LI> Ping the N3xx's checked out IP address with <code>ping <N3xx_DHCP_IP></code>. If this ping is unsuccessful, check your network restrictions / firewall. | ||
+ | <LI> Specify "--args type=n3xx,mgmt_addr=<N3xx_DHCP_IP>". If this works but vanilla <code>uhd_find_devices</code> didn't, you likely need to enable broadcast packets on your network. | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="4"> | ||
+ | <LI> <u>Issue: </u><code>uhd_usrp_probe</code><u> returns "No Devices Found"</u> | ||
+ | <UL> | ||
+ | <LI> This is expected behavior when only connected over the MGMT Ethernet interface. Connect to the device over a SFP+ or QSFP+ port to enable CHDR Packet interfacing. | ||
+ | </UL> | ||
+ | </OL> | ||
==Serial Connection== | ==Serial Connection== | ||
+ | Getting Started Guide Page: [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Setting_up_a_Serial_Console_Connection Setting up a Serial Console Connection] | ||
+ | |||
+ | USRP Manual Page: [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_serial N3xx Getting Started Serial Console] | ||
+ | |||
+ | N3xx devices all have an serial console port intended for communications with the ARM or the SMT32 MCU. This interface is suitable for remote device access and MCU log monitoring. | ||
+ | |||
+ | <center> | ||
+ | <div><ul> | ||
+ | <li style="display: inline-block;"> [[File:N310 back serial.png|thumb|1000px|center|Figure 1: N310 Rear Panel with serial port emphasized.]] </li> | ||
+ | </ul></div> | ||
+ | </center> | ||
+ | |||
+ | <OL> | ||
+ | <LI> <u>Issue: When connecting to the N3xx with </u><code>screen</code><u>, the following error returns:</u> | ||
+ | <pre>No such file or directory</pre> | ||
<UL> | <UL> | ||
− | + | <LI> Ensure that the symlink you're using is specific to your machine by copying the output from <code>ls /dev/serial/by-id</code>. Your symlink will be unique , meaning that you can '''not''' copy the command <code>sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200</code> verbatim from the KB. | |
− | + | <LI> Use <code>ls /dev/serial/by-id</code> to enumerate available N3xx serial nodes. If this directory does not exist, your serial cable is likely bad or unplugged - this directory is created when your N3xx is connected to the PC. Try an unplug/replug cycle or a new cable. | |
</UL> | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="2"> | ||
+ | <LI> <u>Issue: When connecting to the N3xx over serial I do not get a prompt to log into the device</u> | ||
+ | <UL> | ||
+ | <LI> Ensure that the node you're connecting to is <code>usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_<UNIQUE_ID>-if01-port0</code> | ||
+ | <LI> If you see a blank terminal with a blinking cursor, hit <code>Enter</code> to progress to the prompt. If <code>Enter</code> does nothing, you've connected to the wrong node. | ||
+ | <LI> If you see continuously printing debug lines (similar to the example below), you are connected to the MCU. Use the <code>...-if01-..</code> node referenced in the first bullet of this list to connect to the ARM. | ||
+ | <pre> | ||
+ | +++(++)[1819115.512968 HC 0x21] | ||
+ | +++(++)[1819116.551227 HC 0x21] | ||
+ | +++(++)[1819116.790476 HC 0x07] | ||
+ | [1819116.791563 HC 0x21] | ||
+ | ++[1819117.589498 HC 0x21] | ||
+ | +++(++)[1819118.627901 HC 0x21] | ||
+ | +++(++)[1819119.666264 HC 0x21] | ||
+ | +++(++)[1819120.704714 HC 0x21] | ||
+ | </pre> | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="3"> | ||
+ | <LI> <u>Issue: When connecting to the N3xx over serial I get a notice about partial or dropped output</u> | ||
+ | <UL> | ||
+ | <LI> Ensure that your screen session was opened with <code>115200</code> at the end of the command. This sets the Baud rate and should not be omitted | ||
+ | <LI> Try a different USB-A -> Micro-USB cable | ||
+ | <LI> Try a different USB port on your host machine | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="4"> | ||
+ | <LI> <u>Issue: When connecting to the N3xx over serial my login / password results in:</u> | ||
+ | <pre>Login incorrect</pre> | ||
+ | or | ||
+ | <pre>Sorry, try again.</pre> | ||
+ | <UL> | ||
+ | <LI> Ensure that you are actually being asked for the password for the N3xx. You are required to run <code>screen</code> as root and will be prompted for your host machine's password before the N3xx's password. | ||
+ | <LI> If you have forgotten or lost the password for your N3xx (default login: <code>root</code>, default password: <code><BLANK></code>), the only solution we can offer is to reformat your SD card. Ettus Research can not help you bypass this password. | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="5"> | ||
+ | <LI> <u>Issue: </u><code>uhd_find_devices</code><u> doesn't return or returns:</u> | ||
+ | <pre>No UHD Devices Found</pre> | ||
+ | <UL> | ||
+ | <LI> This is expected behavior. You must use a valid Ethernet interface to communicate with the N3xx with UHD. | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | <OL start="6"> | ||
+ | <LI> <u>Issue: </u><code>uhd_usrp_probe</code><u> returns "No Devices Found"</u> | ||
+ | <UL> | ||
+ | <LI> This is expected behavior. Connect to the device over a SFP+ or QSFP+ port to enable CHDR Packet interfacing. | ||
+ | </UL> | ||
+ | </OL> | ||
==SFP+ Connection== | ==SFP+ Connection== | ||
− | The | + | The N3xx has a pair of SFP+ ports located on the rear panel of the device. These interfaces are labeled 0 and 1: |
<center> | <center> | ||
<div><ul> | <div><ul> | ||
− | <li style="display: inline-block;"> [[File: | + | <li style="display: inline-block;"> [[File:N310_back_SFP_.png|thumb|1000px|center|N310 with SFP+ ports emphaized]] </li> |
</ul></div> | </ul></div> | ||
</center> | </center> | ||
− | It is possible to connect to the | + | In general, it is recommended that you start off by connecting via either MGMT Ethernet or Serial before setting up streaming over the SFP+ or QSFP+ ports. It is possible to connect to the N3xx over 1 Gigabit Ethernet via an SFP+ to RJ45 adapter or a 10 Gigabit Ethernet-capable SFP+ cable. Whether or not your N3xx device is capable of using 1GbE is dependent on the FPGA image being used. With the HG image, port 0 is 1GbE and port 1 is 10GbE. Using the XG image enables dual-10GbE-links (ports 0 and 1). See the [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_fpga_update UHD Manual] for instructions regarding updating the FPGA image of your device. |
+ | |||
+ | <center> | ||
+ | <div><ul> | ||
+ | <li style="display: inline-block;"> [[File:N3xx flavors.png|thumb|600px|center|Example of N3xx port assignments by FPGA version]] </li> | ||
+ | </ul></div> | ||
+ | </center> | ||
===1 Gigabit Ethernet (1GbE)=== | ===1 Gigabit Ethernet (1GbE)=== | ||
− | This protocol is supported only on | + | This protocol is supported only on N3xx SFP+ port 0 when using the HG / HA FPGA image. If both of these conditions are met, you will see the green LINK LED illuminate when a working SFP+ adapter is inserted into the powered-on N3xx. On N3xx devices, this LED should light up regardless of successful connection to host when a working SFP+ adapter is inserted. |
<center> | <center> | ||
<div><ul> | <div><ul> | ||
− | <li style="display: inline-block;"> [[File: | + | <li style="display: inline-block;"> [[File:N310 SFP only.png|thumb|200px|center|Figure 2: N310 SFP+ ports with link and data LEDs.]] </li> |
</ul></div> | </ul></div> | ||
</center> | </center> | ||
− | <OL> | + | |
− | <LI> <u>Issue: Ethernet LINK LED (Port 0) does not illuminate</u> | + | <OL start="1"> |
+ | <LI> <u>Issue: Ethernet LINK LED (Port 0) does not illuminate when an SFP+ -> RJ45 </u> | ||
<UL> | <UL> | ||
<LI> Ensure your USRP is powered on. | <LI> Ensure your USRP is powered on. | ||
<LI> If the green LINK LED does not illuminate in port 0, you should try a different (known working) SFP+ adapter. | <LI> If the green LINK LED does not illuminate in port 0, you should try a different (known working) SFP+ adapter. | ||
− | <LI> If a known good SFP+ adapter does not elicit a green LINK LED, you should | + | <LI> If a known good SFP+ adapter does not elicit a green LINK LED, you should flash the FPGA using the HG image. Connect to the device over the MGMT Ethernet interface and update the FPGA: [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_FPGA_Image N3xx: Updating the FPGA Image] |
− | <LI> If | + | <LI> If the FPGA recovery doesn't complete successfully or recovery doesn't bring back the link LED, reflash your SD Card and try the FPGA flash again. |
+ | <LI> If these steps don't elicit a green link LED, contact Ettus Support. | ||
</UL> | </UL> | ||
</OL> | </OL> | ||
− | |||
− | |||
<OL START="2"> | <OL START="2"> | ||
<LI> <u>Issue: Host PC is unable to ping the USRP</u> | <LI> <u>Issue: Host PC is unable to ping the USRP</u> | ||
<UL> | <UL> | ||
− | <LI> Ensure your USRP is powered on. Ensure your host network settings are correct. See [https://files.ettus.com/manual/ | + | <LI> Ensure your USRP is powered on. |
− | <LI> Ensure host is connected directly to the | + | <LI> Ensure your host network settings are correct. See [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_connectivity USRP Manual: N3xx Network Connectivity]. The host NIC must have an appropriate IP address and subnet mask for the N3xx interface you are connecting to. Note that many systems require a user to unplug/replug the ethernet interface for configuration changes to take effect. |
− | <LI> Use | + | <LI> Ensure host is connected directly to the N3xx. Eliminate all routers and switches in between USRP and host machine. (**Note on this at the end of this list) |
− | < | + | <LI> Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in <code>/etc/systemd/network/</code> |
− | <LI> Replace your RJ45 cable and repeat | + | <LI> Replace your RJ45 cable and repeat the above steps for this issue. |
− | <LI> Some communication issues have been observed with specific Linux distros (Kubuntu is one example) '''requiring''' a network switch between Host and USRP - adding an intermediate switch is worth exploring in the event other steps in this were unsuccessful. | + | <LI> **Some communication issues have been observed with specific Linux distros (Kubuntu is one example) '''requiring''' a network switch between Host and USRP - adding an intermediate switch is worth exploring in the event other steps in this were unsuccessful. |
− | <LI> If you are still unable to ping your | + | <LI> If you are still unable to ping your N3xx, contact Ettus support. |
</UL> | </UL> | ||
</OL> | </OL> | ||
− | If you're able to ping the device, then you have successfully connected to it. At this point, it is recommended to run uhd_usrp_probe to pull device information. If your FPGA image is not consistent with your version of UHD on the host side, you may get errors or warnings regarding FPGA | + | <OL START="3"> |
+ | <LI> <u>Issue: SFP0 does not appear when I run <code>ip a</code> from the N3xx's ARM</u> | ||
+ | <UL> | ||
+ | <LI> Ensure your N3xx SFP0 is correctly configured in <code>/etc/systemd/network/sfp0.network</code>. | ||
+ | <LI> Ensure that you are using the HG image. In FPGA images like WG, SFP0 is reserved for white rabbit timing functionality. See [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_FPGA_Image N3xx: Updating the FPGA Image] | ||
+ | <LI> Flash a fresh filesystem onto the N3xx's SD card. | ||
+ | </UL> | ||
+ | </OL> | ||
+ | |||
+ | If you're able to ping the device over the SFP+ port, then you have successfully connected to it. At this point, it is recommended to run uhd_usrp_probe to pull device information over this interface. If your FPGA image is not consistent with your version of UHD on the host side, you may get errors or warnings regarding FPGA versioning. See the [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_fpga_update USRP Manual: Updating the FPGA] section. | ||
===10 Gigabit Ethernet (10GbE)=== | ===10 Gigabit Ethernet (10GbE)=== | ||
Line 112: | Line 275: | ||
<LI> Ensure your USRP is powered on. | <LI> Ensure your USRP is powered on. | ||
<LI> Ensure the SFP+ cable is plugged into port 1 of the USRP. This is a 10 Gig interface on both the HG and XG images. | <LI> Ensure the SFP+ cable is plugged into port 1 of the USRP. This is a 10 Gig interface on both the HG and XG images. | ||
− | <LI> If your host machine is using a PCIe | + | <LI> Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in <code>/etc/systemd/network/</code>. Verify that your IP address and subnet mask are compatible between host and USRP. |
+ | <LI> If your host machine is using a PCIe NIC with SFP+ interfaces, ensure the NIC was enumerated correctly by your operating system with <code>sudo lshw</code>. You may need to reinstall drivers or try a different PCIe port on your host machine. | ||
<LI> Check that the SFP+ interface on your host machine is configured to support a 10 Gigabit link. If your NIC supports dual 10 GbE links, you can put it in loopback with your SFP+ cable and confirm that both ports recognize a 10GbE connection: | <LI> Check that the SFP+ interface on your host machine is configured to support a 10 Gigabit link. If your NIC supports dual 10 GbE links, you can put it in loopback with your SFP+ cable and confirm that both ports recognize a 10GbE connection: | ||
<center> | <center> | ||
<div><ul> | <div><ul> | ||
− | <li style="display: inline-block;"> [[File:Ethernet_toggle.png|thumb|600px|center|Figure 3: Ubuntu | + | <li style="display: inline-block;"> [[File:Ethernet_toggle.png|thumb|600px|center|Figure 3: Ubuntu Network Manager with 2 10GbE interfaces in loopback]] </li> |
</ul></div> | </ul></div> | ||
</center> | </center> | ||
− | <LI> Swap your cable for a different (known good SFP+ to SFP+ cable | + | <LI> Swap your cable for a different (known good) SFP+ to SFP+ cable. |
− | <LI> If a known good SFP+ cable connected to a known working SFP+ port does not elicit a green LINK LED, you should attempt | + | <LI> If a known good SFP+ cable connected to a known working SFP+ port does not elicit a green LINK LED, you should attempt an N3xx FPGA update with the XG image. Connect to the N3xx over the MGMT interface and see: [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_FPGA_Image N3xx Getting Started: Updating the FPGA]. With the XG image, try the above steps on Port 0 of your N3xx. |
− | <LI> If | + | <LI> If the FPGA recovery doesn't complete successfully or recovery doesn't bring back the link LED, reflash your SD Card and try the FPGA flash again. |
</UL> | </UL> | ||
</OL> | </OL> | ||
− | Once the device has a successful 10GbE connection to the host, the host machine should be able to ping the radio using a | + | Once the device has a successful 10GbE connection to the host, the host machine should be able to ping the radio using a <code>ping <N3xx Port 1 IP address></code> command. |
<OL START="2"> | <OL START="2"> | ||
<LI> <u>Issue: Host PC is unable to ping the USRP</u> | <LI> <u>Issue: Host PC is unable to ping the USRP</u> | ||
<UL> | <UL> | ||
− | <LI> Ensure your USRP is powered on | + | <LI> Ensure your USRP is powered on. |
− | <LI> | + | <LI> Ensure your host network settings are correct. See [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_connectivity USRP Manual: N3xx Network Connectivity]. The host NIC must have an appropriate IP address and subnet mask for the N3xx interface you are connecting to. Note that many systems require a user to unplug/replug the ethernet interface for configuration changes to take effect. |
+ | <LI> Ensure host is connected directly to the N3xx. Eliminate all routers and switches in between USRP and host machine. (**Note on this at the end of this list) | ||
+ | <LI> Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in <code>/etc/systemd/network/</code>. Verify that your IP address and subnet mask are compatible between host and USRP. | ||
+ | <LI> **Some communication issues have been observed with specific Linux distros (Kubuntu is one example) '''requiring''' a network switch between Host and USRP - adding an intermediate switch is worth exploring in the event other steps in this were unsuccessful. | ||
+ | <LI> If you are still unable to ping your N3xx, contact Ettus support. | ||
+ | </UL> | ||
+ | </OL> | ||
+ | If you're able to ping the device, then you have successfully connected to it. At this point, it is recommended to run uhd_usrp_probe to pull device information. If your FPGA image is not consistent with your version of UHD on the host side, you may get errors or warnings regarding FPGA version numbers. See the [https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_fpga_update_flavors USRP Manual: Updating the FPGA section]. | ||
+ | |||
+ | ==QSFP+ Connection== | ||
+ | The N320 and N321 devices are equipped with a QSFP+ port: | ||
<center> | <center> | ||
<div><ul> | <div><ul> | ||
− | <li style="display: inline-block;"> [[File: | + | <li style="display: inline-block;"> [[File:USRP N321 Back QSFP.jpeg|thumb|800px|center|Figure 1: N310 Rear Panel with serial port emphasized.]] </li> |
</ul></div> | </ul></div> | ||
</center> | </center> | ||
+ | At the time of this application note's creation, no unique troubleshooting steps have been identified for the QSFP+ port. See the steps recommended for the SFP+ ports. | ||
− | + | If you encounter a connectivity issue not resolved by the SFP+ section of this document, please contact support@ettus.com | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
+ | ==Miscellaneous Notes== | ||
+ | Early runs of the N300 and N310 had a firmware bug that resulted in intermittent issues with power button response. This can often be bypassed by issuing the command "powerbtn" over the serial console to the ARM. Reach out to support@ettus.com for instructions on downloading and installing the patch. | ||
==Additional Resources== | ==Additional Resources== | ||
<UL> | <UL> | ||
− | <LI> [https://files.ettus.com/manual/ | + | <LI> [https://files.ettus.com/manual/page_usrp_n3xx.html USRP Hardware Driver and USRP Manual: USRP N3xx Series] |
− | <LI> [https://kb.ettus.com/ | + | <LI> [https://kb.ettus.com/N300/N310 Ettus Knowledge Base: N300/N310] |
+ | <LI> [https://kb.ettus.com/N320/N321 Ettus Knowledge Base: N320/N321] | ||
+ | <LI> [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide USRP N300/N310/N320/N321 Getting Started Guide] | ||
<LI> [https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio Verifying the Operation of the USRP Using UHD and GNU Radio] | <LI> [https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio Verifying the Operation of the USRP Using UHD and GNU Radio] | ||
</UL> | </UL> |
Latest revision as of 15:07, 23 January 2020
Contents
Application Note Number
AN-621
Revision History
Date | Author | Details |
---|---|---|
2020-01-23 | Sam Reiter | Initial creation |
Introduction
This guide will serve as a troubleshooting guide for users who have run into N3xx connectivity / device discovery issues while following the USRP N3xx Getting Started Guide. If you haven't seen the getting started guide up to this point, you should start there.
There are several methods of connecting a USRP N3xx device to a host PC (MGMT Ethernet, Serial, SFP+, and QSFP+), the troubleshooting of which are covered in this guide. We will be using a Linux machine (Ubuntu 19.10) for the following steps, but the troubleshooting steps can be generalized across other operating systems. While this guide is applicable to N300, N310, N320, and N321, several of the sections will be applicable to E3xx devices as well.
Aligning Software Versions on Host and USRP
On MPM-based devices, like the N3xx, there are several pieces of software that need to be version-aligned to allow for communication. Irrespective of your connectivity issues, start your troubleshooting by completing this list:
- Install UHD on the Host Machine (required to interface with N3xx and to download FPGA images)
- Linux (source): Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux
- Windows (binaries): https://files.ettus.com/binaries/uhd/
- Install the same version of UHD on the N3xx
- Option 1: Writing the USRP File System Disk Image to a SD Card
- Option 2: Updating the N3xx file system with Mender
- Note: you will have to establish communication over Ethernet/*SFP+ to update the N3xx file system using Mender
- Install the corresponding version of MPM on the N3xx
- This is taken care of by completing the N3xx filesystem update above. Skip if you completed steps 1 and 2.
- Update MPM only: Compiling MPM Natively
- Note: you will have to establish communication over Ethernet/*SFP+ to compile MPM on the N3xx
- Update the FPGA on the N3xx
- UHD Manual: Updating the FPGA
- KB Page: Embedded and Network Mode FPGA update instructions
- Note: This is required for streaming, but you will have to establish communication before you can update the FPGA.
MGMT Port Ethernet Connection
Getting Started Guide Page: Connecting to the ARM via SSH
USRP Manual Page: N3xx Getting Started SSH
N3xx devices all have an RJ45 port intended for communications with the device. This interface is called the management (mgmt) port and is suitable for SSH, file transfer, and device discovery, but not CHDR packet streaming (including uhd_usrp_probe
):
- Issue: The N3xx doesn't check out a DHCP address from my
dnsmasq
server- Ensure your USRP is powered on.
- Ensure your host network and dnsmasq server are configured correctly:
- Host interface must be configured for a static connection. A subnet of
255.255.255.0
is recommended. - Make sure you're specifying the appropriate host interface in
-i <ETHERNET_ADAPTER_NAME>
. Available interfaces can be found by runningip a
on a host machine. - Make sure the first 3 octets of your
--dhcp-range <LOWER IP>-<UPPER IP>
match the first 3 octets of your interface's static IP (assuming you're using the subnet255.255.255.0
).
- Host interface must be configured for a static connection. A subnet of
- For network changes to take effect, it's often necessary to reset the network interface. This can be done by physically disconnecting the Ethernet cable from the host's RJ45 port.
- Try using a new Ethernet cable.
- If the N3xx still won't check out an IP, try connecting it to an existing network (company wired network, router RJ45 port, etc.). From here, you can search your network with nmap to discover the device. If this is successful, consult the dnsmasq man page to correct your configuration.
- If communication with the MGMT port is still unsuccessful, try connecting via Serial Console (below). From there, you can investigate
/etc/systemd/network/eth0.network
to ensure it has the correct default settings.
- Issue: I am unable to SSH into the device using the MGMT Port
- Ensure your USRP has successfully checked out an IP from your
dnsmasq
server. Use this IP tossh root@<N3xx_DHCP_IP>
- If you are given a notice about host identification (see example below), follow the instructions to remove given by ssh
ssh-keygen -f "/home/$USER/.ssh/known_hosts" -R "<N3XX_IP>"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Please contact your system administrator. Add correct host key in /home/$USER/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/$USER/.ssh/known_hosts:13 remove with: ssh-keygen -f "/home/$USER/.ssh/known_hosts" -R "192.168.1.234" ECDSA host key for <N3XX_IP> has changed and you have requested strict checking. Host key verification failed.
- If you are still unable to ssh into a device that has checked out an IP address, try uninstalling and reinstalling
ssh
on your machine
- Ensure your USRP has successfully checked out an IP from your
- Issue:
uhd_find_devices
doesn't return or returns:No UHD Devices Found
- Ensure your USRP is powered on and has checked out an IP address from your
dnsmasq
instance. - Ping the N3xx's checked out IP address with
ping <N3xx_DHCP_IP>
. If this ping is unsuccessful, check your network restrictions / firewall. - Specify "--args type=n3xx,mgmt_addr=<N3xx_DHCP_IP>". If this works but vanilla
uhd_find_devices
didn't, you likely need to enable broadcast packets on your network.
- Ensure your USRP is powered on and has checked out an IP address from your
- Issue:
uhd_usrp_probe
returns "No Devices Found"- This is expected behavior when only connected over the MGMT Ethernet interface. Connect to the device over a SFP+ or QSFP+ port to enable CHDR Packet interfacing.
Serial Connection
Getting Started Guide Page: Setting up a Serial Console Connection
USRP Manual Page: N3xx Getting Started Serial Console
N3xx devices all have an serial console port intended for communications with the ARM or the SMT32 MCU. This interface is suitable for remote device access and MCU log monitoring.
- Issue: When connecting to the N3xx with
screen
, the following error returns:No such file or directory
- Ensure that the symlink you're using is specific to your machine by copying the output from
ls /dev/serial/by-id
. Your symlink will be unique , meaning that you can not copy the commandsudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200
verbatim from the KB. - Use
ls /dev/serial/by-id
to enumerate available N3xx serial nodes. If this directory does not exist, your serial cable is likely bad or unplugged - this directory is created when your N3xx is connected to the PC. Try an unplug/replug cycle or a new cable.
- Ensure that the symlink you're using is specific to your machine by copying the output from
- Issue: When connecting to the N3xx over serial I do not get a prompt to log into the device
- Ensure that the node you're connecting to is
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_<UNIQUE_ID>-if01-port0
- If you see a blank terminal with a blinking cursor, hit
Enter
to progress to the prompt. IfEnter
does nothing, you've connected to the wrong node. - If you see continuously printing debug lines (similar to the example below), you are connected to the MCU. Use the
...-if01-..
node referenced in the first bullet of this list to connect to the ARM.+++(++)[1819115.512968 HC 0x21] +++(++)[1819116.551227 HC 0x21] +++(++)[1819116.790476 HC 0x07] [1819116.791563 HC 0x21] ++[1819117.589498 HC 0x21] +++(++)[1819118.627901 HC 0x21] +++(++)[1819119.666264 HC 0x21] +++(++)[1819120.704714 HC 0x21]
- Ensure that the node you're connecting to is
- Issue: When connecting to the N3xx over serial I get a notice about partial or dropped output
- Ensure that your screen session was opened with
115200
at the end of the command. This sets the Baud rate and should not be omitted - Try a different USB-A -> Micro-USB cable
- Try a different USB port on your host machine
- Ensure that your screen session was opened with
- Issue: When connecting to the N3xx over serial my login / password results in:
Login incorrect
or
Sorry, try again.
- Ensure that you are actually being asked for the password for the N3xx. You are required to run
screen
as root and will be prompted for your host machine's password before the N3xx's password. - If you have forgotten or lost the password for your N3xx (default login:
root
, default password:<BLANK>
), the only solution we can offer is to reformat your SD card. Ettus Research can not help you bypass this password.
- Ensure that you are actually being asked for the password for the N3xx. You are required to run
- Issue:
uhd_find_devices
doesn't return or returns:No UHD Devices Found
- This is expected behavior. You must use a valid Ethernet interface to communicate with the N3xx with UHD.
- Issue:
uhd_usrp_probe
returns "No Devices Found"- This is expected behavior. Connect to the device over a SFP+ or QSFP+ port to enable CHDR Packet interfacing.
SFP+ Connection
The N3xx has a pair of SFP+ ports located on the rear panel of the device. These interfaces are labeled 0 and 1:
In general, it is recommended that you start off by connecting via either MGMT Ethernet or Serial before setting up streaming over the SFP+ or QSFP+ ports. It is possible to connect to the N3xx over 1 Gigabit Ethernet via an SFP+ to RJ45 adapter or a 10 Gigabit Ethernet-capable SFP+ cable. Whether or not your N3xx device is capable of using 1GbE is dependent on the FPGA image being used. With the HG image, port 0 is 1GbE and port 1 is 10GbE. Using the XG image enables dual-10GbE-links (ports 0 and 1). See the UHD Manual for instructions regarding updating the FPGA image of your device.
1 Gigabit Ethernet (1GbE)
This protocol is supported only on N3xx SFP+ port 0 when using the HG / HA FPGA image. If both of these conditions are met, you will see the green LINK LED illuminate when a working SFP+ adapter is inserted into the powered-on N3xx. On N3xx devices, this LED should light up regardless of successful connection to host when a working SFP+ adapter is inserted.
- Issue: Ethernet LINK LED (Port 0) does not illuminate when an SFP+ -> RJ45
- Ensure your USRP is powered on.
- If the green LINK LED does not illuminate in port 0, you should try a different (known working) SFP+ adapter.
- If a known good SFP+ adapter does not elicit a green LINK LED, you should flash the FPGA using the HG image. Connect to the device over the MGMT Ethernet interface and update the FPGA: N3xx: Updating the FPGA Image
- If the FPGA recovery doesn't complete successfully or recovery doesn't bring back the link LED, reflash your SD Card and try the FPGA flash again.
- If these steps don't elicit a green link LED, contact Ettus Support.
- Issue: Host PC is unable to ping the USRP
- Ensure your USRP is powered on.
- Ensure your host network settings are correct. See USRP Manual: N3xx Network Connectivity. The host NIC must have an appropriate IP address and subnet mask for the N3xx interface you are connecting to. Note that many systems require a user to unplug/replug the ethernet interface for configuration changes to take effect.
- Ensure host is connected directly to the N3xx. Eliminate all routers and switches in between USRP and host machine. (**Note on this at the end of this list)
- Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in
/etc/systemd/network/
- Replace your RJ45 cable and repeat the above steps for this issue.
- **Some communication issues have been observed with specific Linux distros (Kubuntu is one example) requiring a network switch between Host and USRP - adding an intermediate switch is worth exploring in the event other steps in this were unsuccessful.
- If you are still unable to ping your N3xx, contact Ettus support.
- Issue: SFP0 does not appear when I run
ip a
from the N3xx's ARM- Ensure your N3xx SFP0 is correctly configured in
/etc/systemd/network/sfp0.network
. - Ensure that you are using the HG image. In FPGA images like WG, SFP0 is reserved for white rabbit timing functionality. See N3xx: Updating the FPGA Image
- Flash a fresh filesystem onto the N3xx's SD card.
- Ensure your N3xx SFP0 is correctly configured in
If you're able to ping the device over the SFP+ port, then you have successfully connected to it. At this point, it is recommended to run uhd_usrp_probe to pull device information over this interface. If your FPGA image is not consistent with your version of UHD on the host side, you may get errors or warnings regarding FPGA versioning. See the USRP Manual: Updating the FPGA section.
10 Gigabit Ethernet (10GbE)
This protocol is supported on USRP Ethernet port 1 when using the HG FPGA image. When using the XG image, 10 Gigabit Ethernet is supported on ports 0 and 1. Unlike the SFP+ adapter's behavior the section “1 Gigabit Ethernet” section above, you should only expect to see the LINK LED turn green for a 10 Gigabit port upon successful connection to a host machine.
- Issue: Ethernet LINK LEDs do not illuminate when connected to host machine
- Ensure your USRP is powered on.
- Ensure the SFP+ cable is plugged into port 1 of the USRP. This is a 10 Gig interface on both the HG and XG images.
- Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in
/etc/systemd/network/
. Verify that your IP address and subnet mask are compatible between host and USRP. - If your host machine is using a PCIe NIC with SFP+ interfaces, ensure the NIC was enumerated correctly by your operating system with
sudo lshw
. You may need to reinstall drivers or try a different PCIe port on your host machine. - Check that the SFP+ interface on your host machine is configured to support a 10 Gigabit link. If your NIC supports dual 10 GbE links, you can put it in loopback with your SFP+ cable and confirm that both ports recognize a 10GbE connection:
- Swap your cable for a different (known good) SFP+ to SFP+ cable.
- If a known good SFP+ cable connected to a known working SFP+ port does not elicit a green LINK LED, you should attempt an N3xx FPGA update with the XG image. Connect to the N3xx over the MGMT interface and see: N3xx Getting Started: Updating the FPGA. With the XG image, try the above steps on Port 0 of your N3xx.
- If the FPGA recovery doesn't complete successfully or recovery doesn't bring back the link LED, reflash your SD Card and try the FPGA flash again.
Once the device has a successful 10GbE connection to the host, the host machine should be able to ping the radio using a ping <N3xx Port 1 IP address>
command.
- Issue: Host PC is unable to ping the USRP
- Ensure your USRP is powered on.
- Ensure your host network settings are correct. See USRP Manual: N3xx Network Connectivity. The host NIC must have an appropriate IP address and subnet mask for the N3xx interface you are connecting to. Note that many systems require a user to unplug/replug the ethernet interface for configuration changes to take effect.
- Ensure host is connected directly to the N3xx. Eliminate all routers and switches in between USRP and host machine. (**Note on this at the end of this list)
- Use an SSH connection over the MGMT interface (or tty connection over the serial port) to connect to the N3xx and explore the network configuration in
/etc/systemd/network/
. Verify that your IP address and subnet mask are compatible between host and USRP. - **Some communication issues have been observed with specific Linux distros (Kubuntu is one example) requiring a network switch between Host and USRP - adding an intermediate switch is worth exploring in the event other steps in this were unsuccessful.
- If you are still unable to ping your N3xx, contact Ettus support.
If you're able to ping the device, then you have successfully connected to it. At this point, it is recommended to run uhd_usrp_probe to pull device information. If your FPGA image is not consistent with your version of UHD on the host side, you may get errors or warnings regarding FPGA version numbers. See the USRP Manual: Updating the FPGA section.
QSFP+ Connection
The N320 and N321 devices are equipped with a QSFP+ port:
At the time of this application note's creation, no unique troubleshooting steps have been identified for the QSFP+ port. See the steps recommended for the SFP+ ports.
If you encounter a connectivity issue not resolved by the SFP+ section of this document, please contact support@ettus.com
Miscellaneous Notes
Early runs of the N300 and N310 had a firmware bug that resulted in intermittent issues with power button response. This can often be bypassed by issuing the command "powerbtn" over the serial console to the ARM. Reach out to support@ettus.com for instructions on downloading and installing the patch.