FTTP connection taken by persons unknown & loss of service

The saga so far....
It appears that persons unknown have placed an order for FTTP on a clients circuit, the first indication was loss of service just after midnight.

The FTTPoD connection is provided by Cerberus - they sent loosing provider information including outstanding charges (as still in contract) by email only, but not from one of their usual contact addresses so ended up in a SPAM folder and not seen.

As the circuit has been transferred Cerberus say all they can do is try to take over the circuit with the inherent 10-day cooling-off period, I presume the gaining CP could actually fix the problem more quickly (whoever ordered a service from them won't have one either) but Cerberus don't know who it is and Openreach won't tell them!

Via various convoluted remote tunnelling I've managed to do a PPPoE scan on the connection to the ONT which indicates the PPPoE server / access concentrator is now A0:F3:E4:7C:96:30 sr10.enmid - does anyone have any ideas who the CP may be? (Previously the server was acc-aln2.leb)

Given that there is no telephone number to check the CP can just pick any address, and if they are similar (e.g. Something Farm, Something Cottage, something Farm Cottage) with the same postcode there isn't much to stop this happening more frequently - an current user may be away for a couple of weeks rather than a letter/email not being seen. More importantly there doesn't seem to be any quick method of redressing the problem.

Something doesn’t quite stack up here….

Cerberus will immediately send out an unsolicited cease notification by email to the bill payer when they receive notice from the gaining provider - this will be in advance if the cease. This email comes from the Provisioning Group.

When the cease is effected at some later point, only then will Cerberus issue outstanding invoices etc. This comes from Accounts. The same email address as all usual monthly billing.

If all email correspondence from Cerberus was going into your clients spam mailbox, then how were they receiving their monthly invoices?

They haven't had the billing email yet, only the unsolicited cease email which indicated there would be charges as still in contract. I don't know why that particular email got tagged as SPAM, the original provisioning emails and monthly invoices were/are fine.

What a time for a spam filter epic fail!

Think I would immediately instruct Cerberus to takeover the service again with immediate effect. Need to make clear that client didn’t authorise the original migrate order. They should get compensated by the “gaining” provider.

This could take some days to resolve though and I’m guessing no service as pppoe auth is preventing matters. You at least know the CP isn’t either of TalkTalk or Sky….

Indeed. As the transfer was completed they have said it will take 10 working days, they are effectively starting a new takeover of the service from whichever CP now has it.

Yes, without knowing what the PPPoE credentials should be there isn't any way to authenticate.

It could still be TalkTalk Business as they use PPPoE, only their residential services are IPoE.

Edited by tdw42 (Mon 27-Sep-21 23:28:14)

Won’t be TTB either as their pppoe uses dummy creds - the old Cerberus creds would have re-auth’d after the disconnect and the new connection just comes up. Been there got the shirt.

The systems in use are clearly wrong, surely the rules need changing so that the original service provider needs to get permission or acknowledgment first to their "Sorry you are leaving" email or letter before allowing the transfer? Although perhaps OFCOM don't want the original supplier being able to block the transfer in anyway so maybe that is why they can't do anything to stop it.

On a FTTP migration doesn't the customer need to supply the ONT serial number? I guess this number could have been taken down wrong, although then the new ISP should have been able to see mismatching addresses, assuming they checked.

I do hope you get it sorted out soon, but the system does seem to be setup for these mistakes to happen all too easily.

In reply to a post by E300:

perhaps OFCOM don't want the original supplier being able to block the transfer in anyway so maybe that is why they can't do anything to stop it.

I think that's the case - to minimise friction on transfers.

I had this happen to me on copper/FTTC, with our Plusnet service being "slammed" by Talktalk.

A letter and package arrived at our house, addressed to some random person - both of which we returned unopened as "not known at this address". Plusnet didn't notify us that the service was being taken over. We didn't know it at the time, but the package was almost certainly a Talktalk router.

We lost our service, including our phone number, for about three weeks.

Plusnet couldn't reinstate the account exactly as before - I ended up with a new account, a new static IP, and lost my referrals - so I now have to ask for a discount on each renewal.

In reply to a post by E300:

On a FTTP migration doesn't the customer need to supply the ONT serial number?

I don't think so.

In an ideal world, each line would have a circuit reference: if there are multiple ONTs in the same premise, then there's scope for confusion. I believe copper lines have such references ("CBUK..." if I remember rightly?) but consumers are generally unaware of them. The phone number was normally good enough, even though the phone number can move between lines.

In reply to a post by E300:

On a FTTP migration doesn't the customer need to supply the ONT serial number? I guess this number could have been taken down wrong, although then the new ISP should have been able to see mismatching addresses, assuming they checked.

Not as things stand, they don’t need to give the serial number. Probably a good idea, although there would be complaints from the CPs I reckon. Would however stop this sort of thing happening. Not sure how widespread a problem it is…

The AC name suggests sr10.enmid.isp.sky.com - although why PPPoE discovery would work on a DHCP connection is anyone's guess.