I've had a quick look at this.

In reply to a post by Banger:

Well this is getting frustrating. Uno are saying that port error in their session history could be anything.

It has been explained that this is a standard RADIUS session end reason. My colleague explained that it can be caused by several things and not to focus too much on it being a port issue because the error is not solely relative to the port, but just has the title "Port Error".

Uno are also telling me it is unlikely OR will do a port swap or lift and shift as they term it as the line is likely to prove clear.

What has been said is that it is unlikely OR will just go and do this as matter of course, when a line is testing entirely clear, prior to a visit. If the engineer deems this required on the visit it will be done but we're not even at that stage. You need to allow OR at least some time to look at it before assumptions are made as to what will and won't be done.

Matt

Edited by uno (Sat 05-Sep-20 21:56:19)

It has been explained that this is a standard RADIUS session end reason. My colleague explained that it can be caused by several things and not to focus too much on it being a port issue because the error is not solely relative to the port, but just has the title "Port Error".

Yes I understand that Matt but the fact that port error appears at the time the line drops which was 3 times today is a remarkable coincidence. Usually when I reconfigure my router to find a workaround for the drop it says User-request. Even when rebooting the modem User-request is in the session history.

What has been said is that it is unlikely OR will just go and do this as matter of course, when a line is testing entirely clear, prior to a visit. If the engineer deems this required on the visit it will be done but we're not even at that stage. You need to allow OR at least some time to look at it before assumptions are made as to what will and won't be done.

The two colleagues that have been assisting me with this have been helpful. One more than the other as one colleague left me with the impression OR will not investigate this any further if the engineer finds a clear line. This is not a DSL drop it is PPP disconnection under load which apart from the line card maybe further a field which your colleage failed to mention OR might investigate. I am a little wary as this is not the first ticket I have raised about this issue before although it was not as prolific as today on 08/09/2018 titled Admin Resets and I spoke to you on the ticket. I made some adjustments to my kit and felt it was liveable with but today was the last straw.

Let's see how things go once that fault is picked up on Monday.

The previous ticket you raised on 11/08 and then closed yourself the next day as you said you had found the cause. As it was closed, we'd not see it again so whilst this may not be the first, it is where we've progressed it further within a few hours of you advising the earlier changes didn't help. I'm not sure we could have done it any sooner from the testing you wanted to conduct from advice you were given elsewhere.

Matt

Edited by uno (Sat 05-Sep-20 22:38:08)

I agree that the term "port error" is a generic term used when there is no obvious explanation for the failure.

It's kind of like the term "syndrome" in health where it's used because the problem doesn't lie in any other category.

I've seen this problem, especially when saturating upstream bandwidth. Have a look at PPP Echo parameters (interval and maximum failures count) in your router config. Saturation of bandwidth in either direction can lead to PPP Echo packets either not getting to the far end, therefore not eliciting a response, or response packets being missed. Under sustained load, several Echo sequences can fail in a row. If the number of missed responses exceeds the maximum failures count, the router will assume that the PPP session has dropped when in fact it's alive and kicking, just otherwise engaged.

Increasing the max failures count may help, but the root cause is wrong prioritization of PPP Echo packets by the router OS at either or both ends. Like all other handshake-type traffic, they should have highest priority so that control traffic is never crowded out by payload, but designers of consumer-grade routers tend not to look for such edge cases in QA...

I was working on that assumption that PPP echo packets were not getting there and have tried various settings of max failure on my Asus router. As the Asus isnt approved I have turned my ZyXel VMG-1312-B10A into a router this morning and the Asus as a wifi AP.

It has dropped twice today, I am testing every hour with a 1gb file. Why so random if the upstream is congested or too low (Sync 63/13) as the Openreach specialist has suggested who called me today?

Unfortunately the ZyXel hasn't got the PPP echo settings in its configuration that I can find the Asus has. Has anyone come across PPP Echo settings on the VMG-1312-B10A on latest firmware?

I think it is more complex than that because it happens every 4 hours. In between the download is successful.

So I have had a port swap this afternoon. OR is also saying they can see interference on the line and want to send an SFI. Anyone had one before and know what it involves?

SFI = Special Fault Investigation

Sounds posh, but will just be a standard broadband faulting visit. Pair Quality test. Check the set up is OK (yours is) and a ‘close out’ VDSL test which tests both sync and connectivity to the test login.

SFI cancelled. Both OR and SP agree after port change there should be a noteable pause to monitor the line to see how it performs.

Thanks Zarjaz for info.