UFiber UF-Instant management interface appears to go down shortly after reaching O5 state

[zhongfu]

I've got a UF-Instant running:

• kernel from official fw version v4.3.1.913-d48.210415.0811
• modified rootfs from https://github.com/stich86/UF-Instant-Mod (rootfs_MOD_UFINST_220505)

It's installed in a SFP+ port on a CCR2004-1G-12S+2XS.

After configuring the UF-Instant to match my ISP's Huawei HG8240T5 ONR and rebooting, it seems like the management interface goes down and the UF-Instant stops responding to pings or telnet to 192.168.1.1.

Removing the fiber cable and rebooting allows the stick to be reachable again, while inserting the fiber cable causes it to become unreachable shortly after the ONU state reaches O5 (as seen with while sleep 1; do diag gpon get onu-state; done).

This leads me to suspect that it's because of something being pushed from my ISP through OMCI, though the nature of the issue makes it quite difficult to debug.

Is there a way to... prevent this from happening, somehow? Thanks!

[Anime4000]

To diagnose this issue, you'll need to dump the OMCI log and identify which MIB is causing the problem.

For instance, the D-Link DPN-FX3060V (RTL9607DQ) has an ISP-specific OMCI MIB 517 that impacts the /bin/startup script:

 iVar2 = read_pid("/var/run/boa.pid");
 if (iVar2 < 0) {
   iVar2 = mib_get(0x205,&local_10);
   if (iVar2 == 0) {
     uVar1 = va_niced_cmd(&WEBSERVER,0,0);
     local_c = local_c | uVar1;
   }
   else if (local_10 == 1) {
     uVar1 = va_niced_cmd(&WEBSERVER,1,0,"-n");
     local_c = local_c | uVar1;
   }
   else if (local_10 == 2) {
     uVar1 = va_niced_cmd(&WEBSERVER,1,0,"-s");
     local_c = local_c | uVar1;
   }
   else {
     uVar1 = va_niced_cmd(&WEBSERVER,0,0);
     local_c = local_c | uVar1;
   }
 }

In this case, the OLT pushes MIB 517, causing the WebGUI to be killed.

It's possible that your OLT is doing something similar. Alternatively, MIB 171 might be causing the SFP stick to be disabled. This can happen for two reasons:

1. The OLT pushes MIB 171 at ME Point UNI LAN 1, instructing br0 to remove eth0, as the SFP interface is bound to br0, not eth0.
2. The OLT pushes MIB 171 at ME Point UNI LAN 2 or another port, causing the SFP to lose connectivity to the SFP host because the SFP interface is only mapped to UNI LAN 1. This behavior is similar to the MA5671a.

Identifying the specific MIB being pushed will help in determining the root cause and finding a solution.

[zhongfu]

Is it possible to have omci_app not apply the configs pushed via OMCI, so I can stay connected to the SFP stick and pull the OMCI dumps?

It doesn't seem like the OMCI logfile path is configurable (possibly hardcoded in /lib/libomci_mib.so, so I can't log to e.g. /var/config and pull the OMCI dump after a reboot.

I've also tried running brctl addif br0 eth0 on a loop shortly before plugging the fiber cable in, but that doesn't change anything (connectivity is still lost until a reboot), so I guess that rules # 1 above out.

[Anime4000]

I see, it's better buy other stick instead like ODI or V2801F, no more headache about proprietary OMCI

[zhongfu]

Yeah, I have one of the ODIs on the way -- I was just trying to get it up and running in the meantime with one of my UF-Instants, since the shipping is gonna take a really long time :)

So anyway, I spent a bit more time messing around with it, and here's what I found out:

• the kernel from stock fw 4.1.0 doesn't emulate the SFP EEPROM properly -- the checksums are wrong. Use newer kernel versions (e.g. from fw 4.3.1 or newer -- I've also tried 4.4.9) if this is important to you
  • even then, the advertised capabilities are wrong -- it doesn't advertise itself as an SFP+, and it claims that it does all link speeds (obviously wrong)
• the UF-Instant actually does work... with my TP-Link MC220L media converter!
• with my CCR2004 (and presumably, many other Mikrotik routers/switches), the UF-Instants don't play too well with the SFP+ ports
  • it'll link up and pass traffic if you have a kernel from fw newer than 4.1.0 (I think -- I've only tried fw 4.3.1 and 4.4.9), and if you disable autonegotiation and force it to 1GbaseT full/1GbaseX.
  • HOWEVER, once the ONU finishes linking up to OLT, you will inexplicably lose connection
  • autonegotiation with only 1GbaseT full/1GbaseX only works if you set it, and reinsert the transceiver -- if you do this, it seems like the connection will work even after the ONU reaches O5 and finishes setting up everything

So with all of these caveats in mind... I'd just recommend that you not use a UF-Instant, especially if you're planning on using it with an SFP+ port on a Mikrotik router (and even if you aren't). For now, I've managed to get it working though, so there's that.