Firmware Release February 6th, 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 December 10th, 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.

Verbesserungen

  • The integrated system bootloader of the 500 router now uses error correction for its flash memory. In the past, we have seen RMA-ed 500 routers that had recoverable errors on the bootloader. Such a router would on power-on only have the power led going on, with nothing else happening besides that. With this improvement, these total failures will be a matter of the past.
  • The Routers/Hubs will now keep state of all connections including NAT state if a tunnel disconnects. If the tunnel reconnects within 3 minutes, all state is restored. In previous firmware releases, a full tunnel disconnect (all channels disconnected) would often cause connections going through the tunnel to hang after tunnel reconnect; now it no longer does so if the tunnel comes back within 3 minutes. That's a huge improvement especially in moving vehicles that enter a "dead zone" with no mobile network reception at all. We were now able to do test drives for hours through forests etc. without ever having our connections going through the tunnel getting reset.
  • The BondingTCPOptimizer mode has been improved a lot. Before, it had compatibility issues, especially if a connection went through multiple BondingTCPOptimizer tunnels (site-to-site VPNs). Also, the performance of this mode has been improved a lot. We now recommend to use BondingTCPOptimizer for any TCP traffic when bonding links with very high latencies, even for site-to-site VPNs, as it will improve achievable throughput a lot.
  • Performance for the 500 router has been optimized a lot. In most situations, the maximum amount of bonded throughput is increased by over 30%.
  • VLAN IDs may now be configured for additional LAN routes.
  • LAN Aliases if a VLAN ID is assigned now may optionally have a default GW. If this is configured, then for traffic coming from the respective tunnel, segmentation ID will go to that default gateway, while the LAN interface (VLAN 0) will no longer be used (and that tunnel will no longer be reachable from VLAN 0).
  • The two new features above together allow ISPs/BSPs to have a dedicated VLAN on the Hub per customer, a feature requested by multiple service providers.
  • Webconfig system now logs user logins/logouts/errors.
  • A new set of QoS rules and classes has been created. Web surfing by default still used Bonding, for high-latency bondings this should be changed to BondingTCPOptimizer. RTMP stream always uses BondingTCPOptimizer by default. The rules for RTP/VoIP have been changed to match on ToS and therefore generate less false positives, and to also support video conferencing. The VoIP QoS class now uses Lossy Bonding if a license for that is available. To use the new rules, you need to go to "QoS rules and classes templates" and execute "Restore Manufacturing Defaults", then go to each tunnel and select "Copy QoS templates to here". You need to do this on both, the Hub and the Router!
  • There have been several buffer tunings going on. In many setups, throughput will improve, especially for connections using the "Bonding" mode. Also, performance for high-latency links and links with a high bandwidth-delay product (Satellite) has been improved.
  • Configuring ethernet auto-negotation settings is now supported for Fast & GigabitEthernet modules.
  • For high latency links (GPRS, Satellite), the passive and hybrid autotuning modes will now increase speed much slower so that the link is not overloaded without noticing it late.
  • The Router may now be reached from the LAN using the hostname "viprinet.router".
  • The "Resource Reservation Protocol" (RSVP) can now be routed through Viprinet Routers.
  • Min and Max commands inside CLI now work.
  • CLI is now displaying nicer datatype names on LIST.
  • LTE module signal info inside the monitoring tool is now updated more constantly.

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