Need him to confirm if they replaced the ONT, cant recall. That would be my first port of call for physical port disconnections (Ethernet) and would be insisting on this if this if so.

Didn't Jake's issue appear to be resolved by a mystery card placement somewhere in the Openreach network without the need for him to be un-migrated. I would have expected him to be back here if his issue had come back.

I don't think the Samknows has any way to know if they are actually physical port disconnections. It's on a switch port on the Fritzbox, one stop away from the ONT ethernet port. The logs on the Fritzbox might offer up some clues, as it does log the PPPoE sessions coming and going.

Yep. Was referring to Steve’s connection, rather than Jake

There well could be multiple things in play. Not necessarily one common thread.

Edited by Pheasant (Sat 10-Sep-22 20:33:24)

Knowing whether the disconnection is physical (Ethernet port flapping for example) is key to understanding whether the ONT could be at fault. If it’s a PPPoE disconnect that would be transparent to the ONT.

You want the month? Here it is My beef is that the whole 'testing' of this is a farce in real ISTQB / ISEB terms.... It is best described as 'exploratory' testing, without any baseline, any pass / fail criteria, no 'requirements', no objective with the testing, zero good practice TBH.

So, I am happy to do as they ask, and to share that here, I agree, any element from the RJ45 backwards could be to blame, but there is zero real attempt to isolate it, save from a retrospective look back from their end, and a snapshot of the problem observed from this end.

At the risk of repeating myself.... they continue to roll this out to other (unknowing) victims, with no understanding of the 'problem' ..... THAT is the biggest issue.

The process of testing is very well known, and documented for example It's not rocket science, but it's something that needs an understanding of what one is trying to achieve, some (sensible) pass/fail criteria (50% of advertised bandwidth...? REALLY? !) You need a clear plan of what you do before go-live (to mitigate failure risks), and after that, some warranty plan to catch stuff that was forgotten????

Of course, there is a huge caveat...... ALL testing is 'risk based testing', and it seems that the appetite for risk here is somewhat higher than the industry norms, the drawbacks? 1) Loss of reputation, 2) Probability of negative publicity.... It's again less than rocket science, speed and cost of deployment versus the two big negatives above.

I could go on and on, but there is simply no real science being applied here, even grabbing some 'try this' thing isn't a systematic process that will get the root cause. Seems there isn't a 'Eureka' moment to be had, simply guesswork.

Oh, and end comment.... A proper systematic test approach to all this would have taken FAR less time than from March to now, have caused less grief, cost less, and everyone would have a transparent view of any test results to reassure them that this had been tackled correctly, even if they had a minor problem, they would have the reassurance that things had been tackled properly.

Edited by SteveBushell999 (Sat 10-Sep-22 22:22:30)

Which indicates that as far as the corporate view from Zen is concerned it is not a real problem - just a few nerds who are not typical of most of their customer base shouting the odds. Most of the people paying their bills to Zen are not aware in their everyday use of the network of any problems so where is the business case to spend any money to find a solution?

To anyone with any sort of scientific or technical background that is a deeply unsatisfactory view of how things should be done but for anyone with an arts, liberal arts, media studies or accountancy background a totally acceptable way forward.

Edited by GonePostal (Sun 11-Sep-22 01:09:13)

In reply to a post by GonePostal:

Which indicates that as far as the corporate view from Zen is concerned it is not a real problem - just a few nerds who are not typical of most of their customer base shouting the odds. Most of the people paying their bills to Zen are not aware in their everyday use of the network of any problems so where is the business case to spend any money to find a solution?

To anyone with any sort of scientific or technical background that is a deeply unsatisfactory view of how things should be done but for anyone with an arts, liberal arts, media studies or accountancy background a totally acceptable way forward.

I sadly understand what you saying as some car manufactures when finding issues with their cars sometimes take the decision that a few possible deaths is not a good enough reason to spend millions on a vehicle recall.

Edited by deleted (Sun 11-Sep-22 09:50:43)

Yes, so it's very fail-y.

With that level of disconnections I really wouldn't be bothering to put anything else on that network. It's very obviously broken, and Zen have more than enough there with the Samknows box on the line to be trying to address it if they wanted to. You're not doing yourself any favours moving anything else onto the line, just inconveniencing yourself, and I can't see any evidence they'll care any more for the extra data it might give - they've got plenty of data there already to work through if they wanted. The only testing that would make any sense for you to do to that GEA line would be things which have potential to improve or change its behaviour, which sticking a server running on it has absolutely no chance of improving matters. So things like a replacement ONT, cable replacement, swapping ONTs between the different fibre downleads, swapping routers, etc.

I agree with the continued roll-out question. I've been migrated back, but I doubt anyone else has been at my exchange, and I doubt very much I'm the only one who was affected at my exchange as I can't believe there is any bit of kit that would be unique to me on Zen (I don't think I had a dedicated physical port wired to them, for instance, I think with FTTP it is all done via switch / OLT configuration / VLANs / etc).

In reply to a post by dect:

as some car manufactures when finding issues with their cars sometimes take the decision that a few possible deaths is not a good enough reason to spend millions on a vehicle recall.

Such as Tesla.