New version of my take on wake-up calls is up.
Most noticeable change here is having everything accessible over toolbar. In past some options were in hidden menu but that menu is gone now.
Other feature that is long overdue is upgrade functionality within application.
There was also some bug-fixing involved but that stuff is too boring.
Enjoy new version.
Few days ago I tried to get my VHD Attach to run on Windows Thin PC.
Initial diagnosis was easy - there was no .NET Framework installed. While there is no way to install .NET Framework 3.5 on Windows Thin PC, .NET Framework 4.0 installs just fine.
Next run gave us another clue with System.IO.FileNotFoundException: Could not load file or assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
While .NET 4 is backward compatible, Microsoft made intentional decision that it will not run applications made with earlier runtimes. This is not a big issue in Windows 7. There you have 2.0, 3.5 and 4.0 installed side-by-side and each application can pick whatever it needs. However, in Windows Thin PC there is only 2.0 and 4.0. Notice that one version is missing and it was the one I needed.
To make long story short, there is solution that does not involve recompiling. Just add Application Configuration Files (App.config) and put following text into it:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" />
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>This will tell application to run on .NET 4 if possible and to fallback to 3.5, 3.0 and 2.0 as a backup solution. This might not be most beautiful solution but it is a solution that works.
P.S. Yes, supportedRuntime cannot distinguish between .NET 2.0, 3.0 and 3.5.
This is very small update to VHD Attach. I removed application config files introduced with last version. Of course that means that both Thin PC users will hate me. For them, there is FAQ with separate download.
I do plan to sort things out in later version.
Welcome to my new web server. And for the first time ever, it is Linux-based.
I haven’t moved because Windows were unstable (haven’t had any issues). I haven’t moved because of bugs (PHP is buggy on any platform). I haven’t got tired of .NET (C# rules!).
I moved because of SSH. I grew tired of plain-text FTP where any kid with Wireshark could get my password.
My hosting company made sure that server change went smoothly. They just switched DNS records and, poof, my website on new server started. It is true that, for a while, there was no CSS or JavaScript but culprit was found in W3 Total Cache plugin. It just didn’t like being copied around and quick uninstall sorted that out. :)
There were few other minor issues with upgrade service for VHD Attach and QText but they had more to do with subtle differences between Windows and Linux hosting than with any real error.
Now let’s just hope that I don’t break everything. :)
After sorting out tunneling on my computer, there came time to setup my router too. Idea is not to configure each client with separate tunnel but to have one tunnel on router and all computers connecting to it should use it transparently. Hurricane Electric gives /64 prefix and that ought to be enough.
As a router I will use my trusty DD-WRT. Exact version used in this example is DD-WRT v24-sp2 (12/08/11) std-nokaid (SVN revision 17990M NEWD-2 Eko). Your mileage may vary depending on version of your choosing.
Obvious first step is to enable IPv6. It is easy enough to do. Under Administration -> Management find IPv6 support and enable IPv6 and Radvd. Radvd is configured as simple as it can be:
interface br0
{
AdvSendAdvert on;
prefix ^^2001:db8:9:10ee::/64^^
{
};
};Notice that prefix is same text “Routed /64” under your tunnel details.
Unfortunately this will not do. There is need for small script:
insmod ipv6
SERVER_IPV4_ADDRESS="^^216.66.22.2^^"
SERVER_IPV6_ADDRESS="^^2001:db8:8:10ee::1^^"
CLIENT_IPV4_ADDRESS=$(ip -4 addr show dev eth0 | awk '/inet / {print $2}' | cut -d/ -f1)
CLIENT_IPV6_ADDRESS="^^2001:db8:8:10ee::2^^"
ROUTED_IPV6_ADDRESS="^^2001:db8:9:10ee::1^^"
if [ -n $CLIENT_IPV4_ADDRESS ]
then
ip tunnel add he-ipv6 mode sit remote $SERVER_IPV4_ADDRESS local $CLIENT_IPV4_ADDRESS ttl 255
ip link set he-ipv6 up
ip addr add $CLIENT_IPV6_ADDRESS/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -6 addr add $ROUTED_IPV6_ADDRESS/64 dev br0
kill $(ps | awk '/radvd / { print $1}')
radvd -C /tmp/radvd.conf
wget "http://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&pass=^^9fc4d3d26b6ba921226c53e6c664c1ab0^^&apikey=^^tb4f139f1c342fgbd4.44123289860^^&tid=^^5511235463^^"
fiScript sets some variables, brings interface up, adds some routes and restarts radvd daemon in order to pickup latest settings. Last line is needed only for users with dynamic IP (full explanation can be got once you load page in browser). This script needs to be saved with Save Firewall (under Administration -> Commands).
Once router gets restarted you will notice that all clients get IPv6 address alongside IPv4 (they have to support IPv6, of course). Easiest way to check it to run ping -6 ipv6.google.com. Or load it or one of many IPv6 test pages.
Windows 7 works just beautifully with IPv6.
P.S. In case you are wondering where I pulled those IPv6 addresses from, here is what Hurricane Electric gave me:
IPv6 Tunnel Endpoints
Server IPv4 Address: __216.66.22.2__
Server IPv6 Address: __2001:db8:8:10ee::1/64__
Client IPv4 Address: __174.78.144.123__
Client IPv6 Address: __2001:db8:8:10ee::2/64__
Routed IPv6 Prefixes
Routed /64: __2001:db8:9:10ee::/64__