Viprinet Multichannel VPN Router 2610 RuggedVPN Firmware

Software captura de pantalla:
Viprinet Multichannel VPN Router 2610 RuggedVPN Firmware
Detalles de software:
Versión: 2016100640/2016102400
Fecha de carga: 15 Nov 16
Promotor: Viprinet
Licencia: Libre
Popularidad: 41
Tamaño: 25755 Kb

Rating: nan/5 (Total Votes: 0)

Si desea actualizar desde un firmware clásico, primero actualice el enrutador a la última versión de firmware clásica estable (Versión 2015081830/2015102900 publicada el 27 de noviembre de 2015). Tenga en cuenta que la actualización de su firmware de Classic a RuggedVPN requiere una licencia de mantenimiento de Viprinet Lifetime para estar en su lugar. Es posible tener enrutadores y concentradores que funcionan en el firmware clásico se conectan a un dispositivo que ejecuta firmware RuggedVPN. Sin embargo, se utilizará un modo de compatibilidad en este caso, lo que limita el rendimiento y las características.

Por lo tanto, no se recomienda utilizar una configuración de este tipo en la producción de forma permanente, pero está bien que un dispositivo de firmware clásico hable con un dispositivo de firmware RuggedVPN mientras se están actualizando estos dispositivos. El Software VPN Client ahora está basado en Classic Firmware, y por lo tanto se conectará en modo de compatibilidad. Un cliente VPN basado en RuggedVPN estará disponible pronto.

Correcciones de errores:

- La desconexión / desconexión del canal no ha estado limpia por un tiempo. Sospechamos que esto podría haber llevado a fallos del sistema. En situaciones menos fatales, se produjeron errores de SSL al desconectarse, o los canales tuvieron tiempo de espera de hasta 5 segundos en lugar de desconectarse de forma inmediata.

- En ciertos productos (310, 2620, 2030, 5000, 5010) el motor de cifrado de hardware podría bloquearse durante las desconexiones de canal. Creemos que este error es la razón por la que los clientes que ejecutan routers bajo alto estrés (conexiones de satélites, barcos, vehículos con un montón de reconexiones) están viendo reiniciar los dispositivos, mientras que otros no lo hacen.

- Los esclavos de apilamiento fijos que tienen una MTU calculada & # x3c; 1500 no obtener ese MTU utilizado. Esta fija los canales de esclavo en un esclavo de 500 apilamientos (o cualquier cosa que usa PPP) no se acostumbre.

- Conexión automática fija al servidor de licencias, que no funcionaba antes (tenías que conectarte manualmente a las licencias actualizadas recibidas)

- Revertir de nuevo a no marcar directamente para los módulos LTE, sino modificando el perfil para activar la llamada. Esto significa que esos clientes se quejaron de problemas con los APN privados antes de la actual versión estable ahora tendrán estos problemas de nuevo, pero pueden utilizar la función de perfil WWAN personalizada para evitarla. Tuvimos que revertir esto porque con la nueva forma de marcar a Verizon en los Estados Unidos no funcionaba en absoluto, y también se han reportado problemas del Reino Unido.

- Corregido los routers de demostración y proyecto no pudiendo utilizar los canales esclavos de apilamiento. Tenga en cuenta que debe volver a seleccionar el módulo WAN remoto dentro del canal después de actualizar a este firmware fijo.

- Se ha corregido el mensaje emergente en los routers de demostración para no decir que la demostración se ejecuta sólo 14 días, pero correctamente decir que es de 90 días.

- Volver a factorizar la forma en que se gestionan las estadísticas sobre la fuente de flujo y los destinos de host. Antes de que un ataque DDoS usando direcciones IP falsas pudiera consumir toda la memoria RAM y un montón de rendimiento. El sistema ya no puede ser puesto fuera de servicio inundándolo con direcciones IP falsas, y en general también se comporta mejor en situaciones en las que una enorme cantidad (1000+) de dispositivos LAN están usando un enrutador Viprinet.

- En el caso de cierto tipo de ataques DoS, el hilo de enrutamiento potencialmente podría haber quedado atascado, haciendo que el enrutador reinicie alrededor de 90 segundos.

- En caso de que se detecte un ataque DDoS como probable, los mensajes en este se registran, al máximo una vez por minuto.

- Se ha corregido un error en el manejo de la memoria de paquetes IP. Este error podría causar una pequeña pérdida de memoria se acumulan con el tiempo, pero también podría causar accidentes en determinadas circunstancias.

- La configuración de una dirección IPv6 como dirección IP principal de la LAN (en lugar de agregar la dirección V6 como un alias) no estaba soportada, pero no se evitaba, lo que podría hacer que el enrutador se volviera inaccesible desde la red. Ya no es posible establecer una dirección IPv6 como la dirección principal de la interfaz LAN.

- El gestor de retransmisión utilizado para las clases de QoS con "Garantía de entrega" habilitado tenía un bug que, en primer lugar, estaba goteando memoria, pero también podría haber provocado que la mitad de las retransmisiones no tuviesen lugar. Esto significa que un flujo que pasa por el túnel podría haber visto la pérdida de paquetes, incluso con la entrega garantizada en. Esto podría tener consecuencias dramáticas: la compresión de encabezado TCP / IP se basa en la garantía de que nunca se pierden paquetes. Esto significa que si un flujo utilizado entrega garantizada y, a continuación, un canal había pérdida de paquetes, el flujo podría quedar atascado.

- Se ha corregido la salida de log de los números de secuencia TCP (los números se podrían registrar como negativos). También bajó el nivel de registro de violaciones muy comunes de TCP causadas por escáneres rotos, ya no reclamando que está bajo ataque.

- Asegúrese de que las descargas de stream están bloqueadas. Este error podría haber resultado en pruebas de descarga haciendo en la interfaz web comer 99% de CPU si se quedan atascadas.

- El núcleo de enrutamiento podría quedar atascado en el lado receptor de los flujos. Muy raro, dependiendo del tiempo. Podría estar corriendo sin un núcleo de enrutamiento atrapado durante semanas, y de repente lo tiene pegado todo el tiempo.

- Los receptores de flujo de entrega garantizados de carga alta individuales podrían quedar atascados después de que un túnel se volviera a conectar y, mientras lo hacían, podrían consumir memoria.

- Los tiempos de espera de recepción para flujos no garantizados que aseguran que esperamos el tiempo suficiente (pero no más largo) para que todos los fragmentos lleguen se basa en la supuesta latencia de enlace de la combinación de canales utilizados. Los filtros utilizados no estaban bien ajustados y no eran adecuados para las conexiones por satélite. Estos valores no sintonizados podrían hacer que los paquetes cayeran en el lado de recepción (porque el enrutador no esperaría el tiempo suficiente para que todos los fragmentos de ese paquete llegaran). Esto podría resultar en que el receptor esté en falta por no poder usar la velocidad completa del túnel que descarga desde / a través del túnel. Los filtros han sido completamente reescritos.

- La "latencia media es ... ms, máxima permitida es ... ms, no hay alternativas, manteniendo el canal." Mensaje se ha ido, como es la idea subyacente: No tiene sentido mantener el último canal con una latencia superior a la máxima permitida. Si el último canal sale por un momento, la capa del túnel hará el almacenamiento en búfer.


Actualización sin conexión

Como alternativa a una actualización en línea, está disponible una actualización sin conexión. De vez en cuando en otras versiones de Firmware estables, las versiones de firmware "de vanguardia" se ponen a disposición sólo como una actualización sin conexión. Para realizar una actualización sin conexión, descargue la imagen de firmware correcta para su producto y, a continuación, utilice la función de actualización manual dentro de la interfaz web del enrutador para cargar esa imagen.


Acerca del firmware del enrutador:

Antes de considerar la descarga de este firmware, vaya a la página de información del sistema del enrutador y asegúrese de que la versión actualmente instalada no sea nueva ni que coincida con esta versión.

Debido a la gran variedad de modelos de enrutadores ya los diferentes métodos para actualizar el dispositivo, es muy recomendable que lea y, sobre todo, comprenda los pasos de instalación antes de aplicar el nuevo firmware, incluso si es un usuario avanzado.


En teoría, estos pasos no deben ser una molestia para nadie, porque los fabricantes tratan de hacerlos lo más fácil posible, incluso si no siempre tienen éxito. Básicamente, debe cargar el nuevo firmware al enrutador a través de su página de administración y permitir que se actualice.

Si instala una nueva versión, puede esperar mayores niveles de seguridad, diferentes problemas de vulnerabilidad que deben resolverse, mejor rendimiento general y velocidades de transferencia, compatibilidad mejorada con otros dispositivos, soporte adicional para las nuevas tecnologías, así como varios otros cambios .

Si busca ciertas medidas de seguridad, recuerde que lo mejor sería realizar la carga mediante un cable Ethernet en lugar de una conexión inalámbrica, que puede interrumpirse fácilmente. Además, asegúrese de que no apague el enrutador o utilice sus botones durante la instalación, si desea evitar cualquier mal funcionamiento.

Si este firmware satisface sus necesidades actuales, obtenga la versión deseada y aplíquela a su unidad de enrutador; Si no, consulte con nuestro sitio web lo más a menudo posible para que no pierda la actualización que mejorará su dispositivo. & Nbsp;

Programas parecidos

Otro software de desarrollador Viprinet

Comentarios a la Viprinet Multichannel VPN Router 2610 RuggedVPN Firmware

Comentarios que no se encuentran
Añadir comentario
A su vez en las imágenes!