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

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

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

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

• 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.
• 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 derselben Cutting Edge-Firmware laufen, immer noch produktive Hubs bedienen können, die mit der 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 konnte, 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.

• Die vorherige Cutting Edge Firmware-Version funktionierte nicht mit der 50-00500 Projektrouter-Serie. Das Problem wurde mit dieser Firmware-Version behoben.
• Ein Fehler wurde behoben, der durch einen SSL Handshake-Feler unter seltenen Umständen den Aufbau eines Tunnel-Channels zum VPN Hub abbrechen lassen konnte.

• 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).
• Dieses Release enthält zum ersten Mal Firmware-Builds für die kommenden Multichannel VPN Router-Modelle 511 und 512.
• Im neuen Web-Interface gibt es nun die Tools "Module info", "Interface info" und "ARP table". Trotzdem fehlen noch viele der Tools aus dem alten Web-Interface, z.B. Ping, Traceroute und der Download-Test. Diese werden beim nächsten Release hinzugefügt.

• Das vorherige Cutting-Edge-Release unterstützte CDMA450-Module nicht, die entsprechenden Slots wurden als leer angezeigt. In diesem Release wurde der Support für diese Module wieder hinzugefügt.
• 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.
• Die Testlizenz-Funktion, die in früheren Cutting-Edge-Firmware-Versionen eingeführt wurde, war fehlerhaft: Damit generierte Testlizenzen wurden nie ungültig.

• 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üsselaustausch 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.
• Bei multiplen Authentifizierungsfehlern auf der SSH-CLI werden weitere Login-Versuche von derselben IP nun gedrosselt. Dies erschwert Brute-Force-Attacken auf SSH enorm.
• 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.

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

• Der neue Multichannel VPN Router 200 wird nun unterstützt (dieser wird erstmals auf der CeBIT 2014 zu sehen sein).
• 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.
  Das konnte man in der Realität beobachten, wenn man einen Hub rebootete, der aufgrund vieler Tunnel schwer belastet war, z.B. nach einem Firmware-Upgrade.
  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 ist die neue Cutting-Edge-Version in der Lage, eine höhere Channel-Verbindungslast auf dem Hub zu verarbeiten, als die aktuelle Stable-Firmware (deren SSL-Handshake noch dazu weniger sicher ist).
• 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).
• VDSL-Module erlauben nun das Aufsetzen eines VLAN.
• VDSL-Module unterstützen nun RFC1483 mit statischen IPs, und erlauben Sonderzeichen in PPP-Benutzernamen und Passwörtern.

• Wenn man bei der vorherigen Cutting-Edge Firmware-Version mehrere Channel mithilfe der Multiedit-Funktion im neuen Web-Interface bearbeitet hat, benutzten nach dem Speichern der Änderungen alle Channels ein einziges (das erste) Modul. Nach dem nächsten Channel-Reconnect benutzte aber jeder Channel dasselbe Modul, weswegen es passieren konnte, dass die Performance erst Stunden nach den Änderungen abstürzte. Dieser Fehler wurde beseitigt.
• Die Multichannel VPN Router 511, 512 und 513 zeigen nun den korrekten Produktnamen im Web-Interface an.

• 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 und Router tauschen nun „Boot IDs“ aus, sodass die jeweils andere Seite informiert wird, ob die Gegenstelle neugestartet hat, und entsprechend den Flow State leeren kann.
• Erweiterte Einstellungen für VDSL sind jetzt verfügbar.
• Viprinet Managed SIMs werden nun unterstützt.
• Wartungsverträge werden nun von der Firmware unterstützt.
• Neue Einstellung zum Feinkonfigurieren von Channels „RapidReconnects“: Wenn aktiviert, zeigen Channels ein sehr aggressives Reconnect-Verhalten, dass beinhaltet, das WAN-Modul neu zu starten, wenn ein Channel für längere Zeit stillsteht. Schalten Sie diese Option nur ein, wenn der Router in einem Hochgeschwindigkeitsfahrzeug zum Einsatz kommt, das sich typischerweise bei 100km/h und schneller bewegt.
• Wenn ein Konfigurations-Backup wiederhergestellt wird, gibt es nun die Option „Do not overwrite existing licenses“. Wenn aktiviert, bleiben Lizenzen, die vor dem Backup an den Router gebunden wurden, intakt.
• Neue Funktion „Clear dynamic leases“ innerhalb der DHCP-Server-Einstellungen.

• Wenn Latency Autotuning für eine Channel ausgeschaltet ist, wird der Channel keinen Pingtest mehr durchführen, wenn er von ConnectedStalled auf Connected wechselt. Auf diese Weise kann der Channel nach einem kurzen Stillstand sehr viel schneller wieder genutzt werden (z.B. wenn ein Fahrzeug durch einen Autobahntunnel fährt).
• In sehr seltenen Fällen (Hochgeschwindigkeitszüge) konnten LTE-Module so abstürzen, dass der Router sie immer noch für verbunden hielt – im Zweifelsfall für immer. Ein neuer Wächter-Code stellt nun sicher, dass solche „eingefrorenen“ Module automatisch powercycled werden.
• LTE-Module geben nun Cell-IDs korrekt wieder (vorher zeigten sie typischerweise „0“ als Cell-ID).
• Die Empfängerseite eines BondingDiversity Flow hatte ein ernstes Speicherleck, welches nach einiger Zeit verursachte, dass dem Gerät der Hauptspeicher ausging.
• Wenn die Stromversorgung auf 5XX-Routern während eines bestimmten Moments beim Hochfahren unterbrochen wurde, konnte der Firmware-Speicher beschädigt werden, was dazu führen konnte, dass der Router nicht mehr in der Lage war, hochzufahren. Dies wurde in solchen Installationen beobachtet, bei denen der 5XX-Router in einem Auto verwendet wurde, das oft für nur für ein paar Sekunden angelassen und dann wieder abgestellt wurde.
• Die SSH-CLI lauscht nicht mehr auf WAN-Interfaces, da diese nicht durch eine ACL kontrolliert werden können.
• Einige Objekte im Web-Interface von früheren Firmware-Versionen ignorierten Löschversuche, z.B. Lizenzen und gestackte Router. Nun können diese Objekte erfolgreich gelöscht werden.
• Die Zeitzonenverwaltung bei 5XX-Routern war bei allen früheren Firmware-Versionen fehlerhaft. Dadurch waren Berichte für den Traffic-Bericht-Server mit falschen Zeitstempeln versehen, und Webbrowser nahmen auch keinerlei Elemente aus dem Web-Interface in den Cachespeicher auf.
• Die QoS-Klassen-Einstellung „Required Link Stability“ wurde aufgrund eines Fehlers in allen Firmware-Versionen im letzten Jahr größtenteils ignoriert. Deswegen konnte ein instabiler Channel den Traffic-Durchsatz des Tunnels ruinieren, auch wenn der instabile Channel eigentlich nicht genutzt hätte werden dürfen. Diese Fehlerbehebung bringt daher eine deutliche Durchsatzverbesserung für Setups, in denen instabile Links gebündelt werden (z.B. in Fahrzeugen).
• CDMA450-Module konnten abstürzen, wenn man sie in einem 5XX-Router resettete. Die  Reset-Option für diese Module wird daher nun ignoriert.
• Die diversen Formen von Download-Tools im Web-Interface hatten Probleme auf 5XX-Routern. Dort konnten diese Tools steckenbleiben oder abbrechen.
• Die Benutzerrechteverwaltung für WAN-Module war nicht persistent, entsprechende Einstellungen gingen beim Routerneustart verloren. Im neuen Web-Interface konnten Userrechte-Einstellungen für WAN-Module überhaupt nicht vorgenommen werden. Dies funktioniert nun, man kann nun auch Nicht-Root-Usern Rechte für WAN-Module zuweisen.
• Das Download Test Tool brach den Download nicht ab, wenn das entsprechende Fenster im neuen Web-Interface geschlossen wurde, stattdessen lief der Download im Hintergrund weiter. Das verursachte ggf. unnötigen Datentraffic.

• Leider beinhaltete die Cutting Edge Firmware-Version von Juli einen Compiler-Fehler für die Router-Serien 200, 500 und 51X. Dieser Fehler kann subtiles und schwer zu entdeckendes eigenartiges Verhalten verursachen. Aber schlimmer noch, wenn Hosts viele Traffic-Flows durchführen, kann es passieren, dass diese Traffic-Flows auf dem Router früher oder später stecken bleiben – der Router bezichtigt dann fälschlicherweise den Host einer DoS-Attacke und erlaubt von diesem keine neuen Flows mehr.
  Dieser Fehler bewirkt faktisch, dass einige oder alle Ihrer Hosts im LAN nach einiger Betriebszeit nicht mehr mit dem Router oder dem VPN/Internet sprechen können!
  Wir raten daher all unseren Kunden, die auf Routern aus den Serien 200, 500 und 51X die Cutting Edge Firmware-Version von Juli installiert haben, DRINGEND, auf die aktuelle Version zu updaten! Kein anderes Produkt ist von diesem Fehler betroffen. Wir entschuldigen uns für Ihre Unannehmlichkeiten und haben unsere internen Test-Setups entsprechend umgebaut, um ähnliche Fehler in Zukunft rechtzeitig entdecken zu können.
   
• Neue Option zur Feinkonfiguration von Channels „Save traffic when idle“: Diese wird für Vodafone UK benötigt, damit stagnierende Channels nicht aus der UMTS-Funkzelle und in einen seltsamen Hochlatenz-Idle-Modus geworfen werden. Dieser Idle-Modus bewirkt, dass Modems mit sehr geringem Traffic konstant aus UMTS-Funkzellen geschmissen werden, sodass sie sich neu einloggen müssen. Dadurch verursacht er eine Idle Link-Latenz von über 350ms und einen plötzlichen Anstieg von Paketverlust und/oder Latenz auf bis zu 2500ms, wann immer der Channel versucht, wieder erhebliche Mengen an Bandbreite zu übertragen - nach diesem Anstieg normalisiert sich das Verhalten des Netzwerks wieder. All das kann bzgl. erreichbarem Durchsatz und Channel-Autotuning viele Probleme verursachen. Wir glauben, dass das, was Vodafone da tut, eine schreckliche Idee ist und Standards erheblich verletzt, müssen aber dennoch damit umgehen.
  Die neue „Save traffic when idle“-Option ist standardmäßig eingeschaltet, wodurch das Verhalten des Routers dasselbe ist wie bei früheren Firmware-Versionen, bei denen es diese Option noch nicht gab. Wenn Sie diese Option deaktivieren, wird mehr Idle-Ping-Traffic generiert (ca. 10–15 KBit/s), damit sichergestellt wird, dass das Modem nicht aus der UMTS-Funkzelle gekickt wird. Allerdings werden Sie dadurch mehr Traffic verbrauchen. Wir empfehlen daher, diese Option nur beim Einsatz im Vodafone UK-Netzwerk zu deaktivieren.
  Eine alternative Lösung für das Problem ist, Latency Autotuning für Channels, die Vodafone UK-Netze nutzen, zu deaktivieren und innerhalb der Konfiguration für Channels einen „Optimal Latency below“-Wert von 400ms und einen „Maximum allowed Latency“-Wert von 2500ms zu wählen. Auf diese Weise bleibt der Channel auch dann nutzbar, wenn Vodafone UK den Idle-Modus aktiviert.
  Außerdem kann unser 3G-Monitoring-Code jetzt diesen seltsamen Idle-Modus entdecken und wird ihn entsprechenden Monitoring Tools als Registrierungsstatus „Normal / Idle“ berichten.

• Seit letzter Woche wurden zahlreiche Exploits in der häufig genutzten Bash-Shell entdeckt. Während wir die Bash-Shell nicht direkt dort einsetzen, wo sie mit der Außenwelt in Kontakt käme, wird sie vom DHCP-Client-Dienst genutzt, der für die WAN-Module läuft. Es gibt einen unbestätigten möglichen Angriffsvektor, der bewirkt, dass wenn ein Angreifer in der Lage wäre, einen kompromittierten DHCP-Server an ein Viprinet WAN-Ethernet-Modul anzuschließen und wenn dieses Ethernet-Modul dann konfiguriert würde, um DCHP zu nutzen, dann könnte der Router mithilfe manipulierter DHCP-Optionen dazu gebracht werden, Code auszuführen.
  
  Diese Firmware-Version beinhaltet alle veröffentlichten Patches für Bash und behebt daher nach unserem Erachten alle bekannten Schwachstellen.
  
  Bis Sie Ihren Router auf die neue Version aktualisiert haben, können Sie einen potentiellen Angriffsvektor auch dadurch schließen, dass Sie DHCP auf WAN-Ethernet-Modulen abschalten und diese stattdessen auf eine statische IP konfigurieren.
  
  Soweit wir wissen, gibt es für VPN Hubs keine solchen Angriffsvektor und es gibt auch keinen Angriffsvektor für irgendeinen unserer anderen Routerdienste oder VPNs.
• VDSL-Module antworteten immer „No answer received from modem“, wenn sie die Modulinfo auslasen.
• CDMA450-Module hatten diverse Probleme mit Reset und dem Wechsel vom/zum Stromsparmodus. All diese Probleme wurden behoben.
• In sehr seltenen Fällen konnte die SIM-Initialisierung für unsere LTE-Module aufgrund eines Qualcomm-Fehlers schieflaufen. Ein Work-Around stellt sicher, dass das nicht mehr passiert.
• Durch das Erstellen von unzulässigen Port-Forwarding-Einträgen konnte man ein Port-Forwarding der Hölle einrichten, durch das man sich aus dem Router aussperren konnte. Nun ist es nicht länger möglich, sich selbst so ins Knie zu schießen.
• Wenn man eine Routing-Regel anlegte, bei der alle Optionen auf „Ignore“ standen, konnte man faktisch eine Default-Route anlegen, bei der man sich aus dem Router aussperren konnte. Auch diese Möglichkeit, sich selbst ins Knie zu schießen, wurde beseitigt.