Firmware Release Notes

Unser Entwicklungsteam ist kontinuierlich bemüht, unsere Produkte zu verbessern. Für unsere Router erscheinen daher regelmäßig Firmwareupdates, die nicht nur Fehler beheben und die Produktqualität verbessern, sondern oft auch zusätzliche, neue Features enthalten. Bei der Entwicklung neuer Produktfeatures richten wir uns dabei stark nach Kundenfeedback.

"Classic" vs. "RuggedVPN"

Viprinet bietet aktuell noch zwei Generationen von Firmware antwicklungszweige bzgl. seiner Firmware an. Die "Classic" Firmware existiert seit 2007 und wurde bis 2015 weiterentwickelt. Es ist eine sehr ausgereifte Firmware, aber mit der Ausreifung kommt bekanntlich auch das Alter. Die Firmware sollte nur noch in Bestandsinstallationen genutzt werden, und auch dort wird es langsam Zeit für ein Upgrade.

Die "RuggedVPN"-Firmware hingegen existiert seit 2015. Mittlerweile ist aber auch diese Firmwaregeneration sehr stabil. Hier gibt es auch laufend neue Features. Diese Firmware sollte für alle neuen Installationen verwendet werden.

Online Update

Unsere Router enthalten im Web-Interface unter [ AdminDesk ] [ Logging & Maintenance ] [Router Firmware Update] die Möglichkeit, ein bequemes Online-Update eines "Stable"-Firmware-Releases durchzuführen. Hier kann automatisch geprüft werden, ob für das Routermodell ein Firmware-Update vorliegt, dieses ggf. heruntergeladen und installiert werden. Es kann auch konfiguriert werden, dass Firmware-Updates ohne Zutun des Administrators bei Verfügbarkeit heruntergeladen werden. Die Installation sollte aus Sicherheitsgründen aber immer in Anwesenheit eines Administrators durchgeführt werden. Das Online Update ist sowohl für die Classic- als auch die RuggedVPN-Firmwaregenerationen verfügbar. In der Classic-Firmware existiert eine gesonderte Option, um den Router auf RuggedVPN upzugraden.

Offline update

Als Alternative zum Online-Update steht auch ein Offline-Update zur Verfügung. Zusätzlich zu den stabilen Firmware-Releases gibt es auch von Zeit zu Zeit "Cutting edge"-Firmware Releases, welche neue Features schnell zu unseren Kunden bringen, die diese benötigen. Diese Updates sind dann nur Offline-Update verfügbar. Um ein Offline-Update durchzuführen, müssen Sie das für Ihr Routermodell bestimmte Firmware-Image herunterladen und dann über die entsprechende manuelle Updatefunktion im Web-Interface des Routers hochladen und installieren. Beide Firmware-Images, "Cutting Edge" und "Stable", sind auf unserem Update-Server verfügbar.

Sollten Sie Hilfe beim Firmware-Update benötigen, so wenden Sie sich bitte vertrauensvoll an unseren Support.

Viprinet Lifetime Maintenance

Die Nutzung der RuggedVPN Firmware erfordert einen laufenden "Viprinet Lifetime Maintenance"-Vertrag. Die alte "Classic"-Firmware ist hingegen noch ohne einen solchen Wartungsvertrag verfügbar. Supportunterstützung hingegen erfordert in jedem Falle einen VLM-Vertrag. In andren Worten: Ohne VLM können Sie zwar gerne die Classic-Firmware installieren, sind dann aber ohne Support und Garantie auf sich alleine gestellt. Erwähnten wir, dass Sie stattdessen lieber RuggedVPN haben wollen?

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.

RuggedVPN Stable Firmware Release 20. Juni 2016 - Version 2016040640/2016061000

Dies ist der empfohlene offizielle zweite stabile Release der RuggedVPN Firmware, welche seit über einem Jahr in Entwicklung war. Wir empfehlen allen Kunden, die noch "Classic"-Firmware verwenden, nun auf diese Firmware umzusteigen.

Sollten Sie von einer älteren Classic-Firmware umsteigen wollen, müssen Sie zunächst Ihren Router auf die letzte Classic-Firmware (Version 2015081830/2015102900, veröffentlicht am 27. November 2015) aktualisieren. Anschließend steht das Upgrade auf RuggedVPN zur Verfügung. Bitte beachten Sie dass ein Upgrade der Firmware von Classic zu RuggedVPN eine aktivierte und installlierte Viprinet Lifetime Maintenance Lizenz erfordert. Weitere Informationen hierzu erhalten Sie unter https://www.viprinet.com/vlm.

Router und Hubs, die noch Classic firmware verwenden, können zu Routern und Hubs, die RuggedVPN firmware verwenden, verbinden. Allerdings wird in diesem Falle ein Kompatibilitätsmodus verwendet, der den "kleinsten gemeinsamen Nenner" verwendet und daher keine gute Performanz oder Features liefert. Ein solches Setup sollte also nicht dauerhaft, sondern nur während einer Migrationsphase verwendet werden. Der Software VPN Client verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatiblitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur ersten RuggedVPN Firmware (Version 2016040640/2016040300 veröffentlicht am 7. April 2016)Version 2015081830/2015102900 veröffentlicht am 27. November 2015).

Neue Funktionen

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

Fehlerbehebungen

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