Firmware Classic Stable

Classic Stable Firmware Release 27. November 2015 – Version 2015081830/2015102900

Diese Stable Firmware-Version behebt einige Fehler im Hinblick auf ein Upgrade zu RuggedVPN. Sie beinhaltet auch einige wichtige Fehlerbehebungen für jeden, der mobiles Breitband (UMTS, CDMA, LTE) in seinem Setup nutzt und behebt seltene Abstürze bei Hubs 5010 und Probleme, die bei Node Stacking auftreten können.

Diese Firmware-Version ist sowohl mit der Stable Firmware-Version vom 25. Februar 2015 (Version 2014110730/2015021100) kompatibel als auch mit allen Cutting-Edge Firmware-Versionen seitdem. Wir empfehlen, jeden einzelnen Viprinet Hub und Node auf diese Firmware-Version zu aktualisieren. Diese Version ist identisch zur Cutting Edge Firmware-Version vom 29. Oktober 2015.

Neue Funktionen

Der Lizenzmanager, den es bislang nur für RuggedVPN gab, ist nun auch für die Classic Firmware verfügbar.
Die SupportID, die benötigt wird, um einen Router für das kommende Viprinet Lifetime Maintenance System zu registrieren, wird nun angezeigt.
Es ist nun erlaubt, ohne aktives VLM-Abonnement von Classic auf RuggedVPN aufzurüsten. Dabei wird eine Warnung angezeigt. Bitte beachten Sie, dass RuggedVPN dennoch ein VLM-Abonnement benötigt. Allerdings müssen Sie die VLM-Registrierung nun nicht mehr zwingend vor der Installation der RuggedVPN-Firmware vornehmen, sondern können das danach machen. Nach der Installation von RuggedVPN bleibt der Router 14 Tage lang voll funktionstüchtig; wenn er bis dahin nicht unter ein VLM-Abonnement genommen wurde (oder wenn der Router nicht wieder zu Classic zurückgestuft wurde), hört das Gerät auf, zu funktionieren. Auf diese Weise können unsere Kunden die RuggedVPN-Firmware testen.
Diese Firmware-Version bietet erstmals volle Unterstützung für die nordeuropäischen LTE450-Module.

Fehlerbehebungen

Bei Verwendung mehrerer neuer 4G Module konnte den Router komplett blockieren, wenn eines der Module nicht in der Lage war, die Heimnetzwerkinformation von der SIM-Karte zu lesen.
Die Anzeige des Netzwerknamens war beim 4G Europe II Modul für einige Anbieter (z.B. T-Mobile) fehlerhaft.
Unter sehr seltenen Umständen konnten beschädigte SSL-Daten bei einem Hub 5010 einen Absturz und anschließenden Reboot auslösen.
4G Module, die in einem Stacking Slave verwendet wurden, konnten sich nicht in manche mobilen Netzwerke verbinden.
Unter seltenen Umständen konnte es passieren, dass WWAN-Module die IMSI und Home MCC/MNC von der SIM-Karte nicht lesen konnten, wodurch Automatic APN Detection versagte.
Die APN-Datenbankeinträge wurden für AT&T USA, Rogers und Telus Canada aktualisiert.
Ein seltener Absturzfehler auf VPN Hubs, der auftrat, wenn sich veraltete VPN-Clients verbinden wollten, wurde behoben.
In einem Node-Stacking-Setup haben gestackte Nodes bislang nie LAN-Routen geteilt.
Ein Fehler, bei dem GPS Geschwindigkeit und Richtung nicht aktualisierte, wurde behoben. Alle Produkte sollten jetzt CPU- und Systemkerntemperaturen anzeigen. Bitte beachten Sie, dass für manche Produkte jetzt ein anderer Temperatursensor tiefer innerhalb der CPU verwendet wird. Dadurch kann es passieren, dass Ihre CPU-Temperatur um etwa 10–20°C steigt. Das ist kein Problem und auch kein Defekt.
QoS-Regeln, die nur für TOS galten, wurden bislang ignoriert.
Alle Warn-Popups bzgl. fehlender Service-Verträge und RuggedVPN wurden aktualisiert. Wir möchten uns an dieser Stelle für jegliche Verwirrung entschuldigen, die diese nervenden Meldungen aus früheren Firmware-Versionen verursacht haben.
Wenn ein Classic-Router sich zu einem RuggedVPN-Hub verband, konnte es unter sehr seltenen Umständen passieren, dass der Traffic für QoS-Klassen, die den BondingTCPOptimizer verwenden, auf dem Classic-Node geblockt wurde.
Bislang funktionierte eine Änderung der Einstellung „Enabled mobile technologies“ manchmal nicht, speziell wenn sie für ein Modul getroffen werden sollte, das gerade eine Datenverbindung offen hatte. Nun sollte diese Änderung immer funktionieren.
Nach einem Routerneustart konnte es unter seltenen Umständen passieren, dass ein Stacking Master-Node seine Kommunikationsbuchse nicht aktivieren konnte, wodurch die Stacking Slaves wiederum nicht in der Lage waren, sich mit dem Master zu verbinden, woraus im Endeffekt eine Split Brain-Situation entstehen konnte. In diesem Worst Case startet der Stacking Master jetzt neu, um dieses Split Brain aufzulösen.
Unter sehr seltenen Umständen konnte es passieren, dass zwei in einem Split-Konflikt stehende Stacking Nodes, die gleichzeitig zu einem Hub mit einem zuvor weniger als 3 Minuten unterbrochenen Tunnel verbinden wollten, diesen Hub zum Abstürzen bringen konnten.
Im SNMP wurde vonRouterCPULoad als string ausgegeben, anstatt als integer, wie es eigentlich hätte sein müssen.
Für VDSL-Module war der Sync Speed im Log vertauscht („Synched Downstream / Upstream Rate“). Die tatsächlichen Werte waren in Ordnung, daher war dies nur ein Anzeigefehler.
Falls die DNS-Auflösung auf einem VPN Hub falsch konfiguriert ist, kann der DNS Reverse-Lookup für eingehende Channelverbindungen sehr lange dauern. Falls sich viele Channels neu verbinden, kann das das Abschließen dieser Reconnects sehr lange verzögern. Eingehende Channel-Verbindung werden nun nicht mehr umgekehrt aufgelöst. Lizenzen werden nun gelöscht, wenn der Lizenzserver das anordnet, und die Online-Lizenzdeaktivierungsfunktion ist nun auch verfügbar.
MCC/MNC wurde auf dem Gerät nicht erneut ausgelesen, wenn der erste Versuch fehlschlug. Dadurch konnte es passieren, dass die APN Auto Detection manchmal versagte.
Ein LTE-Modul zu resetten oder wiederzuverbinden, kann bei der Synchronisation des internen Router-Timers zu einer Abweichung von bis zu zwei Sekunden führen. Aufgrund dessen verhalten sich Channels eigenartig: Sie zeigen hohe Latenz, Channel-Stillstand, etc. an. Dieses Problem ist nun behoben. Der Reset oder das Wiederverbinden eines Moduls sollte andere Channels nicht weiter beeinflussen.
Weil die Anti-DDoS-Verbindungsbegrenzung nicht korrekt initialisiert wurde, konnte es bei allen früheren Firmware-Versionen passieren, dass manchmal die Übertragung von Konfigurationsdaten zwischen aktiven und Hotspare-Hubs durch einen SSL-Fehler versagte.
Die Abonnement-Stufe „Iron“, die bei OEM-Projekten Verwendung finden wird, wird nun unterstützt.
Eine bereits bestehende Konfigurationsdatei von einer früheren RuggedVPN-Installation wird nun beseitigt, wenn das Gerät auf Werkseinstellungen zurückgesetzt wird.
Es gab einen Weg, um SSH-CLI-Verbindungen ohne Auswirkung auf die Verbindungsbegrenzung zu schließen. Das konnte dazu führen, dass nach zuvielen Reconnects eine IP permanent aus der CLI ausgeschlossen wurde.
Der Lizenzmanager benutzt nun immer das richtige Interface für Lizenzaktivierungen und -deaktivierungen. Davor funktionierte das nur, wenn die Default-Route auf einem VPN-Tunnel lag.
Die Verbindungsbegrenzung / der DDoS-Schutz wurde geändert. HTTP-, VPN-, SSH-, Stacking- und Hotspare-Verbindungen werden nun individuell pro IP gezählt.

Classic Stable Firmware Release 25. Februar 2015 – Version 2014110730/2015021100

Diese neue Stable Firmware-Version ist die letzte Firmware-Version der „klassischen“ Serie, die neue Features bringt. Neue Funktionen gibt es anschließend dann in unserer „Next Generation“-Plattform.

Diese Firmwareversion behebt auch noch die letzten Stabilitätsprobleme unserer ausgereiften Firmware, sodass sie bestmöglich für einen länger andauernden Gebrauch geeignet ist (d.h. bis Kunden auf die NG-Firmware umsteigen).

Außerdem ist diese Firmware-Version vollständig kompatibel mit der Stable Firmware-Version vom 2. Oktober 2014. Es ist daher in Ordnung, VPN-Hubs mit der vorherigen Stable Firmware-Version zu betreiben und nur diejenigen VPN-Nodes zu updaten, die die beschriebenen Verbesserungen benötigen. Geräte, auf denen bereits die Cutting-Edge Firmware-Version 2014110730/2015021100 vom 11. Februar 2015 installiert ist, müssen nicht geupdated werden – die Firmware-Images in „Cutting Edge“ und „Stable“ sind aktuell identisch.

Kunden, die auf ihren Geräten noch immer Firmware-Versionen von vor Oktober 2014 installiert haben, empfehlen wir, die Release Notes der Oktober-Version vor einem Update genau durchzulesen, da sie viele Neuerungen und Fehlerbehebungen enthält.

Bitte beachten Sie, dass Sie diese Firmware-Version benötigen, um VDSL- oder 4G Europe II-Module betreiben zu können.

Neue Funktionen

Es ist jetzt möglich, DNS-Server für VPN-Client-Gruppen zu konfigurieren. Wenn das der Fall ist, wird der VPN-Client diese DNS-Server anstatt den Hub-DNS nutzen. Dadurch ist es möglich, den VPN-Client in Kombination mit einem Domain-Controller zu nutzen, damit VPN-Client-Nutzer Teil einer Windows-Domäne werden können.
Das neue „4G Europe II“-Modul wird nun unterstützt.
Die CLI unterstützt nun die Werkzeuge Ping, Traceroute und Moduleinfo (angelehnt an die Funktionen im Web-Interface).

Fehlerbehebungen

Eine Race Condition, die bewirkte, dass Update-Scripts manchmal zweimal aufgerufen wurden, wenn man sie manuell startete, wurde behoben.
Sehr große (100Mb+) lokale Update-Pakete werden nun unterstützt.
Ein Fehler wurde behoben, bei dem Offline-Firmware-Updates manchmal abgebrochen wurden, was bewirkte, dass fehlerhafte Firmware-Uploads zurückgewiesen wurden. Das passierte, wenn nur 100ms lang keine Daten während des Uploads gesendet wurden. Meist geschah das mit dem neuen Web-Interface und wenn Updates manuell eingespielt wurden.
Die Verteilung von Systemlast auf Mehrkern-Hubs wurde verbessert.
Der Start für die Benachrichtigung bzgl Serviceverträgen wurde auf März 2015 verschoben.
Diese Firmware-Version bringt einige Verbesserungen für LTE-Statusberichte.
Ein Fehler wurde behoben, der verursachte, dass OptimalLatencyBelow nicht in der Monitoring API und im Monitoring-Tool angezeigt wurde.
Die IP-Adresse eines ersetzten Geräts im Hub-Hotspare-Modus wird nun im neuen Web-Interface angezeigt.
Einige Fehler im Channel-Congestion-Benachrichtigungssystem wurden behoben.
Die SIM-Traffic-Berichterstattung konnte in einem Status enden, bei dem sie ihre Werte nie an den Abrechnungs-Server schickte.

Classic Stable Firmware Release 2. Oktober 2014 – Version 2014093030/2014100200

Diese neue Firmware-Version beinhaltet wichtige Fehlerbehebungen für die Cutting Edge und die Stable Firmware-Version von August 2014. Sie behebt außerdem alle potenziellen Sicherheitsprobleme mit der eingebetteten Bash-Shell, die intern in unseren Routern verwendet wird (bekannt als „Shellshock“). Obwohl eine solche Shellshock-Attacke im Hinblick auf unsere Geräte ohne lokalen Systemzugang sehr schwer umzusetzen ist, existiert mit diesem Fehler dennoch ein gewisses Risiko, das mit dieser Firmware ausgeräumt wird.

Wir raten all unseren Kunden DRINGEND, so schnell wie möglich auf diese Firmware-Version umzusteigen.

Diese Version bringt keine neuen Funktionen, sondern ausschließlich größere Fehlerbehebungen. Außerdem ist diese Version für beide Firmware-Versionszweige, Cutting Edge und Stable, identisch.

Kunden, die auf ihren Geräten noch immer Firmware-Versionen von vor August 2014 installiert haben, empfehlen wir, die Release Notes der August-Version vor einem Update genau durchzulesen, da sie viele Neuerungen und Fehlerbehebungen enthält.

Fehlerbehebungen:

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.

Classic Stable Firmware Release 18. August 2014 – Version 2014061630/2014080100

Diese Firmware-Version bringt einige neue Funktionen, vor allem aber eine große Anzahl an Verbesserungen.

Diese Firmware-Version ist mit dem Cutting-Edge Firmware-Release vom 6. August 2014 (Version 2014061630/2014080100) identisch. Wenn Sie bereits diese Cutting-Edge-Version benutzen, müssen Sie nicht updaten.

Die wichtigste neue Funktion ist, dass Hubs und Router mit dieser Version nun in der Lage sind, einander zu benachrichtigen, wenn die jeweils andere Seite neustartet. Das behebt eine Reihe von Problemen, die durch eine spezielle Art von Traffic entstanden, wenn nur eine Seite eines Tunnels neugestartet wurde und wenn dieser Neustart unter 3 Minuten lag. Die nicht neugestartete Seite erwartete dann, dass die vorher existierende Tunnelverbindung wieder aufgebaut würde, und hielt dafür alle alten Verbindungs-Flow-States aufrecht, während das neugestartete Gerät aber mit einem leeren State startete. Dadurch konnten Verbindungen, die schon vor dem Neustart existierten, steckenbleiben. Während das für die meisten Protokolle kein Problem ist, hat IPSec damit z.B. große Schwierigkeiten, weil es immer dieselben UDP-Verbindungen wieder verwendet (Quell-/Zielport). Diese Verbindungen konnten für lange Zeit steckenbleiben.

Kurz gesagt: Dieses Update sollte die Probleme für alle Kunden beheben, die IPSec oder ähnliche Tunnelprotokolle (GRE) nutzen und deren Tunnel bislang innerhalb eines Viprinet-Tunnels steckenblieb, wenn entweder der Router oder der Hub neu starteten.

Eine weitere wichtige Neuheit ist, dass diese Firmware-Version ein neues Konzept namens „Managed SIM“ unterstützt: eine zentralisierte SIM-Verwaltung mit gemeinsamem Traffic sowie Berichterstattung und Überwachung. Im Moment profitieren nur Kunden in Deutschland von „Managed SIM“; es ist aber geplant, diesen Service auch in anderen Ländern zur Verfügung zu stellen.

Außerdem werden VDSL-Module jetzt vollständig unterstützt.

Und zu guter Letzt wurden auch verschiedene Optimierungen vorgenommen, um Viprinet künftig besser in Hochgeschwindigkeitsfahrzeugen nutzen zu können.

Obwohl dieses Release vollständig kompatibel zur Stable Firmware-Version vom 6. April 2014 (Version 2014021430/2014022500) ist, funktionieren manche der Neuerungen nur, wenn Hubs und Router geupdated werden. Wir empfehlen daher, Hubs und Router zur selben Zeit zu updaten.

Diese Firmware-Version beinhaltet außerdem eine wichtige Fehlerbehebung für die Routerreihe 5XX: Ohne diese Fehlerbehebung könnte es passieren, dass diese Geräte dauerhaft ausfallen, wenn die Stromversorgung während eines bestimmten Augenblicks beim Hochfahren unterbrochen wird. Wir legen daher allen Kunden, die die Routermodelle 500, 510, 511, 512 oder 513 einsetzen, DRINGEND nahe, ihre Geräte schnellstmöglich auf diese Firmware zu updaten.

Wichtige Information für Nutzer, die von älteren Firmware-Versionen upgraden möchten

Wenn Sie von irgendeiner Firmware älter als die letzte Stable Firmware-Version (2014021430/2014022500) updaten möchten, lesen Sie vorher bitte die Release Notes aller älteren Firmware-Versionen, wobei die Notes der aktuellen Stable Firmware-Version am wichtigsten sind.

Liste der Veränderungen im Vergleich zur vorherigen Stable Firmware-Version

Neue Funktionen

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

Fehlerbehebungen

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.

Classic Stable Firmware Release 6. März 2014 – Version 2014021430/2014022500

Im Zuge der NSA-Enthüllungen hebt diese Stable Firmware-Version die Sicherheit unserer Produkte auf eine neue Ebene. Wir haben die vergangenen Wochen damit verbracht, so ziemlich jeden sicherheitsrelevanten Aspekt unserer Produkte zu verbessern.

Außerdem beinhaltet diese Firmware-Version eine finale und stabile Version unseres neuen Administrations-Web-Interface, das als Preview schon seit ein paar Monaten verfügbar war.

Und schließlich behebt diese Firmware eine Reihe an Fehlern.

Dieses Release ist vollständig kompatibel zur Stable Firmware-Version vom 12. August 2013 (Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)). Eine gemischte Installation von Routern und Hubs, die noch die vorherige Stable Firmware-Version nutzen, ist daher möglich. Viele Verbesserungen bzgl. Sicherheit erfordern jedoch Unterstützung auf beiden Seiten des VPNs. Wir empfehlen daher, sowohl auf dem Router als auch auf dem Hub zügig diese Firmware-Version zu installieren.

Wichtige Hinweise für Kunden, die von einer früheren Stable Firmware-Version updaten

Viprinet unterstützt nun Zugriffskontrolllisten (ACL). Damit können Sie definieren, welche IPs und Subnetze aus dem LAN oder WAN/VPN auf welche Dienste zugreifen können. Beim Firmware-Update wird ein Standardregelsatz erstellt. Diese Regeln sind so gestaltet, dass sie existierende Installationen nicht beeinträchtigen, aber es wird empfohlen, sie zu verfeinern. So wird z.B. der Zugriff auf den AdminDesk sowohl per HTTP als auch HTTPS von überall gestattet, wobei wir empfehlen, aus dem Internet nur HTTPS zuzulassen.

Aufgrund der neuen ACLs wurden die Einstellungen für die SSL-Zertifikate im AdminDesk von „[ AdminDesk ] LAN settings“ zu „[ AdminDesk ] Integrated services“ verschoben. Sollten Sie Ihr eigenes SSL-Zertifikat installiert haben, müssen Sie es nach dem Firmware-Update erneut installieren.

Auch alle SNMP-Einstellungen wurden zu „[ AdminDesk ] Integrated services“ verschoben. Nach dem Firmware-Update müssen Sie SNMP erneut konfigurieren.

Liste der Veränderungen im Vergleich zur vorherigen Stable Firmware-Version

Neue Funktionen

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.

Fehlerbehebungen

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.

Classic Stable Firmware Release 12. August 2013 – Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)

Dieses neue Stable Release beinhaltet eine Menge Verbesserungen. Die meisten dieser Fehlerbehebungen gab es schon im Cutting Edge-Firmware Release von Anfang Juli; seitdem haben sie sich bewährt. Wir empfehlen allen unseren Kunden, möglichst bald auf diese neue Stable Firmware umzusteigen.

Folgende Funktionen stehen im Vordergrund dieser Firmware:

Viele Verbesserungen hinsichtlich Channel Autotuning
Beseitigungen von Stabilitätsproblemen für Node Stacking
VLAN-Support on Nodes (kein Lizenzschlüssel notwendig)
Metrische Tonnen an Fehlerbehebungen für Ethernet Auto-Negotiation. Das Ausschalten von Auto-Neg und das Festlegen von Parametern funktioniert nun für alle Produkte, alle LAN- und WAN-Interfaces, und alle Ethernet-Module.
Hinzufügen von Required Link Stability zu QoS-Klassen, wodurch es nun möglich ist, instabile Channels, auf denen Packet Loss oder Jitter kritisch ist, für QoS-Klassen auszuschließen (z.B. VoIP)
Deutlich verbessertes HTTP Download Test-Tool, integrierter Test-Traffic-Generator in Hubs/Router
Schutz gegen DNS Amplification-Attacken
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.

Hier ist eine detaillierte Liste der Veränderungen:

Verbesserungen

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.

Fehlerbehebungen

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.

Classic Stable Firmware-Release 24. Juni 2013 – Version 2013051031/2013062100

Dieses Firmware-Release gründet sich auf unser Stable Firmware-Release vom 6. Juni, das eine große Anzahl neuer Funktionen brachte, und behebt einen wichtigen und einige weitere Fehler. Damit befindet sich diese Firmware-Generation nun auf dem Qualitätslevel, auf dem sie schon von Anfang an hätte sein sollen.

Informationen zu den neuen Funktionen finden Sie in den Release-Notes zum Firmware-Release vom 6. Juni.

Fehlerbehebungen

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.

Classic Stable Firmware Release 11. Juni 2013 - Version 2013060730/2013061001

Dieses Firmware-Release behebt einen gewichtigen Fehler, der in verschiedenen früheren Firmware-Versionen zu finden war, nämlich in:

Version 2013021930/2013042305 (Cutting Edge Firmware Release 23. April 2013)
Version 2013051031/2013060600 (Stable Firmware Release 6. Juni 2013)
Version 2013051031/2013061001 (Stable Firmware Release 10. Juni 2013)

Beim Einschalten des Routers oder nach dem Neustarten eines WAN-Moduls konnte es manchmal passieren, dass die internen Verweise des Routers vertauscht wurden. In dieser Situation wurde beim Anlegen eines Channels über das Modul in Slot 1 in Wirklichkeit ein Channel über das Modul in Slot 2 angelegt und auch die Slot-IP-Zuweisungen wurden vertauscht. Innerhalb des Web-Interface jedoch schienen die Module in den jeweils richtigen Slots zu sein. Das ist ein sehr verwirrender Zustand und für End-User sehr schwer zu erkennen. Dieser Fehler wurde bisher nur beobachtet, wenn mehrere Gigabit Ethernet Module in einem Router betrieben wurden - in der Theorie könnte der Fehler aber auch mit anderen Modultypen auftreten.

Alle modularen Viprinet-Router (Multichannel VPN Router 300, 1610, 2610), auf denen eine der oben genannten Firmware-Versionen läuft, sind von diesem Fehler betroffen. Nicht betroffen sind alle Viprinet-Hubs und der Multichannel VPN Router 500.

Wir empfehlen nachdrücklich allen Kunden, die ihre Router mit einer der oben genannten Firmware-Versionen betreiben, ihre Router auf die neueste Version zu updaten. Ein Update für nicht-betroffene Produkte (Multichannel VPN Hubs oder Multichannel VPN Router 500) ist nicht unmittelbar erforderlich.

Jedoch wird allen Kunden, die eine Firmware-Version von vor dem 6. Juni 2013 (2013051031/2013060600) nutzen, ein Update innerhalb ihrer nächsten Wartung vorzunehmen, um zahlreiche Produktverbesserungen und neue Funktionen nutzen zu können, die die neue Firmware-Version umfasst.

(Hinweis: Die aktuellste und empfohlene Firmware-Version für den Multichannel VPN Router 500, Hub 5000 und Hub 5010 ist immer noch 2013051031/2013061001, ausgegeben am 10. Juni 2013; das aktuellste Release für die Multichannel VPN Hubs 1000, 1020, 2000 und 2020 ist das von heute, das für diese Geräte zur vorherigen Version keine Änderungen enthält.)

Classic Stable Firmware-Release 10. Juni 2013 – Version 2013051031/2013061001

Dieses Stable Firmware-Release beinhaltet zwei wichtige Fehlerbehebungen für die Stable Firmware-Version vom 06. Juni 2013. Für weitere Informationen zu den Änderungen in der neuen Firmware lesen Sie bitte die Release Notes für die Firmware-Version 2013051031/2013060600 vom 06. Juni 2013.

Verbesserungen

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.

Classic Stable Firmware-Release 6. Juni 2013 – Version 2013051031/2013060600

Dieses Stable Firmware-Release bringt eine ganze Reihe von neuen Features, sowie eine große Anzahl von Verbesserungen und Fehlerbehebungen. Das wichtigste neue Feature ist, dass das Stacking von Node-Routern jetzt unterstützt wird. Mithilfe von Stacking können mehrere Router zu einem Stack zusammengefasst werden; diese bilden dann einen großen virtuellen Router, mit dem Sie praktisch eine unbegrenzte Zahl an WAN-Links bündeln können. Ein weiterer Vorteil von Stacking ist Hardware-Redundanz. Erhältlich ist es als optionale Zusatzlizenz. Des Weiteren gibt es nun ein neues, modernes Web-Interface zur Administration von Routern, und auch GPS-Funktionalität wird von den Routern nun unterstützt (sofern eines unserer neuen LTE/GPS-Module verwendet wird). Außerdem bietet diese Firmware nun auch ein weiteres, oft gewünschtes Feature: Tunneln und Channels kann nun ein „Backup Score“ zugewiesen werden. Wenn Ihr Hauptchannel abbricht (z.B. ein hochperformanter DSL-Link), kann der Router also nun verschiedene Backup-Channel (z.B. zwei UMTS-Links) aktivieren, um den Abbruch auszugleichen. Channels kann nun auch ein Kostenwert zugewiesen werden. In diesem Fall werden vorrangig Channels mit niedrigeren Kosten benutzt, wenn nicht alle Channel genutzt werden müssen, um eine spezifische Bandbreite zu erreichen.

Wir empfehlen allen unseren Kunden, möglichst bald auf diese neue Stable Firmware umzusteigen.

Verbesserungen

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.

Fehlerbehebungen

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.

Firmware Release 6. Februar 2013 - Version 2013012301/2013020600 (Multichannel VPN Router 500: 2012112320/2013020600)

Dieses Firmwareupdate setzt auf unseren Stable-Release aus Dezember auf, und behebt dabei einige zum Teil wichtige Fehler. Zudem werden die neuen CDMA-450MHz Modultypen mit diesem Firmwarerelease erstmals unterstützt. Das Kommandozeileninterface (CLI) ist nun bereit für den Produktionseinsatz.

Wir empfehlen allen unseren Kunden möglichst bald auf diese neue stabile Firmware umzusteigen. Bitte beachten Sie, dass alle miteinander verbundenen Hubs und Router die gleiche Firmwareversion verwenden sollten. Zwar ist dieser Firmwarerelease Verbindungskompatibel mit früheren releases, wenn Router oder Hubs sich zu Routern bzw Hubs mit älterer Firmware verbinden, wird die Performance aber eingeschränkt sein.

Verbesserungen

Mit diesem Release unterstützten wir erstmals unsere neuen CDMA 450 Mhz Module, die für den Einsatz in Nord- und Osteuropa bestimmt sind.
Channel Congestion Detection ist nun etwas aggressiver eingestellt als bisher.
Die CLI wurde vervollständigt und ist nun bereit für den Produktiveinsatz. Ein Scripting Toolkit, mit dem die Administration und das Deployment von Routern automatisiert werden können, ist auf Anfrage verfügbar.

Fehlerbehebungen

WICHTIG: Im vorangegangenen Stable Firmware Release aus Dezember 2012 existiert ein ernstzunehmender Fehler. Referenzen von VPN Routing Regeln auf einen Tunnel können zerstört werden, wenn Tunnel aus der Tunnelliste gelöscht werden - anschließend zeigen Regeln dann auf die falschen Tunnel. Ähnliches konnte auch bei QoS-Regeln passieren. Löschen Sie mit dem Dezember-Release keine Tunnel. Aktualisieren Sie zunächst auf diese Firmware.
Wenn Channel komplett idle waren (für geraume Zeit weniger als 20 KBit/s an Traffic), hätten die Channel eigentlich in einen Trafficsparmodus gehen sollen, bei dem nur noch 1x pro Sekunde statt 10x pro Sekunde die Latenz und Eigenschaften des Channels analysiert werden. Damit sollte der Trafficverbrauch insbesondere bei Leitungen mit hohen Traffic-Kosten (z.B. UMTS) reduziert werden. Durch einen Rundungsfehler hat diese Funktion leider tatsächlich in der Praxis nie funktioniert: Wenn auf einem Channel auch nur ein einziges Mal mehr als 24 Kbit/s übertragen worden war, wurde der Traffic-Sparmodus nie wieder aktiviert. Dieser Modus funktioniert nun so wie erwartet und reduziert den Trafficverbrauch bei ungenutzten Channeln um den Faktor 10.
Im Hotspare-Modus eines Hubs zeigt der Lizenzmanager nun einen Hinweis an, dass in diesem Modus keine Lizenzen geprüft werden.
Ein Timingproblem konnte beim 500er Router in seltenen Fällen dazu führen, dass es gelegentlich kurze Aussetzer beim Routing gab.
Das Ethernet Infotool für das LAN Interface am 500er Router funktioniert nun tatsächlich.
Mehrere BondingTCPOptimizer bugs wurden gefixt. Diese konnten BondingTCPOptimizer TCP-Verbindungen hängen lassen, wenn nicht das WAN sondern das LAN das Bottleneck darstellte (z.B. wenn es im LAN einen traffic shaper hinter dem Viprinet-Router gab).
Ethernet Autonegotiation Settings für Ethernet WAN Module wurden bisher nicht gespeichert und waren nach einem Reboot verschwunden. Dies ist nun behoben. Weiter besteht ein bekanntes Problem: Bei Gigabit Ethernet modulen lässt sich Ethernet Autonegotiation aufgrund eines Bugs im NIC-Treiber aktuell nicht deaktivieren. Bitte nutzen Sie als Workaround Fast Ethernet Module in diesen Fällen.
Ein Memoryleak in Bezug auf Tunnelobjekte wurde behoben. Wenn man mit bisherigen Firmwarereleases eine sehr große Zahl von VPN Tunnel z.B. per automatisierter Scripte anlegete und löschte, konnte dem Router mit der Zeit das RAM ausgehen, so dass dieser rebootete. Das passiert nicht länger. Auch wurde die Performance beim Massenanlegen oder -löschen einer großen Zahl von Tunneln verbessert.
Im vorangegangenen Firmwarerelease wurde eingeführt, dass ein Router nach Auftreten einer hohen Zahl von kritischen Fehlern im Routerlog automatisch neu startete. Leider wurde bisher auch der Ausfall einer der zwei Lüfter eines Routers fälschlicherweise als kritisch gelogged, weswegen nun alle Router, bei denen ein Lüfter ausgefallen war, alle paar Minuten rebooteten. Das Problem wurde behoben, in dem der Ausfall nur eines einzelnen Lüfters nun als "Alert" statt als "Critical" gelogged wird.
Ein "invalid floating point error" konnte erscheinen wenn man im Download tool des Web interfaces die Option "Measure & discard" nutzte.
Wenn man das PUTTY-Tool plink nutzt um eine Liste von Kommandos per CLI durch den Router ausführen zu lassen, wurden bisher carriage returns ignoriert, wodurch man immer nur ein Kommando ausführen konnte.

Beispiel:
plink -pw -batch -ssh -P 22 root@ -m commands.txt -v ERROR 140 ←[1m←[31mThis object does not exist←[0m

Nun funktioniert dies sowohl mit CR als auch CR/LF als Kommandotrenner.
Die CLI erlaubt es nun Unterobjekte anhand ihres Objekt-Indexes statt ihres Namens zu löschen - z.B. mit "execute DELETEITEM OBJECT__2"
Die CLI schließt SSH-Verbindungen situationsabhängig nun korrekt. Damit wird es auch möglich SSH-Scriptingtools (z.B. Paramiko) zu nutzen, die pro Kommando einen neuen SSH-Subchannel öffnen.
Mehrere Tippfehler im Webinterface wurden behoben.
Das Timing von Hubs in einer Redundanzgruppe, welche beim Routerstart prüfen ob sie ersetzt wurden, ist nun deutlich robuster.
BondingTCPOptimizer Verbindungen welche auf dem WAN packet loss ausgesetzt waren konnte insbesondere bei instabilen aber schnellen WAN-Verbindungen dafür sorgen, dass aufgrund fehlernder Pakete und Retransmissions sich beim empfangenden Router große Mengen an Daten aufstauten. War der Datenstrom durch Retransmission dann vollständig, wurden diese Daten mit einem Schlag ins LAN weitergeleitet, teilweise mehrere Megabyte. Das sorgte für eine große Trafficspitze im LAN, womit nicht alle Geräte in einem LAN besonders gut klarkamen. Auf dem Router war dies als "XX packets have been dropped reading from LAN" Nachricht zusehen. Die Pakete werden in der oben genannten Situation nun langsamer ins LAN geleitet, wodurch diese Spitzen deutlich abgemildert werden.

Firmware Release 10. Dezember 2012 - Version 2012091701/2012121005 (Multichannel VPN Router 500: 2012112320/2012121005)

Dieser Firmwarerelease bringt eine große Zahl von Verbesserungen zu unseren Kunden. Für alle unsere Router/Hub-Produkte wurde die Performance und der erreichbare Durchsatz für alle Bündelungs-Modi deutlich verbessert. Für den Multichannel VPN Router 500 gibt es zahlreiche Verbesserungen in Bezug auf Stabilität und Performance. Das Kommandozeileninterface (CLI) ist zwar weiterhin im Beta-Stadium, aber nun tatsächlich auch benutzbar. Ein Scripting Toolkit hierfür wird in kürze bereitstehen, hiermit lassen sich dann einfach auch große Zahlen von Routern automatisiert konfigurieren und verwalten. Dieser Firmwarerelease beinhaltet eine Vielzahl von Verbesserungen von Installationen unserer Router in sich bewegenden Fahrzeugen - Sie werden jetzt in der Lage sein, stundenlang mit unseren Routern unterwegs zu sein, ohne einen einzigen Verbindungsabbruch durch den VPN Tunnel zu erleben, sogar wenn Sie zwischenzeitlich kurz in Funklöchern sind. Für die VPN Hubs haben wir den VLAN-Support erweitert, und unsere Router bringen einen optimierten Satz an QoS-Regeln mit.

Verbesserungen

Der integrierte Bootloader des Multichannel VPN Router 500 verwendet nun Error Correction Codes. In der Vergangenheit haben wir defekte Router gesehen, die aufgrund von Bitfehlern auf dem verwendeten Flashspeicher nicht mehr starteten (in diesem Falle ging die Power-LED noch an, sonst geschah aber nichts mehr). Solche Bitfehler werden nun korrigiert. Mit dieser Verbesserung sollten Totalausfälle bei diesem Produkt nun nicht mehr vorkommen.
Die Router/Hubs behalten nun den State aller Verbindungen (inkl. NAT-State) bei, wenn ein Tunnel abbricht. Wenn der Tunnel innerhalb von 3 Minuten wieder verbindet, wird all state wieder hergestellt. In früheren Firmware-Releases verursachte ein totaler Tunnel-Disconnect (alle Channels disconnected), oft, dass Verbindungen durch den Tunnel nach Tunnel-Reconnect hängen blieben; das passiert nun nicht mehr, sofern der Tunnel innerhalb von 3 Minuten wieder verbunden ist. Das ist eine deutliche Verbesserung, speziell in sich bewegenden Fahrzeugen, die in eine sog. "Dead Zone" ohne Mobilfunkempfang hinein fuhren. Wir waren nun in der Lage, stundenlange Testfahrten durch Wälder etc. zu machen, ohne dass unsere Verbindungen durch den Tunnel auch nur einmal resetted wurden.
Der BondingTCPOptimizer-Modus wurde auch um einiges verbessert. Vorher hatte er Kompatibilitätsprobleme, speziell bei Verbindungen durch mehrere BondingTCPOptimizer-Tunnel (Standortvernetzung). Außerdem wurde die Leistung dieses Modus um einiges verbessert. Wir empfehlen nun, den BondingTCPOptimizer für jeglichen TCP-Traffic zu nutzen, wenn Sie Verbindungen mit hohen Latenzen bündeln, selbst bei Standortvernetzungen, da dieser Modus den erreichbaren Durchsatz signifikant verbessert.
Die Leistung für den Router 500 wurde enorm optimiert. In den meisten Situationen wurde der maximale gebündelte Durchsatz um über 30% erhöht.
VLAN-IDs können nun für "additional LAN Routes" konfiguriert werden.
Für LAN Aliases bei zugewiesener VLAN ID kann nun ein Default Gateway zugewiesen werden. Bei dieser Konfiguration wird die Segmentation ID für Traffic, der vom entsprechenden Tunnel kommt, direkt zu diesem Default Gateway geleitet, während das LAN Interface (VLAN 0) nicht mehr genutzt wird (und dieser Tunnel ist vom VLAN 0 auch nicht mehr erreichbar).
Diese zwei neuen Features ermöglichen es ISPs/BSPs, pro Kunde ein dediziertes VLAN auf dem Hub zu haben, eine Eigenschaft, die von zahlreichen Service Providern gewünscht wurde.
Das Web-Konfigurationssystem loggt nun Benutzer-Logins/-Logouts/-Fehler.
Ein neues Set an QoS-Regeln und -Klassen wurde geschaffen. Web-Surfen benutzt standardmäßig Bonding; für hoch-latenziertes Bündeln sollte diese Einstellung auf BondingTCPOptimizer geändert werden. RTMP-Stream nutzt standardmäßig immer BondingTCPOptimizer. Die Regeln für RTP/VoIP wurden geändert, um ToS zu entsprechen und generieren daher weniger False Positives. Außerdem unterstützen sie nun Video-Conferencing. Die VoIP-QoS-Klasse nutzt nun Lossy Bonding, wenn eine Lizenz dafür eingetragen wurde. Um diese neuen Regeln nutzen zu können, müssen Sie "QoS rules and classes templates" anwählen und "Restore Manufacturing Defaults" ausführen. Dann müssen Sie bei jedem Tunnel "Copy QoS templates to here" auswählen. Diese Schritte müssen Sie sowohl beim Hub als auch beim Router ausführen.
Es gab mehrere Buffer-Tunings. In vielen Setups wird sich dadurch der Durchsatz verbessern, speziell für Verbindungen, die den "Bonding"-Modus nutzen. Außerdem wurde die Leistung für hochlatenzierte Verbindungen und Verbindungen mit einem hohen Bandwidth-Delay Product (Satellit) verbessert.
Die Konfiguration von Ethernet Auto-Negotiation-Settings wird nun für Fast & Gigabit Ethernet Module unterstützt.
Bei hochlatenzierten Verbindungen (GPRS, Satellit) werden die Passive und Hybrid Autotuning Modi nun die Geschwindigkeit wesentlich langsamer erhöhen, sodass die Verbindung nicht überladen wird ohne dies zu spät zu bemerken.
Der Router kann nun vom LAN unter dem Hostname "viprinet.router" erreicht werden.
Das "Resource Reservation Protocol" (RSVP) kann nun durch Viprinet-Router geroutet werden.
Die Min and Max Befehle in der CLI funktionieren nun, und zeigen die minimal/maximal zulässigen Werte für eine Einstellung an.
Die CLI zeigt nun bessere Datentypennamen beim LIST-Befehl an.
Für LTE-Module wird die Signalstärkeninformation im Monitoring-Tool nun konstanter aktualisiert.

Fehlerbehebungen

Crash Bugs in der CLI in Zusammenhang mit Disconnects, während noch eine Antwort an den Client unterwegs war, wurden behoben.
Tab-Vervollständigung in der CLI funktioniert nun auch für die VALUES-, MIN- und MAX-Befehle.
Eine Änderung der WAN IP-Adresse an VPN Hubs unter Nutzung des Hub-Redundanzsystems konnte bewirken, dass anschließend das Webinterface des Routers hing und nicht mehr erreichbar war.
Hubs im Hotspare-Modus haben bisher alle optionalen Hub-Features als unlizensiert angezeigt. Es erscheint nun ein Hinweis, dass dies im Hotspare-Modus irrelevant ist.
Der 500er-Router hat für das LAN-Interface weder die Ethernet-Parameter angezeigt, noch ließen sich diese konfigurieren. Beides funktioniert nun.
TCP-Neuübertragungen, welche durch die "Retransmission multiplier"-Einstellung ausgelöst wurden, sorgten als Nebeneffekt dafür, dass Channels nicht mehr in den "Stalled"-Modus gingen. Dies wiederum bewirkte, dass solche Channel trotz überschreiten der "Maximum allowed latency" weiter genutzt wurden. Dieser Bug beschränkte insbesondere in bewegten Fahrzeugen die Performance.
Die 5 Ghz Channel Auswahl im WLAN Access Point des Multichannel VPN Router 500 hat nicht richtig funktioniert, nur der erste Channel konnte korrekt ausgewählt werden.
Im vorangegangenen Stable FirmwareRelease hat das Hub-Redundanzsystem nicht auf dem WAN-Interface gelauscht, sondern nur auf dem LAN-Interface. Das konnte eine "Split Brain"-Situation auslösen, wenn am Hub nur der LAN-Link ausfiel, während das WAN-Interface noch up war. Das Redundanzsystem nutzt nun wieder sowohl WAN- als auch LAN-Interface.
Wenn unter 'Reset after minutes of downtime' ein Wert konfiguriert war, wurde das Modul selbst dann in diesem Intervall rebooted, wenn das Modul eigentlich deaktiviert war.
Objekt-Referenzen (Ziele von QoS-Regeln, Verweise auf WAN-Module in den Channels etc.) lassen sich nun auch mit der CLI konfigurieren.

Firmware Release 25.09.2012 - Version 2012091701/2012091800 (Multichannel VPN Router 500: 2012091720/2012091800)

Dieses Firmware-Release ergänzt unseren Stable-Release vom 7. September, welcher eine große Zahl von Qualitäts-, Performance- und Stabilitätsverbesserungen für alle Viprinet-Produkte brachte, um zwei weitere Änderungen. Ein Update von der Vorgängerversion ist nur erforderlich, wenn diese Änderungen Sie betreffen.

Fehlerbehebungen

In allen bisherigen Releases gab es Stabilitätsprobleme mit dem Hot-Plugging von LTE-Modulen. Das Ziehen von LTE-Modulen oder ein Modulreset im Webinterface konnte zu einem Reboot des Routers führen. Das war besonders ärgerlich, da bei der noch recht instabilen LTE-Technologie der Provider die automatische Modul-Reset-Funktion eigentlich sehr hilfreich wäre. Das entsprechende Problem wurde nun behoben, auch LTE-Module sind nun voll hot-plugging-tauglich.
Mit der Verfügbarkeit des Hub 5010 wurde das Produkt nun als zum Hub 5000 kompatibel in der Firmware erfasst. Sollten Sie Hub 5010 und Hub 5000 gemischt nutzen im Hotspare-Betrieb, so müssen Sie die aktuelle Firmware einsetzen.

Firmware Release 07.09.2012 - Version 2012081500/2012090600 (Multichannel VPN Router 500: 2012082420/2012090600)

Dieser Firmware-Release bringt eine große Zahl von Qualitäts-, Performance- und Stabilitätsverbesserungen für alle Viprinet-Produkte. Inbesondere beim Multichannel VPN Router 500 sind die Verbesserungen äußerst erheblich. Wir empfehlen allen Kunden den Umstieg auf die aktuelle Firmware-Version.

Fehlerbehebungen

Der neue LossyBonding mode, der über die Streaming Optimizations Lizenz optional verfügbar ist, war in allen bisherigen Firmware-Releases fehlerhaft. In vielen Fällen kam es dazu, dass beim Empfänger Packet Reordering auftrat, was bei vielen Anwendungen für Probleme sorgte. LossyBonding bringt nun die erwartete Performance, und wird für alle Applikationen, bei denen zeitkritischer UDP-Traffic über instabile Bündelungen transportiert werden soll (z.B. Videokonferenzen über gebündeltes UMTS) empfohlen.
Unter bestimmten (seltenen) Umständen konnte es passieren, dass ein Stromverlust des Routers beim Speichern der Konfiguration zu Fehlern auf dem internen Flashspeicher führten. In diesen Fällen zeigte der Router nach dem nächsten Start als Seriennummer nur noch "XX-XXXXX-XXXXX" an, und war nicht mehr voll funktionsfähig.
Auf dem Multichannel VPN Router 500 konnte es passieren, dass plötzlich sämtliche Module "verschwanden" und nicht mehr nutzbar waren. Das Problem lies sich nicht mit einem Reboot, sondern nur mit Aus/Anschalten der Stromversorgung des Routers beheben.
Die NAT-Engine hatte Probleme mit diversen ICMP-Unterprotokollen. Das konnte dazu führen dass Traceroutes von genatteten IPs ausgehend teilweise nicht richtig funktioniert haben.
Die Broadcast-Detection wurde verbessert. Wenn bei früheren Firmwarereleases ein Router an einem LAN hing, in dem es ein IP-Netz gab welches aber an dem Router selber lokal nicht anlag, hat der Router Ethernet-Broadcasts dieser Netze ebenfalls empfangen und diese dann verwertet - mangels lokal anliegendem Netz konnte er dabei aber nicht wissen, dass das ein IP-Broadcast ist und hat es auf den Tunnel geschickt. Das hat u.a. zu PacketHeap-Fehlermeldungen im Log geführt.
Das interne Konfigurationssystem wurde um den Faktor 20 beschleunigt. Inbesondere bei Hub-Setup mit einer sehr hohen Zahl von VPN-Tunneln dauerte das Ändern von Einstellungen im Webinterface bisher sehr lange. Auch bei solchen Szenarien speichert das Konfigurationsystem entsprechende Änderungen nun viel schneller.
Die Firmware des Multichannel VPN Router 500 hatte einen Speicherleck-Fehler, der dazu führen konnte, dass dieser Router nach wenigen Tagen automatisch rebootete.
Der BondingTCPOptimizer Bündelungsmodus hatte einen Fehler, der äußerst selten (mit einer Wahrscheinlichkeit von 0.25^12%) auftreten konnte. In diesem Falle stürzte der Router ab und startete neu.
Im Hub-Redundanzsystem hat das Entfernen einer Test-IP nicht dafür gesorgt, dass diese IP tatsächlich nicht mehr gepingt worden wäre. Stattdessen wurde die IP bis zum nächsten Routerneustart weiter angepingt.
Traffic Accounting funktionierte auf dem Multichannel VPN Router 500 nicht richtig
Auf dem Multichannel VPN Hub 5000 funktionierten eingehende VPN Tunnel Channel Verbindungen nicht mehr zuverlässig, wenn bereits über 200 Tunnel Channel verbunden waren.
Diverse Bugfixes für die SNMP-Implementierung, insbesondere für Nutzer der erweiterten SNMP-Lizenz (AdminStatus gemäß MIB, Timestamp für Router Uptime)
Wenn mehrere Module gleichzeitig einen Power-Reset erhielten (z.B. bei entsprechendem automatischem Reset) konnte es passieren, dass bei einigen der Module der Strom nicht wieder angeschaltet wurde, und das Modul dann bis zum einem Neustart des Routers nicht mehr nutzbar war.

Verbesserungen

Der Hybrid-Autotuning-Modus wurde stark verbessert und hat diverse Fehlerkorrekturen erhalten. Die Nutzung vom Hybrid-Autotuning-Modus wird für alle Mobilfunkverbindungen dringend empfohlen, da gute Messergebnisse mit geringem Trafficverbrauch kombiniert werden. Auch der passive Autotuning Modus wurde verbessert.
Bei abgeschaltetem Latency-Autotuning ist die Dauer von Ping-Tests nun stark verkürzt. Bei manuell konfigurierten Latenzen für UMTS-basierte Channels kann dies bei sich schnell bewegenden Fahrzeugen für deutlich größere Nutzungszeiten für die sich ständig neu verbindenden Channels bewirken.
Die vom Router zu verwendende Timezone kann nun unter "Logging & Maintenance" konfiguriert werden
Die ARP-Implementation wertet jetzt auch aus dem LAN kommende IP-Pakete aus, um den Cache zu akualisieren. Dies sorgt dafür dass bei Geräten im LAN, die über längere Zeit nicht mehr aktiv waren bereits mit ihrem ersten Request nach außen dem Router wieder ihre MAC-Adresse mitteilen, wodurch bereits das erste Antwortpaket zugestellt werden kann. Dies bringt Vorteile in Zusammenhang mit einigen embedded TCP/IP stacks.

Firmwareupdate 19.06.2012 - Version 2012061200/2012061200 (für alle Produkte außer Multichannel VPN Hub 5000 und Multichannel VPN Router 500) bzw. 2012032610/2012061200 (für Multichannel VPN Hub 5000 und Multichannel VPN Router 500)

Dies ist ein Wartungsupdate für die Stable-Firmware, die am 13. April 2012 veröffentlicht wurde.

Dieses Update ist von hoher Bedeutung für Kunden, die SNMP-Monitoring mit unseren Routern nutzen, sowie für alle Kunden, die die „Passive“ und „Hybrid“ Autotuning-Modi nutzen (häufig mit UMTS verwendet). Diese Kunden sollten unverzüglich auf dieses Release updaten. Für alle übrigen Kunden wird ein baldiges Update empfohlen.

Fehlerbehebungen

Mit dem vorherigen Stable-Release bleiben SNMP-Counter alle 50 Tage stehen. Der nächste Zeitpunkt, an dem dies geschehen wird, ist der 20. Juni 2012. Wenn Sie von diesem Problem betroffen sind, sollten Sie daher schnellstmöglich updaten.
Hubs 5000 haben via SNMP fälschlicherweise immer eine CPU-Temperatur von 0°C angezeigt.
Im vorherigen Stable-Release war die experimentelle SSH-CLI auf Port 22 standartmäßig angeschaltet. Nun ist der Werkszustand, dass dieser Service ausgeschaltet ist, und Port 22 geschlossen.
Im vorherigen Stable-Firmware Release wurde eine Congestion Detection eingebaut, welche den MaxBandwidthToWAN-Wert eines Channels immer reduziert hat, wenn Packet Loss auf der Leitung erkannt wurde. Diese schnelle Reduzierung der Bandbreite hat das Latenzverhalten von Channeln auf instabilen WAN-Leitungen deutlich verbessert. Allerdings hat die Änderung gerade bei instabilen WAN-Leitungen auch dafür gesorgt, dass deutlich häufiger Bandbreitentests durchgeführt wurden. Dies wiederum hat dazu geführt, dass unser Stable-Release aus April im Vergleich zu früheren Firmware-Versionen deutlich mehr Datentraffic erzeugt hat für diese Tests. Dies wurde nun optimiert, die Menge des Testtraffics sollte wieder stark zurückgehen. Sollten Sie für Traffic viel Geld bezahlen (z.B. bei UMTS), sollten Sie schnellstmöglich updaten.
Der Treiber für unsere neuen Gigabit-Ethernet-Module hatte diverse Probleme. Wenn Sie eine statische IP-Konfiguration mit diesem Modul nutzten, konnte es sein, dass die Link-Detection nicht richtig funktionierte. Dieses Firmware-Release verbessert die Stabilität der Gigabit-Ethernet-Module ganz erheblich.
In allen vorangegangenen Firmware-Releases hatten die „Passive“ und „Hybrid“ Autotuning-Modi einen Bug, welcher dafür sorgen konnte, dass die Bandbreitenmessungen steckenblieben, wenn diese bei sehr niedrigen Geschwindigkeiten (200 KBit/s und darunter) starteten. In diesem Falle verblieb der Channel dauerhaft bei dieser niedrigen Geschwindigkeit. Dieses Problem konnte insbesondere beobachtet werden bei sich bewegenden Fahrzeugen, da hier häufig von UMTS zurück auf GPRS/EDGE geschaltet wird, welches sehr niedrige Bandbreiten erlaubt. Der Bug ist nun behoben, die „Passive“ und „Hybrid“ Autotuning-Modi funktionieren in diesen Situationen nun wie gewünscht. Sollten Sie diese Autotuning-Modi nutzen, sollten Sie unbedingt zeitnah auf die neue Firmware umsteigen.

Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmware-Stand zu halten.

Firmwareupdate 13.04.2012 - Version 2012032600/2012041000

Die neueste Firmware-Version für die Multichannel VPN Router und Multichannel VPN Hubs stellt nicht weniger als eine Revolution bzgl. Funktionalität dar. Das neue Release bietet eine Vielzahl an neuen Features, von denen viele von Partnern und Kunden gewünscht wurden. Zudem enthält diese Firmware zahlreiche Fehlerbehebungen, die für höhere Systemstabilität und höheren Durchsatz sorgen.

Änderungen im Vergleich zum vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101

LTE-Module werden nun unterstützt und sind stabil. Verschiedene Probleme, die im vorherigen Cutting-Edge Release bestanden, sind nun behoben, inkl. Schwierigkeiten beim Hot-Plugging, Monitoring und bei Modul-Info-Fehlern. Die Übergabe zwischen UMTS ↔ LTE scheint nun auch in Real-Life-Szenarios mit sich bewegenden Fahrzeugen zu funktionieren.
Module im Multichannel VPN Router 500 können nun auch konfiguriert werden, während sie im Zuge des Öffnens der SIM-Kartenhalters ausgeschaltet werden.
Im vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101 konnte es passieren, dass sich Verbindungen, die den BondingTCPOptimizer nutzen, beim Unterbrechen eines Channels aufhingen. Das ist behoben.
Aufgrund eines Problems mit SNMP-Encoding im vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101 bekam man manchmal falsche Werte für 64bit-Zähler.
Die Hub WAN Link Speed Detection, die als Parameter für Channel Autotuning genutzt wird, war defekt - sie erfasst nur die Geschwindigkeit, wenn das WAN keinen Ethernet-Link hatte. Daher berichteten Hubs immer nur 0 MBit/s.
Die Einstellung "Enabled Mobile Technologies" wurde für alle Modultypen angezeigt. Nun wird sie nur noch für LTE-Module angezeigt.

Änderungen im Vergleich zum letzten Stable Firmware-Release 2011020901/2011051700

Neue Features:

Erweitertes SNMP benutzt nun seine eigene, dedizierte Viprinet MIB. Um Erweiteres SNMP zu nutzen, brauchen Sie eine Lizenz für Erweitertes SNMP.
Ein Command Line Interface für Router kann nun über SSH auf Port 22 bezogen werden, wenn es vorher im Web Interface aktiviert wurde. Die Benutzernamen und Passwörter sind dieselben wie im Web Interface hinterlegt. Dies ist ein Beta-Feature; die CLI wird in kommenden Firmware-Releases verbessert werden.
Sie können nun die Konfiguration eines Routers downloaden, indem Sie SFTP/SCP nutzen.
Es ist jetzt möglich, die ARP-Tabelle von Ethernet-Geräten (LAN, WAN, WAN-Module) im Web-Interface einzusehen.
Gigabit Ethernet-Module werden jetzt unterstützt.
Für UMTS/HSPA-, UMTS/HSPA+-, CDMA- und LTE-Module gibt es nun im Web-Interface ein Tool, durch das manuell AT-Befehle eingegeben werden können. Dies kann zur Anpassung und Aktivierung benutzt werden, die in manchen Ländern / von manchen Mobilfunkanbietern gefordert wird.
Ethernet Auto Negotiation Parameter können nun für LAN-Interfaces, für WAN-Interfaces auf Hubs und für Ethernet-WAN-Module konfiguriert werden.
Wenn Sie eine Streaming-Optimierungs-Lizenz installiert haben, können Sie nun einen neuen Bündelungsmodus genannt "LossyBonding" nutzen. Dieser Modus ist optimiert, um UDP-Traffic zu bündeln. Im Gegensatz zu allen anderen Bündelungsmodi gewährleistet er keine verlustfreie Übertragung, daher kann es im gebündelten Tunnel zu Paketverlust kommen. Der Modus nutzt einen sich selbst optimierenden Dejitter-Buffer auf der Empfangsseite. Mit diesem Modus können extrem niedrige Latenzen mit minimalem Dejitter für kritischen UDP-Traffic und UDP-Anwendungen wie VoIP und Live-Videokonferenzen erreicht werden.

Verbesserungen:

Ein neuer Satz an verbesserten QoS-Regeln und -Klassen wird mit diesem Release ausgegeben. Um diese zu aktivieren, müssen Sie die "Restore Manufacturing Defaults"-Funktion innerhalb des "QoS rules and classes templates"-Objekts benutzen, und danach die "Copy QoS templates to here"-Funktion in jedem Tunnelobjekt, für das Sie die neuen QoS-Klassen nutzen möchten. Das zu tun wird sehr empfohlen. Seien Sie vorsichtig, wenn Sie eigene QoS-Klassen erstellt haben, denn diese werden beim Kopieren überschrieben.
Sich mit dem falschen Benutzernamen/Passwort per HTTP oder SSH einzuloggen verursacht nun eine zufällige Verzögerung, bevor ein Fehler ausgegeben wird. Das verlangsamt Brute-Force-Passwort-Attacken.
Das Log-Format wurde so verändert, dass nun immer der VPN-Tunnelname für Channel-Meldungen mitgeliefert wird. Bis jetzt war es unmöglich herauszufinden, auf welchen Tunnel sich eine Meldung bezog, wenn mehrere Tunnel denselben Channelnamen hatten (was auf mehrfach genutzten Hubs üblich ist).
Enorme Verbesserungen gibt es im Hinblick auf Buffer-Verwaltung und QoS. In Situationen, bei denen der Upstream durch Traffic komplett ausgelastet ist, ist das Ergebnis für Downstream-Traffic nun weitaus besser.
Zu Testzwecken können Prüfungen hinsichtlich Verbindungsstabilität nun ausgeschaltet werden, indem ein entsprechendes Setting im "Performance finetuning"-Objekt eines Channels genutzt wird.
Die Anzahl an durch Autotuning verursachten Logmeldungen wurde reduziert.
Große Autotuning-Verbesserungen gibt es für gebündelte 3G-Mobilfunkmedien in sich bewegenden Fahrzeugen. Channel reagieren nun viel schneller auf kurze Netzwerkabbrüche und bauen Channel auch viel schneller wieder auf. Infolgedessen hat sich die Performance von Viprinet-Routern in sich bewegenden Fahrzeugen mit dieser Firmware enorm verbessert.
Der BondingTCPOptimizer-Modus hatte Probleme mit vielen TCP-Implementierungen und -Anwendungen. Oft hing der BondingTCPOptimizer oder brach ganz ab, speziell bei SSL-basierten TCP-Verbindungen. Dies wurde um einiges verbessert. Wir empfehlen jetzt, den BondingTCPOptimizer für den gesamten TCP-Traffic zu verwenden, der über gebündelte Channel läuft, die hohe oder instabile Latenzen haben, z.B. Bündelungskombinationen von ADSL + UMTS.

Änderungen:

Wenn Remote-Serviceverbindungen aktiviert werden, um Viprinet-Supportmitarbeiter Remote-Zugang zu einem Router zu gewähren, wird nun Port 20022 genutzt (der in früheren Firmware-Releases genutzte Port 22 wird nun von der SSH-CLI genutzt). Bitte passen Sie Ihre Firewall-Regeln entsprechend an.

Fehlerbehebungen:

Mehrere Memory Leaks wurden behoben.
Wenn man 3 Channels hatte, von denen 2 als Backup konfiguriert waren, konnte es passieren, dass beim Ausfall des Nicht-Backup-Channels beide Backup-Channel gleichzeitig verbunden wurden. Das wiederum bewirkte, dass beide wieder getrennt wurden, da ja angeblich bereits ein Backup-Channel existierte.
Ping und Ethernet-Hilfsprogramme zeigten keine Fehlermeldungen im Web-Interface an, wenn der zu testende Hostname nicht per DNS aufgelöst werden konnte.
IP_IP- und IP_IPV6-Tunnel wurden nicht durch den VPN-Tunnel geroutet, sondern verworfen.
Bis jetzt konnten alle Router erst dann per Setup-Tool auf Werkseinstellungen zurückgesetzt werden, wenn alle Module aus dem Router entfernt worden waren. Das funktioniert bei all jenen Produkten nicht mehr, die einen Reset-Button haben, um auf Werkseinstellungen zurückzusetzen. Sie müssen diesen drücken, anstatt die Module zu entfernen.
Wenn man das 192.168.1.0/24-Netzwerk auf einem Router nutzte, funktionierten ADSL-Module nicht mehr korrekt (interner IP-Adress-Konflikt). Das ist behoben.
Unter Umständen sah der Hub 5000 seine eigenen Pakete, die er zum LAN gesandt hatte, und gab einen "Incoming Packet from.. has incorrect TCP checksum"-Fehlermeldung aus.
Ethernet-Broadcasts, die an ein IP-Alias-Netzwerk gerichtet waren, resultierten in einer Routing-Endlosschleife und brachten den Router zum Abstürzen, während jeglicher Traffic für mehrere Sekunden sichtbar war.
Die maximale Größe des Backups einer Konfigurationsdatei wurde erhöht auf 10 MB. Bis jetzt war es unmöglich, die Konfiguration bei Routerinstallationen mit einer Vielzahl an Tunneln zu sichern und wiederherzustellen.
Gratious ARP auf WAN-Interfaces litt unter einer Race Condition. Nach der Übernahme einer WAN-IP-Adresse konnte die Übergabezeit daher länger dauern, als für Hubs erwartet, da Upstream-Router nicht sofort über die neue MAC-Adresse der IP benachrichtigt wurden.
Die Einstellungen für garantierte Bandbreite innerhalb von QoS-Klassen haben bis jetzt nicht vollständig funktioniert. Die Klasse erhielt mehr oder minder die garantierte Bandbreite. Nun funktioniert das perfekt. Achtung: Wenn Sie eine QoS-Klasse konfiguriert haben, die eine Garantie hat, welche größer als die gesamte gebündelte WAN-Kapazität ist, bedeutet das, dass Ihre anderen QoS-Klassen möglicherweise keinen Traffic machen dürfen, wann immer die QoS-Klasse mit der garantierten Bandbreite die volle Kapazität des gebündelten Tunnels nutzt!
Wenn man eine QoS-Klasse kopierte, wurde die Minimum-Diversity-Einstellung nicht mitkopiert.
Wenn an einer Seite eines VPN-Tunnels Channel-Verschlüsselung aktiviert wurde, auf der anderen Seite aber nicht, war aus den Logmeldungen nicht ersichtlich, dass das eine Fehlkonfiguration ist. Stattdessen brach der Channel immer wieder ab. Nun gibt es eine Logmeldung, aus der der Fehler klar hervorgeht.
Den Reset-Knopf zu drücken funktionierte nicht bei Hubs, die sich im Hotspare-Modus befanden.
ADSL-Module gaben manchmal eine falsche Meldung über Bandbreitenkapazität / Synchronisationswerte aus.
Internal Early Retransmissions (einstellbar durch den Retransmission Multiplier in den Feineinstellungen für Channel) konnten zu einer "Kernschmelze" führen, wenn mehrere Verbindungen zur selben Zeit ausfielen (z.B. 3x ADSL desselben Anbieters, alle Leitungen zeigen gleichzeitig einen plötzlichen hohen Paketverlust aufgrund von Kabelinterferenzen). Das konnte dazu führen, dass keine Pakete übertragen werden konnten, weil alle Channels eine Retransmission versuchten über Channels, die ebenfalls Retransmission versuchten.
Es gab zahlreiche Fehlerbehebungen bzgl. SNMP-Protokoll-Konformität und -Kompatibilität.
SNMP nutzte ein gewisses Maß an CPU pro Tunnel, egal ob der Tunnel aktiv war oder nicht. Bei Hubs mit vielen Tunneln (50+) verursachte das hohe CPU-Load und daher schlechte Routing-Performance.
Auf dem Modell 500 gab es ein verstecktes Geister-WLAN ohne SSID zusätzlich zum konfigurierten WLAN. Das war kein sicherheitsrelevantes Problem, da man sich zu diesem WLAN nicht verbinden konnte, aber es war irritierend.
Auf dem Modell 500 funktionierte das Bridging zwischen LAN und WLAN nicht. Das ist nun behoben; Geräte auf dem LAN können WLAN-Geräte erkennen und umgekehrt.
Auf dem Modell 500 funktionierte das Wechseln des AP-Modus von 5 GHz zu 2.4 GHz und zurück nicht, bis man den Router neu startete.
Die LAN-IP-Konfiguration erlaubte CIDR-Notation, wodurch das Interface abstürzte.
Hybrides und passives Autotuning ignorierten das Abschalten des Autotunings.
Es gab zahlreiche Probleme im Hinblick auf Stabilität und Durchsatz, wenn man die Channel-Verschlüsselung auf dem Hub 5000 abschaltete. Auf dem Modell 500 bewirkte das Abschalten der Channel-Verschlüsselung, dass der Channel abbrach.
Auf dem Hub 5000 war die maximale Anzahl von Tunnelchannel auf 200 begrenzt. Diese Beschränkung wurde beseitigt.

Bekannte Beschränkungen:

Hub 5000 / SNMP: OID for CPULoad gibt "" auf Hub 5000 aus.
Hub 5000 / SNMP: Zähler für Tunnelchannel noch nicht implementiert (OID: 1.3.6.1.4.1.35424.1.6.2.1.9 and 1.3.6.1.4.1.35424.1.6.2.1.10)
Hub 5000: Ethernet Auto Negotiation Parameter können nicht verändert werden.

Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

Firmwareupdate 22.07.2011 – Version 2011020901/2011062701

Dies ist ein Update zu unserem Firmwarerelease vom 11.05.2011 (Multichannel VPN Hub 1000: 16.05.2011).

Dieses Update kann für Kunden von hoher Bedeutung sein, wenn Setups existieren, bei denen Kanäle mit hoher maximaler Bandbreite (z.B. Kabelanschluss, VDSL) gebündelt werden, und diese Kanäle im Up- und Downstream gleichzeitig voll ausgenutzt werden. Die im Mai veröffentlichten Firmwareversionen können bei solchen Setups die Performance verschlechtert haben - die Latenz der Channels konnte deutlich höher sein als in früheren Firmwareversionen, was wiederum für einen eingeschränkten Durchsatz bei den Tunneln, die diese Channel verwenden, sorgen konnte. Dies wurde optimiert, die Latenzen von Tunnel Channels sind nun auch in solchen Fällen wieder deutlich stabiler.

Die übrigen Änderungen an dieser Firmware sind Kleinigkeiten. Diese Firmwareversion wurde von uns lange und intensiv getestet, und wird für die nächsten Monate stabil sein. Wir empfehlen ein Update daher für alle Kunden.

Fehlerbehebungen

Das interne Socket Buffer Tuning der Tunnelkanäle wurde im Mai-Release verändert, mit den oben genannten Konsequenzen. Dies wurde nun optimiert, das Socket Buffer Tuning baut nicht länger auf den "Maximum Bandwidth to WAN"-Wert, sondern richtet sich immer aktuell nach dem "Current Bandwidth to WAN"-Wert. Dies sorgt für eine optimierte Latenz bei Channels mit hoher Maximalbandbreite.
Die Logmeldung eines VPN Hub im Hotspare-Modus mit Bezug auf Paketverlust-Vergleichen war fehlerhaft. Statt einer Prozentangabe für den Paketverlust wurde die IP-Adresse ausgegeben. Dies wurde korrigiert.
Wenn unsere Traffic Accounting API mit einem VPN Hub mit einer großen Zahl konfigurierter VPN Tunnel genutzt wurde, konnte im Log die Meldung "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" erscheinen, damit konnten Traffic Accounting-Einträge verloren gehen. Dies wurde behoben, wir unterstützen nun ein deutlich größeres Backlog.
Die Logmeldung "Unable to submit traffic accounting data to server with URL..." gibt nun tatsächlich eine URL aus. Dies hilft beim Debugging eigener serverseitiger Implementierungen unserer API.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

Firmwareupdate 16.05.2011 – Version 2011020901/2011051700

Dies ist ein dringendes Update zu unserem Firmwarerelease vom 11.05.2011 für den Multichannel VPN Hub 1000. Andere Produkte sind nicht betroffen.

Wir müssen Ihnen mitteilen, dass aufgrund eines Problems in unserem Release- und Zertifizierungssystem ein schwerwiegender Fehler in das Firmwareimage für den Multichannel VPN Hub 1000 gelangt ist: In diesem Firmwareimage war die Hardwarebeschleunigung für die AES-Verschlüsselung des Hubs abgeschaltet. Ein Multichannel VPN Hub 1000, der die Firmwareversion 2011020901/2011051001 nutzt, zeigt damit eine sehr schlechte Performance bei Nutzung mit verschlüsselten VPN-Tunnel-Channeln (was als default eingestellt ist).

Sollten Sie bereits vergangene Woche Ihren Multichannel VPN Hub 1000 auf die Firmware 2011020901/2011051001 aktualisiert haben, so führen Sie bitte schnellstmöglich ein weiteres Update auf die neue Version 2011020901/2011051700 durch. Diese Version behebt das Problem, weitere Änderungen gibt es nicht.

Für alle anderen Produkte gilt, dass diese von diesem Fehler nicht betroffen sind – für sie ist die Firmwareversion 2011020901/2011051001 weiter aktuell. Die Releases 2011020901/2011051001 und 2011020901/2011051700 sind 100% kompatibel zueinander.

Wir möchten uns zutiefst dafür entschuldigen, dass es zu dieser Panne kommen konnte. Wir haben Maßnahmen in die Wege geleitet, unser Release- und Testsystem zu erweitern, um zu verhindern, dass solch ein Fehler in Zukunft nochmals passieren kann.

Firmwareupdate 11.05.2011 – Version 2011020901/2011051001

Die neue Firmwareversion bringt nochmals einige Fehlerbehebungen und Verbesserungen zu unserem Major Release vom 2. Dezember 2010. Sollten Sie den "BondingTCPOptimizer"-Bündelungsmodus nutzen, so ist dies ein kritisches Firmwareupdate.

Dieses Wartungsrelease ist dazu gedacht, unseren Kunden für lange Zeit eine hochstabile Firmwareversion anzubieten, daher sind keine neuen Features enthalten. Wir empfehlen allen Kunden, auf diese aktuelle Firmwareversion umzustellen.

Liste der Verbesserungen und Fixes:

Behoben: Kürzlich hat ein Dritthersteller ein Produkt auf den Markt gebracht, welches einen kaputten TCP/IP-Stack enthält. Dieser TCP/IP-Stack sendet gelegentlich kaputte TCP-Pakete. Leider ist unser BondingTCPOptimizer für diesen Fehler anfällig - entsprechende Pakete können den Bündelungsmodus in eine Endlosschleife schicken, was letztendlich zum Ausfall des Routers führt. Sollten Sie den BondingTCPOptimizer nutzen, ist dies ein kritisches Problem. Das Problem wurde behoben, der BondingTCPOptimizer ist nun sehr robust gegen alle bekannten Attacken gegen das TCP-Protokoll.
Behoben: Die neuen Channel Autotuning-Modes "Hybrid" und "Passive" betrieben weiter Autotuning, auch wenn dieses für den Channel abgeschaltet war.
Behoben: Unter seltenen Bedingungen (insbesondere beim VPN Client) konnte es vorkommen, dass das Bandbreiten-Autotuning ein negatives Bandbreitenergebnis lieferte.
Behoben: Es gab eine sehr hohe Last an ARP-Paketen auf dem LAN-Interface. In vielen Setups wurden deutlich mehr ARP-Pakete durch den Router versendet, als eigentlich nötig gewesen wäre.
Verbesserung: Die Performance und Latenz von Channeln, die unter Volllast stehen, wurde verbessert, dies betrifft insbesondere Channel mit einer Bandbreite von <500 KBit/s.
Verbesserung: Die Monitoring API wurde auf die neue Version v3 aktualisiert. Wenn Sie das aktuelle Monitoring-Tool von unserer Website verwenden, können Sie in diesem nun neben Informationen zu den Channeln auch Zusammenfassungen für den gesamten Tunnel sehen. Die bisherige Monitoring-Version v2 wird weiter unterstützt, entsprechende alte Tools funktionieren also weiterhin.
Verbesserung: Eine zusammenfassende Information zu Bandbreiten ist nun Teil des Tunnel-Objekts im Webinterface.
Behoben: Das Webinterface hat manchmal einen "Internal Error" geloggt.

Firmwareupdate 25.02.2011 – Version 2011010901/2011022500

Die neue Firmwareversion bringt zahlreiche Fehlerbehebungen und Verbesserungen zu unserem major release vom 2. Dezember 2010. Enthalten sind Bugfixes für durch Kunden reportete Fehler, allgemeine Performanceverbesserungen sowie erhebliche neue Features für Nutzer der "Streaming Optimizations"-Lizenz. Für Einsatzszenarien, bei denen über sehr instabile WAN-Verbindungen (z.B. UMTS unter Bewegung) stabile Bandbreiten und Latenzen erreicht werden sollen, gibt es enorme Verbesserungen.

Solange Sie nicht von einem der gefixten Bugs betroffen sind, ist es nicht kritisch sofort auf dieses Update umzustellen. Wegen der zahlreichen Verbesserungen empfiehlt es sich trotzdem für alle Kunden, bald auf diesen Firmware-Release umzustellen.

Liste der Verbesserungen, neuen Features und Fixes:

Verbesserung: Verbesserte Performance für High-Bandwidth setups. Für Nodes und Hubs die mit hoher Bandbreitenlast (>50 MBit/s) arbeiten konnte es vorkommen dass der integrierte LAN-NIC unter Umständen einen geringen Packet Loss im LAN verursachte. Dies wiederum konnte vor allem bei WAN-Strecken mit hoher Latenz für eine Beschränkung des maximal real durch den Tunnel zu realisierenden Durchsatz bedeuten. Das Problem wurde behoben, Packet Loss am LAN-Interface sollte (abgesehen von echten Störungen im LAN) nun nicht mehr auftreten.
Verbesserung: In früheren Releases konnte der vom "Bandwidth Autotuning" erzeugte Datenverkehr die für realen Nutztraffic vorhandene Bandbreite stark limitieren - der Autotuning-Traffic "frass" quasi die Bandreite weg. Jedes Mal wenn ein Channel ein "Bandwidth Autotuning" durchführte, sank dadurch der nutzbare Gesamtdurchsatz des Tunnels. Dies war insbesondere ein Problem, wenn sich im WAN-Bündelungsverbund ein oder mehrere instabile WAN-Links befanden, die sehr häufig Autotuning-Tests erfordern. In der Praxis konnte es so passieren, dass eine Bündelung z.B. aus 2x ADSL und 1x UMTS weniger Durchsatz brachte als 2x ADSL alleine. Das Verfahren hierzu wurde komplett verändert. Mit dieser Firmwareversion wird Autotuning-Traffic nun immer nur die Bandbreite nutzen, die aktuell nicht von realem Traffic gebraucht werden könnte. Autotuning-Traffic beeinflusst damit nun nicht länger die real nutzbare Bandbreite. In Szenarien wo eine oder mehrere WAN-Anbindung instabil sind, wird sich die Performance in der Praxis erheblich verbessern und die nutzbaren Bandbreiten stabiler sein als je zuvor.
Neues Feature: Wenn ein Channel zusammenbrach, war es bisher so, dass Nutztraffic der in der Bündlung diesen Channel mitnutzte stockte, bis der Channel in den Status "ConnectedStalled" wechselte. Dies lag daran, dass eine interne Retransmission erst ausgelöst wurde, wenn der Channel den Status "ConnectedStalled" hat - je nach Ergebnis des Latency Autotunings konnten so bei Channelabbrüchen Aussetzer von bis zu 1500ms im realen Nutztraffic entstehen. Zusätzlich hierzu kann der Router nun bereits vorab spekulativ Retransmissions durchführen, bevor der Channel in den "ConnectedStalled"-Status gewechselt hat. Per default wird nun eine Retransmission ausgelöst, wenn der Channel aktuell die vierfache Latenz des "Optimal Latency"-Wertes hat. In der Praxis reduzieren sich damit die Aussetzer beim Wegfall eines Channels erheblich. Der Multiplikator für diese Retransmission ist konfigurierbar. Die Einstellung dazu findet sich unter "Performance finetuning" im Channel Objekt.
Neues Feature: Für alle channels und tunnels werde nun interner Statistiken zur Stabilität geführt. Hier fließt ein, wie oft der Channel bzw Tunnel in letzter Zeit disconnected war, wie oft ein Channel in den "ConnectedStalled" status gewechselt hat, und wie häufig und wie intensiv Paketverluste aufgetreten sind. Der Stabilitätswert wird sowohl im Monitoring-Tool als auch im Webinterface angezeigt.
Neues Feature: Der BondingDiversity bonding modus wurde dramatisch verbessert. Mit bisherigen Firmwareversionen wurden immer, egal wie stabil oder instabil die Channel waren, so viele Diversity-Kopien jedes Paketes versandt, wie noch Bandbreite auf den Channeln verfügbar war - in vielen Fällen wurde als jedes Paket über jeden Channel geschickt (5 Kopien). Das bedeutete eine Menge zusätzlichen Traffic, was inbesondere bei teuren UTMS-Kanälen ein Problem darstellte. Der mit dieser Firmwareversion deutlich verbesserte BondingDiversity-Modus ändert dieses Verhalten: Es gib nun eine "Minimum diversity" sowie eine "Maximum Diversity" Einstellung, wodurch sich festlegen lässt, wieviele Kopien eines Paketes Minimal und Maximal versendet werden sollen. Der tatsächlich genutzte Wert wird dabei automatisch zwischen diesen Grenzen festgelegt. Hierbei wird berücksichtigt, wie stabil die genutzten Channels aktuell sind. Sind die Channels instabil (z.B. in einem bewegten Fahrzeug unter Nutzung von UMTS), werden mehr Kopien versandt, sind die Channels stabil, weniger. Wir empfehlen den BondingDiversity mode nun nachdrücklich für jede Art von Applikation, bei der über sehr instabile WAN-Links eine stabile Latenz und Bandbreite erreicht werden soll (z.B. Streams, VoIP, Could Computing). Die Nutzung des "BondingDiversity"-Modes erfordert eine "Streaming Optimizations" Lizenz pro Router, welche Sie auch nachträglich erwerben können.
Feature entfernt: Der "Bestchannel" bonding modus wurde entfernt - er war in allen Einsatzszenarien dem "Bonding"-Modus weit unterlegen und seit langer Zeit schon nicht mehr zur Nutzung empfohlen. Die QoS-Einstellung "Latency Priority", die nur für diesen Modus Anwendung fand, wurde ebenfalls entfernt.
Feature entfernt: Die "Minimize AutotuningTraffic" option wurde entfernt. Wenn Traffickosten für einen Channel wichtig sind, verwenden Sie bitte stattdessen den "Hybrid" (empfohlen) oder "Passive" (wenn jedes Byte zählt) modus, welche beide deutlich bessere Ergebnisse bringen.
Verbesserung: Die Dokumentation der "Channel Finetuning" Einstelllungen im Web interface wurde deutlich ausgeweitet, es sollte nun deutlich klarer sein welche der Einstellungen ggf. stark negative Auswirkungen haben können.
Verbesserung: Hubs die das Hub Redundanzsystme nutzen, starten nun deutlich schneller. Im Bereich des Redundanzsystems wurden zudem zahlreiche kleinere Fehler behoben, die Zuverlässigkeit des Systems wurde deutlich erhöht.
Neues Feature: Innerhalb des Tunnel Objekts existieren nun Statistiken über die aktuell insgesamt für diesen Tunnel nutzbare Up- und Downstreambandbreite. Zudem gibt es einen Satz Statistiken zur dauerhaft als stabil anzusehenden Bandbreite. Diese wird dadurch ermittelt, dass die verfügbare Up- und Downstreambandbreiten von instabilen Channeln nicht mitgezählt werden. Für diese Statistiken werden wir in Kürze auch eine API zur Fernabfrage anbieten, welche z.B. für Hersteller von Videocodecs genutzt werden kann, um die Streambandbreite dynamisch anzupassen. Bitte kontaktieren Sie unser Supportteam bei Interesse an dieser API.
Fixed: Nach einem Powercycle konnte es vorkommen, dass ADSL-Module nicht korrekt erkannt wurden. In diesem Falle wurde der jeweilige Slot im Webinterface als leer angezeigt. Das Problem wurde behoben, ADSL-Module sollten nun immer erkannt werden.
Fixed: Das Traceroute tool im Webinterface hat nicht korrekt für das LAN interface funktioniert.
Fixed: Ein sehr selten auftretender Bug konnte theoretisch für Reboots des Routers sorgen.
Fixed: Die Kombination aus einem Port Forwarding am Hub, welches auf einen Host hinter einem VPN Node verwies mit der Nutzung von LAN aliases oder VLANs am Node konnte zu Problemen bei der Erreichbarkeit der Hosts hinter dem Port Forwarding führen. Der Router sendete in diesem Fall inkorrekte "ICMP Redirect" Pakete.
Fixed: Die ARP Implementierung für das LAN-Interface von Hubs und Nodes hatte diverse Probleme. Wenn eine IP innerhalb des LANs von einem PC zu einem anderen übertragen wurde (sich also die MAC-Adresse der IP änderte), konnte es passieren dass diese IP anschließend durch den Node nicht mehr erreichbar war. Dieses und weitere Probleme in Bezug auf den ARP Cache wurden behoben.
Fixed: Statische DHCP Einträge funktionierten nicht, wenn mehr als ein statischer DHCP-Eintrag angelegt wurde.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

Firmwareupdate 10.01.2011 – Version 2011010401/2011011003

Dieser zweite Nachtrags-Release zu unserem großen Firmwarerelease vom 2.Dezember beseitigt eine Reihe von Fehlern. Dieses Update behebt zudem ein wichtiges Problem mit dem Firmwarerelease vom 29. Dezember. Wir empfehlen allen Kunden, baldmöglichst auf die neue Firmware-Version zu aktualisieren. Dieses Update führt zudem neue Features rund um DHCP ein - so ist es nun beispielsweise möglich, statische Einträge für DHCP Leases anzulegen.

Hier die Änderungen im Einzelnen:

Fixed: Die Releases vom 2. und 29. Dezember enthielten beide einen kritischen Memory Leak Fehler. Router unter hoher Last (mehrere tausend gleichzeitige Verbindungen durch den VPN Tunnel) konnten nach Tagen oder Wochen des Betriebes dadurch Fehlverhalten zeigen oder rebooten. Dieses Problem ist nun behoben.
Fixed: Der Release vom 29. Dezember gibt den vollen VPN Tunnel setup Dialog in das logfile aus. Für Verbindungen von VPN Nodes mit einer Firmware von vor Dezember 2010 sowie für Verbindungen von VPN Clients bedeutet das, dass das geheime Tunnel-Passwort im Klartext im Logfile zu lesen ist, was natürlich ein Sicherheitsproblem darstellt. Das Problem wurde behoben, der Dialog wird nicht länger gelogged.
Fixed: VPN Hubs haben auf ICMP pings auf ihrem LAN-Interface mit mehreren ICMP-Replys geantwortet (mit Windows ping nicht sichtbar).
Neues Feature: Es ist nun möglich statische DHCP leases auf VPN Nodes zu konfigurieren.
Neues Feature: Es ist nun möglich sich auf VPN Nodes die aktuelle DHCP lease table anzeigen zu lassen.
Neues Feature: Die DHCP lease time ist nun konfigurierbar.
Fixed: Das VPN Hub Redundanz-System hatte eine ganze Reihe von Problemen und Bugs. Das System ist nun auch bei einer hohen Anzahl von VPN Hubs und in mehr Ausfallszenarien sehr viel stabiler als zuvor.
Fixed: VPN Hubs im "Hotspare"-Modus konnten keine DNS-Auflösung vornehmen, damit war auch ein Online-Firmwareupdate von "Hotspare"-Routern unmöglich.
Fixed: Alle Datei-Uploaddialoge (QoS Config restore, config restore, firmware upload) ließen den Upload beliebig großer Dateien zu, was im schlimmsten Falle zum Reboot des Routers führen konnte. Unsinnige Dateigrößen werden nun abgefangen.
Verbesserung: Die SSL Fehlermeldungen im Logfile sind jetzt klarer zu verstehen als zuvor.
Fixed: Das Download test tool hatte mehrere kleine Probleme. Insbesondere bei Verbindungen zur HTTP Servern, die "Chunked Encoding" nutzen, waren die Messergebnisse falsch. Das Download test tool bricht jetzt automatisch ab, wenn durch dessen Nutzung die CPU-Last des Routers so hoch wird, dass die Performance der VPN Tunnel beinträchtigt werden würde (wodurch die Messergebnisse ohnehin unbrauchbar würden).
Fixed: Die neuen Autotuning modi "Hybrid" und "Heuristic" hatten nach längerer Betriebsdauer u.U. Probleme. Dies konnte zu Messergebnissen von 0/0 KBit/s Up-/Downstream oder auch zu "Internal Errors" im Logfile führen.
Fixed: Es war möglich eine gesicherte Konfigurationsdatei auf einen Router hochzuladen, der mit dieser Konfigurationsdatei gar nicht kompatibel war. Das Problem ist nun behoben. Die folgenden Produkte sind zueinander bzgl. Konfigurationsfiles kompatibel: Multichannel VPN Hub 1000/2000/5000, Multichannel VPN Router 1600/1610/2610. Die Konfiguration des Multichannel VPN Router 300 ist mit keinem anderen Produkt kompatibel.
Fixed: VLANs zur Verwendung von VDSL-Modems an Ethernet-Modulen funktionierten nicht richtig.

Firmwareupdate 29.12.2010 – Version 2010112901/2010122800

Dieser Nachtrags-Release zu unserem großen Firmwarerelease vom 2.Dezember beseitigt eine Reihe von kleineren Fehlern. Für viele Kunden ist dies ein nicht-kritisches Update. Sollten Sie jedoch auf Ihren Routern SNMP oder den BondingTCPOptimizer Modus in Ihren QoS-Klassen nutzen oder künftig das DHCP relay feature nutzen wollen, empfehlen wir Ihnen dringend ein rasches Update.

Folgende Punkte wurden im Einzelnen repariert:

Neues Feature: Die Router unterstützen nun die neuen CDMA/EV-DO module, welche für Kunden in Nordamerika verfügbar sind.
Der SNMP Service hatte im Betrieb Probleme mit einer fehlerhaften SNMP Anfrage. Diese konnten zu einer Betriebsverweigerung führen. Dies ist nun beseitigt.
Falls DHCP als DHCP relay konfiguriert worden ist, wurde dieser Service nach einem Reboot nicht mehr automatisch gestartet. DHCP Relay musste hingegen manuell im Webinterface neu gestartet werden. Dies ist nun beseitigt, auch nach einem Neustart wird DHCP relay automatisch starten.
Eine Vielzahl von HTTP/HTTPS Attacken auf das Webinterface führten zu internen Fehlermeldungen in den Logs. Diese waren und sind unkritisch. Die Zahl an Attacken, die potenziell diese Fehlermeldungen auslösen können, wurde verringert.
Die neue "Heuristic" Autotuning Methode konnte bei Verwendung instabiler Links zu internen Fehlern führen. Diese internen Fehler konnten potenziell zu verringerter Performance oder, im schlimmsten Falle, zu nicht erreichbaren VPN Nodes führen. Dieser Fall ist nun beseitigt.
Fehlermeldungen zu SSL Verbindungen werden künftig deutlicher machen ob sie VPN Tunnelverbindungen oder Webinterface-Verbindungen zuzuordnen sind.
Eine Reihe von "Debug" Log-Meldungen wurden beseitigt.

Firmware update 12/02/2010 - Version 2010112901/2010120203

The latest firmware version for the Multichannel VPN Routers and Multichannel VPN Hubs constitutes no less than a revolution of functionality. The new release offers a vast number of new features, many of which have been desperately requested by partners and customers. Moreover, the firmware contains a number of bugfixes that provide higher system stability.

New features:

Huge performance increase: Compared to previous releases, the total bonded VPN throughput a router/hub can do has increased by about 30%.
User rights management system in AdminDesk - you now may create groups and users who only have read/write rights for certain objects. This can be used to enable customer access to their tunnel's settings only.
VPN Hub: You now may create port forwardings mapping destination IPs at the VPN Hub to private IPs behind VPN Tunnels
WAN VLAN Support: The Ethernet WAN modules now can use VLAN tagging. This is useful e.g. for external VDSL modems that require tagged Ethernet frames
VPN Hub: LAN/LAN alias VLAN support. You now may use multiple VLANs at the LAN interface of a VPN Hub. The main IP configured in LAN Settings always will be sent untagged (VLAN0) and serves as access to the public internet. Traffic going there from the Tunnels matching a NAT rule will be NATted. In addition, LAN aliases may use tagged VLANs. This way it becomes possible to have dedicated networks
"Tunnel segmentation" - similar to VLANs, you may group multiple tunnels by assigning them the same tunnel segmentation ID. Internally, all tunnels with a different segmentation ID are completely separate. This makes it possible to have multiple customers with multiple sites each terminated on one VPN Hub, where all sites per customer can see each other, but customers can't see other customer's networks. It is even possible to have multiple customers use the same private IP network - e.g. two customers that both use 10.0.0.0/8. If the tunnel segmentation ID chosen is the same as a VLAN ID assigned on a LAN interface, then traffic from all tunnels with this ID may exchange traffic with these VLANs, with all other customers not being able to reach the VLAN. Using this in combination with a VLAN-enabled switch at t

Firmware Classic Stable

Classic Stable Firmware Release 27. November 2015 – Version 2015081830/2015102900

Neue Funktionen

Fehlerbehebungen

Classic Stable Firmware Release 25. Februar 2015 – Version 2014110730/2015021100

Neue Funktionen

Fehlerbehebungen

Classic Stable Firmware Release 2. Oktober 2014 – Version 2014093030/2014100200

Fehlerbehebungen:

Classic Stable Firmware Release 18. August 2014 – Version 2014061630/2014080100

Liste der Veränderungen im Vergleich zur vorherigen Stable Firmware-Version

Neue Funktionen

Fehlerbehebungen

Classic Stable Firmware Release 6. März 2014 – Version 2014021430/2014022500

Neue Funktionen

Fehlerbehebungen

Classic Stable Firmware Release 12. August 2013 – ­Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)

Verbesserungen

Fehlerbehebungen

Classic Stable Firmware-Release 24. Juni 2013 – Version 2013051031/2013062100

Fehlerbehebungen

Classic Stable Firmware Release 11. Juni 2013 - Version 2013060730/2013061001

Classic Stable Firmware-Release 10. Juni 2013 – Version 2013051031/2013061001

Verbesserungen

Classic Stable Firmware-Release 6. Juni 2013 – Version 2013051031/2013060600

Verbesserungen

Fehlerbehebungen

Firmware Release 6. Februar 2013 - Version 2013012301/2013020600 (Multichannel VPN Router 500: 2012112320/2013020600)

Verbesserungen

Fehlerbehebungen

Firmware Release 10. Dezember 2012 - Version 2012091701/2012121005 (Multichannel VPN Router 500: 2012112320/2012121005)

Verbesserungen

Fehlerbehebungen

Firmware Release 25.09.2012 - Version 2012091701/2012091800 (Multichannel VPN Router 500: 2012091720/2012091800)

Fehlerbehebungen

Firmware Release 07.09.2012 - Version 2012081500/2012090600 (Multichannel VPN Router 500: 2012082420/2012090600)

Fehlerbehebungen

Verbesserungen

Firmwareupdate 19.06.2012 - Version 2012061200/2012061200 (für alle Produkte außer Multichannel VPN Hub 5000 und Multichannel VPN Router 500) bzw. 2012032610/2012061200 (für Multichannel VPN Hub 5000 und Multichannel VPN Router 500)

Fehlerbehebungen

Firmwareupdate 13.04.2012 - Version 2012032600/2012041000

Änderungen im Vergleich zum vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101

Änderungen im Vergleich zum letzten Stable Firmware-Release 2011020901/2011051700

Neue Features:

Verbesserungen:

Änderungen:

Fehlerbehebungen:

Bekannte Beschränkungen:

Firmwareupdate 22.07.2011 – Version 2011020901/2011062701

Fehlerbehebungen

Firmwareupdate 16.05.2011 – Version 2011020901/2011051700

Firmwareupdate 11.05.2011 – Version 2011020901/2011051001

Liste der Verbesserungen und Fixes:

Firmwareupdate 25.02.2011 – Version 2011010901/2011022500

Liste der Verbesserungen, neuen Features und Fixes:

Firmwareupdate 10.01.2011 – Version 2011010401/2011011003

Hier die Änderungen im Einzelnen:

Firmwareupdate 29.12.2010 – Version 2010112901/2010122800

Folgende Punkte wurden im Einzelnen repariert:

Firmware update 12/02/2010 - Version 2010112901/2010120203

New features:

Classic Stable Firmware Release 12. August 2013 – Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)