Closed Bug 1173931 Opened 9 years ago Closed 9 years ago

send offline/online events on Linux

Categories

(Core :: Networking, defect)

Unspecified
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox41 --- affected

People

(Reporter: bagder, Unassigned)

References

Details

With bug #654579, we get online/offline events on all platforms except Linux.

As with the Windows backend, we could scan all network interfaces to see if there's one that isn't loopback and is UP and then we are still "online" (in some sense of the word).

Here's a start using getifaddrs():

static int iflist(struct ifaddrs *list)
{
  /* Walk through linked list, maintaining head pointer so we
     can free list later */
  struct ifaddrs *ifa;

  for (ifa = list; ifa != NULL; ifa = ifa->ifa_next) {
    int family;
    if (ifa->ifa_addr == NULL)
      continue;

    family = ifa->ifa_addr->sa_family;

    if ((family == AF_INET || family == AF_INET6) &&
        (ifa->ifa_flags & IFF_UP) &&
        !(ifa->ifa_flags & IFF_LOOPBACK)) {
      return TRUE; /* online */
    }
  }

  return FALSE;
}

static int isonline(void)
{
  struct ifaddrs *list;
  int online;

  if(getifaddrs(&list))
    return 1;
  online = iflist(list);
  freeifaddrs(list);

  return online;
}
OS: Unspecified → Linux
This is already fixed, pending the pending bugs for it.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Is this in fact fixed? I'm looking at the release notes and they indicated that the Linux case is not supported. Is the fix landed on a different version?
What are the pending bugs for this fix?

This approach confirms only active network interfaces, it does not confirm actual connectivity to the outside world.

Also: This approach will not be able to confirm HTTP/HTTPS connectivity exclusively thru proxies in a secure environment.

You may want to coordinate with GNOME on their D-Bus, Network Manager, and GNOME Shell connectivity detection improvements. See here: https://bugzilla.gnome.org/show_bug.cgi?id=738694
This bug is marked RESOLVED FIXED which implies there's nothing pending for this bug.

As far as Firefox goes, "online" means that there is at least one interface up that isn't loopback/localhost. We do not have any further sense of "online" than so. There seems to be possible network connectivity to other machines.

> This approach will not be able to confirm HTTP/HTTPS connectivity

This makes no attempts at all to verify connectivity to anything really. You can use Firefox fine in your local network or in your office network or similar. That will be considered online even if you cannot reach the outside world or the Internet.

Checking for specific connectivity would be a much bigger and different effort. There's a related effort to detect captive portals which is more in that style, even if it isn't exactly the same as detecting online/offline.
Then you should check both IFF_UP && IFF_RUNNING. An interface can be administratively up but not running if it is unplugged.

I wonder if there are something akin cross-origin concerns here: I have local-LAN connectivity, but I do not have connectivity to the example.com origin of the app I'm using ??? Just a thought...

Thanks for the input.
See https://dxr.mozilla.org/mozilla-central/source/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp#125 for the current Linux implementation.

> I have local-LAN connectivity, but I do not have connectivity to the example.com origin of the app I'm using 

I hear you, and I can see how connectivity knowledge can be useful. That's not what this online event is though.
You need to log in before you can comment on or make changes to this bug.