I have a VDSL (G.993) connection to my home.
I have brought and previously successfully used this SFP VDSL modem on my Turris Omnia (an OpenWRT Linux based router): https://www.versatek.com/product/vx-160ce-vdsl2-sfp-modem-remote-telco-grade/
This set up worked on a similar connection with the same ISP at the same speed rating on a different telephone exchange (in the same country):
However, I've now moved house and the SFP modem is unable to successfully negotiate a link (LED 2 flashes, intermittently fast).
The vendor supplied consumer grade router works flawlessly. Here are the log lines showing successful link negotiation:
Jan 1 00:00:19 syslog: [ 19.874000] Line 0: xDSL G.994 training
Jan 1 00:00:21 syslog: [ 21.878000] Line 0: ADSL link down
Jan 1 00:00:47 syslog: [ 47.889000] Line 0: xDSL G.994 training
Jan 1 00:00:56 syslog: [ 56.896000] Line 0: VDSL G.993 started
Jan 1 00:01:14 syslog: [ 74.931000] Line 0: VDSL2 link up, Bearer 0, us=9995, ds=39994
Jan 1 00:01:30 syslog: DDNS update successful
Jan 1 00:01:31 syslog: ptm0.1 - WAN link UP.
Unfortunately, on the Turris Omnia with the SFP, the OpenWRT logs do not help much: I'm fairly sure link negotiation happens within the SFP itself which then presents the negotiated link to Linux as PHY.
Because of this, the finance department (the wife) wonders whether £300 spent on a router was a good use of company funds ;)
Does anyone have any tips on how to debug this? Perhaps a way to debug what is happening on the wire? Can I get more relevant information about the physical device through the command line?
The problem could be something as simple as a poor connection to a pin on the SFP or, as I suspect, it may be due to incompatible equipment at the exchange.
I searched online for DSL tap and couldn't find anything that would help. I am not a professional network engineer; any tips on how to take debugging of this further would be most appreciated.
