É bem possível que o firmware em um de seus roteadores (pode ser um, na verdade) seja ruim e não esteja atualizando sua tabela de ponte corretamente quando o endereço MAC do cliente passar da interface sem fio do roteador para sendo visto em sua interface Ethernet LAN (ou vice-versa).
O provavelmente roteador 2 está com defeito, mas a reinicialização também ativa o link Ethernet para o roteador 1, então ainda é possível que o roteador 1 esteja com defeito, mas o ciclo do link Ethernet elimina o problema (a menos que você já tenha descoberto que desconectar e reconectar o cabo não sai do estado ruim).
Às vezes, você pode ajudar pontes (uso o termo "pontes" no sentido amplo de qualquer coisa que forneça funcionalidade semelhante a ponte 802.1D, incluindo switches e partes integradas LAN / WLAN de gateways domésticos e APs) atualizar suas tabelas de ponte mais rápido enviando multicasts ou transmissões do endereço MAC do dispositivo que foi movido. Isso geralmente ocorre automaticamente devido a difusões ARP e DHCP, mas se você quiser tentar forçá-lo enviando seus próprios broadcasts / multicasts do dispositivo vendo o problema, você poderia tentar pingar alguns endereços broadcast e multicast, como 192.168.25.255 (assumindo você está usando uma sub-rede / 24), 255.255.255.255 e 224.0.0.1, do dispositivo que perdeu o contato com a outra metade da rede.
As distribuições de firmware do roteador de código aberto do Aftermarket podem ser menos propensas a ter esse bug, portanto, atualizando seus roteadores para OpenWrt / DD-WRT / Tomato / Gargoyle / etc. pode esclarecer isso para você.