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

Fil fil.bergamo at riseup.net
Sun Aug 6 19:40:17 UTC 2017


Hi Joonas,

thank you for taking the time to read and comment on my patch!

Joonas Kylmälä wrote:
> Fil:
> > +    // TODO RepWifi extension. Remove when a low-level, long-lived
> > solution is found.
> > +    private static final String IFACE_NAME_WIFI = "wlan0";
> > +    private static final String IFACE_NAME_TETHER = "rndis0";
> 
> I think these are now used before this declaration and could be
> therefore moved bit more upwards. See the line "ni =
> getNetworkInfoByInterfaceName(IFACE_NAME_TETHER);".

Yes, indeed you are right..
I put them there, close to "getNetworkInfoByInterfaceName()", just to
keep all my modifications together, so that it's easier to locate them
and remove them in the future.
They can be moved above getActiveNetworkInfo() if there's any strong
reason to do so.

> > +            while (ads.hasMoreElements()) {
> > +
> > +                InetAddress a = ads.nextElement();
> > +
> > +                if (a.getHostAddress() != null &&
> > a.isSiteLocalAddress()) {
> > +                    // if the interface has a valid IP address in the
> > range of a
> > +                    // local network we consider it is connected to an
> > AP.
> 
> I think this needs to be widened. The AP could also give a public IP, right?

Mmm.. I don't really think that could be the case..
I'm no expert in networking, but FWIK WiFi works strictly inside Local
Area Networks, so there should be no reason for any router or AP to
assign public IP addresses. I think the same applies to reverse
tethering.
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.

If anything is missing in my explanation, please feel free to ask :)

Thank you again for your comments!

Fil

-------------- 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/20170806/b6869560/attachment.asc>


More information about the Replicant mailing list