SFP link debugging

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:

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 :wink:

Does anyone have any tips on how to debug this?

  • Is it possible to see more about the PHY SFP interface from within OpenWRT?
  • Perhaps a way to debug what is happening on the wire?

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.

1 Like