Sinceramente no tengo claro ni que sea cierre ni que sea apertura... jajajaja, digamos que es una etiqueta diferente para especificar que no hay nada. De hecho es raro, porque existen nodos que no aparecen ni siquiera etiquetados en el cfg, y creo incluso que puedes crear tus propios nodos... a saber...
El caso es que es cierto, hay que eliminar/sustituir ese "cierre" por el bloque nuevo
ánimo taker59, esperemos que a la... décima? sea la vencida, y podamos ver que le pasa ahora al 2º mitrastar
Edito. Lo interesante es ver si una vez establecida la WAN la regla ebtable está efectivamente eliminada. En el segundo no creo que sirva de nada, puedes ahorrartelo, el secundario no tiene esa regla insertada, tiene otras. Lo que me escama es uqe si ha tardado en levantar WAN más de la cuenta es que haya sido por la espera de los 60seg... la cuestión es si cuando se ejecuta la eliminación la regla había sido ya creada o no. Saca las ebtables del 1º y saliemos de dudas
Esto ,repito esto es lo que me sale en el segundo.
# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 2, policy: ACCEPT
-p IPv4 --ip-proto udp --ip-sport 68 --ip-dport 67 -j block_dhcpRequest_fromWAN_chain
-p IPv4 -i eth0.3285 --ip-proto udp --ip-dport 67 -j DROP
Bridge chain: FORWARD, entries: 4, policy: ACCEPT
-p PPP_DISC -j ACCEPT
-p PPP_SES -j ACCEPT
-p IPv4 -o eth0.3285 -j DROP_DHCPPC_TRAFFIC_FORWARD
-p IPv4 -i eth0.3285 -j DROP_DHCPPC_TRAFFIC_FORWARD
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Bridge chain: block_dhcpRequest_fromWAN_chain, entries: 0, policy: RETURN
Bridge chain: DROP_DHCPPC_TRAFFIC_FORWARD, entries: 0, policy: RETURN
#
Ahora subire lo del primero.
