SCOPE: This document only applies to the following products:
Digi Connect and ConnectPort Cellular Routers
This article does not apply to the Digi TransPort, ConnectPort X2e or ConnectPort X3 products
Background: The Remote Management default server address which is configured on various Digi Gateway products may vary, depending on the age of the product and what defaults were in use at the time. While this default configuration is intended as a convenience to our customers, the reality of server-name changes and widely varied geographical locations can sometimes necessitate changing the Device Cloud server address in use on your Gateway.
A common example is the need to configure a Gateway or Cellular Router to connect to the Device Cloud European server (login.etherios.co.uk) instead of the Device Cloud US server (login.etherios.com), or if a Gateway has no default Remote Management configuration at all. Yet another possibility exists that you may have added the Gateway/Router to the correct Device Cloud server (and changed the configuration of the device to connect to the server as well), yet your Gateway is still showing up on Device Cloud as Disconnected.
In order to get to the CLI, you will first need to know what IP address the Gateway is currently using. One way of doing this is to discover the Gateway on your local area network (LAN). You can use the Digi Device Discovery Tool for Windows to "discover" the Gateway. If you have trouble discovering your Gateway with the Device Discovery Tool, see this article for troubleshooting tips on why it might not be showing up.
Assuming you have run the Discovery and can now see the Gateway on your Local Area Network, record the MAC address listed for that device in Discovery, and compare it to the MAC address on the Gateway label. These two should match, at which point you will want to record the MAC and IP address listed for your Gateway, as they will be used later. While checking the label, also verify that the Power and Network cables are plugged in securely on both ends, and on the Digi end of the Network cable where the cable plugs into your Gateway, verify the Link LED (Amber) is lit solid, and that the Activity Led (Green) is flashing occasionally verifying network activity as seen in the picture below:
If the "discovered" MAC address does NOT match the MAC address listed on your Gateway''s label, add the Gateway to your Device Cloud account using the discovered MAC address instead of what''s written on the label.
Now that you know the IP address of your Gateway, telnet to the IP address you recorded during Discovery. If you don''t know what telnet is or how to telnet, this article should be useful.
If prompted for a username/password when you telnet to your Gateway, try username: root, password: dbps, as these are commonly used Digi defaults.
Configuring a Gateway's Device Cloud connection (from the CLI):
From the command prompt (#>), use command "show mgmtconn" to see where the Gateway is currently trying to connect to:
As seen in the screenshot above, this Gateway is trying to connect to the European Device Cloud Server (login.etherios.co.uk). If your Device Cloud account is found on the US Device Cloud Server (login.etherios.com) this will be a problem and the likely cause of your device's "Disconnected" status. To change the Device Cloud server your Gateway connects to, use the "set mgmtconn" command as follows:
#> set mgmtconn conntype=client svraddr1=en://login.etherios.com
Doing the follow-up "show mgmtconn" in the example above is to make sure everything was entered correctly. If the address is incorrect, repeat the previous step and enter the correct Device Cloud Server address. Reboot your Gateay with the "boot action=reset" command (see below) to make the changes take effect (if the configuration was changed), otherwise continue on to the next step.
Wait about a minute, then telnet into your local Gateway again, this time issuing the "display idigi" command. At this point you should now see the server url listed as en://login.etherios.com
If this is true, check your US Device Cloud account to see if your Gateway is now in a Connected state:
If you see the blue icon in the screenshot above, your Gateway is connected and your task is complete.
If your Gateway is still showing up as "Disconnected" however, you will want to telnet back into the Gateway to access the CLI again to do some troubleshooting.
Troubleshooting a Gateway's Device Cloud connection (from the CLI):
Ping the Device Cloud server you have configured your Gateway for (use Ctrl-C to end the Ping test). In the example below, we're pinging the US Device Cloud server: login.etherios.com:
In the example above, our pings were successful so the Gateway likely doesn't have any problems connecting to the Device Cloud server it was configured for. If the pings are timing out however, you will want to check a few things using the "show network" command in order to view the current network settings of your Gateway:
Verify that valid IP addresses (as opposed to 0.0.0.0 or 169.254.x.x) are listed next to fields "gateway" and "dns1" under the column listed as "Currently in use by the network stack". These are your Gateway IP and Primary DNS Server IP, respectively. If no values are listed or they appear bogus, the DNS primary of 126.96.36.199 and DNS secondary of 188.8.131.52 (as seen in the screenshot) are Google''s open DNS servers, and have been used successfully to connect to the Device Cloud. Use the "set network" command to configure these settings:
Again, a "boot action=reset" command is necessary to reboot your Gateway and make those changes take effect.
At this point, your Gateway is hopefully connected to your intended Device Cloud server. If still showing as "Disconnected", try using telnet to connect to the Device Cloud port. From the gateway prompt:
#> telnet login.etherios.com 3197
If an error is seen, it would be a good time to talk to your IT people to ensure that outbound traffic on TCP port 3197 as described in this article.
If your Gateway is still not in a "connected" state on the Device Cloud, its a good time to contact Technical Support.