Proscend 180-t vdsl2 SFP Support
-
Hmm, so no observable change...
You tried setting the interface to 1000baseSX <full-duplex> fixed?
-
@stephenw10 yes indeed - we've tried a few of the of static media states (we originally thought the interface HAD to be set to 1000base SX) - but since disproved that.
When we have the link set statically, the ifconfig output shows:
mvneta0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: WAN options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 00:e0:ed:bc:2e:eb inet6 fe80::2e0:edff:febc:2eeb%mvneta0 prefixlen 64 scopeid 0x1 media: Ethernet 1000baseSX <full-duplex> (none) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>Quite the conundrum.
If it's interesting, we did have to be on firmware 21.01 or later before the sfp port would work at all. -
Hmm, there may not be much we can do here. The combo port in the 2100 is hardcoded to be only 1000baseSX in the SFP. It doesn't detect the media there.
The correct fix here would probably be at the driver level or even in the hardware description but to so that would require significant developer resources for a device relatively few users will ever see. That's unlikely to happen unfortunately. An alternative might be a startup script that power cycled the module. I'm looking to see if that's possible.If one of our developers in Australia hits this they might suddenly be motivated.
Steve
-
Thanks @stephenw10 ,
Do you have any insights on why the device is fine in all the other models, and only the 2100 has issues? I don't have anyone with skills to edit drivers or firmware for either of the devices; but it just seems a shame that the modem works fine if inserted after boot; but the 2100 can't detect it if present at boot.
I appreciate there would be a reasonable workaround to power cycle the port - do you know of any way I can do that? (obviously a down / up on the interface has no effect).
-
The 2100 WAN port is a unique combination or hardware. It's the mvneta NIC from the SoC but with a combo PHY to give us the SFP port. In order to make that work the SFP port is hard wired to be 1000base-SX and that limits it's flexibility.
I'm not aware of any way to power cycle it unfortunately but let me see if I can find anything...Do you see any errors shown from
sysctl dev.mvneta.0when it's not detected?Steve
-
@stephenw10, thank you for taking another look at this error condition. We have run the requested command on the device in both the initial startup condition, and after manually reseating the SFP module.
Initial boot diagnostics:
[22.05-RELEASE][root@pfSense.home.arpa]/root: ifconfig -m mvneta0 mvneta0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> capabilities=804bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,LINKSTATE> ether 00:e0:ed:bc:2e:eb inet6 fe80::2e0:edff:febc:2eeb%mvneta0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (none) status: no carrier supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX media 1000baseT mediaopt full-duplex,master media 1000baseT mediaopt full-duplex media 1000baseT mediaopt master media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>[22.05-RELEASE][root@pfSense.home.arpa]/root: sysctl dev.mvneta.0 dev.mvneta.0.lpi: 0 dev.mvneta.0.flow_control: 0 dev.mvneta.0.mib.reset: 0 dev.mvneta.0.mib.watchdog: 0 dev.mvneta.0.mib.overrun: 0 dev.mvneta.0.mib.rx_discard: 0 dev.mvneta.0.mib.mac_late_collision: 0 dev.mvneta.0.mib.mac_collision: 0 dev.mvneta.0.mib.mac_crc_err: 0 dev.mvneta.0.mib.mac_rx_err: 0 dev.mvneta.0.mib.pkt_jabber: 0 dev.mvneta.0.mib.pkt_oversize: 0 dev.mvneta.0.mib.pkt_fragment: 0 dev.mvneta.0.mib.pkt_undersize: 0 dev.mvneta.0.mib.fc_rx_bad: 0 dev.mvneta.0.mib.fc_rx_good: 0 dev.mvneta.0.mib.fc_tx: 0 dev.mvneta.0.mib.tx_mac_ctl_err: 0 dev.mvneta.0.mib.tx_bcast_frame: 0 dev.mvneta.0.mib.tx_mcast_frame: 0 dev.mvneta.0.mib.tx_exces_collision: 0 dev.mvneta.0.mib.tx_good_frame: 0 dev.mvneta.0.mib.tx_good_oct: 0 dev.mvneta.0.mib.rx_fame_1024_max: 0 dev.mvneta.0.mib.rx_frame_512_1023: 0 dev.mvneta.0.mib.rx_frame_256_511: 0 dev.mvneta.0.mib.rx_frame_128_255: 0 dev.mvneta.0.mib.rx_frame_65_127: 0 dev.mvneta.0.mib.rx_frame_1_64: 0 dev.mvneta.0.mib.rx_mcast_frame: 0 dev.mvneta.0.mib.rx_bcast_frame: 0 dev.mvneta.0.mib.rx_bad_frame: 0 dev.mvneta.0.mib.rx_good_frame: 0 dev.mvneta.0.mib.tx_mac_err: 0 dev.mvneta.0.mib.rx_bad_oct: 0 dev.mvneta.0.mib.rx_good_oct: 0 dev.mvneta.0.rx.queue0.threshold_timer_us: 100 dev.mvneta.0.%parent: simplebus1 dev.mvneta.0.%pnpinfo: name=ethernet@30000 compat=marvell,armada-3700-neta dev.mvneta.0.%location: dev.mvneta.0.%driver: mvneta dev.mvneta.0.%desc: NETA controllerAfter manually reseating the SFP module:
[22.05-RELEASE][root@pfSense.home.arpa]/root: ifconfig -m mvneta0 mvneta0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> capabilities=804bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,LINKSTATE> ether 00:e0:ed:bc:2e:eb inet6 fe80::2e0:edff:febc:2eeb%mvneta0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (1000baseSX <full-duplex>) status: active supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX media 1000baseT mediaopt full-duplex,master media 1000baseT mediaopt full-duplex media 1000baseT mediaopt master media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>[22.05-RELEASE][root@pfSense.home.arpa]/root: sysctl dev.mvneta.0 dev.mvneta.0.lpi: 0 dev.mvneta.0.flow_control: 0 dev.mvneta.0.mib.reset: 0 dev.mvneta.0.mib.watchdog: 0 dev.mvneta.0.mib.overrun: 0 dev.mvneta.0.mib.rx_discard: 0 dev.mvneta.0.mib.mac_late_collision: 0 dev.mvneta.0.mib.mac_collision: 0 dev.mvneta.0.mib.mac_crc_err: 0 dev.mvneta.0.mib.mac_rx_err: 0 dev.mvneta.0.mib.pkt_jabber: 0 dev.mvneta.0.mib.pkt_oversize: 0 dev.mvneta.0.mib.pkt_fragment: 0 dev.mvneta.0.mib.pkt_undersize: 0 dev.mvneta.0.mib.fc_rx_bad: 0 dev.mvneta.0.mib.fc_rx_good: 0 dev.mvneta.0.mib.fc_tx: 0 dev.mvneta.0.mib.tx_mac_ctl_err: 0 dev.mvneta.0.mib.tx_bcast_frame: 99 dev.mvneta.0.mib.tx_mcast_frame: 19 dev.mvneta.0.mib.tx_exces_collision: 0 dev.mvneta.0.mib.tx_good_frame: 118 dev.mvneta.0.mib.tx_good_oct: 36560 dev.mvneta.0.mib.rx_fame_1024_max: 0 dev.mvneta.0.mib.rx_frame_512_1023: 0 dev.mvneta.0.mib.rx_frame_256_511: 99 dev.mvneta.0.mib.rx_frame_128_255: 14 dev.mvneta.0.mib.rx_frame_65_127: 5 dev.mvneta.0.mib.rx_frame_1_64: 0 dev.mvneta.0.mib.rx_mcast_frame: 0 dev.mvneta.0.mib.rx_bcast_frame: 0 dev.mvneta.0.mib.rx_bad_frame: 0 dev.mvneta.0.mib.rx_good_frame: 0 dev.mvneta.0.mib.tx_mac_err: 0 dev.mvneta.0.mib.rx_bad_oct: 0 dev.mvneta.0.mib.rx_good_oct: 0 dev.mvneta.0.rx.queue0.threshold_timer_us: 100 dev.mvneta.0.%parent: simplebus1 dev.mvneta.0.%pnpinfo: name=ethernet@30000 compat=marvell,armada-3700-neta dev.mvneta.0.%location: dev.mvneta.0.%driver: mvneta dev.mvneta.0.%desc: NETA controller -
Since that module is really a complete router by itself if could be doing something odd when uboot sets up the NICs initially. In both the warm reboot and the cold boot scenario the NIC is first configured by uboot to use for PXE booting.
One thing you could try is setting mvneta1 as the interface uboot uses. To do that you would need to interrupt the boot to reach the uboot prompt (Marvell>>) then run:
setenv ethprime eth1 saveenv resetYou should then see:
Net: eth0: neta@30000, eth1: neta@40000 [PRIME]I tested that here and it still boots fine. Though it would no longer PXE boot from WAN.
It's hard to imagine that will fix it though.Is there any way to reset the module without unplugging it?
Does it have any sort of management interface?Unfortunately they seem to be basically unavailable or incredibly expensive in the UK.
-
S stephenw10 referenced this topic on
-
S stephenw10 referenced this topic on
-
Hi All,
Apologies being yet another person to resurrect this thread, but I have been reading this with significant interest. I am helping out a friend in Queensland with their business network and recommending they get a Netgate 4100 - long story short, we need two WAN ports for a primary ADSL2 connection and failover 4G connection.
Originally I was thinking we would need to purchase a separate ASDL modem, but this thread seems to indicate we can instead use the Transcend 180-T vDSL2 SFP module...is my thinking correct? An all-in-one solution would be perfect.
They are using Aussie Broadband as their provider. Their connection is marketed as NBN VDSL but it's quite clearly ADSL2 since there is literally a phone cable plugging into the back of their Aussie Broadband provided router/modem into the DSL port (by the way, this router/modem is not particularly good or working for them...thus my recommendation to go to pfSense).
Being fortunate enough to have NBN FTTH myself I haven't had the "pleasure" of dealing with an ADSL connection in quite some time, so I am not fully across things like VPI/VCI settings...having a look at the settings on the current model it uses VSDL Profile 17a if that is releavant.
Anyway, this is a long way of asking do you think this is going to work? I'd hate to recommend something to them which then doesn't end up working!
Thanks in advance for any advice!
-
@skoota said in Proscend 180-t vdsl2 SFP Support:
Their connection is marketed as NBN VDSL
I use the an external modem (ISP supplied) in bridge mode.
That way if there are connections issues, I can reset the modem to factory default an confirm it is not a fault with my equipment. -
@patch Thanks, but I am keen to eliminate the provided Aussie Broadband modem (as it's not particularly reliable) and, if possible, would like an all-in-one solution (rat than a separate modem in bridge mode) for both elegance and also fewer devices to go wrong in the chain...so I am keen to know whether the Transcend module will do the job.
