boinc
boinc copied to clipboard
BOINC
Android BOINC uses <suppress_net_info>?
It's more of a question really. This weekend I added a new Android device to Seti, and found in my account -> my computers that it was working fine, but wasn't showing its internal IP address. Then I checked my other Android devices, and none of those show the internal IP address, only the external IP address. My PC shows both the internal and external IP addresses.
On my LAN I give all devices a static IP address, so for the project this internal IP address should show and should always be the same for that device. But in this case it's totally blank. So the only things I can come up with is that the Android BOINC client comes with a cc_config.xml with <suppress_net_info> default on, or that Android doesn't allow sending of its IP address to internet servers.
I've checked the source code and can't find any evidence of that <suppress_net_info> being used. I've asked Oliver Bock about it, he doesn't know. I've asked Eric Korpela, just in case, but he doesn't know either.
Who does? :)
Apropos, seen this happen on both BOINC 7.4.43 and 7.4.53
Quick guess. If Android allowed apps to access device's IP address apps could use that to track people and Google doesn't like that. Apps are not allowed to access MAC address for that reason since Android x.y.
But wouldn't it then not allow the external IP (WAN) address instead of an internal (LAN) address? I doubt it's easy to figure out where 192.168.1.11 lives purely based on that IP address, while 84.xxx.xxx.173 is a lot easier. :)
But as I said, the external IP address is sent to the servers, just not the internal IP address.
Versus PC:
The external IP is the Return To address. Server always knows it and without it Internet wouldn't work.
But yeah, that could be used for tracking just as well. Bad guess.
Some background: the host's network details are looked up here. As you can see the domain name of an Android device is modified randomly in case its original hostname is "localhost". That in turn should pretty much cause the actual IP lookup to fail.
Note: I think the above code is buggy anyway as I don't understand why the hostname randomization is done before the hostname gets fetched further down below.
Apart from that, getting the local IP of an Android device might not be trivial to begin with since it's not clear which network interface (WLAN, cell, bluetooth, USB?) you should query. In fact you'd probably have to contact an external server first and use that's socket's local IP to be sure as that would use the currently active routing table to get the currently used interface.
