New BPI-R4 owner! SFP+?

Hello fellow banana pi owners!

2026 is starting out to be very frustrating.

After doing research on finding a good OpenWrt router, I stumbled on this here. Did the research, watched some youtube videos. Then finally pulled the trigger. My trusty Edgerouter 4 from 2020 died on me so here I am! I installed OpenWrt back in 2022 and was happy ever since.

So I did all the mumbo jumbo: SD Card > Nand > emmc. runs fast yay. Then I plug in my POE Switch (EdgeSwitch 24) to SFP LAN using an SFP+ DAC cable. Thought would work immediately, sure enough it doesn’t. It kicks me off the internet for some reason?? (laptop directly connected to the LAN port). I don’t know how many times i tried to troubleshoot via console USB TTL port.

I’ve come to the conclusion, that I am using the wrong SFP modules??? 10Gtek (thought these were the way to go anyway). Either that or my board is defective.

So far from sifting through these forums. You guys have ran into everything from 2023, 2024, and 2025. Are these seriously still issues to this day??

I’m not quite sure where to go from here. Any advice is truly appreciated.

Poe does not work via SFP…poe is only possible on the phy port (2.5g variant with poe module equipped).

Or don’t you try to power R4 with your poe switch?

Maybe you can get debug log (dmesg) when traffic is getting broken…so that we see if only link goes down or sfp reports removed or something.

RJ45 10G sfp+ getting really hot so make sure you have at least passive heatsink on sfp cages or better fan which also brings hot air outside of the case.

Hi Frank! Thank you for the quick response.

No i’m not connected via POE. i’m connected via the SFP port from the poe switch. My bad if any confusion. my POE switch is already powered by the power cable. I’m also not trying to power the router via POE.

Can i run debug via ssh?

I have the ONT box, and the router on top of a laptop cooler (if that helps).

If network is configured correctly and stable (makes no sense over the sfp which flaps) you can also use ssh…debug-uart is independ of network so mostly more stable in such situations and you see full bootprocess (bootrom,atf,uboot and linux of course) where linux dmesg start with linux kernel…but here dmesg via ssh could be enough

Are you saying that the issue you are having is that your BPI-R4 and your switch don’t link up?

It’s not clear to me what you have connected besides the DAC. Can you please specify your network setup?

Can you paste the output from ethtool -m [interface with the DAC] and also any other transceiver you are having problems with?

Is it an SFP or SFP+ DAC? I believe the OpenWrt developers decided against allowing you to force a particular link rate so you need to make sure your DAC’s EEPROM data specifies the link speed you want.

It has worked great for me the last few months, i.e. as long as I’ve been running it as my main router. I started with OpenWrt to confirm everything could work as I wanted before moving back over to VyOS. :slight_smile: I only use the two SFP+ slots, one with a FlexOptix 10GBASE-T 100m transceiver and one with an Ipolex SFP+ DAC connecting it to my Hasivo 10 Gbit/s switch. So far it has been very reliable.

@blunden

Yes let me clarify.

BPI is my router (only router). i have a switch that i connect to it. SFP doesn’t seem to work. i connected RJ45 just fine.

it’s an SFP+. is that an issue? it’s a 10Gtek brand.

and

Summary of SFP+ Issue on Banana Pi BPI-R4

Problem Statement

When connecting an SFP+ DAC cable from a switch to the BPI-R4’s SFP LAN port:

  • Internet connectivity drops immediately
  • SSH session may disconnect
  • SFP+ link fails to establish (NO-CARRIER)

What We’ve Verified

Hardware/Driver Status:

  • :white_check_mark: SFP kernel driver (sfp ) is loaded and bound to both SFP1 and SFP2 ports
  • :white_check_mark: All SFP GPIO interrupts are properly configured:
    • sfp1-mod-def0 (mt-eint 82) - Module insertion detection
    • sfp1-los (mt-eint 54) - Loss of signal
    • sfp1-tx-fault (mt-eint 69) - Transmit fault
  • :white_check_mark: I2C bus mapping correct: SFP1 → i2c-2 (0x59), SFP2 → i2c-3 (0x5a)
  • :white_check_mark: GPIO mappings from device tree:
    • mod-def0: GPIO bank 0x0a, pin 0x52 (82)
    • los-gpios: GPIO bank 0x0a, pin 0x36 (54)
    • tx-fault-gpios: GPIO bank 0x0a, pin 0x45 (69)
  • :white_check_mark: Ethernet driver mtk_soc_eth loaded with 3 interfaces (eth0, eth1, eth2)
  • :white_check_mark: eth1 configured for inband/10gbase-r link mode

Current State (NO module inserted):

  • /sys/class/net/eth1/carrier = 0 (no link)
  • /sys/class/net/eth1/operstate = down
  • All interrupt counts at 0 (no events triggered)
  • eth1 removed from br-lan bridge for safe testing

Key Finding

The SFP+ hardware appears initialized correctly, but no mod-def0 interrupt triggers when inserting a DAC cable . This suggests either:

  1. GPIO pin not detecting physical state change
  2. DAC cable/module not providing proper insertion signal
  3. Hardware issue with SFP+ cage
  4. Driver expecting different voltage levels or pull-up/down configuration

Next Debug Steps Needed

  1. Test with different SFP+ modules (fiber vs DAC)
  2. Serial console monitoring during insertion
  3. GPIO voltage level measurements on mod-def0 pin
  4. Check if switch-side SFP+ port is configured/enabled

Open Questions for Forum

  1. Are there known issues with specific SFP+ DAC cables on BPI-R4?
  2. Should mod-def0 be active-high or active-low for DAC cables?
  3. Any required kernel configuration options for SFP+ support?
  4. Known working SFP+ module models?

System: OpenWrt snapshot on BPI-R4 (eMMC installation) Testing: 10G SFP+ DAC cable between BPI-R4 and managed switch

Check dmesg after connecting the DAC and paste the relevant output here.

I think the issue you are seeing might be that the BPI-R4 is trying to link up at 10 Gbit/s because it’s likely the only speed the DAC claims to support in its EEPROM data, while the EdgeSwitch on the other end is trying to link up at 1 Gbit/s. Forcing the link speed to 1 Gbit/s would likely have worked, if possible. Using an SFP (i.e. 1 Gbit/s) DAC would likely fix it. :slight_smile:

Why are you running a snapshot release btw.? Just to compare to stable? :slight_smile: I would try with the latest stable release if you haven’t already, just in case.

If you post the ethtool output I asked for (requires the ethtool-full package on OpenWrt), we could confirm what speeds the DAC claims to support.