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 [22.214.171.124] over a maximum of 30 hops: ... 6 69 ms 71 ms 70 ms Frankfurt.de.ALTER.NET [126.96.36.199] 7 81 ms 71 ms 75 ms ge-0-2-0.XR1.FFT1.ALTER.NET [188.8.131.52] 8 152 ms 150 ms 156 ms ge-1-1-0.IL1.DCA4.ALTER.NET [184.108.40.206] 9 150 ms 153 ms 155 ms 0.so-7-0-0.IL3.DCA6.ALTER.NET [220.127.116.11] 10 162 ms 161 ms 154 ms 0.so-5-2-0.XL3.IAD8.ALTER.NET [18.104.22.168] 11 146 ms 147 ms 145 ms POS6-0.GW5.IAD8.ALTER.NET [22.214.171.124] 12 144 ms 143 ms 145 ms 126.96.36.199 13 152 ms 144 ms 144 ms resolver1.opendns.com [188.8.131.52] 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.