I’m visiting the in-laws in Texas this weekend, and I use the SSTP VPN in Windows Server 2008 R2 to connect home (my client is Windows 7, but it works just as well with Vista). Never had many problems with it up until this weekend.
Apparently, on Friday, we had a power cut back at the house, and our network connectivity is still not happening. I’ve asked the house-sitter to restart the servers and routers where possible, but it’s still not there.
So I went online to Comcast, to track down whether they were aware of any local outage. Sadly not, so we’ll just have to wait until I get home to troubleshoot this issue.
What I did see at Comcast, though, got me really excited:
So I can’t but be excited that my local ISP, Comcast, is looking to test IPv6 support. I only hope that it’ll work well with the router we have (and the router we plan to buy, to get into the Wireless-N range). Last time I was testing IPv6 connectivity, it turned out that our router was not forwarding the GRE tunneling protocol that was used by the 6-in-4 protocol used by Hurricane Electric’s Tunnel Broker.
Who knows what other connectivity issues we’re likely to see with whatever protocol(s) Comcast is going to expect our routers and servers to support? I can’t wait to find out
I tried to find a less … alarmist tone to take in the title, but when I think of the consequences of this particular bug, I can’t see that I’m going over the top.
Quite simply, occasionally Windows 7 Explorer will corrupt files when you copy and/or move them using drag/drop. [So far, I’ve only seen this twice, and each time, I was moving MP3 files]
Last night, I dragged a group of files – over a thousand, totaling about 45GB of data, to move them to a network server.
This morning, one of the files was still on the original source. And on the destination.
That alone would be an unsettling bug, but not too much to worry about.
Out of sheer curiosity, I compared the two files (using “FC /B C:File1 Y:File1”).
Sure enough, although the beginning of the file was the same, starting at byte 0x480000 (there may be one too few, or one too many, zeroes there), the target file consisted of nothing other than nulls (zero byte, ‘’ if you’re a C developer).
This doesn’t only happen on files sent to the network, however.
Searching for files with large numbers of nulls at their end, I was shocked to find that over thirty of the files on my hard drive consisted of nothing but null characters. All these files were dated July 27 2009, so clearly that was a bad day for my computer.
That’s unsettling, because these particular files I had assumed to be safely moved. I had first copy-dragged them to my Podcasts folder, and then move-dragged them to a different folder, both of which actions were on my hard drive only. Having listened to these files out of my Zune (using the Podcasts trick I referred to earlier), I wiped them from the Podcasts folder, and now won’t be able to listen again, because the ‘backup’ copy is corrupted.
Mind you, they do compress well when there’s nothing in the file but nulls.
And, just in case anyone’s thinking my system itself is corrupt, or has a bad disk driver or something like that, I should note that I have completely wiped and reinstalled the system from scratch in the last few months, so the first (major) destruction of data was on a Windows 7 installation that was upgraded from Vista, and which had a number of the laptop manufacturer’s drivers on it; the second (less huge) destruction was on a fresh Windows 7 installation with almost no manufacturer’s drivers loaded.
I have yet to find any details of others experiencing this same problem. If you want to scan your own files (MP3 or otherwise) for vast quantities of null bytes at the end, I’ve uploaded the program here – it’s written in C#, and I’ve provided the source code as FindNulls.cs, and the executable as FindNulls.exe in the zip file. I won’t claim it’s a sample, or that it’s particularly good, but it will find files that end with several nulls in sequence.
I’m not at RSA, but I’ve been reading some of the coverage of it.
A couple of Mr Coviello’s comments about cloud security, as reported in Maggie Shiels’ blog at the BBC, make me a tad upset.
"Something is holding back the full realisation of this vision, and that in a word, is security"
And that was when Mr Coviello threw down the gauntlet to the audience telling them that they had to step up and "embrace the challenge and seize the opportunity" and ensure safety is designed and built in.
It’s a bit like saying that those damn safety folks are holding back full utilisation of the roads, and that we safety officials should work to provide roads that can be traveled at high speed safely.
Sure, you can make safe(ish) roads, but there’s also requirements for the cars to be safe(ish), as well as the drivers.
OK, that’s my disagreement with his initial sound-bite – but for the overall tone, I have to agree that it’s vital that Security is seen as a business enabler, rather than a choke-point where business process and information goes to die.
I see cloud computing as a great way for businesses to do what they have always done – to rely on someone who’s really good at a job, to do that job for them.
Most businesses don’t generate their own electricity, or build the roads that lead to them. They get other companies to do that for them. Similarly, if you’re not in the business of developing and providing data centre service, why should you be engaged in doing so?
It’s my hope that cloud computing leads developers to realise that if they can no longer trust or, at least own, the machines on which their software runs, they have to design their applications and data flow to match. I hope that this leads to developers writing more secure and robust applications, and encrypting or removing sensitive data wherever possible.
Sadly, I suspect that many developers and designers will instead say to themselves “the business has bought off / accepted this risk of running in the cloud, so I will just carry on doing the same unsecure application development that has ‘worked’ for me in the past.”
I’d greatly appreciate it if you’d be the first kind of developer. Thank you.
Thirty days hath September,
And all the rest, I can’t remember.
[Ancient English rhyme learnt by school-children everywhere.]
Our talented model Jesper is demonstrating how bad assumptions about calendar data can occasionally come back to bite you.
Important Note: Despite the logo on his sweater, there is no evidence to suggest that this is anything other than a cheap calendar bought at one of those carts in the mall.
So, on days one to three of this post, I will not be approving any comments that explain why this calendar page is fail. You are, however, encouraged to try and demonstrate how sad you are by trying to be the first to post an explanation – winners (and losers) will be revealed when I approve all (non-spammish) comments on Thursday. Bonus points to anyone who can explain rationally why the error might have occurred.