[Replicant] [PATCH v2] Fix "RepWifi connection not correctly reported to userspace apps" Issue #1792.

[Fil]

Joonas Kylmälä wrote:
> It is common practice to define them at top of the file. Also the AOSP
> guidelines have it:
> <https://source.android.com/source/code-style#define-fields-in-standard-places>.
> Well, now you might say that that is no reason but the thing is that
> people are expecting them to be there and it makes it easier to read the
> code for them if the things are in the familiar places.
I didn't say there's no reason to put those declaration at the top of
the file. I just said I have *my* reason to keep them where they are,
but I could move them if some other *strong* reason is given.

Anyway, I read those guidelines, and I tried to be as compliant as
possible. What they actually say is: "Define fields either at the top of
the file *or immediately before the methods that use them*." And that's
what I did.

> No, I'm pretty sure my university network gives public ip addresses for
> everyone connecting to their wifi.
I'm pretty sure you should double check on that one. Please, see [1].

> > The reason why I put the additional condition that interface's address
> > must be in the "site local" range, is that it tries to enforce the fact
> > that WiFi negotiation hasn't failed. 
> > It's an effort to be "less uncertain" about the interface being
> > *actually* connected to WiFi and try to avoid "false positives".
> > For example, if something in the negotiation goes wrong, wlan0 could
> > still have an IP address. Maybe it could be in the "link local" range.
> > That condition cuts away at least that case, reducing the likelihood of
> > reporting "false" connections.
> 
> I don't know what to do about this.

I honestly don't think anything else needs to be done on that side.. 
Or.. well.. a DNS query or a ping could be issued to be sure the
connection is real. But there are a few downsides with that approach:
1) it would cause way too much overhead and may make calling
applications lag for too long or even crash if they think their request
to getActiveNetworkInfo() has timed out (I've experienced this behaviour
while debugging my patch).
2) hard-coded IP addresses should be included as DNS or ping targets. No
good.
3) I'm quite sure that the original method itself doesn't perform any
practical check on the reachability of the internet. It just reports
what kind of connection the device is currently using (namely, data or
wifi). And I don't want to change the original scope of the function so
much.

I'm at complete disposal for any further request of clarification.

Happy hacking.

Fil

[1]https://en.wikipedia.org/wiki/Wireless_LAN 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20170807/7b80335c/attachment.asc>