Discussion:
VDSL unreliability
(too old to reply)
Marco Moock
2024-07-25 18:38:58 UTC
Permalink
The V2763 router always reports "PPP Closed : Remote Terminating
(PPPoA)".
This clearly indicates that your ISP terminates the PPP session. Ask
them why they do that.
--
kind regards
Marco

Send spam to ***@cartoonies.org
Graham J
2024-07-26 11:05:22 UTC
Permalink
This is a service that was upgraded from ADSL to VDSL on 29 April
this year.  Since the upgrade I've seen re-syncs overnight, generally
during the hours of darkness with a slight preference for times
around dusk and dawn.
can you get a bits per bin graph out of the router?
if so compare a before/after graph ...
[snip]
I will check carefully after the next re-sync.
The succeeding re-sync was 25/07/2024 21:00:57 yesterday, and the bits
per bin graph looks the same. Speeds much the same, as shown by:

Downstream Upstream
Actual Rate 32656 Kbps 9199 Kbps
Attainable Rate 34269 Kbps 9199 Kbps

Ideas?
--
Graham J
Graham J
2024-07-26 11:08:13 UTC
Permalink
Post by Marco Moock
The V2763 router always reports "PPP Closed : Remote Terminating
(PPPoA)".
This clearly indicates that your ISP terminates the PPP session. Ask
them why they do that.
I suspect it actually means the DSLAM in the green cabinet has
terminated the PPP session. I did ask the ISP (Zen) but they couldn't
help. They could not see any problems with the connection when using
the tool that Openreach provides them with.
--
Graham J
Marco Moock
2024-07-26 13:16:22 UTC
Permalink
Post by Graham J
I suspect it actually means the DSLAM in the green cabinet has
terminated the PPP session.
PPP is above the DSL signal. If DSL fails, PPP will run in a timeout
and won't do the normal closing process.

https://www.rfc-editor.org/rfc/rfc1661#page-33

If Terminate Request and Ack go through, this is a normal PPP process
and the DSL signal is fine in that case.

PPP isn't handled by the DSLAM, it is handled by the BRAS.
--
kind regards
Marco

Send spam to ***@cartoonies.org
Graham J
2024-07-26 15:07:02 UTC
Permalink
Post by Marco Moock
Post by Graham J
I suspect it actually means the DSLAM in the green cabinet has
terminated the PPP session.
PPP is above the DSL signal. If DSL fails, PPP will run in a timeout
and won't do the normal closing process.
https://www.rfc-editor.org/rfc/rfc1661#page-33
If Terminate Request and Ack go through, this is a normal PPP process
and the DSL signal is fine in that case.
PPP isn't handled by the DSLAM, it is handled by the BRAS.
Thanks.

Generally, the router's logs indicate "SHOWTIME" several seconds
(anything from 10 to 100) after the "PPP Closed : Remote Terminating
(PPPoA)" message. Usually the sync speeds differ by a very small amount
(fractions of a percent) before and after the termination message, from
which I assume that the modem component in the router has re-negotiated.
After another minute or so, I see the sequence:

PPP Start (PPPoA)
CHAP Login OK (PPPoA)
IPCP Opening (PPPoA); Own IP Address ... etc.

From this I assume that there was nothing wrong with the DSL signal and
there was no need to force a re-negotiation, so I don't understand why
the BRAS sends the termination command.

Zen have not been helpful; they report that there is nothing wrong with
the DSL service but are suggesting that random noise is breaking the DSL
connection. From your explanation this is clearly not the case.

Any ideas how I can get any further with this?
--
Graham J
Tweed
2024-07-26 15:25:58 UTC
Permalink
Post by Graham J
Post by Marco Moock
Post by Graham J
I suspect it actually means the DSLAM in the green cabinet has
terminated the PPP session.
PPP is above the DSL signal. If DSL fails, PPP will run in a timeout
and won't do the normal closing process.
https://www.rfc-editor.org/rfc/rfc1661#page-33
If Terminate Request and Ack go through, this is a normal PPP process
and the DSL signal is fine in that case.
PPP isn't handled by the DSLAM, it is handled by the BRAS.
Thanks.
Generally, the router's logs indicate "SHOWTIME" several seconds
(anything from 10 to 100) after the "PPP Closed : Remote Terminating
(PPPoA)" message. Usually the sync speeds differ by a very small amount
(fractions of a percent) before and after the termination message, from
which I assume that the modem component in the router has re-negotiated.
PPP Start (PPPoA)
CHAP Login OK (PPPoA)
IPCP Opening (PPPoA); Own IP Address ... etc.
From this I assume that there was nothing wrong with the DSL signal and
there was no need to force a re-negotiation, so I don't understand why
the BRAS sends the termination command.
Zen have not been helpful; they report that there is nothing wrong with
the DSL service but are suggesting that random noise is breaking the DSL
connection. From your explanation this is clearly not the case.
Any ideas how I can get any further with this?
Move to A&A….
Graham J
2024-07-26 20:41:48 UTC
Permalink
Post by Graham J
Post by Marco Moock
Post by Graham J
I suspect it actually means the DSLAM in the green cabinet has
terminated the PPP session.
PPP is above the DSL signal. If DSL fails, PPP will run in a timeout
and won't do the normal closing process.
https://www.rfc-editor.org/rfc/rfc1661#page-33
If Terminate Request and Ack go through, this is a normal PPP process
and the DSL signal is fine in that case.
PPP isn't handled by the DSLAM, it is handled by the BRAS.
Thanks.
Generally, the router's logs indicate "SHOWTIME" several seconds
(anything from 10 to 100) after the "PPP Closed : Remote Terminating
(PPPoA)" message.  Usually the sync speeds differ by a very small amount
(fractions of a percent) before and after the termination message, from
which I assume that the modem component in the router has re-negotiated.
PPP Start (PPPoA)
CHAP Login OK (PPPoA)
IPCP Opening (PPPoA); Own IP Address ... etc.
From this I assume that there was nothing wrong with the DSL signal and
there was no need to force a re-negotiation, so I don't understand why
the BRAS sends the termination command.
Zen have not been helpful; they report that there is nothing wrong with
the DSL service but are suggesting that random noise is breaking the DSL
connection.  From your explanation this is clearly not the case.
Any ideas how I can get any further with this?
OP here - to add some more detail following a failure in the last few
minutes:

Jul 26 20:55:24 WAN1 PPPoE ==> Protocol:LCP(c021) EchoRep Identifier
Jul 26 20:55:25 ADSL_Status:[Mode=17A States=SHOWTIME
Jul 26 20:55:40 PPP Closed : Remote Terminating (PPPoA)
Jul 26 20:55:40 WAN1 PPPoE ==> Protocol:LCP(c021) TermReq Identifier
Jul 26 20:55:40 DSL: Modem Shut Down from ADSL Phy Layer (0)

So clearly the DSL connection was good until "PPP Closed : Remote
Terminating (PPPoA)" was logged. Then "TermReq Identifier" is logged.
There's no "TermAck" so this presumably is not received because the
modem is now shut down.

It's not clear from the syslog which device sends the command. Thus
"PPP Closed : Remote Terminating (PPPoA)" is reported, but it could have
been sent by the V2763 router, or by the BRAS through the DSLAM.

Similarly "PPPoE ==> Protocol:LCP(c021) TermReq Identifier" is logged,
but is this sent by the V2763 in response the the "Remote Terminating"
message, or is it received from the DSLAM?

Expert guidance appreciated, please.
--
Graham J
grinch
2024-07-27 12:51:37 UTC
Permalink
Post by Graham J
Jul 26 20:55:24 WAN1 PPPoE ==> Protocol:LCP(c021) EchoRep Identifier
Jul 26 20:55:25 ADSL_Status:[Mode=17A States=SHOWTIME
Jul 26 20:55:40 PPP Closed : Remote Terminating (PPPoA)
Jul 26 20:55:40 WAN1 PPPoE ==> Protocol:LCP(c021) TermReq Identifier
Jul 26 20:55:40 DSL:  Modem Shut Down from ADSL Phy Layer (0)
So clearly the DSL connection was good until "PPP Closed : Remote
Terminating (PPPoA)" was logged.  Then "TermReq Identifier" is logged.
There's no "TermAck" so this presumably is not received because the
modem is now shut down.
It's not clear from the syslog which device sends the command.  Thus
"PPP Closed : Remote Terminating (PPPoA)" is reported, but it could have
been sent by the V2763 router, or by the BRAS through the DSLAM.
Similarly "PPPoE ==> Protocol:LCP(c021) TermReq Identifier" is logged,
but is this sent by the V2763 in response the the "Remote Terminating"
message, or is it received from the DSLAM?
Expert guidance appreciated, please.
You have 2 choices here

1 Waste a lot of time money and effort trying to get DSL to work on a
line that is not good enough else it would just work.

OR are about as much use as a chocolate teapot trying to find transient
faults,and that is from personal professional experience working for ISP's.

2 Migrate back to adsl which does just work slower but stable.


Am I right in remembering that PPP CHAP requires re-auth on a regular
basis if that is timing out due to line/traffic issues that could be
the reason for the drops. I have not had much to do with dsl
professionally for a while ,fortunately.
Graham J
2024-07-27 13:16:35 UTC
Permalink
grinch wrote:

[snip]
Post by grinch
2 Migrate back to adsl which does just work slower but stable.
Fair comment. ADSL prior to upgrade to VDSL achieved about 4 mbits/sec
down, 800 kbits/sec up and was fairly reliable - perhaps dropping once
per month.

FTTP (from Zen) is not expected for several years.
Post by grinch
Am I right in remembering that PPP CHAP requires re-auth on a regular
basis if that is timing out due to line/traffic issues that could be
the reason for the drops. I have not had much to do with dsl
professionally for a while, fortunately.
Could you suggest a good reference for this?

The V2763 syslog shows "LCP(c021) EchoReq Identifier" pairs in and out
every 10 seconds.

Interestingly, the pair at 20:55:24 is not followed by another pair at
20:55:34. The next log entry is:

20:55:40 PPP Closed : Remote Terminating (PPPoA)

So you may be right that the lack of LCP packet exchanges may indicate
that the DSL has been affected by noise, and the BRAS sends "terminate"
(via the DSLAM) to cause the line to re-sync.

I will enable logging again this evening in anticipation of seeing a
similar pattern.

The faults are consistent with interference from a security light. They
occur between dusk and dawn, more frequently in late evening when people
may be coming home, or about dawn when muntjac deer or hedgehogs my be
wandering about - this is a rural area. But there can be periods of
several days (maximum 8 so far) when there are no line drops.

It's not the user's security light - that's been off for several weeks.
But it could be a light near the green cabinet.
--
Graham J
Graham J
2024-07-27 19:46:03 UTC
Permalink
Post by Graham J
[snip]
Post by grinch
2 Migrate back to adsl which does just work slower but stable.
Fair comment.  ADSL prior to upgrade to VDSL achieved about 4 mbits/sec
down, 800 kbits/sec up and was fairly reliable - perhaps dropping once
per month.
FTTP (from Zen) is not expected for several years.
Post by grinch
Am I right in remembering that PPP CHAP requires re-auth on a regular
basis if that is timing out due to line/traffic issues that could be
the reason for the drops. I have not had much to do with dsl
professionally for a while, fortunately.
Could you suggest a good reference for this?
The V2763 syslog shows "LCP(c021) EchoReq Identifier" pairs in and out
every 10 seconds.
Interestingly, the pair at 20:55:24 is not followed by another pair at
20:55:40 PPP Closed : Remote Terminating (PPPoA)
So you may be right that the lack of LCP packet exchanges may indicate
that the DSL has been affected by noise, and the BRAS sends "terminate"
(via the DSLAM) to cause the line to re-sync.
I will enable logging again this evening in anticipation of seeing a
similar pattern.
[snip]

The line drop tonight looked like this:

19:59:43 WAN1 PPPoE <== Protocol:LCP(c021) EchoReq Identifier:
19:59:43 WAN1 PPPoE ==> Protocol:LCP(c021) EchoRep Identifier:

... LCP echo pair expected 19:59:53

19:59:59 PPP Closed : Remote Terminating (PPPoA)
19:59:59 WAN1 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:
19:59:59 WAN 1 is down.

Prior to the drop a quick scan of the log file shows EchoReq Identifier
pairs at 10 second intervals.

I think this confirms my suspicion that something prevents the LCP echo
pair from being exchanged, and this is reported to the BRAS which
instructs the system to drop and re-establish the connection.

Thanks to grinch for suggesting this.
--
Graham J
Marco Moock
2024-07-27 20:12:53 UTC
Permalink
Post by Graham J
I think this confirms my suspicion that something prevents the LCP
echo pair from being exchanged, and this is reported to the BRAS
which instructs the system to drop and re-establish the connection.
This is something the ISP needs to check. Is there a specific time
after that happens (e.g. 24 or 48h)?
--
kind regards
Marco

Send spam to ***@cartoonies.org
Graham J
2024-07-28 07:02:46 UTC
Permalink
Marco Moock wrote:
[snip]
Post by Marco Moock
Is there a specific time
after that happens (e.g. 24 or 48h)?
No. As I wrote in an earlier post:

Sometimes the connection stays up for several (the maximum has been 8)
days; sometimes it fails 3 or 4 times per night. Daytime failures are
rare - once per month perhaps.

This would suggest something environmental - a security light perhaps?
--
Graham J
Theo
2024-07-27 13:19:38 UTC
Permalink
Post by grinch
You have 2 choices here
1 Waste a lot of time money and effort trying to get DSL to work on a
line that is not good enough else it would just work.
OR are about as much use as a chocolate teapot trying to find transient
faults,and that is from personal professional experience working for ISP's.
2 Migrate back to adsl which does just work slower but stable.
I'm not seeing why a nightly resync is a problem? I used to get those
regularly, usually 3-5am kind of time. It didn't bother me as everything
stayed up, including open TCP connections. It was just the DSL dropping out
for maybe half a minute and then it came back again.

I don't know why it did it - maybe it was something about the modem (for a
time I was using a third party modem-router, now I'm using the ISP's own
one)? I assumed it was initiated by the ISP in some way. Now I check and
the connection has been up for about 10 weeks, so evidently it's not
happening.

By all means dig into it, but the question is whether you can live with
losing 30 seconds in the middle of the night?
Post by grinch
Am I right in remembering that PPP CHAP requires re-auth on a regular
basis if that is timing out due to line/traffic issues that could be
the reason for the drops. I have not had much to do with dsl
professionally for a while ,fortunately.
You may need to send PPP keepalives, I'm sure I saw those logged in dialup
days. It's been a while.

Theo
Java Jive
2024-07-27 15:20:12 UTC
Permalink
Post by Theo
I'm not seeing why a nightly resync is a problem? I used to get those
regularly, usually 3-5am kind of time. It didn't bother me as everything
stayed up, including open TCP connections. It was just the DSL dropping out
for maybe half a minute and then it came back again.
I used to get these when I was with BT, or was it PlusNet, no matter, as
they're more or less the same thing. They seemed to have this habit of
rebooting the router at around 2 every morning. I'd find things
dropping out, particularly overnight GetIPlayer downloads. I put a stop
to it by changing the default password on their router.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Graham J
2024-07-27 16:23:00 UTC
Permalink
Theo wrote:

[snip]
Post by Theo
I'm not seeing why a nightly resync is a problem? I used to get those
regularly, usually 3-5am kind of time. It didn't bother me as everything
stayed up, including open TCP connections. It was just the DSL dropping out
for maybe half a minute and then it came back again.
The user now has VoIP implemented with a Grandstream HT801 ATA. He also
has a TV connected to the LAN so he can watch internet-based material.

So a break in the evenings is obviously inconvenient.

The Grandstream HT801 occasionally fails to re-register after an
internet failure. The provider (Voipfone) blames the router for the
registration failure, but by rebooting the router and the ATA separately
I have been able to show that only rebooting the ATA resolves the
problem. Has anybody here seen a similar problem?

So there are very good reasons for wanting the VDSL to stay up much more
reliably.

In other locations I monitor VDSL stays up for thousands of hours ...
--
Graham J
Marco Moock
2024-07-27 18:59:00 UTC
Permalink
Post by Graham J
So there are very good reasons for wanting the VDSL to stay up much
more reliably.
In other locations I monitor VDSL stays up for thousands of hours ...
If there is a PPP Termination Request, the remote site intentionally
closes the PPP session which will result in an internet outage, even if
DSL sync still exists. PPP is an upper layer on DSL, sometimes
PPPoverATM, PPP over Ethernet or PPP over Ethernet over ATM.

Tell your provider that they must figure out why they send a term
request. Some did that in the past intentionally to avoid people using
DSL like a non-switched line and to make them pay more not to have that
annoying thing.
--
kind regards
Marco

Send spam to ***@cartoonies.org
grinch
2024-07-28 09:31:18 UTC
Permalink
Post by Marco Moock
Post by Graham J
So there are very good reasons for wanting the VDSL to stay up much
more reliably.
In other locations I monitor VDSL stays up for thousands of hours ...
If there is a PPP Termination Request, the remote site intentionally
closes the PPP session which will result in an internet outage, even if
DSL sync still exists. PPP is an upper layer on DSL, sometimes
PPPoverATM, PPP over Ethernet or PPP over Ethernet over ATM.
Tell your provider that they must figure out why they send a term
request. Some did that in the past intentionally to avoid people using
DSL like a non-switched line and to make them pay more not to have that
annoying thing.
Zen don't do that. I have been a customer for 12 years and have
permanent public IP space V4/V6. They allow business to run on DSL but
you only get DSL levels of service.

They did take my unused /29 IPV4 off me and just gave me a /32 which I
don't have a problem with.
Theo
2024-07-28 11:35:14 UTC
Permalink
Post by Graham J
The user now has VoIP implemented with a Grandstream HT801 ATA. He also
has a TV connected to the LAN so he can watch internet-based material.
So a break in the evenings is obviously inconvenient.
The Grandstream HT801 occasionally fails to re-register after an
internet failure. The provider (Voipfone) blames the router for the
registration failure, but by rebooting the router and the ATA separately
I have been able to show that only rebooting the ATA resolves the
problem. Has anybody here seen a similar problem?
Sounds like it's a Grandstream problem. Apparently it only tries to
reconnect for 2 minutes and then gives up:
https://forums.sonic.net/viewtopic.php?t=10443
(although not in your exact circumstances)

Have you checked the firmware is the latest? According to that thread
dialling '***16' on the phone will read out the firmware version.
Post by Graham J
So there are very good reasons for wanting the VDSL to stay up much more
reliably.
While that's true, it sounds like it's additionally the HT801 at fault.

Theo
Graham J
2024-07-28 17:46:30 UTC
Permalink
Theo wrote:

[snip]
Post by Theo
Post by Graham J
So there are very good reasons for wanting the VDSL to stay up much more
reliably.
While that's true, it sounds like it's additionally the HT801 at fault.
Interesting, thanks. I will go back to Voipfone about this. Previously
they have blamed the router, but I've tried another since then and the
problem remains ...
--
Graham J
Theo
2024-07-29 10:45:21 UTC
Permalink
Post by Graham J
[snip]
Post by Theo
Post by Graham J
So there are very good reasons for wanting the VDSL to stay up much more
reliably.
While that's true, it sounds like it's additionally the HT801 at fault.
Interesting, thanks. I will go back to Voipfone about this. Previously
they have blamed the router, but I've tried another since then and the
problem remains ...
I wonder if tweaking the modem would have any effect?

When I was using a BT Homehub 5a (Lantiq chip) as a VDSL modem, there were
markedly different behaviours from different firmware versions. Somebody
has a repository of all the different firmwares and it's possible (in
OpenWRT) to select which one to upload to the modem. Speed and stability
was quite different - I think the speed was because some firmware didn't
support VDSL2 vectoring, but stability would vary between firmware.
Supposedly there are 'good' firmwares out there but I didn't want to keep
taking the connection down to experiment.

I've since switched to the Sky router (Broadcom chip) - there's no open source
OS for these, so I'm using it as supplied by Sky. This seems much more
stable than the HH5a, and gets higher speed too (~76Mbps down, against ~55Mbps
on the HH5a without vectoring).

Perhaps it's worth trying a discrete VDSL modem plus an ethernet router -
maybe you'll get more stats out of the modem than a combined modem/router
gives you. eg the router will be handling PPP so you can get a log out of
that side of things, whereas the modem would tell you whether the VDSL link
went down or not, and maybe other more detailed line logs.

Someone else's tale, using a discrete modem, showing the kind of stats you
get:
https://forum.kitz.co.uk/index.php?topic=25911.0

Another thing is, do you know what vendor of cabinet you're on? I think the
main ones are Huawei and ECI. I'm on a Huawei cabinet which has Broadcom
silicon, which might be why my Broadcom modem works well with it. Possibly
another reason why the Lantiq modem works less well - it seems that ECI
cabinets using Lantiq silicon so maybe it would be better on those.
https://kitz.co.uk/adsl/fttc-cabinets.htm

I think one of the 'checkers' (maybe the BT Wholesale one?) indicates the
vendor of cabinet, but you can probably identify it from the pictures above
and Streetview.

Which routers did you try? I heard one option is to try the modems that
were originally installed by Openreach on early VDSL installs - can likely
be found on ebay for not-much:
https://kitz.co.uk/routers/openreach-modems.htm
I'd buy the type to match your cabinet vendor, which is what OR did on early
VDSL installs. They probably won't support vectoring but at least you might
get some stats out of them, and perhaps be more stable?

Theo
Theo
2024-07-29 12:16:23 UTC
Permalink
Post by Theo
I think one of the 'checkers' (maybe the BT Wholesale one?) indicates the
vendor of cabinet, but you can probably identify it from the pictures above
and Streetview.
Ah, this has a procedure using Angus' Codelook site:
https://kitz.co.uk/adsl/cabinet-lookup.htm
Graham J
2024-07-29 21:22:57 UTC
Permalink
Theo wrote:

[snip]
Post by Theo
I wonder if tweaking the modem would have any effect?
[snip]
Post by Theo
Perhaps it's worth trying a discrete VDSL modem plus an ethernet router -
maybe you'll get more stats out of the modem than a combined modem/router
gives you. eg the router will be handling PPP so you can get a log out of
that side of things, whereas the modem would tell you whether the VDSL link
went down or not, and maybe other more detailed line logs.
The initial configuration was a V130 modem and a V2830 router. No
useful stats from the V130 unless connected via a switch to the router
and a monitoring PC. Not practical for a customer site.

Performance with ADSL was good. Following conversion to VDSL
performance was awful 20 or 30 line drops per day.

Replaced with a V2763 router. Good diagnostics available. Reliability
better - sometimes 3 or 4 drops per day, other times up continuously for
8 days.
Post by Theo
Another thing is, do you know what vendor of cabinet you're on?
Router reports cabinet Vendor ID:=b5004244 434da4a1 [BDCM]{i.e. =
Broadcom = Huawei }

I need the Vigor router for LAN-to-LAN VPN and to work with F8Lure so I
can monitor the conenction reliability, so the Fritzbox supplied by Zen
is no use.
--
Graham J
Theo
2024-07-30 12:12:58 UTC
Permalink
Post by Graham J
The initial configuration was a V130 modem and a V2830 router. No
useful stats from the V130 unless connected via a switch to the router
and a monitoring PC. Not practical for a customer site.
Performance with ADSL was good. Following conversion to VDSL
performance was awful 20 or 30 line drops per day.
Replaced with a V2763 router. Good diagnostics available. Reliability
better - sometimes 3 or 4 drops per day, other times up continuously for
8 days.
Post by Theo
Another thing is, do you know what vendor of cabinet you're on?
Router reports cabinet Vendor ID:=b5004244 434da4a1 [BDCM]{i.e. =
Broadcom = Huawei }
It seems that the Vigor range is all Lantiq, so that's a mismatch with the
cabinet.
Post by Graham J
I need the Vigor router for LAN-to-LAN VPN and to work with F8Lure so I
can monitor the conenction reliability, so the Fritzbox supplied by Zen
is no use.
Perhaps worth interposing a modem with a Broadcom chipset?
https://forum.kitz.co.uk/index.php?topic=24277.0

The 7530 uses a Lantiq* VRX518 VDSL chip (with a Qualcomm main SoC). You
can put it in bridge mode but that would still be a mismatch.

Theo

[*] acquisitions have been Lantiq -> Intel -> MaxLinear so any of those
refer to the same silicon
NY
2024-07-30 13:27:41 UTC
Permalink
Post by Theo
Perhaps worth interposing a modem with a Broadcom chipset?
https://forum.kitz.co.uk/index.php?topic=24277.0
The 7530 uses a Lantiq* VRX518 VDSL chip (with a Qualcomm main SoC). You
can put it in bridge mode but that would still be a mismatch.
My TP-Link TD-W9980 uses a Lantiq chipset, but that still gives me, as far
as I know, a flawless connection. I say "as far as I know" because the
system log currently (14:20) only goes back as far as 18:55 yesterday
evening, so I've no way of knowing whether there were any DSL disconnections
before that. The main status page says "System Up Time: 29 day(s) 07:06:35"
but that is time since the router was last rebooted (probably the last time
we had a power cut!) and is not "time since last DSL connection".

The router occasionally changes the WAN address that my ISP allocates it. Is
a change of IP address always an indication of a disconnection/reconnection,
or can the DSL connection stay up and yet the *WAN* DHCP lease expire and
renew? I'm sure every reconnection causes a DHCP renewal, but maybe not
every DHCP renewal is due to DSL reconnection.
Graham J
2024-07-30 16:43:25 UTC
Permalink
Theo wrote:

[snip]
Post by Theo
The 7530 uses a Lantiq* VRX518 VDSL chip (with a Qualcomm main SoC). You
can put it in bridge mode but that would still be a mismatch.
I tried putting the Fritz!box 7530 into bridge mode but could not get it
to work. The manufacturers (AVM) say it's not possible, but I did find
somebody on the web who claimed to have done it - I think with a foreign
ISP.

If you can tell me how to do it I will try again ...
--
Graham J
Theo
2024-07-30 16:56:48 UTC
Permalink
Post by Graham J
[snip]
Post by Theo
The 7530 uses a Lantiq* VRX518 VDSL chip (with a Qualcomm main SoC). You
can put it in bridge mode but that would still be a mismatch.
I tried putting the Fritz!box 7530 into bridge mode but could not get it
to work. The manufacturers (AVM) say it's not possible, but I did find
somebody on the web who claimed to have done it - I think with a foreign
ISP.
If you can tell me how to do it I will try again ...
Mine runs OpenWRT so afraid I can't help with that...

(I've not got around to using the VDSL modem though apparently that's
supported under OpenWRT)

Theo

Andy Burns
2024-07-25 10:25:38 UTC
Permalink
This is a service that was upgraded from ADSL to VDSL on 29 April this
year.  Since the upgrade I've seen re-syncs overnight, generally during
the hours of darkness with a slight preference for times around dusk and
dawn.
can you get a bits per bin graph out of the router?
if so compare a before/after graph ...
Graham J
2024-07-25 12:22:34 UTC
Permalink
This is a service that was upgraded from ADSL to VDSL on 29 April this
year.  Since the upgrade I've seen re-syncs overnight, generally
during the hours of darkness with a slight preference for times around
dusk and dawn.
can you get a bits per bin graph out of the router?
if so compare a before/after graph ...
Yes. I don't see any obvious difference across a re-sync. A graph
captured on 20 May looks very similar to today's picture, except that
the upstream bits/bin peak at about 3.5 (probably the upstream sync
speed was lower that day)

As I write upstream shows about 4.5 bits per bin for the range 1000 to 1600.

Downstream shows a range from 30 to about 4 for the range 0 to 600, then
about 4 for the range 600 to 1000. Then a gap 1600 (for the upstream)
after that a slow reduction to about 2 bits/bin up to 2400.

I will check carefully after the next re-sync.

The DSL status currently reports:

Downstream Upstream
Actual Rate 34274 Kbps 9215 Kbps
Attainable Rate 33506 Kbps 9215 Kbps

Interesting that the Actual Rate is faster than the Attainable Rate!

Mostly I see similar figures, but sometimes the upstream rate is lower
at about 7500 Kbits/sec

Do these figures help you?
--
Graham J
Java Jive
2024-07-28 11:22:05 UTC
Permalink
This is a service that was upgraded from ADSL to VDSL on 29 April this
year.  Since the upgrade I've seen re-syncs overnight, generally during
the hours of darkness with a slight preference for times around dusk and
dawn.  The unreliability was not present with ADSL.
The V2763 router always reports "PPP Closed : Remote Terminating (PPPoA)".
Other routers have been tried but give poorer reliability.  I've also
tried all the recommended things like swapping filters and faceplates,
connecting directly into the master socket, and different cables from
filter to router.
Sometimes the connection stays up for several (the maximum has been 8)
days; sometimes it fails 3 or 4 times per night.  Daytime failures are
rare - once per month perhaps.  So I think that a security light or
street light is causing interference.  This is a rural area where
animals such as muntjac deer roam around at night and often trip
security lights.
I know it's not the security light at the user's premises because this
has been disabled for several weeks with no improvement.  So I suspect
something further away.
I can of course report this to the ISP who can then call out Openreach,
so: ....
Has anybody here any experience of whether Openreach can do anything to
their equipment to eliminate this sort problem?
I've just reread the entire thread, and it doesn't seems to be making
enough progress, so I'll try throwing in some thoughts to see if any of
them spark anything in yourself or other contributors ...

1) Your suggestion of a security light is interesting, but I'm not sure
how one would supposedly affect the line, except perhaps by mains
interference from a bad PSU, but the PSU would be on all the time. I
suppose the switching on and off of the light combined with a bad PSU
might cause local mains spikes, but it's not something that I've ever
knowingly encountered, and why would that affect the VDSL line, unless
it affects the terminating equipment at either end? Many security
lights use WiFi, but again that's not something that should affect a
VDSL line, unless perhaps there's a bad connection along it forming some
sort of circuit? [I once had a Sony tape-recorder that picked up Radio
Bulgaria, and included it for free in my recordings - bloody
maddening!] You say it's a rural location, how far away is the green
cabinet from the premises? Would it be possible to mount a camera at
the premises pointing towards it, or at least along the path of the
line, to see if anything is captured, even distantly, such as a security
light coming on? Alternatively, you can buy trail-cams comparatively
cheaply that you might be able to hide near to where you think there's a
problem. My late nephew and his wife did this to gather evidence
against fly-tippers.

2) The night and day difference could be down to something affected by
temperature, rather than actual daylight, perhaps again a bad connection
in a line?

3) In my current home, a switchover between a normal rate and cheap rate
is done remotely by the system, I'm not sure exactly how, but often
these switchovers are not clean, and there are spikes. There are more
of these switchovers during the night than the day, especially in summer
when the heating is off, so there is no load if it's a 'dirty' one.
Kind of fits your pattern, but perhaps not closely, because these would
be events at regular times during the night - note that I'm not saying
these would be regular events, because sometimes the switchovers seem to
be cleaner, sometimes not, rather I'm saying that, if an event were to
occur, it would always be at the particular times that these switchovers
occur. I've not logged these closely, but I know of switchovers around
the following times ...
22:30 - 23:15 Hot water comes on
02:30 - ????? Storage heating comes on
05:30?- 08:30 Hot water
... and there are others for boosting the heating and maybe the
hot-water during the day, but they're more difficult to hear when other
things are going on.

The above is not much, but it's all I can think of right now. Hope it
helps anyway.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Graham J
2024-07-28 18:12:04 UTC
Permalink
Java Jive wrote:

[snip]
Post by Java Jive
I've just reread the entire thread, and it doesn't seems to be making
enough progress, so I'll try throwing in some thoughts to see if any of
them spark anything in yourself or other contributors ...
Thanks.
Post by Java Jive
1)    Your suggestion of a security light is interesting, ...
[snip]

Many existing (i.e. old) security lights incorporate a 500W
Quartz-Halogen lamp, fed from a relay. The inrush current must be
significant, and will generate a strong electromagnetic field. Further,
the relay contacts probably bounce.

I've known ADSL be affected by Christmas tree lights and electric
fences, so EMI from a security light (especially an old one) seems a
reasonable possibility.

The VDSL download sync speed is about 31Mbits/sec which suggests the
green cabinet is about 900 metres distant. It's not visible from the
property.
Post by Java Jive
2)    The night and day difference could be down to something affected
by temperature, rather than actual daylight, perhaps again a bad
connection in a line?
I've plotted the break times by date. The picture shows a good spread
in the 8-11pm and 2-4am range, so consistent with dawn and dusk. I've
been monitoring for about 3 months but as yet there's no evidence of an
underlying seasonal curve. At one point I was ready to blame water
ingress into connection housings, but recent drops have occurred during
the current period of dry weather.
Post by Java Jive
3)    In my current home, a switchover between a normal rate and cheap
rate is done remotely by the system,
[snip]

The problem was still evident when the householder was away on holiday,
and would have switched off heating and the like.

If I'm right that the cause is EMI, is there anything that Openreach
will be able to do about it? Zen tell me that because it is VDSL they
can't get Openreach to increase the SNR margin - evidently this was
possible for ADSL. There's no evidence that the earlier ADSL was
affected, so maybe a filter to reduce the bandwidth? We could live with
a much lower sync speed - 10 Mbits/sec download would be OK for this user.
--
Graham J
Java Jive
2024-07-29 09:06:33 UTC
Permalink
Post by Graham J
If I'm right that the cause is EMI, is there anything that Openreach
will be able to do about it?  Zen tell me that because it is VDSL they
can't get Openreach to increase the SNR margin - evidently this was
possible for ADSL.  There's no evidence that the earlier ADSL was
affected, so maybe a filter to reduce the bandwidth?  We could live with
a much lower sync speed - 10 Mbits/sec download would be OK for this user.
Do you know, or could you find contact details for, any local ham radio
or radio astronomy people? As e-m's usually a curse for them, they
usually know what is about in a given area! Perhaps find a relevant ng,
explain the problem there, suitably anonymised, and ask if anyone is
local to the problem or has local knowledge?
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Java Jive
2024-07-29 11:44:15 UTC
Permalink
Post by Java Jive
Post by Graham J
If I'm right that the cause is EMI, is there anything that Openreach
will be able to do about it?  Zen tell me that because it is VDSL they
can't get Openreach to increase the SNR margin - evidently this was
possible for ADSL.  There's no evidence that the earlier ADSL was
affected, so maybe a filter to reduce the bandwidth?  We could live
with a much lower sync speed - 10 Mbits/sec download would be OK for
this user.
Do you know, or could you find contact details for, any local ham radio
or radio astronomy people?  As e-m's usually a curse for them, they
usually know what is about in a given area!  Perhaps find a relevant ng,
explain the problem there, suitably anonymised, and ask if anyone is
local to the problem or has local knowledge?
Postcode and distance here:
https://rsgb.org/main/clubs/club-finder/

... and, interestingly, ...

https://rsgb.org/main/technical/emc/vdsl-interference-reporting/

... so, given that from their PoV you're from the bad guys, you may not
get much help, but, there again, with a bit of luck, you might! "You
scratch my back and I'll scratch yours"?
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
NY
2024-07-29 10:38:55 UTC
Permalink
Post by Graham J
[snip]
Post by Java Jive
I've just reread the entire thread, and it doesn't seems to be making
enough progress, so I'll try throwing in some thoughts to see if any
of them spark anything in yourself or other contributors ...
Thanks.
Post by Java Jive
1)    Your suggestion of a security light is interesting, ...
[snip]
Many existing (i.e. old) security lights incorporate a 500W
Quartz-Halogen lamp, fed from a relay.  The inrush current must be
significant, and will generate a strong electromagnetic field.  Further,
the relay contacts probably bounce.
Check also LED lights. I had a problem with recordings from one
multiplex of Freeview being corrupted. It took me an embarrassingly long
time to associate this with the hours of darkness when I would have
turned on my GU10 LED lights in my study which is directly below the TV
aerial.

It turned out that two of the bulbs (both the same make) were chucking
out crap at around 482 MHz (PSB1 mux for Belmont). No other muxes were
affected and other makes of lamp were fine at 482. So I moved those
lamps to elsewhere in the house (further from the TV aerial) and the
problem went away.
Marco Moock
2024-07-29 10:41:22 UTC
Permalink
Post by Graham J
I've known ADSL be affected by Christmas tree lights and electric
fences, so EMI from a security light (especially an old one) seems a
reasonable possibility.
If christmas light emit electromagnet signals, get rid off them.
Sadly, such electronics are now common.
--
kind regards
Marco

Send spam to ***@cartoonies.org
Loading...