• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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 t

• 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.
• 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.

• 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.
• 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.
• 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.
• 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.

• For all local services (DNS, AdminDesk HTTP/HTTPS, SSH CLI, SNMP) there now are access control lists. Using this you can define which IPs and subnets from LAN or WAN/VPN may access services. Upon firmware upgrade, a set of default rules will be created. These are designed in a way not to interfere with existing installations, and it is recommended to tighten them. For example AdminDesk access currently is allowed both on HTTP and HTTPS from everywhere, while we recommend allowing only HTTPS from the Internet.
  PLEASE NOTE: Due to the new ACLs the AdminDesk SSL certificate settings have moved from “[ AdminDesk ] LAN settings” to “[ AdminDesk ] Integrated services”. Should you have installed your own custom SSL certificate, you will have to re-install it after firmware upgrade.
  PLEASE NOTE: All SNMP settings also got moved to “[ AdminDesk ] Integrated services”. After firmware upgrade, you will have to re-configure SNMP.
• There is now a fully automated diagnostics tool available, which will test throughput, packet loss etc for all interfaces. For VPN Nodes, local modules and also all modules from stacked routers are measured, as is VPN performance. For VPN Hubs, only the throughput of LAN and WAN interfaces are measured.
  Using this tool doing first diagnostics in all kinds of “I'm not getting the performance I've expected” kind of cases becomes far easier. We highly recommend you make good use of this tool.
  You can find the “Connectivity diagnostics tool” inside the “Logging & Maintenance” settings (old web interface only, not yet available in the new Web interface beta).
• If you wish to test optional router features, you may now generate a free 30 days trial license at https://license.vipri.net/trial.php using the Trial Token listed inside the router’s “Product features License Manager”.
  This web service will generate an activated license file that you then add inside the web interface. The generated license will activate all optional features of the router for a period of four weeks. It may be extended once using the web server, but afterwards the license remains locked for a month. Please note that at the end of the trial phase, the router will automatically reboot.
  Please note that Viprinet support will no longer manually issue trial licenses for router features. Please use the self-service system instead.
  The total of current Bandwidths from/to WAN of all channels is now available as a data source for the tunnel in the Monitoring API.  
• Some performance improvements, which result in all products roughly being able to have 5-10% more bonding capacity.

• There have been problems both with Hubs 5000 and Hubs 5010 that under certain circumstances the LAN interface could block, no longer receiving any packets. These problems have been fixed.
• There have been multiple bugs in regards of the Hub Redundancy system. If you would run a big number of VPN Hubs in a LAN segment in a data center, sometimes config file sharing would not work. Also, running multiple Hotspare Hubs for the same Hotspare group (which is a good idea) could sometimes (rarely) cause two Hotspare Hubs to take over the identity of a dropped out active Hub at the same time, causing an address conflict. All these bugs have been fixed, and running multiple Hotspares for a Redundancy group now works fine.
• Sometimes under rare circumstances, IP flows running through a VPN Tunnel could get stuck. In this case you would see “10001 packets in WANPacketHeap” in the log. This sometimes was seen with flows that run “forever” (like IPSec tunnels through a Viprinet tunnel) on systems where the Viprinet VPN Tunnel would often disconnect due to unstable WAN links. Flows no longer should get stuck in this case now.
• If BondingTCPOptimizer was used, certain corrupted TCP packets could cause a memory leak. A very high stream of these packets (for example in a DoS attack) sooner or later could make the router reboot.
• Small bugfix for BondingTCPOptimizer – with very slow servers, retransmissions of SYN packets could cause weird behavior. Seen in real-life with Samsung TVs and German VOD service Maxdome.
• Conflict resolution while restarting of stacked routers got improved.

• Highly improved channel bandwidth autotuning. You will now get much better results for all kinds of lines, especially Sat links. Hybrid autotuning will now get much better results on its initial tests on VPN Tunnels that are idle. Congestion on the channel will much less drastically slash down Max Bandwidth To WAN, which means you will see better performance on WAN links that have surges of packet loss.
• VLANs on Nodes are now supported in the following way:
  • In the LAN settings, there is now a "Allow route-back" option. If enabled, traffic coming in from a VLAN can be routed back to the same or a different VLAN – in other words, VLAN segments may talk to each other. If disabled, traffic coming in from the LAN with a destination on the LAN instead will be dropped, so the VLANs are completely separated in this case and all may only talk to the VPN Tunnel.
  • On the Node, you have the option “Allow all VLANs to talk to tunnel”. If that is enabled, all VLANs can talk to the tunnel; if disabled, only VLAN0 can.
  • In the WAN/VPN Routing settings on the Hub, you also have an “allow route-back” option. If disabled, traffic coming in from the Tunnel which would go back to the same tunnel (see above) again will be dropped.

Using these features, you can implement both a Node which has a local VLAN that is not allowed to talk to the VPN but to the remaining LAN, and you can also have a setup where you have multiple VLANs that really should be separated from each other but be able to speak to the VPN (for example, both a corporate network and a public visitor WLAN).

Please note that VLAN tags are NOT transported through the tunnel. On the Hub side, all traffic still will come out of a single tunnel with a single Tunnel Segmentation ID. If you need to deal with the networks routed separately, you need to create a VLAN on the Hub and route all traffic from the tunnel to a next-hop in this VLAN, where you separate the traffic according to their source IPs into different multiple VLANs again.

• All Routers and Hubs now have an integrated HTTP test traffic generator which can be enabled at [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads

If enabled, HTTP test downloads can be done from this router without requiring any sort of authentication. This should only be enabled while you are running tests yourself and turned off for production systems.

If enabled, a stream of random data can be downloaded from this router using the following URL:

http://[your router IP]/exec?module=download&speed=Speed&size=Size

Speed is in Bits per Second, 1K means 1 Kbit/s, 1M means 1 MBit/s, 1G means 1 Gbit/s. The speed parameter is optional. If this parameter is not given, the maximum possible link speed will be used. The maximum allowed value is 1G.

Size is the Size to download in Bytes, 1K means 1 KByte, 1M means 1 MByte, 1G means 1 GByte. The size parameter is optional, if not given, 16 GByte is assumed, which is also the maximum allowed value.

• Viprinet routers now contain a security feature to protect against the most common form of the DNS amplification attack – a single IP now is only allowed to do 2 ANY requests within 60 seconds. We still recommend implementing more advanced DNS Amp attack protections in your core firewall.
• The download test tool available in the LAN settings and module settings has been extended and improved a lot. It can now download test files from a world-wide content delivery network provided by Viprinet, which will automatically chose the Edge server nearest to you, or – if the Hub is using the Cutting Edge firmware – download from the Hub traffic generator. You now therefore have a tool which you can easily use to test for connectivity and throughput problems with WAN interfaces, and can easily check where your bandwidth bottleneck is. Use it!
• In the channel fine tuning settings, you can now define a minimum Link stability a channel is expected to have, with a warning getting sent to the log system in case the link stability goes lower than this value. For non-moving installations, a non-broken link should have more than 90% of stability, for moving vehicles it depends on the typical coverage. Using this setting, you can make it easier to automatically get notified of link problems (for example, a SIM card running into the traffic limit).
• The monitoring API used by the Viprinet Monitoring tool caused quite a lot of CPU load on the monitored router. That load has been decreased.
• In the past, the configuration system (both web interface and CLI) would use a global lock which could lock up the routing core for several seconds – for example, while you were applying LAN settings, the router would not route packets. This global lock now has been removed, and working in the web interface should no longer have drastic effects on the routing performance of Viprinet routers.

• A high number of SNMP bugs has been fixed. Most importantly, Hot spare Hubs that take over / replace a Hub now will correctly report normal full Viprinet SNMP on the IPs taken over, and give Hotspare SNMP replies on the Hotspare IP.
• SNMP no longer will change OIDs of other Tunnels if a Tunnel got deleted.
• SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature are now implemented.
• Due to a race condition, Node Stacking would sometimes crash in failover situations. Also, the “Failed to open slot for stacking” bug is fixed, as is the internal error 23239482394811Aa.
• Turning off configured stacking would result in the wrong error message “[Stacking] This router does not have the stacking featured licensed. Can not start stacking!”
• A Node Stacking slave would not stop the internal DHCP server in some cases. This would cause two DHCPs to run on the LAN, which caused problems.
• The firmware online updater always required you to click “check for updates now” TWICE to get an actual result. Now the first click works.
• ADSL modules sometimes have problems to get the module info read. We have increased the timeout for waiting for the modems diagnostics report reply. Please report to Viprinet in case you still get error messages trying to read module info from an ADSL module.
• Everything related to “Ethernet speed and auto-negotiation settings” has been reworked. There had been bugs that turning off auto-negotiation didn't work for some products and some Ethernet modules, bugs that turned off auto-negotiation was ignored on next router reboot, and tons of more bugs. All of these have been fixed, and we have validated that manually setting Ethernet parameters now works with all products and modules, also across reboots.
• The “Reconnect” function of Fast/Gigabit Ethernet modules no longer causes a PHY Reset / Ethernet​ Autonegotiation to restart. If you want that, reset the module instead.
• Using VLANs and an MTU of 1500 didn't work with Fast Ethernet Modules (but it did with Gigabit Ethernet modules). It now works with both.
• In reality, the routing core often would send more average bandwidth on a Channel than the Maximum Allowed Bandwidth to WAN would allow due to rounding errors. On some link types, this resulted in the link getting overloaded and the latency going up despite of perfectly correct autotuning results. These rounding errors have been fixed.
• In the current stable firmware release, changing anything about LAN settings including LAN Aliases will become effective even before you hit “Apply Settings”. This could also cause unclean state if you were in the middle of creating a LAN Alias.
• If “Allow remote service connections” was turned on, then turned off, remote service connections actually still were possible until your rebooted the router. Turning this off now will have immediate effect as expected.
• The download test tool very often would abort “due to high CPU load”, even if the CPU load wasn't that high.

• Complete overhaul of the LTE module monitoring code. This firmware now for the first time fully supports our 10-01031 and 10-01032 modules designed for USA and Canada. It also is much better at analyzing used technologies, and will also report the current frequency/Band that is used.
• The Viprinet router startup code has been optimized. Starting a Viprinet Hub that has tons of Tunnels is now much quicker than before.
• The routers now have a maximum number of Tunnels that can be configured. 
  PLEASE NOTE: This doesn't mean the router will actually be able to serve this many tunnels at the same time at acceptable performance - this also depends on the number of Channels per tunnel and complexity of QoS rules.
  ​Here are the maximum number of tunnels per product:
  • 300: 25
  • 500: 25
  • 1600/1610/2610/1620/2620: 50
  • 1000/1020: 100
  • 2000/2020: 150
  • 5000/5010: 500
• Until now, the Hub redundancy system was exclusively using Ethernet broadcasts for the Hubs to communicate with each other. Due to a technical limitation in the used communication protocol, Hubs could only share configuration files if their compressed size has been below 64k. Sadly there was no way for the user to judge on how big the current configuration would be. If the compressed config was above 64k, the Hub Redundancy system would fail syncing configuration files. For some Hub 5010 installations with a high number of tunnels and QoS configs this limitation was hit in real life.
  In addition the broadcasting protocol had a design problem - with a lot of VPN Hubs operating at the same time, it was possible for multiple Hubs to send their configuration to the Hotspare at exactly the same time. In this case due to fragmentation this could result in no config being received by the Hotspare. This problem got worse if multiple Hotspares were running for a single redundancy group.
  We have improved the Hub redundancy system in that the main communication still runs over Broadcasts, but that for config transfers now a direct TCP connection to the Hotspare is established. Due to this, the size of Hub configs to be synched now is unlimited. The new protocol has been designed in a way that is downward-compatible. This means that Hotspare Hubs running the current cutting edge firmware can still serve production Hubs who run the stable firmware and don't yet are able to sync configs using TCP. We still recommend having all Hubs in a redundancy group using the same firmware release, though.
• Until now, Viprinet routers would sometimes mark traffic flows as unroutable if the tunnel was down while the flow got established. Since the last stable firmware release, this got even stricter: Any traffic flow that was established before the tunnel was up would be marked unroutable forever. This was not expected to be a problem - most sane protocols would abort and reconnect. This isn't the case for e.g. ISAKMP of IPSec, which is a brain dead protocol - it always uses UDP source and destination port 500 by convention. This makes it impossible to differentiate these ISAKMP flows, and obviously causes also huge problems with NAT gateways. In Viprinet, if an IPSec Gateway would establish an IPSec tunnel before the Viprinet tunnel was up (for example because the Viprinet router got rebooted, but the IPSec gateway didn't), this would cause the ISAKMP flow to be marked unroutable forever. This is because the IPSec Gateway would never "abort", and even if it would, a new IPSec setup would look like the old one - as UDP source and destination ports would never change.
  Due to this, if the IPSec Gateway didn't use sane timeouts, this could lead to IPsec tunnels through a Viprinet tunnel to get stuck forever.
  This didn't cause any problem with IPSec gateways we have tested internally because with these, if the ISAKMP handshake fails, they wait a couple of seconds before retrying. By then, in the Viprinet router the UDP port 500 flow will have timed out, and the new ISAKMP setup will be regarded as a new flow, which due to the Viprinet tunnel now being up is marked routable.
  As we have learned, that's not how all IPSec gateways behave - some are hammering without any back-off in case the ISAKMP handshake doesn't work. That's a stupid design, but it is what it is.
  We have changed the routing design inside the Viprinet router to cope with these kinds of problems, while still getting optimal performance.
  Traffic flows marked as invalid/unroutable will now be rechecked every 2 seconds if in the meantime it became possible to route them. This way we neither have high load caused by systems flooding the router with unroutable destination IPs (which would enable some form of DoS), nor do we have a problem with protocols that hammer with always the same flow while the Viprinet tunnel is not up yet.
  ​It is impossible to test with all available IPSec gateway combinations, but with those that we have tested IPSec tunnels now typically get (re-)established within a couple of seconds after the Viprinet VPN Tunnel has come (back) up.

• The previous cutting edge firmware release didn't work with 50-00500 project router series. This one does again.
• A bug was fixed which could in rare situations cause a tunnel channel to abort connecting to the VPN Hub with an SSL handshake error.

• Complete overhaul of the LTE module monitoring code. This firmware now for the first time fully supports our 10-01031 and 10-01032 modules designed for USA and Canada. It also is much better at analyzing used technologies, and will also report the current frequency/Band that is used.
• The logic on which a config coming from a different router is marked compatible with which product has been rewritten. Now project routers are marked as compatible with themselves (another router of same model and project number) or with the standard model of the exact same product.
  Example:
  50-00300 is compatible to 50-00300 and 01-00300, but incompatible to 51-00300.
• The three different types of LTE modules will now automatically rename themselves to “LTE 700 AWS/UMTS/HSPA+/GPRS/EDGE” / “LTE/UMTS/HSPA+/GPRS/EDGE” / “LTE 700/CDMA/EV-DO” once the chipset model has been identified.
• VPN Clients connected to the Hub will now use Hybrid autotuning on the Hub instead of Heuristic. This reduces the amount of test traffic in situations where the PC's WAN connectivity is very unstable (say, a Laptop user sitting in a moving train).
• This release for the first time includes firmware builds for the upcoming Multichannel VPN Router 511 and 512 models.
• The new web interface got a new layout – status and editor are no longer tabs. We think that the new layout gives a better workflow.
• The new web interface now has "module info", "interface info" and "ARP table" tools. Still a lot of tools from the old web interface are missing, e.g. "ping", "traceroute" and "download test". These will be added in the next release.

• The previous cutting edge release did not support CDMA450 modules; slots would be shown as empty. This release re-adds support for these modules.
• The CLI now correctly should be supporting int64 and float values. Therefore, you now should be able to read GPS position data using the CLI.
• For LTE modules, the “Expected link capacity” value was wrongly set if the module used HSDPA. This was rarely seen in the EU, as here you typically get HSPA+ instead (=HSUPA and HSDPA+). If the combination has been HSUPA+HSDPA, you would end up with an expected link capacity of 384 kbps downstream, which would effect autotuning. However, the issue was frequently seen with AT&T and T-Mobile in the USA.
• On the 300 router, we have seen buffer overruns on the LAN interface in situations where there was a big spike of packets going out to the LAN. For instance, this happened when bonding unstable links, where data was released in huge spikes after a situation of packet loss / retransmissions. The problem would cause lost packets on the LAN. And these lost packets would result in application-layer TCP retransmissions, which with high latency links could limit the achievable throughput quite a lot. The problem would automatically improve after a couple of hours. However, this often meant that 300 routers in demo situations (just powered on to demo bonding of UMTS/LTE) would show unstable download speed.
  This problem should now be fixed.
  To validate, go to “[ AdminDesk ] LAN settings -> Ethernet interface info tool”.
  There, the “overruns” counters for TX and RX now should always stay at 0.
• A bug in BondingTCPOptimizer has been fixed – certain devices when sending a zero window could get stuck as the Linux-style of window probing that Viprinet used was ignored. We now also randomly do a Windows-style window probe (trying to send data which is out of the window). This fixes video streams getting stuck on Samsung Smart TVs.
• This release contains preliminary experimental support for the upcoming new VDSL modules.
• The trial license feature introduced in previous cutting edge firmware releases had a bug that caused the trial license to never actually expire.

• The new web interface is now feature complete, and all known bugs are fixed. It is now also used as a default.
• HTTPS usage for web interface access is now highly encouraged.
• The encryption for the web interface has been highly improved. We are now using 2048-bit RSA key + SHA256 certificated, TLS 1.2 and perfect forward secrecy (Elliptic curve Diffie–Hellman). At SSLabs, Viprinet routers score with an “A” mark.
• The encryption for the VPN Tunnels has been updated accordingly. In addition, the VPN Routers will now take a fingerprint of the VPN Hub’s SSL certificate, and reject re-connecting to it in case the fingerprint changes. This is done in a way that the fingerprint will neither change when changing VPN Hub Redundancy settings nor if you move over the VPN Hub configuration to a new VPN Hub. The new system prevents a theoretical Man-in-the-Middle attack against our products, where an attacker would place a device in front of the VPN Hub, stealing the VPN Hubs IP and pretending to be that device.
• For multiple authentication failures on the SSH CLI, further login attempts from the same IP are now throttled. This makes brute force attacks on SSH unfeasible.
• Channel Bandwidth Autotuning by default will no longer generate log messages. This highly reduces the number of log lines generated on busy VPN Hubs with lots of Tunnels/Channels. Logging can be turned back on a per-channel basis.
• Channel and WAN bandwidth reports now are only logged every 10 seconds, and if the link speed of a WAN device is unknown, it is no longer reported instead of reporting “0/0”.
• Our new VDSL modules are now fully supported.

• We have fixed a potential VPN Tunnel protocol downgrade attack. In a man-in-the-middle-attack an attacker could force a VPN Router to fall back to an outdated Viprinet VPN Tunnel protocol version where the Tunnel password would be sent over in clear text over the SSL connection. This way the tunnel password could be stolen, and a rogue VPN Router operated by the attacker could be connected to the VPN Hub instead of the real one, gaining access to the VPN. We would like to thank Portcullis Security for their research and advisory on this issue. The old VPN Tunnel protocol versions are now disabled.
• Both inside the old and new web interface, input filtering wasn't done properly, enabling all kinds of cross-site-scripting attacks (XSS) for logged in users. All known attacks are now properly filtered.
• From this release, you can no longer create objects (Tunnels, Channels etc) that contain illegal characters. Existing objects will still load. Check your log files for critical warnings on this, and rename all objects with illegal special characters in them – in the next firmware release, these objects will no longer be loaded.
• Hybrid autotuning had a bug that could lead to MaxBandwidthToWAN being set to “0” and staying there.
• If multiple users with the same user name were logged in to the web interface (new or old one, doesn't matter), every user would only receive a part of the log messages.
• If Channel Bandwidth Autotuning was turned off for a connected channel and MaxBandwidthToWAN manually set to “0” (as it is sometimes done on the VPN Hub to not use the downstream of an expensive UMTS/LTE link, but only use it as an upstream booster), various weird effects could occur. If the channel had the lowest latency, best LinkStability or lowest Cost, QoS classes could select this channel as the preferred one to use while not being able to actually transfer any traffic through it. Due to this, these QoS classes would no longer transport any traffic. Channels that have zero bandwidth now are ignored by the QoS system.
• In a Node Stacking setup, sometimes on the Slave device a DHCP service would be running while it should not.

• Multichannel VPN Router 200 is now supported (to be first displayed at CeBIT 2014).
• The new improved security features put a higher load onto the Hub when a channel is established. If a very high number of channels would connect to the Hub at the same time, the very high load would result in a kind of DoS on the Hub, and actually could lead to a load feedback loop: Due to the high load, the SSL handshake of the channels would not complete within the timeout range, and therefore disconnect and reconnect, causing even more load.
  You could see this in real life if you would reboot a Hub that is under heavy load with lots of tunnels, for example after a firmware update.
  We have now implemented throttling on both the Hub and the Router. If a channel is aborting during connecting to the Hub, it is now throttled instead of hammering the Hub with connects. On the Hub side, under situations of high CPU load, acceptance of new channels is delayed in a way which does not result in timeouts.
  With these changes, we are now able to survive a higher channel connection load on the Hub than with the current stable branch firmware (which has less secure SSL handshake).
• The behavior of Routers and Hubs during a DoS attack has been improved. If a source or destination host was doing more than 25,000 flows (TCP Connections), it would get blocked. However, if it was the Hub IP being attacked, this would result in the Hub IP itself also getting blocked, making for example the web interface of the Hub unreachable until for example a TCP SYN flood DoS was over. Now, locally bound router IPs are no longer blocked. Also, logging amount during DoS attacks caused significant CPU load. This has been reduced. A blocked host is now only logged once, and again once it is unblocked (which happens if the number of active flows goes below 24,000 again).
• VDSL modules now allow setting a VLAN.
• VDSL modules now support RFC1483 with static IPs, and allow special characters in PPP usernames and passwords.

• With the previous cutting edge firmware if you edit multiple channels at the same time using the Multi-edit feature of the new web interface, after you post your changes all your channels  will be using a single (the first) module. Only after the next channel reconnect, each channel would then use the same module; this means that performance may go down the drain hours after you have done the changes. This bug has been fixed.
• Multichannel VPN Routers 511, 512 and 513 now show the correct product name in the web interface.

• If you have Streaming Optimizations licensed, there now is a new bandwidth autotuning mode available: “Rapid Autotuning”. This mode is optimized for 3G/4G links used in vehicles moving at high speeds, while using multiple different carriers at the same time. Rapid Autotuning is similar to Passive Autotuning as it does not generate any artificial test traffic; it is, however, far more aggressive. In a moving vehicle, cell tower changes will happen very often, as will short spikes of packet loss. With existing autotuning modes, these often would cause the channel to re-start testing at very low speeds. Rapid Autotuning instead aggressively re-establishes the previous bandwidth after a short spike of packet loss and/or a cell tower change. Compared to Hybrid and Passive Autotuning, the amount of throughput with Rapid Autotuning has doubled in our tests in high-speed vehicles. If you are using bonded 3G/4G in moving vehicles, you most definitely should start using this mode.
• The new LTE module “10-01036 LTE/UMTS/HSPA+/GPRS/EDGE (AUS)” for Australia is now fully supported.
• The performance of the new web interface for Hubs where a lot of log messages are scrolling through has been highly improved. It's now finally usable even on busy Hubs.
• For all password fields, there now is a “change password” dialogue, which also measures and displays password strength.
• LTE modules that get rejected from the network now behave much nicer. Instead of  constantly hammering the carriers' networks, they now exponentially back off in case of multiple connection failures.
• The APN database got updated. Now, there internally is also a dedicated APN database  for carriers that uses an APN on LTE that is different from the one on UMTS. Due to this, it is now possible to have APN Auto Configuration enabled for almost any carrier. Also, APN Auto Configuration from now on is by default turned on for all UMTS/LTE modules (before it had been turned off by default).
• Internal time-outs for packet flows have been reduced. This is especially the case for TCP connections through the tunnel that ended by both sides having done the FIN/ACK close. These changes should be invisible to customers, with one exception: During a DoS attack against a network connected by a Viprinet router, the system load will now be dramatically lower.
• When a tunnel was down, every packet arriving for this tunnel would generate a “Dropped packet from LAN as Tunnel is down” warning log message. This message has been removed.
• The “AT command tool” is now also available for CDMA450 modules.

• On 5XX Routers, viewing configuration objects that contained combo boxes (Drop-down selection lists) could result in an internal error.
• The module info could not be read from VDSL modules in the new web interface, only in the old one. It now works in both.
• If an Ethernet module had its “Expected Link Speed” setting not on automatic mode but manually configured, this could confuse the “Online” LED control of that module if you pulled out the Ethernet cable and plugged it back in again.
• Even if the registration on a network hadn't been completed yet, LTE modules would already try to establish a data connection to that network. This would cause log messages complaining that the data connection failed due to lack of service. The modules now won't try to establish a data connection before coverage exists and network registration has been completed.
• Since the current Stable Firmware release, the routers would automatically save the configuration after start-up. This was done so that automatically generated SSL/SSH private keys would get stored to disk. However, in rare cases, modules in the router would not have fully started up by the time the configuration was saved, causing the router to save a config with some modules missing. If you now at some point rebooted the router without ever before having changed something in the web interface (causing the config to be saved), you could lose your module config on the next boot. Now, whenever a module is inserted or removed into a router, the configuration automatically will be saved. Due to this, you will no longer lose your configuration in the case described above.
• The Hub Redundancy System in the latest Stable Firmware release contained forgotten debug log messages. These have now been removed. Also, the amount of logging for the Hub Redundancy System during times where everything is fine has been drastically reduced.
• Some recent versions of our CDMA450 modules would always start up in power-save mode, never waking up from that. With this firmware release, these modules are now woken up during initialization.
• In some cases, uploading files to the router (QoS configuration restore, manual firmware update) through HTTPS could fail with a “Bad Request” error.
• In the current Stable release, every request to the old web interface is delayed between 1–2 seconds, making things really slow. While we highly recommend to move to the new web interface, this “punishment” for using the old web interface surely wasn't intended and is now fixed.
• In a stacking setup, the log message “New effective physical link capacity to WAN (based on remote report)...” for remote interfaces (those located on a slave router) would cause internal errors on the stacking master. After 1000 of these internal errors, the stacking master would reboot. This is now fixed.

• Hubs and Routers are now exchanging “boot IDs” informing the other side whether the remote end has rebooted, and thus can clear the flow state accordingly.
• VDSL advanced settings are now available.
• Viprinet Managed SIMs are now supported.
• Maintenance contracts are now supported by the firmware.
• New channel fine tuning setting “RapidReconnects”: If enabled, channels will very show a very aggressive reconnect behavior which includes restarting the WAN module used if a channel stalls for a longer time. Turn this option on only if the router is going to be used in a high-speed vehicle typically going faster than
• 100 km/h.
• When restoring a config backup, there now is an option “Do not overwrite existing licenses”. If this is set, licenses bound to the router prior to uploading the backup will stay intact.
• New function “Clear dynamic leases” inside the DHCP Server settings.

• If Latency Autotuning is turned off for a channel, the channel no longer will do a ping test when changing from ConnectedStalled to Connected. This way the channel can be used again much quicker after a short stall (e.g. when a vehicle is going through a highway tunnel).
• In very rare cases (high-speed trains), LTE modules could crash in a way that they were detected to be still up – forever. New watchdog code now makes sure that such "frozen" modules are automatically powercycled.
• Cell IDs are now properly reported with LTE modules (before they typically showed "0" as Cell ID).
• The receiving side of a BondingDiversity flow had a serious memory leak which after some time could cause that device to run out of memory.
• If power was lost at a specific moment during boot up on 5XX routers, the firmware storage could get corrupted which would cause the router to no longer be able to start up. This could be seen in installations where the 5XX router was used in a car that very often was powered on only for a couple of seconds before getting powered off again.
• The SSH CLI no longer listens on WAN interfaces as these cannot be controlled by an ACL.
• A couple of objects inside the web interface in previous firmware releases would ignore deletion attempts, e.g. licenses and stacked routers. Now these objects can successfully be deleted.
• On 5XX Routers, time zone management had been broken in all previous firmware releases. This caused reports to the traffic reporting server to use wrong timestamps, and also caused web browsers not to cache any elements of the web interface.
• Due to a bug, the QoS Class setting “Required Link Stability” has mostly been ignored in all firmware releases during the last year. Therefore, an unstable channel could ruin the throughput for tunnel traffic even if due to the “Required Link Stability” setting the unstable channel was not expected to be used. This fix will bring a significant improvement for setups where unstable links are bonded (moving vehicles).
• CDMA450 modules may crash when trying to reset them in a 5XX router. The reset option for these modules therefore now is ignored.
• The various forms of download test tools inside the web interface had problems on 5XX routers where they could get stuck or abort.
• Rights management for WAN modules has not been persistent and lost during router reboot, and also has not been marked as available in the new web interface. It now works, and therefore it’s possible to grant non-root users access to WAN module configuration.
• The download test tool would not abort downloading if you closed the download test tool window inside the new web interface, causing unneeded data traffic to occur.

• Sadly, the Cutting Edge Firmware released in July is suffering from a compiler bug on the Multichannel 200, 500 and 51X series. This bug can cause some subtle and hard-to-notice weird behavior. But even worse, with hosts doing lots of traffic flows, the router sooner or later can have all traffic flows stuck, wrongly accusing that host of doing a DoS attack and no longer allowing new flows from that host.
  This bug effectively can make some or all of your hosts in the LAN to sooner or later to no longer be able to talk to the router or the VPN/Internet!
  We therefore urge all our customers who have updated 200, 500 and 51X routers to July's Cutting Edge firmware releases to immediately update to the August release! No other product is affected by this bug. We apologize for any inconvenience. We have updated our internal test suites to be able to detect similar bugs in the future.
   
• New channel finetuning option “Save traffic when idle”: needed for Vodafone UK not to kick out idle channels out of the UMTS cell into some weird high-latency idle mode. This idle mode causes modems doing very low traffic to constantly getting thrown out of UMTS cell towers, with the need for them to then re-register. This idle mode causes an idle link latency of about 350ms, and a surge in packet loss and/or latency of up to 2500ms each time the channel starts to transmit significant amounts of bandwidth again – after that surge the behavior of the network turns back to normal. All of this can cause lots of troubles with achievable throughput and channel autotuning. We think that what Vodafone is doing here is a terrible idea and a standards violation, but we have to deal with it.
  The new “Save traffic when idle” option is enabled by default, which is identical to the behavior in previous firmware versions when this option didn't exist. If you disable the option, more idle ping traffic (about 10–15 KBit/s) will be generated, making sure the modem is not kicked out of the UMTS cell. However, you will burn more data traffic for this. We recommend disabling this option for the Vodafone UK network only.
  An alternative solution to the problem is to Disable Latency Autotuning for channels using Vodafone UK networks and inside the channel finetuning settings choose a “Optimal Latency below” value of 400ms, and a “Maximum allowed latency” value of 2500ms. This way the channel stays usable even if Vodafone UK enables the idle mode.
  Also 3G monitoring code can now detect this weird idle mode and will properly report it through monitoring tools as registration state “Normal / Idle”.

• Since last week, multiple exploits in the widely used bash-shell were discovered. While we don't use the bash shell in any direct way where it would be exposed to the outside world, it is used by the DHCP client service running for the WAN modules. There is an unconfirmed possible attack vector, in that if an attacker would be able to run a compromised DHCP server connected to a Viprinet WAN Ethernet module, and if this Ethernet module would be configured to use DHCP, the router could be made to execute code using manipulated DHCP options.
  
  This release incorporates all published patches to bash and to our knowledge fixes all known vulnerabilities.
  
  Until you have updated, disabling DHCP on WAN Ethernet modules and instead using static IP configured would also close the potential attack vector.
  
  To the best of our knowledge, there is no attack vector for VPN Hubs, and no attack vector with any other of our router or VPN services. 
• VDSL modules would always return “No answer received from modem” when checking module info
• CDMA450 modules had several problems with resetting and switching from/back to power saving mode. All of these issued have been fixed.
• In very rare cases, SIM initialization could fail for our LTE modules due to a Qualcomm bug. A work-around makes sure this no longer happens.
• By creating invalid port forwarding entries, you could create a port forwarding of doom which would lock you out of the router. You no longer can shoot yourself in the foot this way.
• If you would create a routing rule where all options would have been set to “Ignore” you would effectively create a default route, potentially locking yourself out of the router. This way of shooting yourself in the foot also no longer works.

• Default congestion control now is cubic, default autotuning Hybrid. There have been significant improvements to the Hybrid autotuning mode.
• Full support for final version of VDSL modules.
• A new HTTPS CA database is now used, which includes support for various CA's customers have requested.

• Managed SIMs got disabled after an hour of the activation server being unreachable, while they are meant to be disabled after 24 hours.
• When a VPN Client disconnected and a different client user later connected with the IP of the previous user getting re-used, this could cause to the VPN Hub crashing and rebooting.
• Access Point Settings were missing the option to configure administrative rights.
• On router startup, the error message “The tunnel password for the tunnel contains illegal characters” was printed to the log.
• If two or more WAN modules were power-cycled exactly at the same time, sometimes the modules would not come back, with a router reboot needed to get back the modules.
• TKIP is now disabled for HT clients on 5XX WLAN AP in 802.11n.
• Manual firmware updates may now also be uploaded if the automatic firmware check resulted in the “UpdatesAvailable” status.
• All 51X routers have their configuration files now marked as compatible to each other. Before 511, 512 and 513 weren't allowed to use 510 configuration and vice versa.
• Fixed Hub 5000/5010 picture size in web interface.
• If the SSH CLI was activated, a connection flood to port 22 could be used to run a DoS attack against the router.

• It is now possible to configure DNS servers for VPN Client groups. If done so, the VPN Client will use these DNS servers instead of using the Hub's DNS. This allows the VPN Client to be used in combination with a Domain controller, so VPN Client users can become part of a Windows domain.
• The new “4G Europe II” module is now supported.
• The CLI now supports ping, traceroute and moduleinfo tools (similar to what you can use in the web interface).

• Fixed race condition that caused update scripts to sometimes get called twice when starting them manually.
• Very big (100MB+) local update packages are now supported.
• Fixed the bug that offline firmware uploads are sometimes aborted, resulting in corrupted firmware uploads getting rejected. This happened if there was just 100ms without data getting sent during the upload. It mostly happened with the new web interface and when doing updates remotely.
• The distribution of system load on multi-core Hubs has been improved.
• Changed maintenance contract warning start to March 2015.
• Several improvements for LTE status reporting.
• Fixed a bug that caused OptimalLatencyBelow not to be displayed in monitoring API and -tool. 
• IP address of a replaced device in Hub hotspare mode is now shown in the new web interface.
• Several bug fixes for the channel congestion notification system.
• The SIM traffic reporting could end up in a state where it never committed its values to the accounting server.

• Using multiple of the new 4G modules could completely block the router in case the module had been unable to read home network information from the SIM.
• Network name display for some carriers (e.g. T-Mobile) was broken for the 4G Europe II module.
• Under very rare circumstances, corrupted SSL data could cause the Hub 5010 to crash and reboot.
• 4G modules used in a stacking slave for some mobile networks have been unable to connect.
• Under rare conditions WWAN modules may fail to read the IMSI and Home MCC/MNC from the SIM, causing Automatic APN Detection to fail.
• APN Database entries updated for AT&T USA, Rogers and Telus Canada.

• The license manager available in RuggedVPN is now also available in the classic firmware.
• The SupportID that is needed to register a router for the upcoming Viprinet Lifetime Maintenance System is now displayed.

• A rare crash bug on VPN Hubs caused by outdated VPN Clients connecting was fixed.
• In a node stacking setup, stacked Nodes would never share LAN routes.
• Fix for GPS not updating speed and heading.
• All products should be displaying CPU and System core temperature now. Please note that for some products a different temperature sensor deeper inside the CPU is now used. This may cause your CPU temperature to jump up by 10-20°C. This is not a problem and not a defect.
• QOS rules only matching on TOS did get ignored in the past.
• Updated all warning popups in regards of missing maintenance contract and RuggedVPN. We'd like to apologize for any confusion caused by these nag screens in previous firmware releases.
• When a classic router was connecting to a RuggedVPN Hub, under very rare circumstances traffic could have been blocked for QoS classes using BondingTCPOptimizer on the classic node.
• In the past, changing "Enabled mobile technologies" sometimes did not work, especially when executed on a module that right now has a data connection open. It now should always work.

A valid Warranty extension license that has not expired is now also counted for "Under Maintenance Contract". If your router still has Warranty left you therefore now are able to upgrade to RuggedVPN even if you haven't yet converted your Warranty license to a Viprinet Lifetime Maintenance contract. For warranty extensions we now also display how much days are left on it.

• A rare crash bug on VPN Hubs caused by outdated VPN Clients connecting was fixed.
• After router boot, a stacking master node could fail to bind its communication socket under rare circumstances, causing stacking slaves not to be able to connect to the master, which in turn would cause a split brain situation.
  In this worst case, the stacking master will now instead reboot to resolve this split brain.
• In very rare circumstances two stacking nodes right now being in a split conflict while at the exact same time reconnecting to a Hub with the tunnel previously having been disconnected for less than 3 minutes could cause the Hub to crash.
• In SNMP, vpnRouterCPULoad was exported as string instead of integer as it should be.
• For VDSL Modules the sync speed reported in the log ("Synched Downstream/Upstream Rate") was swapped. The actual values used were correct, so this is a display issue only.
• In case a VPN Hub had an invalid DNS resolver configuration, doing the DNS reverse lookup for incoming channel connections could take very long. In case of a lot of channels reconnecting, this could delay any connects to complete for a very long time. Now, incoming channel connections are no longer reverse-resolved.

• It is now allowed to upgrade from Classic to RuggedVPN without a maintenance license in place. A warning will be shown when doing so. Please note that RuggedVPN still requires a VLM subscription. However, you no longer have to do the VLM registration first before installing RuggedVPN firmware, but can do this after installing the RuggedVPN firmware.
• After installation of RuggedVPN, the router will keep working for 14 days. If no VLM license has been installed (or if the router hasn't been downgraded to Classic firmware) by then, the device will cease operation. This also allows our customers to trial RuggedVPN firmware.
• This Cutting Edge firmware introduces full support for Northern European LTE 450 modules.

• Licenses will now be deleted if instructed by the license server, and the online license deactivation function also is available now.
• Fixed bug that caused the device MCC/MNC not getting re-read in case the first read failed. This sometimes caused the APN auto detection to fail.
• Resetting or reconnecting an LTE module can cause the router's internal timer to get out of sync for up to two seconds. Due to this, channels will behave strangely: You can see high latency, channel stalls etc. This problem is now fixed. Reconnecting or resetting an LTE module no longer should affect other channels.
• Due to the Anti-DDoS connection limiter not being initialized correctly, in all previous firmware releases sometimes the config data transfers between active and Hotspare Hubs could fail with an SSL error.
• The maintenance license type "Iron" which will be used in OEM projects is now supported 
• It is now allowed to upgrade from Classic to RuggedVPN without a maintenance  license in place - now also works with old web interface
• Added missing "Deactivate" button for license manager
• A pre-existing config file from a previous RuggedVPN install will now be removed when doing a factory reset.
• There was a way to close SSH CLI connections without the connection limiter knowing. This could cause an IP getting locked out of the CLI forever after too many reconnects.
• License manager will now always use the right interface to do license activations and de-activations. Before it only worked if the default route was on a VPN Tunnel.
• The connection limiter / DDoS protection has been changed. HTTP, VPN, SSH, Stacking and Hotspare connections are now counted individually per IP.

• The license manager available in RuggedVPN is now also available in the classic firmware.
• The SupportID that is needed to register a router for the upcoming Viprinet Lifetime Maintenance System is now displayed.
• It is now allowed to upgrade from Classic to RuggedVPN without a maintenance license in place. A warning will be shown when doing so. Please note that RuggedVPN still requires a VLM subscription.  However, you no longer have to do the VLM registration first before installing RuggedVPN firmware, but can do this after installing it. After installation of RuggedVPN, the router will keep working for 14 days. If no VLM license has been installed (or if the router hasn't been downgraded to Classic firmware) by then, the device will cease operation. This also allows our customers to trial RuggedVPN firmware.
• This firmware introduces full support for Northern European LTE 450 modules.

• Using multiple of the new 4G modules could completely block the router in case the module had been unable to read home network information from the SIM.
• Network name display for some carriers (e.g. T-Mobile) was broken for the 4G Europe II module.
• Under very rare circumstances, corrupted SSL data could cause the Hub 5010 to crash and reboot.
• 4G modules used in a stacking slave for some mobile networks have been unable to connect.
• Under rare conditions WWAN modules may fail to read the IMSI and Home MCC/MNC from the SIM, causing Automatic APN Detection to fail.
• APN Database entries updated for AT&T USA, Rogers and Telus Canada.
• A rare crash bug on VPN Hubs caused by outdated VPN Clients connecting was fixed.
• In a node stacking setup, stacked Nodes would never share LAN routes.
• Fix for GPS not updating speed and heading.
• All products should be displaying CPU and System core temperature now. Please note that for some products a different temperature sensor deeper inside the CPU is now used. This may cause your CPU temperature to jump up by 10–20°C. This is not a problem and not a defect.
• QOS rules only matching on TOS did get ignored in the past.
• Updated all warning popups in regards of missing maintenance contract and RuggedVPN. We'd like to apologize for any confusion caused by these nag screens in previous firmware releases.
• When a classic router was connecting to a RuggedVPN Hub, under very rare circumstances traffic could have been blocked for QoS classes using BondingTCPOptimizer on the classic node.
• In the past, changing “Enabled mobile technologies” sometimes did not work, especially when executed on a module that right now has a data connection open. It now should always work.
• After router boot, a stacking master node could fail to bind its communication socket under rare circumstances, causing stacking slaves not to be able to connect to the master, which in turn would cause a  split brain situation. In this worst case, the stacking master will now instead reboot to resolve this split brain.
• In very rare circumstances two stacking nodes right now being in a split conflict while at the exact same time reconnecting to a Hub with the tunnel previously having been disconnected for less than 3 minutes could cause the Hub to crash.
• In SNMP, vpnRouterCPULoad was exported as string instead of integer as it should be.
• For VDSL Modules the sync speed reported in the log (“Synched Downstream/Upstream Rate”) was swapped. The actual values used were correct, so this is a display issue only.
• In case a VPN Hub had an invalid DNS resolver configuration, doing the DNS reverse lookup for incoming channel connections could take very long. In case of a lot of channels reconnecting, this could delay any connects to complete for a very long time. Now, incoming channel  connections are no longer reverse-resolved.  
• Licenses will now be deleted if instructed by the license server, and the online license deactivation function also is available now.
• Fixed bug that caused the device MCC/MNC not getting re-read in case the first read failed. This caused the APN auto detection to sometimes fail.
• Resetting or reconnecting an LTE module can cause the router's internal timer to get out of sync for up to two seconds. Due to this, channels will behave strangely – you can see high latency, channel stalls etc. This problem  is now fixed. Reconnecting or resetting an LTE module no longer should affect other channels.
• Due to the Anti-DDoS connection limiter not being initialized correctly, in all previous firmware releases sometimes the config data transfers between active and Hotspare Hubs could fail with an SSL error.
• The maintenance license type “Iron” which will be used in OEM projects is now supported 
• A pre-existing config file from a previous RuggedVPN install will now be removed when doing a factory reset
• There was a way to close SSH CLI connections without the connection limiter knowing. This could cause an IP getting locked out of the CLI forever after too many reconnects.
• License manager will now always use the right interface to do license activations and de-activations. Before it only worked if the default route was on a VPN Tunnel.
• The connection limiter / DDoS protection has been changed. HTTP, VPN, SSH, Stacking and Hotspare connections are now counted individually per IP.

• It is now possible to configure DNS servers for VPN Client groups. If done so, the VPN Client will use these DNS servers instead of using the Hub's DNS. This allows the VPN Client to be used in combination with a Domain controller, so VPN Client users can become part of a Windows domain.
• The new “4G Europe II” module is now supported.
• The CLI now supports ping, traceroute and moduleinfo tools (similar to what you can use in the web interface).

• Fixed race condition that caused update scripts to sometimes get called twice when starting them manually.
• Very big (100MB+) local update packages are now supported.
• Fixed the bug that offline firmware uploads are sometimes aborted, resulting in corrupted firmware uploads getting rejected. This happened if there was just 100ms without data getting sent during the upload. It mostly happened with the new web interface and when doing updates remotely.
• The distribution of system load on multi-core Hubs has been improved.
• Changed maintenance contract warning start to March 2015.
• Several improvements for LTE status reporting.
• Fixed a bug that caused OptimalLatencyBelow not to be displayed in monitoring API and -tool. 
• IP address of a replaced device in Hub hotspare mode is now shown in the new web interface.
• Several bug fixes for the channel congestion notification system.
• The SIM traffic reporting could end up in a state where it never committed its values to the accounting server.

• Since last week, multiple exploits in the widely used bash-shell were discovered. While we don't use the bash shell in any direct way where it would be exposed to the outside world, it is used by the DHCP client service running for the WAN modules. There is an unconfirmed possible attack vector, in that if an attacker would be able to run a compromised DHCP server connected to a Viprinet WAN Ethernet module, and if this Ethernet module would be configured to use DHCP, the router could be made to execute code using manipulated DHCP options.
  
  This release incorporates all published patches to bash and to our knowledge fixes all known vulnerabilities.
  
  Until you have updated, disabling DHCP on WAN Ethernet modules and instead using static IP configured would also close the potential attack vector.
  
  To the best of our knowledge, there is no attack vector for VPN Hubs, and no attack vector with any other of our router or VPN services. 
• VDSL modules would always return “No answer received from modem” when checking module info
• CDMA450 modules had several problems with resetting and switching from/back to power saving mode. All of these issued have been fixed.
• In very rare cases, SIM initialization could fail for our LTE modules due to a Qualcomm bug. A work-around makes sure this no longer happens.
• By creating invalid port forwarding entries, you could create a port forwarding of doom which would lock you out of the router. You no longer can shoot yourself in the foot this way.
• If you would create a routing rule where all options would have been set to “Ignore” you would effectively create a default route, potentially locking yourself out of the router. This way of shooting yourself in the foot also no longer works.

• Hubs and Routers are now exchanging “boot IDs” informing the other side whether the remote end has rebooted, and thus can clear the flow state accordingly.
• VDSL advanced settings are now available.
• Viprinet Managed SIMs are now supported.
• Maintenance contracts are now supported by the firmware.
• New channel fine tuning setting “RapidReconnects”: If enabled, channels will very show a very aggressive reconnect behavior which includes restarting the WAN module used if a channel stalls for a longer time. Turn this option on only if the router is going to be used in a high-speed vehicle typically going faster than
• 100 km/h.
• When restoring a config backup, there now is an option “Do not overwrite existing licenses”. If this is set, licenses bound to the router prior to uploading the backup will stay intact.
• New function “Clear dynamic leases” inside the DHCP Server settings.
• New channel finetuning option “Save traffic when idle”: needed for Vodafone UK not to kick out idle channels out of the UMTS cell into some weird high-latency idle mode. This idle mode causes modems doing very low traffic to constantly getting thrown out of UMTS cell towers, with the need for them to then re-register. This idle mode causes an idle link latency of about 350ms, and a surge in packet loss and/or latency of up to 2500ms each time the channel starts to transmit significant amounts of bandwidth again – after that surge the behavior of the network turns back to normal. All of this can cause lots of troubles with achievable throughput and channel autotuning. We think that what Vodafone is doing here is a terrible idea and a standards violation, but we have to deal with it.
  The new “Save traffic when idle” option is enabled by default, which is identical to the behavior in previous firmware versions when this option didn't exist. If you disable the option, more idle ping traffic (about 10–15 KBit/s) will be generated, making sure the modem is not kicked out of the UMTS cell. However, you will burn more data traffic for this. We recommend disabling this option for the Vodafone UK network only.
  An alternative solution to the problem is to Disable Latency Autotuning for channels using Vodafone UK networks and inside the channel finetuning settings choose a “Optimal Latency below” value of 400ms, and a “Maximum allowed latency” value of 2500ms. This way the channel stays usable even if Vodafone UK enables the idle mode.
  Also 3G monitoring code can now detect this weird idle mode and will properly report it through monitoring tools as registration state “Normal / Idle”.

• If Latency Autotuning is turned off for a channel, the channel no longer will do a ping test when changing from ConnectedStalled to Connected. This way the channel can be used again much quicker after a short stall (e.g. when a vehicle is going through a highway tunnel).
• In very rare cases (high-speed trains), LTE modules could crash in a way that they were detected to be still up – forever. New watchdog code now makes sure that such "frozen" modules are automatically powercycled.
• Cell IDs are now properly reported with LTE modules (before they typically showed "0" as Cell ID).
• The receiving side of a BondingDiversity flow had a serious memory leak which after some time could cause that device to run out of memory.
• If power was lost at a specific moment during boot up on 5XX routers, the firmware storage could get corrupted which would cause the router to no longer be able to start up. This could be seen in installations where the 5XX router was used in a car that very often was powered on only for a couple of seconds before getting powered off again.
• The SSH CLI no longer listens on WAN interfaces as these cannot be controlled by an ACL.
• A couple of objects inside the web interface in previous firmware releases would ignore deletion attempts, e.g. licenses and stacked routers. Now these objects can successfully be deleted.
• On 5XX Routers, time zone management had been broken in all previous firmware releases. This caused reports to the traffic reporting server to use wrong timestamps, and also caused web browsers not to cache any elements of the web interface.
• Due to a bug, the QoS Class setting “Required Link Stability” has mostly been ignored in all firmware releases during the last year. Therefore, an unstable channel could ruin the throughput for tunnel traffic even if due to the “Required Link Stability” setting the unstable channel was not expected to be used. This fix will bring a significant improvement for setups where unstable links are bonded (moving vehicles).
• CDMA450 modules may crash when trying to reset them in a 5XX router. The reset option for these modules therefore now is ignored.
• The various forms of download test tools inside the web interface had problems on 5XX routers where they could get stuck or abort.
• Rights management for WAN modules has not been persistent and lost during router reboot, and also has not been marked as available in the new web interface. It now works, and therefore it’s possible to grant non-root users access to WAN module configuration.
• The download test tool would not abort downloading if you closed the download test tool window inside the new web interface, causing unneeded data traffic to occur.

• The new web interface is now feature complete, and all known bugs are fixed. It is now also used as a default.
• HTTPS usage for web interface access is now highly encouraged.
• The encryption for the web interface has been highly improved. We are now using 2048-bit RSA key + SHA256 certificated, TLS 1.2 and Perfect Forward Secrecy (Elliptic curve Diffie–Hellman). At SSLabs, Viprinet routers score with an “A” mark.
• The encryption for the VPN tunnels has been updated accordingly. In addition, the VPN Routers will now take a fingerprint of the VPN Hub’s SSL certificate, and reject re-connecting to it in case the fingerprint changes. This is done in a way that the fingerprint will neither change when changing VPN Hub Redundancy settings nor if you move over the VPN Hub configuration to a new VPN Hub. The new system prevents a theoretical Man-in-the-Middle attack against our products, where an attacker would place a device in front of the VPN Hub, stealing the VPN Hubs IP and pretending to be that device.
• The new improved security features put a higher load onto the Hub when a channel is established. If a very high number of channels would connect to the Hub at the same time, the very high load would result in a kind of DoS on the Hub, and actually could lead to a load feedback loop: Due to the high load, the SSL handshake of the channels would not complete within the timeout range, and therefore disconnect and reconnect, causing even more load.
  We have now implemented throttling on both the Hub and the Router. If a channel is aborting during connecting to the Hub, it is now throttled instead of hammering the Hub with connects. On the Hub side, under situations of high CPU load, acceptance of new channels is delayed in a way which does not result in timeouts.
  With these changes we are now able to survive a higher channel connection load on the Hub than with the previous stable branch firmware (which has less secure SSL handshake).
• For multiple authentication failures on the SSH CLI, further login attempts from the same IP are now throttled. This makes brute force attacks on SSH unfeasible.
• The behavior of Routers and Hubs during a DoS attack has been improved. If a source or destination host was doing more than 25,000 flows (TCP Connections), it would get blocked. However, if it was the Hub IP being attacked, this would result in the Hub IP itself also getting blocked, making for example the web interface of the Hub unreachable until for example a TCP SYN flood DoS was over. Now, locally bound router IPs are no longer blocked. Also, logging amount during DoS attacks caused significant CPU load. This has been reduced. A blocked host is now only logged once, and again once it is unblocked (which happens if the number of active flows goes below 24,000 again).
• Channel Bandwidth Autotuning by default will no longer generate log messages. This highly reduces the number of log lines generated on busy VPN Hubs with lots of Tunnels/Channels. Logging can be turned back on a per-channel basis.
• Channel and WAN bandwidth reports now are only logged every 10 seconds, and if the link speed of a WAN device is unknown, it is no longer reported instead of reporting “0/0”.
• Our new VDSL modules are now fully supported (including VLANs and RFC1483)
• Multichannel VPN Router 200 is now supported (to be first displayed at CeBIT 2014).
• Complete overhaul of the LTE module monitoring code. This firmware now for the first time fully supports our 10-01031 and 10-01032 modules designed for USA and Canada. It also is much better at analyzing used technologies, and will also report the current frequency/Band that is used.
• The logic on which a config coming from a different router is marked compatible with which product has been rewritten. Now project routers are marked as compatible with themselves (another router of same model and project number) or with the standard model of the exact same product. Example: 50-00300 is compatible to 50-00300 and 01-00300, but incompatible to 51-00300.
• The three different types of LTE modules will now automatically rename themselves to “LTE 700 AWS/UMTS/HSPA+/GPRS/EDGE” / “LTE/UMTS/HSPA+/GPRS/EDGE” / “LTE 700/CDMA/EV-DO” once the chipset model has been identified.
• VPN Clients connected to the Hub will now use Hybrid autotuning on the Hub instead of Heuristic. This reduces the amount of test traffic in situations where the PC's WAN connectivity is very unstable (say, a  Laptop user sitting in a moving train).
• For all local services (DNS, AdminDesk HTTP/HTTPS, SSH CLI, SNMP), there now are access control lists. Using this you can define which IPs and subnets from LAN or WAN/VPN may access services. Upon firmware upgrade, a set of default rules will be created. These are designed in a way not to interfere with existing installations, and it is recommended to tighten them. For example AdminDesk access currently is allowed both on HTTP and HTTPS from everywhere, while we recommend allowing only HTTPS from the Internet.
  PLEASE NOTE: Due to the new ACLs the AdminDesk SSL certificate settings have moved from “[ AdminDesk ] LAN settings” to “[ AdminDesk ]  Integrated services”. Should you have installed your own custom SSL certificate, you will have to re-install it after firmware upgrade.
  PLEASE NOTE: All SNMP settings also got moved to “[ AdminDesk ]  Integrated services”. After firmware upgrade, you will have to re-configure SNMP.
• There is now a fully automated diagnostics tool available, which will test throughput, packet loss etc for all interfaces. For VPN Nodes, local modules and also all modules from stacked routers are measured,  as is VPN performance. For VPN Hubs, only the throughput of LAN and WAN interfaces are measured.
  Using this tool doing first diagnostics in all kinds of “I'm not getting the performance I've expected” kind of cases becomes far easier.  We highly recommend you make good use of this tool.
  You can find the “Connectivity diagnostics tool” inside the “Logging & Maintenance” settings (old web interface only, not yet available in the new Web interface beta).
• If you wish to test optional router features, you may now generate a free 30 days trial license at https://license.vipri.net/trial.php using the Trial Token listed inside the router’s “Product features License Manager”.
  This web service will generate an activated license file that you then add inside the web interface. The generated license will activate all optional features of the router for a period of four weeks. It may be extended once using the web server, but afterwards the license remains locked for a month. Please note that at the end of the trial phase, the router will automatically reboot.
  Please note that Viprinet support will no longer manually issue trial licenses for router features. Please use the self-service system instead.
• The total of current Bandwidths from/to WAN of all channels is now available as a data source for the tunnel in the Monitoring API.  
• Some performance improvements, which result in all products roughly being able to have 5–10% more bonding capacity.
• The Viprinet router startup code has been optimized. Starting a Viprinet Hub that has tons of Tunnels is now much quicker than before.
• The routers now have a maximum number of Tunnels that can be configured.
  PLEASE NOTE: This doesn't mean the router will actually be able to serve this many tunnels at the same time at acceptable performance – this also depends on the number of Channels per tunnel and complexity of QoS rules.
  Here are the maximum numbers of tunnels per product:
  • 300: 25
  • 500: 25
  • 1600/1610/2610/1620/2620: 50
  • 1000/1020: 100
  • 2000/2020: 150
  • 5000/5010: 500
• Until now, the Hub redundancy system was exclusively using Ethernet broadcasts for the Hubs to communicate with each other. Due to a technical limitation in the used communication protocol, Hubs could only share configuration files if their compressed size has been below 64k. Sadly there was no way for the user to judge on how big the current configuration would be. If the compressed config was above 64k, the Hub Redundancy system would fail syncing configuration files. For some Hub 5010 installations with a high number of tunnels and QoS configs this limitation was hit in real life.
  In addition the broadcasting protocol had a design problem – with a lot of VPN Hubs operating at the same time, it was possible for multiple Hubs to send their configuration to the Hotspare at exactly the same time. In this case due to fragmentation this could result in no config being received by the Hotspare. This problem got worse if multiple Hotspares were running for a single redundancy group.
  We have improved the Hub redundancy system in that the main communication still runs over Broadcasts, but that for config transfers now a direct TCP connection to the Hotspare is established. Due to this, the size of Hub configs to be synched now is unlimited. The new protocol has been designed in a way that is downward-compatible. This means that Hotspare Hubs running the current firmware can still serve productive Hubs that run the previous stable firmware and don't yet are able to sync configs using TCP. We still recommend having all Hubs in a redundancy group using the same firmware release, though.
• Until now, Viprinet routers would sometimes mark traffic flows as unroutable if the tunnel was down while the flow got established. Since the last stable firmware release, this got even stricter: Any traffic flow that was established before the tunnel was up would be marked unroutable forever. This was not expected to be a problem – most sane protocols would abort and reconnect. This isn't the case for e.g. ISAKMP of IPSec, which is a brain dead protocol – it always uses UDP source and destination port 500 by convention. This makes it impossible to differentiate these ISAKMP flows, and obviously causes also huge problems with NAT gateways. In Viprinet, if an IPSec Gateway would establish an IPSec tunnel before the Viprinet tunnel was up (for example because the Viprinet router got rebooted, but the IPSec gateway didn't), this would cause the ISAKMP flow to be marked unroutable forever. This is because the IPSec Gateway would never “abort“, and even if it would, a new IPSec setup would look like the old one – as UDP source and destination ports would never change.
  Due to this, if the IPSec Gateway didn't use sane timeouts, this could lead to IPsec tunnels through a Viprinet tunnel to get stuck forever.
  This didn't cause any problem with IPSec gateways we have tested internally because with these, if the ISAKMP handshake fails, they wait a couple of seconds before retrying. By then, in the Viprinet router the  UDP port 500 flow will have timed out, and the new ISAKMP setup will be  regarded as a new flow, which due to the Viprinet tunnel now being up is  marked routable.
  As we have learned, that's not how all IPSec gateways behave – some are hammering without any back-off in case the ISAKMP handshake doesn't work. That's a stupid design, but it is what it is.
  We have changed the routing design inside the Viprinet router to cope with these kinds of problems, while still getting optimal performance. Traffic flows marked as invalid/unroutable will now be rechecked every 2 seconds if in the meantime it became possible to route them. This way we neither have high load caused by systems flooding the router with unroutable destination IPs (which would enable some form of DoS), nor do we have a problem with protocols that hammer with always the same flow while the Viprinet tunnel is not up yet. It is impossible to test with all available IPSec gateway combinations, but with those that we have tested IPSec tunnels now typically get (re-)established within a couple of seconds after the Viprinet VPN Tunnel has come (back) up.

• We have fixed a potential VPN Tunnel protocol downgrade attack. In a man-in-the-middle-attack, an attacker could force a VPN Router to fall back to an outdated Viprinet VPN Tunnel protocol version where the Tunnel password would be sent over in clear text over the SSL connection. This way the tunnel password could be stolen, and a rogue VPN Router operated by the attacker could be connected to the VPN Hub instead of the real one, gaining access to the VPN. We would like to thank Portcullis Security for their research and advisory on this issue. The old VPN Tunnel protocol versions are now disabled.
• Both inside the old and new web interface, input filtering wasn't done properly, enabling all kinds of cross-site-scripting attacks (XSS) for logged in users. All known attacks are now properly filtered.
• From this release, you can no longer create objects (Tunnels, Channels etc) that contain illegal characters. Existing objects will still load. Check your log files for critical warnings on this, and rename all objects with illegal special characters in them – in the next firmware release, these objects will no longer be loaded.
• Hybrid autotuning had a bug that could lead to MaxBandwidthToWAN being set to “0” and staying there.
• If multiple users with the same user name were logged in to the web interface (new or old one, doesn't matter), every user would only receive a part of the log messages.
• If Channel Bandwidth Autotuning was turned off for a connected channel and MaxBandwidthToWAN manually set to “0” (as it is sometimes done on the VPN Hub to not use the downstream of an expensive UMTS/LTE link, but only use it as an upstream booster), various weird effects could occur. If the channel had the lowest latency, best LinkStability or lowest Cost, QoS classes could select this channel as the preferred one to use while not being able to actually transfer any traffic through it. Due to this, these QoS classes would no longer transport any traffic. Channels that have zero bandwidth now are ignored by the QoS system.
• In a Node Stacking setup, sometimes on the Slave device a DHCP service would be running while it should not.
• The CLI now correctly should be supporting int64 and float values. Therefore, you now should be able to read GPS position data using the CLI.
• For LTE modules, the “Expected link capacity” value was wrongly set if the module used HSDPA. This was rarely seen in the EU, as here you typically get HSPA+ instead (=HSUPA and HSDPA+). If the combination has been HSUPA+HSDPA, you would end up with an expected link capacity of 384 kbps downstream, which would affect autotuning. However, the issue was frequently seen with AT&T and T-Mobile in the USA.
• On the 300 router, we have seen buffer overruns on the LAN interface in situations where there was a big spike of packets going out to the LAN. For instance, this happened when bonding unstable links, where data was released in huge spikes after a situation of packet loss / retransmissions. The problem would cause lost packets on the LAN. And these lost packets would result in application-layer TCP retransmissions, which with high latency links could limit the achievable throughput quite a lot. The problem would automatically improve after a couple of hours. However, this often meant that 300 routers in demo situations (just powered on to demo bonding of UMTS/LTE) would show unstable download speed.
  This problem should now be fixed.
  To validate, go to “[ AdminDesk ] LAN settings -> Ethernet interface info tool”.
  There, the “overruns” counters for TX and RX now should always stay at 0.
• A bug in BondingTCPOptimizer has been fixed – certain devices when sending a zero window could get stuck as the Linux-style of window probing that Viprinet used was ignored. We now also randomly do a Windows-style window probe (trying to send data which is out of the window). This fixes video streams getting stuck on Samsung Smart TVs.
• This release contains preliminary experimental support for the upcoming new VDSL modules.
• There have been problems both with Hubs 5000 and Hubs 5010 that under certain circumstances the LAN interface could block, no longer receiving any packets. These problems have been fixed.
• There have been multiple bugs in regards of the Hub Redundancy system. If you would run a big number of VPN Hubs in a LAN segment in a data center, sometimes config file sharing would not work. Also, running multiple Hotspare Hubs for the same Hotspare group (which is a good idea) could sometimes (rarely) cause two Hotspare Hubs to take over the identity of a dropped out active Hub at the same time, causing an address conflict. All these bugs have been fixed, and running multiple Hotspares for a Redundancy group now works fine.
• Sometimes under rare circumstances, IP flows running through a VPN Tunnel could get stuck. In this case you would see “10001 packets in WANPacketHeap” in the log. This sometimes was seen with flows that run “forever” (like IPSec tunnels through a Viprinet tunnel) on systems where the Viprinet VPN Tunnel would often disconnect due to unstable WAN links. Flows no longer should get stuck in this case now.
• If BondingTCPOptimizer was used, certain corrupted TCP packets could cause a memory leak. A very high stream of these packets (for example in a DoS attack) sooner or later could make the router reboot.
• Small bugfix for BondingTCPOptimizer – with very slow servers, retransmissions of SYN packets could cause weird behavior. Seen in real-life with Samsung TVs and German VOD service Maxdome.
• Conflict resolution while restarting of stacked routers got improved.
• A bug was fixed which could in rare situations cause a tunnel channel to abort connecting to the VPN Hub with an SSL handshake error.

• A couple of bugs existed in a Stacking setup with more than 2 routers. A slave switching from an old to a new master could crash, alternatively some of the shared modules of the slave would no longer work after the switch.
• The "Download Test Tool" inside the web interface could crash / reboot the router.

We recommend all customers who have previously updated to the 2013051031/2013060600 release to update their routers a second time. All other customers are recommended to also update to the current firmware release to make use of the various improvements the June 2013 stable release has brought.

• Important: All our recent firmware releases (stable and cutting edge releases since April 2013) contained a critical bug: If a VPN Tunnel got established, then disconnected, then reconnected, then disconnected with then keeping it disconnected for more than 3 minutes, both the Router and Hub could crash and reboot.
  We are sorry for any inconveniences this may have caused to customers, and like to thank those of our partners who have spotted and reported the bug.
  Due to this bug, we’ve decided to withdraw all firmware releases since April 2013 from our servers. If you are using one of the affected releases, please update immediately.
• The download test tool inside the web interface would crash the router if the test file downloaded was using HTTPS.
• Sometimes, Tunnel Channels on connect would disconnect and reconnect due to an SSL handshake error, and it would take a while until they would finally connect. This no longer happens; this random handshake error is fixed.
• Passive and Hybrid autotuning, which are recommended to be used for mobile links (UMTS, LTE, Sat), had a tendency to optimize the Max Bandwidth To WAN to a value slightly above the actual optimal value. This would cause buffering on the channel, to be seen in the monitoring as a “sawtooth” like shape on both Latency and actual traffic through this channel. The autotuning has been improved to increase speed more slowly in cases where it is close to the “Optimal Latency Below” cut-off value.
  This optimization improves stability of latency-critical applications like VoIP over unstable links a lot.
• The 1020 and 2020 Hubs would sometimes report one or two of the fans to be turning too slowly, and would alert that those probably are broken. This isn’t actually the case, the minimum RPM of the fans had been lowered for these products compared to other products.
• The download test tool quite often would abort due to too high CPU usage. It now is a bit more relaxed about that.
• The Hub redundancy system now correctly marks the 1000, 1020, 2000 and 2020 Hubs to be compatible to each other. In previous releases, 1020 and 2020 were marked incompatible to the previous product generations.

• Highly improved channel bandwidth autotuning. You will now get much better results for all kinds of lines, especially Sat links. Hybrid autotuning will now get much better results on its initial tests on VPN Tunnels that are idle. Congestion on the channel will much less drastically slash down Max Bandwidth To WAN, which means you will see better performance on WAN links that have surges of packet loss.
• VLANs on Nodes are now supported in the following way:
  • In the LAN settings, there is now a "Allow route-back" option. If enabled, traffic coming in from a VLAN can be routed back to the same or a different VLAN – in other words, VLAN segments may talk to each other. If disabled, traffic coming in from the LAN with a destination on the LAN instead will be dropped, so the VLANs are completely separated in this case and all may only talk to the VPN Tunnel.
  • On the Node, you have the option “Allow all VLANs to talk to tunnel”. If that is enabled, all VLANs can talk to the tunnel; if disabled, only VLAN0 can.
  • In the WAN/VPN Routing settings on the Hub, you also have an “allow route-back” option. If disabled, traffic coming in from the Tunnel which would go back to the same tunnel (see above) again will be dropped.

Using these features, you can implement both a Node which has a local VLAN that is not allowed to talk to the VPN but to the remaining LAN, and you can also have a setup where you have multiple VLANs that really should be separated from each other but be able to speak to the VPN (for example, both a corporate network and a public visitor WLAN).

Please note that VLAN tags are NOT transported through the tunnel. On the Hub side, all traffic still will come out of a single tunnel with a single Tunnel Segmentation ID. If you need to deal with the networks routed separately, you need to create a VLAN on the Hub and route all traffic from the tunnel to a next-hop in this VLAN, where you separate the traffic according to their source IPs into different multiple VLANs again.

• All Routers and Hubs now have an integrated HTTP test traffic generator which can be enabled at [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads

If enabled, HTTP test downloads can be done from this router without requiring any sort of authentication. This should only be enabled while you are running tests yourself and turned off for production systems.

If enabled, a stream of random data can be downloaded from this router using the following URL: 

http://[your router IP]/exec?module=download&speed=Speed&size=Size

Speed is in Bits per Second, 1K means 1 Kbit/s, 1M means 1 MBit/s, 1G means 1 Gbit/s. The speed parameter is optional. If this parameter is not given, the maximum possible link speed will be used. The maximum allowed value is 1G.

Size is the Size to download in Bytes, 1K means 1 KByte, 1M means 1 MByte, 1G means 1 GByte. The size parameter is optional, if not given, 16 GByte is assumed, which is also the maximum allowed value.

• Viprinet routers now contain a security feature to protect against the most common form of the DNS amplification attack – a single IP now is only allowed to do 2 ANY requests within 60 seconds. We still recommend implementing more advanced DNS Amp attack protections in your core firewall.
• The download test tool available in the LAN settings and module settings has been extended and improved a lot. It can now download test files from a world-wide content delivery network provided by Viprinet, which will automatically chose the Edge server nearest to you, or – if the Hub is using this firmware – download from the Hub traffic generator. You now therefore have a tool which you can easily use to test for connectivity and throughput problems with WAN interfaces, and can easily check where your bandwidth bottleneck is. Use it!
• In the channel fine tuning settings, you can now define a minimum Link stability a channel is expected to have, with a warning getting sent to the log system in case the link stability goes lower than this value. For non-moving installations, a non-broken link should have more than 90% of stability, for moving vehicles it depends on the typical coverage. Using this setting, you can make it easier to automatically get notified of link problems (for example, a SIM card running into the traffic limit).
• The monitoring API used by the Viprinet Monitoring tool caused quite a lot of CPU load on the monitored router. That load has been decreased.
• In the past, the configuration system (both web interface and CLI) would use a global lock which could lock up the routing core for several seconds – for example, while you were applying LAN settings, the router would not route packets. This global lock now has been removed, and working in the web interface should no longer have drastic effects on the routing performance of Viprinet routers.

• If VPN Clients would connect/disconnect from VPN Hubs in a certain time pattern, sooner or later the VPN Hub could crash and reboot. This would most likely happen if a VPN Client connected to a VPN Hub, then disconnected and reconnected immediately, and then disconnect for at least 3 minutes before reconnecting. The problem is now fixed, VPN Clients no longer can crash VPN Hubs.
• Fix in heuristic Autotuning: In theory (not seen in real life) autotuning could be stuck in an endless loop, causing lots of test traffic.
• A high number of SNMP bugs has been fixed. Most importantly, Hot spare Hubs that take over / replace a Hub now will correctly report normal full Viprinet SNMP on the IPs taken over, and give Hotspare SNMP replies on the Hotspare IP.
• SNMP no longer will change OIDs of other Tunnels if a Tunnel got deleted.
• SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature are now implemented.
• Due to a race condition, Node Stacking would sometimes crash in failover situations. Also, the “Failed to open slot for stacking” bug is fixed, as is the internal error 23239482394811Aa.
• Turning off configured stacking would result in the wrong error message “[Stacking] This router does not have the stacking featured licensed. Can not start stacking!”
• A Node Stacking slave would not stop the internal DHCP server in some cases. This would cause two DHCPs to run on the LAN, which caused problems.
• The firmware online updater always required you to click “check for updates now” TWICE to get an actual result. Now the first click works.
• ADSL modules sometimes have problems to get the module info read. We have increased the timeout for waiting for the modems diagnostics report reply. Please report to Viprinet in case you still get error messages trying to read module info from an ADSL module.
• Everything related to “Ethernet speed and auto-negotiation settings” has been reworked. There had been bugs that turning off auto-negotiation didn't work for some products and some Ethernet modules, bugs that turned off auto-negotiation was ignored on next router reboot, and tons of more bugs. All of these have been fixed, and we have validated that manually setting Ethernet parameters now works with all products and modules, also across reboots.
• The “Reconnect” function of Fast/Gigabit Ethernet modules no longer causes a PHY Reset / Ethernet Autonegotiation to restart. If you want that, reset the module instead.
• Using VLANs and an MTU of 1500 didn't work with Fast Ethernet Modules (but it did with Gigabit Ethernet modules). It now works with both.
• In reality, the routing core often would send more average bandwidth on a Channel than the Maximum Allowed Bandwidth to WAN would allow due to rounding errors. On some link types, this resulted in the link getting overloaded and the latency going up despite of perfectly correct autotuning results. These rounding errors have been fixed.
• In the last stable firmware release, changing anything about LAN settings including LAN Aliases will become effective even before you hit “Apply Settings”. This could also cause unclean state if you were in the middle of creating a LAN Alias.
• If “Allow remote service connections” was turned on, then turned off, remote service connections actually still were possible until your rebooted the router. Turning this off now will have immediate effect as expected.
• The download test tool very often would abort “due to high CPU load”, even if the CPU load wasn't that high.

• Channels now may have backup scores, and the tunnel can have a minimum required backup score. This allows you to do setups where if one master channel goes down, multiple backup channels are brought up at the same time until the loss in "score" is compensated for. The router will bring up more backup channels until the tunnel's minimum backup score value is reached. The backup score of a channel also is multiplied with the Link stability value of the channel, which results in unstable channels not getting the full score. This way, a protection against link flapping is also provided.
• Using Stacking, multiple node routers can form a stack, becoming one big router. One of the routers will be the designated master router, using the other routers who are acting as slaves. If a slave router breaks, only the channels running over the slave router will go down. If the master router breaks, a slave router will automatically become the new master. If the designated master router comes back, an automatic failback takes place. For all of this to work, the current master router is constantly synching most parts of the router configuration with the slaves. Also, the current master router carries at least one dedicated IP address in the LAN which is also taken over if another slave becomes master. This shared IP is used as the gateway in the LAN. Detailed instructions on how to setup stacking are available. Stacking requires an add-on software license to be used.
• If the router is equipped with a GPS receiver (for modular router that means that you are using at least one LTE/GPS module), the router may now report its current position. With the new web interface, a Google Maps integration is also available.
• Channels now have a "Cost" setting. Channels with lower cost will be preferred if not all available bandwidth is used right now. You therefore now can have e.g. ADSL channels which are cheap to take most of the load, and use UMTS/LTE channels for traffic spikes.           
  This feature still has issues if you define more than 2 different cost levels.
•  A new modern looking web interface is now optionally available in parallel to the old one. The new web interface speeds up administration of routers dramatically. For example, you can edit multiple similar objects at the same time (for example all channels of a tunnel). The new web interface requires a current web browser (IE9+, Firefox 3.6+).
• In future firmware releases, we will limit the allowed characters in object names and string properties. Only the following characters will be allowed: 
  'a'..'z', 'A'..'Z', '0'..'9', '-', '+', '.', '_', ' ', '#', '(', ')', '/'
  If you are currently using other characters anywhere (tunnel or channel names, routing rules, router names, etc), please change them. Starting with this firmware release, a warning will be put to the log every time illegal characters are used.
  The reason for this change is to work against injection attacks on various levels.
• User-created objects like tunnels and QoS classes now should use only about 1/4 of the memory they used before. This should allow for a much higher number of configured tunnels and QoS objects on Hubs than before.
• The used root servers for the DNS service have been updated.
• This release for the first time fully supports our new CDMA 450 MHz modules to be used in Northern and Eastern Europe. The support previously released in the stable firmware released in February was incomplete. Use this firmware if you want to use CDMA 450 MHz modules. *)
• Highly improved LTE monitoring support, highly improved support for having multiple LTE modules in a single router. If you are using LTE, upgrade to this release. *)
• Hub 1020 and 2020 are now fully supported. This firmware release is required to run 1020/2020. *)
• CPU load is now monitored and reported through the web interface and SNMP. *)
• Several Ethernet auto-negotiation fixes. Auto neg now works for the 500 LAN port and the Gigabit Ethernet Modules. *)
• Until now, fully using the up- and downstream of a channel at the same time would overload the channel and cause high latencies because the downstream would cause ACK traffic on the upstream for the tunnel channel connection and vice versa. This is improved now. *)
• Changing QoS classes that were in use (for example by executing "Copy QoS templates to here" on a running tunnel) could crash the router or cause it to get stuck. This no longer happens. *)
• It was possible to get internal errors or crashes if you deleted the Default QoS class. This is fixed. In worst-case situations where the Default QoS class no longer exists, the first available class instead will be used. *)
• There now is a "reconnect" function available for tunnels. *)
• If a tunnel was moved from one Node to a different one, sometimes the Hub would report the error "A channel of this tunnel is already connected to a different VPN Node" even if no channel from the old node was still connected. This is now fixed. *)
• If an LTE module was idle (module connected, but no tunnel channel going through it), it would first go "dormant", then disconnect, then reconnect, with this cycle going on forever. This is now fixed, LTE modules will no longer disconnect for being dormant. *)
• If tunnel segmentation on the Hub was used, TCP connections that had been established coming from a tunnel on Seg 0 going to some other Segment tunnel would time out after 30 seconds if unused. This would cause for example idle SSH connections between these segments to hang. *)

*) These improvements already had been available in the "cutting edge" Firmware released in April 2013.

• The dreaded Internal Error Code 513791371A2237AE should be gone – it was a bug in Heuristic auto tuning.
• There has been a race condition on the Hub. If two nodes would connect channels to the Hub exactly at the same time, the Hub may have entered an inconsistent state where one Channel of Node A was connected, but the Hub's tunnel believed it was connected to Node B. This caused the Node A then to not be able to connect further channels. This situation could happen in larger stacks when routers were rebooted or power-cycled, and briefly two masters existed and connected to the Hub, before detecting and resolving this split brain situation.
• The CLI for setting properties only checked if the user had the permission to change a property, but did not check if the property actually supports setting or is a read-only property. Setting read-only properties could lead to all kinds of weird issues. You now no longer can modify read-only properties.
• No tool in the old and new web interface required user write permissions for changes. Now all of them do.
• The download test tool (old web interface only) got improved so it uses far less CPU. No more "download test aborted due to too high CPU load" messages anymore.
• When re-enabling a disabled fan, on some router models the fan would not start up, as the fan speed was set too low.
• During router startups CPU load is no longer monitored and reported to get rid of annoying warnings when there is nothing to warn about.
• Some production runs of the 300 router have an issue where the reset button does not always work quickly. This is now solved, pressing the reset button shortly will reset the system again even on those devices.
• In the module settings by CLI and new web interface in past releases you could select invalid configuration types. You no longer can.
• "Expected Internet link capacity" was broken for some LTE carriers, causing internal errors and negative autotuning speed results. This is now fixed.

• Full IPv6 support for LAN interfaces and Tunnels
• WWAN Image manager and switcher. On modular routers you can now flash firmware images to WWAN/LTE modules, to keep those updated. WWAN firmware images will be downloaded as needed from the Internet and cached.
  On 511/512 routers instead all possible WWAN images are shipped in the router firmware, there you have a switcher tool to switch the firmware the module uses (which does not require a download from the Internet).
• The CLI is completely reworked. It now includes tons of tools also available in the web interface like ping, traceroute, wan interface info etc.
• The web interface finally uses HTTP keep-alive and Websockets. You should see a dramatic increase in responsiveness.
• Single and Double forward error correction - similar to a harddrive RAID5 (single parity) or RAID6 (double parity), the router can now automatically correct and replace IP fragments lost on a fluctuating line. Single Parity mode is available without extra licenses, Double Parity requires a Streaming Optimizations license.
• New optional Data compression for QoS flows - you can select per QoS class if you want data compression or not. On typical office traffic, data compression will get you additional 25-30% of throughput.
• You can select per QoS class "guaranteed delivery" - if this is enabled in worst-case if a packet can not be reconstructed through DFEC it will be retransmitted. You always should have 0,0 packet loss using this mode.
  We did a little bit of overengineering here - the retransmission system is extremely clever and needs minimal overhead for acknowledgments, and it does not retransmit actual packets but only the minimum amount of redundancy information missing to enable the other side to reconstruct data. It is MUCH faster and more effective than relying on the TCP retransmissions of your data connection instead. The system however does eat a lot of CPU.
  By default guaranteed delivery will be off - only a very limited amount of applications will make use of this feature.
  You should use guaranteed delivery for applications that behave really badly on a lost packet - for example video codecs that would drop all further video frames until the next key frames.
  Without guaranteed delivery you will get a more stable latency and no jitter, as retransmitting takes time. You will therefore have to test with your application what works better in real-life - having a dropped packet in the very unlikely case that line conditions change that quickly that the DFEC didn't see it coming or having a retransmission in this case which could make your data "stutter" for a short moment.
  It is our experience that for hard live (video conferning) depending on the codec guaranteed delivery should be either on or off, and for everything that has a buffer of 1000+ms (video streaming) that guaranteed delivery should be on.
• Huge speedup for log output in new web interface. Even with a huge amount of log messages, the web browser no longer should freeze.
• The License manager is now able to do an automatic online check. All registered licenses will be automatically fetched to the router (provided the router has access to the Internet).
• For 511/512 routers, the WLAN AP can now use AC mode. Also, the WLAN AP code has been rewritten. Depending on what region you are selecting, all channels that are allowed for this region are available.
• VLAN tunnel transport
  The idea is this:
  Inside the Routing object you can create VLAN aliases. You then can refer those both in the Module settings and inside the tunnel settings. For the tunnel, you can select multiple of these VLANs.
  Now, all traffic coming in from a LAN VLAN will be forwarded to the tunnel if that VLAN is listed for the tunnel. If it is not listed, the packet will be dropped. The packet inside the tunnel is TAGGED, so on the other side (the HUb) the packet will exit the tunnel with the same VLAN tag - and if you don't have enabled the VLANs for this tunnel on the Hub, the packets will be dropped there. Due to this someone in control of a Node can not just send a VLAN tag that does not belong to him to get access to a different tunnel segment/customer on the hub.
  The previous tunnel segmentation ID setting is kept - this is now used for packets coming in from the tunnel which do NOT have a vlan tag (like it was in classic firmware), these packets will get the VLAN tag configured here. This way you can still use VLAN tagging and tunnel segmentation on the Hub, but not doing any VLAN settings on the Node.
  If you wish to map multiple VLANs coming from/to the Tunnel to the local LAN interface of a Node, the Node needs to have a "Enterprise Node Features" license installed (with the exception of the 2610/2620 routers, which being Enterprise-level devices get this feature for free.)
• Every WAN module now has a subobject "Performance data", which you can access through the web interface and CLI etc, whenever you poll with SNMP, the data will also be updated. At most, internally this will update every 5 seconds if constantly polled. Reading this data using SNMP requires an "Enterprise Node Features" license to be installed (again, 2610/2620 have this feature included for free).
• Support for LTE450 modules
• Enabled Mobile Technologies now gets defaults set as soon as the modem type and carrier certification is known. For LTE450 for example, only 450 Mhz is enabled by default, for 4G Europe/Australia CDMA is disabled etc.
• A total of channel bandwidth for all connected tunnels is now displayed in the Tunnellist object. This makes it easier to see what bandwidth a Hub is using right now.
• SSL Session and Channel handshake caching is now used for VPN Tunnel connections. Due to this, Node channels constantly reconnecting to Hubs should no longer cause high CPU load on those. We have seen a dramatic improvement for everyone who is running VPN Hubs for Nodes in moving vehicles. On a customer VPN Hub serving vehicles the CPU load has dropped from 65% down to 2%.
  This feature also means that a channel that needs to reconnect on a module with say100ms will no longer need 1+ Seconds to re-establish the channel, but only a fraction of that. We believe that this is a huge improvement, and a lot of customers will love it.
• Added VLAN Ids to routing rules and QoS rules. With this new feature you can now limit routing rules and QoS rules to match a TunnelSegmentation / VLAN Id.

• Should during a cold router boot-up a module missing that previously was configured (and is stored in the config) we'll now wait for up to 30 seconds for the module to re-appear. This is because on routers booting up quickly at this point a 4G module might not yet have fully booted and therefore isn't seen at the moment the configuration is loaded and applied. This could with bad timing result in the module losing its configuration.
  This should fix all the problems we never before could reproduce where customers had LTE modules lose their configuration if powered up sometimes.
• Security improvement: Added a TLS security fix against the RSA CRT attack
• Security improvement: SSLv3 and SB_SUITE_RSA_RC4_SHA are no longer used for the web interface (Which means IE6 is no longer supported).
• Security improvement: The only ICMP packet types accepted to be sent to the routers are now ICMP_ECHO, ICMP_ECHOREPLY, ICMP_UNREACH, ICMP_TIMXCEED, all other are filtered. This is in response to a security audit - you will no longer be able to get TIMESTAMP replies, which are a potential attack vector, from a Viprinet router.
• Hubs now know what model they are even in Hub replacement and hotspare modes. In Hotspare modes therefore licenses are now regarded as valid (before the check failed as the router model wasn't "known"). Also removed text that says you can not use the license manager in Hotspare mode, you now can.
• A Classic VPN Client connecting to a RuggedVPN Hub could get sent packets bigger than 1500 bytes (due to a missing unpadding), which would result in Internal Error - Code 12A8922323111132 in the VPN Client.
• Hubs will now report an error to the log in case the remote router has sent one during tunnel negotiation. Also the "Connection dropped due to command timeout" message now will only be used if the connection actually was closed due to a timeout.
• Sometimes due to a race condition the SIM may be unlocked but reading the IMSI and HomeMCC/MNC will fail due to the SIM not being ready. In this case reading it is retried. However, the code for re-trying to read the MCC was buggy, so this never worked. This is the reason why APN Autodetection was failing on some LTE modules since a couple of releases.
• For interface traffic counters, resetting a counter more than once would result in wrong values.
• If a WAN module was reconnecting often or didn't get an IP, the channel using it could cause Internal Errors and/or the router to reboot.
• Sometimes when rebooting or when switching from slave to master mode on a stacking router, some LAN services would randomly not work.
• Resetting a module (manually or automatically) would block the main timer of the router for up to 2 seconds. This could cause unrelated channels to stall and disconnect.
• A 511/512 constantly resetting the module after a while could run out of file descriptors and no longer be usable. This should no longer happen.
• Fix for VDSL RFC1483StaticIP (a modem fix is also needed)
• The maximum number of connections for hotspare config transfers was undefined (never set), and therefore depending on the build random. Due to this on some firmware builds this feature has worked, while on others you could not have Hubs do config transfers.
• Multiple crash bugs in the stacking system have been fixed.
• If a router was under low memory conditions, it could fail running scripts, causing all kinds of things to fail - for example modules dialing in. If this happened you could typically not even reboot the router.
• Assigning an IPv6 address to the main LAN interface caused a reboot loop. This is now forbidden and prevented, v6 addresses may only be used on LAN aliases - different parts of the product still rely on an IPv4 address existing on the LAN main interface.
• NTP does now work on Hub Hotspares, too.
• The way that the LTE modems are dialing out have been changed for the 4G Europe/Australia, 4G Europe II and 4G Americas modules. This fixes the problem of the modules with recent 05.05.58 firmware no longer being able to connect to AT&T and T-Mobile in the USA.
• For some carriers, the new "4G Europe II" module reported the network string in 7bit encoding, resulting in garbage network name.
• Fixed 4G Europe II module reporting wrong expected link capacity values, also fixed all other 4G modules sometimes reporting EVDO while on UMTS, also resulting in wrong link capacity values. Wrong link capacity values could result in channels using these modules not to use the full speed they actually could.
• Due to a race condition in the module, reading IMSI or Home MCC/MNC from SIM may fail directly after SIM unlock. This in turn could cause the APN Auto Detection not to work. In this case this is now retried later.
• Reboots of routers should now never fail even on low memory conditions

• You can now define preferred LTE bands in the Enabled Mobile Technology settings
• Changes in celltowers are now recorded and logged. Also there is a function to manually re-scan all enabled LTE bands. And finally there is an optional feature to automatically scan all enabled LTE bands if we have seen UMTS only on two celltowers. This is useful for moving vehicles which pass through areas of bad coverage, and then come back to an area where LTE is available. Without this feature the module would have been stuck on UMTS forever to not interrupt the channel connection. If this auto re-scan is enabled in this case the module will disconnect the channel and itself to re-scan LTE.
• Google maps tool will now live update the markers position when the router is moving, you no longer need to refresh.
• Created better QoS default templates including VPN protocols like IPSec. Use the restore Manufacturing defaults function to see those. If you are using the router in a vehicle, we strongly recommend to enable FEC for all QoS classes.
• SNMP: added CellID to SNMP and performance data. Also vpnRouterInterfaceIndex is now also right. This was always 0 for WAN modules in the VIPRINET-MIB

• Limit notices on expiring maintenance licenses if the license expires in < 7 days.
• Updated all firmware-related warnings, added a warning for unlicensed firmware in case VLM is not installed.
• 310/2030/2620 did not turn off the logo on system reboot in previous releases.
• Fixed log warning for demo routers to no longer count from 14 days downward, but from 90 days.
• Updated text inside SNMP Settings to include 2620 and 2030 models.
• Added missing maintenance license types for Hub 5000 - before, any maintenance license or warranty extension a Hub 5000 had was fully ignored.
• Changed login popup to not warn if a maintenance license runs out in <28 days, but instead only if <7 days. This is because in a subscription, you license always will be only valid for 30 days unless you select a long interval, and therefore constantly warning about it is bogus.
• Fixed the way items are deleted - depending on selection order sometimes some items could not be deleted before. Deletion list is now sorted before doing anything, so it also no longer breaks if you select some items from bottom to top holding the CTRL key.
• A Loading mask will not be shown on loading objects if a roundtrip of a websocket connection is <500ms. This makes the webinterface snappier if used locally on a router.
• Object editors are automatically reloaded if the object was changed. However, now if you are currently EDITING an object (cursor inside any input element) the object editor will no longer be reloaded.
• Moving items up and down in the item list of a collection now works as expected without any reload. The tree view is automatically updated while moving items up and down
• If an object changes (for example module rename), the tree view now should correctly automatically update again
• This release fixes two different bugs that could cause the routingcore to freeze for up to 30 seconds, causing all tunnels on a Hub to disconnect.
• Fixed "Slot 6 - 4G Americas for AT&T USA contains illegal characters." message
• Fixed / workarounded dhcpd sometimes not starting up in stacking setups
• Changed latency autotuning to not go over 1000ms by default. If you are using Satelite, you should not be using latency Autotuning anyway
• If you enable FEC in the web interface, it will automatically set the preferred number of channels to something that makes sense - 3)
• For WWAN modules, on their first attach to a network in a lot of cases the network name was reported as empty due to Qualcomm bugs. This was confusing the Signal monitor tool, too. In these cases the Networkname is now retrieved using an internal database if not reported by the modem. 
• The monitor tool for WWAN modules typically would have every slot twice - once as "Slot 1 - WWAN (3G/4G)" and once as the final module name. This is now fixed in the router code. You now should no longer see the "Slot 1 - WWAN (3G/4G)" entry
• The whole logic of adapting entries if you set a duplicate entry for first/second/third bonding priority didn't work at all. It's removed now, so you will no longer see one bonding priority suddenly beeing set to none etc.
• Once again fixed multiple bugs that on a router power cycle could cause WAN module configurations get lost.
• Applying QoS templates did not actually copy most QoS class properties
• The GUI and the CLI got unavailable if you had an "empty" routing rule having only a tunnel assigned.
• The code reading packets from the LAN NIC had multiple issues: For other Ethernet types than IP/IPv6/ARP, it would still treat this partly as IP, therefore using unknown random data as IP, before then dropping this. This could indirectly also cause access violations. This has caused internal error CA23AA32932FFFF1 (aka BACEE2923EEEEEEB)
• For tagged VLAN traffic, multicasts that the router should listen to got completely dropped
• Multiple bugs in how IPv6 packets are handled, the flow hashing was completely broken, and you might have seen oversized IPv6 coming out of tunnels (which then might got dropped by user operating systems)
• When reading the VLAN Id from the NIC, IEEE 802.1Q / IEEE 802.1p flags weren't filtered, resulting in bogus VLAN Id numbers.
• After reading a packet from the raw NIC, some basic sanity checks are now done BEFORE the flowhash is calculated. Without these checks it before was possible to cause an internal error by sending an invalid TCP Header with size 0 to a Viprinet router.
• The 55-... demo routers did complain about not having a VLM license, which they don't need at all. They now should no longer complain.
• Fixed channel connect error if SSL Resume was enabled on boot-up and was used while it shouldn't (because there can't be a cached session after bootup). Now for the first time it is safe to enable SSL session caching, which speeds up things in mobile scenarios a lot (and lowers CPU usage dramatically)
• Removed forgotten debug messages

• You can now create custom LTE WWAN profiles, which might be needed for some carriers or users of private APNs. Please note: The default APN profile settings have changed. Please verify that your LTE provider works fine with these new profiles before mass-deploying this release.
• Hubs in Hotspare mode now have working ACLs (and internally run our full routing stack, which they did not before). Finally this enables using the Service ACLs. This is important because without them, the DNS service on Hubs running in Hotspare mode could be used as amplifiers in DNS DDoS attacks. Please verify you have ACLs in place after upgrading to this release.
• The CPU usage of tunnel channels on Nodes has been decreased. This may result in slightly higher total bonding capacity especially when using a lot of channels (stacking).
• The CPU load when a Hub or Node receives a very high number of new connections at the same time (for example during a port scan or DoS attack) has been reduced significantly.
• The routing core latency now is as low as never before. You can ping the router with a response time of <3ms now.
• LAN throughput has been increased, CPU load for LAN traffic decreased.
• LTE-TDD Bands B38 and B40 are now validated to work. The 4G Europe/Australia/Africa module now has a working AT command tool, and is now ready for production use.

• Multiple bug fixed for the WLAN Client module which improves compatibility and now also allows connecting to unencrypted APs.
• QoS bonding priorities did not get copied when using QoS restore from/to templates.
• On stacking slaves a 24h disconnect or the ISP re-assigning the IP while connected could cause the router to eat 99% CPU permanently.
• Hubs in Replacement mode would complain about not having VLM installed. They no longer do that.
• Heartbeat diagnostics ("A single router is gone from the network") is now only shown once instead of every second.
• Log messages have leaked memory if the web interface was used without web sockets being enabled. This could grow to a significant amount of memory if the web interface was opened for a very long time with the router producing a lot of log lines (very busy Hubs).
• Fixed a memory leak when the router was dropping IPv6 broadcast traffic it was seeing on the LAN.
• Fixed a small memory leak in the configuration system. On stacked nodes doing lots of configuration syncs (for example because very unstable channels are used), this could grow to a significant amount.
• The memory usage of Hubs that see a very high number of concurrent flows (50000+) has been reduced.
• The internal packet slicer (which is used to cut IP packets into slices that are then sent over the channels) under circumstances (especially with a high number of channels, unstable channels and/or FEC enabled) could leak significant amount of memory.
• The LAN NIC no longer can get stuck, and in worst-case a LAN reset will always actually bring the NIC back to life now.
• A WLAN Client module could cause the router to eat 100% CPU. This is fixed.
• The default Autotuning mode for newly created channels is now Hybrid instead of Heuristic.

• There are no new features in this release.

• Channel shutdown/disconnect has not been clean for a while. We suspect that this could have lead to system crashes. In less-fatal situations it gave you SSL errors on disconnect, or had channels time out for up to 5 seconds instead of cleanly disconnecting right away.
• On certain products (310, 2620, 2030, 5000, 5010) the hardware crypto engine could crash during channel disconnects. We believe that  this bug is the reason why customers running routers under high stress (Satellite connections, ships, vehicles with lots of reconnects) are seeing devices reboot, while others don't. 
• Fixed stacking slaves having a calculated MTU < 1500 not getting that MTU used. This fixed slave channels on a 500 stacking slave (or anything that uses PPP) not getting used.  
• Fixed automatic connect to the License Server, which did not work before (you had to manually connect to received updated licenses)
• Reverting back to not dialing directly for LTE modules, but instead modifying to profile to trigger call. This means that those customers complained about problems with private APNs prior to the current stable release now will have these problems again, but they can use the custom WWAN profile feature to work around. We had to revert this because with the new way of dialing Verizon in the US did not work at all anymore, and also problems have been reported from the UK.
• Fixed demo and project routers not being able to use stacking slave channels. Please note that you have to re-select the remote WAN module inside the channel after updating to this fixed firmware.
• Fixed popup message on demo routers to not say that the demo runs only 14 days, but correctly state that it is 90 days.
• Re-factored the way statistics about flow source and destinations host are managed. Before a DDoS attack using spoofed IP addresses could eat up all the RAM and a lot of performance. The system now no longer can be put out of service flooding it with spoofed IP addresses, and in generally also performs better in scenarios where a huge amount (1000+) of LAN devices are using a Viprinet router.
• In case of certain kind of DoS attacks, the routingcore thread potentially could have gone stuck, causing the router to reboot about 90 seconds.
• In case a DDoS attack is detected as likely, messages on this are logged, at the maximum once per minute.
• A bug in memory handling of IP packets has been corrected. This bug could cause both a small memory leak accumulate over time, but also could cause crashes under certain circumstances.
• Setting an IPv6 address as main LAN IP address (instead of adding the V6 address as an Alias) wasn't supported but not prevented, which could result in the router becoming unreachable from the network. It's no longer possible to set an IPv6 address as the main LAN interface address.
• The retransmission manager used for QoS classes having "Guaranteed delivery" enabled had a bug which first of all was leaking memory, but also could have resulted in half of the retransmissions not taking place. This  means that a flow going through the tunnel could have seen packet loss even with Guaranteed delivery on. This could have dramatic consequences: TCP/IP header compression used builds on the guarantee that there never are lost packets. This means that if a flow used guaranteed delivery and then a channel had packet loss, the flow could get stuck.
• Fixed log output of TCP Sequence numbers (the numbers could be logged negative).  Also lowered log level of very common TCP violations caused by broken scanners, no longer claiming that you are under attack.
• Make sure stuck stream downloads are aborted. This bug could have resulted in download tests doing in the webinterface eating 99% CPU if they get stuck.
• The routing core could get stuck on the receiving side of flows. Very rare, depending on timing. You could be running without a stuck routing core for weeks, and then suddenly have it getting stuck all the time. 
• Individual high-load guaranteed delivery flow receivers could get stuck after a tunnel reconnect, and while doing so could eat up memory.
• The receive-side timeouts for non-guaranteed flows that make sure that we wait long enough (but not longer than) for all fragments to arrive is based on the assumed bonding latency of the combination of channels used. The filters used weren't fine-tuned, and not suitable at all for satellite connections. These non-tuned values could cause packets getting dropped receive-side (because the router would not wait long enough for all fragments of that packet to arrive). This could result in the receiver being at fault for not being able to use the full tunnel speed downloading from/through the tunnel. The filters have been completely rewritten. 
• The "Average latency is ... ms, maximum allowed is ... ms, no alternatives, keeping channel." message is gone, as is the underlying idea: It does not make sense to keep the last channel with a latency higher than the maximum allowed one. If the last channel drops out for a moment, the tunnel layer will do the buffering.

There are no new features in this release.

• Starting December 1st, 2016, all previous releases started to display an annoying pop-up when logging into the web interface, claiming the firmware to be out of date and out of support. This even was the case with the most recent firmware release from October 28, which is perfectly fine and covered by support. The popup has been removed. We apologize for any inconveniences.
• This releases fixes an encoding bug that caused VPN Clients connected to RuggedVPN Hubs to be unable to display Downstream and Latency graphs in the Monitor tab.

• Dynamic routing with BGP and OSPF is now fully supported on both Hubs and Nodes.
• LTE modules may now send and receive SMS. There also are auto responders which you can configure to automatically reply to incoming SMS. Using this feature you can now use our products with LTE providers that offer data-plans where you can add data packages by sending an SMS. For example Vodafone Germany will send you an SMS "Your high-speed data has been used up, reply with "5" to book another 5GB". With the auto responder feature you could create a filter on "high-speed data has been used up", and have the router reply "5" in this case to automatically book a data package. Please note that this feature due to chipset limitations sadly does not work on the LTE 450 and 4G Europe II modules.
• Viprinet Virtual Hub config is now compatible with hardware hubs, which means you can copy a config file from or to a hardware router and use it.
• Internal improvements in RAM management reduce the amount of RAM and address space used a lot. Memory usage on a heavily used Hub should increase much slower than before.

• New improved behavior for disabled tunnels on VPN Hubs: Instead of letting tunnels, clients or channels connect and then have them disconnected again if disabled (or the VVH identity not being ready), we now reject them directly while  they are trying to connect. Also added some throttling.
• Viprinet Virtual Hub: Improved startup system to make sure the VVH is not flooding with incoming Tunnel connections before being ready to accept them
• Viprinet Virtual Hub: If the DNS was unreachable on VVH startup, it would take up to 5 minutes until the identity server's hostname could be resolved again.
• Viprinet Virtual Hub: Users can no long acquire a new device identity unless the device is marked to be a "Copy"
• Fixed SFTP support
• In the WAN module info of LTE modules you could sometimes see garbage text behind "Country:"
• Fixed the web interface sometimes not showing the summary list of all items when selecting a list object.
• Fixed stacking slaves not having their channels used after restart
• Removed lots of JS debug output lines in web interface
• Fixes an unsynchronized access inside the web interface Ajax message system. This could cause routers to get stuck and/or the Object tree would no longer being accessible in the web interface, and other errors. This most often appeared when executing "Contact license server" manually from the web interface, or when disabling a Tunnel on the VVH.
• Now reports an error in case a license de-activation has failed
• Fix for ADSL/VDSL modules sometimes no longer being usable if they get assigned a new IP in a 24h reconnect without the interface going down/up during that reconnect.
• Made sure that expired licenses/subscriptions are not counted as valid tunnel licenses on the VVH.
• Drastically improved upstream autotuning results on RuggedVPN VPN Client by a factor of 10+.
• As our routers, the RuggedVPN VPN Client will now also tune the TCP sendbuffers. We've seen this stuck at 8k for Windows, so this gives a HUGE performance improvement over high-latency links.
• The HTTPS download test tool would accept SSL certificates that are valid, but expired
• If on the Hub no DNS was configured to be assigned to VPN Clients, the VPN Client would block during connect for 10 seconds. This delay no longer exists, speeding up VPN Client connection time dramatically.
• Routes pointing to invalid targets could not be deleted.
• 2620 routers believed their Bandwidth Capacity to be 200 Mbit/s instead of the 400 MBit/s they can do. They also reported a wrong capacity over the tunnel to the remote device. In practice that should not mean much, but under certain circumstances / loads from LAN this could have limited the total throughput the router can do, and it also would cause the Hub to use a wrong assumption on total capacity for bandwidth auto-tuning.
• Made sure HTTPS web server is disabled for the VPN Client
• Added log prefix for HTTPS errors showing the remote IP that caused this error
• Improved identity handling of Viprinet Virtual Hubs. In case a VVH gets flagged as clone you can now resolve this by shutting down the clones. After a while the one remaining ex-clone then is flagged as verified again.

• Internal transfer network for virtual hubs must not be changed.
• Dynamic routing tries to handle VLANs and segmentation as good as possible, but not all setups may work. There are no separate routing tables.
• To configure the SMS features on a 510, a SIM has to be present for the module.
• Disabled VPN Bypass for now.

To active the dynamic routing feature you will need to install the Enterprise Node Features software license on the Node side. So this feature is built-in on any Viprinet Hub and of course on the 2610/2620 for free.

• A new web interface object "Dynamic routing settings", also including two new tools "Full routing table" and "Viprinet routing table". 
• Allows you to dynamically distribute static LAN/WAN Viprinet routes.
• Push / Accept routes per tunnel. You can find this setting in each tunnel. The standard use case is to enable Push routes on the node side and enable Accept incoming routes on the hub side. I'm sure you will find a scenario where it is useful to use it in both directions.
• You can select which interface should speak in which area and if it should be used for dynamic routing (OSPF/OSPF for IPv6 only).
• WAN/VPN routing rules, VPN Client pools, LAN IPs and additional LAN routes can be distributed.
• The Viprinet router is able to announce itself as default gateway, but it will ignore default routes announced by other routers.

Two example cases

Case 1: Use the new Tunnel protocol to send all node networks to the hub so the hub can route them (No static WAN/VPN routing rules)

• Hub side: Enable "Accept incoming routes" in the selected VPN tunnel
• Node side: Enable "Push routes through tunnel" in the selected VPN tunnel

After enabling these settings, the tunnel needs to be reconnected. The Hub should now receive all node networks and route them in the right tunnel.

Case 2: Extending Case 1 with a dynamic routing service

• First configure the Node and Hub the same way as in case 1
• Additional to that configure/enable on Node and/or Hub side the Dynamic routing service and the service you want to use (BGP, OSPF or OSPF for IPv6)

All networks incoming on node side will be also known by the Hub and can be routed. Make sure you have enabled the check mark "Distribute local Networks" in the service you want to use. Otherwise it will not be distributed. If you also enabled a dynamic routing service on the Hub side it can distribute all Node and Hub networks to the Uplink router.

Warning/Hints

• BGP only: To start the service, you need to configure at least one BGP neighbor. You can find the BGP neighbor object under "Integrated services" " "Dynamic routing settings" " "BGP settings".
• OSPF/OSPF for IPv6 only: For starting the service, you need to configure an interface to use in the LAN settings object; there, you can also configure the OSPF area.
• VPN Tunnels: Changing "Push routes through tunnel"/"Accept incoming routes" needs a tunnel reconnect to take effect.

Known issues

• OSPF/OSPF for IPv6: Password authentication doesn't work.
• Default routes announced by other routers are getting dropped right now.

• You can now update the firmware of VDSL modules inside the routers web interface. New firmware images for the VDSL modules are automatically downloaded as needed,  the same way the LTE firmware images are.
  ​Firmware changes for latest VDSL module firmware version 1.91:
  • VLANs now work in ADSL RFC1483 mode.
  • Module now reports authentication failure to the router if the credentials are wrong during ppp dial-in.
  • Ping and traceroute tools in Viprinet work again.
  • Now multiple connections via the module into the world work again (for example download test tool).
  • Uses most current Datapump (10.23.0.47) this fixes a lot of VDSL related sync issues.
• Full support for the 4.5G LTE-A module. The module will now also display the module's Viprinet serial number in the web interface.
• Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is protecting both our routers and networks behind it against a huge range of TCP/IP protocol attacks.
• New logo animation on router boot-up. Nobody asked for this, but we still did it.

• We now allow VPN Tunnels, VPN Client Tunnels and Channels to be deleted while they still are enabled (but not connected). This is changed to work around a bug in the VPN Client that can get stuck in an unclean state on startup forever, trying to delete an enabled tunnel. But in general this should also improve convenience for all of our users.
• This release fixes the problems the LTE Europe/Australia/Africa module has with reading some SIMs.
• Fixed wrong time zone calculations being done on 200 and 5xx products, causing wrong log time stamps etc.
• Under rare circumstances a channel that was disconnecting uncleanly could get the routing core stuck.
• Under very rare circumstances access to some objects that were used by the routing core in that same moment could get it stuck (this could be reading SNMP, web interface, CLI or router stacking communication).
• On newer devices that were using an asynchronous hardware crypto accelerator, an unclean channel disconnect could cause the router kernel to crash, panic and reboot.
• Stacking masters could sometimes get stuck if a lot of changes were going on on channels and/or WAN modules that were synchronized between routers.
• A slow memory leak would cause the Hub to run out of RAM after a few days. This was mostly seen when using FEC.
• The Virtual VPN Hub's clone detection potentially could wrongly flag your Hub as a clone if time on our backend server cloud was de-sychnronized.
• SSL handshake timeouts are now much more relaxed, which should result in less SSL handshake errors on unstable WAN connections.
• In case that the router has to reboot (due to a routing core being stuck, being out of memory, etc), it will now first try to write a copy of the log file to flash memory. This means that in future our support team will be able to diagnose a Hub/Router after a reboot, even if you did not have a local syslog server.
• The designated stacking master will now use its own uptime instead of the one reported by the current stacking master. Also the logging has been improved and should be less confusing now.
• Fixed timing problem in Dynamic routing which resulted in "Duplicate Route received" on the remote side.
• The property "Distribute via Dynamic routing" in Additional LAN Routes was not used.
• A node connecting to a Hub could end up with 99% CPU forever in case the TCP connection broke down in the middle of the handshake.
• The "Guaranteed delivery" QoS feature/setting under rare circumstances was able to cause router crashes and memory leaks. The feature is disabled in this firmware release and will come back later. No matter what you set in the QoS now, in this build guaranteed delivery will not be used (it does not change your setting).
• As a protective measure on the Hub side, we will now close a channel connection if during authentication more than 10 errors have occurred.
• Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is to make sure that under no circumstances we are sending out garbage that might crash the kernel.
• Reduced the number of packets read from the LAN in one go. Before, if you flooded a Hub on the LAN interface with packets, the router was hardly able to handle anything else anymore – it could get the routing core feel stuck.
• On Hubs, there is another safeguard that a broken cached SSL session will not be re-used. This fixed the floods of SSL Handshake errors some customers have seen before the routing core got stuck.
• Fragmented IP packets that span more than 32kb could cause memory corruption and would then make the router crash. We have seen this in the wild, potentially part of an attack against a customer.
• When a Hub was switching from Hotspare to Replacement mode, some part was internally crashing. The Hub recovered from this, but it involved a system reboot. Due to this, failover was slower than intended. It is much quicker again now.
• LAN IP Aliases accepted invalid IPv6 addresses. They no longer do.
• Applying settings in DHCP services logged an internal error message for no reason.
• Changed SSH CLI RSA Key length from 1024 to 2048 bit.
• Until now, if you flooded a Viprinet device with ICMP ping packets, after a while it stopped responding and never answered ICMP again.
• The tunnel will now auto-reconnect in case a Fatal Error is experienced while trying to read a packet from a channel.

• Under certain circumstances traffic in one or more QoS classes would suddenly stop flowing. This could for example result in the users suddenly no longer being able to resolve IPs via DNS. This issue existed for a long time, but became more frequent with newer firmware releases. The issue now is verified to be fixed.
• In some installations, with the July firmware release LTE 450 MHz modules as used in Northern Europe would no longer be detected. They now are detected on all products again.

• UMTS and LTE modules now are using a brand new APN databases that is based on the SIM's IMSI range. This means we can now differentiate between network resellers – so “Tchibomobil” SIMs on O2 will now use their own APN instead of the O2 one. The database is always updated and fresh. In case the new system fails, there is a fallback to the old MCC/MNC-based APN detection.
• Drastically reduced memory usage both on Hubs and Nodes.
• LAN throughput on Hubs has been drastically increased. Even if the Hub could do more, in previous releases it would at the maximum read around 250 MBit/s from the LAN only. Now it is doing 2 Gbit/s again.
• Massive improvement on bonding throughput on most products. We have now seen peek bonding throughputs of >200 Mbit/s on a 310.
• Now supports the new LTE-A 4.5G APAC module.
• All recent LTE modules now are able to acquire the IP address on connect much faster than before.

• Using the packet capture tool you can now live-view or download pcap files of traffic at various places.
• In the web interface collections you can now not only add new items, but also insert them. If you use insert while being in the collection object (“Tunnels”), the item will be inserted on the top. If you have selected an item (“WurstTunnel”), the new item will be inserted in front of it.
• In collections you can now move items to the top and bottom instead of just up/down.
• Tunnel items may now be moved, and new tunnels inserted instead of just added.

• Various fixes and changes on how FEC and channel selection for it works.
• Various AWS fixes for certificate management.
• Some logic bugs in how QoS classes are allowed to send at what speed were fixed. This fixes the broken “guaranteed bandwidth” test cases reported by partners.
• Made sure that ALL possible LTE bands are enabled before it is known which bands the module actually supports. This might fix the problems partners had with “Forgotten LTE bands”.
• Now accepting silly TCP Option 14 through Viprinet tunnels.
• If the internal transfer network was re-configured to something else than the default settings, Virtual Hubs no longer were able to reach the Virtual Hub Verification servers.
• For WLAN Client modules, the currently seen WLAN APs are getting listed in the module info again, even if there no connection to an AP.
• Previous firmware releases could reboot after running for 49.7 days, due to a 32 bit counter wrap-around. They no longer are doing that.
• Fix for a workaround for bugs in some LTE module firmware releases that might cause the LTE modules of a 51x not to detect SIM cards on a cold boot.
• Fixed potential KRACK WLAN security issue.
• Some fixes for the “Modules are getting stuck in disconnecting state forever” problem that partners have seen.
• Fix for Chrome 61 being unhappy about the self-signed SSL certificates that our routers generate for the web interface. Please note that you must manually re-generate a new SSL certificate inside the router to make Chrome happy again.
• “Managed SIM Settings” have been removed from the firmware, as our managed SIMs haven't been available for a year already.
• The 511 LTE images were reduced by 35MB in size. Now doing an offline update on a 511 works reliably again.
• A slave in a stacked router setup was saving the config every time a change was sent from the master. It now only saves every 30 seconds max.
  Also the synching now has been throttled to eat less CPU.
• Under very rare circumstances, NATted ICMP-traffic coming from multiple sources (tunnels) at the same time could get one or more of these ICMPs flows get stuck.
• All download tools now support HTTP chunked encoding.
• In the previous stable release the LTE firmware carrier certification was not being displayed in module info.
• Made sure that for custom profiles all of its settings are confirmed to really be received by the LTE chipset. This fixes all reported problems when using private APNs.
• Some users were reporting the Google maps GPS tool in the web interface to no longer be working. A new Google Maps API key was added to solve this.
• Starting December 1st, all prior firmware releases incorrectly complained in the web interface to be outdated. We are sorry for the confusion.

• There have been reports that in some installations, VDSL or ADSL modules get stuck in "Disconnecting" state once they receive a new IP address during a 24h reconnect. There had been reports about this in the past, but just as today we are unable to reproduce this. If you are seeing this problem, please contact the Viprinet support team.
• Under circumstances, you are not able to enable VPN clients on Virtual VPN Hubs. Please contact support if this happening to you. We will be preparing a Hotfix for this.
• Deleting a VPN tunnel that had been connected within the last 3 minutes may cause a VPN Hub reboot. Please wait 3 Minutes before deleting a VPN Tunnel.
• After installing the firmware update, a VPN Hub Hotspare may wrongly report the active Hub not being able to reach any of its ping targets on the LAN and WAN, wanting to replace it. This problem is gone after a second reboot. One possible work-around for this problem is to temporarily remove the VPN Hub from Redundancy Group before updating it. If you need assistance in planning the update of a large amount of VPN Hubs, please contact our support for assistance. 

• VPN Bypass is here!
  This allows you to create traffic rules that do not point to a tunnel, but instead directly to the module, where traffic will be NATted to the module's IP.
  Go to WAN/VPN routing rules, enable “Allow VPN Bypass routing”, setup some routing rules pointing to a module, and have fun.
  Please note that this feature is only to be used in corner cases–for example if there is a DSL router with integrated VoIP gateway behind an Ethernet WAN module, and your phones need to reach it. Remember that using the WAN module directly for Internet traffic defeats pretty much any purpose Viprinet routers have (security, redundancy, etc).
  There also is the option “Module browsing tool” inside the WAN module objects if you just want to temporarily surf through a module to fill out a captive portal.
• You can now add and manage DNS A records of the integrated DNS server. This allows you to configure hosts like “mycomputer.local” and have that resolved to an IP for all computers using the router's DNS server.

• Using repeated security scan floods for a TLS ROBOT attack could make Hubs/Routers crash and reboot.
  We have now updated the Cipher suites used to completely disable RSA key exchange as recommended as a best practice.
  By that, we have removed compatibility for any Viprinet classic firmware device using a firmware version older than 2015 connecting to an updated Hub.
  You'll also no longer be able to use the web interface with HTTPS with very outdated browsers like IE below version 11.
  We also have hardened the VPN Tunnel code in regards of future TLS attacks.
• It was possible to run a DoS attack against the router by opening lots of connections against the SSH ports, then closing the SSH session on the SSH protocol layer, while at the same time keeping the SSH TCP connection open.
• With the previous firmware release, it was possible that routers restarted after 24 days of uptime displaying a “Routing core stuck” message due to a timer desynchronization.
• If a stacked setup was connected to a Hub, and the master rebooted, the slave took over. But if the master came back and restarted the channel, you could see on the Hub that the slave's channel might have hung in the “disconnecting” state until the hub rebooted. This was caused by  the "A split brain situation has occured on the remote stacking Node, channel will be disconnected" error.
• Problems with activating VPN Clients on Virtual Hubs were fixed.
• In very rare chases, DSL modules can get stuck due to communication issues between the router and the module. If that happens, modules will now automatically power-cycle. There are still known issues in this regard which we are working on. Should any of your modules get stuck in “Disconnecting” state, please contact our support team.
• Proper permanent fix for the “Outdated Firmware” message. The message will now always appear 1 year after the firmware's release date.
• Stacking often had problems doing ARP resolves for LTE modules, rendering these remote modules unusable for the stacking master.
• A whole lot of problems with the way routers handle IP fragmentation have been fixed. This will help all customers who are using fragmented IP packets (e.g. IPSec tunnels through the Viprinet VPN Tunnel, some audio/video codecs). Please note that IP fragmentation is still not recommended as it will hinder performance. You should fix any IP fragmentation you have on your network as far as you can by adapting IP payload size to your network's MTU.

• Having more than 256 routes could cause the dynamic routing engine and router startup to fail.
• Fixed a bug that could cause routers to reboot once every 24 days.
• Fixed a problem with dynamic routing that would randomly appear on startups.
• Fixed WAN modules sometimes getting stuck in “Disconnecting” state, mostly seen with VDSL.

• In the stable release 2018070900 we had prepared support for the web interface to be able to use Unicode (for localization) in the future. The implementation contains a bug that if a certain URL formatwere included in a HTTP/HTTPS request, it would make the Hub/Router silently reboot without giving any message.
• In some rare cases, updating a 51x router to the stable release 2018070900 could make it hang during the boot process. For some customers this has never happened, for some it happened on a lot of devices. The exact reasoning why this is happening only for some customers are unclear, but with those who had seen the problem we have verified the bug is fixed.
• With the stable release the "Minimum guaranteed bandwidth/maximum allowed bandwidth" features of QoS did not longer work as expected. This is now fixed, they fully work as expected again. (Bug ticket #1391)
• For 200/5xx routers an optimization for reading packets going to internal router services (web interface, SSH CLI) was introduced in the stable release 2018070900. This has now been removed, as CPU cache bugs were causing packet loss and reordered packets when accessing router services. From our tests we have not seen any significant impact in performance.
• Viprinet routers contain a connection limiter making sure you can not overload the router's services with simple single-IP DoS attacks. It makes sure only a certain amount of connections per IP can be established per service. However, in the 2018070900 stable release this was broken on two counts: For HTTP/HTTPs and SSH the limit was not enforced at all.
  • Web interface: 25
  • VPN Channels: 25
  • SSH Connections: 3
• The code that decided on how many concurrent WAN Optimizer connections to allow was basing it decision on how much free RAM was left on a router. However, it did not take into account that RAM it already uses itself should also be counted as "free". This caused a router after running for a long time or having used a lot of WAN Optimizer connections to reduce the maximum allowed WAN Optimizer connections, effectively resulting in at some point the WAN Optimizer hardly being used at all anymore.
• The TCP Option 254 originally used for RFC3694-style experiments according to IANA is illegal and should not be used, however customers have reported that they have broken equipment in their network that improperly uses this option in shipping products. We therefore are now allowing this TCP Option as requested by a partner.
• If you had flapping channels on a Hub (channels constantly reconnecting), this would cause a small memory leak that over time would grow large until the Hub ran out of memory. (Bug ticket: #1399: Memory leak with flapping channels)

• In case the local output bandwidth of a WAN Optimizer connection dropped to zero, the WAN Optimizer would
  not notify the remote side to stop sending, therefore filling up the RAM. That's a very rare condition, because
  this can only happen if the receiving side of a TCP user connection would suddenly close the receive window
  forever. There is one case where we have seen this in real life: The "pause download" function of browsers.
• Removed "HUGE" debug messages that were flooding the logs in some installations, causing lots of
  headaches
• Fixed an ARP problem on the Hub's WAN Interface. If someone had a terribly broken switch configuration,
  this could cause a Hub's WAN interface to not be reachable for a long time after a reboot or IP change. This
  fix is not an invitation to run out-of-spec ARP cache timeouts on switches
• If a Multichannel VPN Router 300 runs out of memory, it will reboot. Before rebooting it would write a crash
  log to the flash. It turns out that sometimes the flash write-trough might not have completed by then. This
  could cause the flash to fail. This fix should prevent this to happen. However, keep in mind: On older 300s, the
  flash chip now is over 10 years old and therefore has long passed its typical mean time before failure. We
  recommend to replace your 300 routers.

• The WAN optimization feature is available as an option to be enabled in the QoS settings. If you restore your QoS Templates to manufacturing defaults, a new set of QoS classes including the WAN optimization feature will be available to be assigned to your tunnels.
• The download test tool has a new "delay" parameter that can be used to wait between sending the HTTP header and the actual data for a number of seconds – useful to simulate long-lasting idle connections.
  ​Like this: wget -O NUL "http://192.168.200.1/exec?module=download&delay=10".
• The route back option in LAN settings now has an option to disable its logging to prevent excessive logging.

• Due to both virtualization hypervisors and the Linux kernel addressing a bug on how a virtual machine identity is passed on to the guest operating system, on multiple hypervisors the device might get into a state of "identity crisis" after a firmware update – it will identify as a new machine with a different hardware ID, not matching its virtual hub license. We hope to have fixed this problem with this release. We've tested with latest versions of VMWare and KVM but if you are deploying Virtual Hubs please urgently check your own installations.
• Fragmented Packets are now also captured using the packet capture tool.
• Enabled Band 8 for 4.5G Europe/America.
• Fixed performance problems within IP fragmentation on 200/5xx.
• Fix for system getting stuck in a reboot loop if more than 256 routes are created.
• A big and complex fix for FEC:
  The first problem was that FEC was meant as a "this is a minimum guaranteed redundancy for the system". This makes sense for parity, but for packet duplication it does not.
  The logic was something like "If I want 4 channels, and in general have 4 channels connected / fitting the QoS needs, but only three of those can be used right now, then this means that we have reached the maximum available bandwidth and can not do anything".
  Turns out that the speed tests after the missing channel reconnected caused exactly this scenario – all channels are there, but for this one channel all the potentially available traffic is eaten by speed tests.
  The logic has now been changed: For parity it still is "we guarantee this minimum", while for duplication and up, now we just don't care – as long as we have a channel left, we'll send. This means that a potential QoS class doing lots of traffic could prevent a duplication class to only use a single channel most of the times. We still think it's more intuitive than it is today, and this limitation can be solved using bandwidth guarantees.
  ​Also, we have fixed the situation that a speed test can take away all the traffic of a channel, not allowing much user traffic (and none in case of duplicate and above).
• "ICMP time exceeded" messages caused by a routing loop could itself cause a routing loop resulting in a packet storm.
• Fixed ICMP stuff so you again see the Viprinet hop when doing a traceroute.
• Lots of optimizations for 5xx throughput/CPU load.
• Fixed CPU Temperature Sensor for 50X0.
• Fixed internal error BEF3238723CD2983.
• Fixed a long-standing bug in RuggedVPN (has always been present) that in a rare case if multiple channels had the exact same score could have caused that only one of them would be used.
• The HTTP server will now correctly declare the character encoding (UTF8 / Ansi) for any kind of text file (html, js, css etc) served. This is in preparation for a fully Unicode-enabled web interface that can be localized in multiple languages. Please report any strange encoding/character errors.
• Fixed WLAN AP config regions now being selectable with Toughlink.
• Fixed the "HTTP Server is eating 100% of the CPU forever" problem.
• "No gratuitous ARP on stacking failover" bug should be fixed.
• Fixed the underlying problem leading to Internal Error 137239A239232341 / Map size HUGE. That one is actually interesting: If you did NOT use guaranteed delivery and also did NOT use WANoptimizer, over time any flow would eat a few bytes of memory until the flow ends. If you had VERY long running connections(say a VPN tunnel through the VPN tunnel), and/or connections that ran a long time with very small packets(say a SIP trunk), the amount of memory available to the device could actually have mattered. Also, the longer this flow lasted, (a little) more CPU would have been used.
• All Gratuitous ARPs will be repeated after 5 seconds in case the first one gets lost for whatever reason.This fixes a problem with ARP on stacked nodes.

• We are not happy with the maximum bonding throughput we are seing on the 2610 and 2620. This will significantly improve with the next firmware release. If you are interested in trying a beta, let us know.
• IPv6 support had a lot of really bad bugs, one of which could cause very high CPU load. To be frank, IPv6 support has been broken since last December. As nobody complained after the last two stable releases, we assume it's not a big problem to our customers. Therefore, for this stable release we are now dropping most problematic IPv6 traffic. After this stable release, we'll re-enable IPv6 support after having fixed the bugs. If anyone of you is interested in testing IPv6 setups, let us know.
• If you have both WANoptimizer and non-wan-opt connections in a QoS class (say WANopt is enabled within QoS, but the same class is used for UDP), there might be starvation of non-wan-opt traffic. Please try not to have both UDP and TCP traffic in a QoS class where WAN optimization is enabled.
• There might be problems with fixed-bandwidth applications (Video streams) using the WANoptimizer. Please report back if you see any.
• The 300 is very low on memory. If you want to update/downgrade the firmware after using this release, you need to first reboot the device to have enough memory. In general, WANoptimizer is of limited use on the 300 due to the low amount of RAM it has. We highly recommend using one of our 300-to-310 trade-in offers and get rid of this outdated device.
• On 200 and 5xx, if you try to reach Integrated Services (web interface, ping to LAN IP, CLI etc) you will see packet loss and/or high ping times if the router is idle. If the router has some load, the problems disappear.
  This is a side-effect of optimizing WANoptimizer performance for these products and can not easily be fixed. Therefore it will stay this way for this release, and it will be fixed during the next beta cycle.
  ​In real life, this should not be much of an issue – however, it may confuse your monitoring systems (in our case, it did confuse an automated test doing a CLI login on an idle router).