ruggedvpn

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

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

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

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

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

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

• Diese Firmware bietet keine neuen Funktionen.

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

Diese Firmware bietet keine neuen Funktionen.

• Seit dem 1. Dezember 2016 zeigten alle früheren Firmware-Versionen beim Einloggen in das Web-Interface ein nervendes Popup, das verkündete, dass die Firmware veraltet sei und nicht mehr unterstützt werde. Das passierte sogar bei der jüngsten Firmware-Version vom 28. Oktober, die vollkommen in Ordnung ist und definitiv unterstützt wird. Dieses Popup wurde entfernt. Wir entschuldigen uns für die Unannehmlichkeiten.
• Diese Firmware-Version behebt einen Kodierungsfehler, der dafür sorgte, dass VPN Clients, die mit einem RuggedVPN-Hub verbunden waren, keine Downstream- und Latenz-Graphen im Monitor-Tab darstellen konnten.

• Dynamisches Routing mit BGP und OSPF wird nun auf Hubs und Nodes voll unterstützt.
• LTE-Module können jetzt SMS verschicken und empfangen. Zudem können Sie automatische Antworten für eingehende SMS konfigurieren. Mithilfe dieser Funktion können Sie unsere Produkte nun für LTE-Provider verwenden, die Datentarife anbieten, bei denen Sie mithilfe einer SMS Datenpakete hinzufügen können. Beispiel: Vodafone Deutschland schickt Ihnen eine SMS „Ihr High-Speed Datenvolumen wurde aufgebraucht, antworten Sie mit ‚5‘, um weitere 5GB hinzuzubuchen.“ Mit der Autoresponder-Funktion können Sie einen Filter auf "Datenvolumen wurde aufgebraucht" erstellen, bei dem der Router automatisch mit "5" antwortet, um ein weiteres Datenpaket zu buchen. Bitte beachten Sie, dass diese Funktion aufgrund Chipsatz-Beschränkungen leider nicht für LTE 450 und 4G Europe II Module funktioniert.
• Die Konfiguration für Viprinet Virtual VPN Hub ist jetzt kompatibel mit der von Hardware Hubs, sodass Sie eine Config-Datei von oder für einen Hardware-Router kopieren und nutzen können.
• Interne Verbesserungen beim Speichermanagement reduzieren die Größe des genutzten Speichers und Adressraums deutlich. Die Speichernutzung auf intensiv genutzten Hubs sollte damit deutlich langsamer steigen als bisher.

• Neues verbessertes Verhalten für deaktivierte Tunnel auf VPN Hubs: Anstatt Tunnels, Clients oder Channels verbinden und wieder trennen zu lassen, wenn sie deaktiviert wurden (oder die VVH-Identität noch nicht bereit ist), werden sie nun direkt am Verbinden gehindert. Für Verbindungsversuche wurde eine Drosselung hinzugefügt.
• Viprinet Virtual VPN Hub: Verbessertes Startsystem, das sicherstellt, dass der VVH nicht mit eingehenden Tunnelverbindungen überflutet wird, bevor er bereit ist, diese anzunehmen.
• Viprinet Virtual VPN Hub: Wenn beim Starten des VVH DNS unerreichbar war, konnte es bis zu 5 Minuten dauern, bis der Hostname des Identitätsservers neu aufgelöst werden konnte.
• Viprinet Virtual VPN Hub: Benutzer können nicht länger eine neue Geräteidentität anfordern, es sei denn der Hub ist als „Copy“ markiert.
• SFTP-Transfers vom und zum Router funktionieren wieder.
• In der WAN-Modulinfo für LTE-Module konnte manchmal sinnloser Text hinter "Country:" auftauchen.
• Manchmal zeigte das Web-Interface die Zusammenfassung aller Items nicht, wenn eine Objektliste aufgerufen wurde.
• Manchmal wurden die Channels von gestackten Slaves nach einem Neustart nicht mehr genutzt.
• Aus dem Web-Interface wurden zahlreiche Javascript-Debug-Ausgabezeilen entfernt.
• Manchmal konnte es zu einem nicht synchronisierten Zugriff innerhalb des Ajax-Nachrichtensystems des Web-Interface kommen. Dadurch konnten u.a. Router einfrieren und/oder der Object-Baum konnte im Web-Interface nicht mehr erreicht werden. Das passierte meistens, wenn „Contact license server“ manuell aus dem Web-Interface ausgeführt wurde oder wenn auf dem VVH ein Tunnel deaktiviert wurde.
• Wenn eine Lizenz-Deaktivierung fehlschlägt, wird nun ein Fehler ausgegeben.
• Wenn ADSL/VDSL-Modulen bei einem 24h-Reconnect eine neue IP zugewiesen wurde, ohne dass das Interface während des Reconnects neugestartet wurde, funktionierten sie danach manchmal nicht mehr.
• Abgelaufene Lizenzen/Abonnements werden auf dem VVH nicht mehr als gültige Tunnellizenzen gezählt.
• Die Ergebnisse von Upstream-Autotuning auf dem RuggedVPN VPN-Client wurden um ein Zehnfaches verbessert.
• Genau wie die Router stimmt jetzt auch der RuggedVPN VPN-Client die TCP-Sendbuffers ab. Wir haben gesehen, dass damit für Windows erst bei 8k Schluss war, das bringt also eine RIESIGE Leistungssteigerung bei hochlatenzierten Links.
• Das HTTPS-Download-Testtool akzeptierte SSL-Zertifikate, die gültig aber abgelaufen waren.
• Wenn ein Hub nicht konfiguriert war, VPN-Clients DNS zuzuweisen, konnte der VPN-Client während des Verbindungsaufbaus für 10 Sekunden blockieren. Diese Verzögerung wurde beseitigt, wodurch das Verbinden eines VPN-Clients drastisch beschleunigt wurde.
• Routen, die auf ungültige Ziele zeigten, konnten nicht gelöscht werden.
• Der VPN Router 2620 glaubte, seine Bandbreitenkapazität wäre 200 Mbit/s anstatt der 400 Mbit/s, die er leisten kann. Außerdem vermeldete er eine falsche Kapazität über den Tunnel zur Gegenstelle. In der Praxis bedeutete das zwar nicht viel, aber unter gewissen Umständen / bei gewissen Lasten aus dem LAN konnte das den möglichen Gesamtdurchsatz des Routers beschränken und es konnte dafür sorgen, dass der Hub falsche Werte für die Gesamtkapazität für Bandbreiten-Autotuning annahm.
• Für den VPN-Client wurde der HTTPS-Webserver deaktiviert.
• Für HTTPS-Fehler wurde ein Log-Präfix hinzugefügt, das die Remote-IP anzeigt, die den Fehler verursacht.
• Das Identitätsmanagement des Viprinet Virtual VPN Hubs wurde verbessert. Falls ein VVH als Klon markiert wird, können nun einfach alle tatsächlichen Klone ausgeschaltet werden. Nach einer Weile wird der eine verbliebene Ex-Klon dann wieder als legitimer VVH verifiziert.

• Das interne Transfernetzwerk für Virtual Hubs darf nicht verändert werden.
• VLANs und Segmentierung werden so gut wie möglich über dynamisches Routing geregelt, allerdings funktionieren möglicherweise nicht alle Setups. Es gibt keine separaten Routing-Tables.
• Um die SMS-Funktion auf einem 510 zu konfigurieren, muss sich im entsprechenden Modem eine SIM befinden.
• VPN-Bypass ist derzeit deaktiviert.

Um die Funktion Dynamisches Routing zu aktivieren, muss eine Enterprise Node Features Software-Lizenz auf der Node-Seite installiert werden. Das bedeutet, diese Funktion wird derzeit mit allen Viprinet-Hubs werkseitig ausgeliefert und steht auf dem 2610/2620 kostenfrei zur Verfügung.

• Fügt ein neues Objekt im Web-Interface „Dynamic routing settings“ hinzu, inklusive zweier neuer Tools „Full routing table“ und „Viprinet routing table“
• Macht dynamische Verteilung statischer LAN/WAN-Viprinet-Routen möglich
• Erlaubt Push-/Accept-Routen pro Tunnel. Diese Eigenschaft findet sich bei jedem Tunnel. Der Standardfall ist, Push-Routen auf der Node-Seite und die Option „Accept incoming routes“ auf der Hub-Seite zu aktivieren, allerdings gibt es bestimmt auch Anwendungsfälle, bei denen beide Richtungen zum Einsatz kommen.
• Erlaubt die Auswahl, welches Interface in welcher Area sprechen und ob es für dynamisches Routing verwendet werden soll (OSPF/OSPF nur für IPv6).
• Verteilt WAN/VPN-Routingregeln, VPN-Client-Pools, LAN-IPs und zusätzliche LAN-Routen.
• Ermöglicht einem Viprinet-Router, sich selbst als Default-Gateway zu ernennen, wobei er von anderen Routern angegebene Default-Routen ignoriert.

Zwei Beispiele

Fall 1: Das neue Tunnel-Protokoll nutzen, um alle Node-Netzwerke an den Hub zu schicken, damit der Hub sie routet (keine statischen WAN/VPN Routingregeln)

• Hub-Seite: Aktivieren Sie „Accept incoming routes“ im ausgewählten VPN-Tunnel
• Node-Seite: Aktivieren Sie „Push routes through tunnel“ im ausgewählten VPN-Tunnel

Nachdem diese Einstellungen aktiviert wurden, muss der Tunnel erneut verbunden werden. Der Hub sollte nun alle Node-Netzwerke empfangen und diese zum richtigen Tunnel routen.

Fall 2: Fall 1 um einen dynamischen Routingdienst erweitern

• Konfigurieren Sie zuerst Node und Hub wie in Fall 1
• Konfigurieren/Aktivieren Sie zusätzlich den dynamischen Routingdienst auf Node- und/oder Hub-Seite sowie den gewünschten Dienst (BGP, OSPF oder OSPF für IPv6)

Der Hub erkennt auch alle eingehenden Netzwerke auf Node-Seite und routet diese. Stellen Sie sicher, dass Sie den Haken bei „Distribute local Networks“ im gewünschten Dienst gesetzt haben, sonst wird er nicht ausgeführt. Wenn Sie zusätzlich einen dynamischen Routingdienst auf der Hub-Seite aktiviert haben, kann er alle Node- und Hub-Netzwerke zum Uplink-Router leiten.

Warnung/Hinweise

• BGP only: Um den Dienst zu starten, müssen Sie zumindest einen BGP-Nachbar konfigurieren. Sie finden das BGP-Nachbar-Objekt unter „Integrated services“ " „Dynamic routing settings“ " „BGP settings“.
• OSPF/OSPF for IPv6 only: Um den Dienst zu starten, müssen Sie ein Interface konfigurieren, um es im LAN-Einstellungen-Objekt zu verwenden; dort können Sie auch das OSPF-Gebiet konfigurieren.
• VPN-Tunnel: Um „Push routes through tunnel“/„Accept incoming routes“ erfolgreich zu ändern, muss der jeweilige Tunnel neu verbinden.

Bekannte Probleme

• OSPF/OSPF für IPv6: Die Passwort-Authentifizierung funktioniert nicht.
• Von anderen Routern ausgegebene Default-Routen gehen derzeit verloren.

• Sie können nun die Firmware von VDSL-Modulen innerhalb des Web-Interface des Routers updaten. Neue Firmware-Images für VDSL-Module werden automatisch nach Bedarf heruntergeladen, analog der Firmware-Images für LTE-Module.
  Firmware-Änderungen für die aktuellste VDSL-Modul-Firmware-Version 1.91:
  • VLANS funktionieren nun im ADSL RFC1483-Modus.
  • Module kommunizieren nun Authentifizierungsfehler an den Router, wenn sich die Zugangsdaten während der PPP-Einwahl als falsch herausstellen.
  • Die Werkzeuge Ping und traceroute funktionieren in Viprinet wieder.
  • Mehrfachverbindungen des Moduls in die Welt funktionieren wieder (z.B. Download Test Tool).
  • Die Firmware nutzt den aktuellen Datapump (10.23.0.47), das behebt viele VDSL-bezogene Sync-Probleme.
• Volle Unterstützung für 4.5G LTE-A-Module. Die Module zeigen nun auch die Modulseriennummer im Web-Interface an.
• Implementierung von Code, der Ethernet/IP/TCP/UDP/ICMP-Pakete detailliert überprüft, wenn sie aus dem LAN eingehen und wenn sie rausgehen. Das schützt sowohl unsere Router und die Netzwerke dahinter gegen eine große Reihe von TCP/IP-Protokollattacken.
• Neue Logo-Animation beim Starten von Routern. Weil wir's können. ;-)

• Wir erlauben nun das Löschen von VPN-Tunnels, VPN-Client-Tunnels und Channels, während sie noch aktiviert (aber nicht verbunden!) sind. Das wurde geändert, um einen Fehler zu beheben, bei dem der VPN-Client beim Hochstarten unendlich in einem unsauberen Zustand stecken bleiben konnte, bei dem er versuchte, einen aktivierten Tunnel zu löschen. Im Allgemeinen sollte sich dadurch auch die Nutzererfahrung verbessern.
• Diese Firmware-Version behebt die Probleme, die LTE Europe/Australia/Africa Module mit dem Einlesen mancher SIMs hatten.
• Falsche Zeitzonenberechnungen auf den Geräten der 200er und 5xx-Reihe wurden behoben, die falsche Log-Zeitstempel verursachen konnten.
• Unter seltenen Umständen konnte der Routingkern durch den unsauberen Disconnect eines Channels stecken bleiben.
• Unter sehr seltenen Umständen konnte durch den Zugriff auf einige Objekte, die derzeit vom Routing-Kern genutzt werden, dieser stecken bleiben (z.B. durch das Auslesen von SNMP, Web-Interface, CLI oder Router-Stacking-Kommunikation).
• Auf neueren Geräten, die einen asynchronen Hardware-Crypto-Beschleuniger nutzen, konnte ein unsauberer Channel-Disconnect beim Routerkernel zu Absturz, Panik and Reboot führen.
• Stacking-Master blieben manchmal stecken, wenn viele Änderungen auf Channels und/oder WAN-Modulen geschahen, die zwischen Routern synchronisiert wurden.
• Ein Memory Leak führte bei der Nutzung von FEC unter Umständen nach einigen Tagen zu einem voll laufenden Speicher und zu einem Reboot.
• Die Clone Detection des Virtual VPN Hub konnte fälschlicherweise einen Hub als Klon identifizieren, wenn die Uhrzeit auf unserem Backend-Server desynchronisiert war.
• SSL Handshake-Timeouts sind jetzt viel entspannter, was zu weniger SSL Handshake-Fehlern bei instabilen WAN-Verbindungen führen sollte.
• Im Fall, dass der Router rebooten muss (z.B. weil der Routingkern hängengeblieben oder der Speicher ausgegangen ist), wird er nun zunächst noch versuchen, eine Kopie der Logdatei auf den Flash-Speicher zu schreiben. Dies ermöglicht dem Supportteam in Zukunft, einen Hub/Router nach einem Reboot auf dessen Gründe zu diagnostizieren, auch wenn kein lokaler Syslog-Server am LAN existiert.
• Der designierte Stacking-Master nutzt nun seine eigene Uptime statt der, die vom aktuellen Stacking-Master berichtet wird. Zudem wurde das Logging verbessert, so dass es jetzt weniger verwirrend sein sollte.
• Ein Timing-Problem im dynamischen Routing, welches zur Meldung „Duplicate Router received“ auf der anderen Seite führte, wurde behoben.
• Die Einstellung „Distribute via Dynamic routing“ in den Additional LAN Routers wurde ignoriert.
• Ein zum Hub verbindender Node konnte für immer mit 99% CPU-Last stecken bleiben, wenn die TCP-Verbindung des Channels in einer bestimmten Phase des Verbindungsaufbaus zusammenbrach.
• Die „Guaranteed delivery“ QoS-Einstellung konnte unter sehr seltenen Umständen dafür sorgen, dass der Router abstürzt und/oder Speicher verliert. Dieses Feature ist in dieser Firmwareversion komplett deaktiviert, und wird in einer späteren Firmwareversion zurückkommen. Egal, was aktuell in den QoS-Einstellungen konfiguriert ist, Guaranteed Delivery wird nicht benutzt (und die Einstellung in Ihrer Konfiguration auch nicht geändert).
• Als Schutzmaßnahme wird Hub-seitig die Channel-Verbindung geschlossen, wenn während der Authentifizierungsphase mehr als 10 Fehler aufgetreten sind.
• Es wurde Programmcode implementiert, welcher vom/zum LAN eingehende/ausgehende Ethernet/IP/TCP/UDP/ICMP-Pakete im Detail überprüft. Dies geschieht, um sicherzustellen, dass in keinem Falle Müll-Pakete den Router verlassen, welche Abstürze verursachen könnten.
• Die Anzahl von Paketen, die in einem Rutsch vom LAN gelesen werden, wurde reduziert. Zuvor konnte man das LAN-Interface des Hubs mit Paketen fluten, und der Router war dann kaum noch in der Lage, etwas anderes zu tun. Das konnte den Eindruck vermitteln, dass der Routingkern steckengeblieben sei.
• Auf dem Hub gibt es nun einen weiteren Schutzmechanismus gegen die erneute Nutzung einer invaliden, zwischengespeicherten SSL-Sitzung. Dies behebt eine Flut an SSL Handshake-Fehlern, die von einigen Kunden beobachtet wurden, bevor der Routingkern eingefroren ist.
• Fragmentierte IP-Pakete mit einer Größe über 32KB konnten einen Speicherfehler auslösen, der wiederum einen Neustart zur Folge hatte. Wir sahen dies bei einigen Kunden, meist als Folge eines Angriffs auf deren Netzwerke.
• Der Wechsel eines Hotspares in den Replacement-Mode verursachte einen internen Absturz. Dies führte wiederum zu einem Neustart des Systems sowie zu einer längeren Dauer der Übernahme. Dies wurde behoben, so dass die Übernahme nun wesentlich schneller geht.
• LAN IP-Aliases akzeptieren nun keine ungültigen IPv6 Adressen mehr.
• Das Anwenden neuer Einstellungen bei den DHCP-Diensten konnte eine grundlose Fehlermeldung auslösen.
• Die SSH CLI RSA Keylänge wurde von 1024 auf 2048 Bit erhöht.
• Wenn man bisher ein Viprinet-Gerät mit ICMP-Ping-Paketen flutete, hörte der Router nach einiger Zeit auf, darauf zu antworten, und beantwortete von da an ICMP-Anfragen gar nicht mehr.
• VPN-Tunnel verbinden jetzt automatisch neu, wenn ein fataler Fehler beim Lesen von Paketen eines der Tunnel-Channel auftritt.

• Unter bestimmten Umständen konnte Traffic innerhalb von einer oder mehreren QoS-Klassen plötzlich steckenbleiben. Das konnte z.B. darin resultieren, dass plötzlich für Benutzer keine Auflösungen per DNS mehr möglich waren. Dieser Bug existierte schon seit langem, trat aber extrem selten auf. Mit neueren Firmwareversionen trat er nun häufiger auf. Wie alle uns mit uns deswegen in Kontakt stehenden Kunden bestätigt haben, ist das Problem nun behoben.
• Bei einigen Installationen wurden mit der Juli-Firmware die LTE 450 Mhz Module, die in Nordeuropa eingesetzt werden, teilweise nicht mehr vom Router erkannt. Das funktioniert jetzt wieder mit allen Produkten.

• UMTS- und LTE-Module verwenden jetzt eine brandneue APN-Datenbank, die auf der IMSI-Reihe der SIM basiert. Das bedeutet, dass wir nun zwischen den Netzwerk-Resellern unterscheiden können – so werden die „Tchibomobil“-SIMs auf O2 nun ihre eigene APN verwenden, anstelle der von O2. Die Datenbank wird immer aktuell gehalten. Fällt das neue System aus, wird auf die alte MCC/MNC-basierte APN-Erkennung zurückgegriffen.
• Drastisch reduzierter Speicherverbrauch sowohl auf Hubs als auch auf Nodes.
• Der LAN-Durchsatz auf Hubs wurde drastisch erhöht. Selbst wenn ein Hub mehr konnte, konnte er in früheren Releases maximal nur etwa 250 MBit/s aus dem LAN lesen. Jetzt liest er wieder 2 Gbit/s.
• Massive Verbesserung des Bündelungsdurchsatzes bei den meisten Produkten. Wir haben jetzt Spitzenbündelungsdurchsätze von >200 Mbit/s auf einem 310 gesehen.
• Unterstützt jetzt das neue LTE-A 4.5G APAC Modul.
• Alle neueren LTE-Module sind nun in der Lage, die IP-Adresse beim Connect wesentlich schneller als bisher zu erfassen.

• Mit dem Packet Capture Tool können Sie nun an verschiedenen Stellen PCAP-Dateien des Datenverkehrs live betrachten oder herunterladen.
• In den Web-Interface-Sammlungen können Sie nun nicht nur neue Elemente hinzufügen, sondern auch einfügen. Wenn Sie „Einfügen“ verwenden, während Sie sich im Sammelobjekt befinden („Tunnels“), wird das Objekt oben eingefügt. Wenn Sie einen Punkt („WurstTunnel“) ausgewählt haben, wird der neue Punkt davor eingefügt.
• In Sammlungen können Sie nun Elemente ganz nach oben und ganz nach unten verschieben, anstatt nur Zeile für Zeile.
• Tunnelobjekte können nun verschoben und neue Tunnel eingefügt werden, anstatt sie nur hinzuzufügen.

• Das Release enthält verschiedene Korrekturen und Änderungen an der Funktionsweise von FEC und Kanalauswahl.
• Es enthält auch verschiedene AWS-Fixes für die Zertifikatsverwaltung.
• Einige Logikfehler, wie QoS-Klassen mit welcher Geschwindigkeit senden dürfen, wurden behoben. Dies behebt die von den Partnern gemeldeten fehlerhaften Testfälle mit „guaranteed bandwidth“.
• Es wurde sichergestellt, dass ALLE möglichen LTE-Bänder aktiviert sind, bevor bekannt ist, welche Bänder das Modul tatsächlich unterstützt. Dies könnte die Probleme beheben, die Partner mit „Forgotten LTE bands“ hatten.
• Von nun an wird die TCP-Option 14 durch Viprinet-Tunnel akzeptiert.
• Wenn das interne Übertragungsnetz auf etwas anderes als die Standardeinstellungen umkonfiguriert wurde, konnten die Virtual Hubs die Verifizierungsserver für Virtual Hubs nicht mehr erreichen.
• Bei WLAN-Client-Modulen werden die aktuell gesehenen WLAN-APs wieder in der Modulinfo aufgelistet, auch wenn keine Verbindung zu einem AP besteht.
• Bei früheren Firmware-Versionen konnte es nach einer Laufzeit von 49,7 Tagen aufgrund eines 32-Bit-Zähler-Wrap-Arounds zu einem Reboot kommen. Dieses Problem besteht nicht mehr.
• Das Release enthält einen Fix für einen Workaround für Fehler in einigen LTE-Modul-Firmware-Releases, die dazu führen konnten, dass die LTE-Module eines 51x SIM-Karten bei einem Kaltstart nicht erkennen.
• Ein potentielles KRACK-WLAN-Sicherheitsproblem wurde behoben.
• Es gab einige Fehlerbehebungen für das Problem „Module bleiben für immer im Verbindungszustand stecken“, das Partner gesehen haben.
• Zudem enthält das Release einen Fix für Chrome 61, das die selbstsignierten SSL-Zertifikate nur ungern angenommen hat, die unsere Router für das Web-Interface generieren. Bitte beachten Sie, dass Sie manuell ein neues SSL-Zertifikat im Router erneut generieren müssen, damit Chrome aufhört, sich zu beschweren.
• „Managed SIM Settings“ wurden aus der Firmware entfernt, da unsere Managed SIMs bereits seit einem Jahr nicht mehr verfügbar sind.
• Die 511 LTE-Bilder wurden um 35 MB verkleinert. Jetzt funktioniert ein Offline-Update auf einem 511 wieder zuverlässig.
• Der Slave in einem Stacking Router-Setup speicherte die Konfiguration jedes Mal, wenn eine Änderung vom Master gesendet wurde. Nun wird er nur noch alle 30 Sekunden gespeichert.
  Auch die Synchronisation wurde nun gedrosselt, um weniger CPU zu verbrauchen.
• Unter sehr seltenen Umständen konnte es vorkommen, dass geNATteter ICMP-Verkehr, der von mehreren Quellen (Tunneln) gleichzeitig kam, einen oder mehrere dieser ICMP-Flüsse blockierte.
• Alle Download-Tools unterstützen jetzt auch HTTP Chunked Encoding.
• In der vorherigen Stable Firmware-Version wurde die LTE-Firmware Carrier-Zertifizierung nicht in der Modul-Info angezeigt.
• Es wurde sichergestellt, dass bei benutzerdefinierten Profilen bestätigt werden, dass alle Einstellungen auch wirklich vom LTE-Chipsatz empfangen werden. Dies behebt alle gemeldeten Probleme bei der Verwendung privater APNs.
• Einige Nutzer haben berichtet, dass das im Webinterface enthaltene Google Maps GPS Tool nicht mehr funktioniere. Es wurde ein neuer API-Key von Google hinzugefügt, was dieses Problem behebt.
• Seit dem 1. Dezember 2017 beschweren sich alle Firmwareversionen fälschlicherweise, dass die Firmware völlig veraltet sei. Wir bitten die daraus resultierende Verwirrung zu entschuldigen. 

• Wir haben Berichte erhalten, dass in einigen Installationen VDSL oder ADSL Module im Status “Disconnecting” hängen bleiben können, wenn sie durch den 24h-Reconnect des ISP eine neue IP bekommen. Dieses Problem wurde in den letzten Jahren schon mehrfach berichtet, wir konnten es aber nie reproduzieren. Sollte dieses Problem bei Ihnen auftreten, so wenden Sie sich bitte an unser Support-Team, damit wir das Problem endlich finden und beseitigen können.
• Unter Umständen ist es nicht möglich, auf Virtuellen VPN Hubs VPN Clients zu aktivieren. Bitte kontaktieren Sie den Support, wenn dies bei Ihnen der Fall ist. Wir arbeiten an einem Hotfix für dieses Problem.
• Das Löschen eines VPN-Tunnels auf einem VPN Hub kann diesen rebooten lassen, wenn der Tunnel in den 3 Minuten zuvor noch verbunden war. Bitte warten Sie daher mit dem Löschen von VPN-Tunnels 3 Minuten bis nach dessen Disconnect.
• Nach der Installation der Firmware kann ein VPN Hub Hotspare fälschlicherweise behaupten, dass der active VPN Hub nicht mehr erreichbar sei und versuchen, diesen zu übernehmen. Das Problem verschwindet, wenn der Hotspare ein zweites Mal neugestartet wird. Dies kann z.B. umgangen werden, indem vor dem Update der Hostspare temporär aus der Redundanzgruppe entfernt wird. Wenn Sie Unterstützung beim Rollout der Firmware auf einer großen Zahl von VPN Hubs brauchen, kontaktieren Sie bitte unseren Support. 

• VPN Bypass ist da!
  Dies ermöglicht es Ihnen, Traffic-Regeln zu erstellen, die nicht auf einen Tunnel zeigen, sondern direkt auf das Modul, wo der Verkehr auf die IP des Moduls geNATtet wird.
  Gehen Sie zu WAN/VPN Routing-Regeln, aktivieren Sie „Allow VPN Bypass Routing“, richten Sie einige Routing-Regeln ein, die auf ein Modul zeigen, und genießen Sie.
  Bitte beachten Sie, dass diese Funktion nur in Ausnahmefällen genutzt werden sollte – z.B. wenn sich hinter einem Ethernet WAN-Modul ein DSL-Router mit integriertem VoIP-Gateway befindet, den Ihre Telefone erreichen müssen. Denken Sie daran, dass die Verwendung des WAN-Moduls direkt für den Internet-Verkehr so ziemlich jeden Zweck zunichtemacht, für den Viprinet-Router geschaffen wurden (Sicherheit, Redundanz, reich und berühmt werden, usw.).
  Es gibt auch das „Modul Browsing Tool“ innerhalb der WAN-Modul-Objekte, wenn Sie nur vorübergehend ein Modul nutzen wollen, um ein Captive-Portal auszufüllen.
• Sie können nun DNS A-Einträge des integrierten DNS-Servers hinzufügen und verwalten. Damit können Sie Hosts wie „mycomputer.local“ konfigurieren und diese für alle Rechner, die den DNS-Server des Routers verwenden, auf eine IP auflösen.

• Durch wiederholte Fluten von Scans für den TLS ROBOT-Angriff konnten Hubs/Router zum Absturz gebracht und neu gestartet werden.
  Wir haben jetzt die Cipher-Suiten aktualisiert, die verwendet werden, um den Austausch von RSA-Schlüsseln vollständig zu deaktivieren, wie es als Best Practice empfohlen wird.
  Damit haben wir die Kompatibilität für alle Viprinet Classic-Firmware-Geräte mit einer Firmware älter als 2015 entfernt, die mit einem aktualisierten Hub verbunden sind.
  Sie werden auch nicht mehr in der Lage sein, das Webinterface mit HTTPS mit sehr veralteten Browsern wie IE unter Version 11 zu verwenden.
  Wir haben auch den VPN-Tunnel-Code im Hinblick auf zukünftige TLS-Angriffe gestärkt.
• Es war möglich, einen DoS-Angriff gegen den Router durchzuführen, indem man viele Verbindungen gegen die SSH-Ports öffnete, dann die SSH-Sitzung auf der SSH-Protokollschicht schloss und gleichzeitig die SSH-TCP-Verbindung offen hielt.
• Aufgrund einer Timer-Desynchronisation konnte es vorkommen, dass Router mit der vorherigen Firmware-Version nach 24 Tagen Betriebszeit neu gestartet wurden, während die Meldung „Routing core stuck“ angezeigt wurde.
• Wenn ein Stacked Setup mit einem Hub verbunden war und der Master neu startete, übernahm der Slave. Aber wenn der Master zurückkam und den Kanal neu aufbaute, konnte man am Hub sehen, dass der Kanal des Slaves manchmal im Zustand „Disconnecting“ hängen blieb, bis der Hub neu gestartet wurde. Dies wurde verursacht durch den “A split brain situation has occured on the remote stacking Node, channel will be disconnected”-Fehler.
• Probleme mit der Aktivierung von VPN-Clients auf virtuellen Hubs wurden behoben.
• In sehr seltenen Fällen können DSL-Module aufgrund von Kommunikationsproblemen zwischen Router und Modul stecken bleiben. In diesem Fall schaltet sich das Modul nun automatisch aus und wieder ein. Hier gibt es noch bekannte Probleme, an denen wir arbeiten. Sollten irgendwelche Ihrer Module im Zustand „Disconnecting“ steckenbleiben, wenden Sie sich bitte an unser Support-Team.
• Korrekte dauerhafte Behebung der Meldung „Veraltete Firmware“. Die Meldung erscheint nun immer ein Jahr nach Erscheinen der Firmware.
• Beim Stacking gab es oft Probleme mit der ARP-Auflösung für LTE-Module, wodurch diese für den Stacking-Master unbrauchbar wurden.
• Eine ganze Reihe von Problemen mit der Art und Weise, wie die Router mit der IP-Fragmentierung umgehen, wurde behoben. Dies hilft allen Kunden, die fragmentierte IP-Pakete verwenden (z.B. IPSec-Tunnel durch den Viprinet VPN-Tunnel, einige Audio/Video-Codecs). Bitte beachten Sie, dass IP-Fragmentierung immer noch nicht empfohlen wird, weil sie die Performance beeinträchtigt. Sie sollten jede IP-Fragmentierung, die Sie in Ihrem Netzwerk haben, so weit wie möglich beheben, indem Sie die IP-Nutzlastgröße an die MTU Ihres Netzwerks anpassen.