The process of making changes actually has several steps, and it's important to understand them:

• Submit takes the edits in your browser screen and transfers them to the device
• Activate makes those changes apply to your current session
• Store puts the changes into non-volatile memory, so they will be loaded when the device is rebooted

So, if you made changes on one browser page, then navigated to a new browser page without pressing the Submit button, those changes were lost. If you perform a Submit on each page but do not Activate the changes, you don't yet see the effect your changes will have. If you Submit and Activate but do not Store the changes, the next time the device reboots, it will have the old settings, not the new ones.

The separate steps can actually be useful if you Activate (but have not stored) a change that causes something undesirable to happen: In that case, power-cycling the unit will bring it back to the prior stored configuration, giving you a chance to try a different change this time.

Note that there may actually be times when you want to store changes without activating them first. For example, if you are changing the subnet of the Trusted interface, then as soon as you Activate, the network connection to your PC is lost. If you wanted to make several changes and only have them apply upon reboot, you could Submit the edits on each page, do a Store at the end of your editing, then let the reboot do the activation step for you.

Actually, it's not quite that simple. The manual should contain a section with the following sequence of steps to return the unit to factory defaults:

1. apply power, blue (bottom) led will go on then the green (top) led will go on
2. wait for the green led to go off
3. press and hold the setup switch
4. wait for the green led to blink on then off
5. the switch may be released
6. the serial port will be in setup mode and the unit can be accessed from the default address

It should be noted that these default settings are now in the Active Configuration, but have not yet been stored to non-volatile memory: If you remove power to the unit at this point, you'd have to go through those steps again.

If you have a terminal program and a null modem cable (in most cases a USB-to-Serial adapter cable is needed as well), the DE9M connector ("Setup") may be used to access a command-line interface and perform the reset to factory defaults.

If the cable was connected and the terminal session was opened before powering up the unit, the welcome screen will appear as the unit finishes boot-up. If it was already booted-up, you can still attach the cable, open the terminal program and press Enter to get the same welcome screen. Type the login name "setup" and press Enter: This will display some explanatory text, as well as the current IP configurations of the unit's interfaces.

At the question, "Set ALL parameters to default (y/[n])?" type "y" and press Enter. Press Enter several more times to answer "No" to the rest of the questions. The (now defaulted) settings will then be stored in non-volatile memory and the unit will reboot with the defaults in effect.

It actually depends on your application. In many cases DCB tunnel devices are being used to extend a particular subnet to a remote location. So if your local office is using a subnet of 192.168.1.x, with a Subnet Mask of 255.255.255.0, you can assign an address in that same subnet to the Trusted interface of the tunnel device in the remote office and it will make it possible for you to access the local office LAN from the remote site.

However, at a more fundamental level, you are creating a "Layer 2 Bridge", and technically it is possible to have a different subnet assignment on the Trusted interface at the remote device. Because your PC at the local site can have multiple IP addresses assigned to the NIC, you could in theory do the following:

Local Office Tunnel Device Trusted interface: IP Address = 192.168.1.5 (Mask = 255.255.255.0)

Remote Office Tunnel Device Trusted interface: IP Address = 10.10.1.5 (Mask = 255.255.255.0)

PC NIC: Assign both 192.168.1.10 and 10.10.1.10, thus allowing the PC to network with all the devices on both the Local Office and Remote Office LAN segments, and allowing you to manage both of the tunnel devices from their Trusted interfaces.

But, if you had another Local Office device with only a 192.168.1.x IP address, you would not be able to (for example) print to a printer in the Remote Office that only had a 10.10.1.x IP address. A router would be needed for that, and the DCB tunnel device is not a router.

Additionally, IP Multicast does not follow the same rules as routed network traffic, so if the only function of the tunnel is to pass IP Multicast (e.g. for dispatch), you do not need to have the same Trusted interface subnet assigned at both Local and Remote ends of the tunnel. It may make things easier to keep track of, but it is not strictly required.

First, it is important to realize that when setting up a network of DCB tunnels, "the Client talks first, but the Server listens first", that is, whatever units are configured as Clients will immediately begin sending messages in an attempt to find the Server. The Server will only reply once it has successfully received a message from a Client.

Because of this order of operation, the Clients must know where the Server will be, and this fixed value is entered in the Remote Server IP field in the Client setup. The IP address in that field may be the one assigned directly to the Server Untrusted interface, or it may be the external-facing IP address of a Router or Firewall positioned between the Server Untrusted interface and the larger network. In this second case, the Router/Firewall needs to have a Forwarding Rule added to direct the Client messages on through to the Server.

The Client's first message contains the IP address information the Server needs to send a reply, and for that reason, it is permissible to let the Client's Untrusted interface configuration obtain an IP address via DHCP. However, if the Server's Untrusted interface obtained a new IP address each time it was restarted, the Client's Remote Server IP information might now be invalid, and the messages can no longer reach the Server.

It is possible to use DNS or a Dynamic DNS service and allow the Server Untrusted interface IP address to be assigned with DHCP, but this is an advanced technique that is unnecessary in most scenarios. For most users the general rules for the Untrusted interface are:

• Clients may obtain an IP address (with Mask and Gateway) via DHCP, since they "talk first".
• Servers should use Static Configuration for their IP address or a customer provided DHCP address with DNS, so they can always be found by the Clients.

No. This should never be done as it causes an ambiguity for the tunnel device with the ARP protocol. You may test it and it seems like it works, but it will fail at some point.

It should be noted that this is not the same thing as operating in a "Single-Ended" configuration. In that mode, only the Trusted interface is used, for both the untunneled and tunneled traffic, and the Untrusted interface(s) are disabled altogether. For further details on this configuration, see the application note on our website.

We recommend against this if you are using any networking equipment that supports a Layer 2 discovery protocol or a VLAN trunking protocol. This includes most high-end network switches. The tunnel path provided by the UT devices may confuse the discovery protocols and be flagged as a redundant path, causing the switches to block ports. The failure may not occur immediately, but will show up at a much later time.

This particular syslog message does mean exactly what it says. Either, A) The Shared Secret/Common Passphrase is not identical in both units or, B) Two different encryption options are being used (e.g. AES-128 vs AES-256).

Of these possibilities, B) is simple to diagnose, but A) is not always obvious. It has been observed that using a Copy/Paste operation to fill-in the field does not always work as intended, as it is possible for an unprintable character to be present before or after the password string. Our recommendation is to start with a simple, short password (e.g. a name) manually typed into both units. (Note: This is case-sensitive.) Once this is demonstrated to work correctly, a more complex password may be entered, up to 51 characters in length. (Earlier documentation claimed 52 characters, but that is incorrect.)

No, this is exactly how the tunnel is supposed to work. By the nature of tunneling, the Untrusted interface will not be visible from the Trusted interface. However, inside the tunnel device itself is a utility (Tools → Ping in the menus) with which you can select the Untrusted interface as the one to send the ping from: If the tunnel is established, you should be able to ping from the local Untrusted interface to the remote Untrusted interface using this tool.

In many cases, the routers in between the Server and Client are configured to discard fragmented packets, and one of the causes of fragmented packets is packet length becoming too large. By the nature of tunneling, the packet size grows due to encapsulation, and may be exceeding the length allowed in a single packet. Both Ping packets and voice packets are small, so they will pass without issue, but the web browser requests and replies are more likely to become fragmented. Under the menu Ethernet Tunnel → Advanced, the parameter Limit UDP packet size should be set to "yes" to prevent the fragmentation.

Note that this change needs to be made on all the tunnel units in the network (Clients and Servers). In addition to the hardware tunnel devices, the UT-Soft client software also has a check box for Limit UDP packet size, and it must be checked as well.

It means an interruption has occurred on the network link between the Client and the Server. It is important to realize that, in a vast majority of cases, the tunnel device is not causing this interruption, it is responding to it.

The action taken when the connection becomes idle differs between the Client and the Server. For the Client, the connection is considered closed. The Client tunnel will try to reestablish a connection with the Server. If it is unable to, it will try to establish a connection to the Backup Server.

When the Server detects an idle condition, it marks a Client as idle and will no longer send Ethernet data to that Client. However, it will continue to maintain state information for that Client until the session key expires. By maintaining state information, there will be less impact on the system in the event that the Client reconnects.

DCB tunnel devices are designed to take account of network imperfections. Under the menu Ethernet Tunnel → Advanced, the parameter Idle Disconnect Time controls how long a Client or Server will wait until marking a connection as “inactive”, and during that waiting time, Clients will continue sending messages to the Server according to the Send Keep-Alives value. The default values are 45 seconds for Idle Disconnect Time and 15 seconds for Send Keep-Alives, with the general rule being to have a 3-to-1 ratio between those values. The Help screens inside the tunnel device contain further details on these parameters.

Yes, there are some built-in diagnostics that may be helpful, and examples include:

• On the Status → Tunnel Nodes screen there are counters for RX CRC errors and Sequence errors.
• On the Status → Interface screen there are various counters for TX and RX packet errors.
• The Tools menu contains a Packet Sniffer and a Bandwidth Test utility that can send data between a Client and a Server. (The Help screens contain details about setting the parameters for the Bandwidth Test.)

The firmware file must be 100% uploaded and verified by the device before it will start the update routine. So if a network interruption were to occur in the middle of an upload, you will have to restart the upload over again, but there is no chance of the device locking-up due to the earlier network interruption.

Once the new code is fully loaded to the tunnel device, the power must stay on during the update process, so a power interruption is actually the more concerning scenario, and hopefully not very likely.

There is no built-in utility on the tunnel devices that can search for and report the addresses of all other similar units. One handy trick we have run across is to do the following, from a PC that is currently connected to the the Trusted subnet (for this example, assume it is the 192.168.0.x subnet, with Subnet Mask 255.255.255.0):

1. Open a Command Prompt as Administrator
2. Type the following: FOR /L %i IN (1,1,254) DO ping -n 1 192.168.0.%i
3. Press Enter and allow this command to ping each address in the subnet, in this example from 192.168.0.1 to 192.168.0.254, which will take several minutes
4. Examine your PC's ARP Cache by typing the command arp -a, and note which addresses on the list are the unfamiliar ones
5. Try browsing to the unfamiliar addresses (using https), and you should get the authentication screen when one of them is a tunnel device

Of course, if you can get to the authentication screen, but have forgotten what the User Name and Password were, that's a different problem. At that point, it might be better to read the question about resetting a unit to factory defaults.

Due to the encryption employed in these products, they are export controlled items and are regulated by the Bureau of Industry and Security (BIS) of the U.S. Department of Commerce. It is necessary to keep the firmware in a secured section of our website. Please contact DCB Support and ask for assistance with the firmware download.

All products within a family, for example, all UT units, will operate together regardless of firmware version. XT units interoperate with XT, UT, and older ET units. You do not need to upgrade older firmware when adding a unit with newer firmware version. However, adding additional features is the most common reason for DCB to create a new version of firmware, so you might want to check to see if any desired features are available on the new version. If there are no additional features that provide a reason to update the firmware, most customers chose not to change it. You can see what features have been added by reading the firmware version log our downloads page. Just click here.

With the exception of our XT family products, the UT, FT, and ET families can not be mixed. Only UT products interoperate with UT products; only ET products interoperate with ET products; only FT products interoperate with FT products. This is because ET products use TCP/IP as the connection protocol; UT products use UDP/IP as the connection protocol; and FT products use FIPS approved connection protocols. XT products interoperate just fine with UT and ET products since the XTs allow for the connection protocol (TCP/IP vs. UDP/IP) to be selected during configuration. The XTs do not interoperate with FT products, though.

The remote client name may be up to 52 characters in length and can't include a quote or backslash character. Other than those requirements, clients may have any name you choose. While different clients can share the same name, doing so is not a good practice. By assigning a unique name to each client, status and diagnostics are made much easier since the individual site information displays on the tunnel nodes status and tunnel log pages. Individual site information would be ambiguous if client names are shared.

Also from a security perspective, if a remote client or laptop is stolen, it can be disconnected by disabling that client name at the server. Each client's name must be configured in the server's authorized client list.

The 33xx series of hardware (e.g. UT-3302) does not include a Real-Time Clock (RTC), but the 66xx hardware (e.g. UT-6602) does. All models have a software clock. So if you manually set the clocks for all tunnel devices in your network, the 66xx series devices will hold their settings during a power outage, but the 33xx series will not.

Fortunately, all but a few very early DCB tunnel models can set their clocks (both RTC and software) using Network Time Protocol, under Tools → NTP in the menus. The default NTP Server value is “us.pool.ntp.org”, and in order to resolve that name to an IP address, the Primary DNS field on one of the interfaces (Trusted or Untrusted) must be populated. If Static Configuration of the IP addresses is used, you must manually enter a Primary DNS Server address (and Alternate if you wish), but if DHCP is being used to set the IP address, the DHCP Server must populate the DNS field as well. However, if you use a private NTP server or know the IP address of the server you wish to use, an IP address may be entered instead of the NTP server's URL and no DNS server is required. There must be a route available to the NTP server either through a trusted or untrusted ethernet port.

For most applications where ET, UT and XT devices are used, time synchronization is largely a matter of convenience, and can aid in troubleshooting problems that may occur on the network. However, due to the x509 certificates employed by the FT family devices, CA and key generation will not work correctly unless the clocks are more strictly aligned on FT products.

Yes, this is one of the most useful features of our tunnels, and there are multiple options:

1. You could keep a spare tunnel device with you, pre-configured to connect to the Server of your network via the Internet whenever you have access.
2. You can purchase a license of UT-Soft (for use with UT tunnels) or FT-Soft (for use with FT tunnels) and let your laptop become a soft-client, allowing you to access the Server from anywhere you can get an Internet connection.
3. You can make web access available through the (Internet-facing) Untrusted port(s) of one or more of the tunnel devices. This option is found under the menu Administration → Access Control. We only recommend this for use during initial configuration and troubleshooting of the network, and a very strong Admin Password (up to 15 characters) should be used

Also note, when using option 3, you are only able to login to units that have access opened as described. In contrast, options 1 and 2 allow you to be on the Trusted side of the network, where you can login to the web interface of any tunnel device, and keep multiple browser sessions open to observe the interactions between devices.

Only if you buy 5 licenses. (Please notice that the web page also reads, "Price is per unit".) It is possible for the software to reside on more than one computer, but only one may be using each Software Key at a time. As an example, if you have a work laptop and a home laptop, you could use the same key for whichever one you are using: Make sure to exit UT-Soft after each use in this case.

If a single license key is used on two computers that are running simultaneously, the most common symptom is that traffic bounces back and forth between the two client computers: In a dispatch environment, the audio has been said to, "ping-pong" between them.

No, you need to make sure to assign a static IP address ("Use the following IP address"), choosing a value that is currently unused on the the Trusted subnet of your Server tunnel device. Fill-in the Subnet mask to match that of the Server Trusted interface, but leave the Default Gateway field empty.

If you have not yet established a connection to a Remote Server, this is the normal status you will see. Once you have configured the DCB Virtual Ethernet Adapter, configured UT-Soft, hit the "Connect" button and received a response from the Server, the status will change to what you would normally see for any other network connection.

This status will always correspond to your connection to the Server, and if an interruption occurs on the link between Client and Server, then “Network cable unplugged” will appear again.

Yes, we’ve done this many times. There are certain items we will need you to provide:

• A static IP address (and Subnet Mask) on your Trusted network
• The IP address of your Server’s Untrusted interface, or of the router or firewall device in front of it
• The Shared Secret for the tunnel units on your network
• The Port Number and Encryption type you are using (for example, “Port 22 and AES-256”)
• You need to add our UT-Soft client name (for example, “dcbsupport”) to your Server device’s Ethernet Tunnel → Remote Clients, table, with a simple password (for example, “dcb”)

Once you have activated the changes on your Server, look at the Status → Tunnel Log screen, and when we try to connect, there should be a message such as, “dcbsupport connected from address <IP address>”. If we can’t get in either, there is still a problem with your IP addressing or the router/firewall setup. If we can get in, but your own UT-Soft client cannot, the problem is more likely with your UT-Soft configuration settings.

Versions of UT-Soft earlier than 2.0 do not work with Windows 10. However, if you already have a license for the earlier version, there is no cost to upgrade. Contact DCB Support for details on obtaining the new version.

If you were trying to transfer your pre-2.0 UT-Soft license to a new Windows 10 PC, it will fail. The Version 2.0 Release Notes contain the following clarification:

If a user attempted to install an older UT-Soft package on Windows 10, Windows 10 will have erased the Software Key. They have two options. 1) Completely uninstall UT-Soft and then reinstall with this new package. 2) Install this UT-Soft package on top of the old installation. Then go into the DCB Virtual Ethernet Adapter Properties - Advanced Tab and manually set the Software Key. Method 2 will preserve their old configuration.

If the original laptop is still functioning, the Software Key value may be found in the Properties of the DCB Virtual Ethernet Adapter: Pressing the Configure button and selecting the Advanced tab should display the key value.

If the old laptop has failed and can no longer be restarted, we need to locate the Serial Number of your license. Ideally, it would still be visible on (what's left of) the sticker. Alternately, check to see if it is recorded in your own paperwork. If neither of these is possible, we may be able to look up the order information here at DCB, but it will take some time to do so.