El 11/10/13 17:39, Camaleón escribió: > El Fri, 11 Oct 2013 16:20:06 +0200, Gerardo Diez García escribió: > >> El 11/10/13 16:14, Camaleón escribió: >>> El Thu, 10 Oct 2013 21:23:53 +0200, Gerardo Diez García escribió: >>> >>>>> El 10/10/13 16:17, Camaleón escribió: >>> (...) >>> >>>>>>>>> Parece que las contramedidas TKIP que se indican en el log van >>>>>>>>> en ese sentido. Creo que es lo que explican aquí: >>>>>>>>> http://blog.s21sec.com/2010/03/un-nuevo-ataque-wpatkip.html >>>>>>>>> cuando hablan de Contramedidas implementadas en WPA/TKIP >>>>>>> >>>>>>> Esto no lo pillo... ¿qué relación le ves a esto con el problema de >>>>>>> la desconexión del resto de equipos con el AP y los problemas de >>>>>>> desconexiones intermitentes con el driver ath9k? >>>>>>> >>>>>>> >>>>> Bueno, tal y como yo he entendido en ese enlace, una medida que toma >>>>> el AP ante la corrupción del MIC es la de renegociar todas las >>>>> autorizaciones. Y cuando digo todas me refiero a la de todos los >>>>> dispositivos enlazados. Quizás algún experto me diga que estoy >>>>> haciendo una lectura errónea. >>> Pero en esa página están hablando de ataques dirigidos a romper el >>> cifrado WPA-TKIP ¿crees que estás sufriendo algún tipo de intrusión por >>> el mensaje que te aparecía en el registro? :-? >> >> No. Lo que _creo_ es que el AP cree que está sufriendo ese ataque (por >> lo de la corrupción del mensaje), y por eso toma la contramedida >> establecida en el protocolo, que es renegociar todas las autorizaciones >> con una penalización de 60 segundos. Creo que es esa penalización la que >> deja fuera de combate la conexión a todos los equipos. >> >> Pero como digo, esa es mi lectura de completo desconocedor de todos esos >> mecanismos. Igual no es esa la causa. > > Un pelín enrevesado ¿no? :-) > > De todas formas, rebusca en el registro del AP, algunos equipos incluyen > un syslog, y si se trata de eso (→ contramedidas) quizá veas algo más de > lo que está haciendo el punto de acceso (→ bloquear el acceso al resto de > equipos previamente autorizados). > > Saludos, > Pego aquí un par de logs de mi última desconexión. El primero es del equipo con el problema en el módulo ath9k
08-10-13 13:21:48 LittleAmita wpa_supplicant[3124] wlan0: WPA: Sending EAPOL-Key Request (error=1 pairwise=0 ptk_set=1 len=99) 08-10-13 13:21:48 LittleAmita wpa_supplicant[3124] wlan0: TKIP countermeasures started 08-10-13 13:21:48 LittleAmita kernel [ 4428.653013] wlan0: deauthenticating from "mac AP" by local choice (reason=14) Se ve que genera un error en el mensaje de conexión. Y a continuación que se inician "TKIP countermeasures". En el otro equipo se ve este log: Oct 8 13:21:48 LiMei kernel: [ 6227.154675] wlan0: deauthenticated from e8:40:f2:e7:df:04 (Reason: 14) Como se ve el AP es el que manda la deautenticación. Por todo esto creo que es eso lo que sucede, y si no, como dirían los italianos "si non e vero, e ben trovato" -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
