@websquadza My fibre has been down since morning, logged ticket #635422 with a detailed description/diagnosis of the issue. Your support replied with a cookie cutter response. After which radio silence. Can you please check.
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: What's the most interesting small town you've visited in South Africa?
Web Squad ISP
- Thread starter Gazed416
- Start date
- Status
On it
Edit: we did try reach out. Seeing your line up and learning your router’s Mac addy. But not getting any connection from you.
Last edited:
@websquadza Line up and mac being learnt don't really matter as PPPoE discovery fails. Your support are all trying to troubleshoot the PPP connection which of course cannot be setup if PPPoE discovery does not happen. The PPP connection will never come up if the POP is not responding with an offer.
Our support were pretty clear that we are not receiving a PPPOE connection from you despite seeing your MAC address - which means L2 is fine. Which is why we asked you to check your router. PPP is up on the VLAN you're on, other clients on this VLAN are up and running. Team also can't assist if you're not responding to tickets.
JustAnotherSouthAfrican
Well-Known Member
- Joined
- Oct 21, 2017
- Messages
- 158
- Reaction score
- 57
What's this VPN all about?Day 15 of the VPN vigil
Users outside of CPT have routing that seems to be more optimised throughout EU, especially for gaming, going through Cogent. We can't use the same routing because as I understand it, Cogent don't have a CPT PoP. I asked @websquadza if perhaps we could have a VPN that uses this routing, as it honestly feels better in-game even with the added 20ms latency to JHB, and he made a claim that I bet he regrets (
) saying they could get something up very quickly quite a while ago, but alas, still nothing.Your team is clueless on how PPPoE works, there are two stages to PPPoE. The discovery phase and the session phase. The discovery phase is used to setup the connection (session) on which PPP then runs. The discovery phase was failing because the POP was not responding with a PADO offer. Your team is trying to debug the session phase. You cannot have the session phase if the discovery fails. Authentication only happens in the session phase when PPP is active.
DrJohnZoidberg
Honorary Master
Octotel?
I would love to try this as wellUsers outside of CPT have routing that seems to be more optimised throughout EU, especially for gaming, going through Cogent. We can't use the same routing because as I understand it, Cogent don't have a CPT PoP. I asked @websquadza if perhaps we could have a VPN that uses this routing, as it honestly feels better in-game even with the added 20ms latency to JHB, and he made a claim that I bet he regrets (
Thank you very much for your insight. It’s a wonder we manage to get this to work for 100% of the rest of our user base. But of course, we don’t know what we’re doing.
Rather than claim we’re clueless here, take the time to respond to the ticket so we can help you troubleshoot your connection. We do this on a daily basis. There’s a troubleshooting process to go through.
The fact that we went to the extent to confirm we are learning your MAC at our NNI obviously points to the fact that we’re incompetent. Our BNG is operating at 100% and PPP is active. All Vumatel connections from your area are aggregated on a single VLAN, all those connections are working just fine. It’s just yours not working.
We are not receiving a PADI from you. This points to your router not sending a discovery packet or that discovery packet being eaten up along the way. The former is easy to test and our support team are waiting for your response to your ticket to suggest trying a ppp session from another device. If that doesn’t work, it’s much more complicated to escalate to Vumatel to get them to understand their network is snooping. So let’s test the former first.
eddief1
Expert Member
- Joined
- Feb 26, 2008
- Messages
- 1,523
- Reaction score
- 301
I can assure you websquadza knows how PPPoE works.
Thing is they learning your routers MAC, on a VLAN that has other clients already able to auth via PPPOE. something does not make sense and it's logical to assume it's your side as what else could it be?
Have you got a laptop directly plugged into the ONT, dialing a PPPOE for these tests you doing?
No where in the responses to my ticket was there any mention of the fact that you are not seeing my PADI packet. Your support is sending me my authentication details via email to confirm if i have my credentials setup correctly.
Authentication does not come into the picture if you are not seeing a PADI packet from me. Why on earth are you asking me about authentication if you are not seeing a PADI from my device ?
When i sent my ticket i did indicate am sending out the PADI and not getting back the PADO. Why then are they responding with questions about credentials if they understand PPPoE ?
I had already debugged the issue before i logged the ticket. My ticket was very specific i told them am sending out the PADI packet but not gettting back a PADO packet. Any one who knows PPPoE would not ask you about authentication details. PADI->PADO->PADR->PADS are part of the discovery phase. Authentication only happens in the Session phase.
As I've mentioned, support are unable to diagnose your issue if you do not respond to the ticket. To quote exactly what we stated on your ticket last night:
At no point did we say we were receiving the wrong session credentials or mention the session establishing incorrectly at all. 99% of clients won't understand the word PADI, so we don't use it, but they do understand not seeing a connection -which encompass the entire connection process (PADI request, discovery etc). We suggested a hard reset and provided the PPP credentials in case you did not have these.
Have you tried a connection from your PC (establishing a PPP session from the PC connected directly to the ONT). We also have DHCP enabled on the VLAN, please let me know if you are able to pick up a DHCP address (it will be CGNAT, but it's for test purposes).
As I said before, eliminating any other issues is paramount because dealing with Vuma and AEX NOC on broadcast protocol issues is a headache- to put it lightly. So let’s first clear obvious issues before taking it up with them.
eddief1
Expert Member
- Joined
- Feb 26, 2008
- Messages
- 1,523
- Reaction score
- 301
For sure, but you have posted on the forum, presumably for help from the community?
We don't need to know how PPPoE works, we know that...we need to know how you sending the PADI packet and if you have tried using a different method to send it!
Let us deal with specifics here, my contention that who ever is responding to tickets does not understand PPPoE still stands.
We are not talking about 99% clients who do not understand what PADI is. We are talking about a ticket that was logged with the extracts below.
Here is the response i got.
Your ticket was sent during an outage which affected the WHOLE Vumatel network in JHB yesterday.
A reply that says there was an area wide outage (which there was and would lead to padis not making it to us, and pados to you) is 100% correct and the technician who replied did know what he was talking about when he responded to your ticket after the outage. The outage lasted about 30 mins and we could not respond to every single ticket before it ended. Subsequent to the outage, we were still not seeing your connection and asked you to verify you were connecting and supplied the credentials so you could run diagnostics. It’s standard procedure and we need to go through these steps. By refusing to engage the support desk constructively, your ticket is gathering dust and not moving forward.
Later in the day we responded to your ticket reminding you that we weren’t seeing a connection from you after the team checked and confirmed we were learning your MAC. So I’m not sure why you’re still unable to respond to the ticket and continue to assume we’re incompetent?
Have you tested from another device? We need this confirmation on the ticket. Then our team can escalate to AEX/Vumatel. I’m not here to provide support, that’s the support team’s job and don’t want this forum becoming a support desk- it’s not monitored 24/7 and as such it can’t be. I’m here to assist in ensuring issues are correctly escalated, assist and advise when necessary and facilitate a community around Web sQuad.
Fundamentally, our BNG is operating correctly. We’re learning your MAC addy, we’re not receiving PADI which eliminates an egress VLAN tagging issue on your end. This leaves snooping of sorts on your ONT, a faulty ONT or a faulty router.
You'd think you've never dealt with first line support before.
- Also, no, this is a common misconception. The PON light indicates you have a connection to the OLT, so your last mile is fine. It does not indicate you have a connection to the Vuma core network neother to our network. There are no status lights on the ONT which indicate you have a connection through to our network. So we use MAC lookups on L2 and compare these to what Vumatel say they are learning at the LAN port to see if we can see you, if we can, we then turn to troubleshooting why your connection is not establishing.
On a sidenote, through all of this, I didn't check if you're online. You are.. Your session came back up 15 hours 30 minutes ago, which is after we sent you a response suggesting the issue was on your router?
- Status