• Standard Congestion Control ist nun Cubic, standardmäßiges Autotuning Hybrid. Es gab signifikante Verbesserungen zum Hybrid Autotuning-Modus.
• Volle Unterstützung für die finale Version der VDSL-Module.
• Ab jetzt wird eine neue HTTPS-Zertifizierungsstellen-Datenbank verwendet, die Unterstützung für diverse Zertifizierungsstellen, nach denen Kunden gefragt haben, mit sich bringt.

• Managed SIMs wurden deaktiviert, sobald der Aktivierungsserver für eine Stunde unerreichbar war, während sie eigentlich erst nach 24h deaktiviert werden sollten.
• Wenn ein VPN-Client getrennt wurde und ein anderer Client-Nutzer später mit derselben IP des vorherigen Nutzers wieder angemeldet wurde, konnte das einen Absturz und Neustart des VPN-Hubs auslösen.
• Bei den Access-Point-Einstellungen fehlte die Option, Admin-Rechte zu konfigurieren.
• Beim Router-Start wurde die Fehlermeldung „The tunnel password for the tunnel contains illegal characters“ ins Log geschrieben.
• Wenn zwei oder mehr WAN-Module exakt zur gleichen Zeit powercycled wurden, konnte es passieren, dass die Module manchmal nicht mehr gefunden wurden, sodass ein Router-Neustart nötig war, um die Module wieder anzuzeigen.
• TKIP ist nun für HT-Clients auf 5XX WLAN-APs in 802.11n deaktiviert.
• Manuelle Firmware-Updates können nun auch hochgeladen werden, wenn die automatische Firmware-Prüfung den Status „UpdatesAvailable“ ergab.
• Bei allen 51X-Routern wurden die jeweiligen Konfigurationsdateien als miteinander kompatibel markiert. Davor konnten 511, 512 und 513 keine 510-Konfigurationen nutzen und umgekehrt.
• Bei Hubs 5000/5010 wurde im Web-Interface die Bildgröße korrigiert.
• Wenn die SSH-CLI aktiviert war, konnte eine Verbindungsflut auf Port 22 genutzt werden, um eine DoS-Attacke gegen den Router zu fahren.

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

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

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

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

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

Eine gültige Garantieerweiterungs-Lizenz, die noch nicht abgelaufen ist, wird nun auch als „Unter Wartungsvertrag“ gezählt. Wenn Ihr Router noch immer Garantie übrig hat, können Sie daher jetzt auf RuggedVPN aktualisieren, selbst wenn Sie Ihre Garantielizenz bislang nicht in einen Viprinet Lifetime Maintenance-Vertrag umgewandelt haben. Bei Garantieerweiterungen wird nun auch angezeigt, wie viele Tage sie noch gültig sind.

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

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

• Lizenzen werden nun gelöscht, wenn der Lizenzserver das anordnet, und die Online-Lizenz-deaktivierungsfunktion 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 "Eisen", die bei OEM-Projekten Verwendung finden wird, wird nun unterstützt.
• Es ist nun erlaubt, ohne aktives VLM-Abonnement von Classic auf RuggedVPN aufzurüsten. Das funktioniert auch mit dem alten Web-Interface.
• Zum Lizenzmanager wurde eine fehlende "Deactivate"-Schaltfläche hinzugefügt.
• 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.

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

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

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

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

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

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

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