For anyone finding this thread now:

I had this issue and my solution was to ping the device before doing the iw dump, e.g.

Get the list of of connected MAC addresses:

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

Then get the IP address from these MAC addresses (alternatively you could use arp):

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

Then ping each of those:

ping -c 1 'IP.address'

Then get the refreshed signal for that MAC address

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

I wrapped all this up in a Python script and it seemed to give reliable data.

I'll give it a try:

You're embedded so I guess you have busybox. You have no IP but you may then use arping (if this applet is not configured in your busybox build, change the config) to send something small and useless that may wake up the thing. What IP to use for your ARP requests? Well it seems you can use a "dummy" IP.

I'm running this on a PC but I do have busybox with its arping, and I use a wired interface, but here is the concept:

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))

The useful thing is that though the "dummy" IP, I can check with tcpdump that the arp requests do actually go on the wire (or in the air in your case):

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

So sending ARP request on your wireless interface may be enough to "wake up" your connection and refresh your RSSI.

EDIT:

See the interesting uses and properties of IP 0.0.0.0 here:

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

EDIT 2:

Re-thinking about it, I realized there will be a problem if your wireless interface does not have an IP itself. Which, if I'm not mistaking, may not necessarily be case in your bridging configuration. In such case, arping will not have a source address to build its request packets (nor will know how to listen for responses), and will fail.

But you can create your own "mini-unidirectional arping", using an AF_PACKET socket and build your own ARP request packet with a dummy/random source IP address. It will be unidirectional because the response to your forged ARP request, if any, would go to to the random source IP which may and preferably should not exist. But it the principle of just awaking your wireless connection by sending "something", that may do the trick.

For inspiration on how to code this "mini-unidirectional arping", have a look at busybox implementation from its udhcpc/udhcpd (it's simpler than the full-blown arping busybox applet):

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

The from_ip parameter is what you want to forge. You can use your actual MAC as from_mac, just for the sake of dignity :-) You don't even have to wait for a response (starting line 89), so that would be something like 50 lines of C code + a little main if you want to add a few options to it.