Eu não sou o administrador Linux mais strong. Eu apenas pensei em jogar isso lá fora. Eu tenho um ponto de acesso sem fio Linux com HOSTAPD e DNSMASQ. Eu tenho trabalhado nisso há algum tempo e resolvi algumas questões, mas o problema principal ainda permanece. Eu tive um problema em que o HOSTAPD não funcionava corretamente após uma reinicialização ou reinicialização do serviço. Consegui corrigir isso com dependências de serviço. Há tantas respostas do google para o HOSTAPD que não consigo encontrar um problema que corresponda ao meu. Eu tentei implementar alguns, como não deixar a NIC adormecer e assim por diante, mas ela não corrigiu o problema principal.
Eu terei meus dispositivos conectados ao WAP e ele será executado por 6 a 10 horas, então os clientes começarão a soltar um por um. Eles nem todos caem ao mesmo tempo, mas quando um cai, os outros começam a cair em 10 minutos. Eu configurei o DNSMASQ para dar concessões por 2 minutos. Isso foi feito para garantir que o serviço DHCP não fosse o problema. Consegui obter o tempo exato de uma falha, mas o syslog não tinha detalhes interessantes. Ele só funciona, então não funciona em um loop infinito.
Oct 17 17:17:01 raspberrypi CRON[1084]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 17 17:17:18 raspberrypi dnsmasq-dhcp[598]: DHCPREQUEST(wlan0) 192.168.3.101 00:bb:3a:35:74:e1
Oct 17 17:17:18 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sat Oct 17 17:18:48 2015 [try http://www.rsyslog.com/e/2007 ]
Oct 17 17:17:18 raspberrypi dnsmasq-dhcp[598]: DHCPACK(wlan0) 192.168.3.101 00:bb:3a:35:74:e1 android-8edf05d3f461104e
Oct 17 17:17:18 raspberrypi dnsmasq-dhcp[598]: not giving name raspberrypi to the DHCP lease of 192.168.4.114 because the name exists in /etc/hosts with address 127.0.1.1
Oct 17 17:18:14 raspberrypi dnsmasq-dhcp[598]: DHCPREQUEST(wlan0) 192.168.3.101 00:bb:3a:35:74:e1
Oct 17 17:18:14 raspberrypi dnsmasq-dhcp[598]: DHCPACK(wlan0) 192.168.3.101 00:bb:3a:35:74:e1 android-8edf05d3f461104e
Oct 17 17:18:14 raspberrypi dnsmasq-dhcp[598]: not giving name raspberrypi to the DHCP lease of 192.168.4.114 because the name exists in /etc/hosts with address 127.0.1.1
Oct 17 17:19:21 raspberrypi dnsmasq-dhcp[598]: DHCPREQUEST(eth1) 192.168.4.114 b8:27:eb:05:9b:c8
Oct 17 17:19:21 raspberrypi dnsmasq-dhcp[598]: DHCPACK(eth1) 192.168.4.114 b8:27:eb:05:9b:c8 raspberrypi
Oct 17 17:19:21 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sat Oct 17 17:20:51 2015 [try http://www.rsyslog.com/e/2007 ]
Oct 17 17:19:21 raspberrypi dnsmasq-dhcp[598]: not giving name raspberrypi to the DHCP lease of 192.168.4.114 because the name exists in /etc/hosts with address 127.0.1.1
Oct 17 17:19:44 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: deauthenticated due to local deauth request
Oct 17 17:19:44 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: disassociated
Oct 17 17:19:44 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: associated
Oct 17 17:19:48 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: deauthenticated due to local deauth request
Oct 17 17:19:48 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: disassociated
Oct 17 17:19:48 raspberrypi hostapd: wlan0: STA 00:bb:3a:35:74:e1 IEEE 802.11: associated
Esse é o trecho do syslog no momento da falha. É possível que algum outro serviço esteja falhando e fazendo com que o HOSTAPD pare de funcionar? Na maioria das vezes, o WAP ainda estará visível, mesmo que não esteja permitindo clientes. Algum tempo não é visível. Algumas vezes não é visível após a reinicialização, mas aparece como "Outra rede". O Windows me faz digitar o SSID e a senha, mesmo que ela já tenha. Quando falha, tanto o HOSTAPD quanto o DNSMASQ dizem que estão ativos (em execução). Alguém tem alguma ideia?
Editar 1 - Eu adicionei o nível do syslog 0 e reiniciei. Meus dispositivos foram conectados por aproximadamente 7 horas e depois caíram. Eu tenho os registros que eu editei para facilitar a leitura.
IEEE 802.11: associated
WPA: event 1 notification
WPA: start authentication
IEEE 802.1X: unauthorizing port
WPA: sending 1/4 msg of 4-Way Handshake
WPA: EAPOL-Key timeout
WPA: sending 1/4 msg of 4-Way Handshake
WPA: EAPOL-Key timeout
WPA: sending 1/4 msg of 4-Way Handshake
WPA: EAPOL-Key timeout
WPA: sending 1/4 msg of 4-Way Handshake
WPA: EAPOL-Key timeout
WPA: PTKSTART: Retry limit 4 reached
IEEE 802.1X: unauthorizing port
IEEE 802.11: deauthenticated due to local deauth request
IEEE 802.11: disassociated
Isso indica claramente que ele acha que não recebeu a resposta, mas isso não acontece no Cisco Wap, por que isso funcionaria por 7 horas? isso indica alguma outra coisa?