Stephen Kingston

I’ve been playing with the Google Maps API.

The Google Maps API allows the inclusion of google maps on your own pages, and you can use the Asynchronous JavasScript and XML (AJAX) to interact with the maps. It is all very interesting, and I want to do more with this – not least because of the seamless fusion between GIS data (of which I have a fair amount) and the web.

I have previously used MAPServer, but whilst google maps does not have all the feautures of MAPServer, it odes come with a complete set of maps included!

So here is the problem. At www.root-servers.org you will find a complete list of the 13 DNS root name servers that make all other name service lookups work. But where are these root name servers?

Well this is not accurate to the street level, but I used the information on the site to geocode locations for the root name servers, and you can view them at myRoot Nameservers page.

In the last few years there has been much experimentation and roll out of IPv4 Anycast Services to clone the functionality of these thirteen key root name servers. This reduces the clustering of all the vital name servers around the Washington DC area, and provides faster lookup to localities that were historically far removed from the nameservers. I again geocoded data from root-servers.org to come up with this page of the current location of all Worldwide Root Nameservers.

Let me know what you think.

Some useful pages about IPv4 address exhaustion are as follows:

The Internet Protocol Journal

Geoff Huston’s dynamically generated graphs

Tony Hain’s latest quaterly updates

Some links to go with today’s seminar in which we discussed the campaign for a new TLD for Wales are here:

The .cym Campaign

Ping Wales article on the .cym campaign

The .cw Campaign

In my previous post I showed how to get NMEA data from my TomTom GPS. You will also notice that the latitude and longitude data was presented thus:


  W 5224.771484
  N 404.355896


The sharp eyed reader will realise that actually, latitudes are a number of degrees north or south of the equator, whereas longitudes are a number of degrees east or west of the prime meridian (in Greenwich… did I mention I recently got lost on my way home from Greenwich?)

Even sharper eyed readers will realise that Aberystwyth is roughly 4 degrees to the west of Greenwich and roughly 52 degrees north of the equator. So what is happening here?

I think it is a Mac stumbler bug. I haven’t checked, but essentially I just ignored the letters “N” and “W” when converting my data in my XSL stylesheets in the previous post. If you are east of Greenwich or south of the equator, you will have to fix the stylesheets by hand!

In my last post I wrote about how I attached my TomTom One to my Mac via bluetooth to extract the GPS data. I hooked this all up to Mac stumbler and took a drive around Aberystwyth to see what wireless access points were advertsing themsleves. I used no special aerials, nor did I try and look for access points that were not advertising themselves – if a beacon frame made it to my Mac sitting on the passenger seat, it was counted – otherwise the access point was ignored.

The results of my drive are displayed in this Google map of some Aberystwyth Wireless Access Points. I haven’t put all captured fields of data into this map, because it is just for demonstration purposes. It is also not a complete map of Aberystwyth access points for the same reason. The third disclaimer is that the markers show the locations where I first saw a beacon frame and not the position of the strongest signal from the access point.

But the question is: how do we get the data from Mac stumbler to Google maps?

Mac stumbler saves its data in a “plist” XML format. This is a slightly odd format that looks like this:

<plist version="1.0">
<array>
    <dict>
        <key>channel</key>
        <integer>1</integer>
        <key>comments</key>
        <string></string>
        <key>date</key>
        <date>2006-11-08T17:26:57Z</date>
        <key>latitude</key>
        <string>W 5224.795410</string>
        <key>longitude</key>
        <string>N 404.561493</string>
        <key>mac</key>
        <string>00:12:17:DD:99:0E</string>
…
</dict></array></plist>

and so on.

What would make more sense would be:

<node>
  <channel>1</channel>
  <comments />
  <date>2006-11-10T17:57:11Z</date>
  <latitude>W 5224.771484</latitude>
  <longitude>N 404.355896</longitude>
  <mac>00:12:17:DD:99:0E</mac>
…
</node>

So I wrote an XSL style sheet which would do this translation, and ran the plist file through xalan to apply the stylesheet. The stylesheet is here: 

<?xml version="1.0" ?>
<xsl :stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    </xsl><xsl :template match="array">
        <nodelist>
            <xsl :apply-templates select="dict"/>
        </nodelist>
    </xsl>

    <xsl :template match="dict">
        <node>
            <xsl :apply-templates select="key"/>
        </node>
    </xsl>

    <xsl :template match="key">
        </xsl><xsl :element name="{translate(text(), ' ', '_')}">
            <xsl :value-of select="following-sibling::*"/>
        </xsl>
  </xsl:template>
</xsl:stylesheet>

At this point, I could have just written a google maps page to read my data, but there is a complication. NMEA format presents data in degrees and minutes, whereas google maps and many other applications want to use decimal degrees. I wrote another stylesheet that translates the NMEA data to decimal degrees and then throws out the results in someting that I could copy and paste into an existing google maps page. This is not pretty (and the XML code is not as neat as I would like), but I wanted something running quickly, so here is the code I used:

< ?xml version="1.0" ?>
<xsl :stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl&:output method="html" omit-xml-declaration="no"
     doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
     doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" />

  </xsl><xsl :template match="node">
    </xsl><xsl :variable name="lat1">
      <xsl :value-of select="substring(latitude,3) div 100" />
    </xsl>
    <xsl :variable name="lon1">
      <xsl :value-of select="substring(longitude,3) div 100" />
    </xsl>
    <xsl :variable name="lat2">
      <xsl :value-of select="floor($lat1)" />
    </xsl>
    <xsl :variable name="lon2">
      <xsl :value-of select="floor($lon1)" />
    </xsl>
    <xsl :variable name="lat">
      <xsl :value-of select="(($lat1 - $lat2) div 0.6) + $lat2" />
    </xsl>
    <xsl :variable name="lon">
      <xsl :value-of select="(($lon1 - $lon2) div 0.6) + $lon2" />
    </xsl>

    var marker = createMarker(new GPoint(-<xsl :value-of select="$lon"
         />,  <xsl :value-of select=”$lat”  />), 0<xsl :if test=”wep=’Yes’”
         >1</xsl>,”<xsl :value-of select=”ssid” /><xsl :value-of select=”mac” />“);
    map.addOverlay(marker);
  </xsl:template>

</xsl:stylesheet>

Having run the plist through xalan again, I coped and pasted the results into the web page example above.

Okay, I have successfully connected my new TomTom One with my Mac laptop via bluetooth, such that the GPS data can be read by applications. It was not quite the way I wanted to do it, but it works well enough. Here then are instructions if you want to do the same (complete with how to get Macstumbler to read the GPS data).

Safety first: Do not follow these instructions until you have backed up your SD card safely, and have tested the restore process. Restore to a new SD Card and keep your original SD card safe. The details on this web page do not constitute a recommendation that you should follow them. You do so entirely at your own risk.

Okay, with those disclaimers over, and if you want to proceed, then you need to do the following:

1) Install the rfcomm executable onto your SD card
2) Install a startup script that will create the rfcomm bluetooth connection(s)
3) Tell your Mac to listen for the connections
4) Tell Macstumbler and other applications where to find the GPS data feed

There is an easy method and a hard method to do this. I’ll detail the easy method first.

You can install the missing rfcomm executable and some pre-built scripts by downloading the Wildtom package (tt-bt-net2.zip from Roberto Piola’s site). If you want to connect to a Linux box with bluetooth, this is all you need. Just follow the instructions in the package.

However, if you have a Mac, then you have some more work to do. Copy the files in the Wildtom package onto your SD card, and then edit the gpsproxylistener file in the wildtom folder on the card. You are going to alter this so that it no longer listens for incoming connections, but tries to open a connection to your Apple mac.

Why?

Unfortunately the Mac does not provide the tools for creating a direct RFCOMM connection to the TomTom one. It tries to do everything through the GUI interface. This would be great, except that the RFCOMM serial ports on the TomTom are not discoverable, and it resists pairing. If you could pair to the TomTom one from a Mac (using the Pairing key of 0000) you could theoretically just connect up the serial ports, but I couldn’t make this work unfortunately.

Right, so we have to get the TomTom to initiate the bluetooth serial connection to your Mac. How do we do that? Well, the first step is to discover the MAC (Media Access Control) address of your Mac’s bluetooth adaptor. click the “Apple” menu, choose “About This Mac” and click the “More Info” button. Under “hardware”, click “Bluetooth” and your Bluetooth Mac address is listed in the address field. It is a six byte number that looks something like this: 00-14-51-00-01-02. Note this down.

Okay, so we have the MAC address. Now plug in your TomTom One to your Mac and let it connect to the computer so that you can access the SD Card. Navigate into the “wildtom” folder on the SD card and edit the file called “gpsproxylistener”. Change the “rfcomm listen … ” line to read:


/mnt/sdcard/wildtom/rfcomm connect 1 00:14:51:00:01:02 3 &


Substituting your bluetooth MAC address for the one above of course. Technically, this is no longer a gpsproxylistener, but don’t worry about that detail!

And that is it. You are ready now to connect your TomTom. Disconnect from your computer, and click your way through te menus to find the newly installed “start BT services” button. Click this and click Okay to the following question, and your TomTom should now try to connect with your Macintosh. The gps data feed should appear on rfcomm channel 3, which should be your Bluetooth-PDA-Sync serial port (if you use a PDA, you may wish to modify the rfcomm cahnnel from 3 to 1 and add in a new incoming serial port).

Try it out. Fire up Macstumbler, or some other GPS aware application. In Macstumbler, choose preferences and choose to enable GPS support, and select /dev/tty.Bluetooth-PDA-Sync as the GPS device.

Make sure the TomTom One is not in your house (if your car is out the front, lock the TomTom in the car and go inside. Because we are using Bluetooth you don’t need to be right next to the GPS when testing). Once you get a GPS lock, “Show GPS status” in Macstumbler will give you your GPS location in NMEA format.

You are now ready to go for a drive and collect some test data!

This article is long enough now. Watch out for the next installment: How to convert NMEA data and Macstumbler output into something you can use on Google maps.

I mentioned an article in the Internet Protocol Journal in today’s lecture, looking at the anatomy of Network Address Translators. The article is by Geoff Huston of APNIC, and is called Anatomy: A Look Inside Network Address Translators

The forward of the article reads:

Over the past decade numerous IP-related technologies have generated some level of technical controversy. One of these is the Network Address Translator, or NAT. This article describes the inner workings of NATs in some detail, and then looks at the issues that have accompanied the deployment of NATs in the Internet that appear to have fueled this technical controversy. NATs are a very widespread feature of today’s Internet, and this article attempts to provide some insight as to how they operate, why there is such a level of technical controversy about NATs, and perhaps some pointers to what we have learned about technology and the process of standardization of technology along the way.

After our discussion of the sliding windows protocol today, and of what makes a good window size for a TCP connection, I was asked what the default window size is in Microsoft Windows XP, and how to change this.

The answer is that the default window size is just 16KB. The value can be adjusted in the registry, and the details are listed below. The TCP1323 key will turn on the window scaling option. The second key raises the default window size from 16KB to 128KB, and the third option sets the maximum window size for all connections to 1MB (if you don’t set this, the default in Windows is 64K, and this will take precedence over your other parameters).

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323=1
HKLM\SYSTEM\CurrentControlSet\
      Services\Tcpip\Parameters\TcpWindowSize=131400
HKLM\SYSTEM\CurrentControlSet\
      Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=1048576


The global max tcp window size parameter illustrates something I did not mention in the lecture – that during the lifecycle of a connection, TCP implementations can adjust their buffer sizes on the fly. Adjusting downwards can be problematic (leading to shrinking windows), but adjusting upwards allows the operating system to allocate more memory only to those TCP connections that require large buffers.

On Linux you can achieve the same thing. To change TCP settingson 2.4 kernels and later, you add the entries below to the file /etc/sysctl.conf, and run “sysctl -p”.


# increase TCP maximum buffer size
net.core.rmem_max = 1048576
net.core.wmem_max = 1048576
# increase Linux autotuning TCP buffer limits (min, default max)
net.ipv4.tcp_rmem = 4096 131400 1048576
net.ipv4.tcp_wmem = 4096 131400 1048576


On a Mac, the same effect is obtained with these commands:


sysctl -w kern.ipc.maxsockbuf=1048576
sysctl -w net.inet.tcp.sendspace=131400
sysctl -w net.inet.tcp.recvspace=131400


Apple also provides a Broadband Tuner patch that does some similar tuning for you on Mac OS X 10.4 and above.

The Mac is based on BSD, and the method for tuning BSD is similar. Add the following lines to /etc/sysctl.conf and reboot.


kern.ipc.maxsockbuf=1048576
net.inet.tcp.rfc1323=1
net.inet.tcp.sendspace=131400
net.inet.tcp.recvspace=131400


Obviously the actual values you use for buffer sizes will depend on the bandwidth and latency of your networks, but these values above should be a good starting point.

I was asked at the end of today’s lecture whether there was additional information to help understand subnets. Here are some pointers:

1) Take a look at the website for Behrouz Forouzan’s “TCP/IP Protocol Suite” (the course text). There are some powerpoint slides for chapter 5 (the chapter on subnetting) that go into considerable detail about subnetting and CIDR.

2) Wikipedia has an entry that (at the moment at least) is substantially complete.

3) Tech Republic has an IP subnetting made easy article, which claims to provide a clear and graphical method of understanding subnets. I am not sure if I agree that this site is particularly clear, but on the basis that different people learn differently, I offer it up. Please comment to let me know if it helps or not.

I mentioned in today’s lecture that the linksys wrt54g has a small tftp service built in that can be used to reflash the firmware on the device. You can obtain custom firmwares that do much more than you would expect for a £50.00 home access point.

To find out more, you could point your browser at The OpenWRT page, where you can assemble yourself a custom router that can do just about anything you like. (I have one that does FreeRADIUS authentication on my home wireless network).

If you just want lots of cool features done for you with a minimum of effort, look at DD-WRT, which gives you a firmware with many features you would not expect in a small home access point.

Be warned though, that you update your firmware at your own risk. There is a small risk that your device will stop functioning, and that your shiny blue access point will become an interesting door stop. In particular, do not stop the TFTP server from listening for a new firmware at power on. You will need this if you load a firmware that doesn’t work!

Wikipedia also has a page about this router. I have also seen pages that describe how to:

1. Add serial ports to your router, so that you can use it with serial devices including plain old modems.

2. Customise your wrt54g to create a “POP in a box” – a wireless portal for public use.