• Das neue Web-Interface ist nun feature-complete, und alle bekannten Fehler wurden beseitigt. Es wird nun auch als Standard verwendet.
• Für die Nutzung des Web-Interface-Zugangs wird HTTPS empfohlen.
• Die Verschlüsselung für das Web-Interface wurde deutlich verbessert. Wir nutzen nun einen 2048-bit RSA-Schlüssel mit SHA256-Zertifikaten, TLS 1.2 und Perfect Forward Secrecy (Diffie-Hellman-Schlüssel-austausch mit Hilfe elliptischer Kurven). Bei SSLabs erzielen Viprinet-Router Bestnoten.
• Die Verschlüsselung für VPN-Tunnel wurde ebenfalls aktualisiert. Zusätzlich nehmen die VPN-Router nun einen Fingerabdruck des SSL-Zerfitikats des VPN-Hubs und lehnen die Wiederherstellung einer Verbindung ab, wenn sich der Fingerabdruck ändert. Das ist so geregelt, dass sich der Fingerabdruck weder beim Bearbeiten der Redundanz-Einstellungen von VPN-Hubs ändert noch beim Verschieben einer VPN-Hub-Konfiguration zu einem neuen VPN-Hub. Das neue System verhindert eine theoretische Man-in-the-Middle-Attacke gegen unsere Produkte, bei der ein Angreifer ein Gerät vor einem VPN-Hub installiert, das dessen IP-Adresse stiehlt und sich als dieser Hub ausgibt.
• Die neuen verbesserten Sicherheitsfunktionen verursachten auf dem Hub mehr Last, wenn ein Channel aufgebaut war. Wenn nun eine große Anzahl Channels gleichzeitig zum Hub verbanden, konnte die große Last eine Art DoS auf dem Hub verursachen, was wiederum eine Feedback-Schleife für die Last auslösen konnte: Aufgrund der hohen Last konnten die SSL-Handshakes der Channels nicht innerhalb der Timeout-Zeit durchgeführt werden, weshalb die Channel immer wieder abbrachen und sich neu verbanden, wodurch noch mehr Last produziert wurde.
  Wir haben nun eine Drosselung auf dem Hub und auf dem Router implementiert. Wenn nun ein Channel während des Verbindens zu einem Hub abbricht, wird er gedrosselt, anstatt auf den Hub mit Verbindungen einzuhämmern. Auf der Hub-Seite wird, wenn die CPU-Last hoch ist, die Annahme neuer Channels verzögert, ohne dass es zu einem Timeout kommt.
  Durch diese Änderungen sind wir nun in der Lage, eine höhere Channel-Verbindungslast auf dem Hub zu verarbeiten, als mit der vorherigen Stable-Firmware (deren SSL-Handshake noch dazu weniger sicher ist).
• Bei multiplen Authentifizierungsfehlern auf der SSH-CLI werden weitere Login-Versuche von derselben IP nun gedrosselt. Dies erschwert Brute-Force-Attacken auf SSH enorm.
• Das Verhalten von Routern und Hubs während einer DoS-Attacke wurde verbessert. Wenn von einem Quell- oder Zielhost mehr als 25.000 Flows (TCP-Verbindungen) eingingen, konnte dieser Host geblockt werden. Wenn jedoch die Hub-IP attackiert wurde, konnte es passieren, dass die Hub-IP selbst geblockt wurde; dadurch wurde das Web-Interface des Hubs unerreichbar, bis z.B. ein TCP SYN Flood DoS vorbei war. Nun werden lokal gebundene Router-IPs nicht mehr geblockt. Außerdem verursachte die Log-Menge während DoS-Attacken eine ziemliche CPU-Last; das wurde reduziert. Ein blockierter Host wird nun nur einmal geloggt, und erst dann wieder, wenn er nicht mehr blockiert wird (was passiert, sobald die Zahl an aktiven Flows wieder unter 24.000 sinkt).
• Channel Bandwidth Autotuning wird nun standardmäßig keine Log-Nachrichten mehr generieren. Das reduziert deutlich die Anzahl an Logzeilen, die auf beschäftigten VPN-Hubs mit vielen Tunneln/Channels generiert werden. Das Logging kann per Channel wieder eingeschaltet werden.
• Channel- und WAN-Bandbreiten-Berichte werden nun nur alle 10 Sekunden aufgezeichnet; wenn die Verbindungsgeschwindigkeit eines WAN-Gerätes unbekannt ist, wird sie nun nicht mehr aufgeführt, anstatt bisher mit „0/0“ protokolliert zu werden.
• Unsere neuen VDSL-Module werden nun voll unterstützt (inklusive VLANs und RFC1483).
• Der neue Multichannel VPN Router 200 wird nun unterstützt (dieser wird erstmals auf der CeBIT 2014 zu sehen sein).
• Der Code für die Überwachung der LTE-Module wurde komplett überarbeitet. Diese Firmware-Version unterstützt nun zum ersten Mal vollständig die Modulversionen 10-01031 und 10-01032 für die USA und Kanada. Nun können auch die verwendeten Technologien besser analysiert werden; der Code meldet außerdem die/das aktuell genutzte Frequenz/Band.
• Die Logik, anhand derer die Konfiguration eines anderen Routers darauf geprüft wurde, womit sie kompatibel ist, wurde neu geschrieben. Jetzt werden Projektrouter als mit sich selbst kompatibel markiert (ein anderer Router gleichen Modells und gleicher Projektnummer) und mit dem Standardmodell des übereinstimmenden Produkts. Beispiel: 50-00300 ist kompatibel mit 50-00300 und 01-00300, aber inkompatibel zu 51-00300.
• Die drei verschiedenen Arten von LTE-Modulen benennen sich ab jetzt automatisch nach „LTE 700 AWS/UMTS/HSPA+/GPRS/EDGE“ / „LTE/UMTS/HSPA+/GPRS/EDGE“ / „LTE 700/CDMA/EV-DO“ um, sobald das Chipset-Modell identifiziert wurde.
• Mit einem Hub verbundene VPN-Clients verwenden nun Hybrid Autotuning statt Heuristic auf dem Hub. Dadurch wird das Volumen an Test-Traffic in solchen Situationen reduziert, wenn die WAN-Konnektivität des PCs sehr instabil ist (z.B. bei einem Laptop-User, der in einem sich bewegenden Zug sitzt).
• Für alle lokalen Dienste (DNS, AdminDesk HTTP/HTTPS, SSH CLI, SNMP) gibt es nun Zugriffskontrolllisten (ACLs). Mit diesen können Sie definieren, welche IPs und Subnetze vom LAN oder WAN/VPN auf welche Dienste zugreifen können. Beim Firmware-Upgrade wird ein Standard-Regelsatz generiert. Diese Regeln wurden so erstellt, dass sie bestehende Installationen nicht beeinträchtigen, und es wird empfohlen, sie zu verfeinern. Beispielsweise wird momentan Zugang zum AdminDesk auf HTTP und HTTPS von überall erlaubt, während wir empfehlen, nur HTTPS vom Internet aus zu erlauben.
  ACHTUNG: Aufgrund der neuen ACLs wurden die AdminDesk SSL-Zertifikatseinstellungen im Web-Interface von „[ AdminDesk ] LAN settings“ nach „[ AdminDesk ] Integrated services“ verschoben. Sollten Sie Ihr eigenes SSL-Zertifikat installiert haben, müssen Sie dieses nach dem Firmware-Upgrade erneut installieren.​
  ACHTUNG: Auch alle SNMP-Einstellungen wurden im Web-Interface nach „[ AdminDesk ] Integrated services“ verschoben. Nach dem Firmware-Upgrade müssen Sie auch SNMP erneut konfigurieren.
• Es gibt nun ein vollautomatisches Diagnose-Tool, das Durchsatz, Packetloss, etc. für alle Interfaces testet. Bei Multichannel VPN Routern werden lokale Module sowie alle Module von gestackten Routern gemessen, ferner auch die VPN-Performance. Bei Multichannel VPN Hubs wird nur der Durchsatz von LAN- und WAN-Interfaces gemessen.
  Mithilfe dieses Tools werden erste Diagnosen in allen „Ich erreiche nicht die Leistung, die ich erwartet habe“-Fällen wesentlich einfacher. Wir legen Ihnen die Verwendung dieses Tools sehr ans Herz.
  Sie finden das „Connectivity diagnostics tool“ innerhalb der „Logging & Maintenance“-Einstellungen (im alten Web-Interface, in der Beta des neuen Web-Interface ist diese Funktion noch nicht verfügbar).
• Sollten Sie optionale Routerfunktionen testen wollen, können Sie sich nun unter https://license.vipri.net/trial.php mithilfe des Trial-Tokens, den Sie im Web-Interface unter „Product features License Manager“ finden, eine 30 Tage gültige, kostenlose Trial-Lizenz generieren lassen.
  Dieser Web-Dienst wird eine aktivierte Lizenzdatei generieren, die Sie dann im Web-Interface einfügen können. Die generierte Lizenz wird alle optionalen Funktionen des Routers für einen Zeitraum von vier Wochen aktivieren. Sie kann einmalig mithilfe des Webservers verlängert werden, wird danach aber für einen Monat gesperrt. Bitte beachten Sie, dass der Router am Ende des Testzeitraums automatisch rebooten wird.
  Achtung: Das Viprinet-Supportteam wird Trial-Lizenzen für Routerfunktionen nicht mehr manuell ausgeben. Bitte nutzen Sie stattdessen das Selbstbedienungssystem.
• Die Summe aller Bandbreiten vom/zum WAN auf allen Channels ist nun als Datenquelle für den Tunnel in der Monitoring API verfügbar.
• Einige Leistungsverbesserungen sorgen dafür, dass nun alle Produkte ca. 5-10% mehr Bündelungskapazität haben.
• Der Startup-Code für Viprinet Router wurde optimiert. Dadurch geht die Inbetriebnahme eines Viprinet Hubs mit tonnenweise Tunneln nun wesentlich schneller vonstatten.
• Die Router haben nun eine maximale Anzahl an Tunneln, die konfiguriert werden können.​
  WICHTIGER HINWEIS: Das bedeutet nicht, dass der Router tatsächlich in der Lage sein wird, so viele Tunnel gleichzeitig bei annehmbarer Leistung zu halten – dies hängt auch von der Anzahl der Channels pro Tunnel und von der Komplexität der QoS-Regeln ab.
  Hier ist die Anzahl maximal zulässiger Tunnel je Produkt:
  • 300: 25
  • 500: 25
  • 1600/1610/2610/1620/2620: 50
  • 1000/1020: 100
  • 2000/2020: 150
  • 5000/5010: 500
• Bis jetzt nutzte das Hub-Redundanzsystem ausschließlich Ethernet-Broadcast bei der Kommunikation von Hubs untereinander. Aufgrund einer technischen Limitierung im verwendeten Kommunikationsprotokoll konnten Hubs nur dann Konfigurationsdateien teilen, wenn deren komprimierte Größe unter 64k lag. Leider war der Benutzer nicht in der Lage, herauszufinden, wie groß die aktuelle Konfiguration ist. Wenn die komprimierte Konfigurationsdatei etwas größer war als 64k, versagte das Hub-Redundanzsystem beim Synchronisieren der Konfigurationsdateien. Bei einigen Hub 5010-Installationen mit einer großen Anzahl an Tunneln und QoS-Konfigurationen wurde diese Limitierung tatsächlich auch erreicht.
  Zusätzlich gab es beim Broadcasting Protocol ein grundsätzliches Problem: Wenn viele VPN Hubs zur gleichen Zeit im Betrieb waren, konnte es bei mehreren Hubs passieren, dass sie ihre Konfiguration exakt zur selben Zeit an den Hotspare schickten. In diesem Fall erhielt der Hotspare aufgrund von Fragmentierung manchmal überhaupt keine Konfiguration. Dieses Problem verschlimmerte sich, wenn in einer einzelnen Redundanzgruppe mehrere Hotspares liefen.
  Wir haben das Hub-Redundanzsystem so verbessert, dass die hauptsächliche Kommunikation noch immer über Broadcasts läuft, für die Übertragung von Konfigurationsdateien aber nun eine direkte TCP-Verbindung zum Hotspare aufgebaut wird. Daher ist die Größe der Hub-Konfigurationsdateien nun unlimitiert. Das neue Protokoll wurde abwärts kompatibel gestaltet. Das bedeutet dass Hotspare Hubs, die mit der aktuellen Firmware laufen, immer noch produktive Hubs bedienen können, die mit der vorherigen Stable Firmware-Version laufen und ihre Konfiguration noch nicht per TCP synchronisieren können. Wir empfehlen dennoch, bei allen Hubs in einer Redundanzgruppe dieselbe Firmware-Version zu verwenden.
• Bis jetzt konnte es passieren, dass Viprinet-Router manchmal Traffic als nicht routbar markierten, wenn der Tunnel down war, während der Traffic-Flow aufgebaut wurde. Seit der letzten Stable Firmware-Version wurde diese Restriktion noch etwas strenger: Jeglicher Traffic-Flow, der aufgebaut wurde, bevor der Tunnel bestand, wurde für immer als nicht routbar markiert. Wir haben nicht erwartet, dass das je ein Problem wäre - die meisten gesunden Protokolle brechen bei so etwas ohnehin ab und verbinden neu. Das ist aber z.B. bei ISAKMP von IPSec nicht der Fall, einem völlig hirnverbranntem Protokoll: Es nutzt per Konvention immer den UDP Quell- und Zielport 500. Dadurch wird es unmöglich, zwischen diesen ISAKMP-Flows zu unterscheiden, was unter anderem auch bei NAT Gateways Probleme verursacht. Bei Viprinet wurde, wenn ein IPSec Gateway einen IPSec-Tunnel aufbaute, bevor der Viprinet-Tunnel bestand (z.B. weil der Viprinet-Router, aber nicht das IPSec Gateway rebootet wurde), der ISAKMP-Flow als permanent nicht routbar markiert. Das konnte passieren, weil das IPSec Gateway nie „abbrach“, und selbst wenn, dann würde ein neues IPSec-Setup genauso aussehen wie das alte, da die UDP Quell- und Zielports sich nicht änderten.
  Wenn also das IPSec Gateway keine vernünftigen Timeouts benutzt, konnte es passieren, dass IPSec-Tunnel durch einen Viprinet-Tunnel für immer stecken blieben.
  Das verursachte keine Probleme mit IPSec Gateways, die wir intern testen konnten, denn diese warteten einfach einige Sekunden vor einem erneuten Versuch, falls der ISAKMP-Handshake fehlschlug. Bis dahin zeigte der Flow vom UDP-Port 500 im Viprinet-Router eine Zeitüberschreitung, und das neue ISAKMP-Setup wurde als neuer Flow betrachtet, der dank des Viprinet-Tunnels nun als routbar markiert wurde.
  Wie wir gelernt haben, verhalten sich nicht alle IPSec Gateways so – einige hämmern ohne Unterlass für den Fall, dass der ISAKMP-Handshake nicht funktioniert. Das ist unklug, aber leider Realität.
  Wir haben das Routing-Design innerhalb der Viprinet-Router so geändert, dass nun diese Art von Problemen bewältigt werden kann, während die Geräte weiterhin optimale Leistung bringen. Traffic-Flows, die als unzulässig/nicht routbar markiert werden, werden nun alle 2 Sekunden darauf überprüft, ob es in der Zwischenzeit möglich geworden ist, sie zu routen. Auf diese Weise haben wir weder hohe Last durch Systeme, die den Router mit nicht routbaren Ziel-IPs fluten (was zumindest eine Art von DoS ermöglichen würde), noch haben wir Probleme mit Protokollen, die immer denselben Flow hämmern, während der Viprinet-Tunnel noch nicht aufgebaut ist. Es ist unmöglich, alle verfügbaren IPSec Gateway-Kombinationen zu testen, aber bei denen, die wir testen konnten, wurden IPSec-Tunnel typischerweise nach einigen Sekunden (wieder) aufgebaut, nachdem auch der Viprinet VPN-Tunnel wieder kam.

• Wir haben eine potenzielle Downgrade Attack auf das VPN-Tunnel-Protokoll behoben. Bei einer Man-in-the-middle-Attacke konnte ein Angreifer einen VPN-Router dazu zwingen, auf eine veraltete Viprinet VPN-Tunnel-Protokoll-Version zurückzuschalten, bei der das Tunnel-Passwort in Klartext über die SSL-Verbindung gesendet wurde. Auf diese Weise konnte das Tunnel-Passwort gestohlen werden und ein falscher, vom Angreifer betriebener VPN-Router konnte sich anstelle des echten zum VPN-Hub verbinden, wo er Zugang zum VPN erlangen konnte. Wir möchten an dieser Stelle der Firma Portcullis Security für ihre Forschung und ihre Beratung in dieser Sache danken. Die alten VPN-Tunnel-Protokoll-Versionen wurden deaktiviert.
• Sowohl im alten, als auch im neuen Web-Interface wurde Eingaben nicht richtig gefiltert, sodass eingeloggte Benutzer alle Arten von Cross-Site-Scripting-Attacken (XSS) ausführen konnten. Alle bekannten Attacken werden nun ordnungsgemäß gefiltert.
• Ab dieser Firmware-Version ist es nun nicht länger möglich, Objekte (Tunnel, Channel, etc.) mit unzulässigen Zeichen anzulegen. Existierende Objekte werden weiterhin geladen. Überprüfen Sie Ihre Log-Dateien für kritische Warnungen diesbezüglich und benennen Sie alle Objekte mit unzulässigen Sonderzeichen um – mit der nächsten Firmware-Version werden diese Objekte nicht länger geladen werden.
• Hybrid Autotuning zeigte einen Fehler, der dazu führen konnte, dass MaxBandwidthToWAN auf „0“ gesetzt wurde und bei diesem Wert blieb.
• Wenn mehrere Benutzer mit demselben Benutzernamen im Web-Interface eingeloggt waren (egal ob altes oder neues), konnte jeder Benutzer nur einen Teil der Log-Nachrichten sehen.
• Wenn Channel Bandwidth Autotuning für einen verbundenen Channel ausgeschaltet war und MaxBandwidthToWAN manuell auf „0“ gesetzt wurde (wie es manchmal auf dem VPN-Hub gemacht wird, um nicht den Downstream einer teuren UMTS-/LTE-Verbindung nutzen zu müssen, sondern sie nur als Upstream-Booster zu verwenden), konnten bizarre Effekte auftreten. Wenn besagter Channel die niedrigste Latenz, die beste LinkStability oder den niedrigsten Kostenwert hatte, konnte es passieren, dass QoS-Klassen diesen Channel bevorzugt zur Nutzung auswählten, obwohl sie keinen Traffic durchleiten konnten. Daher konnten diese QoS-Klassen keinen Traffic mehr transportieren. Channels mit Bandbreite „0“ werden nun vom QoS-System ignoriert.
• In einem Node-Stacking-Setup konnte manchmal ein DHCP-Dienst auf einem Slave-Gerät laufen, obwohl er das nicht sollte.
• Die CLI sollte nun korrekterweise Int64- und Float-Werte unterstützen, daher sollten Sie nun in der Lage sein, GPS-Positionsdaten mithilfe der CLI auszulesen.
• Bei den LTE-Modulen war der Wert „Expected link capacity“ falsch gesetzt, wenn die Module HSDPA nutzten. Dieser Fehler war in der EU sehr selten zu sehen, da man hier normalerweise HSPA+ anstatt HSDPA nutzt (=HSUPA und HSDPA+). Wenn HSUPA mit HSDPA kombiniert wurde, erreichte die Expected link capacity 348 kbit/s im Downstream, wodurch Autotuning ausgelöst wurde. In den USA trat dieser Fehler häufig bei Verwendung der Module mit AT&T und T-Mobile auf.
• Beim Routermodell 300 konnten wir Pufferüberläufe auf dem LAN-Interface sehen, wenn plötzlich eine große Menge an Paketen zum LAN gesendet wurde. Das passierte z.B. bei der Bündelung instabiler Verbindungen, bei denen Daten nach Packet-Loss/Retransmissions in großen Mengen übertragen wurden. Dieses Problem verursachte verlorene Pakete auf dem LAN, und diese verlorenen Pakete lösten TCP-Retransmissions auf der Anwendungsebene aus, wodurch der erreichbare Durchsatz bei Verbindungen mit hoher Latenz ziemlich eingeschränkt werden konnte. Das Problem besserte sich nach einigen Stunden von selbst. Allerdings bedeutete das, dass 300er in Demo-Situationen (nur eingeschaltet, um UMTS/LTE zu bündeln) instabile Download-Geschwindigkeiten erreichten.​
  Dieses Problem sollte jetzt behoben sein.
  Um das zu überprüfen, rufen Sie „[ AdminDesk ] LAN settings -> Ethernet interface info tool“ auf.
  Dort sollten die „Overruns“-Zähler für TX und RX immer bei 0 bleiben.
• Ein Fehler beim BondingTCPOptimizer wurde behoben: Manche Geräte konnten beim Senden eines Zero Window steckenbleiben, da der Linux-Stil des Window-Probing, den Viprinet nutzt, ignoriert wurde. Wir haben nun auch ein zufälliges Window-Probing im Windows-Stil eingerichtet (das versucht, Daten außerhalb des Fensters zu senden). Dadurch wird künftig verhindert, dass Video-Streams bei Samsung Smart TVs hängen bleiben.
• Diese Firmware-Version beinhaltet vorläufige experimentelle Unterstützung für die kommenden neuen VDSL-Module.
• Auf Hubs 5000 und Hubs 5010 gab es das Problem, dass unter gewissen Umständen das LAN-Interface blockieren und daher keine Pakete mehr empfangen konnte. Dieses Problem wurde behoben.
• Es gab verschiedene Fehler bezüglich des Hub-Redundanzsystems. Wenn viele Multichannel VPN Hubs in einem LAN-Segment eines Rechenzentrums betrieben wurden, funktionierte manchmal das Verteilen der Konfigurationsdatei nicht. Außerdem verursachte der Betrieb mehrerer Hotspare-Hubs in derselben Hotspare-Gruppe (was eigentlich eine gute Idee ist) manchmal (selten), dass zwei Hotspare-Hubs gleichzeitig die Identität eines ausgefallenen Aktiv-Hubs übernahmen, sodass es zu einem Adresskonflikt kam. All diese Probleme wurden behoben, sodass der Betrieb von mehreren Hotspares in einer Redundanzgruppe nun problemlos funktioniert.
• Manchmal unter seltenen Umständen konnten IP-Flows durch einen VPN-Tunnel steckenbleiben. In diesem Fall wurde im Log die Meldung „10001 packets in WANPacketHeap“ ausgegeben. Diese Meldung trat manchmal bei Flows auf, die „für immer“ (wie IPsec-Tunnel durch einen Viprinet-Tunnel) auf Systemen liefen, während der Viprinet VPN-Tunnel aufgrund instabiler WAN-Links oft abbrach. Flows sollten nun nicht länger steckenbleiben.
• Wenn BondingTCPOptimizer benutzt wurde, konnte es passieren, dass gewisse beschädigte TCP-Pakete ein Speicherleck verursachten. Ein Sturm dieser Pakete (z.B. während einer DoS-Attacke) konnte früher oder später für einen Reboot des Routers sorgen.
• Kleine Fehlerbehebung für BondingTCPOptimizer: Bei sehr langsamen Servern konnten Retransmissions von SYN-Paketen seltsames Verhalten bewirken. Tatsächlich beobachtet mit Samsung-Fernsehern und dem deutschen VoD-Dienst Maxdome.
• Die Konfliktlösung beim Restart von gestackten Routern wurde verbessert.
• Ein Fehler wurde behoben, der durch einen SSL Handshake-Felher unter seltenen Umständen den Aufbau eines Tunnel-Channels zum VPN Hub abbrechen lassen konnte.

• In Stacking-Setups mit mehr als 2 Routern gab es einige Fehler. Ein Slave, der von einem alten zu einem neuen Master wechselte, konnte abstürzen; alternativ konnte es passieren, dass einige der geteilten Module auf dem Slave nach dem Wechsel nicht mehr funktionierten.
• Das "Download Test Tool" im Web-Interface konnte den Router abstürzen / rebooten lassen.

Wir empfehlen allen Kunden, die zuvor auf die Firmware-Version 2013051031/2013060600 geupdatet haben, ihre Router erneut zu updaten. Allen anderen Kunden wird empfohlen, auf die aktuelle Firmware-Version zu updaten, um die zahlreichen Verbesserungen nutzen zu können, die das Stable Firmware-Release aus Juni bringt.

• Wichtig: Alle unsere jüngsten Firmware-Versionen (Stable und Cutting Edge-Releases seit April 2013) beinhalteten einen kritischen Fehler: Wenn ein VPN-Tunnel aufgebaut und dann getrennt, danach erneut aufgebaut und wieder getrennt wurde, diesmal für mehr als 3 Minuten, dann konnten Router und Hub abstürzen und neustarten.
  Wir entschuldigen uns für eventuelle Unannehmlichkeiten, die das bei Kunden verursacht haben könnte, und möchten uns an dieser Stelle bei denjenigen unserer Partner bedanken, die den Fehler gefunden und uns davon berichtet haben.
  Aufgrund dieses Fehlers sahen wir uns auch gezwungen, alle Firmware-Versionen seit April 2013 von unseren Servern zu nehmen. Wenn Sie eine der betroffenen Versionen verwenden, updaten Sie Ihre Geräte bitte umgehend.
• Das Download Test Tool innerhalb des Web-Interface konnte den Router zum Absturz bringen, wenn die heruntergeladene Test-Datei HTTPS nutzte.
• Manchmal konnten Tunnel-Channels aufgrund eines SSL Handshake-Fehlers beim Verbinden direkt wieder abbrechen und neu verbinden, und es konnte eine Weile dauern, bis die Verbindung stabil bestehen blieb. Das passiert nun nicht mehr, dieser Handshake-Fehler ist behoben.
• Passive und Hybrid Autotuning, deren Nutzung bei mobilen Verbindungen (UMTS, LTE, Sat) empfohlen wird, tendierten dazu, die Max Bandwidth To WAN auf einen Wert zu optimieren, der leicht über dem optimalen Wert liegt. Dadurch konnte es zu Buffering auf dem Channel kommen, was im Monitoring für Latenz und aktuellem Traffic durch diesen Channel als „Sägezahn“-Form aufschien. Das Autotuning wurde verbessert, um die Geschwindigkeit dann langsamer zu erhöhen, wenn der Wert für „Optimal Latency Below“ fast erreicht ist.
  Diese Optimierung verbessert die Stabilität von Latenz-kritischen Anwendungen wie VoIP über instabile Verbindungen um einiges.
• Die Hub-Modelle 1020 und 2020 berichteten manchmal, dass ein oder zwei Lüfter zu langsam liefen, und meldeten daher, dass diese vermutlich defekt seien. Das ist tatsächlich nicht der Fall, daher wurde die Minimaldrehzahl der Lüfter bei diesen Produkten im Vergleich zu anderen Produkten gesenkt.
• Das Download Test Tool brach aufgrund zu hoher CPU-Auslastung öfters ab. Es ist nun in dieser Hinsicht etwas entspannter.
• Das Hub-Redundanzsystem markiert nun korrekterweise die Hub-Modelle 1000, 1020, 2000 und 2020 als zueinander kompatibel. In früheren Releases waren die Modelle 1020 und 2020 als inkompatibel zu früheren Hubgenerationen markiert.

• Deutlich verbessertes Channel Bandwidth Autotuning. Sie bekommen nun viel bessere Ergebnisse für alle Arten von Verbindungen, speziell aber Sat-Verbindungen. Hybrid Autotuning bekommt nun viel bessere Ergebnisse bei seinen anfänglichen Tests auf VPN-Tunnels, die idle sind. Überlastung auf dem Channel wird nun Max Bandwidth To WAN wesentlich weniger drastisch senken, d.h. Sie werden bessere Leistung auf WAN-Links sehen, die viel Packet Loss zeigen.
• VLANs on Node werden nun auf folgende Art unterstützt:
  • In den LAN-Setting gibt es nun eine „Allow route-back“-Option. Wenn diese aktiviert wird, kann Traffic, der von einem VLAN kommt, zum selben oder einem unterschiedlichen VLAN zurückgeroutet werden – in anderen Worten, VLAN-Segmente können miteinander sprechen. Wenn die Funktion deaktiviert ist, wird Traffic vom LAN mit Ziel im LAN stattdessen gedroppt, sodass die VLANs in diesem Fall komplett separiert sind und nur mit dem VPN-Tunnel sprechen können.
  • Auf dem Node gibt es die Option „Allow all VLANs to talk to tunnel“. Wenn diese aktiviert ist, können alle VLANs mit dem Tunnel sprechen; wenn sie deaktiviert ist, kann das nur VLAN0.
  • In den WAN/VPN Routing-Einstellung auf dem Hub kann ebenso eine „allow route-back“-Option aktiviert werden. Wenn diese inaktiv ist, wird der Traffic, der vom Tunnel reinkommt und in denselben Tunnel gehen würde, gedroppt.

Mithilfe dieser Funktionen können Sie nun sowohl einen Router (Node) implementieren, der ein lokales VLAN hat, welches nicht mit dem VPN, dafür aber mit dem restlichen LAN sprechen kann, wie auch ein Setup erstellen, bei dem mehrere VLANs voneinander getrennt, aber in der Lage sein sollen, mit dem VPN zu sprechen (z.B. ein Firmennetzwerk und gleichzeitig ein öffentliches Besucher-WLAN).

Bitte beachten Sie, dass VLAN-Tags NICHT durch den Tunnel transportiert werden. Aus Sicht des Hubs kommt noch immer aller Traffic aus einem einzigen Tunnel mit einer einzigen Tunnel Segmentation ID. Wenn Sie die gerouteten Netzwerke separat behandeln müssen, müssen Sie ein VLAN auf dem Hub anlegen und den gesamten Traffic aus dem Tunnel zu einem Next-Hop in diesem VLAN routen, wo Sie dann den Traffic nach seinen Quell-IPs in mehrere verschiedene VLANs auftrennen.

• Auf allen Routern und Hubs findet sich nun ein integrierter HTTP Test-Traffic-Generator, der unter [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads aktiviert werden kann.

Wenn er aktiviert ist, können HTTP Test-Downloads von diesem Router gemacht werden ohne irgendeine Form der Authentifizierung. Dies sollte nur aktiviert werden, solange Sie selbst testen, und für Produktivsysteme deaktiviert werden.

Wenn diese Funktion aktiviert ist, kann ein zufälliger Datenstrom von diesem Router runtergeladen werden unter folgender URL:

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

Speed wird angegeben in Bit/s, 1K bedeutet 1Kbit/s, 1M bedeutet 1 MBit/s, 1G bedeutet 1 Gbit/s. Der Speed-Parameter ist optional. Wenn dieser Parameter nicht gegeben ist, wird die maximal mögliche Link-Geschwindigkeit genutzt. Der maximale erlaubte Wert ist 1G.

Size ist die Größe der herunterzuladenden Datei in Bytes, 1K bedeutet 1 Kbyte, 1M bedeutet 1 MByte, 1G bedeutet 1 GByte. Der Größen-Parameter ist optional, wenn er nicht gegeben ist, werden 16 GByte angenommen, also der maximale erlaubte Wert.

• Viprinet-Router beinhalten nun eine Sicherheitsfunktion, die vor den meisten bekannten Arten der DNS Amplification-Attacke Schutz bietet – eine einzelne IP darf jetzt nur 2 BELIEBIGE Anfragen innerhalb von 60 Sekunden stellen. Wir empfehlen weiterhin, in Ihrer Kern-Firewall ausgefeiltere Methoden zum Schutz vor DNS-Amp-Attacken zu installieren.
• Das Download-Test-Tool in den LAN- und Modul-Settings wurde erweitert und um einiges verbessert. Es kann nun Test-Dateien von einem weltweiten von Viprinet zur Verfügung gestellten Content Delivery Network runterladen, welches automatisch den Edge-Server wählt, der Ihrer Position am nächsten ist, oder – sofern der Hub diese Firmware nutzt – vom Hub Traffic-Generator runtergeladen wird. Hiermit haben Sie ein Tool, mithilfe dessen Sie einfach Ihre Verbindung und Durchsatzprobleme mit WAN-Interfaces testen, und überprüfen können, wo der Flaschenhals bzgl. Ihrer Bandbreite ist. Benutzen Sie es!
• In den Channel Feineinstellungen kann nun eine Minimum-Link-Stabilität definiert werden, die ein Channel haben soll; dabei wird eine Warnung ins Logsystem verschickt, wenn die Link-Stabilität diesen Wert unterschreitet. Für stationäre Installationen sollte ein aktiver Link mehr als 90% Stabilität aufweisen, bei sich bewegenden Fahrzeugen hängt das von der typischen Netzabdeckung ab. Mithilfe dieser Einstellung können Sie leichter automatische Benachrichtigungen einstellen, wenn Verbindungsprobleme auftreten (z.B. wenn eine SIM-Karte ihr Traffic-Limit erreicht).
• Die Monitoring AP, die vom Viprinet Monitoring Tool verwendet wird, verursachte eine hohe CPU Load auf dem überwachten Router. Diese Load wurde gesenkt.
• Früher verwendete das Konfigurationssystem (sowohl Web-Interface als auch CLI) eine globale Sperre, die den Routing-Kern für mehrere Sekunden komplett lahmlegte – z.B. konnte der Router, während LAN-Settings zugewiesen wurden, keine Pakete routen. Diese globale Sperre wurde nun entfernt, und das Arbeiten im Web-Interface sollte nicht länger solche drastischen Effekte auf die Routing-Leistung von Viprinet-Routern haben.

• Wenn sich VPN Clients in einem gewissen zeitlichen Muster zu/von VPN Hubs verbanden/trennten, konnte der Hub früher oder später abstürzen und rebooten. Das passierte meistens dann, wenn ein VPN Client zu einem VPN Hub verband, die Verbindung trennte, direkt wieder aufbaute und vor erneutem Wieder-Verbinden erneut für mind. 3 Minuten trennte. Dieses Problem wurde behoben, VPN Clients können VPN Hubs nicht länger zum Abstürzen bringen.
• Reparatur bei heuristischen Autotuning: In der Theorie (nicht bestätigt durch reale Ereignisse) konnte Autotuning in eine Endlosschleife geraten, sodass unglaubliche Mengen an Test-Traffic erzeugt wurden.
• Eine große Zahl an SNMP-Fehler wurde behoben. Am wichtigsten ist, dass Hotspare Hubs, die einen Hub übernehmen/ersetzen, nun korrekterweise normale volle Viprinet SNMP auf den übernommenen IPs berichten und Hotspare SNMP-Antworten auf der Hotspare IP ausgeben.
• SNMP ändert nicht länger OIDs auf anderen Tunnels, wenn ein Tunnel gelöscht wurde.
• SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature sind nun implementiert.
• Aufgrund einer Race Condition konnte Node Stacking manchmal in Failover-Situationen abstürzen. Auch der „Failed to open slot for stacking“-Fehler wurde behoben, sowie der interne Fehler 23239482394811Aa.
• Konfiguriertes Stacking zu deaktivieren konnte die falsche Fehlermeldung „[Stacking] This router does not have the stacking featured licensed. Can not start stacking!“ hervorrufen.
• Es konnte manchmal passieren, dass ein Node-Stacking Slave den internen DHCP-Server nicht beendete. Dadurch konnten zwei DHCPs auf dem LAN laufen, wodurch es zu Problemen kommen konnte.
• Der Firmware Online-Updater erforderte immer das DOPPELTE Klicken auf „check for updates now“, um ein aktuelles Ergebnis zu bekommen. Nun funktioniert schon der erste Klick.
• ADSL-Module hatten manchmal Probleme damit, die Modul-Info zu lesen zu lassen. Wir haben den Timeout für das Warten auf die Antwort vom Modem-Diagnostik-Bericht erhöht. Bitte benachrichtigen Sie den Viprinet-Support, wenn Sie beim Auslesen der Modul-Info eines ADSL-Moduls immer noch Fehlermeldungen bekommen.
• Alles im Bezug auf „Ethernet speed and auto-negotiation settings“ wurde überarbeitet. Es gab an allen Ecken und Enden Fehler: Das Ausschalten der Auto-Negotiation bei manchen Produkten und Ethernet-Modulen funktionierte nicht; das Ausschalten der Auto-Negotiation wurde beim nächsten Router-Reboot ignoriert; und zahlreiche andere. Alle wurden behoben, und wir haben sichergestellt, dass das manuelle Setzen von Ethernet Parametern nun bei allen Produkten und Modulen funktioniert, auch nach Reboots.
• Die „Reconnect“-Funktion von Fast/Gigabit Ethernet Modulen verursacht keinen PHY Reset / Neustart der Ethernet Auto-Negotiation mehr. Wenn Sie das möchten, müssen Sie das Modul jetzt resetten.
• VLANs und eine MTU von 1500 zu nutzen funktioniert bei Fast Ethernet Modulen nicht (mit Gigabit Ethernet Modulen hingegen schon). Nun funktioniert es bei beiden Modulen.
• Es konnte passieren, dass der Routing-Kern aufgrund von Rundungsfehlern in der Praxis oft mehr durchschnittliche Bandbreite auf einen Channel schickte als der „Maximum Allowed Bandwidth to WAN“-Wert erlaubte. Bei manchen Verbindungstypen konnte das dazu führen, dass der Link überlastet wurde und die Latenz trotz perfekter Autotuning-Resultate stieg. Diese Rundungsfehler wurden behoben.
• Seit der letzten Stable Firmware-Version werden Änderungen bei LAN-Einstellungen inkl. LAN Aliases übernommen noch bevor der Knopf „Apply Settings“ gedrückt wird. Das konnte für einen unsauberen Zustand sorgen, wenn man gerade dabei war, einen LAN Alias anzulegen.
• Wenn „Allow remote service connections“ eingeschaltet war und dann ausgeschaltet wurde, konnte es passieren, dass Remote Service-Verbindungen weiterhin möglich waren, bis der Router rebootet wurde. Das Ausschalten dieser Funktion hat nun direkt den erwarteten Effekt.
• Das Download Test-Tool konnte oft abstürzen „due to high CPU load“, selbst wenn die CPU Load gar nicht hoch war.

• Channels können nun Backup Scores haben, und dem Tunnel kann ein Minimum-Backup Score zugewiesen werden. Das erlaubt Ihnen Setups, bei denen mehrere Backup-Channels genau dann aktiviert werden, wenn der Master-Channel abbricht, bis der Verlust im „Score“ ausgeglichen wurde. Der Router wird mehr Backup-Channels aufrufen, bis der Minimum Backup Score des Tunnels erreicht ist. Der Backup Score eines Channels wird auch mit dem Link Stability-Wert des Channels multipliziert, daher bekommen instabile Channels nicht den vollen Score. Auf diese Weise ist ein Schutz gegen Link Flapping gegeben.
• Mithilfe von Stacking können mehrere Node-Router einen Stack bilden und so zu einem großen Router werden. Einer der Router bekommt die Master-Funktion zugewiesen und benutzt die anderen Router, die als Slaves dienen. Wenn ein Slave-Router ausfällt, brechen nur die Channels ab, die über den Slave-Router laufen. Wenn der Master-Router ausfällt, wird ein Slave-Router automatisch der neue Master. Wenn der festgelegte Master-Router wiederkommt, geschieht ein automatischer Failback. Damit all das funktionieren kann, synchronisiert der aktuelle Master-Router permanent einen Großteil der Router-Konfiguration mit den Slaves. Außerdem bringt der aktuelle Master-Router mindestens eine dedizierte IP-Adresse ins LAN, die ebenso übernommen wird, wenn ein Slave zum Master wird. Diese geteilte IP wird als Gateway ins LAN genutzt. Detaillierte Anweisungen zum Aufsetzen eines Stackings sind nun verfügbar. Stacking erfordert das Verwenden einer optionalen Zusatzlizenz.
• Wenn der Router mit einem GPS-Empfänger ausgestattet ist (für modulare Router bedeutet das, dass zumindest ein LTE/GPS-Modul verwendet wird), kann der Router nun seine aktuelle Position kommunizieren. Mit dem neuen Web-Interface ist eine Integration von Google Maps möglich.
• Channels können nun den Wert „Kosten“ haben. Channels mit niedrigeren Kosten werden bevorzugt, wenn nicht die gesamte verfügbare Bandbreite genutzt wird. Sie können nun z.B. ADSL-Channels haben, um damit den meisten Traffic kostengünstig abzuwickeln, und UMTS/LTE-Channels für Traffic-Spitzen.
  Dieses Feature ist noch nicht ganz ausgereift, wenn mehr als 2 verschiedene Kosten-Level definiert werden.
• Ein neues modern aussehendes Web-Interface ist nun optional und parallel zum alten Web-Interface verfügbar. Das neue Web-Interface beschleunigt die Router-Administration dramatisch. So können Sie z.B. mehrere gleiche Objekte zur selben Zeit bearbeiten (z.B. alle Channels eines Tunnels). Das neue Web-Interface erfordert einen aktuellen Browser (IE9+, Firefox 3.6+).
• Bei zukünftigen Firmware-Releases werden wir die erlaubten Zeichen in Objektnamen und String Properties begrenzen. Nur die folgenden Zeichen werden erlaubt sein:
  'a'..'z', 'A'..'Z', '0'..'9', '-', '+', '.', '_', ' ', '#', '(', ')', '/'​
  Wenn Sie momentan irgendwo andere Zeichen verwenden (Tunnel- oder Channel-Namen, Routing-Regeln, Router-Namen, etc.), ändern Sie sie bitte. Mit diesem Firmware-Release wird im Log eine Warnung ausgegeben, wann immer nicht-erlaubte Zeichen benutzt werden.​
  Der Grund für diese Änderung ist der bessere Schutz gegen Injection-Attacken auf allen Levels.
• Von Benutzern angelegte Objekte wie Tunnels und QoS-Klassen sollten nun nur noch etwa 1/4 so viel Memory benötigen wie bisher. Dadurch wird eine größere Anzahl an konfigurierten Tunnels und QoS-Objekten auf Hubs möglich.
• Die benutzten Root-Server für den DNS-Service wurden geupdated.
• Mit diesem Release unterstützen wir unsere neuen CDMA 450 MHz Module, die für den Einsatz in Nord- und Osteuropa bestimmt sind, erstmals vollständig. Die Unterstützung, die in der letzten Stable Firmware released wurde, war unvollständig. Nutzen Sie diese Firmware, wenn Sie CDMA 450 MHz-Module verwenden möchten. *)
• Die Unterstützung für LTE-Monitoring wurde entscheidend verbessert, wie auch die Unterstützung für mehrere LTE-Module in einem einzigen Router. Wenn Sie LTE benutzen, upgraden Sie bitte auf dieses Release. *)
• Hubs 1020 und 2020 werden nun vollständig unterstützt. Dieses Firmware-Release wird benötigt, um 1020/2020 zu betreiben.*)
• Die CPU Load wird nun durch das Web-Interface und SNMP überwacht und gemeldet. *)
• Es gab einige Fehlerbehebungen bezüglich Ethernet Autonegotiation. Auto Neg funktioniert nun für den 500er LAN-Port und die Gigabit Ethernet-Module. *)
• Bis jetzt führte das völlige Ausnutzen des Up- und Downstreams eines Channels zur selben Zeit zur Überlastung des Channels und zu hohen Latenzen, da der Downstream auf dem Upstream ACK Traffic verursachte zur Tunnel-Channel-Verbindung und anders rum. Das wurde verbessert. *)
• Das Ändern von QoS-Klassen, die gerade benutzt wurden (z.B. durch Ausführen von „Copy QoS templates to here“ auf einem laufenden Tunnel) konnte den Router zum Absturz bringen oder ihn einfrieren. Das passiert nun nicht mehr. *)
• Es war möglich, durch das Löschen der Standard-QoS-Klasse Internal Errors oder Abstürze zu verursachen. Das wurde behoben. Im schlimmsten Fall, bei dem die Standard-QoS-Klasse nicht mehr existiert, wird stattdessen die erste verfügbare Klasse genutzt. *)
• Es gibt nun eine „Reconnect“-Funktion für Tunnels. *)
• Wenn ein Tunnel von einem Node zu einem anderen verschoben wurde, konnte es passieren, dass der Hub den Fehler „A channel of this tunnel is already connected to a different VPN Node“ meldete, obwohl kein Channel des alten Nodes mehr verbunden war. Das wurde behoben. *)
• Wenn ein LTE-Modul idle war (Modul verbunden, aber kein Tunnel-Channel vorhanden), konnte es passieren, dass es erst inaktiv wurde, dann die Verbindung abbrach und sich wieder verband. Diese Schleife konnte ewig weitergehen. Nun ist dieses Problem behoben, LTE-Module beenden keine Verbindung aufgrund Inaktivität. *)
• Wenn Tunnel-Segmentation auf einem Hub genutzt wurde, konnten TCP-Verbindungen, die zwischen einem Tunnel auf Seg 0 zu einem anderen Segmenttunnel aufgebaut wurden, nach 30 Sekunden abbrechen, wenn sie inaktiv waren. Dadurch konnten inaktive SSH-Verbindungen zwischen diesen Segmenten einfrieren.

*) Diese Verbesserungen waren bereits mit der „Cutting Edge“-Firmware aus April 2013 verfügbar.

• Der gefürchtete Internal Error-Code 513791371A2237AE sollte behoben sein – es war ein Fehler im Heuristic Autotuning.
• Auf dem Hub gab es einen kritischen Wettlauf: Wenn zwei Nodes exakt zur selben Zeit Channels zum Hub verbanden, konnte der Hub in einen inkonsistenten Zustand gelangen, bei dem ein Channel von Node A verbunden wurde, aber der Tunnel des Hubs dachte, er wäre mit Node B verbunden. Deswegen konnte Node A keine weiteren Channel verbinden. Diese Situation konnte in größeren Stacks vorkommen, wenn Router rebooteten oder einen Powercycle brauchten und daher kurzzeitig zwei Master existieren und auf den Hub verbanden. Diese Split Brain-Situation wurde nun entdeckt und gelöst.
• Die CLI zum Zuweisen von Eigenschaften prüfte nur, ob der Benutzer die Erlaubnis hatte, eine Eigenschaft zu ändern, aber nicht, ob die Eigenschaft änderbar oder nur read-only war. Read-only Eigenschaften zu ändern führte zu allerlei seltsamen Problemen. Es ist nun nicht mehr möglich, Read-only Eigenschaften zu ändern.
• Kein Tool im alten und neuen Web-Interface benötigte Write-Erlaubnis des Benutzers für Änderungen. Nun brauchen dies alle Tools.
• Das Download Test-Tool (nur altes Web-Interface) wurde verbessert, sodass es weit weniger CPU benötigt. Daher gibt es nun keine „Download test aborted due to too high CPU load“-Meldungen mehr.
• Wenn ein deaktivierter Lüfter wieder aktiviert wurde, konnte es passieren, dass der Lüfter nicht startete, da der Lüfter-Speed zu niedrig eingestellt war.
• Während Router-Neustarts wird nun die CPU Load nicht länger überwacht und gemeldet, um nervige Warnungen loszuwerden, wenn es nichts gibt, wovor gewarnt werden sollte.
• Einige Produktionsläufe des Routermodells 300 haben das Problem, dass der Resetknopf nicht immer schnell funktioniert. Das ist nun behoben; den Resetknopf kurz drücken resettet das System sogar auf diesen Geräten.
• In den Modul-Einstellungen in der CLI und dem neuen Web-Interface konnten unzulässige Konfigurationstypen ausgewählt werden. Das ist nun nicht mehr möglich.
• „Expected Internet link capacity“ funktionierte für einige LTE-Carrier nicht, dadurch entstanden Internal Errors und negative Autotuning Speed Resultate. Das ist nun behoben.

• Volle Unterstützung für IPv6 Support für LAN Interfaces und VPN-Tunnel
• WWAN Image Manager und Umschalter. Auf modularen Routern lassen sich nun für WWAN/LTE-Module neue Firmware-Versionen auf diese Module installieren, um neueste Entwicklungen bei der LTE-Technologie abzudecken und für den jeweiligen Netzbetreiber zertifzierte Firmware zu verwenden. Die zugehörigen LTE-Firmwareimages werden dabei automatisch nach Bedarf aus dem Internet heruntergeladen und für weitere Modulupdates gecached.
  Auf 511/512-Routern werden stattdessen alle möglichen WWAN-Images für die integrierten Modems bereits zusammen mit der Routerfirmware ausgeliefert. Mit einem Umschalter-Tool kann hier wiederum die auf dem Modul verwendete Firmware gewechselt werden, ohne dass ein Download aus dem Internet nötig ist.
• Die CLI wurde komplett überarbeitet. Sie enthält nun auch eine große Zahl an Tools, die es bisher nur im Webinterface gab, z.B. Ping, traceroute, wan interface info etc.
• Das Webinterface nutzt nun HTTP keep-alive und Websockets. Dies ergibt eine erhebliche Verbesserung bei der Reaktionszeit und Geschwindigkeit.
• Einfache und Doppelte verteilte Vorwärtsfehlerkorrektur. Ähnlich RAID5 (Single Parity) und RAID6 (Double Parity) bei Server-Festplatten kann der Router nun automatisch durch schwankende Leistungsqualität fehlende oder beschädigte IP-Fragmente auf der Empfangsseite korrigieren und ersetzen. Der Single Parity-Modus ist ohne Extra-Lizenz verfügbar, der Double Parity Modus erfordert eine installierte Streaming Optimizations-Lizenz.
• Neue optionale adaptive Datenkompression auf QoS-Basis. Per QoS-Klasse kann nun gewählt werden, ob der Router versuchen soll, die übertragenen Daten zu komprimieren. Bei typischem Bürotraffic erreicht man damit im Schnitt 25-30% zusätzliche Bandbreite.
• Per QoS-Klasse kann nun eine "garantierte Übertragung" gewählt werden. Ist diese aktiviert, werden in dem Fall, dass ein Paket selbst per Vorwärtsfehlerkorrektur nicht wiederhergestellt werden kann, dieses automatisch intern neu übertragen. Damit wird für den Applikationstraffic garantiert, dass immer 0,0% Paketverlust herrscht.
  Dieses Feature ist ein bisschen "overengineered" - unsere Vorwärtsfehlerkorrektur ist so gut, dass dieser Modus so gut wie nie gebraucht wird. Dieses Feature braucht zudem einiges an CPU und RAM-Speicher.
  Das Feature ist daher per Default aus, da nur eine sehr begrenzte Anzahl von Applikationen einen Nutzen hieraus ziehen.
  Das Feature sollte nur für Applikationen aktiviert werden, die ein erhebliches Problem mit einem verlorenen Paket haben. Das können z.B. Video Codecs oder Videokonferenzsysteme sein.
• Große Beschleunigung bei der Ausgabe von Logmeldungen im Webinterface. Selbst wenn der Router eine sehr hohe Anzahl von Logzeilen pro Sekunde generiert, sollte der Webbrowser nun nicht mehr einfrieren.
• Der Lizenzmanager kann nun automatisch über das Internet Lizenzen prüfen. Alle auf einen Router registrierten Lizenzen werden dabei automatisch heruntergeladen und auf dem Router installiert. Sollte der Router nicht ins Internet verbinden dürfen, müssen Lizenzen weiterhin manuell eingetragen werden.
• Für 200/511/512 Router kann der integrierte WLAN AP nun auch den schnellen "AC Mode" nutzen. Zudem wurde der Verwaltungscode für den WLAN AP neu geschrieben. Je nachdem welche Standort-Region gewählt ist, werden jetzt alle für die Region zugelassenen WLAN-Channel angeboten.
• VLAN tunnel transport
  Die Idee ist:
  Innerhalb des Routingobjektes können Sie nun VLAN Aliase erstellen. Auf diese kann in den Modul- und Tunnel-Einstellungen verwiesen werden. Für jeden Tunnel können Sie eines oder mehrere dieser VLANs wählen.
  Nun wird aller vom LAN VLAN hereinkommender Traffic auf den Tunnel weitergeleitet der dieses VLAN gelistet hat. Das Paket innerhalb des Tunnels ist Tagged, d.h. auf der anderen Seite des Tunnels wird das Paket ebenfalls mit einer VLAN-ID markiert sein. Sollte das VLAN-Tag dort nicht eingetragen sein, wird das Paket verworfen. Dadurch kann der Administrator eines Nodes nicht in VLANs anderer Nutzer auf dem VPN Hub eindringen, egal was er konfiguriert.
  Die aus der Classic-Generation bekannte "Tunnel Segmentation ID" existiert weiterhin. Diese wird verwendet um Pakete zu taggen, die untagged aus dem Tunnel kommen. Dadurch kann selbst dann auf dem Hub VLN Tagging benutzt werden, wenn auf dem Node keine VLANs konfiguriert sind.
  Sollten Sie mehrere am Node vorhandene VLANs durch den Tunnel hindurch zum Hub durchbingen wollen, so erfordert das auf dem Node eine "Enterprise Node Features"-Lizenz (Ausnahme: 2610/2620 Router enthalten dieses Feature kostenlos).
• Jedes WAN-Modul hat nun ein Unterobjekt "Performance data", welches über Webinterface und CLI sowie SNMP erreichbar ist. Wenn es per SNMP abgefragt wird, wird das Objekt maximal alle 5 Sekunden aktualisiert. Damit lassen sich bequem aus der Ferne Performancedaten wie Signalstärke auslesen. Das Auslesen dieser Daten per SNMP erfordert eine "Enterprise Node Features"-Lizenz (2610/2620 haben dieses Feature wiederum kostenfrei inkludiert).
• Unterstützung für LTE450 Module
• Enabled Mobile Technologies bekommt nun automatisch passende Vorgabewerte zu den von dem jeweiligen Modul unterstützten mobilen Technologien. Als Beispiel wird bei LTE450 nur das 450 Mhz-Band aktiviert, bei dem 4G Europe/Australie-Modul wird CDMA deaktiviert.
• Die summierte aktuelle Bandbreite für alle verbundenen Tunnel wird nun in der Tunnelübersicht angezeigt. Dies ermöglicht es nun die genutzte Bandbreite des Hubs auszulesen.
• SSL-Sitzungen und Kanalautentifizierungen werden nun zwischengespeichert. Dies bewirkt das wiederverbindende Kanäle auf den Nodes nicht länger eine erhöhte CPU-Last auf dem Hub verursachen. Wir konnten somit eine erhebliche Verbesserung für jeden Nutzer von Nodes in Fahrzeugen beobachten. Auf einem Kunden VPN-Hub wurde die CPU-Last von 65% auf 2% verringert.
  Diese Verbesserung bewirkt auch, dass ein Kanal mit Beispielsweise 100ms Latenz nicht länger mehr als eine Sekunde Zeit zur Wiederverbindung des Kanals benötigt, sondern nur noch einen Bruchteil davon. Wir glauben das dies eine deutliche Verbesserung ist, die viele unserer Kunden nicht mehr missen wollen.
• Eine VLAN ID wurde zu den Routing- und QoS-Regeln hinzugefügt. Mit diesem neuen Feature können Sie nun die Routing- und QoS-Regeln entsprechend der Tunnel Segmentierung / VLAN ID steuern.

• Sollte während eines Router-Kaltstarts ein Modul, welches vorher bereits konfiguriert (und in der Konfiguration gespeichert) wurde, nicht sichtbar sein, warten wir nun bis zu 30 Sekunden, damit das Modul wieder erscheint. Das liegt daran, dass während eines schnellen Bootprozesses des Routers die betroffenen 4G Module noch nicht komplett gebootet haben, aus diesem Grund sind die Module noch nicht sichtbar, während die Konfiguration geladen und ausgeführt wird. Bei einem unvorteilhaften Timing könnte dies dazu führen, dass die Module ihre Konfiguration verlieren.
  Dies sollte alle bei Kunden aufgetretene Probleme mit verlorenen Konfigurationsdaten beheben, welche wir zuvor nie reproduzieren konnten.
• Verbesserte Sicherheit: TLS Sicherheitspatch gegen RSA CRT Attacken implementiert.
• Verbesserte Sicherheit: SSLv3 und SB_SUITE_RSA_RC4_SHA werden nicht länger für das Web-Interface verwendet (dies bedeutet, dass der IE 6 nicht mehr unterstützt wird).
• Sicherheitsverbesserung: die einzigen ICMP Pakete die noch akzeptiert werden sind: ICMP_ECHO, ICMP_ECHOREPLY, ICMP_UNREACH, ICMP_TIMXCEED, alle anderen werden gefiltert. Dies wird aufgrund eines Sicherheitsaudits eingeführt - man erhält keine TIMESTAMP Antworten eines Viprinet Routers, da diese einen potenziellen Angriffsvektor darstellen.
• Hubs überprüfen nun ihre Modellnummer während sie im Hub Replacement und Hotspare Mode sind. Im Hotspare Modus werden Lizenzen deshalb als gültig dargestellt (zuvor war diese Überprüfung nicht möglich, da das Router Modell "unbekannt" war). Es wurde ausserdem Text entfernt, welcher ausführte, dass der Lizenz-Manager im Hotspare Modus nicht genutzt werden kann, denn dies ist nun möglich.
• Ein Classic VPN Client welcher sich zum HUB verbindet, konnte Pakete senden die eine Größe von 1500 Bytes überschreiten (aufgrund fehlendes Unpaddings) dies führte zum Fehlercode 12A8922323111132 innerhalb des VPN Clients.
• Hubs werden nun Fehlermeldung in das Logfile schreiben, falls ein entfernter Router eine Fehlermeldung während der Verbindungsaushandlung des Tunnels sandte. Ausserdem wird die "Connection dropped due to command timeout" message nur dann genutzt wenn die Verbindung während einer Zeitüberschreitung geschlossen wurde.
• Manchmal wurde eine SIM Karte während einer Race Condition entsperrt, aber das Auslesen der IMSI und HomeMCC/MNC schlug fehl, da die SIM Karte noch nicht bereit war. In diesem Fall wird das Auslesen wiederholt. Jedoch war die Funktion zum Wiederauslesen des MCC fehlerhaft, so dass dies nie funktionierte. Dies ist der Grund, warum APN Autodetection seit einigen Firmware Versionen mit einigen unserer LTE Module fehlschlug.
• Wurde der Trafficcounter eines Interfaces mehrfach resettet, hatte dieser anschließend falsche Werte.
• Falls ein WAN Module öfters neu verbunden hat oder keine IP-Addresse erhielt, konnte der genutzte Channel Internal Error Fehlermeldungen verursachen und der Router neustarten.
• Manchmal, wenn man einen Router neustartete oder wenn man von Slave auf Master Mode umschaltete, war es möglich dass einige LAN Dienste nicht funktionierten.
• Ein Modulreset (manuell oder automatisch) blockierte den Haupttimer des Routers bis zu zwei Sekunden. Dies verursachte unter Umständen einen Verbindungsabbruch der übrigen Channels.
• Ein 511/512, der durchgehend ein Modul neustartet, konnte nach einer Weile keine File Descriptors mehr zur Verfügung haben und deshalb in einem unnutzbaren Zustand enden. Dies sollte nun behoben sein.
• Fix für VDSL RFC 1483 statische IP (ein Modem-Fix ist hierfür auch notwendig)
• Die maximale Anzahl an Verbindungen für Hotspare Konfigurationsübertragungen war undefiniert (wurde niemals gesetzt) und deshalb war diese Anzahl je nach Build zufällig definiert. Aufgrund dieses Zustandes hat dieses Feature auf einigen Firmware Builds nicht funktioniert, während auf anderen Builds die Hubs einwandfrei die Konfiguration übertragen konnten.
• Mehrere Crash-Bugs im Stacking-System wurden behoben.
• Bei hoher Speicherauslastung konnten einige Skripte nicht mehr ausgeführt werden. Dies verursachte verschiede Fehler, z.B. bei der Einwahl. Wenn dies geschah konnte der Router noch nicht einmal rebootet werden.
• Das Hinzufügen einer IPv6-Adresse als primäre LAN IP Adresse führte zu einer Reboot-Schleife. Dies ist nun nicht mehr möglich, IPv6 Adressen können nur als LAN Alias verwendet werden - verschiedene Teile der Software vertrauen auf eine IPv4-Adresse als primäre IP auf dem LAN Interface.
• Zeitsynchronisation mittels NTP funktioniert nun auch auf Hotspare Hubs.
• Die Art wie sich LTE Modems eingewählt haben, hat sich für folgende Module geändert - 4G Europe/Australia, 4G Europe II und 4G Americas. Dies löst Probleme die Module mit der 05.05.58 Firmware hatten und sich nicht mehr zu AT&T und T-Mobile in den USA verbinden konnten.
• Bei manchem Netzanbietern haben die neuen 4G Europe II Module den Netzwerkname in 7bit Kodierung gemeldet, was in falschen Netzwerknamen resultierte.
• 4G Europe II Module haben falsche "Expected Link Capacity"-Werte ermittelt, zudem haben alle 4G Module manchmal EV-DO statt UMTS erkannt, was ebenfalls in falschen Kapazitätswerten resultierte. Falsche Kapazitätswerte wiederum sorgten dafür dass Channels nicht die tatsächlich maximale mögliche Kapazität der Verbindung nutzten.
• Durch ein Timingproblem schlug das Auslesen der IMSI oder Home MCC/MNC von der SIM nach der SIM Entsperrung fehl. Dies kann dazu führen, das die APN Autokonfiguration fehlschlägt. Diese Daten werden nun später ausgelesen.
• Der Neustart eines Routers sollte nun nicht mehr fehlschlagen, auch bei wenig verfügbaren Speicher.

• In den Enabled Mobile Technology lassen sich nun präferierte LTE-Bänder konfigurieren.
• Funkzellenwechsel werden nun aufgezeichnet und gelogged. Es gibt nun auch eine Funktion um manuell alle LTE-Bänder abzuscannen. Und schließlich gibt es ein optionales Feature, dass nach zwei Funkzellenwechseln bei denen nur UMTS empfangen wurde automatisch versucht wird, auf LTE zurückzukehren, und dabei die präferierten Bänder zu nutzen. Das ist sehr nützlich für Fahrzeuganwendungen, bei denen durch Bereiche mit schlechtem Empfang gefahren wird. Ohne dieses Feature würde das LTE-Modul nach dem Wechsel hinunter auf UMTS dort verharren, da ein Wiederhochwechseln zu LTE die Channelverbindung trennen würde. Mit diesem neuen Feature wird in diesem Fall zunächst der Channel kurz disconnected, LTE gescanned, und dann der Channel wieder neu aufgebaut.
• Das Google maps tool mach nun live automatische Updates, wenn der Router (bzw das Fahrzeug in dem sicher Router befindet) bewegt.
• Es gibt nun bessere QoS default templates, die auch viele möglicherweise durch den Viprinet-Tunnel betriebene VPN-Protokolle erkennt, z.B. IPSec. Benutzen Sie die "Restore Manufacturing defaults" Funktion um diese neuen QoS-Templates zu erhalten. Sollten Sie den Router in einem Fahrzeug nutzen, sollten Sie zusätzlich die Forward Error Correction (FEC) für alle QoS-Klassen aktivieren.
• SNMP: Die Mobilfunk-CellID sowie Module-Perfomancedaten werden nun übermittelt. Zuvor wurde für vpnRouterInterfaceIndex in der VIPRINET-MIB immer 0 berichtet, das wurde nun korrigiert.

• Die Hinweise auf bald ablaufende VLM Lizenzen erscheinen jetzt nur noch, wenn die Lizenz in weniger als 7 Tagen abzulaufen droht.
• Alle Firmware-bezogenen Warnungen wurden aktualisiert. Für unlizensierte Firmware (kein VLM installiert) gibt es nun sehr explizite Warnungen.
• 310/2030/2620 Router haben beim System-Neustart das Viprinet-Logo nicht ausgeschaltet.
• Demorouter dürfen nun für jeweils bis zu 90 Tage am Stück genutzt werden, die Warnungen im Log wurden entsprechend angepasst.
• In den SNMP Settings werden nun auch die Modelle 2620 und 2030 erwähnt.
• Für den Hub 5000 wurden fehlende Lizenztypen hinzugefügt. Zurvor wurden VLM Lizenzen beim Hub 5000 ignoriert.
• Die Art wie Listenobjekte (z.B. Tunnel) intern gelöscht wurden wurde geändert. Zuvor konnte es passieren, dass abhängig von der Reihenfolge in der der Benutzer diese markierte, manche Einträge nicht gelöscht wurden.
• Die Lademaske im Webinterface wird nicht mehr angezeigt, wenn der Router weniger als 500ms vom Browser-Benutzer "entfernt" ist. Wenn man lokal zu einem Router verbindet fühlt sich das Webinterface dadurch noch flotter an.
• Objekteditoren im Webinterface werden nun automatisch aktualisiert, wenn sich das Objekt verändert (z.B. die Bandbreite eines Tunnels). Wird ein Objekt gerade editiert, wird das Objekt aber nicht mehr neu geladen, um das aktuelle Editieren nicht zu stören.
• Listeneinträge hoch- oder runterzubewegen war bisher extrem mühsam und erforderte Teils ein Neuladen der Seite. Dieses verschieben funktioniert nun sauber wie erwartet, und der Objektbaum auf der linken Seite aktualisiert sich ebenfalls passend automatisch.
• Wenn sich ein Objektname ändert (z.B. wenn sich ein WAN-Modul umbenennt) wird der Objektbaum nun korrekt aktualisiert.
• Diese Firmware behebt zwei seltene aber bedeutende Fehler die dafür sorgen konnten dass der Routingkern bis zu 30 Sekunden einfriert, was wiederum alle Tunnel zu einem Hub zum disconnecten bringen würde.
• Die Meldung "Slot 6 - 4G Americas for AT&T USA contains illegal characters." wurde korrigiert.
• Gelegentlich (vor allem mit Stacking) konnte es passieren, dass der DHCP-Dienst beim Routerstart nicht mitstartete.
• Latency Autotuning wurde so geändert, dass keine Werte über 1000ms mehr ermittelt werden. Sollten Sie Satellitenverbindungen mit höheren Latenzen nutzen, sollten Sie Latency Autotuning ohnehin deaktivieren.
• Wenn Sie FEC im Webinterface für eine QoS-Klasse aktivieren, wird die "Preferred number of channels" automatisch auf einen sinnvollen Startwert 3 gesetzt. Dieser Wert sollte dann nach Bedarf angepasst werden (z.B. wenn lieber die besten 4 von 6 Channeln genutzt werden sollen).
• Für WWAN-Module wurde auf Grund von Bugs im Qualcomm-Chipsatz beim ersten Verbinden zu einem Mobilfunknetz häufig kein Providername ermittelt. Dies wiederum konnte unser Signal Monitoring Tool verwirren. In diesen Fällen wird der Netzwerkname stattdessen nun durch eine Routerinterne Providernamendatenbank ermittelt.
• Das Monitor Tool hat bisher bei WWAN-Modulen meist jeden Slot zwei Mal angezeigt - einmal als "Slot 1 - WWAN (3G/4G) und dann kurz darauf mit dem finalen Modulnamen. Dies wurde korrigiert, der "Slot 1 - WWAN (3G/4G)" Eintrag wird nicht mehr an das Monitor Tool übermittelt.
• Die Logik dass bei doppelten Einträgen in der Liste von "First/Second/Third Bonding Priority" diese aussortiert werden hat nicht funktioniert. Die Logik wurde entfernt, es liegt jetzt in der Benutzerverantwortung logisch sinnvolle Einträge zu erzeugen.
• Es wurden mehrere Bugs behoben, die dafür sorgen konnten dass WAN-Module nach dem stromlosschalten des Routers ihre Konfiguration vergessen konnten.
• Wenn man in einer QoS-Klasse die QoS Templates angewendet hat, wurden die meisten QoS-Eigenschaften überhaupt nicht kopiert.
• Das Webinterface und die CLI wurden unerreichbar wenn man eine leere Routingregel angelegt hatte, die auf einen Tunnel zeigt.
• Der Programmcode der Pakete vom LAN-Interface gelesen hat hatte mehrere Fehler: Ethernet-Typen außer IP/IPv6/ARP wurden trotzdem zum Teil wie IP behandelt, bevor diese Pakete verworfen wurden. Dies konnte die Internal errors CA23AA32932FFFF1 und BACEE2923EEEEEEB auslösen.
• Für VLAN-Tagged Traffic wurden für den Rotuer wichtige Multicast-Pakete verworfen.
• Mehrere Bugs bei der Verarbeitung von IPv6-Paketen wurden behoben. Bisher konnte es passieren, dass bei IPv6-Paketen übergroße Ethernet-Frames versendet wurden, die ggf. dann im Netz verworfen worden wären.
• Wenn die VLAN-Id vom LAN gelesen wird wurden IEEE 802.1Q / IEEE 802.1p Markierungen bisher nicht herausgefiltert, dies resultierte in falschen VLAN Id Nummern.
• Nachdem ein Paket vom LAN gelesen wird, werden nun zunächst einige weitere Plausibilitätschecks gemacht, bevor das Paket weiter verarbeitet wird. Ohne diese Checks war es bisher möglich einen Internal Error auszulösen, in dem man einen ungültigenTCP Header mit der Größenangabe 0 an den Router geschickt hat.
• Die Demorouter beginnend mit dem Produktcode 55-... haben sich darüber beschwert, keine VLM-Lizenz zu haben, die sie überhaupt nicht benötigen.
• Der Channel Verbindungsfehler nach Systemstart, der auftrat wenn "SSL/Channel Session Caching" aktiviert war wurde behoben. Es ist nun sicher diese Option für Channel zu aktivieren. Für Hubs und Nodes bei denen die Channel häufig neuverbinden, z.B. bei Nutzung von LTE oder instabilen Leitungen, wird dies sowohl die Geschwindigkeit erhöhen als auch die CPU-Last dramatisch senken.
• Einige vergessene Debug-Logmeldungen wurden entfernt

• Es können nun angepasste LTE WWAN-Profile angelegt werden, wie sie von einigen Carriern benötigt werden (z.B. für private APNs). Bitte beachten Sie, dass die Profil-Voreinstellungen sich geändert haben. Bitte überprüfen Sie die Kompatibilität mit Ihrem LTE-Anbieter, bevor Sie diese Firmware im großen Stil ausrollen.
• Hubs im Hotspare-Modus verfügen nun über funktionierende ACLs (und haben intern nun unseren vollen Routing-Stack laufen, was zuvor nicht der Fall war). Dies ermöglicht endlich, die Service-ACLs auch in diesem Modus zu nutzen. Dies ist deshalb wichtig, da ohne ACLs der DNS-Service von Hubs im Hotspare-Modus offen im Internet erreichbar ist, und für DNS Amplification-Attacks missbraucht werden kann. Bitte verifizieren Sie daher nach dem Firmware-Update unbedingt, dass Sie eine entsprechende ACL angelegt haben, die den DNS-Dienst abschottet.
• Die CPU-Last für Tunnel-Channel auf Nodes wurde verringert. Dies kann zu leicht erhöhter Bündelungskapazität führen, wenn viele Channels benutzt werden (z.B. beim Stacking).
• Die CPU-Last auf Hubs und Nodes, die eine sehr hohe Anzahl von neuen Verbindungen/Flows durch den Tunnel erhalten (z.B. bei einem eingehenden Portscan oder einer DoS-Attacke), wurde drastisch reduziert.
• Die Latenz des Routingkerns ist nun so niedrig wie nie zuvor. Der Router lässt sich nun mit einer Antwortzeit von <3ms anpingen.
• Der LAN-Durchsatz wurde erhöht, die CPU-Last durch LAN-Traffic reduziert.
• Die LTE-TDD Bänder B38 and B40 bei Nutzung des 4G Europe/Australia/Africa moduls sind nun getestet und funktionieren. Das Modul hat nun auch ein funktionierendes AT Command Tool, und ist insgesamt bereit für die Nutzung in Produktion.

• Zahlreiche Fehler beim WLAN Client-Modul behoben, wodurch die Kompatibilität verbessert und nun auch die Verbindung zu unverschlüsselten Access Points erlaubt wird.
• QoS Bündelungsprioritäten wurden nicht kopiert, wenn man QoS aus Vorlagen wiederherstellte oder dorthin speicherte.
• Beim Stacking von Slaves konnte ein 24h-Disconnect oder das Neuzuweisen einer IP durch den Provider, während man verbunden war, den Router dazu bringen, konstant 99% CPU zu verbrauchen.
• Hubs im Replacement-Modus warnten manchmal davor, dass auf ihnen VLM nicht installiert sei. Das wurde behoben.
• Die Heartbeat-Diagnose ("A single router is gone from the network") wird nun nur noch einmal pro Sekunde ausgegeben.
• Log-Nachrichten verloren Speicher, wenn das Web-Interface ohne aktivierte Websockets genutzt wurde. Das wurde zu einer wesentlichen Menge an Speicher, wenn das Web-Interface eine sehr lange Zeit geöffnet war und der Router eine große Anzahl Log-Zeilen produzierte (sehr ausgelastete Hubs).
• Ein Speicherleck wurde behoben, das auftrat, wenn der Router IPv6 Broadcast-Verkehr verwarf, welchen er vom LAN erhielt.
• Ein kleines Speicherleck im Konfigurationssystem wurde behoben. Bei gestackten Nodes mit sehr vielen Konfigurations-Synchronisationen (z.B. weil sehr instabile Channels genutzt werden) konnten diese Lecks über längere Zeit erhebliche Ausmaße annehmen.
• Der RAM-Verbrauch von Hubs die eine sehr hohe Zahl (50000+) von gleichzeitigen Flows (Verbindungen durch das VPN) sahen, wurde deutlich reduziert.
• Der interne Packet-Slicer, welcher dafür zuständig ist, dass Pakete in Fragmente zerschnitten und dann über mehrere Channels geschickt werden, konnte unter Umständen (hohe Nummer von Channeln, instabile Channels und/oder FEC angeschaltet) eine erhebliche Menge von Speicher lecken.
• Die LAN NIC der Router kann nicht länger hängenbleiben, im schlimmsten Falle bringt ein LAN-Reset das Interface wieder zurück ins Leben.
• Ein WLAN Client-Modul konnte dafür sorgen, dass der Router 100% CPU verbrauchte.
• Der voreingestellte Autotuning Modus für neu angelegte Channels ist nun "Hybrid" statt "Heuristic", was typischerweise die bessere Wahl ist.

• Diese Firmware bietet keine neuen Funktionen.

• Seit geraumer Zeit wurden Channel disconnects nicht sauber ausgeführt. Dies könnte zu Abstürzen führen. In weniger schlimmen Fällen traten nur SSL-Fehler auf, oder es dauerte 5 Sekunden bis der Channel abgebaut war, statt direkt sauber getrennt zu werden.
• Auf einigen Produkten (310, 2620, 2030, 5000, 5010) konnte die Hardwareverschlüsselungsengine während Channel disconnects für einen Absturz sorgen. Wir vermuten dass dieser Fehler der Grund ist, wieso Kunden mit Routern, welche unter großem Stress stehen (Satellitenverbindungen, Schiffe, Fahrzeuge mit häufigen Verbindungsneuaufbau), häufige Reboots sehen, während andere Kunden gar nicht betroffen sind.
• Module, die im Stacking-Verbund als Slave genutzt werden konnten nicht verbinden, wenn die errechnete MTU kleiner als 1500 war. Das führte dazu dass 500er Router nicht als Stacking Slave verwendet werden konnte (das für UMTS verwendete PPP-Protokoll verlangt nach MTUs kleiner 1500).
• Das automatische Kontaktieren des Lizenzservers funktioniert jetzt - zuvor musste man Lizenzen manuell neu abrufen lassen.
• Bei LTE-Modulen findet, anders in vorherigen Firmwareversionen, die Einwahl nicht mehr direkt statt, sondern wird intern ausgelöst durch eine Änderung des LTE-Profils. Wir hatten dies zuvor geändert, da es Kunden gab, die mit der Nutzung von privaten APN Profilen Probleme hatten. Das neue Verfahren hat nun aber Probleme mit einigen Providern in manchen Ländern ergeben. Das Einwahlverfahren wurde daher zurückgeändert, damit die LTE-Profile der jeweiligen Provider genutzt werden. Kunden mit privaten APNs können daher nun wieder Probleme haben. Diese können das neue "Custom WWAN Profile"-Feature nutzen, um das Problem zu umgehen.
• Spezielle Demo- und Projektrouter waren nicht in der Lage, Stacking Slave Channels zu nutzen. Das wurde korrigiert. Betroffene Kunden müssen das WAN-Modul betroffener Channel neu auswählen, nachdem diese Firmware installiert wurde.
• Die Popup-Meldungen bei Demo-Routers, in denen darauf hingewiesen wird dass eine Produktvorführung nur 14 Tage dauern darf, wurde angepasst und teilt nur korrekterweise mit, dass dafür 90 Tage zur Verfügung stehen.
• Die Art wie intern Statistiken über die Quell- und Zielhosts von Traffic-Flows gehandhabt werden wurde überarbeitet. Zuvor konnte man mit DDoS-Attacken mit gefälschten Quell-IP-Adressen das gesamte RAM des Routers aufbrauchen. Derartige Angriffe machen Viprinet-Routern nun nichts mehr aus. Zudem hat sich durch die Änderungen die Perfomanz bei Nutzung mit einer sehr hohen Zahl (1000+) von Geräten im LAN merklich verbessert.
• Bei bestimmten Arten von DoS-Angriffen konnte der Routingkern festhängen, was nach 90 Sekunden einen Neustart des Routers auslöste.
• Im Falle dass ein DDoS-Angriff vom Router erkannt wird, wird nun ein Hinweis im Log ausgegeben.
• Ein Fehler in der Speicherverwaltung bei IP-Paketen wurde korrigiert. Der Fehler konnte ein kleines Speicherleck auslösen, was im Laufe der Wochen zu eine erheblichen Größe anwachsen konnte. Der Fehler konnte zudem unter sehr speziellen Bedingungen auch zum Absturz des Routers führen.
• Das setzen einer IPv6-Adresse als Haupt-IP des LAN-Interface (anstatt die V6-Adresse als Alias hinzuzufügen) war zuvor nicht zulässig, konnte aber dennoch durchgeführt werden. Damit wurde der Router aus dem LAN-Netzwerk unerreichbar. Der Router verhindert nun, dass man auf irgendeinem Weg eine v6-Adresse als Haupt-IP angibt.
• Der Neuübertragungsmanager für QoS-Klassen mit aktivierter "Guaranteed delivery" hatte einen Speicherleck, konnte aber unter Umständen auch bewirken, dass die Hälfte aller Neuübertragungeng gar nicht stattfanden. Das bedeutete, dass ein Flow durch den Tunnel trotz garantierter Übertragung doch Paketverluste erleidigen konnte. Das konnte dramatische Konsequenzen haben: Die TCP/IP Headerkompression baut auf die garantierte Übertragung auf, es dürfen nie Pakete fehlen - geschah dies doch, wäre der entsprechende Flow steckengeblieben.
• Die Logausgabe von TCP-Sequenznummern wurde korrigiert. Zudem wurde der Loglevel für sehr häufige TCP-Protokollverstöße, welche von kaputten IP-Scannern ausgelöst werden, nicht länger als Angriff protokolliert.
• Es wird nun sichergestellt dass serverseitig hängende HTTP-Verbindungen bei Nutzung der Download-Testtools des Webinterfaces sauber abgebaut werden. Der zuvor vorhandene Bug konnte für 99% CPU-Last sorgen, wenn ein Download serverseitig hängenblieb.
• Der Routingkern konnte unter außergewöhnlichen Umständen unregelmäßig auf der Empfangsseite von Flows hängenbleiben. Der Fehler trat bei Kunden teilweise über Wochen und Monate nicht auf, um dann plötzlich für einen Tag ständig aufzutreten.
• Einzelne Flows mit aktivierter "Guaranteed Delivery" konnten bei einem Neuverbinden des VPN-Tunnels steckenbleiben, wenn sie zu diesem Zeitpunkt eine hohe Übertragungsrate aufwiesen. Hängengebliebene Flows haben in diesem Falle das RAM gefüllt, bis dem Router ggf der Speicher ausging.
• Die empfangsseitigen Timeouts für Flows ohne "Guaranteed Delivery" sorgen dafür, dass beim Neusortieren der empfangenen Paketfragmente nur so lange auf fehlende Teile gewartet wird, wie die Bündelungslatenz erwarten lassen sollte. Verstreicht diese Zeit, sollte das entsprechende Paket verworfen werden (aus Sicht des Zielsystems handelt es sich dann um einen Paketverlist). Die Filter, um die richtige maximale Wartezeit zu ermitteln, waren bisher nicht ausgereift. Insbesondere bei Bündelung von Leitungen mit sehr hoher oder schwankender Latenz (z.B. Satellit) konnten die Timeout-Werte ungünstig sein. Dies konnte dazu führen dass aufgrund von scheinbar verlorenen Paketen auf Empfangsseite ein Nutzer z.B. bei einem Download nicht die volle Bandbreite ausnutzen konnte, die der VPN-Tunnel eigentlich zur Verfügung stellt. Die Filter wurden nun komplett neu geschrieben und ausführlich getestet.
• Die Meldungen "Average latency is ... ms, maximum allowed is ... ms, no alternatives,  keeping channel." wurden komplett entfernt, wie auch die zugrundeliegende Idee: Es macht keinen Sinn einen Channel kramphaft als verbunden zu forcieren, wenn die Latenz über der liegt, die vom Benutzer als maximal angebenen ist. Es ist sinnvoller in diesem Fall die Verbindung des Channels zu trennen, und die Pufferung auflaufender Pakete stattdessen auf der Tunnelebene durchzuführen.