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
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.
I highly doubt it. The BPI-R4 is the first device I have ever seen that employs such an odd setup.
The R3 for example simply does not have any such setup, and just permanently powers the modules.
As does every Switch or Media-Converter I could get my hands on (meaning, the GPON module booted up fine in them).
If the LED is not permanently lit, something went wrong with the solder mod.
Cause it lighting up permanently is a direct result of the modules power circuit now being permanently powered.
Given it’s lit up in the picture, I guess it’s just a typo?
When the LED is brightly lit all the time, power is being supplied fine, and the issue with the module lies elsewhere.
Come to think of it, when I plugged in the module the first time, there did seem to be a short bright flash. But I had already assembled the case and played it off as my fatigue/imagination.
Do you maybe have a working non-OpenWrt image that you could please share? So I can test this further. (A tutorial to build one myself would be great, too.)
edit: oh. the first result on google is literally your gentoo tutorial XD
If you have the exact same model, yes. It’ll show up without being hooked up to an actual fiber network.
The light being dimmly lit up is also the result of the module itself pulling the def0 pin high, but not as “strong” as normally, so a little bit of power is let through by the moset, resulting in the dim LED.
The initial short bright flash is also a result of the module controling that in software. It boots up, and very early in the boot sequence, like milliseconds into it, stops pulling the pin low, and effectively disconnecting itself from power.
Why that does result in a flickering of it powering down, the pin going back low, and it booting up again… I’m not sure.
Uff, turns out it’s an issue with OpenWrt seeming to have broken something in 24.10 (incl. snapshot @ 6.6.74 now).
I have no clue what (just that it definitely isn’t the renaming of eth{1,2} to sfp-{l,w}an), but with Sinovoip’s 20240620 build (21.02 @ 5.4.271) the module does show properly in dmesg & ethtool -m eth2 returns everything.
I’m not surprised, OpenWrt’s BPI-R4 support so far is horribly broken. Wifi is likewise nonfunctional in snapshot. Though while there’s this custom build that ‘fixes’ the latter through mtk 24.10 patches (which also return eth{1,2}), the module is still AWOL in it (No such device).
edit: Or is there anybody who has it still working with 24.10+?
Thanks, but it still doesn’t show in dmesg or elsewhere. ethtool -m sfp-wan even shows netlink error: No such device. (i2cdump is not present.)
What’s curious since soldering (regardless of image used) is just how hot the device gets. I guess once my 2.5G RJ45 module is here and both SFPs actually process data, I can use the R4 as heater.
Yeah, I just didn’t expect that to happen even when it’s disconnected/idling on standby. Makes me wonder how full 48-SFP-port switches handle it, but I suppose it’s but another reason why datacenters are insanely loud.
Anyway, for quirks, do you happen to know whether the format needs to be…
