Firmware Release Notes
Our team of developers is keen to continuously improve our products. Hence, we periodically release firmware updates to not only eliminate errors and raise product quality but also provide new additional features. In the development of new product features we strongly upon our customer's feedback.
"Cutting edge" vs "stable"
Viprinet offers two branches of firmware releases - "stable" and "cutting-edge". Stable firmware releases are done once or twice a year after extensive long-term testing in real-world setups. Customers are advised to always use the latest stable firmware release. In addition, we offer "cutting-edge" releases several times a year, bringing new features quicker to those customers who require them. These releases also have been tested extensively, but not long-term.
Online update (stable Firmware only)
All our routers provide the option of a simple online update for the "stable" firmware branch in the Webinterface at [ AdminDesk ] [ Logging & Maintenance ] [ Router Firmware Update ]. The device will automatically check for firmwareupdates for this specific router model and - if applicable - download and install them. Configuration settings permit that firmwareupdates will be downloaded without any administrator support when available. However, the installation should always be run with an administrator present.
Offline update
As an alternative to an online update, an offline update is available. "Cutting-edge" firmware releases are only available as an offline update. To do an offline update, please download the correct firmware image for your product and then use the manual update function inside the router's web interface to upload that image. Both firmware images, "cutting-edge" and "stable", are available from our FTP server.
If you need any help or further information concerning firmware updates, please contact our support team.
Current stable firmware release notes
Following, you will find important information on recently released "stable" firmware versions, with the latest update at the head.
Firmware Release February 6th, 2013 - Version 2013012301/2013020600 (Multichannel VPN Router 500: 2012112320/2013020600)
This firmware update is based on our last Stable Release from December; it rectifies some partly very important mistakes. In addition, the new CDMA 450MHz module types are supported for the first time by this firmware release. The command line interface (CLI) is now ready for production use.
We recommend all customers to update to this stable firmware release as soon as possible. Please note that all Hubs and Routers should be updated to this release. Routers with this current firmware are able to talk to Hubs with older firmware (and vice versa), but performance may be degraded.
Improvements:
This release for the first time fully supports our new CDMA 450 Mhz modules to be used in northern and eastern Europe.
Channel congestion detection is slightly changed to be more aggressive.
The CLI has been completed and is now ready for production use. A scripting toolkit to automate router administration and deployment is available on request.
Bug fixes:
IMPORTANT: The previous stable firmware released on December 10th has a very dangerous bug: If you have references in the VPN & Routing object to a Tunnel, and then in the Tunnellist remove a Tunnel previous to such a referenced Tunnel, all routing references would break, potentially killing all of your routing configuration. The same happened with QoS rules references. Do not delete any Tunnels before upgrading to this firmware release!
If channels were completely idle (traffic less than 20 kbit/s for a while), they were supposed to only send the internal pings for latency and loss management every 1000ms instead of the default 100ms. This was meant to reduce idle traffic usage over expensive links like UMTS. This feature always has been broken due to a rounding error. Once you ever on a connected channel had more than 24 Kbit/s, it would never go back to this idle-traffic-saving mode. This now works as expected and will reduce idle traffic usage by a factor of 10.
In Hotspare mode, the license manager now displays a note that licenses are not checked in this mode.
A rare timer overrun on the 500 could cause short hangs of the routing.
The Ethernet info tool for the LAN interface of the 500 now actually works.
Multiple BondingTCPOptimizer bugs were fixed. Those could cause a BondingTCPOptimizer TCP connection to hang if the bottleneck in bandwidth has not been the tunnel, but on the LAN instead (e.g. if you had a traffic shaper behind a Viprinet router).
Ethernet Autonegotiation settings for Ethernet WAN Modules were not saved across reboots. This is now fixed. Known issue: Gigabit Ethernet Modules right now do not support turning off Auto Negotiation at all due to a NIC driver bug. You can only turn off Auto Negotiation for Fast Ethernet modules.
A memory leak in regards of Tunnel objects was fixed. If you created and deleted a huge number of VPN Tunnels using scripting, the router could run out of memory with previous firmware releases. This no longer happens. Also, performance of this kind of mass additions/removals has been improved.
In the previous stable firmware release, it was changed that after a big number of critical errors in the log, the router would automatically reboot. However, if one of the two redundant fans breaks, this is logged as critical error. This caused routers with a broken fan to constantly reboot every few minutes. This issue is now fixed - a single broken fan is no longer reported as critical, but as an alert. Only both fans failing is now critical.
An "invalid floating point error" could appear when using the download tool with "Measure & discard" setting.
When using e.g. plink to supply a file of commands that are to be executed via the CLI, carriage returns were ignored and no command separators existed.
Example:
plink -pw-batch -ssh -P 22 root@ -m commands.txt -v ERROR 140 ←[1m←[31mThis object does not exist←[0m
This now works with CR or CR/LF as command seperator.The CLI now allows to delete items using their object index instead of object names only, e.g. "execute DELETEITEM OBJECT__2".
The CLI now properly supports closing the SSH connection, and closing/reopening SSH subchannels to issue multiple commands in a way that some SSH scripting toolkits (e.g. Paramiko) do it.
Multiple typos have been fixed in the web interface.
The timing of Hubs placed in a redundancy group probing to check if they are replaced on boot has been modified to be more robust.
BondingTCPOptimizer connections seeing packet loss on the WAN with unstable high-bandwidth links could, after internal retransmission of lost segments, have queued up a very big amount of packets on the LAN side (multiple megabytes). This could cause huge traffic spikes when those were released to the LAN, potentially causing problems on the LAN which could be seen on the routers as "XX packets have been dropped reading from LAN" messages. These packets will now be released more slowly to reduce these spikes.
Firmware Release December 10th, 2012 - Version 2012091701/2012121005 (Multichannel VPN Router 500: 2012112320/2012121005)
This firmware release brings a huge number of improvements to our customers. For all products, the performance and achievable throughput have been improved for various Bonding modes. There is a high number of fixes for the Multichannel VPN Router 500, which improve both stability and performance. The command line interface (CLI) while still in beta has improved a lot and now actually is usable. A scripting toolkit for the CLI will be made available soon to help with mass deployment. This release also improves real-life performance and user experience of routers used in moving vehicles a lot - you will now be able to go hour for hour without having connections through your tunnel ever getting reset, even if you go through areas where there is no mobile data signal coverage at all. We've also extended VLAN options on Multichannel VPN Hubs, and also are providing an improved set of default QoS rules.
We recommend all customers to update to this stable firmware release as soon as possible. Please note that all Hubs and Routers should be updated to this release. Routers with this current firmware are able to talk to Hubs with older firmware (and vice versa), but performance may be degraded.
Here is the list of changes:
Improvements:
The integrated system bootloader of the 500 router now uses error correction for its flash memory. In the past, we have seen RMA-ed 500 routers that had recoverable errors on the bootloader. Such a router would on power-on only have the power led going on, with nothing else happening besides that. With this improvement, these total failures will be a matter of the past.
The Routers/Hubs will now keep state of all connections including NAT state if a tunnel disconnects. If the tunnel reconnects within 3 minutes, all state is restored. In previous firmware releases, a full tunnel disconnect (all channels disconnected) would often cause connections going through the tunnel to hang after tunnel reconnect; now it no longer does so if the tunnel comes back within 3 minutes. That's a huge improvement especially in moving vehicles that enter a "dead zone" with no mobile network reception at all. We were now able to do test drives for hours through forests etc. without ever having our connections going through the tunnel getting reset.
The BondingTCPOptimizer mode has been improved a lot. Before, it had compatibility issues, especially if a connection went through multiple BondingTCPOptimizer tunnels (site-to-site VPNs). Also, the performance of this mode has been improved a lot. We now recommend to use BondingTCPOptimizer for any TCP traffic when bonding links with very high latencies, even for site-to-site VPNs, as it will improve achievable throughput a lot.
Performance for the 500 router has been optimized a lot. In most situations, the maximum amount of bonded throughput is increased by over 30%.
VLAN IDs may now be configured for additional LAN routes.
LAN Aliases if a VLAN ID is assigned now may optionally have a default GW. If this is configured, then for traffic coming from the respective tunnel, segmentation ID will go to that default gateway, while the LAN interface (VLAN 0) will no longer be used (and that tunnel will no longer be reachable from VLAN 0).
The two new features above together allow ISPs/BSPs to have a dedicated VLAN on the Hub per customer, a feature requested by multiple service providers.
Webconfig system now logs user logins/logouts/errors.
A new set of QoS rules and classes has been created. Web surfing by default still used Bonding, for high-latency bondings this should be changed to BondingTCPOptimizer. RTMP stream always uses BondingTCPOptimizer by default. The rules for RTP/VoIP have been changed to match on ToS and therefore generate less false positives, and to also support video conferencing. The VoIP QoS class now uses Lossy Bonding if a license for that is available. To use the new rules, you need to go to "QoS rules and classes templates" and execute "Restore Manufacturing Defaults", then go to each tunnel and select "Copy QoS templates to here". You need to do this on both, the Hub and the Router!
There have been several buffer tunings going on. In many setups, throughput will improve, especially for connections using the "Bonding" mode. Also, performance for high-latency links and links with a high bandwidth-delay product (Satellite) has been improved.
Configuring ethernet auto-negotation settings is now supported for Fast & GigabitEthernet modules.
For high latency links (GPRS, Satellite), the passive and hybrid autotuning modes will now increase speed much slower so that the link is not overloaded without noticing it late.
The Router may now be reached from the LAN using the hostname "viprinet.router".
The "Resource Reservation Protocol" (RSVP) can now be routed through Viprinet Routers.
Min and Max commands inside CLI now work.
CLI is now displaying nicer datatype names on LIST.
LTE module signal info inside the monitoring tool is now updated more constantly.
Bug fixes:
Crash bugs in CLI have been fixed in regards of disconnects while still having a response in the pipeline.
Tab completion in CLI now works for VALUES, MIN, MAX commands.
Changing the WAN IP address on the VPN Hub with the Hub redundancy system enabled could cause the web interface to hang afterwards.
Hubs in Hotspare mode would display Hub features always as unlicensed. Now it gives a hint that licenses are not checked in Hotspare mode.
The 500 router would neither correctly output link information for the LAN port nor would it allow Ethernet parameters to be configured. Both now work.
Early retransmissions started by the "Retransmission multiplier" setting would cause channels to never go to stalled mode. This could cause these channels to continue being used. This bug was especially affecting performance in moving vehicles.
The 5 Ghz channel selection mechanism for the 500 WLAN AP was broken, only the first channel could be correctly selected.
In the previous stable firmware, the Hub redundancy system did not listen on the WAN interface. This could cause a split brain situation in Hub redundancy setups where the original Hub was fine, and only the LAN interface link was down. Now, the redundancy system uses both the LAN and WAN interfaces again.
If a value for 'Reset after minutes of downtime' for a module was configured, this was executed in this interval even when the module was disabled.
Configuring enumerations/references (QoS rules targets, WAN modules inside channels etc.) inside the CLI now works correctly.
Firmware Release 09/25/2012 - Version 2012091701/2012091800 (Multichannel VPN Router 500: 2012091720/2012091800)
This firmware release adds two more fixes to our major stable firmware released on September 7th. An update from that release to the current one is only required if your setup benefits from the two additional fixes:
Here is the list of changes:
Fixed: In all previous releases, there have been stability issues with hot-plugging LTE modules. Unplugging or power resetting an LTE module until now could cause the router to automatically reboot. This was especially inconvienient as the LTE technology on the carrier side is still rather unstable, and having automatic LTE module resets inside the Viprinet router would help here. With the current release, the issue is now fixed: LTE modules are fully hotplugging capable.
Fixed: With the availability of the new Hub 5010, this product now has been marked compatible to the Hub 5000 inside the firmware. Should you wish to run a mixed setup of Hub 5000 and Hub 5010 using the redundancy system, you need to upgrade the Hub 5000 to this firmware release.
Firmware Release 09/07/2012 - Version 2012081500/2012090600 (Multichannel VPN Router 500: 2012082420/2012090600)
This firmware release brings a huge number of quality and stability improvements. On the Multichannel VPN Router 500, the improvements are very significant. We recommend that all customers update all products to this firmware release.
Here is the list of all changes:
Bug fixes:
The new LossyBonding mode which became available in recent firmware releases to users of the Streaming Optimizations license has been faulty in all prior firmware releases. In many cases with the LossyBonding mode the receiving side of IP packets would see reordered packets, which caused a lot of performance troubles for many applications. LossyBonding with the release now brings the expected performance, and is recommended to be used whenever low-latency UDP traffic needs to be sent over instable bonded links (like UMTS/3G). It is especially recommended for live video streaming and conferencing.
Fixed: Under certain (rare) circumstances a power loss of the router while it was in progress of saving the configuration could cause corruption on the internal flash memory module. After a router reboot the router then would report a serial of "XX-XXXXX-XXXXX" and no longer function correctly.
On the Multichannel VPN Router 500 it was possible that suddenly all WAN modules "disappeared" and no longer had been usable. This problem could not be fixed with a router reboot, instead a full power cycle of the router was needed to get the WAN modules displayed again.
The NAT engine had several problems with some ICMP protocols. This could traceroutes from NATted IPs not to always work properly.
The IP broadcase detection has been improved. If in previous firmware releases a router was connected to a LAN where an IP network existed that wasn't also configured on the router, broadcasts from these IP networks were picked up by the router and forwarded to the VPN Tunnel. This unintended behaviour also causes "PacketHeap" error messages inside the router's log.
Previous firmware releases for the Multichannel VPN Router 500 contained a memory leak error. This error could cause the router to automatically reboot after several days of operation.
The BondingTCPOptimizer bonding mode contained a bug which under rare circumstances (for 0.25^12% of all packets) would cause the router to crash and reboot.
For the Hub redundancy system removing a test IP address did not cause the Hub router to actually stop pinging this IP, instead it continued to ping it until the next restart.
Traffic accounting features did not work properly on Multichannel VPN Router 500
On the Multichannel VPN Hub 5000 incoming VPN tunnel channel connections did not work correctly anymore once over about 200 channels had been connected.
Several bug fixes for SNMP, mostly for users of the extended SNMP license
If multiple WAN modules received a power reset at exactly the same moment (for example due to automatic timed reset being configured), sometimes not all of these modules would come back but instead got stuck powered off. Those modules were unavailable until the next router reboot.
Improvements:
The time zone to be used by the router may now be configured under "Logging & Maintenance"
The internal configuration system received a 20x speed boots. Especially with Hub setups containing a very high number of VPN tunnel channels changing a setting inside the webinterface in the past caused delays of multiple seconds. Even in this situations the configuration system now will respond promptly.
The Hybrid autotuning mode has been improved a lot and has received several bug fixes. Using the hybrid autotuning mode is highly recommended for any 3G/4G based channels, as it combines good tuning results with only very low test traffic overhead. The passive autotuning mode also has received similar improvements.
The ARP implementation now also uses IP packets coming in from the LAn to update the ARP cache. For devices on the LAN who haven't sent anything for a long time, this means that the first packet they send will already make them reachable on the LAN again, without a further ARP request. This brings an improvement for embedded devices with crippled TCP/IP stacks.
Firmware Update 06/19/2012 - Version 2012061200/2012061200 (for all products other than Multichannel VPN Hub 5000 and Multichannel VPN Router 500) / 2012032610/2012061200 (for Multichannel VPN Hub 5000 and Multichannel VPN Router 500)
This is a maintenance update for the firmware released on April 13th 2012.
This update is of importance to all customers who are using SNMP monitoring with routers and for all customers using the “Passive” and “Hybrid” channel auto-tuning modes. These customers should update quickly. For all other customers, this is still a recommended update.
Here is the list of all changes:
Bug fixes:
With the previous stable release, all SNMP counters may stop counting every 50 days. The next time SNMP counters will stop is expected to happen on June 20th 2012. If you are affected by this problem, you should update as soon as possible.
Hubs 5000 were reporting a CPU temperature of 0°C through SNMP. This is fixed.
In the previous stable firmware, the experimental SSH CLI running on port 22 by default was turned on. Now the factory default is for this service to be turned off and for port 22 to be closed.
In the previous stable firmware release, congestion detection had been added that would reduce the MaxBandwidthToWAN whenever congestion on the link due to packet loss got detected. This quick reducing the available bandwidth improved the latency of the channel. However, as we learned, for many installations, it also caused far more auto-tuning tests to happen, resulting in a strong increase in generated test traffic. This especially was the case if congestion happened while a speed test was running. This has now been optimized; the amount of test traffic should be back to normal. If traffic is costing you money, you should update soon.
The driver for our new Gigabit Ethernet modules had several issues. If you used static IP configuration with the Gigabit Ethernet modules, problems with link detection occurred. This release improves the stability of the Gigabit Ethernet modules a lot.
In all previous firmware releases, the “Passive” and “Hybrid” auto-tuning mode had a bug which could cause the speed auto-tuning to stall when it was started at very low speeds (200 kbit/s and below). In this case, the speed would be stuck therefore and never increasing again. This especially could be seen in moving vehicles with bonded UMTS, due to frequent cell changes including GPRS/EDGE cells. This bug is now fixed, and “Passive” and “Hybrid” auto-tuning modes perform as intended in these situations. If you are using the “Passive” or “Hybrid” auto-tuning modes, you should update soon.
We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmware update 04/13/2012 – Version 2012032600/2012041000
The latest firmware version for the Multichannel VPN Routers and Multichannel VPN Hubs constitutes no less than a revolution of functionality. The new release offers a vast number of new features, many of which have been desperately requested by partners and customers. Moreover, the firmware contains a number of bug fixes that provide higher system stability and throughput.
Changes compared to the previous cutting edge firmware release 2012020100/2012030101:
LTE modules are now supported and stable. Various issues that existed in the previous cutting edge release are now fixed, including hot-plugging issues, monitoring problems and module info errors. Hand-over between UMTS ↔ LTE now also appears to be working in real-life scenarios with moving vehicles.
Modules on the Multichannel VPN Router 500 may now be configured even while they are powered off due to the SIM card holder being opened.
On previous cutting edge firmware release 2012020100/2012030101, connections using BondingTCPOptimizer would sometimes hang on channel disconnects. This is fixed.
Due to an issue with SNMP encoding on previous cutting edge firmware release 2012020100/2012030101, you would sometimes get wrong values for 64 bit counters.
The Hub WAN link speed detection used as a parameter for channel autotuning was broken – it only detected the speed when the WAN did not have an Ethernet link. Therefore, Hubs were always reporting 0 MBit/s.
The "Enabled Mobile Technologies" was displayed for all module types. It's now only displayed for LTE modules.
Changes compared to the last stable firmware release 2011020901/2011051700:
New features:
Extended SNMP now uses its own, dedicated Viprinet MIB. To use extended SNMP, you need to have the extended SNMP feature licensed. MIB is available here: http://www.viprinet.com/downloads/viprinetmib.zip
A command line interface for the router is now available via SSH on port 22 if enabled inside the web interface. Usernames and passwords are used as defined inside the web interface. This is a beta feature; the CLI will be improved in upcoming firmware releases.
You may download the router's configuration using SFTP/SCP.
You may now view the ARP table of Ethernet devices (LAN, WAN, WAN modules) inside the web interface.
Gigabit Ethernet modules are now supported.
UMTS/HSPA, UMTS/HSPA+, CDMA and LTE modules now have a web interface tool to manually issue AT commands. This can be used for customization and activation that is required for some countries / mobile carriers.
Ethernet auto negotiation parameters may now be configured for the LAN interfaces, the WAN interfaces on Hubs and for Ethernet WAN modules.
If you have a Streaming Optimization license installed, a new bonding mode called LossyBonding is now available. This mode is optimized for bonding UDP traffic. Unlike all other bonding modes, it does not guarantee IP delivery, so there may be packet loss on the bonded tunnel. The mode uses a self-tuning dejitter buffer on the receiving side. With this mode, extremely low latencies with minimal jitter can be achieved for critical UDP traffic and applications like VoIP and live video conferencing.
Improvements:
A new set of improved QoS rules and classes are deployed with this release. To enable those, you need to use the "Restore Manufacturing Defaults" function inside the "QoS rules and classes templates" object, and then afterwards use the "Copy QoS templates to here" function in each tunnel object with which you wish to use the new QoS classes. Doing this is highly recommended. Take caution in case you have created custom QoS classes, as those would be overwritten by the copy.
Logging in with wrong username/password by HTTP or SSH now causes a random delay before returning an error. This slows down brute force password attacks.
The log format has been changed to always include the VPN tunnel name for channel messages. Until now, it was impossible to find out which tunnel a message was referring to if you had multiple tunnels using the same channel name (which is very common on shared VPN Hubs)
Huge improvements in regards to buffer management and QoS. In situations where the upstream is fully used by traffic, you now will be getting a far better performance for downstream traffic.
For test purposes, link stability checks can now be turned off using a setting inside the "Performance finetuning" object of a channel.
The number of log messages caused by the auto-tuning has been reduced.
Big autotuning improvements for bonded 3G in moving vehicles. Channels will now respond far quicker to short coverage outages, and will reestablish channels much faster. As a result, performance of Viprinet routers in moving vehicles with this firmware is highly improved.
The BondingTCPOptimizer mode had various issues with lots of TCP implementations and applications. Often, BondingTCPOptimizer connections would hang or fail, especially for SSL-based TCP connections. This has been improved a lot. We now recommend using the BondingTCPOptimizer mode for all TCP traffic going over bonded channels that have very high or unstable latencies, for example for bonding combinations of ADSL + UMTS.
Changes:
If you enable remote service connections to let Viprinet support staff access your router remotely, this now uses port 20022 (port 22 previously used in earlier firmware releases is now used by SSH CLI). Please update your firewall rules accordingly.
Bug fixes:
Several memory leaks have been fixed.
If you had 3 channels, with 2 configured as backup, it could happen that on dropout of the non-backup channels, both backup channels were set up on the same time, with both then getting shut down again because there already was a backup channel running.
Ping and Ethernet tools did not show error messages inside the web interface if hostname to test was unresolvable by DNS.
IP_IP and IP_IPV6 tunnels were not routed through the VPN tunnel but dropped.
Until now, all routers could be enabled for factory reset using the setup tool if all modules of the router were removed. This no longer works for all products which have a reset button to do a factory reset. You need to press that instead of removing modules.
If you used the 192.168.1.0/24 network on your router, ADSL modules would not work correctly anymore (internal IP address conflict). This is solved.
Under circumstances, Hub 5000 would see its own packets that it had sent to the LAN and report an "Incoming Packet from.. has incorrect TCP checksum" error message.
Ethernet broadcasts directed at an IP alias network under circumstances could result in an endless loop in routing and cause the router to drop out seeing any traffic for multiple seconds.
The maximum size of a config file backup was increased to 10 MB. Until now, with router installations with a high number of tunnels it was impossible to backup and restore the configuration.
Gratious ARP on WAN interfaces suffered from a race condition. After taking over a WAN IP address, this could make the takeover time take longer than expected with Hubs, because upstream routers did not get notified about the new MAC address for the IP at once.
The guaranteed bandwidth settings inside QoS classes did not fully work until now. The class might have gotten more or less the guaranteed bandwidth. This now works perfectly. Attention: If you have a QoS class configured that has a guarantee that's bigger than the total bonded WAN capacity, it means that your other QoS classes may not be allowed to do any traffic every time the QoS class with the guaranteed bandwidth is using the full capacity of the bonded tunnel!
If you copied a QoS class, the minimum diversity setting did not get copied over.
If on one side of a VPN tunnel channel encryption was enabled, and on the other side disabled, the log messages would not make it obvious that this is a misconfiguration, instead the channel would simply disconnect all the time. There now is a log message that makes it clear what is happening.
Pressing the reset button for factory reset did not work for Hubs that currently were running in Hotspare mode.
ADSL modules were sometimes reporting a wrong message about bandwidth capacity / sync values.
Internal early retransmissions (adjustable using the retransmission multiplier of the channel's fine-tuning settings) could lead to a "meltdown", if multiple links dropped out at the same time (for example 3x ADSL from same carrier, all lines show sudden high packet loss at the same time due to some cable interference). This could cause for not being able to transmit packets, because all channels would try to retransmit using the other channels that also want to retransmit.
Various fixes for SNMP protocol compliance and compatibility.
SNMP was using some amount of CPU per tunnel, not matter if the tunnel was active or not. For Hubs with a high number of tunnels (50+), this was causing very high CPU load and therefore bad router performance.
On the 500, there was a hidden ghost WLAN without an SSID in addition to the one configured. It was no security issue, as you could not connect to this WLAN, but irritating.
On the 500, bridging between LAN and WLAN did not work. This is now fixed; devices on the LAN can see WLAN devices and the other way round.
On the 500, switching the AP mode from 5 GHz to 2.4 GHz or back did not work until you rebooted the router.
The LAN IP configuration did allow CIDR notation, causing the interface to fail.
Hybrid and passive autotuning ignored turning off autotuning.
There have been various problems in regards to stability and throughput, if you had turned off channel encryption on the Hub 5000 product. With the 500, turning off encryption caused the channel to fail.
On Hub 5000, the maximum number of tunnel channels was limited to 200, this limit has been removed.
Known limitations:
Hub 5000 / SNMP: OID for CPULoad will return "" on Hub 5000
Hub 5000 / SNMP: Counter for tunnel channels not yet implemented (OID: 1.3.6.1.4.1.35424.1.6.2.1.9 and 1.3.6.1.4.1.35424.1.6.2.1.10)
Hub 5000: Ethernet auto negotiation parameters cannot be changed
We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmware update 07/22/2011 – Version 2011020901/2011062701
This is a maintenance update for the firmware released on May 11th, 2011 (Multichannel VPN Hub 1000: May 16th, 2011)
This update might be of importance to customers who are using a setup where commonly both the up- and downstream of all channels are fully used in combination with high-bandwidth links. The firmware versions released 11.05.2011/16.06.2011 might have degraded performance in these setups - the latency of the links could become much higher than in previous releases, possibly causing suboptimal throughput on the VPN tunnel level.
This has been resolved, the latencies of VPN tunnel channels are much more stable now even with high-bandwidth links.
Other than the former change, this release, which has gone through a long testing phase and is regarded the stable firmware release for the next few months, only brings some minor changes. We therefore recommend all customers to update to this firmware release.
Here is a list of all changes:
Fixed: The internal socket buffer tuning of tunnel channels was changed in the release from May, with the consequences outlined above. This has been optimized now, the socket buffer tuning no longer relies on the calculated Maximum Bandwidth to WAN, but instead uses the Current Bandwidth to WAN, optimizing latency for high-bandwidth links.
Fixed: The log message of a VPN Hub in hot spare mode in regards to comparisons on packet loss have been corrupt. Instead of a percentage, the IP address was displayed. This has been fixed.
Fixed: If you use the traffic accounting API on a Hub with a very high number of VPN tunnels, "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" messages would appear in the log, with traffic accounting entries getting lost. This is fixed, we now support a much larger backlog.
Fixed: The log message "Unable to submit traffic accounting data to server with URL..." now actually does output a URL to help with debugging your own implementations based on our traffic accounting API.
Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmware update 05/16/2011 – Version 2011020901/2011051700
This is an urgent update for the firmware released on 11th May 2011 for the Multichannel VPN Hub 1000. Other products are not affected.
We have to inform you that due to an error in our release and certification process, a significant error slipped through - in our firmware release for the Multichannel VPN Hub 1000, the hardware encryption acceleration was turned off. The Multichannel VPN Hub 1000, when using the firmware release 2011020901/2011051001, will show terrible performance when used with encrypted VPN Tunnel channels (which is the default).
If you have already updated your Multichannel VPN Router 1000 to the firmware release 2011020901/2011051001 last week, please immediately update again to the new release 2011020901/2011051700, which fixes this problem. There are no other changes in this firmware release.
For all other products, the issue does not exist, and the firmware release 2011020901/2011051001 is current. The releases 2011020901/2011051001 and 2011020901/2011051700 are 100% compatible to each other.
We are very sorry for any inconvenience caused. We've made sure that such an error cannot happen again in the future by again improving our release testing system.
Firmwareupdate 05/11/2011 – Version 2011020901/2011051001
This is a maintenance release bringing once again small fixes and improvements to our major release from December 2nd 2010. If you are using the "BondingTCPOptimizer" mode in your router setups, this is a critical release.
This maintenance release was designed for providing a long-time highly stable firmware version and therefore does not add new features. We recommend all customers to upgrade to this firmware release.
List of improvements and fixes:
Fixed: Recently, a third-party vendor has released products with a broken TCP/IP stack, which is sometimes sending broken TCP packets. Sadly, our BondingTCPOptimizer was sent into an endless loop if such a packet was transferred through a Viprinet router. This would basically make the router go out of service. If you are using BondingTCPOptimizer, this is a critical issue. The problem has been solved, and the BondingTCPOptimizer is now unsusceptible against all known kinds of TCP exploits.
Fixed: The new channel autotuning modes "Hybrid" and "Passive" still did do autotuning even if bandwidth autotuning was turned off for a channel.
Fixed: Under rare circumstances (particularly with the VPN Client), bandwidth autotuning could result in a negative bandwidth value.
Fixed: There was a very high load of ARP packets on the LAN interface. For many setups, far more ARP packets were sent than needed.
Improvement: The performance and latency of channels that are under 100% load have been improved, especially for slow channels with <500 KBit/s bandwidth.
Improvement: The monitoring API has been updated to v3. If you use the current monitoring tool from our website, in addition to channel information you will now see summary information for the tunnel. The previous monitoring API version v2 is still supported, old tools will continue to work as before.
Improvement: Summary information for bandwidth is now part of the tunnel's object inside the web configuration system.
Fixed: The web interface would sometimes log an "Internal Error".
Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmwareupdate 02/25/2011 – Version 2011010901/2011022500
This is a maintenance release bringing various fixes and improvements to our major release from December 2nd 2010. This update brings various bug fixes for problems reported by customers, general performance improvements for most usage scenarios, and new features for "Streaming Optimizations" license holders. For usage scenarios where very unstable WAN links are bonded (like UMTS while on the move), the performance improvements in regards of achievable stable bandwidth are enormous.
Unless you are affected by one of the fixed bugs, it is not critical to update to this release. However, due to the performance improvements, it is still a recommended update for all customers.
List of improvements, new features, and fixes:
Improvement: Performance Improvements for high-bandwidth setups. For Nodes and Hubs under high bandwidth load (>50 MBit/s) minimal packet loss could occur on the LAN board due to an Ethernet NIC issue. This could limit the achievable throughput especially for high-latency transfers through the VPN Tunnel. Packet loss will no longer occur in these situations.
Improvement: In past releases, the test data traffic generated by the bandwidth autotuning would limit the achievable throughput of real data traffic while a channel was under test. Every time a channel was doing speed tests, the total throughput that could be achieved through the bonded Tunnel would go down. This was especially an issue for situations where very unstable WAN links were bonded that needed re-testings often. Often in these cases, a bundle of 2x ADSL and 1x 3G/UMTS would give a lower real throughput than 2x ADSL alone, due to the unstable 3G link causing test data traffic very often. This has been completely changed: Now autotuning test traffic never will eat away real data traffic bandwidth, real traffic always will have a higher priority. Especially for setups where some or all bonded WAN links are unstable, the achievable constant throughput now will be much more stable than ever before.
New feature: In the past, when a channel was going down, depending on the "Maximum allowed Latency" settings of the channel data traffic using this channel could stall for 100-1500ms. This was because that internal re-transmissions were only triggered the moment a channel switched to "ConnectedStalled" status. In addition to that, these internal retransmissions now can also be triggered long before a channel stalls. The default now is that if a channel latency goes over 4 times the optimal latency, such a "speculative retransmit" is internally issued. The default multiplier should be fine, can however be adapted inside the "Performance finetuning" settings of the channel object.
New feature: For all channels and tunnels there are now internal statistics about the stability. The number of times a channel went down recently is taken into account, as is the number of times a channel stalled, as is the number of times and amount of packet loss seen. The stability value is displayed inside the Monitoring tool and inside the web interface.
New feature: The BondingDiversity bonding mode has been improved a lot. With older firmware versions, no matter how stable or unstable the channels were, redundant diversity copies were always sent as long as unused bandwidth was available. This caused a lot of traffic overhead, which especially was a problem whereever traffic is expensive (UMTS). The new BondingDiversity mode now offers a "Minimum diversity" and a "Maximum Diversity" setting, which allows you to configure the min/max number of copies of packets that should be sent. The actual number of copies now is automatically tuned between those min/max settings depending on the overall stability of the tunnel. If channels are unstable (for example because you are inside a moving vehicle, with frequent 3G cell changes), more copies of the packets will be sent, if the channels are stable, less copies will be sent. We highly recommend using the BondingDiversity mode for all applications where stable/low latency bandwidth (Streams, VoIP, Cloud Computing) should be done over highly unstable WAN links. Usage of this feature requires a valid "Streaming Optimizations" license for each router where it is going to be used.
Feature removed: The "Bestchannel" bonding mode has been removed, as it always has been a far worse choice than for example the default "Bonding" mode. The "LatencyPriority" setting also has been removed, because it only was used for the "Bestchannel" bonding mode
Feature removed: The "Minimize AutotuningTraffic" option has been removed. If traffic cost due to autotuning traffic is an issue, please switch either to "Hybrid" (recommended) or "Passive" (if you do not want to waste a single byte) autotuning methods, they work much better.
Improvement: The documentation of the Channel Finetuning settings inside the web interface has been improved, it should be now much clearer which parameters are dangerous to change.
Improvement: Hubs using our Hub redundancy system now start up much faster. There also have been lots of bug fixes in this area.
New feature: Inside the tunnel object, there are now statistics about the current total up- and downstream bandwidths available for the tunnel. There also is a set of statistics on how much bandwidth of that is regarded stable (currently available bandwidth from channel which are regarded as unstable is not counted in). We will be offering an API to use these values for streaming codec manufacturers soon. Contact our support team if you are interested.
Fixed: After a power-cycle, ADSL modules sometimes would not be correctly detected. Instead an empty slot was shown. This issue has been fixed.
Fixed: The traceroute tool inside the web interface didn't correctly work for the LAN interface.
Fixed: A very rare bug that in theory could result in router reboots has been fixed.
Fixed: The combination of doing a port forward at a VPN Hub pointing to a host behind a VPN Node could lead to issues in regards of reachabilty if multiple LAN aliases or VLANs were used at the Node. The router was issuing incorrect "ICMP redirect" messages.
Fixed: The LAN-Interface ARP implementation was having a lot of issues. If an IP inside the LAN was transferred from one PC to another (MAC address change), this could result in unreachability of this IP from the Node. All reported problems in regards of ARP have been fixed.
Fixed: Static DHCP entries didn't work if more than one entry was created.
Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmwareupdate 01/10/2011 – Version 2011010401/2011011003
This is a maintenance release bringing various fixes and improvements to our major release on December 2nd. This update also fixes an important issue introduced with the December 29th, 2010, firmware update. We recommend all customers to quickly update to this firmware release due to this. This update also introduces the option to configure static DHCP leases (and the ability to view the current lease table) as a new feature.
The following issues have been fixed:
Fixed: Both the December 2nd and the December 29th release contained a serious memory leak issue. For routers under high load (several thousand concurrent traffic flows going through a VPN Tunnel) this could cause the router to misbehave and/or reboot after a couple of days/weeks. This issue is now fixed.
Fixed: The December 29th release puts out the full VPN Tunnel setup dialogue between a VPN Hub and VPN Node / VPN Client to the log file. For connections between a VPN Hub with a firmware release older than December 2010 and for connections from VPN Clients this means that the VPN Tunnel password is written in clear text into the Log file. This is a security issue. The problem has been fixed, the dialogue no longer is logged.
Fixed: VPN Hubs did send back multiple ICMP replies when pinged at the LAN interface (not visible with Windows ping tool).
New feature: It is now possible to configure static DHCP leases at VPN Nodes.
New feature: It is now possible to view the current DHCP lease table at VPN Nodes.
New feature: The DHCP lease time is now configurable.
Fixed: The VPN Hub redundancy system had a number of problems and bugs. The redundancy system is now far more stable than before even in critical situations.
Fixed: A VPN Hub in "Hotspare" mode was unable to use DNS (and therefore also unable to do online firmware updates).
Fixed: All file upload dialogs (QoS config restore, config restore, firmware upload) allowed files of unlimited size to be uploaded, causing the router to reboot in worst-case. There now exists a file size limit.
Improvement: The SSL error messages are now easier to understand than before.
Fixed: The download test tool had various issues, especially with HTTP servers using Chunked Encoding. This is fixed. The download test tool will now automatically abort if the test download is causing a CPU load so high that VPN tunnel performance would be affected.
Fixed: The new autotuning methods "Hybrid" and "Heuristic" could result in Up-/Downstream values of 0/0 KBit or cause an Internal error after being run for a few days.
Fixed: It was possible to restore configuration files to router types which are not compatible with the source router. Routers that are treated compatible to each other for configuration restore are now Multichannel VPN Hub 1000/2000/5000 and Multichannel VPN Router 1600/1610/2610. The Multichannel VPN Router 300 configuration is not compatible with any other model.
Fixed: VLANs needed by external VDSL modems connected to an Ethernet modules didn't work correctly.
Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmwareupdate 12/29/2010 – Version 2010112901/2010122800
This is a maintenace release bringing various fixes to our major release that was released on December 2nd. For many customers, this is a non-critical update. However, if you are using SNMP on your routers, the BondingTCPOptimizer mode in your QoS classes, or wish to use the DHCP relay feature, it is highly recommended to update quickly.
The following issues have been fixed:
New Feature: All routers now fully support the new CDMA/EV-DO modules available to customers in North America.
The SNMP service had an issue that if enabled, a malformed SNMP query could cause a denial of service. This is now fixed.
If DHCP was configured to act as DHCP relay, the service would not come up automatically after a reboot, DHCP relay had to be restarted manually from the webinterface. This is now fixed, DHCP relay will automatically start up after a reboot.
Quite a lot of HTTP/HTTPS attacks to the webinterface did cause Internal Error messages in the logs. These were and are non-critical. The number of attacks that can cause these Internal Errors has been reduced.
The new "Heuristic" Autotuning method could result in Internal Errors when used with unstable links. These internal errors could potentially result in lowered performance or in worst-case, unresponsive VPN Nodes. This issue is now fixed.
SSL connection error messages will now more clearly state if they are related to VPN Tunnel connections or web interface connections.
Several "Debug"-class log messages have been removed.
Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.
Firmware update 12/02/2010 - Version 2010112901/2010120203
The latest firmware version for the Multichannel VPN Routers and Multichannel VPN Hubs constitutes no less than a revolution of functionality. The new release offers a vast number of new features, many of which have been desperately requested by partners and customers. Moreover, the firmware contains a number of bugfixes that provide higher system stability.
New features:
Huge performance increase: Compared to previous releases, the total bonded VPN throughput a router/hub can do has increased by about 30%.
User rights management system in AdminDesk - you now may create groups and users who only have read/write rights for certain objects. This can be used to enable customer access to their tunnel's settings only.
VPN Hub: You now may create port forwardings mapping destination IPs at the VPN Hub to private IPs behind VPN Tunnels
WAN VLAN Support: The Ethernet WAN modules now can use VLAN tagging. This is useful e.g. for external VDSL modems that require tagged Ethernet frames
VPN Hub: LAN/LAN alias VLAN support. You now may use multiple VLANs at the LAN interface of a VPN Hub. The main IP configured in LAN Settings always will be sent untagged (VLAN0) and serves as access to the public internet. Traffic going there from the Tunnels matching a NAT rule will be NATted. In addition, LAN aliases may use tagged VLANs. This way it becomes possible to have dedicated networks
"Tunnel segmentation" - similar to VLANs, you may group multiple tunnels by assigning them the same tunnel segmentation ID. Internally, all tunnels with a different segmentation ID are completely separate. This makes it possible to have multiple customers with multiple sites each terminated on one VPN Hub, where all sites per customer can see each other, but customers can't see other customer's networks. It is even possible to have multiple customers use the same private IP network - e.g. two customers that both use 10.0.0.0/8. If the tunnel segmentation ID chosen is the same as a VLAN ID assigned on a LAN interface, then traffic from all tunnels with this ID may exchange traffic with these VLANs, with all other customers not being able to reach the VLAN. Using this in combination with a VLAN-enabled switch at the VPN Hub allows for having local servers in the datacenter next to the VPN Hub, which become part of a customer’s VPN.
Local Firmware updates - you now may upload Firmware images using the web interface. This allows for the firmware to be updated in situations where the online updater is unable to connect to the Internet
QoS classes/rules export/import - You now may backup and restore collections of QoS rules and classes from/to Tunnels, VPN Client settings and the QoS Template object
BondingDiversity mode - inside the QoS classes, you may now select the new BondingDiversity mode. This mode will send duplicates of data packets over multiple channels. This way even with VERY unstable WAN link quality you are able to get a stable stream through the bonding - this helps a lot for low-latency-streaming, Citrix or VoIP over bonded UMTS/3G.
Several bandwidth autotuning methods are now available for selection per channel. There are huge improvements in regards of throughput for high-loss WAN links like UMTS. One of the new autotuning modes works without generating any artificial test traffic, which is useful whenever traffic is expensive (UMTS/3G).
For the TCP connection used by the Viprinet tunnel protocol, the congestion control method now can be used. Some are optimized for high-latency and high-loss links (UMTS, Satellite). "Hybla" for UMTS in many cases will drastically increase achievable throughput.
The monitoring tool will receive more data sources: The maximum allowed bandwidth for both directions of a channel will now be displayed; it is no longer needed to connect the monitor to both the VPN Hub and Node. In addition link stability and packet loss of the tunnel transport itself will be displayed. This allows for judging if there is a problem with the WAN link easily. This information also is available inside the Channel object inside the web interface.
MCC/MNC/LAC are now displayed for UMTS/3G modules inside the monitoring tool and web interface. This allows to track changes of the used cell
For UMTS/3G modules, APN auto configuration is now available. Using an integrated database of APN/username/password settings for various UMTS/3G providers in the world, the router will fully automatically configure these settings once a UMTS/3G module is plugged in. You no longer have to change any configuration setting if you exchange the SIM of a UMTS/3G module. Please report back if any UMTS/3G provider in your country is not detected!
The maximum interface link speed for various WAN media is now automatically detected and displayed inside the module Object. For UMTS/3G this value for example is adapted depending on current reception of GPRS/EDGE/UMTS/3G/HSPA, for ADSL this is the ATM sync rate. The value here also is internally shared with the VPN Hub, and used on both sides to optimize bandwidth autotuning.
New feature: It is now possible to run the integrated DHCP server on the node as a DHCP relay agent, forwarding DHCP requests to a central DHCP server located behind another VPN Node or a VPN Hub.
Enhancements:
Hybrid-Autotuning now uses an exponential approach at measuring maximum bandwidth on connect, followed by passive autotuning. This ensures an initial rough estimate of the possible bandwidth without relying only on user generated traffic.
Ethernet modules now show MAC-address in WAN Interface info
Configurable DNS servers. With the new DNS server settings you can run the Viprinet router in two different modi:
resolver: The router will work as recursive DNS server, requesting the 13 DNS root server
CachingProxy: The router will work as recursive DNS server, forwarding the DNS request to a editable list of nameserver and cache the look up
Configurable NTP server. Now it is possible to configure own NTP servers for time synchronization
Both in the module configuration section and the LAN configuration object there now exists a download test tool. This allows you to measure the speed, round-trip-time and packet loss while doing a HTTP- or HTTPS-download from a server through the physical link instead of the tunnel. Very useful for problem diagnosis - if your tunnel channel is showing, issues test the line using the download test tool, it is comparable to connecting a Laptop directly to the line modem (if all tunnel channels using the link are disabled during the test, that is)
Several fields that allow input of IP addresses or CIDR networks inside the web interface now do more accurate input validation.
Major Bug fixes:
Small Memory leak when reading ADSL module info. This caused issues for partners who periodically polled this info using an external tool.
The Hub redundancy system had various non-critical bugs. In case of a hotspare Hub taking over a broken active Hub and the administrator then converting this into a permanent replacement, all routers in this segment didn't notice this and kept complaining about a missing Hub.
Reading the CPU/System temperature was inaccurate
Space characters at the end of "IP to connect to" for tunnels/tunnel channels caused the connect to fail because the router would think this is a hostname
Lots of bugfixes for the BondingTCPOptimizer mode - in many cases performance should be much better now, compatibility should be highly improved. It is recommended to try the BondingTCPOptimizer for high-bandwidth/high-latency bonded WAN links for bulk traffic like HTTP and FTP.
We recommend that all customers presently convert to the latest firmware version in order to profit from the various features and improvements. If you need advice for the update, please contact our support team to fix an appointed date for upgrading at support@viprinet.com. Please do not update your system during weekends, as our support won’t be able to back you up then. As usual, we advise you to run all devices connected with a VPN tunnel with the same firmware version.
Firmware update 08/25/2010 – Version 2010063001/2010082300
In order to remove minor issues when using IPSec tunnels through Viprinet VPN tunnels, we have updated our firmware again.
This firmware update eliminates two minor problems:
When using permanent connections it might have occurred that a temporary tunnel breakdown (all tunnel channels disconnected) after reestablishing the tunnels led to stuck lines. This problem particularly occurred when using IPSec tunnels through Viprinet VPN tunnels (which we advise against). The update will solve the problem.
An error in handling packages with expired time to live within the bonding mode led to an unreliable function of multiple consecutive ICMP traceroutes. The update will solve the problem.
An immediate update is recommended only for customers that operate IPSec through a Viprinet VPN tunnel. For all other customers, this update is not pressing and can be performed during routine maintenance operations.
Notes on the update: Configuration changes are not needed for the update. As usual, we advise you to run all devices connected with a VPN tunnel with the same firmware version.
Firmware update 07/07/2010 - Version 2010063001/2010070600 (for Multichannel VPN Hub 1000 & Multichannel VPN Hub 2000 only)
At July 1st, we had released a new firmware for all Multichannel VPN Routers and Multichannel VPN Hubs. Unfortunately, this firmware version for Multichannel VPN Hubs 1000 and Multichannel VON Hubs 2000 contained a bug that might – depending on the actual configuration – cause that the Hub’s WAN/VPN interface cannot be reached via Internet any more.
Therefore, we have released another firmware update as of today for these two products. If you have already installed the July 1st firmware version on your VPN Hubs, we strongly advice an immediate update.
Products of the Multichannel VPN Router product line are not affected by this bug, hence there is no update for these devices. Multichannel VPN Hubs with a firmware older than July 1st, 2010, are not affected, either, updating to the new firmware is not considered as urgent.
Please note that we recommend to keep all devices connected with a VPN tunnel at the same firmware version. However, in this case there however will not be any problems caused by having the Multichannel VPN Hub using a slightly different firmware version than a connected Multichannel VPN Router – the versions released on July 1st (Multichannel VPN Routers) and todays release are fully compatible.
We want to apol