I’d recommend not configuring the ssh interface unless you really want to connect to it right now. The OpenWRT on there is horrendously insecure and ancient, so better not expose it in any way.
10G is wrong though, the module by default runs in 1G mode, and can be configured to 2.5G mode, but host support for that mode is uncertain, and setting that mode is immediate and irreversible. If you are trying to access it like it’s a 10G SFP module, there’s your issue right there.
Was this from a reboot? It takes longer then that for the sfp to finish boot, so was it booted before, or was this too soon?
Depending on how long BL2 and uboot took to load, and how long of a timeout is set in uboot, this could be right on time actually.
Forgot those seconds 
Now just set it to sgmii/1000base-x
Thanks for the quick answer. The eth2 is configured to MII and eththool says it only supports MII:
Settings for eth2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
10000baseT/Full
2500baseX/Full
1000baseKX/Full
10000baseKX4/Full
10000baseKR/Full
1000baseX/Full
10000baseCR/Full
10000baseSR/Full
10000baseLR/Full
10000baseLRM/Full
10000baseER/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10000baseT/Full
10000baseKX4/Full
10000baseKR/Full
10000baseCR/Full
10000baseSR/Full
10000baseLR/Full
10000baseLRM/Full
10000baseER/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: MII
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
ethtool looks like this for me, on 6.10.8-bpi-r4-main, which if Franks 6.10-main tree rebased on top of 6.10.8.
# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Have you already set the correct speed?
Assuming you have done already:
ip link set eth2 up
Sometimes a bug is found after doing:
ip link set eth2 down
ip link set eth2 up
Did you already see sgmii or 1000base-x in the line:
[ 13.575165] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
Donnow if this is activated in your openwrt, but you may get more useful dmesg output after:
echo "file drivers/net/phy/* +p" > /sys/kernel/debug/dynamic_debug/control
Also strange there is no 1000base-x in:
But not sure if this is a problem when autoneg is off. You could try setting it manually:
ethtool -s eth2 advertise 0x20000000000
I remember reading somewhere that the OpenWRT build only supports 10G sfp module, but I don’t recall the reason or how to remedy it. On normal Linux the module just worked out of the box, with the kernel auto-negotiating the speed and mode with it.
I have a spare SD card so i will try to build the Debian images and have a look if it works there. Do you mind sharing what image you used or the build options?
The speed is read from eeprom, negotiation is turned off.
I also do not use openwrt, and I really don’t know, of all different version out there, which one suipports what. Hopefully eventually all is supported.
I’m running Gentoo on mine, so there is no image or anything I could provide. But anything running Franks latest 6.9/6.10/6.11 kernels should just work.
Hi,
sorry for not answering for a few days. I had some hard deployments at my job.
In the meantime i tried different things… But I just hit my lowest point and tried to bridge the other mosfet of sfp1. And the same thing: nothing.
Then i tried to configure eth2 again insted of eth1 and now i got some output of ethtool -m eth2 
root@OpenWrt:~# ethtool -m eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-LX
Encoding : 0x03 (NRZ)
BR, Nominal : 1200MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 20km
Length (SMF) : 20000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : ZYXEL___________
Vendor OUI : 00:00:00
Vendor PN : PMG3000-D20B____
Vendor rev : V1.0
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : S234107503784___
Date code : 150525
Optical diagnostics support : Yes
Laser bias current : 15.194 mA
Laser output power : 2.0000 mW / 3.01 dBm
Receiver signal average optical power : 0.0000 mW / -inf dBm
Module temperature : 41.85 degrees C / 107.33 degrees F
Module voltage : 3.3000 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : On
Laser output power high warning : Off
Laser output power low warning : On
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : On
Laser rx power high warning : Off
Laser rx power low warning : On
Laser bias current high alarm threshold : 90.000 mA
Laser bias current low alarm threshold : 0.000 mA
Laser bias current high warning threshold : 70.000 mA
Laser bias current low warning threshold : 3.000 mA
Laser output power high alarm threshold : 3.1622 mW / 5.00 dBm
Laser output power low alarm threshold : 1.0000 mW / 0.00 dBm
Laser output power high warning threshold : 2.8183 mW / 4.50 dBm
Laser output power low warning threshold : 1.1220 mW / 0.50 dBm
Module temperature high alarm threshold : 100.00 degrees C / 212.00 degrees F
Module temperature low alarm threshold : -50.00 degrees C / -58.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -40.00 degrees C / -40.00 degrees F
Module voltage high alarm threshold : 3.6000 V
Module voltage low alarm threshold : 3.0000 V
Module voltage high warning threshold : 3.5000 V
Module voltage low warning threshold : 3.1000 V
Laser rx power high alarm threshold : 0.1995 mW / -7.00 dBm
Laser rx power low alarm threshold : 0.0015 mW / -28.24 dBm
Laser rx power high warning threshold : 0.1584 mW / -8.00 dBm
Laser rx power low warning threshold : 0.0020 mW / -26.99 dBm
I am confused, but happy.
I can confirm the 2.5G copper SFP works just fine on both the stock BPI image and OpenWrt snapshot.
You mean this specific Zyxel modem? Or some other unrelated SFP module? Cause of course it generally works, but I don’t know if this module correctly expressed the changed link speed. If it for some reason does not work, the module is useless until you find a device that does speak 2.5G with it, to change it back to 1G.
Yes, I mean 2.5G SFP modules in general, as whether they are supported by the hardware is not well communicated in the official documentation. Sorry I didn’t get that you were asking about the specific one.
Bring this threat back to life. I suspect lots of pon or xgspon sfp modules are going to suffer from the same exact issue. Not keen to physically bridge the mosfet. Any software based hacks/patches/boot parameters?
Quote" Ok, I have managed to make this module at least work. The issue from my observation: It has a really long boot-up sequence, and only AFTER that sequence, it pulls the MOD_DEF0 pin low.
The problem: While that pin is not pulled low, the circuit of the BPI-R4 board itself does not turn on the power supply for the SFP module. There’s a mosfet that prevents it."
It cannot be circumvented by software. The logic is implemented via circuit, the software sees the module for a split second, and then it vanishes to never come back. The BPI-R3 had no such circuicy, and any other bit of SFP hardware I tested doesn’t either. The module only does not work in the stock BPI-R4. And given the circuit diagram for the R4 has a place for a brige in place of the mosfet drawn into the diagram, I highly assume this was at least to some degree accounted for. There are no ill effects to replacing the mosfet with a bridge. Other than the status LED being permanently lit.