Proscend 180-t vdsl2 SFP Support

ETSAU

@interspective sorry for the post on such an old thread - wondering if you would be prepared to share some of your final settings that you used for your Proscend 180-T.

I've burned about a day trying to get it working on an NBN service here in Australia, but just not getting anywhere.

I can get line sync, but beyond that, nothing. (Can't any packets received, but can do a TCPDump and see DHCP / PPPoE requests being sent).

Any help you can give would be appreciated; I'll write a HowTo if I do get it working, as I think it would be a wonderful solution for the Australian market.

Thanks in advance!

stephenw10

Do you see any incoming traffic in a pcap? Is any of it tagged?

Steve

interspective

Hi @ETSAU

I have DM'd you my contact details. If you're in Aus its probably best to give me a call.
Reading through the threads you've been posting on - yes it is weird that you set a VLAN on the interface, and then don't use it, but this is just to configure the device to use a specific VPI/VCI. That's all.

ETSAU

Folks, thank you; that's awesome!
@stephenw10 - No, we were seeing 0 packets inbound on any interface (we created an interface with the physical wan interface after creating the pppoe interface - nothing inbound).
Thanks @interspective! I'll see if I can flip the office over to 4G internet and take the NBN connection over for testing... right now!

ETSAU

Firstly - Massive thank you to @interspective - your efforts were so helpful.

As it turns out; the key thing that was the "fix" here was the pfSense version - we have been operating 2.4.5 on the Netgate 2100.

The error we saw was the "media" state showing as "none" in Status -> Interfaces, WAN. The WAN needed to be configured to obtain a DHCP lease (i.e. not PPPoE).

With the older firmware version, we were unable to receive any traffic on the WAN interface (and I would question if any traffic actually did leave the WAN interface anyway).

Once we connected the Proscend 180-T to a Netgate 4100 (on the latest firmware), we instantly obtained an address on the WAN interface, which does conflict with the findings @interspective has above, however @interspective makes a good point, that perhaps the Proscend 180-T only needs to see one packet on a specific VLAN to be configured - nothing further. I'm unable to test this further currently, but if I get conclusive results, I'll post back here.

We'll also do some further work (at a point in the future) to see if there are any line stats we can get out of the Proscend 180-T device, as this would clearly have value.

Thanks also @stephenw10 for your contributions!

stephenw10

Nice!
So you didn't have a VLAN configured at all on the 4100 but perhaps the 180-T was already configured correctly having previously been exposed to some tagged traffic?

That seems super weird!

Steve

interspective

@stephenw10 Yeah the VLAN situation does seem strange. I always thought that defining VPI/VCI was required for ADSL, but not vDSL. I could be wrong, however. Also, my initial posts were all done prior to nbn's network upgrade - and their requirements for vDSL may have changed? I haven't tested it since then, and the original device I configured is no longer being used in that configuration. The router moved to a different location and now connects via its gigabit WAN interface.
Looks like @ETSAU has his device working after a router firmware upgrade. I'm sure he'll post any other findings he makes in testing various configurations.

ETSAU

I think our next move is to order a few more of the Proscend 180-T devices and pop them into a selection of 2100/4100/6100/7100's and see how they perform on Australian NBN connections.

We'll hang on until we can get our hand on more stock of the 2100's, and take a couple un-touched Proscend 180-T's through initial config steps and document.

Really, it's an incredibly tidy solution; with the only gap being the lack of line stats for the vDSL service.

We may also need to look at a means of power cycling the device (Proscend) as rebooting the host Netgate appliance doesn't drop power to the modem (Pro and Con really).

So glad to have an [modular] integrated vDSL modem; significantly better customer outcome.

Thanks again folks!

madheff23

Hi @ETSAU - just wondering if you have any update on configuring these for the Netgate 2100s? I've had mixed success. One worked fine with Internode with no VLAN, however struggling to get another working with Valve Networks with VLAN 10...

I think our next move is to order a few more of the
Proscend 180-T devices and pop them into a selection
of 2100/4100/6100/7100's and see how they perform
on Australian NBN connections.

I think there are two main points here in this case for you.

Is it compatible to the lokal ISP xDSL
How it performs in x86_64 and the ARM (Marvel) hardware (compatibility)

Would be nice to hear about that in the future if will
be able to tell something about real life made experiences.

We have a several of the APU6B4, a bunch of Supermicro
C3958/C3858 devices together with pfSense.

And now we are also want to insert sfp modems into this
boxes.

ETSAU

@madheff23 we did get the VDSL modules working, and they are working well.
The key trick for us on the 2100 was actaully the pfSense version - we needed to update (we were running 2.4.5x).

We didn't need to do any specific VLAN tagging on our service (i.e. ISP didn't require), but in the case where we do need to pass a VLAN tagged traffic, we created a vlan interface on top of the WAN interface.

I haven't got round to writing the documentation on doing that yet; I will get to it but in the meantime happy if you DM me and we can work it through together.

ETSAU

We have uncovered what we believe to be a bug with the Netgate 2100 SFP port, where the link state is lost when the device reboots, and requires the module to be removed from the SFP port and then re-inserted.

We have tested the Netgate 2100, 4100 and 6100 (Base models, but I don't expect there would be any material difference here for the MAX editions). The process we have gone through is:

Power on Device
Observe Media state in "Status -> Interfaces"
Insert SFP Module
Observe Media state in "Status -> Interfaces"
Reboot appliance
Observe Media state in "Status -> Interfaces"

For the 4100 and 6100 appliances, the Media state is consistent across reboots, showing the expected media state. For the 2100, the media state is as expected after inital installation into the appliance, then reverts to "none" after reboots.

The results are consistent between power loos / power restore, and graceful reboots.
The Combo ports were used in all cases (i.e. not the dedicated WAN3/4 on the 6100).

Confusingly, the 2100 continues to power the SFP module, and power to the SFP module is not interrupted during the graceful reboot cycle. Any troubelshooting steps have proven unhelpful on the 2100 to recover the link state - such as disable / enable the port, down/up the interface (ifconfig xxxx down && ifconfig xxxx up, etc). The only tangible change was physically remove and re-insert.

Screen shot of no media state after a 2100 reboot: (which is also represented in the ifconfig output at console with "media: Ethernet autoselect (none)"

Screen Shot of expected state (observed on 4100 and 6100 consistently):

I'll be raising support request with Netgate to see if we can ascertain exactly what the difference here between the 2100 and the 41/6100 devices.

I'll post back here when we have an update for those who are interested.

rcoleman-netgate

@etsau What software version are you running?

@etsau said in Proscend 180-t vdsl2 SFP Support:

I'll be raising support request with Netgate to see if we can ascertain exactly what the difference here between the 2100 and the 41/6100 devices.

They are completely different platforms. The ARM processor in the 2100 does not use the same hardware as the Atom processor in the 4100/6100 series devices.

ETSAU

@rcoleman-netgate Sorry for not including that!
We (months ago) had 2.4.5x - with which nothing worked.

We then upgraded to 22.01 - the device was detected and we were all good.

The testing we've just completed last week and posted a few minutes ago; was tested on version 22.01 and version 22.05.

ETSAU

@rcoleman-netgate re Hardware - acknowledge the difference in processor - do you know anything about the combo ports? I was thinking something like that might be relevant.

Does feel odd that's a problem if it's the CPU architecture, but this is well outside my wheelhouse.

rcoleman-netgate

@etsau They're not the same NICs, and thus not the same drivers.
On the 4100/6100 they are Intel SoC NICs, on the 2100 they're Marvell.

ETSAU

@rcoleman-netgate do you see this as being something that's fixable in some way? Not sure about other regions but we're seeing a good amount of interest (Australia), and it's really a very tidy solution for the 2100

I'm willing to put a bit of effort in to see what we can do.

rcoleman-netgate

@etsau I'll leave this ticket for my colleague to see in the morning... he has better thoughts when it comes to the hardware and engineering side. If he has anything for me to test in the lab he'll reach out to me directly.

Not sure what we can do about reproducing your specific media converter, however. It might be a limitation of the hardware device itself.

ETSAU

@rcoleman-netgate Thank you very much for your assistance there. FWIW, we are a partner for Australia.

stephenw10

What does ifconfig -m mvneta0 show in either state?