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.

"Cutting edge" vs "stable"

Viprinet bietet zwei Entwicklungszweige bzgl. seiner Firmware an - "stable" und "cutting-edge". Die "stable"-Firmware wird von uns über Wochen in Langzeiteinsätzen getestet und ein bis zwei Mal pro Jahr aktualisiert. Alle Kunden sollten immer mindestens die neueste "stable"-Firmware nutzen. Zusätzlich bieten wir mehrfach im Jahr eine "cutting-edge"-Firmware an - diese enthält neueste Entwicklungen und Features, wurde aber nicht langzeit-getestet. Diese Firmware sollte von allen Kunden genutzt werden, die neue Features oder Fehlerbehebungen benötigen.

Online update (nur stable Firmware)

Unsere Router enthalten im Webinterface unter [ AdminDesk ] [ Logging & Maintenance ] [Router Firmware Update] die Möglichkeit, ein bequemes Onlineupdate der "stable"-Firmware durchzuführen. Hier kann automatisch geprüft werden, ob für das Routermodell ein Firmwareupdate vorliegt, dieses ggf. heruntergeladen und installiert werden. Es kann auch konfiguriert werden, dass Firmwareupdates ohne Zutun des Administrators bei Verfügbarkeit heruntergeladen werden. Die Installation sollte aus Sicherheitsgründen aber immer in Anwesenheit eines Administrators durchgeführt werden.

Offline update

Als Alternative zum Online-Update steht auch ein Offline-Update zur Verfügung. "Cutting-edge" Firmware Releases sind nur als 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 FTP-Server verfügbar.

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

Wichtige Hinweise zur aktuellen stable Firmware

Nachfolgend erhalten Sie wichtige Informationen zu den zuletzt veröffentlichten "Stable"-Firmwareversionen, die neueste steht oben.

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

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

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

Verbesserungen:

• Mit diesem Release unterstützten wir erstmals unsere neuen CDMA 450 Mhz Module, die für den Einsatz in Nord- und Osteuropa bestimmt sind.

• Channel Congestion Detection ist nun etwas aggressiver eingestellt als bisher.

• Die CLI wurde vervollständigt und ist nun bereit für den Produktiveinsatz. Ein Scripting Toolkit, mit dem die Administration und das Deployment von Routern automatisiert werden können, ist auf Anfrage verfügbar.

Fehlerbehebungen:

• WICHTIG: Im vorangegangenen Stable Firmware Release aus Dezember 2012 existiert ein ernstzunehmender Fehler. Referenzen von VPN Routing Regeln auf einen Tunnel können zerstört werden, wenn Tunnel aus der Tunnelliste gelöscht werden - anschließend zeigen Regeln dann auf die falschen Tunnel. Ähnliches konnte auch bei QoS-Regeln passieren. Löschen Sie mit dem Dezember-Release keine Tunnel. Aktualisieren Sie zunächst auf diese Firmware.

• Wenn Channel komplett idle waren (für geraume Zeit weniger als 20 KBit/s an Traffic), hätten die Channel eigentlich in einen Trafficsparmodus gehen sollen, bei dem nur noch 1x pro Sekunde statt 10x pro Sekunde die Latenz und Eigenschaften des Channels analysiert werden. Damit sollte der Trafficverbrauch insbesondere bei Leitungen mit hohen Traffic-Kosten (z.B. UMTS) reduziert werden. Durch einen Rundungsfehler hat diese Funktion leider tatsächlich in der Praxis nie funktioniert: Wenn auf einem Channel auch nur ein einziges Mal mehr als 24 Kbit/s übertragen worden war, wurde der Traffic-Sparmodus nie wieder aktiviert. Dieser Modus funktioniert nun so wie erwartet und reduziert den Trafficverbrauch bei ungenutzten Channeln um den Faktor 10.

• Im Hotspare-Modus eines Hubs zeigt der Lizenzmanager nun einen Hinweis an, dass in diesem Modus keine Lizenzen geprüft werden.

• Ein Timingproblem konnte beim 500er Router in seltenen Fällen dazu führen, dass es gelegentlich kurze Aussetzer beim Routing gab.

• Das Ethernet Infotool für das LAN Interface am 500er Router funktioniert nun tatsächlich.

• Mehrere BondingTCPOptimizer bugs wurden gefixt. Diese konnten BondingTCPOptimizer TCP-Verbindungen hängen lassen, wenn nicht das WAN sondern das LAN das Bottleneck darstellte (z.B. wenn es im LAN einen traffic shaper hinter dem Viprinet-Router gab).

• Ethernet Autonegotiation Settings für Ethernet WAN Module wurden bisher nicht gespeichert und waren nach einem Reboot verschwunden. Dies ist nun behoben. Weiter besteht ein bekanntes Problem: Bei Gigabit Ethernet modulen lässt sich Ethernet Autonegotiation aufgrund eines Bugs im NIC-Treiber aktuell nicht deaktivieren. Bitte nutzen Sie als Workaround Fast Ethernet Module in diesen Fällen.

• Ein Memoryleak in Bezug auf Tunnelobjekte wurde behoben. Wenn man mit bisherigen Firmwarereleases eine sehr große Zahl von VPN Tunnel z.B. per automatisierter Scripte anlegete und löschte, konnte dem Router mit der Zeit das RAM ausgehen, so dass dieser rebootete. Das passiert nicht länger. Auch wurde die Performance beim Massenanlegen oder -löschen einer großen Zahl von Tunneln verbessert.

• Im vorangegangenen Firmwarerelease wurde eingeführt, dass ein Router nach Auftreten einer hohen Zahl von kritischen Fehlern im Routerlog automatisch neu startete. Leider wurde bisher auch der Ausfall einer der zwei Lüfter eines Routers fälschlicherweise als kritisch gelogged, weswegen nun alle Router, bei denen ein Lüfter ausgefallen war, alle paar Minuten rebooteten. Das Problem wurde behoben, in dem der Ausfall nur eines einzelnen Lüfters nun als "Alert" statt als "Critical" gelogged wird.

• Ein "invalid floating point error" konnte erscheinen wenn man im Download tool des Web interfaces die Option "Measure & discard" nutzte.

• Wenn man das PUTTY-Tool plink nutzt um eine Liste von Kommandos per CLI durch den Router ausführen zu lassen, wurden bisher carriage returns ignoriert, wodurch man immer nur ein Kommando ausführen konnte.
  
  Beispiel:
  plink -pw -batch -ssh -P 22 root@ -m commands.txt -v ERROR 140 ←[1m←[31mThis object does not exist←[0m
  
  Nun funktioniert dies sowohl mit CR als auch CR/LF als Kommandotrenner.

• Die CLI erlaubt es nun Unterobjekte anhand ihres Objekt-Indexes statt ihres Namens zu löschen - z.B. mit "execute DELETEITEM OBJECT__2"

• Die CLI schließt SSH-Verbindungen situationsabhängig nun korrekt. Damit wird es auch möglich SSH-Scriptingtools (z.B. Paramiko) zu nutzen, die pro Kommando einen neuen SSH-Subchannel öffnen.

• Mehrere Tippfehler im Webinterface wurden behoben.

• Das Timing von Hubs in einer Redundanzgruppe, welche beim Routerstart prüfen ob sie ersetzt wurden, ist nun deutlich robuster.

• BondingTCPOptimizer Verbindungen welche auf dem WAN packet loss ausgesetzt waren konnte insbesondere bei instabilen aber schnellen WAN-Verbindungen dafür sorgen, dass aufgrund fehlernder Pakete und Retransmissions sich beim empfangenden Router große Mengen an Daten aufstauten. War der Datenstrom durch Retransmission dann vollständig, wurden diese Daten mit einem Schlag ins LAN weitergeleitet, teilweise mehrere Megabyte. Das sorgte für eine große Trafficspitze im LAN, womit nicht alle Geräte in einem LAN besonders gut klarkamen. Auf dem Router war dies als "XX packets have been dropped reading from LAN" Nachricht zusehen. Die Pakete werden in der oben genannten Situation nun langsamer ins LAN geleitet, wodurch diese Spitzen deutlich abgemildert werden.

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

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

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

Hier eine Liste aller Änderungen:

Verbesserungen:

• Der integrierte Bootloader des Multichannel VPN Router 500 verwendet nun Error Correction Codes. In der Vergangenheit haben wir defekte Router gesehen, die aufgrund von Bitfehlern auf dem verwendeten Flashspeicher nicht mehr starteten (in diesem Falle ging die Power-LED noch an, sonst geschah aber nichts mehr). Solche Bitfehler werden nun korrigiert. Mit dieser Verbesserung sollten Totalausfälle bei diesem Produkt nun nicht mehr vorkommen.

• Die Router/Hubs behalten nun den State aller Verbindungen (inkl. NAT-State) bei, wenn ein Tunnel abbricht. Wenn der Tunnel innerhalb von 3 Minuten wieder verbindet, wird all state wieder hergestellt. In früheren Firmware-Releases verursachte ein totaler Tunnel-Disconnect (alle Channels disconnected), oft, dass Verbindungen durch den Tunnel nach Tunnel-Reconnect hängen blieben; das passiert nun nicht mehr, sofern der Tunnel innerhalb von 3 Minuten wieder verbunden ist. Das ist eine deutliche Verbesserung, speziell in sich bewegenden Fahrzeugen, die in eine sog. "Dead Zone" ohne Mobilfunkempfang hinein fuhren. Wir waren nun in der Lage, stundenlange Testfahrten durch Wälder etc. zu machen, ohne dass unsere Verbindungen durch den Tunnel auch nur einmal resetted wurden.

• Der BondingTCPOptimizer-Modus wurde auch um einiges verbessert. Vorher hatte er Kompatibilitätsprobleme, speziell bei Verbindungen durch mehrere BondingTCPOptimizer-Tunnel (Standortvernetzung). Außerdem wurde die Leistung dieses Modus um einiges verbessert. Wir empfehlen nun, den BondingTCPOptimizer für jeglichen TCP-Traffic zu nutzen, wenn Sie Verbindungen mit hohen Latenzen bündeln, selbst bei Standortvernetzungen, da dieser Modus den erreichbaren Durchsatz signifikant verbessert.

• Die Leistung für den Router 500 wurde enorm optimiert. In den meisten Situationen wurde der maximale gebündelte Durchsatz um über 30% erhöht.

• VLAN-IDs können nun für "additional LAN Routes" konfiguriert werden.

• Für LAN Aliases bei zugewiesener VLAN ID kann nun ein Default Gateway zugewiesen werden. Bei dieser Konfiguration wird die Segmentation ID für Traffic, der vom entsprechenden Tunnel kommt, direkt zu diesem Default Gateway geleitet, während das LAN Interface (VLAN 0) nicht mehr genutzt wird (und dieser Tunnel ist vom VLAN 0 auch nicht mehr erreichbar).

• Diese zwei neuen Features ermöglichen es ISPs/BSPs, pro Kunde ein dediziertes VLAN auf dem Hub zu haben, eine Eigenschaft, die von zahlreichen Service Providern gewünscht wurde.

• Das Web-Konfigurationssystem loggt nun Benutzer-Logins/-Logouts/-Fehler.

• Ein neues Set an QoS-Regeln und -Klassen wurde geschaffen. Web-Surfen benutzt standardmäßig Bonding; für hoch-latenziertes Bündeln sollte diese Einstellung auf BondingTCPOptimizer geändert werden. RTMP-Stream nutzt standardmäßig immer BondingTCPOptimizer. Die Regeln für RTP/VoIP wurden geändert, um ToS zu entsprechen und generieren daher weniger False Positives. Außerdem unterstützen sie nun Video-Conferencing. Die VoIP-QoS-Klasse nutzt nun Lossy Bonding, wenn eine Lizenz dafür eingetragen wurde. Um diese neuen Regeln nutzen zu können, müssen Sie "QoS rules and classes templates" anwählen und "Restore Manufacturing Defaults" ausführen. Dann müssen Sie bei jedem Tunnel "Copy QoS templates to here" auswählen. Diese Schritte müssen Sie sowohl beim Hub als auch beim Router ausführen.

• Es gab mehrere Buffer-Tunings. In vielen Setups wird sich dadurch der Durchsatz verbessern, speziell für Verbindungen, die den "Bonding"-Modus nutzen. Außerdem wurde die Leistung für hochlatenzierte Verbindungen und Verbindungen mit einem hohen Bandwidth-Delay Product (Satellit) verbessert.

• Die Konfiguration von Ethernet Auto-Negotiation-Settings wird nun für Fast & Gigabit Ethernet Module unterstützt.

• Bei hochlatenzierten Verbindungen (GPRS, Satellit) werden die Passive und Hybrid Autotuning Modi nun die Geschwindigkeit wesentlich langsamer erhöhen, sodass die Verbindung nicht überladen wird ohne dies zu spät zu bemerken.

• Der Router kann nun vom LAN unter dem Hostname "viprinet.router" erreicht werden.

• Das "Resource Reservation Protocol" (RSVP) kann nun durch Viprinet-Router geroutet werden.

• Die Min and Max Befehle in der CLI funktionieren nun, und zeigen die minimal/maximal zulässigen Werte für eine Einstellung an.

• Die CLI zeigt nun bessere Datentypennamen beim LIST-Befehl an.

• Für LTE-Module wird die Signalstärkeninformation im Monitoring-Tool nun konstanter aktualisiert.

Fehlerbehebungen:

• Crash Bugs in der CLI in Zusammenhang mit Disconnects, während noch eine Antwort an den Client unterwegs war, wurden behoben.

• Tab-Vervollständigung in der CLI funktioniert nun auch für die VALUES-, MIN- und MAX-Befehle.

• Eine Änderung der WAN IP-Adresse an VPN Hubs unter Nutzung des Hub-Redundanzsystems konnte bewirken, dass anschließend das Webinterface des Routers hing und nicht mehr erreichbar war.

• Hubs im Hotspare-Modus haben bisher alle optionalen Hub-Features als unlizensiert angezeigt. Es erscheint nun ein Hinweis, dass dies im Hotspare-Modus irrelevant ist.

• Der 500er-Router hat für das LAN-Interface weder die Ethernet-Parameter angezeigt, noch ließen sich diese konfigurieren. Beides funktioniert nun.

• TCP-Neuübertragungen, welche durch die "Retransmission multiplier"-Einstellung ausgelöst wurden, sorgten als Nebeneffekt dafür, dass Channels nicht mehr in den "Stalled"-Modus gingen. Dies wiederum bewirkte, dass solche Channel trotz überschreiten der "Maximum allowed latency" weiter genutzt wurden. Dieser Bug beschränkte insbesondere in bewegten Fahrzeugen die Performance.

• Die 5 Ghz Channel Auswahl im WLAN Access Point des Multichannel VPN Router 500 hat nicht richtig funktioniert, nur der erste Channel konnte korrekt ausgewählt werden.

• Im vorangegangenen Stable FirmwareRelease hat das Hub-Redundanzsystem nicht auf dem WAN-Interface gelauscht, sondern nur auf dem LAN-Interface. Das konnte eine "Split Brain"-Situation auslösen, wenn am Hub nur der LAN-Link ausfiel, während das WAN-Interface noch up war. Das Redundanzsystem nutzt nun wieder sowohl WAN- als auch LAN-Interface.

• Wenn unter 'Reset after minutes of downtime' ein Wert konfiguriert war, wurde das Modul selbst dann in diesem Intervall rebooted, wenn das Modul eigentlich deaktiviert war.

• Objekt-Referenzen (Ziele von QoS-Regeln, Verweise auf WAN-Module in den Channels etc.) lassen sich nun auch mit der CLI konfigurieren.

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

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

Hier ist eine Liste aller Änderungen:

• Behoben: In allen bisherigen Releases gab es Stabilitätsprobleme mit dem Hot-Plugging von LTE-Modulen. Das Ziehen von LTE-Modulen oder ein Modulreset im Webinterface konnte zu einem Reboot des Routers führen. Das war besonders ärgerlich, da bei der noch recht instabilen LTE-Technologie der Provider die automatische Modul-Reset-Funktion eigentlich sehr hilfreich wäre. Das entsprechende Problem wurde nun behoben, auch LTE-Module sind nun voll hot-plugging-tauglich.

• Behoben: Mit der Verfügbarkeit des Hub 5010 wurde das Produkt nun als zum Hub 5000 kompatibel in der Firmware erfasst. Sollten Sie Hub 5010 und Hub 5000 gemischt nutzen im Hotspare-Betrieb, so müssen Sie die aktuelle Firmware einsetzen.

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

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

Hier ist die Liste der Änderungen:

Fehlerbehebungen:

• Der neue LossyBonding mode, der über die Streaming Optimizations Lizenz optional verfügbar ist, war in allen bisherigen Firmware-Releases fehlerhaft. In vielen Fällen kam es dazu, dass beim Empfänger Packet Reordering auftrat, was bei vielen Anwendungen für Probleme sorgte. LossyBonding bringt nun die erwartete Performance, und wird für alle Applikationen, bei denen zeitkritischer UDP-Traffic über instabile Bündelungen transportiert werden soll (z.B. Videokonferenzen über gebündeltes UMTS) empfohlen.

• Unter bestimmten (seltenen) Umständen konnte es passieren, dass ein Stromverlust des Routers beim Speichern der Konfiguration zu Fehlern auf dem internen Flashspeicher führten. In diesen Fällen zeigte der Router nach dem nächsten Start als Seriennummer nur noch "XX-XXXXX-XXXXX" an, und war nicht mehr voll funktionsfähig.

• Auf dem Multichannel VPN Router 500 konnte es passieren, dass plötzlich sämtliche Module "verschwanden" und nicht mehr nutzbar waren. Das Problem lies sich nicht mit einem Reboot, sondern nur mit Aus/Anschalten der Stromversorgung des Routers beheben.

• Die NAT-Engine hatte Probleme mit diversen ICMP-Unterprotokollen. Das konnte dazu führen dass Traceroutes von genatteten IPs ausgehend teilweise nicht richtig funktioniert haben.

• Die Broadcast-Detection wurde verbessert. Wenn bei früheren Firmwarereleases ein Router an einem LAN hing, in dem es ein IP-Netz gab welches aber an dem Router selber lokal nicht anlag, hat der Router Ethernet-Broadcasts dieser Netze ebenfalls empfangen und diese dann verwertet - mangels lokal anliegendem Netz konnte er dabei aber nicht wissen, dass das ein IP-Broadcast ist und hat es auf den Tunnel geschickt. Das hat u.a. zu PacketHeap-Fehlermeldungen im Log geführt.

• Das interne Konfigurationssystem wurde um den Faktor 20 beschleunigt. Inbesondere bei Hub-Setup mit einer sehr hohen Zahl von VPN-Tunneln dauerte das Ändern von Einstellungen im Webinterface bisher sehr lange. Auch bei solchen Szenarien speichert das Konfigurationsystem entsprechende Änderungen nun viel schneller.

• Die Firmware des Multichannel VPN Router 500 hatte einen Speicherleck-Fehler, der dazu führen konnte, dass dieser Router nach wenigen Tagen automatisch rebootete.

• Der BondingTCPOptimizer Bündelungsmodus hatte einen Fehler, der äußerst selten (mit einer Wahrscheinlichkeit von 0.25^12%) auftreten konnte. In diesem Falle stürzte der Router ab und startete neu.

• Im Hub-Redundanzsystem hat das Entfernen einer Test-IP nicht dafür gesorgt, dass diese IP tatsächlich nicht mehr gepingt worden wäre. Stattdessen wurde die IP bis zum nächsten Routerneustart weiter angepingt.

• Traffic Accounting funktionierte auf dem Multichannel VPN Router 500 nicht richtig

• Auf dem Multichannel VPN Hub 5000 funktionierten eingehende VPN Tunnel Channel Verbindungen nicht mehr zuverlässig, wenn bereits über 200 Tunnel Channel verbunden waren.

• Diverse Bugfixes für die SNMP-Implementierung, insbesondere für Nutzer der erweiterten SNMP-Lizenz (AdminStatus gemäß MIB, Timestamp für Router Uptime)

• Wenn mehrere Module gleichzeitig einen Power-Reset erhielten (z.B. bei entsprechendem automatischem Reset) konnte es passieren, dass bei einigen der Module der Strom nicht wieder angeschaltet wurde, und das Modul dann bis zum einem Neustart des Routers nicht mehr nutzbar war.

Verbesserungen:

• Der Hybrid-Autotuning-Modus wurde stark verbessert und hat diverse Fehlerkorrekturen erhalten. Die Nutzung vom Hybrid-Autotuning-Modus wird für alle Mobilfunkverbindungen dringend empfohlen, da gute Messergebnisse mit geringem Trafficverbrauch kombiniert werden. Auch der passive Autotuning Modus wurde verbessert.

• Bei abgeschaltetem Latency-Autotuning ist die Dauer von Ping-Tests nun stark verkürzt. Bei manuell konfigurierten Latenzen für UMTS-basierte Channels kann dies bei sich schnell bewegenden Fahrzeugen für deutlich größere Nutzungszeiten für die sich ständig neu verbindenden Channels bewirken.

• Die vom Router zu verwendende Timezone kann nun unter "Logging & Maintenance" konfiguriert werden

• Die ARP-Implementation wertet jetzt auch aus dem LAN kommende IP-Pakete aus, um den Cache zu akualisieren. Dies sorgt dafür dass bei Geräten im LAN, die über längere Zeit nicht mehr aktiv waren bereits mit ihrem ersten Request nach außen dem Router wieder ihre MAC-Adresse mitteilen, wodurch bereits das erste Antwortpaket zugestellt werden kann. Dies bringt Vorteile in Zusammenhang mit einigen embedded TCP/IP stacks.

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

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

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

Hier ist die Liste der Änderungen:

Fehlerbehebungen:

• Mit dem vorherigen Stable-Release bleiben SNMP-Counter alle 50 Tage stehen. Der nächste Zeitpunkt, an dem dies geschehen wird, ist der 20. Juni 2012. Wenn Sie von diesem Problem betroffen sind, sollten Sie daher schnellstmöglich updaten.

• Hubs 5000 haben via SNMP fälschlicherweise immer eine CPU-Temperatur von 0°C angezeigt.

• Im vorherigen Stable-Release war die experimentelle SSH-CLI auf Port 22 standartmäßig angeschaltet. Nun ist der Werkszustand, dass dieser Service ausgeschaltet ist, und Port 22 geschlossen.

• Im vorherigen Stable-Firmware Release wurde eine Congestion Detection eingebaut, welche den MaxBandwidthToWAN-Wert eines Channels immer reduziert hat, wenn Packet Loss auf der Leitung erkannt wurde. Diese schnelle Reduzierung der Bandbreite hat das Latenzverhalten von Channeln auf instabilen WAN-Leitungen deutlich verbessert. Allerdings hat die Änderung gerade bei instabilen WAN-Leitungen auch dafür gesorgt, dass deutlich häufiger Bandbreitentests durchgeführt wurden. Dies wiederum hat dazu geführt, dass unser Stable-Release aus April im Vergleich zu früheren Firmware-Versionen deutlich mehr Datentraffic erzeugt hat für diese Tests. Dies wurde nun optimiert, die Menge des Testtraffics sollte wieder stark zurückgehen. Sollten Sie für Traffic viel Geld bezahlen (z.B. bei UMTS), sollten Sie schnellstmöglich updaten.

• Der Treiber für unsere neuen Gigabit-Ethernet-Module hatte diverse Probleme. Wenn Sie eine statische IP-Konfiguration mit diesem Modul nutzten, konnte es sein, dass die Link-Detection nicht richtig funktionierte. Dieses Firmware-Release verbessert die Stabilität der Gigabit-Ethernet-Module ganz erheblich.

• In allen vorangegangenen Firmware-Releases hatten die „Passive“ und „Hybrid“ Autotuning-Modi einen Bug, welcher dafür sorgen konnte, dass die Bandbreitenmessungen steckenblieben, wenn diese bei sehr niedrigen Geschwindigkeiten (200 KBit/s und darunter) starteten. In diesem Falle verblieb der Channel dauerhaft bei dieser niedrigen Geschwindigkeit. Dieses Problem konnte insbesondere beobachtet werden bei sich bewegenden Fahrzeugen, da hier häufig von UMTS zurück auf GPRS/EDGE geschaltet wird, welches sehr niedrige Bandbreiten erlaubt. Der Bug ist nun behoben, die „Passive“ und „Hybrid“ Autotuning-Modi funktionieren in diesen Situationen nun wie gewünscht. Sollten Sie diese Autotuning-Modi nutzen, sollten Sie unbedingt zeitnah auf die neue Firmware umsteigen.

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

Firmwareupdate 13.04.2012 - Version 2012032600/2012041000

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

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

• LTE-Module werden nun unterstützt und sind stabil. Verschiedene Probleme, die im vorherigen Cutting-Edge Release bestanden, sind nun behoben, inkl. Schwierigkeiten beim Hot-Plugging, Monitoring und bei Modul-Info-Fehlern. Die Übergabe zwischen UMTS ↔ LTE scheint nun auch in Real-Life-Szenarios mit sich bewegenden Fahrzeugen zu funktionieren.

• Module im Multichannel VPN Router 500 können nun auch konfiguriert werden, während sie im Zuge des Öffnens der SIM-Kartenhalters ausgeschaltet werden.

• Im vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101 konnte es passieren, dass sich Verbindungen, die den BondingTCPOptimizer nutzen, beim Unterbrechen eines Channels aufhingen. Das ist behoben.

• Aufgrund eines Problems mit SNMP-Encoding im vorherigen Cutting-Edge Firmware-Release 2012020100/2012030101 bekam man manchmal falsche Werte für 64bit-Zähler.

• Die Hub WAN Link Speed Detection, die als Parameter für Channel Autotuning genutzt wird, war defekt - sie erfasst nur die Geschwindigkeit, wenn das WAN keinen Ethernet-Link hatte. Daher berichteten Hubs immer nur 0 MBit/s.

• Die Einstellung "Enabled Mobile Technologies" wurde für alle Modultypen angezeigt. Nun wird sie nur noch für LTE-Module angezeigt.

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

Neue Features:

• Erweitertes SNMP benutzt nun seine eigene, dedizierte Viprinet MIB. Um Erweiteres SNMP zu nutzen, brauchen Sie eine Lizenz für Erweitertes SNMP. Die MIB können Sie hier downloaden: http://www.viprinet.com/downloads/viprinetmib.zip

• Ein Command Line Interface für Router kann nun über SSH auf Port 22 bezogen werden, wenn es vorher im Web Interface aktiviert wurde. Die Benutzernamen und Passwörter sind dieselben wie im Web Interface hinterlegt. Dies ist ein Beta-Feature; die CLI wird in kommenden Firmware-Releases verbessert werden.

• Sie können nun die Konfiguration eines Routers downloaden, indem Sie SFTP/SCP nutzen.

• Es ist jetzt möglich, die ARP-Tabelle von Ethernet-Geräten (LAN, WAN, WAN-Module) im Web-Interface einzusehen.

• Gigabit Ethernet-Module werden jetzt unterstützt.

• Für UMTS/HSPA-, UMTS/HSPA+-, CDMA- und LTE-Module gibt es nun im Web-Interface ein Tool, durch das manuell AT-Befehle eingegeben werden können. Dies kann zur Anpassung und Aktivierung benutzt werden, die in manchen Ländern / von manchen Mobilfunkanbietern gefordert wird.

• Ethernet Auto Negotiation Parameter können nun für LAN-Interfaces, für WAN-Interfaces auf Hubs und für Ethernet-WAN-Module konfiguriert werden.

• Wenn Sie eine Streaming-Optimierungs-Lizenz installiert haben, können Sie nun einen neuen Bündelungsmodus genannt "LossyBonding" nutzen. Dieser Modus ist optimiert, um UDP-Traffic zu bündeln. Im Gegensatz zu allen anderen Bündelungsmodi gewährleistet er keine verlustfreie Übertragung, daher kann es im gebündelten Tunnel zu Paketverlust kommen. Der Modus nutzt einen sich selbst optimierenden Dejitter-Buffer auf der Empfangsseite. Mit diesem Modus können extrem niedrige Latenzen mit minimalem Dejitter für kritischen UDP-Traffic und UDP-Anwendungen wie VoIP und Live-Videokonferenzen erreicht werden.

Verbesserungen:

• Ein neuer Satz an verbesserten QoS-Regeln und -Klassen wird mit diesem Release ausgegeben. Um diese zu aktivieren, müssen Sie die "Restore Manufacturing Defaults"-Funktion innerhalb des "QoS rules and classes templates"-Objekts benutzen, und danach die "Copy QoS templates to here"-Funktion in jedem Tunnelobjekt, für das Sie die neuen QoS-Klassen nutzen möchten. Das zu tun wird sehr empfohlen. Seien Sie vorsichtig, wenn Sie eigene QoS-Klassen erstellt haben, denn diese werden beim Kopieren überschrieben.

• Sich mit dem falschen Benutzernamen/Passwort per HTTP oder SSH einzuloggen verursacht nun eine zufällige Verzögerung, bevor ein Fehler ausgegeben wird. Das verlangsamt Brute-Force-Passwort-Attacken.

• Das Log-Format wurde so verändert, dass nun immer der VPN-Tunnelname für Channel-Meldungen mitgeliefert wird. Bis jetzt war es unmöglich herauszufinden, auf welchen Tunnel sich eine Meldung bezog, wenn mehrere Tunnel denselben Channelnamen hatten (was auf mehrfach genutzten Hubs üblich ist).

• Enorme Verbesserungen gibt es im Hinblick auf Buffer-Verwaltung und QoS. In Situationen, bei denen der Upstream durch Traffic komplett ausgelastet ist, ist das Ergebnis für Downstream-Traffic nun weitaus besser.

• Zu Testzwecken können Prüfungen hinsichtlich Verbindungsstabilität nun ausgeschaltet werden, indem ein entsprechendes Setting im "Performance finetuning"-Objekt eines Channels genutzt wird.

• Die Anzahl an durch Autotuning verursachten Logmeldungen wurde reduziert.

• Große Autotuning-Verbesserungen gibt es für gebündelte 3G-Mobilfunkmedien in sich bewegenden Fahrzeugen. Channel reagieren nun viel schneller auf kurze Netzwerkabbrüche und bauen Channel auch viel schneller wieder auf. Infolgedessen hat sich die Performance von Viprinet-Routern in sich bewegenden Fahrzeugen mit dieser Firmware enorm verbessert.

• Der BondingTCPOptimizer-Modus hatte Probleme mit vielen TCP-Implementierungen und -Anwendungen. Oft hing der BondingTCPOptimizer oder brach ganz ab, speziell bei SSL-basierten TCP-Verbindungen. Dies wurde um einiges verbessert. Wir empfehlen jetzt, den BondingTCPOptimizer für den gesamten TCP-Traffic zu verwenden, der über gebündelte Channel läuft, die hohe oder instabile Latenzen haben, z.B. Bündelungskombinationen von ADSL + UMTS.

Änderungen:

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

Fehlerbehebungen:

• Mehrere Memory Leaks wurden behoben.

• Wenn man 3 Channels hatte, von denen 2 als Backup konfiguriert waren, konnte es passieren, dass beim Ausfall des Nicht-Backup-Channels beide Backup-Channel gleichzeitig verbunden wurden. Das wiederum bewirkte, dass beide wieder getrennt wurden, da ja angeblich bereits ein Backup-Channel existierte.

• Ping und Ethernet-Hilfsprogramme zeigten keine Fehlermeldungen im Web-Interface an, wenn der zu testende Hostname nicht per DNS aufgelöst werden konnte.

• IP_IP- und IP_IPV6-Tunnel wurden nicht durch den VPN-Tunnel geroutet, sondern verworfen.

• Bis jetzt konnten alle Router erst dann per Setup-Tool auf Werkseinstellungen zurückgesetzt werden, wenn alle Module aus dem Router entfernt worden waren. Das funktioniert bei all jenen Produkten nicht mehr, die einen Reset-Button haben, um auf Werkseinstellungen zurückzusetzen. Sie müssen diesen drücken, anstatt die Module zu entfernen.

• Wenn man das 192.168.1.0/24-Netzwerk auf einem Router nutzte, funktionierten ADSL-Module nicht mehr korrekt (interner IP-Adress-Konflikt). Das ist behoben.

• Unter Umständen sah der Hub 5000 seine eigenen Pakete, die er zum LAN gesandt hatte, und gab einen "Incoming Packet from.. has incorrect TCP checksum"-Fehlermeldung aus.

• Ethernet-Broadcasts, die an ein IP-Alias-Netzwerk gerichtet waren, resultierten in einer Routing-Endlosschleife und brachten den Router zum Abstürzen, während jeglicher Traffic für mehrere Sekunden sichtbar war.

• Die maximale Größe des Backups einer Konfigurationsdatei wurde erhöht auf 10 MB. Bis jetzt war es unmöglich, die Konfiguration bei Routerinstallationen mit einer Vielzahl an Tunneln zu sichern und wiederherzustellen.

• Gratious ARP auf WAN-Interfaces litt unter einer Race Condition. Nach der Übernahme einer WAN-IP-Adresse konnte die Übergabezeit daher länger dauern, als für Hubs erwartet, da Upstream-Router nicht sofort über die neue MAC-Adresse der IP benachrichtigt wurden.

• Die Einstellungen für garantierte Bandbreite innerhalb von QoS-Klassen haben bis jetzt nicht vollständig funktioniert. Die Klasse erhielt mehr oder minder die garantierte Bandbreite. Nun funktioniert das perfekt. Achtung: Wenn Sie eine QoS-Klasse konfiguriert haben, die eine Garantie hat, welche größer als die gesamte gebündelte WAN-Kapazität ist, bedeutet das, dass Ihre anderen QoS-Klassen möglicherweise keinen Traffic machen dürfen, wann immer die QoS-Klasse mit der garantierten Bandbreite die volle Kapazität des gebündelten Tunnels nutzt!

• Wenn man eine QoS-Klasse kopierte, wurde die Minimum-Diversity-Einstellung nicht mitkopiert.

• Wenn an einer Seite eines VPN-Tunnels Channel-Verschlüsselung aktiviert wurde, auf der anderen Seite aber nicht, war aus den Logmeldungen nicht ersichtlich, dass das eine Fehlkonfiguration ist. Stattdessen brach der Channel immer wieder ab. Nun gibt es eine Logmeldung, aus der der Fehler klar hervorgeht.

• Den Reset-Knopf zu drücken funktionierte nicht bei Hubs, die sich im Hotspare-Modus befanden.

• ADSL-Module gaben manchmal eine falsche Meldung über Bandbreitenkapazität / Synchronisationswerte aus.

• Internal Early Retransmissions (einstellbar durch den Retransmission Multiplier in den Feineinstellungen für Channel) konnten zu einer "Kernschmelze" führen, wenn mehrere Verbindungen zur selben Zeit ausfielen (z.B. 3x ADSL desselben Anbieters, alle Leitungen zeigen gleichzeitig einen plötzlichen hohen Paketverlust aufgrund von Kabelinterferenzen). Das konnte dazu führen, dass keine Pakete übertragen werden konnten, weil alle Channels eine Retransmission versuchten über Channels, die ebenfalls Retransmission versuchten.

• Es gab zahlreiche Fehlerbehebungen bzgl. SNMP-Protokoll-Konformität und -Kompatibilität.

• SNMP nutzte ein gewisses Maß an CPU pro Tunnel, egal ob der Tunnel aktiv war oder nicht. Bei Hubs mit vielen Tunneln (50+) verursachte das hohe CPU-Load und daher schlechte Routing-Performance.

• Auf dem Modell 500 gab es ein verstecktes Geister-WLAN ohne SSID zusätzlich zum konfigurierten WLAN. Das war kein sicherheitsrelevantes Problem, da man sich zu diesem WLAN nicht verbinden konnte, aber es war irritierend.

• Auf dem Modell 500 funktionierte das Bridging zwischen LAN und WLAN nicht. Das ist nun behoben; Geräte auf dem LAN können WLAN-Geräte erkennen und umgekehrt.

• Auf dem Modell 500 funktionierte das Wechseln des AP-Modus von 5 GHz zu 2.4 GHz und zurück nicht, bis man den Router neu startete.

• Die LAN-IP-Konfiguration erlaubte CIDR-Notation, wodurch das Interface abstürzte.

• Hybrides und passives Autotuning ignorierten das Abschalten des Autotunings.

• Es gab zahlreiche Probleme im Hinblick auf Stabilität und Durchsatz, wenn man die Channel-Verschlüsselung auf dem Hub 5000 abschaltete. Auf dem Modell 500 bewirkte das Abschalten der Channel-Verschlüsselung, dass der Channel abbrach.

Auf dem Hub 5000 war die maximale Anzahl von Tunnelchannel auf 200 begrenzt. Diese Beschränkung wurde beseitigt.

Bekannte Beschränkungen:

• Hub 5000 / SNMP: OID for CPULoad gibt "" auf Hub 5000 aus.

• Hub 5000 / SNMP: Zähler für Tunnelchannel noch nicht implementiert (OID: 1.3.6.1.4.1.35424.1.6.2.1.9 and 1.3.6.1.4.1.35424.1.6.2.1.10)

• Hub 5000: Ethernet Auto Negotiation Parameter können nicht verändert werden.

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

Firmwareupdate 22.07.2011 – Version 2011020901/2011062701

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

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

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

Hier die Liste aller Änderungen:

• Behoben: Das interne Socket Buffer Tuning der Tunnelkanäle wurde im Mai-Release verändert, mit den oben genannten Konsequenzen. Dies wurde nun optimiert, das Socket Buffer Tuning baut nicht länger auf den "Maximum Bandwidth to WAN"-Wert, sondern richtet sich immer aktuell nach dem "Current Bandwidth to WAN"-Wert. Dies sorgt für eine optimierte Latenz bei Channels mit hoher Maximalbandbreite.

• Behoben: Die Logmeldung eines VPN Hub im Hotspare-Modus mit Bezug auf Paketverlust-Vergleichen war fehlerhaft. Statt einer Prozentangabe für den Paketverlust wurde die IP-Adresse ausgegeben. Dies wurde korrigiert.

• Behoben: Wenn unsere Traffic Accounting API mit einem VPN Hub mit einer großen Zahl konfigurierter VPN Tunnel genutzt wurde, konnte im Log die Meldung "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" erscheinen, damit konnten Traffic Accounting-Einträge verloren gehen. Dies wurde behoben, wir unterstützen nun ein deutlich größeres Backlog.

• Behoben: Die Logmeldung "Unable to submit traffic accounting data to server with URL..." gibt nun tatsächlich eine URL aus. Dies hilft beim Debugging eigener serverseitiger Implementierungen unserer API.

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

Firmwareupdate 16.05.2011 – Version 2011020901/2011051700

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

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

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

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

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

Firmwareupdate 11.05.2011 – Version 2011020901/2011051001

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

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

Liste der Verbesserungen und Fixes:

• Behoben: Kürzlich hat ein Dritthersteller ein Produkt auf den Markt gebracht, welches einen kaputten TCP/IP-Stack enthält. Dieser TCP/IP-Stack sendet gelegentlich kaputte TCP-Pakete. Leider ist unser BondingTCPOptimizer für diesen Fehler anfällig - entsprechende Pakete können den Bündelungsmodus in eine Endlosschleife schicken, was letztendlich zum Ausfall des Routers führt. Sollten Sie den BondingTCPOptimizer nutzen, ist dies ein kritisches Problem. Das Problem wurde behoben, der BondingTCPOptimizer ist nun sehr robust gegen alle bekannten Attacken gegen das TCP-Protokoll.

• Behoben: Die neuen Channel Autotuning-Modes "Hybrid" und "Passive" betrieben weiter Autotuning, auch wenn dieses für den Channel abgeschaltet war.

• Behoben: Unter seltenen Bedingungen (insbesondere beim VPN Client) konnte es vorkommen, dass das Bandbreiten-Autotuning ein negatives Bandbreitenergebnis lieferte.

• Behoben: Es gab eine sehr hohe Last an ARP-Paketen auf dem LAN-Interface. In vielen Setups wurden deutlich mehr ARP-Pakete durch den Router versendet, als eigentlich nötig gewesen wäre.

• Verbesserung: Die Performance und Latenz von Channeln, die unter Volllast stehen, wurde verbessert, dies betrifft insbesondere Channel mit einer Bandbreite von <500 KBit/s.

• Verbesserung: Die Monitoring API wurde auf die neue Version v3 aktualisiert. Wenn Sie das aktuelle Monitoring-Tool von unserer Website verwenden, können Sie in diesem nun neben Informationen zu den Channeln auch Zusammenfassungen für den gesamten Tunnel sehen. Die bisherige Monitoring-Version v2 wird weiter unterstützt, entsprechende alte Tools funktionieren also weiterhin.

• Verbesserung: Eine zusammenfassende Information zu Bandbreiten ist nun Teil des Tunnel-Objekts im Webinterface.

• Behoben: Das Webinterface hat manchmal einen "Internal Error" geloggt.

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

Firmwareupdate 25.02.2011 – Version 2011010901/2011022500

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

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

Liste der Verbesserungen, neuen Features und Fixes:

• Verbesserung: Verbesserte Performance für High-Bandwidth setups. Für Nodes und Hubs die mit hoher Bandbreitenlast (>50 MBit/s) arbeiten konnte es vorkommen dass der integrierte LAN-NIC unter Umständen einen geringen Packet Loss im LAN verursachte. Dies wiederum konnte vor allem bei WAN-Strecken mit hoher Latenz für eine Beschränkung des maximal real durch den Tunnel zu realisierenden Durchsatz bedeuten. Das Problem wurde behoben, Packet Loss am LAN-Interface sollte (abgesehen von echten Störungen im LAN) nun nicht mehr auftreten.

• Verbesserung: In früheren Releases konnte der vom "Bandwidth Autotuning" erzeugte Datenverkehr die für realen Nutztraffic vorhandene Bandbreite stark limitieren - der Autotuning-Traffic "frass" quasi die Bandreite weg. Jedes Mal wenn ein Channel ein "Bandwidth Autotuning" durchführte, sank dadurch der nutzbare Gesamtdurchsatz des Tunnels. Dies war insbesondere ein Problem, wenn sich im WAN-Bündelungsverbund ein oder mehrere instabile WAN-Links befanden, die sehr häufig Autotuning-Tests erfordern. In der Praxis konnte es so passieren, dass eine Bündelung z.B. aus 2x ADSL und 1x UMTS weniger Durchsatz brachte als 2x ADSL alleine. Das Verfahren hierzu wurde komplett verändert. Mit dieser Firmwareversion wird Autotuning-Traffic nun immer nur die Bandbreite nutzen, die aktuell nicht von realem Traffic gebraucht werden könnte. Autotuning-Traffic beeinflusst damit nun nicht länger die real nutzbare Bandbreite. In Szenarien wo eine oder mehrere WAN-Anbindung instabil sind, wird sich die Performance in der Praxis erheblich verbessern und die nutzbaren Bandbreiten stabiler sein als je zuvor.

• Neues Feature: Wenn ein Channel zusammenbrach, war es bisher so, dass Nutztraffic der in der Bündlung diesen Channel mitnutzte stockte, bis der Channel in den Status "ConnectedStalled" wechselte. Dies lag daran, dass eine interne Retransmission erst ausgelöst wurde, wenn der Channel den Status "ConnectedStalled" hat - je nach Ergebnis des Latency Autotunings konnten so bei Channelabbrüchen Aussetzer von bis zu 1500ms im realen Nutztraffic entstehen. Zusätzlich hierzu kann der Router nun bereits vorab spekulativ Retransmissions durchführen, bevor der Channel in den "ConnectedStalled"-Status gewechselt hat. Per default wird nun eine Retransmission ausgelöst, wenn der Channel aktuell die vierfache Latenz des "Optimal Latency"-Wertes hat. In der Praxis reduzieren sich damit die Aussetzer beim Wegfall eines Channels erheblich. Der Multiplikator für diese Retransmission ist konfigurierbar. Die Einstellung dazu findet sich unter "Performance finetuning" im Channel Objekt.

• Neues Feature: Für alle channels und tunnels werde nun interner Statistiken zur Stabilität geführt. Hier fließt ein, wie oft der Channel bzw Tunnel in letzter Zeit disconnected war, wie oft ein Channel in den "ConnectedStalled" status gewechselt hat, und wie häufig und wie intensiv Paketverluste aufgetreten sind. Der Stabilitätswert wird sowohl im Monitoring-Tool als auch im Webinterface angezeigt.

• Neues Feature: Der BondingDiversity bonding modus wurde dramatisch verbessert. Mit bisherigen Firmwareversionen wurden immer, egal wie stabil oder instabil die Channel waren, so viele Diversity-Kopien jedes Paketes versandt, wie noch Bandbreite auf den Channeln verfügbar war - in vielen Fällen wurde als jedes Paket über jeden Channel geschickt (5 Kopien). Das bedeutete eine Menge zusätzlichen Traffic, was inbesondere bei teuren UTMS-Kanälen ein Problem darstellte. Der mit dieser Firmwareversion deutlich verbesserte BondingDiversity-Modus ändert dieses Verhalten: Es gib nun eine "Minimum diversity" sowie eine "Maximum Diversity" Einstellung, wodurch sich festlegen lässt, wieviele Kopien eines Paketes Minimal und Maximal versendet werden sollen. Der tatsächlich genutzte Wert wird dabei automatisch zwischen diesen Grenzen festgelegt. Hierbei wird berücksichtigt, wie stabil die genutzten Channels aktuell sind. Sind die Channels instabil (z.B. in einem bewegten Fahrzeug unter Nutzung von UMTS), werden mehr Kopien versandt, sind die Channels stabil, weniger. Wir empfehlen den BondingDiversity mode nun nachdrücklich für jede Art von Applikation, bei der über sehr instabile WAN-Links eine stabile Latenz und Bandbreite erreicht werden soll (z.B. Streams, VoIP, Could Computing). Die Nutzung des "BondingDiversity"-Modes erfordert eine "Streaming Optimizations" Lizenz pro Router, welche Sie auch nachträglich erwerben können.

• Feature entfernt: Der "Bestchannel" bonding modus wurde entfernt - er war in allen Einsatzszenarien dem "Bonding"-Modus weit unterlegen und seit langer Zeit schon nicht mehr zur Nutzung empfohlen. Die QoS-Einstellung "Latency Priority", die nur für diesen Modus Anwendung fand, wurde ebenfalls entfernt.

• Feature entfernt: Die "Minimize AutotuningTraffic" option wurde entfernt. Wenn Traffickosten für einen Channel wichtig sind, verwenden Sie bitte stattdessen den "Hybrid" (empfohlen) oder "Passive" (wenn jedes Byte zählt) modus, welche beide deutlich bessere Ergebnisse bringen.

• Verbesserung: Die Dokumentation der "Channel Finetuning" Einstelllungen im Web interface wurde deutlich ausgeweitet, es sollte nun deutlich klarer sein welche der Einstellungen ggf. stark negative Auswirkungen haben können.

• Verbesserung: Hubs die das Hub Redundanzsystme nutzen, starten nun deutlich schneller. Im Bereich des Redundanzsystems wurden zudem zahlreiche kleinere Fehler behoben, die Zuverlässigkeit des Systems wurde deutlich erhöht.

• Neues Feature: Innerhalb des Tunnel Objekts existieren nun Statistiken über die aktuell insgesamt für diesen Tunnel nutzbare Up- und Downstreambandbreite. Zudem gibt es einen Satz Statistiken zur dauerhaft als stabil anzusehenden Bandbreite. Diese wird dadurch ermittelt, dass die verfügbare Up- und Downstreambandbreiten von instabilen Channeln nicht mitgezählt werden. Für diese Statistiken werden wir in Kürze auch eine API zur Fernabfrage anbieten, welche z.B. für Hersteller von Videocodecs genutzt werden kann, um die Streambandbreite dynamisch anzupassen. Bitte kontaktieren Sie unser Supportteam bei Interesse an dieser API.

• Fixed: Nach einem Powercycle konnte es vorkommen, dass ADSL-Module nicht korrekt erkannt wurden. In diesem Falle wurde der jeweilige Slot im Webinterface als leer angezeigt. Das Problem wurde behoben, ADSL-Module sollten nun immer erkannt werden.

• Fixed: Das Traceroute tool im Webinterface hat nicht korrekt für das LAN interface funktioniert.

• Fixed: Ein sehr selten auftretender Bug konnte theoretisch für Reboots des Routers sorgen.

• Fixed: Die Kombination aus einem Port Forwarding am Hub, welches auf einen Host hinter einem VPN Node verwies mit der Nutzung von LAN aliases oder VLANs am Node konnte zu Problemen bei der Erreichbarkeit der Hosts hinter dem Port Forwarding führen. Der Router sendete in diesem Fall inkorrekte "ICMP Redirect" Pakete.

• Fixed: Die ARP Implementierung für das LAN-Interface von Hubs und Nodes hatte diverse Probleme. Wenn eine IP innerhalb des LANs von einem PC zu einem anderen übertragen wurde (sich also die MAC-Adresse der IP änderte), konnte es passieren dass diese IP anschließend durch den Node nicht mehr erreichbar war. Dieses und weitere Probleme in Bezug auf den ARP Cache wurden behoben.

• Fixed: Statische DHCP Einträge funktionierten nicht, wenn mehr als ein statischer DHCP-Eintrag angelegt wurde.

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

Firmwareupdate 10.01.2011 – Version 2011010401/2011011003

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

Hier die Änderungen im Einzelnen:

• Fixed: Die Releases vom 2. und 29. Dezember enthielten beide einen kritischen Memory Leak Fehler. Router unter hoher Last (mehrere tausend gleichzeitige Verbindungen durch den VPN Tunnel) konnten nach Tagen oder Wochen des Betriebes dadurch Fehlverhalten zeigen oder rebooten. Dieses Problem ist nun behoben.

• Fixed: Der Release vom 29. Dezember gibt den vollen VPN Tunnel setup Dialog in das logfile aus. Für Verbindungen von VPN Nodes mit einer Firmware von vor Dezember 2010 sowie für Verbindungen von VPN Clients bedeutet das, dass das geheime Tunnel-Passwort im Klartext im Logfile zu lesen ist, was natürlich ein Sicherheitsproblem darstellt. Das Problem wurde behoben, der Dialog wird nicht länger gelogged.

• Fixed: VPN Hubs haben auf ICMP pings auf ihrem LAN-Interface mit mehreren ICMP-Replys geantwortet (mit Windows ping nicht sichtbar).

• Neues Feature: Es ist nun möglich statische DHCP leases auf VPN Nodes zu konfigurieren.

• Neues Feature: Es ist nun möglich sich auf VPN Nodes die aktuelle DHCP lease table anzeigen zu lassen.

• Neues Feature: Die DHCP lease time ist nun konfigurierbar.

• Fixed: Das VPN Hub Redundanz-System hatte eine ganze Reihe von Problemen und Bugs. Das System ist nun auch bei einer hohen Anzahl von VPN Hubs und in mehr Ausfallszenarien sehr viel stabiler als zuvor.

• Fixed: VPN Hubs im "Hotspare"-Modus konnten keine DNS-Auflösung vornehmen, damit war auch ein Online-Firmwareupdate von "Hotspare"-Routern unmöglich.

• Fixed: Alle Datei-Uploaddialoge (QoS Config restore, config restore, firmware upload) ließen den Upload beliebig großer Dateien zu, was im schlimmsten Falle zum Reboot des Routers führen konnte. Unsinnige Dateigrößen werden nun abgefangen.

• Verbesserung: Die SSL Fehlermeldungen im Logfile sind jetzt klarer zu verstehen als zuvor.

• Fixed: Das Download test tool hatte mehrere kleine Probleme. Insbesondere bei Verbindungen zur HTTP Servern, die "Chunked Encoding" nutzen, waren die Messergebnisse falsch. Das Download test tool bricht jetzt automatisch ab, wenn durch dessen Nutzung die CPU-Last des Routers so hoch wird, dass die Performance der VPN Tunnel beinträchtigt werden würde (wodurch die Messergebnisse ohnehin unbrauchbar würden).

• Fixed: Die neuen Autotuning modi "Hybrid" und "Heuristic" hatten nach längerer Betriebsdauer u.U. Probleme. Dies konnte zu Messergebnissen von 0/0 KBit/s Up-/Downstream oder auch zu "Internal Errors" im Logfile führen.

• Fixed: Es war möglich eine gesicherte Konfigurationsdatei auf einen Router hochzuladen, der mit dieser Konfigurationsdatei gar nicht kompatibel war. Das Problem ist nun behoben. Die folgenden Produkte sind zueinander bzgl. Konfigurationsfiles kompatibel: Multichannel VPN Hub 1000/2000/5000, Multichannel VPN Router 1600/1610/2610. Die Konfiguration des Multichannel VPN Router 300 ist mit keinem anderen Produkt kompatibel.

• Fixed: VLANs zur Verwendung von VDSL-Modems an Ethernet-Modulen funktionierten nicht richtig.

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

Firmwareupdate 29.12.2010 – Version 2010112901/2010122800

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

Folgende Punkte wurden im Einzelnen repariert:

• Neues Feature: Die Router unterstützen nun die neuen CDMA/EV-DO module, welche für Kunden in Nordamerika verfügbar sind.

• Der SNMP Service hatte im Betrieb Probleme mit einer fehlerhaften SNMP Anfrage. Diese konnten zu einer Betriebsverweigerung führen. Dies ist nun beseitigt.

• Falls DHCP als DHCP relay konfiguriert worden ist, wurde dieser Service nach einem Reboot nicht mehr automatisch gestartet. DHCP Relay musste hingegen manuell im Webinterface neu gestartet werden. Dies ist nun beseitigt, auch nach einem Neustart wird DHCP relay automatisch starten.

• Eine Vielzahl von HTTP/HTTPS Attacken auf das Webinterface führten zu internen Fehlermeldungen in den Logs. Diese waren und sind unkritisch. Die Zahl an Attacken, die potenziell diese Fehlermeldungen auslösen können, wurde verringert.

• Die neue "Heuristic" Autotuning Methode konnte bei Verwendung instabiler Links zu internen Fehlern führen. Diese internen Fehler konnten potenziell zu verringerter Performance oder, im schlimmsten Falle, zu nicht erreichbaren VPN Nodes führen. Dieser Fall ist nun beseitigt.

• Fehlermeldungen zu SSL Verbindungen werden künftig deutlicher machen ob sie VPN Tunnelverbindungen oder Webinterface-Verbindungen zuzuordnen sind.

• Eine Reihe von "Debug" Log-Meldungen wurden beseitigt.

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

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

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

New features:

• Huge performance increase: Compared to previous releases, the total bonded VPN throughput a router/hub can do has increased by about 30%.

• User rights management system in AdminDesk - you now may create groups and users who only have read/write rights for certain objects. This can be used to enable customer access to their tunnel's settings only.

• VPN Hub: You now may create port forwardings mapping destination IPs at the VPN Hub to private IPs behind VPN Tunnels

• WAN VLAN Support: The Ethernet WAN modules now can use VLAN tagging. This is useful e.g. for external VDSL modems that require tagged Ethernet frames

• VPN Hub: LAN/LAN alias VLAN support. You now may use multiple VLANs at the LAN interface of a VPN Hub. The main IP configured in LAN Settings always will be sent untagged (VLAN0) and serves as access to the public internet. Traffic going there from the Tunnels matching a NAT rule will be NATted. In addition, LAN aliases may use tagged VLANs. This way it becomes possible to have dedicated networks

• "Tunnel segmentation" - similar to VLANs, you may group multiple tunnels by assigning them the same tunnel segmentation ID. Internally, all tunnels with a different segmentation ID are completely separate. This makes it possible to have multiple customers with multiple sites each terminated on one VPN Hub, where all sites per customer can see each other, but customers can't see other customer's networks. It is even possible to have multiple customers use the same private IP network - e.g. two customers that both use 10.0.0.0/8. If the tunnel segmentation ID chosen is the same as a VLAN ID assigned on a LAN interface, then traffic from all tunnels with this ID may exchange traffic with these VLANs, with all other customers not being able to reach the VLAN. Using this in combination with a VLAN-enabled switch at t