I have a question about devices in standby-mode on my Wi-Fi network. My configuration consists of a Fritzbox3490 and a Raspberry-PI3. In my Fritzbox connection menu (fritz.box) i can see passive devices (overall 14) like my smartphone in stand-by, my PI on the other hand is not able to show me passive devices (only 10). I tried many programs like ARP-Scan, netdiscover..., but these programs only showed me the active devices. I also tried the fritzconnection api, but it did not work for me. I must admit that I am new in networking. Is there a way to get the passive devices on the console or in a python script, which are connected the fritzbox?
We had a very similar-sounding problem trying to
ping a phone. We were trying to set up a "treasure hunt" puzzle. It did not work as we hoped, because phones go to sleep after a while to save power.
[My discontinued phone] seems to have several "modes". I get 50-100ms [
pingreponses to start with]. Later, I get alternately 1000ms and 10ms, and 10% loss.
Just tapping the lock button gets it back to the first mode. Takes somewhere like 30s to enter the second mode.
You’re a genius! Lock iPhone and 30-60s later it stops responding to pings completely. Press the lock button again to wake it up and it immediately begins responding again.
If it doesn't respond to multiple ARP probes, I would have said it was completely asleep. No ARP = no TCP/IP.
And yet. Here's the puzzle. Do the devices provide any "push notifications", e.g. immediate notifications of
emails chat messages? That's got to be relying on TCP/IP.
The default settings for the Linux kernel will expire & remove old ARP entries after ten minutes or less. After that expiry, the Linux-based router would be unable to forward the push notifications.
To explain these results, the sleeping phone would have to be deliberately ignoring ARP requests unless they are from the router. That's not impossible, I'm just surprised that it would be considered necessary! I guess it might be done to cut off some chatty local network discovery protocol that the phone could have been using when active, such as uPNP?
EDIT: I suspect you can't find any code like this when you look in the Android Linux kernel itself. The specific behaviour may be determined by ARP offload code in the Wi-Fi device firmware.
To test this behaviour, you would
- set up a Linux device, to work as a Wireless Access Point and router
- run a packet sniffer on the Linux device's Wi-Fi interface
- connect a phone to it
- wait for the phone to go to sleep & stop responding to probes
- wait for the ARP entry to expire on the Linux device
- send the phone an
By default, your Android device turns off the Wi-Fi module during off-peak hours when the device is not being used, and this is a part of the Doze Mode.
-- a third-party non-technical article: https://www.theandroidsoul.com/how-to-fix-delayed-notifications-problem-on-android/
Normal priority messages are delivered immediately when the app is in the foreground. When the device is in Doze, delivery may be delayed to conserve battery. For less time-sensitive messages, such as notifications of new email ... choose normal delivery priority.
FCM attempts to deliver high priority messages immediately, allowing the FCM service to wake a sleeping device when necessary and to run some limited processing (including very limited network access).
Also, if the phone has no chat apps installed & enabled, only "low priority" notifications like email, then maybe it will only poll periodically, and the rest of the time maybe it does not respond even to ARP.