 |
|
||
|
|
|
|||||||
| Nexus 4 Todo sobre el nuevo smartphone de Google |
| Ver resultado de la encuesta: Tienes problemas con el wifi? | |||
| No, me va perfectamente todo |
   
|
242 | 28.98% |
| Si, me llegan con retraso las notificaciones |
  
|
313 | 37.49% |
| Si, me llegan con retraso las notificaciones y el wifi se duerme cada cierto tiempo |
  
|
245 | 29.34% |
| Si, directamente ni se me conecta |
  
|
35 | 4.19% |
| Votantes: 835. Tú no puedes votar en esta encuesta | |||
 |
|
|
Herramientas |
|
#841
27/02/13, 23:27:13
|
||||
|
||||
|
Parece que vamos en círculos.
http://www.htcmania.com/showthread.p...09#post7626309 Lo que comenta entropy en XDA a grandes rasgos(sin entrar en lo técnico) es lo que ya se sabia, Que el arp offload Falla en suspensión, tira a a macs incorrectas(la suspensión interna del modulo wifi, no la de opciones avanzadas), pero también es algo que ya se sabia: http://forum.xda-developers.com/show...&postcount=194 Comenta que habría que figurarse porque peta el ARP Offload en Deep Sleep. Aparte dice que dejar entrar todo el trafico multicast es como dar palos de ciego y que si que aumentara el gasto de batería, algo que ya dijo el creador del fix en XDA. Es cosa de Qualcomm/Google dar una solución, Edit: Si bien no se si un Desarrollador puede darnos una solución pues "creo" que los blobs de qualcomm son de código cerrado, y a saber si es esto exactamente, porque hay gente que también le pasa en el nexus 7/10. Hay que seguir esperando pues. 
__________________
#HOLOYOLO 420 ROOT IT
Última edición por NeoDaemon Día 27/02/13 a las 23:48:55. 
|
|
|
|
#842
28/02/13, 00:00:40
|
||||
|
||||
|
He estado espiando un poco el thread en XDA para entenderlo mejor.
Alguien pregunta que cual es el comportamiento de otros terminales en cuando a esa línea de configuración que se dice que arregla el problema. Alguien contesta que no se puede saber porque ese archivo con esa configuración solo se aplica a terminales con este chip the qualcomm... pero que lo normal sería la configuración que viene por defecto, es decir, no tocar nada, ya que el chip debería encargarse el solito de responder a esos paquetes broadcast (ARP offloading). en caso contrario, lo que tienes el al sistema operativo procesando esos paquetes y contestando. Básicamente ARP offloading es que el chip conteste directamente, ya que ahorra batería al no pasar por la CPU ni el sistema operativo. ALguien que ha visto el INI ha visto que hay algo mal en cómo está configurado el ARP offloading hasta el punto de que las direcciones MAC que reporta el terminal está mal. La raiz del problema es que cuando llega un paquete destinado a nuestro telefono, nuestro router (wifi), pregunta a todos los ordenadores de la red cual es la dirección MAC del telefono, y el telefono con la pantalla encendida no contesta, entonces el router no manda nada y al telefono no le llega. En circunstancias normales el movil deberia contestar, bien por el chip o bien el sistema operativo. Otro 'fix' que proponen es decirle a tu router que para la IP de tu movil, use siempre la MAC de tu movil, para que no vuelva a 'preguntarle' al movil. Y aqui está la razón por la que algunos no tienen problema. En muchos casos, depende de cómo asigne las IPs el router, y de cuanto tiempo guarde el router la correspondencia IP/MAC. Algunos routers tienen caches que guardan la correspondencia durante horas, por lo que igual la gente ni lo nota. Los routers linux al parecer lo guardan durante muy poco tiempo y casi todos los routers domesticos son linux. Otros routers asignan la misma IP siempre a la misma MAC, lo que no implica que dejen de preguntar. Algunos routers dan la opcioón de forzar esto: asignar la misma IP a la misma MAC, siempre. Según peña en XDA, la mayoría de los routers con esta opción guardan la correspondencia iP/MAC para siempre, y ya no hace falta mandar los broadcast ARP. Otros routers tienen la opción explícita de especificar ARP estáticas. Imagino que muchas de las cosas ya estaran dichas... pero vamos, lo mejor es probar con el router y decirle al DHCP que de siempre la misma IP al telefono (esta opcion la tienen casi todos los routers...)
|
| Gracias de parte de: | ||
|
#843
28/02/13, 00:12:10
|
||||
|
||||
|
Hola a todos,
voy a tratar de explicar cual es exactamente el problema que existe después de haber estado investigando un poco sobre el asunto. El problema principal es que el driver Qualcomm no soporta la funcionalidad "ARP offload" mientras se filtran paquetes broadcast. El Nexus 4, como la gran mayoría de los moviles, filtra los paquetes broadcast cuando entra en modo sleep para ahorrar batería. Este incidencia es verídica y reconocida por un desarrollador de Android el día 14 de Enero: https://code.google.com/p/android/is...?id=40065#c535 ARP es un protocolo para resolver la dirección hardware (Ethernet MAC) a partir de una determinada dirección IP. Protocolo absolutamente necesario para recibir las notificaciones. ARP offload, es un variación del protocolo para resolver la dirección hardware sin tener que despertar al dispositivo (en este caso, al Nexus 4) cuando se encuentra en modo sleep. El FIX que se publicó en XDA (http://forum.xda-developers.com/show....php?t=2072930) funciona porque lo que hace es evitar que se filtren peticiones broadcast cuando el dispositivo entra en modo sleep. Al no filtrar este tipo de peticiones, el driver Qualcomm sí permite ARP offload y por tanto llegan las notificaciones. Pero, tiene el handicap de que consume más batería. Otra solución sin hacer root al Nexus, es añadir una entrada permanente en la tabla ARP del router para que pueda resolver directamente la dirección hardware del Nexus. Yo es lo que actualmente estoy haciendo. Para concluir, me gustaría añadir que, por lo que he podido leer, se estan mezclando dos tipos de problemas que, sí bien puede parecer el mismo, no lo son. En concreto, se esta confundiendo con el relacionado con los heartbeat, el cual puede ocurrir en cualquier versión de Android dependiendo de la configuración del router del usuario. Android, por defecto, manda un heartbeat cada 15 minutos cuando esta sobre WiFi para mantener las conexiones TCP abiertas. El problema viene cuando es nuestro router cuando cierra la conexión antes de esos 15 minutos. Para solucionar este tipo de problema hay múltiples aplicaciones en la Play Store que lo hacen es mandar un heartbeat con un periodo más corto. Son dos problemas distinto que provocan los mismo síntomas. Por lo que puede haber usuarios que esten incluso sufriendo ambos. Última edición por qwerty999 Día 28/02/13 a las 01:04:03.
|
| Los siguientes 4 usuarios han agradecido a qwerty999 su comentario: | ||
|
#844
28/02/13, 00:19:56
|
||||
|
||||
|
ni zorra de hacer eso con ono...
de hecho, creo que ni se puede poner IP fija.. además en el router me salen muy muy pocas opciones que tocar
|
| Gracias de parte de: | ||
|
#845
28/02/13, 00:23:44
|
||||
|
||||
 Cita: Originalmente Escrito por qwerty999
En concreto, se esta confundiendo con el relacionado con los heartbeat, el cual puede ocurrir en cualquier versión de Android dependiendo de la configuración del router del usuario. Android, por defecto, manda un heartbeat cada 15 minutos cuando esta sobre WiFi para mantener las conexiones TCP abiertas. El problema viene cuando es nuestro router cuando cierra la conexión antes de esos 15 minutos. Para solucionar este tipo de problema hay múltiples aplicaciones en la Play Store que lo hacen es mandar un heartbeat con un periodo más corto.
|
|
#846
28/02/13, 00:24:32
|
||||
|
||||
|
Cita: Originalmente Escrito por elandune
ni zorra de hacer eso con ono...
de hecho, creo que ni se puede poner IP fija.. además en el router me salen muy muy pocas opciones que tocar
|
|
#847
28/02/13, 00:25:29
|
||||
|
||||
|
Menuda cagada...si ya ha costado identificar el problema es de "juzgao de guardia" que Google no ponga remedio al problema de la Wifi y el 3g..
__________________
|
|
#848
28/02/13, 00:30:48
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
depende de que router tengas!
 y están los dos funcionando
|
|
#849
28/02/13, 00:31:38
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
Esto lo hace para que el router con NAT no cierre la conexión? Porque si no hay NAT de por medio el router no tendría por qué tocar la conexión TCP...
Para mantener esa conexión activa se mandan Heartbeat de forma periódica. Que no es más que un pequeño paquete para dejar constancia de que la conexión sigue viva. Si nuestro router corta esa conexión antes de que Android vuelva a mandar el siguiente Heartbeat, no se volverá a mandar uno de nuevo hasta que el usuario enciende la pantalla (despierta al dispositivo del modo sleep), momento en el que llegarán todas las notificaciones atrasadas.
|
|
#850
28/02/13, 00:32:23
|
||||
|
||||
|
Cita: Originalmente Escrito por qwerty999
Hola a todos,
voy a tratar de explicar cual es exactamente el problema que existe después de haber estado investigando un poco sobre el asunto. El problema principal es que el driver Qualcomm no soporta la funcionalidad "ARP offload" mientras se filtran paquetes broadcast. El Nexus 4, como la gran mayoría de los moviles, filtra los paquetes broadcast cuando entra en modo sleep para ahorrar batería. Este incidencia es verídica y reconocida por un desarrollador de Android el día 14 de Enero: https://code.google.com/p/android/is...?id=40065#c535 ARP es un protocolo para resolver la dirección hardware (Ethernet MAC) a partir de una determinada dirección IP. Protocolo absolutamente necesario para recibir las notificaciones. ARP offload, es un variación del protocolo para resolver la dirección hardware sin tener que despertar al dispositivo (en este caso, al Nexus 4) cuando se encuentra en modo sleep. El FIX que se publicó en XDA (http://forum.xda-developers.com/show....php?t=2072930) funciona porque lo que hace es evitar que se filtren peticiones broadcast cuando el dispositivo entra en modo sleep. Al no filtrar este tipo de peticiones, el driver Qualcomm sí permite ARP offload y por tanto llegan las notificaciones. Pero, tiene el handicap de que consume más batería. Otra solución sin hacer root al Nexus, es añadir una entrada permanente en la tabla ARP del router para que pueda resolver directamente la dirección hardware del Nexus. Yo es lo que actualmente estoy haciendo. Para concluir, me gustaría añadir que, por lo que he podido leer, se estan mezclando dos tipos de problemas que, sí bien puede parecer el mismo, no lo son. En concreto, se esta confundiendo con el relacionado con los heartbeat, el cual puede ocurrir en cualquier versión de Android dependiendo de la configuración del router del usuario. Android, por defecto, manda un heartbeat cada 15 minutos cuando esta sobre WiFi para mantener las conexiones TCP abiertas. El problema viene cuando es nuestro router cuando cierra la conexión antes de esos 15 minutos. Para solucionar este tipo de problema hay múltiples aplicaciones en la Play Store que lo hacen es mandar un heartbeat con un periodo más corto. Son dos problemas distinto que provocan los mismo síntomas. Por lo que puede haber usuarios que esten incluso sufriendo ambos. Yo tengo un router zyxel p660 de imagenio, como podria añadir esa tabla ARP, para intentar solucionar el problema? Y podrias pasarme la aplicacion para mandar heartbeat antes? ya que a mi se me duerme el wifi, y entonces supongo que sera por eso. Porque mi router cerrara la conexion antes de esos 15 minutos. Y gracias por la clara explicacion!  Ya esta claro porque la mayoria de dispositivos android les falla el wifi o se les duerme, que google tendria que modificar esos 15 minutos, por 10 minutos. Y que se fijasen mas en como hacen los drivers, que esten bien configurados etc..
__________________
Última edición por ivancpa Día 28/02/13 a las 00:36:25.
|
|
#851
28/02/13, 00:38:49
|
||||
|
||||
|
Cita: Originalmente Escrito por qwerty999
El servicio de notificaciones de Google funciona a través de una conexión compartida TCP que se establece entre los servidores de Google y tu teléfono a través del puerto 5228.
Para mantener esa conexión activa se mandan Heartbeat de forma periódica. Que no es más que un pequeño paquete para dejar constancia de que la conexión sigue viva. Si nuestro router corta esa conexión antes de que Android vuelva a mandar el siguiente Heartbeat, no se volverá a mandar uno de nuevo hasta que el usuario enciende la pantalla (despierta al dispositivo del modo sleep), momento en el que llegarán todas las notificaciones atrasadas. es que me llama la atencion que el router ande cortando conexiones TCP, pero evidentemente tiene sentido que lo haga para que haya puertos libres en el NAT. y esto no se arregla redireccionando puertos. a lo mejor si el router se deja, tocar el NAT para que el timeout de las conexiones abiertas sea mayor que 15 minutos.. edit: segun leo los NAT por defecto tienen timeouts para conexiones TCP bastante altos. por encima de una hora, y algunos hasta 24 horas. el heartbeat no debería ser un problema para nadie... Última edición por jcar87 Día 28/02/13 a las 00:43:14.
|
|
#852
28/02/13, 00:45:13
|
||||
|
||||
|
¿Cómo añadir una entrada estática en la tabla ARP del router?
Destacar que la gran mayoría de los routers eliminan la entrada estática si reiniciamos el router. No es permanente. Si esto es un problema siempre podemos crear un script que se ejecute al inicio para añadir la entrada.
|
|
#853
28/02/13, 00:57:32
|
||||
|
||||
|
Si el router tiene la opción de fijar la IP dada una mac (en un dlink que tengo te deja). te vas a la parte de configurar el DHCP, y te deja asignar una IP a una MAC (vamos, que sigue habiendo DHCP y no hay que configurar IP fija en el movil, pero el router siempre asignará la misma IP a ese dispositivo).
esto casi seguro garantiza que se cree esa entrada ARP. otra alternativa es modificar el tiempo de lease de las IPs DHCP para que nunca caduquen, y a lo mejor el router mantiene fija la tabla arp. ninguna de estas dos alternativas es al 100%, depende de que tan 'audaz' haya sido el fabricante.
|
|
#854
28/02/13, 01:02:18
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
edit: segun leo los NAT por defecto tienen timeouts para conexiones TCP bastante altos. por encima de una hora, y algunos hasta 24 horas. el heartbeat no debería ser un problema para nadie...
Cita: Originalmente Escrito por jcar87
Si el router tiene la opción de fijar la IP dada una mac (en un dlink que tengo te deja). te vas a la parte de configurar el DHCP, y te deja asignar una IP a una MAC (vamos, que sigue habiendo DHCP y no hay que configurar IP fija en el movil, pero el router siempre asignará la misma IP a ese dispositivo).
esto casi seguro garantiza que se cree esa entrada ARP. 
|
|
#855
28/02/13, 01:03:17
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
Si el router tiene la opción de fijar la IP dada una mac (en un dlink que tengo te deja). te vas a la parte de configurar el DHCP, y te deja asignar una IP a una MAC (vamos, que sigue habiendo DHCP y no hay que configurar IP fija en el movil, pero el router siempre asignará la misma IP a ese dispositivo).
esto casi seguro garantiza que se cree esa entrada ARP. otra alternativa es modificar el tiempo de lease de las IPs DHCP para que nunca caduquen, y a lo mejor el router mantiene fija la tabla arp. ninguna de estas dos alternativas es al 100%, depende de que tan 'audaz' haya sido el fabricante. He puesto la mac de mi nexus 4 y la ip 192.168.1.35 (que es la que ya estaba puesta de por si en el movil) reinicio y pruebo
__________________
Última edición por ivancpa Día 28/02/13 a las 01:06:28.
|
|
#856
28/02/13, 01:07:41
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
Si el router tiene la opción de fijar la IP dada una mac (en un dlink que tengo te deja). te vas a la parte de configurar el DHCP, y te deja asignar una IP a una MAC (vamos, que sigue habiendo DHCP y no hay que configurar IP fija en el movil, pero el router siempre asignará la misma IP a ese dispositivo).
esto casi seguro garantiza que se cree esa entrada ARP. otra alternativa es modificar el tiempo de lease de las IPs DHCP para que nunca caduquen, y a lo mejor el router mantiene fija la tabla arp. ninguna de estas dos alternativas es al 100%, depende de que tan 'audaz' haya sido el fabricante. el lease time lo puedo poner de media hora a 2 semanas, y ya después fijo ¿eso que hace esactamente?¿que a mi móvil siempre le asigne la misma IP? Última edición por elandune Día 28/02/13 a las 01:26:10.
|
|
#857
28/02/13, 01:14:08
|
||||
|
||||
|
bueno, yo tengo la tabla DHCP con una ip fija al movil y la mac de mi nexus 4, asi no deberia dormirse el wifi? Las notificaciones siguen llegando tarde, pero con que no se me duerma algo es algo..
__________________
|
|
#858
28/02/13, 01:35:20
|
||||
|
||||
|
Cita: Originalmente Escrito por elandune
¿habría que dejar el "habilitar servidor DHCP" en fijo y poner el lease time en "fijo" entonces? eso si lo puedo modificar
el lease time lo puedo poner de media hora a 2 semanas, y ya después fijo ¿eso que hace esactamente?¿que a mi móvil siempre le asigne la misma IP?
|
| Gracias de parte de: | ||
|
#859
28/02/13, 01:36:17
|
||||
|
||||
|
Cita: Originalmente Escrito por ivancpa
bueno, yo tengo la tabla DHCP con una ip fija al movil y la mac de mi nexus 4, asi no deberia dormirse el wifi? Las notificaciones siguen llegando tarde, pero con que no se me duerma algo es algo..
el wifi se duerme igual, lo que pasa que ahora no hace falta que el router pregunte por la MAC del movil, que es lo que da fallos si el movil esta dormido
|
|
|
|
#860
28/02/13, 01:37:54
|
||||
|
||||
|
Cita: Originalmente Escrito por jcar87
el wifi se duerme igual, lo que pasa que ahora no hace falta que el router pregunte por la MAC del movil, que es lo que da fallos si el movil esta dormido
__________________
|
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar390522_1.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/unknown.gif)
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar469544_2.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar341756_1.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar320352_11.gif){kind=avatar}
