Could be very useful to include the feature to make that the Mikrotik Routers/Swithches with SFP/SFP+ ports be able to do sequential Single-Byte reads to obtain the transceiver specs and ddm from the EEPROM tables A0h/A2h for transceivers like GPON ONU SFP and others than only supports Single-Byte Reads and not multi-bytes reads (255 Bytes read per call).

Some of this transceivers doesn't have connected the two-wire interface SFP pins directly to the EEPROM, They have connected the 2-wire interface to a slave i2c interface of the SoC and then the SoC have a master i2c connection to the EEPROM.

in other cases the transceiver doesn't have a physically EEPROM and use a virtualized EEPROM allocated on the SPI Flash chip that comes available after the embedded OS is booted.

Implementing the detection of the EEPROM reads to switch automatically between Single-Byte and Multi-Byte reads should not so complex and will gives a plus in the interoperability between the different brands and models of SFP Transceivers apart of to make complies the SFF-8431

for manufacturers as we, would be a very good feature to be added, having in mind that we recommend the Mikrotik hardware to the most of our customers for the wide capabilities and stability of the hardware.

did you have included in the development pipeline this feature?, if not, what do you think? could be included?

+1 I agree

This could be very useful to pull custom data from SFPs. It's clear Mikrotik can't just add support for statistics that every SFP on the market provides, so it's important to have a generic way of access. Memory dump is one way, but it's not script/automation friendly. Read command would be much better.

I would also like to see SNMP support SFP EEPROM reads over OID where last number of OID is the read address. This way you could query SFP bytes over SNMP easily for graphing and statistics.

yes, please mikrotik, that will help!

I agree please mikrotik

+1 - Keep compliant as far as possible.

Please Mikrotik : /

I agree, please mikrotik, as far as possible.

Hello,

We are aware of this topic and SFP feature request, it has been booked and we are researching and considering of implementing it in the future.

Hello,

We are aware of this topic and SFP feature request, it has been booked and we are researching and considering of implementing it in the future.

Thank you, we are looking forward to

+1 I'm looking forward

Hello,

We are aware of this topic and SFP feature request, it has been booked and we are researching and considering of implementing it in the future.

We still looking for this feature. When can it be implemented?

Really useful feature. Mikrotik please

+1 Please MikroTik.
Both Bell and Telus in Canada provide SFP modules having the same issue.
Both MikroTik and EdgeRouter need to fix the same issue.
Whoever fixes it soon, will save thousands of media converters for small businesses.

Situation worsened with release of new router models.
We are talking about SFP-modules based on Realtek RTL8672/RTL9601C chips.
On all new router models and CCRs these modules are detected, but no RX data are transmitted. I had this happen with my new RB5009. However, on the RB760iGS these same modules work fine.
MikroTik Team, please pay attention to this problem.

+1 I agree

On all new router models and CCRs these modules are detected, but no RX data are transmitted. in my CCR1009-8G-1S dont work

On all new router models and CCRs these modules are detected, but no RX data are transmitted. I had this happen with my new RB5009. However, on the RB760iGS these same modules work fine.

I confirm. Apparently this is a software problem with ROS and it will not be difficult for developers to fix it.
Please pay attention for this problem as soon as possible.
Thank you.

Currently dealing with this issue as well with a Bell GPON SFP in my CCR2004.

Disappointed that this hasn't been implemented. Any updates about if it is still being looked at?

Set camp here to see my FS ONU sfp module where the issue can be fixed or not.

What's new in 7.8beta2 (2023-Jan-20 12:27):

*) sfp - fixed reading of SFP EEPROM on single SFP port devices;

I took the leap.

CCR2004 with ALCATELLUCENT GPON module from Bell. Usually end up with a FAN fail error within a few minutes of startup due to the SFP issues.

Currently at 11 minutes uptime with no fails yet. Module stats are still updating in interface list and system health is also still updating. Now just to wait and see if this does finally resolve this issue.

Nope. Lasted a decent bit, however it ended up locking things up again and actually causing the SFP to lose connection and take the link down in the process. Reboot didn't help.

Downgraded to 7.7 and the link is back up but health monitoring failed. Close but not quite.

HI Chris
you mean that with 7.7 , at least the link is uo again and 'only' the health monitoring was KO ?
for how long was the link stable? few hours or multiples days? without making the CCR2004 going crazy with red light fault....
pascal

Nope. Lasted a decent bit, however it ended up locking things up again and actually causing the SFP to lose connection and take the link down in the process. Reboot didn't help.

Downgraded to 7.7 and the link is back up but health monitoring failed. Close but not quite.

Hi,
I'm going to take a guess that this is the problem related to my post viewtopic.php?t=191627 or viewtopic.php?t=186200 (I've recently RMA'd the CCR2116 as well and same issue keeps happening). That being said, I did upgrade to 7.8B2 and it solved the PSU health issues. But I am having the same problem as Chris -- SFP interface drops connection, after maybe ~10 minutes.

Seems 7.8B2 still isn't the proper fix to solve the issue. Unfortunately the CCR2116 is still a 1600$ CAD brick for the moment in my use case

HI Chris
you mean that with 7.7 , at least the link is uo again and 'only' the health monitoring was KO ?
for how long was the link stable? few hours or multiples days? without making the CCR2004 going crazy with red light fault....
pascal

Nope. Lasted a decent bit, however it ended up locking things up again and actually causing the SFP to lose connection and take the link down in the process. Reboot didn't help.

Downgraded to 7.7 and the link is back up but health monitoring failed. Close but not quite.

On 7.7 and the last 7.6 beta the link is basically rock solid however health monitoring fails within minutes. So no line stats and no health monitoring for the entire duration with the exception of the first minute or so. The irritating side effect is that the fans constantly spin up to max and then down to min every 5 or 10 seconds and the fault light is on.

Hi,
I'm going to take a guess that this is the problem related to my post viewtopic.php?t=191627 or viewtopic.php?t=186200 (I've recently RMA'd the CCR2116 as well and same issue keeps happening). That being said, I did upgrade to 7.8B2 and it solved the PSU health issues. But I am having the same problem as Chris -- SFP interface drops connection, after maybe ~10 minutes.

Seems 7.8B2 still isn't the proper fix to solve the issue. Unfortunately the CCR2116 is still a 1600$ CAD brick for the moment in my use case

Same here, start with 2004 with gpon and got the issue, then I change to 2116 but the same issue. Frustrated.

I installed the 7.8rc release on my CCR2004-16g-2s+ yesterday. After the first boot up there seemed to be some issues between the GPON module and the router on the link speed negotiation. I changed it to auto and then back to 1gig full duplex fixed speed and everything came up after a reboot. I also pulled the module and reinstalled it in order to force a full power off reset of the GPON module.

As of now the connection has been stable for 23 hours and health monitoring has continued to work. Time will tell however it looks like they have at least started to address part of the problem...

If anything changes I'll post an update.

And it failed again… traffic is still being passed but health monitoring has failed and no stats being reported from gpon…

I know what I'm testing today

Hi there this thread has gone quiet does this mean problems solved or is everyone waiting for a solution?

Richard

At last, after many years Mikrotik includes in the new beta6 of RouterOS 7.14 the most awaited feature for GPON ONU SFPs, the sequential single byte reads for the I2C bus, used for reading the EEPROM of the SFPs to obtain module specifications and details from the DDM section (Digital Dianostic Monitor)

https://mikrotik.com/download/changelog ... lease-tree
It's time for testing.

What extra info is expected (Temp, Rx, Tx and etc)?

This fixes being able to read any data from SFPs which do not correctly handle multi-byte I2C read requests correctly.

The actual data, and location thereof, is specified by https://members.snia.org/document/dl/25916 - some is mandatory, some is optional and some is vendor-specific. Mikrotik decode and display some of this, they haven't indicated any changes.

Hi!
I installed the latest beta 7.14beta8 on my hap ac (RB962UiGS-5HacT2HnT).
I use SFP ONU C-DATA FD511GX-RM0 with firmware: V2801F_V1.9.0-220425 working on CPU: RTL9601CI.
But couldn't see EEPROM DATA in Mikrotik interface.
And I continue have a problem if I reboot or disconnect power my router - No link. I need physical reconnerc SFP from fix it. Sorry if I'm writing in the wrong topic. I can't post in the update 7.14 discussion

And I continue have a problem if I reboot or disconnect power my router - No link. I need physical reconnerc SFP from fix it.

I have tried with TWCGPON657 with C00R657V2801F_V1.9.0-220404.tar firmware, and... still need reattach the PON Stick in order to work, yet no EEPROM data is shown

And I continue have a problem if I reboot or disconnect power my router - No link. I need physical reconnerc SFP from fix it.

I have tried with TWCGPON657 with C00R657V2801F_V1.9.0-220404.tar firmware, and... still need reattach the PON Stick in order to work, yet no EEPROM data is shown

In the latest RouterOS versions (Beta 7.15.x), an "Ignore Rx LOS" option has been introduced under the SFP tab in the Interfaces section. This feature addresses the issue with devices failing to establish the SFP Link UP after a router reboot, effectively resolving the connection problem.



Additional Note: If you discover that the EEPROM information is absent in Winbox, despite utilizing a recent RouterOS version, this suggests that the transceiver's EEPROM lacks the necessary data. To remedy this, you will need to manually enter the information into the EEPROM of the transceiver. For devices with a Realtek SoC, this can be achieved through the i2c command, accessible from the "diag" submenu when connecting to the SFP via telnet.

Additional Note: If you discover that the EEPROM information is absent in Winbox, despite utilizing a recent RouterOS version, this suggests that the transceiver's EEPROM lacks the necessary data. To remedy this, you will need to manually enter the information into the EEPROM of the transceiver. For devices with a Realtek SoC, this can be achieved through the i2c command, accessible from the "diag" submenu when connecting to the SFP via telnet.

What i2c commands to use to show Tx, Rx, Temp ,etc... for ODI and similar Realtek chipsets?

I found out that on my hAP ac with routerOS 7.15.1 the C-DATA FD511GX-RM0 works without a replug with the following settings:
- enable the auto negotiation on Ethernet section
- remove all advertised speeds and add 1Gbase-X only
After that unplug the router, wait 10 sec and plug it back in. It starts normally after cold boot with these settings.

I also enabled Ignore RX LOS but that does not seem to make any difference in my case.

ADD: With auto negotiation disabled I have the "link ok" but no actual data transfer. That behavior is different with hex S and the same SFP module, there I had no issues with auto negotiation disabled and speed forced to 1Gbase-X.