[BPI-R4] SFP works in openWRT 21.02 only?

Banana Pi Router design BPI-R4(MT7988)
1

I have DFP-34X-2C3 and it doesn’t work in openwrt-snapshot.

openwrt-snapshot

dmesg | grep sfp

ethtool

official-21.02

dmesg | grep sfp

ethtool

2

maybe something like this helps?

https://patchwork.kernel.org/project/netdevbpf/patch/AS1PR03MB81893D69344708C98EE2B470827F2@AS1PR03MB8189.eurprd03.prod.outlook.com/

see some discussion here: BPI-R3 SFP Module compatibility - #108 by Sergiosat

1 Like
3

After patch

switched the stick to 2500x mode “flash set LAN_SDS_MODE 6”

No link. :slightly_frowning_face:

4

Mhm,do not know more here…maybe disable auto-neg? But afaik daniel already use a 2g5 fix in openwrt

5

I noticed that with autoneg off nothing works.

In openwrt-snapshot stick is not detected (ethtool -m):

Offset          Values
------          ------
0x0000:         03 04 01 00 00 00 02 22 00 01 00 01 0d 00 14 c8 
0x0010:         00 00 00 00 4f 44 49 20 20 20 20 20 20 20 20 20 
0x0020:         20 20 20 20 00 00 00 00 44 46 50 2d 33 34 58 2d 
0x0030:         32 43 33 20 20 20 20 20 20 20 20 20 05 1e 00 71 
0x0040:         00 1a 00 00 58 50 4f 4e 32 34 30 36 30 34 38 31 
0x0050:         20 20 20 20 32 34 30 36 32 31 20 20 00 00 00 e7 
0x0060:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0070:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0080:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0090:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00a0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00b0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00c0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00d0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00e0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x00f0:         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

In 21.02

        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                               : ODI
        Vendor OUI                                : 00:00:00
        Vendor PN                                 : DFP-34X-2C3
        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                                 : XPON24060481
        Date code                                 : 240621
6

maybe @Sergiosat can help here and tell you whats needed…

7

Perhaps this one also needs link up from optical side

8

but before the sfp quirk there was a link-up

9

I managed to achieve “Link detected: yes”, but there is still no connection.

[  398.369619] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control off
[  398.372943] br-wan: port 1(eth2) entered disabled state
[  398.386599] mtk_soc_eth 15100000.ethernet eth2: entered allmulticast mode
[  398.393481] mtk_soc_eth 15100000.ethernet eth2: entered promiscuous mode

RX: 0 B (0 Pkts.)
TX: 4.91 KB (117 Pkts.)
10

I am seeing something similar. With a June-2024 snapshot, my SFP+ works just fine. With recent snapshots, it fails to come up properly (but in my case ethtool does show link up).

Can you try what happens when you run (after link is up)

udhcpc -i br-wan

manually? I then do get an IP, can ping IPs on the net but DNS remains shot. ifstatus wan sadly still claims the link is down after that.

Honestly still trying to get to the bottom of it. It’s hard to debug because whenever I boot the new images no internet to do research (and backup 5G is super slow where I live).

I suspect it’s related to the port entering disabled state (happens in newer images but not in the older ones) but I sure can’t figure out why it does that.

11

udhcpc is a dhcp client, so it means hardware all is ok. You only need to setup the network connection correctly.

1 Like
12

I know that the hardware is ok, but recent snapshots for some reason do not properly bring it up.

In June snapshot, it just works (the setup is really simple, no PPPoE or anything, just straight ethernet over fiber), no configuration whatsoever needed so I am really at a loss why it fails in more recent ones and where I would need to change config…

And the symptoms look quite similar to what karasik reports.

13

It is up, but network is not configured correctly. That is very different. Writing it like that suggests a totally different problem

14

Fine but then what’s missing (and why does it work with older snapshots as it is)?

15

Sadly I do not use openwrt… If this was a driver issue, that would not really matter, and I would also be curious as to what is wrong. But this is a userland issue and depends on the operating system of choice. That is, if others also can partly fix it with udhcpc.

16

I agree it’s most likely a userland issue and the likely culprit is a major netifd upgrade in openwrt-snapshot in early August.

Also, FWIW, the DAC going to my switch works like it always did.

17

I’m away from home until September, when I get there I’ll try this patch https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a1a9572f43776c3fed46c4545e93fbbb25d923c2 Something was changed in kernel 6, so it works on 5.4.

18

FWIW setting force_link worked for me (both on wan and wan6):

config interface 'wan'
        option device 'br-wan'
        option proto 'dhcp'
        option force_link '1'
1 Like
20

I think the problem is that the module is detected as “DFP-34X-2C3” and not as “DFP-34X-2C2”, maybe the second is the only one supported in the linux kernel.

Try flashing the firmware of the “DFP-34X-2C2” model like these guys did, since both devices are the same and only the connectors are different (UPC vs APC):

This is just a suggestion and I hope you can solve this problem.

21

@Karasik To change module connection speed, check this discussion: Right SFP EEPROM config for DFP-34X-2C2 to work automatically work at 2500base-X? · Anime4000/RTL960x · Discussion #250 · GitHub

(Though this shouldn’t have anything with your current problem)

1 Like