lsmod without any parameters ?
root@bpi-r3:/# lsmod
Module Size Used by
mt7915e 126976 0
mt76_connac_lib 45056 1 mt7915e
mt76 65536 2 mt7915e,mt76_connac_lib
hwmon 24576 1 mt7915eso if you load the module i guess the message comes up
modprobe sfpyes
root@bpi-r3:/# modprobe sfp
root@bpi-r3:/# lsmod
Module Size Used by
sfp 32768 0
mdio_i2c 16384 1 sfp
mt7915e 126976 0
mt76_connac_lib 45056 1 mt7915e
mt76 65536 2 mt7915e,mt76_connac_lib
hwmon 24576 2 mt7915e,sfp
root@bpi-r3:/#I meant the message you are missing in debian log…
sfp sfp-1: module ALCATELLUCENT G010SP rev 10 sn ALCLFAB44018 dc 161205
it didn’t appeared in the shell, i have to reboot ?
No maybe in dmesg only
can’t see it
root@bpi-r3:/# dmesg | grep 'G010SP'
root@bpi-r3:/#
root@bpi-r3:/#I guess debuglevel is higher (only prints errors/warnings) as the message you want to see ahould be created here
Here are some ways to change the loglevel
https://linuxconfig.org/introduction-to-the-linux-kernel-log-levels
You can increase the level and the unload/load the sfp module with modprobe (-r) sfp
From: Russell King - ARM Linux admin @ 2019-11-20 11:39 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit; +Cc: David S. Miller, netdev
The SFP module EEPROM describes the capabilities of the module, but
doesn't describe the host interface. We have a certain amount of
guess-work to work out how to configure the host - which works most
of the time.
However, there are some (such as GPON) modules which are able to
support different host interfaces, such as 1000BASE-X and 2500BASE-X.
The module will switch between each mode until it achieves link with
the host.
There is no defined way to describe this in the SFP EEPROM, so we can
only recognise the module and handle it appropriately. This series
adds the necessary recognition of the modules using a quirk system,
and tweaks the support mask to allow them to link with the host at
2500BASE-X, thereby allowing the user to achieve full line rate.
And later:
|> +||// Alcatel Lucent G-010S-P can operate at 2500base-X, but|
|---|---|---|
|> +||// incorrectly report 2500MBd NRZ in their EEPROM|
|> +||.vendor = "ALCATELLUCENT",|
|> +||.part = "G010SP",|
|> +||.modes = sfp_quirk_2500basex,|
So this is how these modules ‘auto negotiate’ and get connected at one of the possible interfaces. Definitely no inband negotiation. So it may be worth a try disabling auto negotiation, in order for the mac to report link up, same as the OEM 2.5G-T.
ethtool -s eth1 autoneg off
Then bring it up:
ip link set dev eth1 up
Also, not only ping the interface, but make sure it is setup right before pinging. Indeed not with a master bridge. Then check it has ip address and route
ip addr show dev eth1
ip route
It has absolutely no use to ping if this is not setup right.
Possibly correct if necessary:
ip addr add 192.168.20.1/24 broadcast 192.168.20.255 dev eth1
ip route add 192.168.20.0/24 dev eth1
Then ping
Thanks @ericwoud for this clear explanation !
let’s try…
By the way, from the site https://hack-gpon.org/ont-fs-com-gpon-onu-stick-with-mac/
We can’t set the speed @2500Mbps with autoneg off from the ONT Stick…we can only do it for 1Gbps. Unless there is an undocumented value.
Unfortunately, it still doesn’t work.
config interface 'ont'
option device 'eth1'
option proto 'static'
option ipaddr '192.168.20.1'
option netmask '255.255.255.0'
ip a
root@OpenWrt:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
inet6 fe80::8ced:11ff:fe03:875c/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 8e:ed:11:03:87:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.20.1/24 brd 192.168.20.255 scope global eth1
valid_lft forever preferred_lft forever
4: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5d brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
9: sfp2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
10: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:0c:43:26:60:00 brd ff:ff:ff:ff:ff:ff
11: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 8e:ed:11:03:87:5e brd ff:ff:ff:ff:ff:ff
19: br-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 8e:ed:11:03:87:5c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fdee:7d2b:f512::1/60 scope global tentative noprefixroute
valid_lft forever preferred_lft forever
20: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 8e:ed:11:03:87:5d brd ff:ff:ff:ff:ff:ff
and then :
root@OpenWrt:/# ethtool -s eth1 autoneg off
root@OpenWrt:/# ip link set dev eth1 up
root@OpenWrt:/# ip addr show dev eth1
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 8e:ed:11:03:87:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.20.1/24 brd 192.168.20.255 scope global eth1
valid_lft forever preferred_lft forever
root@OpenWrt:/# ip route
192.168.1.0/24 dev br-lan scope link src 192.168.1.1
192.168.20.0/24 dev eth1 scope link src 192.168.20.1
root@OpenWrt:/# ping 192.168.20.10
PING 192.168.20.10 (192.168.20.10): 56 data bytes
^C
--- 192.168.20.10 ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# ip addr add 192.168.20.1/24 broadcast 192.168.20.255 dev eth1
ip: RTNETLINK answers: File exists
root@OpenWrt:/# ip route add 192.168.20.0/24 dev eth1
ip: RTNETLINK answers: File exists
result :
root@OpenWrt:/# ping 192.168.20.10
PING 192.168.20.10 (192.168.20.10): 56 data bytes
^C
--- 192.168.20.10 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/#Did you try posting the problem on the openwrt forum? There may be more users using the gpon module, or something similar.
To bad it is still not working.
How about booting first then inserting the module and trying the above. Then paste the full dmesg log from the moment of inserting the module. Then we are certain not missing anything by using grep, but the log we need is still filtered of unneeded info of other hardware initializing.
As the module seems to be working with the SFP signals ignored and SerDes set to 2500Base-X with in-band-status my guess would rather be the opposite: The module requires in-band-status (at least in it’s current software configuration).
Just something to try, since it does not want to go up… I came across some post of another gpon module that needed auto negotiation off also.
I wonder if phylink.c- is waiting for the LOS signal to switch, and need to check the latest log with debug info if it does.
Guess LOS 0->1 means LOST SIGNAL and is coupled with a bit in pl->phylink_disable_state.
static void phylink_resolve(struct work_struct *w)
{
struct phylink *pl = container_of(w, struct phylink, resolve);
struct phylink_link_state link_state;
struct net_device *ndev = pl->netdev;
bool mac_config = false;
bool retrigger = false;
bool cur_link_state;
mutex_lock(&pl->state_mutex);
if (pl->netdev)
cur_link_state = netif_carrier_ok(ndev);
else
cur_link_state = pl->old_link_state;
if (pl->phylink_disable_state) {
pl->mac_link_dropped = false;
link_state.link = false;
So here it means that the link is down.
If the modules LOS is coupled to the fibre link state (which I am assuming here) then it would mean that on the BPI-R3 we do need to attach the fiber to be able to connect it with ssh or telnet.
With inband enable, like dangowrt syas, then we probably only need the 2500-base-x quirk (check with @Dale).
First setup a connection with the fiber side, using the media-converter. If that is successful, then move it to the R3…
but we have already in-band enabled…
or am i wrong?
The 2.5 quirk is there. Don’t count on me to build anything anytime soon, my pc doesn’t boot
Ok, if it only fixes the 2500base-x and nothing more, then should be ok.
What we need to see is (my OEM 2.5G-T module):
[ 132.182334] sfp sfp-1: los 1 -> 0
[ 132.185674] sfp sfp-1: SM: enter present:up:wait_los event los_low
[ 132.191847] sfp sfp-1: SM: exit present:up:link_up
But @Rooot
[ 807.445028] sfp sfp-1: los 1 -> 0
[ 807.448335] sfp sfp-1: SM: enter probe:up:down event los_low
[ 807.453980] sfp sfp-1: SM: exit probe:up:down
[ 807.458358] sfp sfp-1: los 0 -> 1
Always ends up with los 0 -> 1
los is a pin on the sfp cage, so it is a hardware signal coming from the module. It prevents the link going up. My guess is that the fiber link needs to go up and then then los 1 -> 0 will happen, and phylink.c will continue setting the link up.