Monday, September 17, 2012

Reach the Beach Relay - 2012

Massakruliks - Mixed Open

147/425 - 28/117

Back row from left: Bill (leg 3), Randy (leg 7), Gavin (leg 5), Dave (leg 1), Dan (leg 9)

Middle row from left: Patty (leg 12), Jen (leg 6), Jodi (leg 11), Suzi (leg 10), Ashley (leg 8), Jackie (leg 4)

Front row: Vince [aka: Me] (leg 2), Krulik [aka: Mascot] (on my leg)

Vert
Distance Difficulty Gain Loss Net Time Pace
Leg 2 8.96 Hard 285 127 158 69:48 7:47
Leg 14 7.57 Moderate 492 502 -10 54:12 7:10
Leg 25 * 7.1 (wild card) Moderate 56:05 7:54
Leg 30 * 3.15 Easy 101 173 -72 21:52 6:57
26.78 3:21:57 7:32

* Due to an injury to Leg 1 runner, I doubled-up on our last set running his leg (Leg 25) and the last leg for our van (Leg 30) - Jen took my original Leg 26.

Monday, August 20, 2012

IPv6 in Perl on Windows

The state of IPv6 support in Perl has long been lamented but there are those trying to change this including Paul Evans who's updating many of the networking modules - including the Socket core module - to support IPv6. It's a shame the C compiler shipping with Strawberry Perl still doesn't accommodate IPv6 on Windows.

I've been using Strawberry Perl after switching from ActiveState since version 5.10. I found myself needing more and more XS modules and the ActiveState PPM process was always lagging behind. I had a copy of MinGW gcc - the free Windows port of the 'gcc' compiler - and with 'dmake', I could build my own modules directly from CPAN. However, I had some issues and when I learned about Strawberry Perl including the gcc compiler in the distribution, I switched. I've used Strawberry Perl on Windows XP 32-bit and now Windows 7 64-bit.

I've also recently been doing a lot of IPv6 work and using Perl as a quick development platform to test the IPv6 protocol proved easy with the Net::Frame modules detailed in an early series of blog posts. However, when looking to create sockets with Perl, I found errors, most notably:

Socket::inet_ntop not implemented on this architecture

The lack of this function prevented the display of IPv6 addresses and it's missing complement - inet_pton - prevents the resolution of IPv6. These functions are certainly present in Windows 7.

The issue lies in the header and library files distributed with MinGW gcc compiler in the Strawberry Perl release. They simply don't identify the functions in the headers, nor provide linkage to them in the libraries. Fortunately, tools shipped with the MinGW gcc compiler in Strawberry Perl can be used to remedy the issue and get full IPv6 functionality. Here's how.

First off, we need to update the header file with the function prototypes. I did this by creating a new header file called 'ws2tcpip-win.h':


#ifndef WS2TCPIP_WIN_H
#define WS2TCPIP_WIN_H

typedef USHORT ADDRESS_FAMILY;

#if (NTDDI_VERSION >= NTDDI_VISTA)
WINSOCK_API_LINKAGE INT WSAAPI inet_pton(INT, PCSTR, PVOID);
WINSOCK_API_LINKAGE INT WSAAPI InetPtonW(INT, PCWSTR, PVOID);

WINSOCK_API_LINKAGE PCSTR WSAAPI inet_ntop(INT, PVOID, PSTR, size_t);
WINSOCK_API_LINKAGE PCWSTR WSAAPI InetNtopW(INT, PVOID, PWSTR, size_t);

#define InetPtonA       inet_pton
#define InetNtopA       inet_ntop

#ifdef UNICODE
#define InetPton        InetPtonW
#define InetNtop        InetNtopW
#else
#define InetPton        InetPtonA
#define InetNtop        InetNtopA
#endif

#if INCL_WINSOCK_API_TYPEDEFS
typedef INT (WSAAPI * LPFN_INET_PTONA)(INT Family, PCSTR pszAddrString, PVOID pAddrBuf);
typedef INT (WSAAPI * LPFN_INET_PTONW)(INT Family, PCWSTR pszAddrString, PVOID pAddrBuf);

typedef PCSTR (WSAAPI * LPFN_INET_NTOPA)(INT Family, PVOID pAddr, PSTR pStringBuf, size_t StringBufSize);
typedef PCWSTR (WSAAPI * LPFN_INET_NTOPW)(INT Family, PVOID pAddr, PWSTR pStringBuf, size_t StringBufSize);

#ifdef UNICODE
#define LPFN_INET_PTON          LPFN_INET_PTONW
#define LPFN_INET_NTOP          LPFN_INET_NTOPW
#else
#define LPFN_INET_PTON          LPFN_INET_PTONA
#define LPFN_INET_NTOP          LPFN_INET_NTOPA
#endif

#endif  //  TYPEDEFS
#endif  //  (NTDDI_VERSION >= NTDDI_VISTA)

#endif

Next, copy that file to the appropriate location:

copy ws2tcpip-win.h c:\strawberry\c\x86_64-w64-mingw32\include

and update the existing 'ws2tcpip.h' file in that location with the following:

#include <ws2tcpip-win.h>

Now we need to create the library. This is done by first exporting the symbols from the appropriate DLL file - in this case, ws2_32.dll - and then creating the link library. The version of the MinGW gcc compiler with Strawberry Perl has 'pexports' included, so simply create the DEF file:

pexports c:\windows\system32\ws2_32.dll > ws2_32.def

Now create the library:

dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libws2_32-new.a --input-def WS2_32.def

Then put the new library in the appropriate location:

copy libws2_32-new.a c:\strawberry\c\x86_64-w64-mingw32\lib

Now we're ready to go. Get the latest release of Socket from CPAN, unzip and extract the tar file. Change into the directory and start the build process:

perl Makefile.PL

Now, before doing the 'dmake', edit the generated Makefile. Find the "DEFINE =" and "LDLOADLIBS =" lines and update them as per below:

DEFINE = -DHAS_GETADDRINFO -DHAS_GETNAMEINFO -DHAS_SOCKADDR_IN6 -DHAS_IP_MREQ -DHAS_IP_MREQ_SOURCE -DHAS_IPV6_MREQ -DHAS_INETNTOP -DHAS_INETPTON -DAF_INET6

LDLOADLIBS = -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lws2_32-new

Finally, 'dmake', 'dmake test' and 'dmake install' and you're good to go with IPv6!

Friday, August 17, 2012

The Adventures of Rich and Vince




Characters courtesy of SP Studio

Tuesday, July 31, 2012

Makeshift Mobile IPv6

For all its benefits, IPv6 also has increased support for mobility. This is due to the header structure of IPv6 accommodating extension headers - one of which is a mobility header.

However, given the slow adoption and limited deployment of IPv6, use of the mobility header isn't really prevalent and mobility of IPv6 nodes - my computer in this example - leaves a lot to be desired.

In fact, the only reason I have IPv6 working at home isn't from the forethought of my Internet Service Provider - Comcast, but because I'm tech-savvy and configured a Hurricane Electric 6in4 tunnel through their Tunnel Broker service.


NOTE: Comcast is very far ahead of many ISPs when it comes to IPv6 support including dual-stack support to end customers - unfortunately, just not in my area.


While the HE 6in4 tunnel works fine from my home - terminating on my home router with DD-WRT and providing all equipment in my home network with IPv4/IPv6 support - it doesn't help me when I'm not at home. When I take my computer anywhere - even into the office - I no longer can use IPv6, unless of course the network I connect to has IPv6 deployed (not likely).

My solution albeit not a very elegant one is to use another of the 5 free 6in4 tunnels HE provides me with. The first is for my home network and that stays static. The second one I have configured to a random endpoint which changes based on my location. HE offers a web-based update both manually and via a simple GET URL to change the local endpoint IP address of any of your 6in4 tunnels. The HE server examines the IP address from which it sees your request come from and adjusts the tunnel configuration on the server side. I even wrote a simple batch script to call the HE URL and configure the local tunnel interface on my computer. This works great ...

... but of course there's a catch. HE requires that the local IP address to terminate the tunnel be reachable via Ping. Therefore, if ICMP echo-requests are blocked or echo-replies are not sent, the tunnel won't get built. This is an issue as many sites prevent ICMP for security purposes - in fact, most all home routers disable ICMP from the Internet by default. For my home router, I can change the setting to have the tunnel built, but when I'm travelling, I'm relying on the network to allow ICMP so my mobile IPv6 tunnel can be built. Again, not the most elegant solution.

There are other options. SixXS offers a tunnel broker service and a client AICCU that provides AYIYA (Anything In Anything) support. This may provide a client-based alternative that doesn't rely on a provider network to support IPv6 or ICMP to build a 6in4 tunnel. I may test this next time I'm away.

Wednesday, July 25, 2012

The Adventures of Rich and Vince




Characters courtesy of SP Studio

Monday, May 21, 2012

Reach the Beach Relay - MA - 2012

Massakruliks - Mixed Open

46/175 - 13/52

Back row from left: Emily (leg 9), Bayen (leg 8), Bill (leg 7), Dan (leg 2), Robert (leg 3), Jen (leg 12)

Middle row from left: Ashley (leg 10, 11), Patty (leg 5), Jodi (leg 6), Suzi (leg 1)

Front row: Vince [aka: Me] (leg 4)

Vert
Distance Difficulty Gain Loss Net Time Pace
Leg 4 8.42 Moderate 678 750 -255 62:51 7:28
Leg 16 4.63 (actual) Easy 164 127 37 32:10 6:57
Leg 28 8.11 Hard 194 248 -54 59:05 7:17
21.16 (actual) 2:34:06 7:17

Wednesday, May 09, 2012

The Adventures of Rich and Vince




Characters courtesy of SP Studio
 

Copyright © VinsWorld. All Rights Reserved.