Actually, you can buy a good 2.5g rtl8221 adapter for almost the same price…It also does 1g.
The 88e1111 module will probably also work ok, but you never know for sure until you try it.
If you will be intrested i got few corner cases with using this sfp+ with bpi-r4
1 - SFP-2.5G-T stop receive traffic after software reboot.
For example if i restart bpi with reboot command or restart Wan interface coresponded to this sfp+ module then it can’t receive any packet from ISP Even replug ethernet cable can’t solve this problem Only way to fix it is to replug sfp module from router. Or reboot router with power switch
it is not so critical in real case because i rarely change some settings that need software reboot
i seen some patches that sound similiar but don’t know if its really same problem - [openwrt-24][mt7988][eth][Fix the issue of firmware loss after toggling the interface up and down for the Aquantia 10G PHY] https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/25e6da735931937668f11a5f339dc7b033710d1c
2 - sfp+ speed maximum to 8gbit\5gbit rx\tx
i was not able to achiveve speed over 8gbit receive and 5gbit transfer with iperf3 test I tried this 10gbe sfp+ and also 3meter DAC sfp+.
Same speeds
bpi-r4 cpu load to 25%
Good day! I would like to understand: is it possible to use regular SFP RJ45 for 1Gb? None of the models that I have are suitable: the error is the same:
OpenWrt SNAPSHOT, r26895-d7a76fc351
-----------------------------------------------------
root@OpenWrt:/# [ 51.702912] sfp sfp1: module Molex Inc. 74741-0015 rev A sn 83182063 dc 081113
[ 51.803665] mtk_soc_eth 15100000.ethernet eth2: validation with support 00,00000000,00000000,00000000 failed: -EINVAL
[ 51.814377] sfp sfp1: sfp_add_phy failed: -EINVAL
root@OpenWrt:/# dmesg | grep sfp
[ 12.077394] sfp sfp1: Host maximum power 3.0W
[ 12.082269] sfp sfp2: Host maximum power 3.0W
[ 51.702912] sfp sfp1: module Molex Inc. 74741-0015 rev A sn 83182063 dc 081113
[ 51.814377] sfp sfp1: sfp_add_phy failed: -EINVAL
root@OpenWrt:/#
How can I deal with the above problem?
I am using a LuLeey XPON stick called LL-XS2510.
It was detected in the earlier openwrt versions already, but I could never access the web interface.
Today I figured out that the issue was the auto negotiation for the speed between the R4 and the module. I used ethtool to disable autoneg and set the speed to full duplex and 1000Mbit. Then it all worked.
ISP Modem vs WAS-110 (10G XGS-PON ONU SFP+ Stick)
ISP Modem vs Alcatel-Lucent G-010S-P (2.5G GPON ONU SFP Stick)
Source:
1 Like
I found these heatsinks on AliExpress for the ONU SFP Stick, maybe they will help to reduce the temperature of the ONU SFP module.
AliExpress Links:
Blue Heatsink with Thermal Tape:
- 20x14.5x13mm: Younuon Cooling (10PCS)
- 20x14x13mm: Ai Mengda (5PCS)
Green Heatsink with Thermal Tape:
- 20x14x11mm:
.
They would be placed like this:
Source:
1 Like
Can this 100m SFP+ 10G transceiver work with BPI-R4? Please advise.
I might add that double-sided tape that is applied to those heatsinks from AliExpress is most likely not a thermal transfer tape, but a generic acrylic adhesive tape, which is actually a thermal insulator. Even if it’s labeled as 3M. The real deal from 3M like is the 88xx series tapes. They’re not cheap at all though.
1 Like
By the way, could someone tell me what extra package I need to see the SFP module temperature with the sensors command? On my system it can only monitor the SoC and wireless Phy temperatures.
Just a word of caution do not attempt to upgrade or install to any new snapshot as of OpenWrt SNAPSHOT, r28056-40b8fbaa97 , opkg is no longer working and other than the core functionality not much else is available. I understand that the migration from opkg to apk has been planned for some time, but is now happened, I have also been advised to sit tight till all the packages have been migrated to the new apk. I did read some posts about Attended Sysupgrade being broken, I experienced the same… This is an issue for me (or anyone else) needing ethtool to get their SFP to work - ethtool is not available yet…
1 Like
Just an update on the above - quite a few of the packages are available to install with apk.
1 Like
What command can I use to interrupt the power to the SFP module?
I would like to restart the module together with the BPI-R4 OpenWrt system. I noticed that it remains powered and is functioning normally.
I have already used “ip link set dev eth2 down” but it does not work.
I would like it, like the BPI-R4 and my Huawei MA5671A, to restart periodically.
Afaik sfp power cannot be controlled by software
Hello I am looking for help with bpi-r4 and SFP+ -LRB 10G fiber transceiver - tx1330/rx1270
Problem looks like after software reboot router via ssh with command reboot. I totally lost connection to my ISP. ethtool -m and ethtool -S, ethtool commands says that everything is very good. But it can’t establish connection anymore. It sends packet but receive 0
i am even thinkin about erased firmware of this transiver becouse sound very strange how reboot can affect physical stability
Temperatures was good all time
And now physicall power off router, unplugging transiever or fiber cable nothing helps
Here is few logs:
ethtool -m eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Transceiver type : 10G Ethernet: 10G Base-LR
Encoding : 0x06 (64B/66B)
BR, Nominal : 10300MBd
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 : 1330nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : SFP+-LRB
Vendor rev : 00
Option values : 0x00 0x00
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : XC240131111
Date code : 240131
Optical diagnostics support : Yes
Laser bias current : 32.362 mA
Laser output power : 1.0765 mW / 0.32 dBm
Receiver signal average optical power : 1.2367 mW / 0.92 dBm
Module temperature : 47.91 degrees C / 118.25 degrees F
Module voltage : 3.3932 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 : Off
Laser output power high warning : Off
Laser output power low warning : Off
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 : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 100.000 mA
Laser bias current low alarm threshold : 10.000 mA
Laser bias current high warning threshold : 80.000 mA
Laser bias current low warning threshold : 20.000 mA
Laser output power high alarm threshold : 2.5118 mW / 4.00 dBm
Laser output power low alarm threshold : 0.1122 mW / -9.50 dBm
Laser output power high warning threshold : 1.9952 mW / 3.00 dBm
Laser output power low warning threshold : 0.1412 mW / -8.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 : 4.0000 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 : 1.9952 mW / 3.00 dBm
Laser rx power low alarm threshold : 0.0198 mW / -17.03 dBm
Laser rx power high warning threshold : 1.5848 mW / 2.00 dBm
Laser rx power low warning threshold : 0.0316 mW / -15.00 dBm
ethtool -S eth2
NIC statistics:
tx_bytes: 11461
tx_packets: 76
tx_skip: 0
tx_collisions: 0
rx_bytes: 0
rx_packets: 0
rx_overflow: 0
rx_fcs_errors: 0
rx_short_errors: 0
rx_long_errors: 0
rx_checksum_errors: 0
rx_flow_control_packets: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
rx_pp_alloc_fast: 18818
rx_pp_alloc_slow: 33
rx_pp_alloc_slow_ho: 0
rx_pp_alloc_empty: 33
rx_pp_alloc_refill: 272
rx_pp_alloc_waive: 0
rx_pp_recycle_cached: 0
rx_pp_recycle_cache_full: 0
rx_pp_recycle_ring: 17075
rx_pp_recycle_ring_full: 0
rx_pp_recycle_released_ref: 0
ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseLR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10000baseLR/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
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 bought a SFP+ module ONTi ONT-C11TE-R01 When I try to use it with the latest snapshot it beaks Luci UI … and do freezes in ssh console if I try to call ifconfig. dmesg shows that system identified it as OEM SPF-10G-T rev 02 … and nothing else Any ideas how to deal with it?
PS It seams that the problem with autoneg … after some time it finally interface starts but it shows 10G (ethtool eth1 shows “Speed: 10000Mb/s”) where a client has only 2.5G NIC card. And in dmesg “mtk_soc_eth 15100000.ethernet eth1: selection of interface failed, advertisement 00,00000000,00000000,00006248”
Hello, I’m planning to buy this module to replace my Alcatel G-010S-P which completely lose connection if bpi-r4 perform a soft reboot. Had to re-plug power cable to make it work again.
Can you confirm that your router has no problem establishing PPPoE through this Huawei one after a ‘reboot’ command? Thanks.
So now a solution is implemented in mainline by Russell:
That is great news!
But shouldn’t it report it cannot LINK_INBAND_ENABLE with PHY_INTERFACE_MODE_2500BASEX and maybe PHY_INTERFACE_MODE_1000BASEX ???
1 Like
The patch is afaik (if i understood correctly) only for sfp not supporting in-band-management (daniel told me only some with broadcom phy).
The in-band-management itself should only report link-state,not speed,duplex, etc. Kernel needs to know supported speeds from eeprom,if eeprom does not contain some speeds we have added them (or forced to one) with quirks.
https://lore.kernel.org/all/[email protected]/
From the first series I quote:
Phylink’s handling of in-band has been deficient for a long time, and people keep hitting problems with it. Notably, situations with the way- to-late standardized 2500Base-X and whether that should or should not have in-band enabled. We have also been carrying a hack in the form of phylink_phy_no_inband() for a PHY that has been used on a SFP module, but has no in-band capabilities, not even for SGMII.
When phylink is trying to operate in in-band mode, this series will look at the capabilities of the MAC-side PCS and PHY, and work out whether in-band can or should be used, programming the PHY as appropriate.
net: phylink: add negotiation of in-band capabilities Support for in-band signalling with Serdes links is uncertain. Some PHYs do not support in-band for e.g. SGMII. Some PCS do not support in-band for 2500Base-X. Some PCS require in-band for Base-X protocols.
Simply using what is in DT is insufficient when we have hot-pluggable PHYs e.g. in the form of SFP modules, which may not provide the in-band signalling.
In order to address this, we have introduced phy_inband_caps() and pcs_inband_caps() functions to allow phylink to retrieve the capabilities from each end of the PCS/PHY link. This commit adds code to resolve whether in-band will be used in the various scenarios that we have: In-band not being used, PHY present using SGMII or Base-X, PHY not present. We also deal with no capabilties provided.
So, I understood, here we can tell phylink the pcs does not support inband at 2500-basex and have phylink negotiate if it can link PCS to PHY using this limitation.
I did the same in my crude patch, but this is much better ofcourse. He mentioned a while back he was working on it, so I did not go any further with my patch, waiting for his work to be mainlined.
I have exactly the same issue with this module. After a soft or hard reboot it would occasionally lose link until unplugged and replugged into the router. Like this time:
[ 96.130345] sfp sfp1: module OEM SFP-2.5G-T-R-RM rev 1.0 sn 2405070065 dc 240507
[ 100.866956] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control rx
[ 158.718349] mtk_soc_eth 15100000.ethernet eth2: Link is Down
Does anyone have any tips for troubleshooting it?
Edit.: I’m running the latest mainline OpenWrt.