Anyone seen this issue before with Fritzbox on BigPipe UFB?

zaptor:

Right, so, I tried @snnet suggestion of using another port. However, it seems the only one which goes green when physically connected is LAN1?

Then, following @hio77 suggestion that the non-PPP traffic could be triggering some sort of DROP rule at the ONT, I disabled IPv4 on the the ethernet adapter, so the only Client/Service/Protocol operating was the "Npcap Packet Driver" - which I need for the captures.

The WAN Miniport connection had IPv4 enabled on it, so I figured/hoped that would be enough.

Turns out, all the extraneous non-PPP traffic was the problem.

After the first packet, which was a PADI, I immediately received a PADO, followed by a PADR, and then a PADS, which I think completes the PPPoE discovery stage.

In total there's 22 x PPP/PPPoE packets.

I can see Configuration Requests/Acks, Identification, Authentication packets (x2), Code Rejects, Termination Request/Ack, all followed by PADT packets from both my laptop and the ONT.

What's of most interest were the Authenticate packets.

The Authenticate-Request payload had both Peer-ID and Password set to "bigpipe" - which as I understand it is okay (anyone feel free to correct on that).

The corresponding reply was an Authenticate-Nak, with the payload being the string "Unknown Subscriber type".

Following this, I see a Termination Request from the ONT.

Okay, so this behaviour appears to match what I was seeing with the 7490.

Will ponder what to do next over dinner.

Hi Zaptor, so it sounds like PPPoE Discovery and the initial PPP LCP is working ok.

My best guess of what is going on here is that Chorus (or whichever LFC) are not inserting the Circuit/Remote ID, so our network is just seeing a random PPP request with very little inside it to tell us who it is.

I suspect that this is you:

TIMESTAMP="Jan 1 2021 17:05:29 NZDT" ACCESS-TYPE="PPPoEoQinQ" TYPE="Auth" PACKET-TYPE="Access-Reject" REASON="Unknown Subscriber type" CIRCUIT-ID="" REMOTE-ID=""

The MAC address for that was a Dell device.

I can't be certain it was you, but think the chances are pretty good considering it matches with your description.

If it is you then you'll unfortunately need to log a fault with Bigpipe. Tell them you cannot authenticate, and the advice from a Spark network technician is that it does not appear that the Circuit ID/Remote ID insertion is enabled for your line and they need to take a look at it from that perspective. PM me if you are not getting any joy (I can't log a fault myself, but can help push the process along once its started).

Dave.

zaptor

cbrpilot