Google told me that others had attempted this before.  That solution seems to have been designed around linux and while it is all pretty much perl and it should have run on windows I just didn’t have the patience to get it working.  I could see that the solution used the truly excellent exiftool  by Phil Harvey.  I also knew that there was a standalone windows executable for exiftool.  Upon closer inspection I found that it could read GPS track logs in various formats and tag photos accordingly.

In the end I settled for just uploading the activity file to Garmin Connect, exporting it in GPX format and then using exiftool to batch process all the photos in the directory.

Update:  After loading my geotagged pictures in to Picasa and then pressing the geotag button I was surprised to find that the photos were not showing the correct location.  It seems that I had forgotten to check the time on the camera and it was out by almost 6 minutes. Exiftool came to the rescue again with its date/time shift feature

The bash shell script below is simple yet still capable enough to meet these occasional demands.  Without all the niceties the script amounts to just three lines.

1. The exec statement to connect file handle 3 to our socket.
2. Reading the input of the file handle and using cat to send it to the screen.
3. Reading STDIN  (keyboard) and writing it to our file handle.

A great example of how powerful  linux IO redirection can be.

#! /bin/bash
#
# Workaround for lack of telnet client on Secureplatform
# Uses Bash IO redirection to tcp sockets
#
usage(){
     echo "USAGE: $0 host port" >&2
}
#Check we have the right number of args on the command line
if [ -z "$1" -o -z "$2" ]; then
     usage
#Check if the script is sourced.
#We use return if it is to avoid exiting the parent shell
    if [ "$0" == "bash" ]; then
        return -1
    else
       exit -1
    fi
fi
#Redirect input and output from the socket to filehandle
exec 3<>/dev/tcp/$1/$2
#Output from the file handle goes to the screen,we run this process in background
cat <&3 &
#Input from the keyboard goes to our file handle. CTRL-C to exit.
cat >&3
#Close Output then input
exec 3>&-
exec 3<&-

Unix times are used by a number of Cisco products like in callmanager call record reports, as the OSPF cryptographic sequence number, and as the time measurements were taken using snmp bulkstats.

Taking leap seconds and leap years into account can be a messy business, but excel can help simplify the calculations to normal date and time by using the  vba DateAdd function.

Unfortunately it can’t be used directly in a cell formula but you can create a macro (vba function) that can be used in a cell formula.  The vba code I used is shown below.  Note that there is a second optional parameter  UTCOffset, the number of hours from UTC , that can be used to calculate local times. If omitted you will get UTC times.

Private Const SecondsPerHour = 3600
Private Const EpochStart = "1/1/1970" '1 Jan 1970 00:00:00 UTC
Function epochconvert(epochtime, Optional UTCOffset)
    If IsMissing(UTCOffset) Then
        epochconvert = DateAdd("s", epochtime, EpochStart)
    Else
        epochconvert = DateAdd("s", epochtime + SecondsPerHour * UTCOffset, EpochStart)
    End If
End Function

Function ToEpoch(dtDate, Optional UTCOffset)
    If IsMissing(UTCOffset) Then
        ToEpoch = DateDiff("s", dtDate, EpochStart)
    Else
        ToEpoch = DateDiff("s", EpochStart, dtDate) - SecondsPerHour * UTCOffset
    End If
End Function

If you need to perform a short data collection from  applications like syslog  or netflow that just pump out  udp packets then wireshark/tshark can work for you in a pinch.

Here’s the recipe for syslog.

tshark -i 2 -f "port 514" -T fields -e syslog

Using the -T fields switch allows us to specify which data to output with one or more  -e switches.  Since we have specified a protocol (syslog),  tshark prints multiple fields, in this case its the facility(LOCAL7),severity(NOTICE), and the remainder of the output below is the actual message.

Syslog message: LOCAL7.NOTICE: 27403: Dec 23 14:44:29: %SYS-5-CONFIG_I: Configured from console by root on vty0 (10.0.2.19)

The people that wrote the dissectors in wireshark have done all the hard work of interpreting the binary fields for us.  It’s worth noting that there is no documentation (that I am aware of)  for the field names. I usually just capture a couple of packets and export them in PDML format.  You can then open that file in any text editor and determine the field names from the XML.

Now as luck would have it I stumbled across a bug with tunnel interfaces miscalculating the IP mtu after the router is rebooted.   For  readers who just want the short story, the workaround is to always specify tunnel source by interface name, not ip address. Cisco TAC report that the bug exists across a large number of IOS versions and platforms. A bug ID has been requested from Cisco so that we can follow it. I’ll post it here once they allocate it.  The bug ID is CSCth31172. For those that would like proof of the bug read on.

To test this I configured two 2811 routers in the lab.  The configs can be viewed here for R1 and R2.  The relevant interface configurations for each are below.
R1 config

interface Tunnel2
  ip address 10.0.0.1 255.255.255.252
  ip mtu 1400  ip tcp adjust-mss 1360
  tunnel source Serial0/0/0.100 
  tunnel destination 192.168.0.2
  tunnel mode ipsec ipv4
  tunnel path-mtu-discovery
  tunnel protection ipsec profile MY_VTI
!
interface Serial0/0/0
  no ip address
  encapsulation frame-relay IETF
  clock rate 2000000
!
interface Serial0/0/0.100 point-to-point
  ip address 192.168.0.1 255.255.255.252
  frame-relay interface-dlci 100

R2 Config

interface Tunnel1
  ip address 10.0.0.2 255.255.255.252
  ip mtu 1400
  ip tcp adjust-mss 1360
  tunnel source 192.168.0.2
  tunnel destination 192.168.0.1
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile MY_VTI
!
interface Serial0/0/0
  no ip address
  encapsulation frame-relay IETF
  frame-relay intf-type dce
!
interface Serial0/0/0.100 point-to-point
  ip address 192.168.0.2 255.255.255.252
  frame-relay interface-dlci 100

The serial interface on router R1 that carries the tunnel traffic should have an mtu of 1500 bytes. We verify this by doing a ping with the df bit set.

R1#ping 192.168.0.2 df size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms

The IP  mtu of the tunnel2 interface is configured to 1400 bytes, an allowance of 100 bytes for ESP header/trailer and GRE headers.  That’s plenty, and we should be able to send 1400 bytes through with the DF bit set.

R1#ping 10.0.0.2 df size 1400

Type escape sequence to abort.
Sending 5, 1400-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

Something is not quite right. We can check the IP mtu of the crypto SA by issuing the command.

R1#show crypto ipsec sa | include mtu|interface
 interface: Tunnel2
      path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0.100
 interface: Tunnel21
      path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

Nothing obvious there, time to move on to router R2 and repeat the tests.  First confirm the mtu of the underlying interface.

R2#ping 192.168.0.1 df size 1500
 Type escape sequence to abort.
 Sending 5, 1500-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds: Packet sent with the DF bit set
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms

All good, now we can test the tunnel to R1 with 1400 byte packets.

R2#ping 10.0.0.1 df size 1400
 Type escape sequence to abort. Sending 5, 1400-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: Packet sent with the DF bit set
 M.M.M
*Jun  7 01:08:10.855: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1400, mtu=1343
*Jun  7 01:08:10.855: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1400, mtu=1343
*Jun  7 01:08:12.855: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1400, mtu=1343
*Jun  7 01:08:12.855: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1400, mtu=1343
*Jun  7 01:08:14.855: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1400, mtu=1343

Okay, so now we’re on to something.  The crypto engine tells us the mtu is 1343 or 57 bytes short of our expectation. Coincidentally that is suspiciously close to the 52 bytes overhead for ESP that Cisco has documented in “QoS DESIGN FOR IPsec VPNs“.

R2#show crypto ipsec sa | include interface|mtu
interface: Tunnel1
      path mtu 1400, ip mtu 1400, ip mtu idb Tunnel1
interface: Tunnel12
      path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

Notice the differences between tunnel 2 on R1 and Tunnel 1 on R2.  The IP mtu is 1400 bytes and the idb (I have no idea what idb means Interface Descriptor Block, thanks for the correction Ivan) is the actual tunnel interface and not the transit interface of the tunnel. We can reset the tunnel interfaces and the crypto SA’s by briefly shutting the interface.

R2#conf t
 Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int tu1
R2(config-if)#shut
R2(config-if)#no shut
*Jun  7 01:10:48.571: %LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down
*Jun  7 01:10:49.571: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun  7 01:11:07.555: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up
*Jun  7 01:11:08.555: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R2(config-if)#end
*Jun  7 01:11:18.515: %SYS-5-CONFIG_I: Configured from console by console
R2#show crypto ipsec sa | include interface|mtu
interface: Tunnel1
      path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0.100
interface: Tunnel12
      path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

The difference to tunnel1 after shutting down the interface is readily apparent. The IP mtu is now 1500 bytes and the idb is now the serial subinterface.  A 1400 byte ping should now be possible.

R2#ping 10.0.0.1 df size 1400
Type escape sequence to abort.
Sending 5, 1400-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
R2#

It’s not really viable resetting  tunnel  interfaces after every reboot, but our testing has found that Cisco’s workaround of specifying tunnel source by interface name rather than IP address has been 100% effective so far.

I had an unused two port E1 card in a Cisco 3845 router, making the testing easy.  One VRF for each E1 interface,  an E1 crossover cable and I was good to go.  Once the E1 controller channel group is configured a new serial port is created. This was the final config I used, and fortunately the frame relay pvc’s came up straight away. Mission accomplished. 

An important point to remember with VRF’s is that many of the usual commands have VRF specific variations. To do a ping test with this configuration you need to use the ping VRF command as shown below, or else you’ll just be using what’s in the global routing table.
router#ping vrf E1-0/0/0
Protocol [ip]:
Target IP address: 192.168.1.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: Serial0/0/0:0.37
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
router#sh ip route vrf E1-0/0/0

! Configure the serial controller on E1 0/0/0 with frame-relay encapsulation
! Note that one of the two serial interfaces has to be Frame-relay DCE when using a crossover.
interface Serial0/0/0:0
  no ip address
  encapsulation frame-relay IETF
  frame-relay lmi-type q933a
  frame-relay intf-type dce
!
interface Serial0/0/0:0.37 point-to-point
  no ip address
  ip vrf forwarding E1-0/0/0
  ip address 192.168.1.1 255.255.255.252
  frame-relay interface-dlci 37
!
interface Serial0/0/1:0
  no ip address
  encapsulation frame-relay IETF
  frame-relay lmi-type q933a
!
interface Serial0/0/1:0.37 point-to-point
  ip vrf forwarding E1-0/0/1
  ip address 192.168.1.2 255.255.255.252
  frame-relay interface-dlci 37

After a bit of googling I came up with this small script to gather all the installed .Net versions and a support function to test for a particular release version.  The same thing could be accomplished using a registry key as described by Aaron Stebner’s blog post. 

option explicit
'Detect which versions of DotNet Framework are installed.
'From Microsoft KB Article http://support.microsoft.com/kb/318785/
'By NetworkNerd 3/11/2009

Const WindowsFolder = 0
Const SystemFolder = 1
Const TemporaryFolder = 2
const DOTNET_10 = "v1.0.3705"
const DOTNET_11 = "v1.1.4322"
const DOTNET_20 = "v2.0.50727"
const DOTNET_30 = "v3.0"
const DOTNET_35 = "v3.5"

dim objFrameworkVers

set objFrameworkVers = CreateObject("Scripting.Dictionary")
wscript.echo "Found " & getFrameWorkVersions(objFrameworkVers) & " .NET Frameworks installed."
if HasDotNet(DOTNET_20) then
  wscript.echo "Has .Net Framework 2.0 installed"
end if

function HasDotNet(ver)
  if objFrameworkVers.exists(ver) then
    HasDotNet = True
  else
    HasDotNet = False
  end if
end function

function getFrameWorkVersions(byref objDict)
  dim fso, winfolder, strPath, basefolder, f
  Set fso = CreateObject("Scripting.FileSystemObject")
  set winfolder = fso.GetSpecialFolder(WindowsFolder)
  strPath = winfolder.path & "\Microsoft.NET\Framework"
  set basefolder = fso.getfolder(strPath)
  objDict.removeAll
  for each f in basefolder.subfolders
	objDict.add f.name, f.name
  next
  getFrameWorkVersions = objDict.count
end function

The quick solution to detect bootworks was to read the bootsector of the disk and look for some identifying strings. The code below shows how to read from a physical disk.  Note this has only been tested in Windows XP, and you require admin privileges.  The code below was called from a startup script so privilege wasn’t an issue.

When reading from a physical disk we need to seek, read and write in multiples of sector size and on sector boundaries. See Microsoft KB article 100027.  I use WMI to get the number of bytes per sector for the drive.

I found the signature by extracting the bootsector using a copy of dcfldd that was compiled for cygwin. I dumped it to file using the command below.
dcfldd if=”\\\\.\\physicaldrive0 of =”bootsec.bin” count=1

The file bootsec.bin can then be opened using good old debug to get the hex/ascii display

The same result can be achieved by booting to a linux live cd and using the command below.

 dd if=/dev/sda count=1 | hexdump -C

 Listing 1

using System;
using System.IO;
using System.Management;
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

namespace bwcheck
{
    class Program
    {
        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError=true)]
        internal static extern SafeFileHandle CreateFile(string lpFileName, int dwDesiredAccess, int dwShareMode,
            IntPtr lpSecurityAttributes, uint dwCreationDisposition, uint dwFlagsAndAttributes, SafeFileHandle hTemplateFile);

        internal const int GENERIC_READ = unchecked((int)0x80000000);
        internal const int OPEN_EXISTING = 3;
        internal const int FILE_ATTRIBUTE_NORMAL = 0x80;
        const String SIGNATURE = "Altiris EBootMastr";
        const int SEEKOFFSET = 3;
        const int LENGTH_TO_READ = 18;   // LENGTH_TO_READ = SIGNATURE.Length;
        const int RETCODE_SUCCESS = 0;
        const int RETCODE_IOERROR = 1;
        const int RETCODE_BADSIGNATURE = 2;
        const int RETCODE_HIT_EOF = 3;
// NB The where clause requires additional escaping even with the @string literal
        const String WMIQRY = @"Select * from win32_diskdrive where Name='\\\\.\\PhysicalDrive0'";
        const String WMI_NS = @"\\.\root\cimv2";
        //const String WMIQRY = "Select * from win32_diskdrive ";

        public static int Main(string[] args)
        {

            // TODO: Implement Functionality Here
            int retcode = RETCODE_SUCCESS;
            SafeFileHandle h = null;
            h = CreateFile("\\\\.\\PhysicalDrive0",
                            GENERIC_READ, 0, IntPtr.Zero, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,
                            new SafeFileHandle(IntPtr.Zero, true));

            if (! h.IsInvalid ) {
                try {
                    //Find the bytes per sector for the disk
                    //We must read, write and seek in multiples of sector size (ref: http://support.microsoft.com/kb/q100027)
                    //This is true even when we convert the handle to a filestream.
                    ManagementObjectSearcher objSearch = new ManagementObjectSearcher(WMI_NS, WMIQRY);
                    int bytespersector = 0;
                    foreach (ManagementObject objResult in objSearch.Get()){
                        bytespersector = Convert.ToInt32(objResult["BytesPerSector"]);
                    }
                    FileStream fstream = new FileStream(h, FileAccess.Read);
                    // Read from stream
                    Byte[] chunk = new Byte[bytespersector];
                    int bytesRead;
                    int bytesTotal = 0;
                    int bytesToRead =  bytespersector;
                    while (bytesToRead > 0) {
                        bytesRead = fstream.Read(chunk,bytesTotal,bytesToRead);
                        if (bytesRead == 0) {
                            break; //end of filestream condition
                        }
                        bytesToRead -= bytesRead;
                        bytesTotal += bytesRead;
                    }
                    if (bytesToRead > 0 ) {
                        retcode = RETCODE_HIT_EOF;
                    }
                    System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
                    String s = enc.GetString(chunk,SEEKOFFSET,LENGTH_TO_READ);
                    Console.WriteLine("{0}", s);
                    if (! s.Equals(SIGNATURE)){
                        retcode = RETCODE_BADSIGNATURE;
                    }

                } catch (Exception e) {
                    Console.WriteLine(e.ToString());
                    retcode = RETCODE_IOERROR;
                }
            }
            else
            {
                // get error code and throw
                int error = Marshal.GetLastWin32Error();
                Console.WriteLine("Last WIN32 Error: {0}", error);
                retcode = RETCODE_IOERROR;
            }
            return retcode;
        }
    }
}

This applet is used to add/delete static arp entries on 6509 core switches in a HSRP pairing, since you can’t have a static arp configured more than once on the HSRP cluster.  The mac address is a multicast mac address of a windows network load balanced server.

Listing 1

event manager applet deletearpvlan234
event syslog occurs 1 pattern "%HSRP-5-STATECHANGE: Vlan234 Grp 1 state Speak -> Standby"
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "no arp vrf SERVERS 192.168.1.100 0100.5e7f.00ac ARPA"
action 4.0 syslog msg "EEM deleted arp entry for 192.168.1.100"

event manager applet addarpvlan234
event syslog occurs 1 pattern "%HSRP-5-STATECHANGE: Vlan234 Grp 1 state Standby -> Active"
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "arp vrf SERVERS 192.168.1.100 0100.5e7f.00ac ARPA"
action 4.0 syslog msg "EEM added arp entry for 192.168.1.100"

To view this additional information in wireshark some extra configuration is required.

1. Select edit/preferences/protocols/ethernet
2. Check the box labelled “Attempt to interpret as Firewall-1 monitor file” and press ok
3. Select edit/preferences/User Interface/columns
4. Click add to add a new column and name it interface.
5. From the format dropdown listbox select FW-1 monitor if/direction and press ok

Save the text below to a file colorise.txt

# DO NOT EDIT THIS FILE!  It was created by Wireshark
@FW-Mon-i @ fw1.direction contains "i"@[65535,65535,0][0,0,0]
@FW-Mon-I @fw1.direction contains "I"@[37008,61166,37008][0,0,0]
@FW-Mon-o@fw1.direction contains "o"@[44461,55512,59110][0,0,0]
@FW-Mon-O@ fw1.direction contains "O"@[31161,49051,54875][0,0,0]

1. Select View/coloring rules
2. Click import and open the saved file from above
3. Select the last 4 rules and move them to the top of the list by clicking the up button
4. Press ok

Your now ready to view the fw monitor files in wireshark.

References

Wireshark modification for FW Monitor files