Problemas con Firefox 3.5 Beta 4 y dd-wrt

Una de las cosas que trae de nuevo Fedora 11 es Firefox 3.5 Beta 4, y parece que funciona bastante diferente de la rama 3.0.x que venía usando con Jaunty.

Ha sido una marcianada de 3 días que al final he resuelto hoy. Las pistas:

1. Todo funciona perfectamente hasta que llega un momento en el que, paulativamente, la conectividad empieza a fallar.
2. No es un problema de radio, porque no dejamos de estar asociados a nuestro Linksys con dd-wrt perfectamente actualizado.
3. Las conexiones en curso, se mantienen. Es decir, no funciona un ping porque no hay resolución DNS, pero nuestras conexiones SSH abiertas funcionan perfectamente :).
4. No podemos renovar nuestros leases vía DHCP, y tampoco podemos conseguir IP desde otro portátil que, hasta ese punto, estaba apagado.
5. Cuando reiniciamos el Linsys, todo vuelve a funcionar perfectamente durante un tiempo, hasta que volvemos a los problemas.

Hay que decir que esto nunca me ha pasado con Jaunty, así que era alguno de los cambios que ha introducido Fedora lo que me tenía en jaque :S. A ver qué puede ser.

Después de muchas pruebas, cambios y descartes, me ha llamado la atención lo siguiente:

¿Demasiados estados?

Por algún motivo parece que Firefox 3.5 es más agresivo con las conexiones y las resoluciones de nombres, y es razonable porque es mucho más rápido que la rama 3.0.x.

Me he dado cuenta de esto porque, mirando en Status > Router en la web de dd-wrt había un número algo alto de conexiones activas y tampoco estaba haciendo nada especial.

Bueno, la clave ha sido Firefox :P.

Antes el máximo no era 4096, sino 512 :(

Además he probado con mi netbook con Jaunty y, aparentemente, abre muchas menos conexiones. El límite indicado en este momento era de 512 conexiones, límite que no recuerdo haber puesto (el defecto parece ser 4096), y que nunca me había dado problemas (ni con Transsmission a toda mecha).

Bien, supongamos que este es el problema. ¿Cubre todos los síntomas observados? Pues resulta que sí, porque ese límite de estados en el cortafuegos del Linksys es global. Veamos nuestra lista.

1. Efectivamente, tenemos problemas cuando alcanzamos el número máximo de estados. Eso tarda un tiempo variable, según la actividad que estemos realizando (y ahí Firefox tiene mucho que ver).
2. La radio no tiene nada que ver, porque no es un problema a nivel de enlace.
3. No podemos abrir nuevas conexiones porque la tabla de estado está llena, pero las entradas existentes se mantienen perfectamente.
4. Bueno, se supone que DHCP se maneja a otro nivel, pero me cuadra que cortafuegos de dd-wrt sea lo suficientemente inteligente como para no dejar un cambio de IP si no hay estados libres. Esto aplica a nuevos clientes, porque el límite es global.
5. Si apagamos el Linksys, la tabla de estados se vacía porque no se almacena en memoria persistente :D. Es como volver al estado cero.

La solución es muy sencilla: vamos a Administration > Management > IP Filter Settings (adjust these for P2P) (sí, el comentario es bastante revelador :S).

También podríamos ajustar el valor del timeout, para que la tabla se vacíe más rápido

He puesto los estados al supuesto valor por defecto, porque tampoco sé el posible límite del hardware del Linksys (un WRT54GS v4).

La verdad es que ha sido un problemilla que me ha tenido entretenido bastante tiempo, pero bueno... mientras las cosas se solucionen y aprendamos por el camino, genial :D.