Currently I’m on a quest of finding configuration options to make computers easier to use. One of my recent problems was how to make sure that internet connections “just work”, especially in a dial-up kind of situation (where there are usernames and passwords involved). Here is the method that I developed for Windows XP (probably it will work from Win2K to Win2k8 – including Vista – but I didn’t try it there).

The heart of the solution is a simple batch file:

:start
ping -n 1 -l 8 google.com
if errorlevel 1 goto dial
goto end
:dial
rasdial "Broadband Connection" username password
goto start
:end
cls

What this does, is to ping google.com as a connectivity test (using only one packet of a small size to avoid tripping anti-DoS mechanisms), and if the ping fails, it tries to dial the connection. Some remarks:

• This solution works in both dial-up and PPPoE scenarios. In fact I developed it in the later situation).
• Instead of pinging google.com (or some other host), alternative connectivity tests can be used. For example performing a DNS lookup (nslookup google.com) or fetching a webpage (curl http://google.com). Two things to be aware of: some providers give you access to their DNS servers even before the authentication (DNS tunnelling anyone?), so it might not be the definitive test to determine connectivity. The second method (fetching a webpage) involves downloading a third-party utility, which you might be lazy to do 🙂
• There is a secondary benefit for me in using a DNS name (google.com) rather than an IP: I’ve set up OpenDNS on the machines, and for some reason, the first lookups can be quite timeconsuming (30″-60″). After that the rest of the lookups are fast. I know that I’m quite far from the London OpenDNS resolver, as can be seen from the traceroute dump displayed below, but this is still mysterious. On the upside: the initial ping takes care of the problem.

  Tracing route to resolver1.opendns.com [208.67.222.222]
  over a maximum of 30 hops:
  
    ...
    6    69 ms    71 ms    70 ms  Frankfurt.de.ALTER.NET [139.4.25.21]
    7    81 ms    71 ms    75 ms  ge-0-2-0.XR1.FFT1.ALTER.NET [149.227.18.97]
    8   152 ms   150 ms   156 ms  ge-1-1-0.IL1.DCA4.ALTER.NET [146.188.15.65]
    9   150 ms   153 ms   155 ms  0.so-7-0-0.IL3.DCA6.ALTER.NET [146.188.15.58]
   10   162 ms   161 ms   154 ms  0.so-5-2-0.XL3.IAD8.ALTER.NET [152.63.36.25]
   11   146 ms   147 ms   145 ms  POS6-0.GW5.IAD8.ALTER.NET [152.63.36.53]
   12   144 ms   143 ms   145 ms  63.65.187.230
   13   152 ms   144 ms   144 ms  resolver1.opendns.com [208.67.222.222]
  
  Trace complete.
  

• Putting useranmes / passwords in clear in the batchfile does represent some security risk, especially given that some providers have the (rather insecure) practice of basing these on personal details of the customer. However, one has to weigh the benefits, given that stored dialup passwords are already quite easy to retrieve.
• If you edit the batch file using Notepad, don’t forget to put the filename between quotes when saving (ie “dial_conn.bat” instead of dial_conn.bat). Failing to do so will result in an extra .txt extension being appended (ie dial_conn.bat.txt), which will make the run attempts fail.

A final note on how to start this batch file: you can either put in in the Startup group (just make sure that it starts a minimized to reduce the interference with the user). You can also run it from the task scheduler. This has the advantage of starting up even before a user is logged in (if the computer is used by multiple people). Also, it can eliminate the “should this connection be disconnected” prompts when switching between multiple users.