The Wayback Machine - https://web.archive.org/web/20170630014422/http://www.advogato.org/person/dwmw2/diary.html?start=184

Older blog entries for dwmw2 (starting at number 184)

British Telecom are going from strength to strength, continuing their stunning display of incompetence.

The fault has been reported against a handful of lines belonging to affected subscribers — and although it's a fault in the core network, in some of their Cisco routers, it looks like they decided to try to fix it by shifting one of the affected lines to a different copper pair.

Quite why they think this would help, I don't know — but thinking doesn't seem to be their strong suit. In making this unnecessary change, they seem to have terminated service to the affected subscriber entirely.

This would be funny if it wasn't so sad — and scary; how is it that people like this are allowed out into the community rather than being kept in secure institutions where they can't pose a danger to themselves or others?

Fucking Useless Telco.

It's just scary watching the responses from British Telecom, in the tickets which have been opened for the core network fault with their Cisco kit. I've posted a copy of the tickets on my line here and here. (There are two tickets because they actually closed the first, in what seems to be a fraudulent attempt to hide the fact that they are failing to meet their Service Level Guarantee.)

These people are so lacking in intelligence that I really don't know how they manage to feed and dress themselves. They just keep trying to clear the fault, with totally bogus responses — often trying to trick us into accepting a chargeable engineer visit, sometimes just claiming that such a visit has happened when it has not, sometimes claiming to have run diagnostics and found that the line was OK, sometimes claiming that there must be a misconfiguration at my end, etc.

It's clear that they aren't even reading the information in the fault report, and are just clearing it without even thinking — and they've done it so many times that the ISP has had to implement a bot to automatically reject the 'clear' each time.

It's mindboggling that a company can be so incompetent in the way it treats its customers.

I swear, the world would be a better place if the likes of Cisco and British Telecom were eradicated from it in a freak incident of self-annihilation brought about by their own incompetence.

Update... British Telecom have cleared the fault, saying "[End User] Equipment/settings/drivers believed incorrect".

Is there no limit to how incompetent these people can be?

Fucking Useless Telco.

British Telecom's capacity for incompetence continues to amaze me. We're reproduced the fault in their L2TP service using purely Legacy IP — although we first saw it with IPv6, it does affect IPv4 too.

It's a known Cisco bug — CSCsd13298, for which a patch exists. And yet they still seem incapable of dealing with it.

They've tried sending engineers to my house, as if they think that could help. I turned him away with an explanation of what the problem really was, and then they put false information into the ticket: "SFI Line tested ok following attendance by BT external engineer". The engineer didn't get anywhere near it; he was turned away at the door.

They've tried charging for a "Special Faults Investigation" engineer visit, despite clearly being instructed that such a visit was not requested. This is an offence under the Unsolicited Goods and Services Act, 1971.

This update from their side is particularly impressive:

No BTW fault - an engineer attended on 15/10/2008 23:40:00 and reported reterminated e side to b/pair 17070 all ok fast test done = line test ok. Notes and test results indicate no fault exists.
If there was an engineer in our house at twenty to midnight on Wednesday, he was very quiet. And he managed to complete his work without disturbing the DSL line, which has remained synchronised from Wednesday morning until now without interruption.

They've even tried just closing the ticket without fixing it, in what seems to be just a fraudulent attempt to evade the SLA.

It's astonishing to watch the exchanges back and forth between BT and the ISP on the fault ticket, with complete lies being put forth from BT in clearing the ticket, and then being rejected by the ISP.

Why on earth can they not just fix their poxy Cisco kit? (Or preferably retire it in favour of machines from someone less incompetent, like Juniper; but that's more of a long-term plan).

Fucking Useless, Criminal, Telco.

No matter how much I think I have come to accept the fact that British Telecom are massively incompetent, they always seem to be able to come up with a new way to fuck up which can still surprise me. It's a talent, it really is.

BT own most of the copper to our homes in the UK, and provide DSL services to an ISP of our choice. BT is paid to pass PPP frames between the DSL subscriber and the ISP, over L2TP or some similar mechanism.

The content of the PPP frames is something that BT shouldn't be involved with. But due to a bug in some of their Cisco kit (and don't get me started on Cisco this week, either), certain packets are getting 'eaten' in transit.

BT, in their 'wisdom', have declared that they are not intending to fix the bug. For technical reasons, IPv4 packets happen to get away without tickling this bug in the transport, while (some) IPv6 packets do fall foul of it. So although this is clearly a bug in the service which BT are contracted to provide, their response is:

"BT currently supports IPv4 on it's[sic] Broadband products and does not support IPv6".

They seem to have missed the point that this is a generic problem in their transport. And it's a problem for which a patch exists, too!

Fucking Useless Telco.

A&A's response, as ever, is wonderful:

"Of course we are wondering what else BT do not "support" now.
We exchange data with them at a low level (L2TP and PPP). When a higher level (IPv6) broken their answer is that they never said they support IPv6
But they do not state they "support" email either, or web pages, or MSN...
BT have never said they "support" web sites with a lime green background colour...
We have asked BT what they do "support" over PPP, including the above list..."
(The Register, /.)

I pay my telephone bill to British Telecom by Direct Debit — it's taken from my bank account directly, under their control (albeit with fairly decent safeguards).

Strange, therefore, that I got a call yesterday from their missing payments department chasing up my last bill, which they hadn't bothered to take for some reason. They left a message with a number to call them back on, and a reference number. Yet when I called, the person there seemed unable to do anything useful like checking why they hadn't bothered to take the payment. She just said she'd have to get someone more clueful to call me. I wonder why I wasn't asked to call that person in the first place?

Immediately after the call I checked my bank statement, and it seems that the Direct Debit was actually taken — yesterday. So I helpfull called back and told them that, since they didn't seem clueful enough to work out for themselves what they were doing.

Today I got another phone call, and another British Telecom representative lied to me by telling me that the bill was still unpaid.

Fucking Useless Telco.

I suppose we should try to keep the ppc64 ExcludeArch bug as empty as we've been keeping the 32-bit one, despite the fact that we don't really use much 64-bit userspace on Fedora/PPC.

So let's make a start with the fun bits... OCaml now builds on PPC64 Linux. Maybe I'll take a look at Modula-3 if I get a few moments to myself and need a little light relief.

I've looked at a few build failures on PPC/PPC64 this week, and (aside from the 'we need some nutter to port OCaml' bit) so far they've all turned out to be generic problems which just happened to bite here first. As usual, Fedora on other architectures benefits a lot from the mere fact that we also build it for PowerPC.

24 Feb 2008 (updated 24 Feb 2008 at 11:08 UTC) »

Apparently travellers have voted Seoul Incheon airport the best in the world. I can't say I agree. I don't particularly enjoy airports at the best of times, but ICN was especially crappy.

For a start, there are almost no useful shops. Now, I can deal with airports without shops; there are a lot of those. But Incheon is just packed with perfume and shiny things and tat of all kinds. Although there's a huge concourse of shops, it's really disappointing to find that there's nothing but rubbish there, aside from two tiny bookstalls. And absolutely nobody selling DVDs, thus failing to provide the two basic ways of whiling away the time spent locked in tin cans. It was extremely disappointing.

If I'd wanted to buy 500 handbags from 17 separate but (to the untrained eye) identical shops, I'd have been perfectly happy though.

There was no Internet access either. Again disappointingly so -- it looked like there was, but on trying to pay for an hour's access and getting a few screens through the process you get a popup dialog saying "Try again, please after setting the Plugin!". Closer investigation shows that it seems to be trying some Windows-only plugin just to register for access!

Not a good airport. Hong Kong, from which I type this, is much nicer. Also lots of tat shops, but at least there are some real shops amongst them. And working (and free) wireless access. And a Virgin lounge, which helps... :)

I'm slightly confused by Jeremy Clarkson's admission that he was wrong about the safety of publishing his bank details.

The Direct Debit Guarantee promises him a full and immediate refund in this situation. If he phones his bank, the money should be back in his account by the time he puts the phone down.

I have heard that Barclays Bank are very bad at honouring their obligations under the Direct Debit Guarantee, and one person tells me that's one of the reasons he now banks elsewhere.

But that's a reason for Jeremy to change banks, not to admit that he was wrong about publishing bank details -- which are, after all, on every cheque he's ever written, too.

8 Dec 2007 (updated 8 Dec 2007 at 15:21 UTC) »
(Oops. Updated to use anoncvs as I originally intended. Not everyone has an account)

Why is it that the easy way of obtaining and building a Fedora kernel isn't documented anywhere? It looks something like this:


$ cvs -d :pserver:anonymous@cvs.fedora.redhat.com:/cvs/pkgs co kernel/F-8
$ cd kernel
$ cvs -d :pserver:anonymous@cvs.fedora.redhat.com:/cvs/pkgs co common
$ cd F-8
$ cat > GNUmakefile <<EOF
ppc: DIST_DEFINES += --without smp
ppc64: DIST_DEFINES += --without kdump
i686: DIST_DEFINES += --without pae --without xen
include Makefile
EOF
$ make $(uname -m)

There are HOWTOs out there, but they seem to recommend that you download the SRPM and extract it, instead of working directly from the original. And presumably if you ever want to update it you need to download a whole new SRPM and do it all over again, instead of just 'cvs update; make $ARCH'. I cannot fathom why anyone would ever want to work directly with SRPMS like that, for any package. Even when I'm just building local hacks I wouldn't do it that way; I'd always take a copy of the Makefile from CVS and keep everything together in its own directory rather than scattered around ~/rpmbuild mixed together with potentially conflicting files from other packages.

The bit with the GNUmakefile is optional, but useful -- you can disable the builds you aren't interested in to save time, and more to the point if the last package built is the one you're interested in, you have the fully compiled source tree left behind (in kernel-$VERSION/linux-$VERSION.$ARCH) when it's done. This makes it easier for you to hack on it and debug it. After installing the built RPM on the target machine, you can individually rebuild and replace files -- both modules and the kernel image.

For the development ('rawhide') version, you'd use 'kernel/devel' in the first cvs checkout instead of 'kernel/F-8'. You can obviously have both at the same time, or even just checkout 'kernel', which should get you the common/ directory too. And a bunch of other 'branches' of the kernel.

175 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!