cahoot is now total rubbish

Have been using cahoot for a bank for a few years now.

To begin with, they were really good. But in recent times they have gone downhill, and are now complete rubbish.

The on-line banking regularly does not work and says "service is suspended. We are currently updating our systems. This takes approximately 5 minutes. Please wait until the cahoot service is resumed. Thanks for your patience."

Now cahoot is just a branch of Santander. Despite Santander being part of the Faster Payments Service, cahoot does not support Faster Payments, and there are apparently no plans to do so. So it seems if I want 20th century banking, cahoot should be my first choice. No thanks.

Another thing they have started doing is to "accidentally" block my on-line access. When I phone them up to report this, they act like they don't know what it is and say they will have to call me back. After about half a day, they phone back and say it was "mysteriously" blocked for no reason that they can determine. They then say that they can restore access, but first they have to "take me through security". They then tell me that they are restoring access. This seemingly takes about ten minutes, during which time they make various noises to indicate they are going through umpteen different things on their computer. They then tell me that it is done. What confuses me is why they didn't just do it before calling me back, and why I have to sit on the phone listening to them operate their computer for ten minutes. Bizarre.

cahoot now appear to have totally lost the plot and seem to be completely incompetent.

So I am now in the process of moving to another bank.

IPv4 address pool final allocations ceremony

Here is the video for the IPv4 address pool final allocations ceremony:

ICANN IPv4 Ceremony | Miami

http://www.youtube.com/watch?v=p9AzSl2MdFk

And whilst we're at it, let's have the IPv6 news conference:

ICANN IPv6 News Conference | Miami, Florida

http://www.youtube.com/watch?v=gveJs6YRYXU

gogo6 gogoCPE IPv6 tunnel router

Looks interesting. It appears to be an IPv6 tunnel router in a box.

http://gogoware.gogo6.com/4105/description.asp?product_id=180

It looks like it solves a number of problems. It looks like it could be used directly by end users to connect to Freenet6, or in connection with ISP-provided services to enable IPv6 over IPv4, or IPv4 over IPv6.

How to get IPv6 on Windows lappy

Update 2011-05-11: I have now ditched Freenet6 and am now using SixXS.

To get IPv6 going on the lappy, I had been using a Tunnelbroker.net tunnel from Hurricane Electric. One of the advantages for me was that the PoP is in London, which gives me a low latency connection.

But this was not without problems. Because it uses protocol 41 tunneling, it doesn't work through a conventionally NATted connection. To get around this, HE provides a public IPv4 address through a PPTP connection. The problem with this is that it then stuffs all of your IPv4 traffic through the PPTP connection, which is a bit smelly.

But recently discovered the gogoCLIENT from gogo6. This seems to be able to set up a tunnel over IPv4/UDP to Freenet 6. This then means that IPv4 traffic goes over its usual (direct) route, and IPv6 traffic is sent through the tunnel.

Now, my local Freenet 6 PoP is in Amsterdam. This is not the best, but at least it is on the same continent.

IPv6 (hopefully) explained for non-techies

Every connection with the Internet has to have a unique number (the IP address). This is because whenever any piece of data is sent across the Internet, it has to have the number of the connection where it is going to. There will be one number for your home broadband connection, one for my home broadband connection, one (or more) for any website you go to, etc.

These numbers are drawn from a pool of about 3.5 billion numbers.
The worldwide master pool is operated by IANA. IANA gives out blocks of numbers to five groups serving Africa; North America; South America; Asia Pacific; and Europe, the Middle East and Central Asia. These groups in turn hand out blocks of numbers to either national bodies or smaller bodies such as ISPs, and eventually numbers get assigned to individual connections.

What happened yesterday (3 Feb 2011) was that the master pool completely ran out of spare numbers.

IANA no longer has any spare numbers to hand out to the five groups it serves.

That doesn't mean there aren't any spare numbers, but rather that any spare numbers are now in the hands of the five regional groups and the smaller groups below them.

The number of spare numbers is declining. Fundamentally, there was no "step" reduction yesterday (3 Feb 2011) in the number of spare numbers available, so in theory it is not really news, but the fact that the global authority IANA no longer has any spare to dish out is considered by many to be a significant milestone or marker in the decline of the Internet addressing system.

Over time, the shortage of spare numbers will hamper the setting-up of new connections.

This issue has not gone unanticipated. By way of of a solution, in 1998, the boffins came up with a new way of operating the Internet called IPv6, which stands for the Internet Protocol version 6. (By way of background, the current way of operating the Internet is called IPv4.)

Amongst other benefits, IPv6 uses a much larger range of numbers to assign unique numbers to each connection. Whereas IPv4 has some 3.5 billion available numbers to assign to connections, IPv6 initially has sufficient space for about 2 billion billion connections (for geeks: I am assuming the first nybble is 2 or 3, and every connection is assigned a /64).

Unfortunately, we can't just switch on IPv6 and everything's peachy again. For IPv6 to work, the computers talking to each other must both talk IPv6, and the intervening bits of Internet must also be compatible with IPv6.

Fortunately IPv6 and IPv4 can happily coexist on computers, and on the Internet in between them. Fortunately again, most of the stuff you usually use like web browsing and e-mail has already been upgraded to be compatible with IPv6 and will automatically use IPv4 or IPv6 depending on what's available. So for the ordinary person, there should not be much in the way of a noticeable difference.

So many people expect that the way forward will be for the existing IPv4 operations to move to combined IPv4 and IPv6 operations. Eventually we should get to a tipping point where more-or-less everything works fine with IPv6 and we can start dropping the old IPv4 system.

The problem is that there is some resistance amongst ISP to adopting IPv6 alongside IPv4. It seems that most ISPs seem to be waiting until there is a "brick wall" problem in front of their nose, at which point they will start running round like headless chickens trying to fix things.

Now, IPv6 is by no means a new technology. It has been live in many places for many years. The problem is that it will take time for people new to the subject to get their knowledge up to speed, systems to be upgraded, problems to shake out etc. and this will take months to years. If ISPs wait until the last minute, then it isn't going to work.

So there are various people trying to make noise, raise awareness etc.

We shall see.

Antix Games Store

Go and have a look at the Antix Games Store.

By the way, the proper URL for the Antix Games Store is http://www.antixgames.com/, and not that thing ending in "/en/". Yes, when you go there, you end up on the URL ending in "/en/", but that is the language-specific top-level page. The proper and correct URL to share and link is http://www.antixgames.com/.

Netgear DGN2200: Don't buy

Netgear DGN2200 review: Don't buy. Zero stars out of Five.

Do you do Perl? If so, you might like to try perldoc.co.uk. It's like perldoc.perl.org, only it's not perldoc.perl.org, so when perldoc.perl.org goes down, perldoc.co.uk stays up. Plus it's UK based, so for people in the UK and the rest of Europe, it should be quicker.

I bought a Netgear DGN2200 (from Amazon) to replace the DG834Gv4 which appeared to have failed (all lights coming on).

As I'm talking about two devices here with gobbledegook codenames, I'll highlight them differently in different colours. So the new (bad) one is the DGN2200, and the old (good) one is the DG834Gv4.

(As it turned out later, the DG834Gv4 hadn't failed; only the power supply had expired. By pinching the power supply from my previous-previous router (DG834Gv2), which was also 12V 1A with the same pinout, I was able to get the DG834Gv4 going again.)

Back to the DGN2200, it is a case of: Nice hardware, shame about the firmware. The DGN2200, as offered in its current form, is a load of rubbish. In a couple of years, assuming the firmware gets fixed, it could be a good little router. But today, don't touch it with a bargepole

The DGN2200 seems to incorporate a perfectly decent DSL modem. On my somewhat lengthy telephone line, I get a DSL synch rate which is in the same ball park as the best I have seen.

Also the DGN2200 seems to incorporate perfectly decent wireless hardware. As far as I could tell, all my kit seemed to connect up to it easily and maintained a reliable connection.

The problem, and it's a biggy, is the network software:

If I try to access an HTTPS website on a non-standard TCP port number, then I find that it takes 5 or 6 attempts to connect. Now, this might look like simple packet loss, or perhaps the MTU is too large. Well, sorry, no, for several reasons:

1. If I do swap test with the old DG834Gv4 router, the DGN2200 fails on this point whereas the DG834Gv4 doesn't. The DG834Gv4 connects first time, every time.

2. I can run a simultaneous ping which shows 0 out of 100 packet loss. Also I can run a simultaneous SSH session which is consistently snappy and responsive. So why do ping and other services work reliably but HTTPS (on a non-standard port number) doesn't?

3. I can take the MTU down to 1400 or 1350 and there is no difference. In any case, why does the DG834Gv4 work fine when the DGN2200 fails miserably?

I tried monitoring the HTTPS packets on the server side using tcpdump. When the problem is manifesting, the server does not see any initial packet arriving. So the server has no cause to respond. The packet is simply not arriving, and everything points to the packet being lost by the DGN2200.

More problems: If I try to set up an OpenVPN connection to a server listening on UDP port 1195, it takes 5 or 6 attempts before it connects. Packet loss or MTU? Nope, for the same reasons as the first problem. Again, the DG834Gv4 connects first time, every time.

I tried raising support requests through Netgear, but we were moving at a snail's pace, and besides I now have the old router working again.

So I have raised an RMA through Amazon and the DGN2200 is going back. Update 2010-11-04: Amazon have now issued a full refund for the unit.

In addition, I have advised Netgear that I would be more than happy to consider assisting them on a consultative basis.

If you found this posting useful, please consider donating 0.25 U.S. dollar or 0.25 Euro.