Support for GPON SFP FGS202

Linux handles SFP modules via

  • sfp-bus.c [1]

    • probes the module's eeprom_id through EEPROM dump and mainly:

      • guesses and sets the port type
      • guesses and sets link modes
      • guesses and sets phy_interface_t mode
      • informs the SFP socket that the network device is now up, so that the module can be enabled by allowing TX_DISABLE to be deasserted
      • inform the SFP socket that the network device is now up, so that the module can be disabled by asserting TX_DISABLE, disabling the laser in optical modules

      Commonly it prints in the syslogs something like

      sfp: module Technicolor AFM0002 rev 1.0 sn U7L8C002676 dc 03-12-18
      sfp: SC connector, encoding NRZ, nominal bitrate 1.3Gbps +0% -0%
      sfp: 1000BaseSX- 1000BaseLX+ 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
      sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
      sfp: Wavelength 1310nm, fiber lengths:
      sfp: 9µm SM : 20000m
      sfp: 62.5µm MM OM1: unsupported/unspecified
      sfp: 50µm MM OM2: unsupported/unspecified
      sfp: 50µm MM OM3: unsupported/unspecified
      sfp: 50µm MM OM4: unsupported/unspecified
      sfp: Options: txdisable, txfault, los+
      sfp: Diagnostics: ddm, intcal, rxpwravg
      sfp: SFP module encoding does not support 8b10b nor 64b66b

    If that probe fails the module will not work.

  • sfp.c [2]
    • performs state machine checks for signal status (asserted / dessarted) for RX_LOS and/or TX_FAULT

    • may print in the syslog:

      sfp: module transmit fault indicated

      relating to the signal status of TX_FAULT (tx-fault in hi IRQ), in which case tries to clear (recover) the fault fives times in total, pausing one second between each attempt and if successful (tx-fault in lo IRQ) prints

      sfp: module transmit fault recovered

      If the five attempts are however exhausted it prints

      sfp: module persistently indicates fault, disabling

      and as a result there is no WAN connectivity. Signal status detection is only attempted again if the interface is being restarted, else the link will remain a down state.

userland for debugging:

  • mii-tool is not suitable for modules that do not have a PHY; the “PHY” registers are emulated, and are there just for compatibility
  • ethtool is better suited and common go to
  • cat /sys/kernel/debug/gpio for modules with GPIO, debugfs enabled and being mounted
  • gpiodetect | gpioinfo from gpiod-tools
  • if the I2C GPIO expander is interrupt capable watching cat /proc/interrupts | grep sfp could help in debugging efforts

developer (R. King) currently looking after SFP.C development at Linux source provided this shell code loop routine to monitor the tx-fault signal state changes reported from the module to the kernel (eth2 being the CPU port facing the SFP cage in this particular node design).

ip li set dev eth2 down; \
ip li set dev eth2 up; \
date; \
while :; do
  cat /proc/uptime
  while ! grep -A5 'tx-fault.*in  hi' /sys/kernel/debug/gpio; do :; done
  cat /proc/uptime
  while ! grep -A5 'tx-fault.*in  lo' /sys/kernel/debug/gpio; do :; done


Wondering whether there is a difference between the (potentially subsided?) module provided by an ISP and one that is procured from independent vendors, or the pin 6 issue being a general violation of the SFP MSA instead?

Could not find a data-sheet for the module that exhibits the pin layout/definition but if indeed violating the SFP MSA it would explain why it does not work since sfp-bus.c and sfp.c adhering to SFP MSA conformity.

Supposedly it is not necessary to fiddle with the hardware but instead correct the respective GPIO line to change the offending pin for compliance. Probably gpioset from gpiod-tools will be useful for that purpose.

Incidently stumbled upon this blog [3] and there is no mentioning of needing to fiddle with the hardware to get the module working a in switch device, though not clear what sort of OS that switch is leveraging.


Hi guys,
Thanks for your valuable answers, this helped me a lot.
I finally got it working after hardcoding phylink to 1000baseX_Full in sfp-bus.c

There is a host up at with ssh port open, however I could not guess any credential to authenticate.

How did you do that? I've tried a lot but not managed to ping any of the 192.168.x.x IP, do you have a GPON line connected to it? Do you access from LAN or WAN/OLT management?

Sorry I was wrong, this IP was actually my host :expressionless:
So.. no I did not find an open port on this device.

I noticed your answer on the subject of MA5671A

Do you think it is possible to create a bootloader for FGS202 that would give us access to the prompt FALCON =>
It would then be sufficient to tape pin10 with tape and change the serial number without soldering.

No... the FGS202 doesn't seem to use Linux unlike the MA5671A which use OpenWRT

There are a lot of SFP modules on sale nowadays that better dissipate heat and are easier to configure. In order to achieve full compatibility you need access to MIB files.

The ITU G.988 specification defines them as follows:

A protocol-independent MIB describes the exchange of information across the OMCI. Clause 8 lists the managed entities and illustrates key relationships between them to implement some of the important features that may be offered by ONUs.

During registration in addition to SN and password, ONT also transmits Vendor id(SCOM), ONT Version(SCOMFGS202v1), Equipment id(FGS202)

#Managed Entity 256(ONU-G)
256 0 SCOM SCOMFGS202v1\0 00000000 0 0 0 0 0 #0
#Managed Entity 257(ONU2-G)
257 0 FGS202\0\0\0\0\0\0\0\0\0\0\0\0\0 0xa0 0x5345 1 1 64 64 1 128 0 0x007f 0 0 48

More in-depth information in the document

For your firmware, it is possible to view MIB after image extraction 0x100000-0x2A0CE7 and endiannes change
user@SFP:~# xxd -e -g4 extracted.bin | xxd -r > reversed.bin
user@SFP:~# strings reversed.bin > reversed.txt

1 Like

do you know how I can add a GEM multicast to MIB file? I have an Alcatel-Lucent SFP but it doesn't do GEM multicast, I tried various value but without luck

Wow, didn't know this was caused by endianes, thanks!

on my FGS202, some multicast streaming works like udp://@ but the udp://@ doesn't, my ISP provided ONT works with both so I don't know what went wrong with the FGS202, do you have any clue? They use GEM port multicast

The new version of the firmware SCOMFGS202115 is distributed among French users.
Does anyone have an image of this firmware or a change log?

its working very well.

Thanks for all information , do you have HD picture ?

Alright... I got a job at an ISP and got access to OLT now... but I still can't figure out how to access the CLI of it from the OLT side, anyone have any idea? the ONT SFP seems to registered and dial PPPoE fine.

Yeah... I've been messing with it for a while and still couldn't find such option, it's a GCOM GL5610 OLT, a random branded Chinese which have no documentation, a pretty similar to Cisco CLI but there's next to no context help, there doesn't seem to have command to add Management IP or such...

Is it just an interface that the SFP ONT is listening on the WAN side? can I just bridge a PON port via L2 to an eth interface on the OLT and access the ONT CLI by the IP while plugged into said eth port?

Hey guys! Does anyone know if this works with EPON providers?

I think what I need to change to make it work with my provider is the MAC address and possibly the SN, LOID user and pass and PLOAM pass. I can desolder the flash chip and put it on my CH341a but I do not know what I have to do next to change the values mentioned above. Can anyone help?

EPON needs different management stack and has also differences in the physical layer. The chip in this device was only designed for GPON (ITU G984)

Is it a HW or SW limitation? Can the SW be edited to allow EPON?

No, the chip is designed only for GPON