views:

164

answers:

3

Our team is developing a Internet Media device based on Linux 2.6. Currently we detect whether Internet connectivity is established (via a wired Ethernet i/f) by pinging www.google.com

Some networks we have tested the device on do not support ICMP packet forwarding so our application code mistakenly reports the Internet as unavailable in this case.

Does anyone know of a more refined approach to deducing whether Internet connectivity is available through /dev/eth0 without resorting to pinging a well-known service?

+2  A: 

There is a great answer to a similar question here on stackoverflow... In short: check for a default route.

ChristopheD
This is a really helpful response and a very neat approach indeed.
sototozo
+3  A: 

As the guy who wrote that answer referenced by ChristopheD, that's not the approach I'd use here. It worked for the other question, because in that case we were checking for the presence of a direct PPP link from the current machine - in this case, you're connected to an abitrary network which may or may not already have a default route, independent of its wider internet connectivity.

Since you need global DNS connectivity for your app, I'd check for that - look up an address you know will always exist - like an NS type query for the com. domain. Use a reasonably long timeout and/or retry a few times before giving up. Something like this:

dig NS +aaonly com.

Ignore the output and test the exit value - 0 indicates the lookup was able to contact the root servers, anything else and it wasn't.

caf
+2  A: 

Ultimately you want the device to be able to use the Internet for some useful function. If there's a well-defined server that the device commonly connects to, then it would be useful to send a query to that.

In between "nothing" and "useful function" there are many steps, and you could potentially check any of those as some measure of "connectivity":

  • Ethernet cable plugged in (or PPP link established, or Wi-Fi, whatever is your low layer)
  • DHCP server assigned address (if applicable)
  • Default gateway is functioning
  • DNS server is responding
  • Destination server is responding (maybe not an ICMP ping, but a small HTTP query or whatever other protocol you might be using)

Depending in how savvy your customer is, or if you want a useful error/diagnostic that they can report to tech support, it could be useful detecting all of those.

Might also be useful being able to do a traceroute as a diagnostic tool.

Craig McQueen