![]() ![]() ![]() ![]() |
|
Also remember BigPipe's default is no VLAN.
The Fritz!Box's default is VLAN 10.
Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)
Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.
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.
Bingo, it's a feature.
I'd personally say it causes more havoc than it's worth though since for the end user it causes faults like this. Generally the helpdesk can't always see it.
In terms of the extra flags your getting i'd suspect you are sending something extra in the ClientID which will also cause PPPoE to fail - cleanly though.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
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.
My views are my own, and may not necessarily represent those of my employer.
cbrpilot:
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.
Hi Dave,
That timestamp matches the time of my trace - to the exact second. Plus, my MAC address does indeed belong to a Dell device.
So, I think your suspicions are bang on.
Will look at logging a fault as per your suggestion.
Thanks for the assist.
Right, so should be fixed soon according to the rep I was able to contact. Waiting on Chorus to action their end.
Might be a good idea to plug your router back in - on the off chance they action the order faster than they say they will ...
My views are my own, and may not necessarily represent those of my employer.
cbrpilot:
Right, so should be fixed soon according to the rep I was able to contact. Waiting on Chorus to action their end.
Might be a good idea to plug your router back in - on the off chance they action the order faster than they say they will ...
Thanks Dave, and everyone else who assisted. All seems to be good now.
Had to set the upstream/downstream cap rates in the 7490 appropriately. The factory reset defaulted to 1Mbps down, 256Kbps up!
|
![]() ![]() ![]() ![]() |