@thazza lo que comentas es precisamente lo que hemos estado hablando en este hilo sobre la B21, lo que no está claro del todo es si estaba el problema presente también en la B14. No es una cuestión del WIFI, afecta por igual a Ethernet como a WIFI.
Efectivamente cuando un cliente se desconecta del router en la B21 (al menos en la B21), este puede entrar en un ciclo contínuo de envío de ARP request en broadcast.
Ya expliqué por qué pasa esto, es parte del funcionamiento normal de descrubrimiento de clientes en una red, lo que se escapa de la normalidad es que el Router debería de detenerse después de enviar un máximo de 3 ARP request y no obtener respuesta.... no como sucede, que cada segundo aproximadamente envía uno.
El proceso estándar es sencillo. Si un cliente se conecta por 1º vez este lanza por lo general un ARP solicitando la dirección física de la puerta de enlace, y normalmente la puerta de enlace pregunta por el cliente, para actualizar su tabla ARP, y tenerlo localizado. Esta tabla está siempre actualizada, como lo normal es que el cliente tenga aunque sólo sea ruído de fondo en la red, el router sabe que está aun conectado, así que mantiene en su tabla ARP al cliente. Pero si pasa X tiempo y no hay actividad alguna en dicho cliente, la tabla ARP marca ese cliente como "STALE". Durante otro período de tiempo pequeño se queda a espera de algo que le indique la actividad, pero si también pasa ese tiempo, el router intenta directamente ver que pasa con ese cliente.
En primer lugar intenta X veces una conexión directa a la interfaz. Si esto falla, pasa a lanzar X ARP request en unicast (directamente al cliente, estas peticiones NO LAS VES a menos que coloques un analizador en el router) con la esperanza de tener contestación. Si esto también falla, y aquí está el "problema", pasa a realizar la misma prueba a Broadcast, lanzando otros X veces ARP request a la red... en esta última instancia en Broadcast, con lo que la petición llega a todos. Lo normal es que después de este último intento, ARP da por perdio dicho cliente, se marca e la tabla como FAILED y todo termina.
con la B21 lo que sucede es que ese último paso es indefinido, como no obtiene respuesta (porque no está conectado el cliente) manda otro, y otro y otro... el parámetro mcast_solicit (/proc/sys/net/ipv4/neigh/br0) establece por defecto un máximo de 3 peticiones, y de echo en el Mitrastar está establecido así.... pero por algún bug del kernel o del módulo ARP este límite no se obedece. La única solución que he logrado para cortarlo es estableciendo /mcast_solicit a cero, con lo que efectivamente no se envía ningún ARP request por broadcast cuando llega al último paso de la cadena. No es algo ideal, pero soluciona el problema y verifica que el problema está ahí.
Problema?? Que aunque es posible modificar dicho valor a cero (no sé hasta que punto esto podría dar problemas en alguna otra cosa), este valor se restablece al reiniciar el router.
Problema 2?? que como has visto, esa avalancha puede desencadenarse en cualquier momento una vez desconectas un dispositivo, a veces antes, a veces despúes... y por cada dispositivo desconectado, con lo que un ARP por segundo por cliente desconectado... -> Batería baja y baja.
Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
