Para cualquiera que encuentre este hilo ahora:

Tuve este problema y mi solución fue hacer ping al dispositivo antes de hacer el volcado iw, por ejemplo

Obtenga la lista de direcciones MAC conectadas:

 iw dev wlan0 station dump | grep 'signal' | awk '{print $2}'

Luego obtenga la dirección IP de estas direcciones MAC (alternativamente, puede usar arp ) :

 ip neigh | grep 'ma:ca:dd:re:ss:ss' | awk '{print $1}'

Luego haga ping a cada uno de ellos:

 ping -c 1 'IP.address'

Luego obtenga la señal actualizada para esa dirección MAC

 iw dev wlan0 station get 'ma:ca:dd:re:ss:ss' | grep 'signal' | awk '{print $2}'

Envolví todo esto en un script de Python y parecía dar datos confiables.

Lo probaré:

Estás incrustado, así que supongo que tienes busybox . No tiene IP, pero puede usar arping (si este subprograma no está configurado en su compilación de busybox, cambie la configuración) para enviar algo pequeño e inútil que puede despertar la cosa. ¿Qué IP usar para tus solicitudes ARP? Bueno, parece que puedes usar una IP "ficticia".

Estoy ejecutando esto en una PC, pero tengo una caja ocupada con su arping, y uso una interfaz con cable, pero este es el concepto:

 jbm@sumo:~/sandbox/iw$ sudo busybox arping -w 1 -U -I eth0 0.0.0.0 ARPING to 0.0.0.0 from 192.168.1.66 via eth0 Sent 2 probe(s) (2 broadcast(s)) Received 0 reply (0 request(s), 0 broadcast(s))

Lo útil es que, a pesar de la IP "ficticia", puedo verificar con tcpdump que las solicitudes de arp realmente van por cable (o en el aire en su caso):

 jbm@sumo:~$ sudo tcpdump -i eth0 -v arp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:42:20.111100 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 0.0.0.0 (Broadcast) tell sumo, length 28 10:42:21.111206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 0.0.0.0 (Broadcast) tell sumo, length 28 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel

Por lo tanto, enviar una solicitud ARP en su interfaz inalámbrica puede ser suficiente para "despertar" su conexión y actualizar su RSSI.

EDITAR:

Vea los usos y propiedades interesantes de IP 0.0.0.0 aquí:

https://en.wikipedia.org/wiki/0.0.0.0

EDITAR 2:

Reconsiderándolo, me di cuenta de que habrá un problema si su interfaz inalámbrica no tiene una IP. Lo cual, si no me equivoco, puede no ser necesariamente el caso en su configuración de puente. En tal caso, arping no tendrá una dirección de origen para construir sus paquetes de solicitud (ni sabrá cómo escuchar las respuestas) y fallará.

Pero puede crear su propio "arping mini-unidireccional", usando un socket AF_PACKET y construir su propio paquete de solicitud ARP con una dirección IP de origen ficticia/aleatoria. Será unidireccional porque la respuesta a su solicitud ARP falsificada, si la hay, iría a la IP de origen aleatoria que puede y preferiblemente no debería existir. Pero es el principio de simplemente despertar su conexión inalámbrica enviando "algo", que puede hacer el truco.

Para obtener inspiración sobre cómo codificar este "miniarping unidireccional", eche un vistazo a la implementación de busybox desde su udhcpc/udhcpd (es más simple que el applet de busybox de arping completo):

https://git.busybox.net/busybox/tree/networking/udhcp/arpping.c#n38

El parámetro from_ip es lo que desea falsificar. Puede usar su MAC real como from_mac , solo por el bien de la dignidad :-) Ni siquiera tiene que esperar una respuesta (línea de inicio 89), por lo que sería algo así como 50 líneas de código C + un poco principal si desea agregarle algunas opciones.