Talktalk support - laughable.

I've just wasted nearly an hour of my life trying to get Talktalk to fix their servers.

Like a growing number of providers, they ignore the rules about DNS. Try to access a page which doesn't exist in a browser and you get a redirect to an error page instead of a NXDOMAIN.

There is some quite clever stuff going on here, BUT MAKING THAT REDIRECT CACHEABLE IS NOT ONE OF THEM. 

Particularly when your DNS forwarders are on the blink!

They don't even have the sense to return a 404 code!
Could they do any worse? Actually, yes, they could! The frame handling is just silly.

colin@animal ~ $ curl -i 'http://kshgauyuegvuaFRA.com/none.html'
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 20 Feb 2020 19:46:59 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: close
Expires: Thu, 20 Feb 2020 19:56:59 GMT
Cache-Control: max-age=600
X-Frame-Options: DENY

SWMBO thought we should report this to their support. Unfortunately the online chat people had all gone home early.



Which mean dealing with IVR-of-pain before eventually speaking to some poor helpdesk person in India who had trouble spelling DNS. They assured me that there was "nothing wrong with my line" despite me trying to tell them I knew that - the problem was with their DNS server and their web server.

They hung up on me.

Democratization of truth

America elected Trump. The UK elected a prime minister who had already been tried by the courts and found guilty of an abuse of power. Both election campaigns seem to have involved a great deal of "fake news" (attributed, amongst others, to foreign states).

This week (among other excitement) I've been working on an infrastructure plan for a target architecture which will also allow progressive migration of legacy systems. Actually, this is taking a bit longer than a week, but the question of shared file access has bubbled up to the top of my list. I'd like to think I've learned a few things over the years, but I always like to check my facts - and to check if there are new facts to be discovered. So I hit the search engines, starting off with a comparison of NFS and SMB.

The first page of results searching for "NFS vs SMB in the datacentre" in both Google and DuckDuckgo was pitiful. Biased and misinformed blog postings and marketing SEO spam. I spent a very long time trudging through misinformation and idiot guides before realizing that the internet, formerly the definitive source for technology guides and (informed) opinions was a mere shadow of its former self. While most institutions dwindle due to under-subscription, it is the exact opposite which has harmed the internet's utility to me. I don't think the Kremlin is behind this, indeed I think the poor quality information is mostly published with good intentions, but I wish Google and Duckduckgo provided the a facility where I could easily feedback on the quality of articles they index.

It seemed like a more productive use of my time might be to record what I already know about the protocols rather than try to find out something new.

So, for the record....SMB was not invented by Microsoft. They did develop the technology. CIFS is also based on the same technology but forked the protocol to implement support for POSIX hard/symbolic links and large files. This was then added to the SMB 2.0 specification.

Both exist in multiple iterations. Both are intended for file sharing, but SMB also supports a lot of other network oriented operations.

The key differences between (most) NFS and SMB installations are that the former uses UDP while the latter uses TCP with in-band authentication and session handling. This has a lot of impact on data transfer speeds - a LAN, the internet and a datacentre are each very different network environments - so benchmarks from one will be misleading in another.

NFS doesn't (normally) use passwords on encryption - it is based on trust between the existing devices. Enforcing authentication for every operation makes implementing some security models easier.

But a flip side of this, is that once an SMB connection is lost (i.e. if the client, the server, or the network in between fail at any point) it is upt to the client to renegotiate the connection. Although that technology exists within smbmount (used on Linux and other POSIX systems) it is not the most reliable.

OTOH the intrinsic authentication but absence of network-based user identifiers means that it is a lot simpler to align client users with the permissions on the files in the remote filesystem of SMB than NFS. Until NFSv4 it was not enough to have the same user configured on multiple machines - to get the same access they needed to have same (numerical) user id.

I'm not going to tell you that one is better than the other, because, despite trying to fulfill the same goal of providing shared access to remote files, they are different.

Installing the new Fortinet VPN client on MS-Windows

After the last round of MS-Windows updates, running Fortinet's VPN client on my work laptop (MS-Windows) resulted a BSOD. So I downloaded the new client from Fortinet - round about 1Mb and it didn't take too long. But then I discovered that the thing I had downloaded was not the client, but a downloader to download the client.

This took rather a long time to do its job (on a 200Mb internet link). Meanwhile I:

• Found a spare Linux host,
• ran an OS update/upgrade
• installed openfortivpn
• configured this for first time round
• discovered the remote end does not use a trusted certificate
• reconfigured vpn
• discovered the remote end is publishing routes which trash the local routing configured
• rebooted the server ( I was connecting over ssh)
• made myself a coffee
• RTFM
• Went for lunch
• Came back and discovered the download had finished
• Installed the new version of the MS-Windows client
• Discovered that 
•   1) it had overwritten the old client
•   2) that it would not connect - turns out to be a *different* VPN client from what I had before
• Started downloading something else from Fortinet (as advised by colleague)
• Worked out how to manually set up the routes on Linux and got a working connection
• Finished the task for which I wanted a VPN connection
• Startup the new client and found it was the same as the one I had installed earlier

Why smartwatches are dumb

TLDR; Apple and Google showed that providing an open ecosystem for running code on phones could lead to market dominance. So why isn't it hppenning for wearables?

I was thinking to myself the other day that a combination of Google authenticator and a smartwatch was a match made in heaven. I'd been toying with the idea of jumping on the smartwatch bandwagon to get my geek on – but fitness trackers don't really light my fire. And, like email, I read my texts when I've got time to, not when they arrive. So I wasn't left with a lot of reasons for spending money on a watch with an irritatingly short battery life. 

Then I thought of 2FA. 

I use it for work with a ridiculously expensive RSA token. I recently had to get a new one after losing one somewhere. A TOTP generator on my phone is not a great idea – my work pays for a blackberry where they enforce a silly password policy. Do I really want to type a 12 character password into my phone in order to start an app to get a token so I can then log into something else? But dongles are just something else to carry. And I need something which is convenient to carry around....BING....light bulb moment.

A quick look round the internet revealed Gear 4 Android (not really clear if the watch itself runs android or if it just talks to an android phone) and Apple iWatches. But at a price starting around £150, it's rather a lot for pet project. Pebble watches have a really good SDK, but the original company went bankrupt and I don't know if the new owners of the technology really want to continue in the same market. And they're not much cheaper.

The first computer I ever bought cost me around £70 in 1981 and came with 1k RAM, no permanent storage built in, and hooked up to a TV to use as a display. But today I can buy an ARM based device with a lithium battery and a full colour screen for under a tenner. Sadly, the ZX81 was easier to program!  

People are actively hacking these U8 devices but we still seem to be a long way from being able to use them as general purpose computers.

There's no end of fitness bands available for under £20. They promise much longer battery life than the fullblown smartwatch and more than enough processing/memory/display capabilities to also support TOTP, but it seems that none of them are programmable. Even the ones which claim to come with anSDK (actually its an SDK to write code for Android/iOS to poll the ANT+/Google fit APIs) don't actually provide a development chain.

Yes, I know there's lots of people building cunning, but ugly devices out of arduino's and 3D printing cases. But that's a bit hardcore for me (and would end up costing me a lot more than a Pebble/Android watch). I could buy a ready-made one but its still so UGLY.

Googling for smartwatches, I eventually came across “metawatch” which claims to be an open-source smart watch – but currently unavailable on Amazon.

Hexiwear? UGLY

The inpulse and WIMM aren't ugly – but they are expensive.

Microsoft's smartwatch came and went so quickly nobody even saw it.

Why can't I get a watch for under £100 where I can run my own code?

Stop Press: I did just find this but do I really want to strap a full blown android phone to my wrist? And there are a growing number of MTK6737 Android watches appearing. But what about the battery life?