Yes, I’ve already done that. I’ve opened all the Firewalls, I’ve done it and redone it. And I still don’t have access.
Are you sure you don’t need the converter for this method of accessing the module?
I can’t figure out what’s wrong.
Watch these videos:
1 Like
do you have a “link detected: yes” on your SFP (cable connected)? have you a local IP-Adress from same subnet as your sfp webinterface? can you make a local ping and http request (telnet/curl) from r4 to the webinterface of the module?
1 Like
It worked!! 
Everything worked!! With internet access on the module already connected to the BPI-R4.
After I got access to the SFP module, I configured the MAC, Password, LOID, GPON SN, VLAN. As in the tutorials. And it worked immediately.
I’m doing PPoE access on the Openwrt image on the BPI-R4, out of personal preference, but I know I could do it on the SFP module.
My problem is that when I was accessing the SFP module, I was setting up the interface, but when I set up the WAN bridge, it worked. I think it was a firewall.
Thanks for your help!
1 Like
Are you able to explain how the OP was able to get the MA5671A module to work in the BPI-R4’s SFP+ port given that the BPI-R4 documentation states “ The SFP serdes speed of BPI-R4 is fixed at 10Gbps, so only SFP that support this can be used”?
It is my understanding that the MA5671A only negotiates at 1G or 2.5G.
By the way, my ISP provides a G-010S-P that I would like to use in a BPI-R4 that I have ordered by not yet received. My provided network speed, from ISP, is 1.5G. So ideally, I would like to establish a 2.5G negotiated link between the BPI-R4 and the SFP module. Will I run into issues?
I also have a 2.5G module from luleey for GPON.
It didn’t work at first, because it tried to auto negotiate the speed of the interface between SFP and CPU.
I set it fixed to 1G, because my internet connection is only 500 MBit.
I could try to set it to 2.5G to test if that would work as well.
Thanks. Do you have a link to a tutorial on how to fix the speed?
The command I use is
ethtool -s eth2 speed 1000 duplex full autoneg off
which forces the speed to 1000MBit, full-duplex mode and disables auto negotiation.
I just tried with 2500 instead of 1000 but it didn’t work for my device, even though it is a 2.5G SFP module.
To see the supported modes use
ethtool eth2
and look for
Supported link modes: 1000baseX/Full
in the output.
To automate the process on boot I initially added the command to /etc/rc.local, but after seeing the SoC switch being reset by the kernel at runtime, I needed a different solution.
Instead, I now use a script in /etc/hotplug.d/iface/10-sfp, which automatically executes when the eth2 device comes up (again) at any time while the system is running.
#!/bin/sh
[ "$ACTION" = ifup -a "$DEVICE" = eth2 ] || exit 0
logger -t sfp "Force 1Gbps full-duplex on SFP module (eth2)"
ethtool -s eth2 speed 1000 duplex full autoneg off
@frank-w any idea why I don’t see the 2.5G option on eth2 for my module?
Because for eth1 it looks like this, without a plugged SFP module though.
Settings for eth1:
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
Should be same for eth1 and eth2 on r4 as there are same macs for both…(r3 is different in this manner where second sfp is connected to switch not sfp). Can you show output for eth2 for same state (only no sfp)? Afair i had fewer options for both when no sfp is connected…this is maybe driver bug (creating the mac with fewer options)
I didn’t make any speed settings, I left it on automatic. It looks like this:
It shows the same options for eth2 and eth1 when I remove the SFP module.
So, either the SFP module can’t deal with 2500Mb/s or a driver issue. Because according to the manufacturer it should support it.
What is the model of your SFP module that is not being recognized?
It’s this one 2.5G XPON STICK SFP ONU - LuLeey
According to name and specs it should support 2.5G. But in the SFP+ port of the R4 it doesn’t.
Not sure if the issue is SFP+ or the realtek chipset inside and the corresponding driver on the kernel side.
This one looks like it is the same as the ODI DFP-34X-2C2. Can you post the output of ethtool -m eth2 ?
Here you go. What information are you looking for? It doesn’t seem to properly load the EEPROM though, because I changed some of those values in the webinterface, but those changes are not reflected here.
The chipset is a RTL9601D according to sources I found.
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 0x22 0x00 0x01 0x00 0x00
Transceiver type : Ethernet: 1000BASE-LX
Transceiver type : FC: intermediate distance (I)
Transceiver type : FC: Longwave laser (LC)
Transceiver type : FC: Single Mode (SM)
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
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 : OEM
Vendor OUI : 00:00:00
Vendor PN : XPON-Stick
Vendor rev :
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 : XPONXXXXXXXX
Date code : 231127
It probably is a clone of ODI DFP-34X-2C2/3. The issue with this stick is that it advertises 1000base-LX support and sets the bitrate to 1300MBd in the EEPROM, which makes linux see is as a 1Gbit device. This behavior can be changed either by adding an sfp quirk for your device and recompiling the kernel, or editing the EEPROM and changing the relevant bytes.
I followed this post to set the correct values to the EEPROM and now it is detected as a 2500baseX device: Right SFP EEPROM config for DFP-34X-2C2 to work automatically work at 2500base-X? · Anime4000/RTL960x · Discussion #250 · GitHub
Basically, you have to remove the bit that advertises support for 1000base-LX, and set the nominal bitrate to 3100MBd instead of 1300. Note that after doing this change, the device will probably only work at 2.5gbe and it will not be recognized if you use it in a 1gbit media converter etc.
Thanks. This is so bad.
I checked out your link and found this: https://github.com/Anime4000/RTL960x/blob/main/Docs/FLASH_GETSET_INFO.md#lan_sds_mode
Have you tried changing this value instead of changing the eeprom directly?
Personally, I would prefer if I could change the eeprom to announce the correct speeds. 1G and 2.5G.
<4>change mode to 7(SGMII Force)
<4>change mode to 1(Fiber 1G)
<4>change mode to 3(SGMII MAC)
<4>change mode to 4(HiSGMII PHY)
<4>sgmii mode is 7
<4>change mode to 7(SGMII Force)
I wish there was an open-source firmware for those devices. or even easier, an option to run it inside the OpenWrt on the R4 instead of the SFP module.
Yes, I tried modes 4,5,6 (the default was 0 on mine which just tries the modes one by one until it finds a suitable one). It made no difference.
It is very easy to change the eeprom values with i2c-tools, but of course there is a risk of losing access to the module. You don’t need the program mentioned in the link I posted, if you don’t change the checksum, you will get a message in the kernel log that will state that it is wrong and which value is the correct one. So what I did was:
i2cdump -y X 0x50
where X is 0 to 5, until I got the output from my gpon stick. This is just to find the correct bus (the eeprom address is 0x50). In my case, for the wan sfp port, the bus number is 3, so i2cdump -y 3 0x50 prints the contents of the eeprom. Then:
i2cset -y 3 0x50 0x06 0x00 (removes the 1000base-LX advertisement)
i2cset -y 3 0x50 0x0c 0x1f (sets nominal bitrate to 3100MBd)
Then I removed and reinserted the sfp and I got the kernel message:
sfp sfp1: EEPROM base structure checksum failure: 0x81 != 0x71
so I just set the correct checksum (byte 0x3f) with:
i2cset -y 3 0x50 0x3f 0x81
Now the stick is identified as 2.5G:
root@OpenWrt:~# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 2500Mb/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: no
The issue I have with bpi-r4 is that I cannot access the stick on its IP address, the eth2 link remains down, whereas if I use a 2.5G media converter or put it in my other router (turris omnia), it is accessible.
The auto negotiation is broken, at least for my module. I use ethtool to force it to the 1Gbps speed full duplex. You should do the same for 2.5Gbps I guess.
What I’d rather have is that it advertises both modes. And that I can then use both modes.
I think the auto negotiation being broken is just another issue that we might or might not figure out. Could be the realtek chip. Or the eeprom not being correctly setup for the kernel to figure things out.
According to linux/drivers/net/phy/sfp-bus.c at v6.6 · torvalds/linux · GitHub , lines 308-340, setting one of the fiber channel bits for 100/200/400 speed or setting the correct min/max bitrate in the eeprom, should make both 1000base-x and 2500base-x available, I might test this when I get home.