Older blog entries for dwmw2 (starting at number 198)

My DSL line has been unusably slow and unreliable since around mid-November, and BT's responses in the fault ticket are, as usual, varying between the stonkingly incompetent, the dishonest, and the outright fraudulent.

They claim to have sent an 'external engineer' on January 3rd, who claims to have tested the line and reported it OK... despite the fact that we were in France skiing on the 3rd, and the line was connected at a speed below the Fault Threshold Rate all of that day, until the evening.

They seem to be referring to this alleged visit as "Chargeable" despite the fact that we clearly did not ask for their "Special Faults Investigation" service, so it would be a violation of the Unsolicited Goods and Services Act 1971. And despite the fact that the charge is for "repair activity beyond the NTE", and they would have to have broken into my house to do any of that in my absence.

They keep clearing the ticket with idiotic claims such as "EU Equipment/settings/drivers believed incorrect" despite the fact that they've been here (on a previous occasion when I was actually present) and checked it all.

They seem to have learned another trick recently, to fraudulently avoid the 'Service Level Guarantee' clock counting up and having to pay compensation for the extended failure. They've taken to reassigning the ticket back to us, telling us to wait for the BRAS profile to change. But the BRAS profile is just a reflection of the state of the line, limiting IP traffic so that we don't saturate the ATM link. So effectively they were saying "we won't bother with this until the problem magically fixes itself... and we're not letting the fault timer count up while we wait, either".

They also tried arbitrary delays — clearing the ticket with "GPMS notes state that the line is not stable so case needs to be slept for 8 hours. So setting a sleeper for remaining time.". As if another 8 hours is going to make a difference when the line has been buggered since mid-November.

They closed the previous ticket outright, even though the line was still dropping, so this particular ticket has only been open since December 30th — but BT's blatant fraud means that they've only just admitted to exceeding the 40-hour Service Level Guarantee, almost two weeks later.

As usual, it's quite scary reading the fault ticket. The responses from the BT side seem completely nonsensical at times, as if they haven't even bothered looking at the fault history. They've even cleared the ticket reporting that the line is in sync, while it's clearly connected at a rate below the fault threshold. They repeat themselves and almost never seem to respond directly and coherently to anything — neither the direct questions and statements in the ticket, nor the facts of the case. It's difficult to understand how anyone could be so massively incompetent.

I sincerely believe that British Telecom is too incompetent and dishonest to be permitted to hold the monopoly position it does. A huge number of people have no choice but to deal with them, and the watchdog is notoriously toothless.

I fantasise that the government will realise this and issue a compulsory purchase order to re-nationalise the infrastructure which connects British homes, then allow the existing British Telecom to go bankrupt. They seem to be completely beyond help.

I don't know what would happen to the infrastructure after this — I normally wake up at this point. But whether it remains nationalised or whether it's sold to someone else, it couldn't possibly be as bad as British Telecom.

Argh. How is it that people can be so fucking stupid?

Are Yahoo actually employing people to do their customer service, or just dragging in crack-smoking monkeys off the street to do it for a laugh?
This reminds me of the exchange with Vodafone, where they never bothered to read anything I wrote, but just kept asking the same identity questions over and over again... even when I answered them.


Message-Id: <200901112335.n0BNZjsU033833@mail-relay1.yahoo.com>
Date: Sun, 11 Jan 2009 23:35:53 +0000
To: David Woodhouse <dwmw2@infradead.org>
Subject: Re: UK - United Kingdom (KMM81869195V16943L0KM)
From: Yahoo! UK & Ireland Login Support <uk-account@cc.yahoo-inc.com>
X-Bad-Reply: 'Re:' in Subject but no References or In-Reply-To headers

Hello David,

Thanks for writing to Yahoo! UKIE Customer Care.

Currently, we are unclear on exactly what it is you want done to your
account. Please reply to this message with a more detailed explanation
of what you need done.

Also, in your reply, please include the:

- Yahoo! ID
- alternate email address
- date of birth
- postal code
- secret question and answer

that you supplied when you created your account. We will then be able to
verify your account.

Regards,

Customer Care - Yahoo! UK & Ireland

CONFIDENTIALITY NOTICE: This email and any attachment is confidential
and may be legally privileged. It is intended for the named recipient
only.




Original Message Follows:
-------------------------

On Sat, 2009-01-10 at 23:48 +0000, Yahoo! UK & Ireland Login Support wrote:
> Currently, we are unclear on exactly what it is you want done to your
> account.

This was fully stated in my mail of January 8th.

I'm sorry; I don't mean to be rude, but I don't think I could explain it
in words of fewer syllables. You'll have to find a competent adult to
read it to you.

I am attaching that email for your convenience, in case you can't find
it. Please forward it to someone who is capable of dealing with it... as
I requested on the 8th.

--
dwmw2

[ Attachment 1.2 Type: message/rfc822][ Forwarded message displayed below ]

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 08 Jan 2009 15:36:07 +0000

On Thu, 2009-01-08 at 13:44 +0000, Yahoo! UK & Ireland Login Support wrote:
> Hello David,
>
> Thanks for writing to Yahoo! UKIE Customer Care.
>
> We have received the account information you have provided and
> understand that you are unable to login to your Yahoo! account.

I have found the reason why your reminder message wasn't getting though.
Please forward this to whoever is responsible:

Your reminder messages are being sent out without a Message-Id: header.
This header is supposed to contain a unique identifier for each message,
and the email RFC (RFC5322) says that every message SHOULD have such a
header.

Since most messages lacking such a header, in violation of the standard,
are spam or virus traffic, many mail servers reject them. Including
mine.

I have implemented a temporary workaround, and I was able to receive the
reminder -- so I do have my username and password now; thanks. But you
should fix the problem anyway, of course.

--
dwmw2

[ End of Forwarded Message 1 ]

Wheee! Opened my first Christmas present a couple of days ago. A PCI ADSL2+ card, fully supported by Linux.

Many thanks to the folks at Traverse Technologies and Xrio for the effort they've put into developing this hardware — and for sending me a board.

At last I'll be able to have a properly supported Linux box, with legal drivers, as the endpoint for my ADSL lines.

There are a few things to improve; adding DMA support is a priority right now. But we do have the capability to update the FPGA from software now, so they're starting to ship real hardware to customers.

Following my post on Friday, we're now at almost 19,000 bogus 'clears' from the BT side, as they dishonestly keep clearing the fault in order to avoid being held accountable to their own Service Level Guarantee. All of the clears have been rejected by the ISP, of course — but BT have arranged for their systems to fall over when the ISP responds too quickly, while they can re-clear the fault from their side within a second or so of it being passed back to them.

So it looks like BT are winning the game with the 'chess clock' — although the line has been fairly much unusable for a week now, and the fault was reported 6 days ago, the clock has yet to reach a single day, let alone the SLG of 40 hours. Purely because they keep kicking the fault back to the ISP's side while we're waiting for BT to take action.

There's no way we can attribute this to their normal incompetence — this is blatant fraud on the part of British Telecom.

28 Nov 2008 (updated 28 Nov 2008 at 21:12 UTC) »
"Any sufficiently advanced incompetence is indistinguishable from malice"
Grey's Law

The above rule (inspired, no doubt, by Clark's Law and Hanlon's Razor) is often applicable to the actions of British Telecom.

Regular readers of my drivelings may be surprised to find that I actually think I've been kind to BT in reporting their actions as incompetence, rather than anything more sinister.

Sometimes, however, it's virtually impossible to give them the benefit of the doubt. One example of this is their repeated insistence on a 'Special Faults Investigation' (SFI) engineer visit, when we're asking them to fix faults. SFI is an optional service which we don't usually want, and they repeatedly try to charge for it after explicitly being told that it was not required — a criminal offence under the Unsolicited Goods and Services Act 1971. In fact, although it's supposed to be a charge for services beyond the limit of their responsibility, in the customer's own equipment or wiring, they've also been known to apply charges after themselves clearly stating that no such work has occurred.

(Update: The ISP reports that today they've had someone in BT refusing point blank to fix a fault unless an SFI is booked. This is a clear-cut fault where the end user has tried two separate modems, RJ11 cables and filters and the problem persists — it's definitely a BT fault.)

I have a similar problem with my line, although thankfully BT haven't refused to send an engineer to investigate. Since about 2:30AM on Monday morning, my DSL line has turned to crap — it seems to be caused by RF interference from something outside my house. I did similar tests to the above, with different cables, different filters and different modems. The usage graphs look like this, with ugly purple stalactites eating my connectivity:

Even when it's connected, it's getting lots of errors and running at half the speed it should be; below the 'Fault Threshold Rate'.

When the engineer arrived, I'd disconnected everything else on the line and connected the DSL modem directly to the master socket, at the ISP's request. With no filter, since there was no analogue equipment present.

The engineer held up the little adaptor which lets you plug an RJ11 into the BT socket, and told me that it was "not a filter"... strangely. He then went away and reported in the fault ticket that "customer also had filter incorectly [sic] installed which I believe to be a genuine mistake as he had already had a nte2000 master plate installed". A doubly confusing statement, since I didn't have a filter installed — the filters I use are the NTE2000 faceplate type, and were quite clearly sitting on the floor near the socket. I'd also told him why I'd removed it. So his report in the ticket really does look like it's an excuse to charge for the SFI, pretending that there was some work done on my side of the line.

It gets better than that, though — they also have a Service Level Guarantee which says that faults should be fixed within 40 hours, and they're required to pay compensation if they fail to meet it. There's a kind of 'chess clock' which counts the time during which the ticket is with BT for action, and BT keep 'clearing' tickets with totally bogus responses, as shown in the Cisco-IPv6 tickets I posted here and here.

They do this so much that the ISP found it necessary to implement an autoresponder, rejecting the bogus 'clear' and flipping the clock back to BT so that the SLG clock kept counting. Obviously, they apply this with care, only when they're sure that BT aren't clearing the ticket for genuine reasons, but only their fraudulent attempts to avoid the SLG.

Today, we found that BT have implemented their own autoresponder, flipping the ticket back to the ISP even while we're waiting for BT to take action. Again, it's really hard to put this down to BT's normal institutional incompetence — it cannot really be interpreted as anything but a deliberate attempt to defraud their customers by circumventing the Service Level Guarantee.

I've posted a copy of the fault ticket, although I truncated it at about the 50th clear/reject cycle. We're up to about 1000 cycles now, and counting... :)

Fucking Useless, Criminal, Telco.

After BT failed to turn up for the appointment last week, they said they were going to give us a status update by yesterday.

Naturally, they failed to do so.

Fucking Useless Telco.

Waited at home all morning today, for a British Telecom engineer to come and fit a new line. They failed to show up, and failed to contact me to let me know. Excellent customer service from British Telecom, as usual.

The ISP apparently received an email this afternoon — after the BT engineer had already missed the appointment — telling them that the job is delayed and has now been referred to the planning department.

They had to dig the roads up between here and the exchange to install my ISDN line when I first moved in, not so many years ago. Now we suspect they didn't bother to lay enough new copper that time, so they're going to have to do it again.

I suppose it's unrealistic to hope that they'll actually install fibre this time?

Fucking Useless Telco.

4 Nov 2008 (updated 4 Nov 2008 at 12:50 UTC) »

What do we do in a time of economic downturn when we've just issued a profit warning and seen our stock price drop by 20%?

Well, if we're a monopoly and the watchdog which is supposed to regulate us is notoriously toothless, then we can just put our prices up exorbitantly, right?

I saw this on Andrews and Arnold's status feed today...

BT announce massive price increases

"BT have just announced price changes that look set to increase our costs by well over £100K p.a. In the past we have always been quick to pass on changes in our costs as changes in prices to our customers.

"These price increases relate specifically to the "old" central links and 20th Century end user connections, which BT are making us keep until something like next August because they don't have their new IPStream Connect product ready in a way we can use yet. They seem to have created a huge delay and then put prices up to profit from that delay.

"We are very reluctant to put prices up at this stage, obviously, at a time when we are trying to reduce prices. We need to fully assess the timings and how they impact us in real terms over the next 12 month to decide if any changes are necessary. At this stage we are not announcing any change in price."

The massive price increases (23% or so) are on the BT "Central" pipes which provide the connection between the BT network and the ISP, for subscribers still on the old "20CN" network — which is most of us, because BT are so far behind with the 21CN rollout.

The price hike is exacerbated — almost doubled for some ISPs — by details in the small print, where they drop an existing per-line "rebate" on connections in high density areas.

The thing is, the ISPs don't even want the Centrals any more. With the long-anticipated "21st Century Network", the ISP just gets L2TP over GigE.

BT's long-promised IPstream Connect will eventually mean that lines connected to exchanges which haven't yet been upgraded to 21CN will also be connected to the ISP via the same type of GigE links, and the BT Centrals can be retired. But although the BT link given there says "Installed Base Migration completed - 31st December 2008", the current estimate is that it won't be available until at least August 2009.

So BT are pumping up the price on the service which they were supposed to have phased out by the end of the year, but haven't. And ISPs have no real choice but to pay up.

It's even better than that, in fact — because of the long delays on IPstream Connect, BT started offering new Centrals at a reduced installation cost, about a month ago. Any ISP who took them up on that offer is probably regretting it now.

Thanks, BT. And thanks in advance to Ofcom, for doing bugger all about it.

Maybe we should buy some of these and donate them to BT?

As strange as it seems to advertise a cable that "supports IPv6", it's very closely related to BT's problem.

When British Telecom states, as they did, that "BT currently supports IPv4 on it's[sic] Broadband products and does not support IPv6", that makes no more sense than saying "this cable does not support IPv6".

BT are paid to transport PPP data between the ISP and the end users. The contents of the PPP frames should be irrelevant — whether they be IPv4, IPv6 or anything else. Whether they're web traffic, email, IRC or anything else. Whether they're Russian, Polish, French, English or any other language... British Telecom are completely incompetent if they claim that some of these things are "supported" but others aren't. They are supposed to be providing a simple data transport — just like the cable — and they have no business caring about what gets carried over the transport.

The low-level transport really shouldn't care what's being carried across it, unless someone really went out of their way to fuck up. In fact it looks like Cisco did just that, on this occasion, and the muppets at British Telecom are too stupid to comprehend what's going on.

This is apparently a known Cisco problem, and I hear second-hand reports that it was actually expected to be fixed in the IOS version(s) that BT are using. If that's the case, Cisco get bonus fuckwit points — not only did they have such an inexcusable bug in the first place, but they also failed to fix it properly.

BT now say that they are "looking into this problem and will be holding a conference call with [their] suppliers". I wish them the best of luck with that. This particular supplier doesn't seem particularly competent either, judging by my recent experience of trying to report shameful security holes in some of their other products.

In the meantime, those subscribers lucky enough to be connected to Juniper's products instead of Cisco's should find that the service works just fine. BT use a mixture of both.

1 Nov 2008 (updated 1 Nov 2008 at 10:24 UTC) »

We just need 4 more days like yesterday...

189 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!