Internet disconnects exactly every 4 hours for 10 seconds

Forums › Spark New Zealand (including Skinny and BigPipe) › Internet disconnects exactly every 4 hours for 10 seconds

1 | 2

freitasm

BDFL - Memuneh
79250 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2183956 19-Feb-2019 20:15

BarTender:
freitasm:

Always blame @BarTender...

I'll own that.

Here's an idea (not original, got from MM): drop the connection, assign a private IP that only redirects to a static webserver with a page telling the customer to contact the call centre, and explaining why this is happening.

Better than just drop/connect, rinse, repeat...

hio77

12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

#2183962 19-Feb-2019 20:26

freitasm:
BarTender:
freitasm:

Always blame @BarTender...

I'll own that.

Here's an idea (not original, got from MM): drop the connection, assign a private IP that only redirects to a static webserver with a page telling the customer to contact the call centre, and explaining why this is happening.

Better than just drop/connect, rinse, repeat...

That's too snappy..

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

freitasm

BDFL - Memuneh
79250 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2183966 19-Feb-2019 20:33

hio77:

freitasm:

Here's an idea (not original, got from MM): drop the connection, assign a private IP that only redirects to a static webserver with a page telling the customer to contact the call centre, and explaining why this is happening.

Better than just drop/connect, rinse, repeat...

That's too snappy..

Yeah, it might cost, I don't know, about $1500 plus beer to implement. Too much...

antoniosk

2358 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2183972 19-Feb-2019 20:52

freitasm:
hio77:

freitasm:

Here's an idea (not original, got from MM): drop the connection, assign a private IP that only redirects to a static webserver with a page telling the customer to contact the call centre, and explaining why this is happening.

Better than just drop/connect, rinse, repeat...

That's too snappy..

Yeah, it might cost, I don't know, about $1500 plus beer to implement. Too much...

Seriously, where do you get these ridiculous ideas from? Customers will cope... a few months of pain is nothing. But spending money.... did all those years in Unisys teach you nothing about telcos?

________

Antoniosk

BarTender

3606 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2184099 20-Feb-2019 09:04

freitasm:

hio77:

freitasm:

Here's an idea (not original, got from MM): drop the connection, assign a private IP that only redirects to a static webserver with a page telling the customer to contact the call centre, and explaining why this is happening.

Better than just drop/connect, rinse, repeat...

That's too snappy..

Yeah, it might cost, I don't know, about $1500 plus beer to implement. Too much...

Funny you should say that, I built exactly that solution in the lab.... Perhaps if you times that number by 200 it would be more realistic as to the cost to implement...

I just deleted a whole lengthy post about my experiences in Spark about why it would cost so much to deliver such a small piece of functionality but really it can be easily summarised as:

"It's complicated"

BigPipeNZ

1170 posts

Uber Geek

Trusted

BigPipe

#2184196 20-Feb-2019 10:19

@BarTender The system we have in place in terms of re-authentication every four hours is infinitely better than the previous situation where it just wouldn't authenticate at all. It's not perfect, but it's a welcome improvement from our perspective.

To be fair, the far simpler solution to this is that the information should be added to our authentication systems properly in the first place. It's part of the process when we place your order, but it was missed with Nathan's connection. If that had happened, he never would have experienced the problem. It's included as part of our troubleshooting steps and our training for this reason - it's one of the first things we should be checking. It's not overly common, but there's always an edge case where it might be the cause of the problem. It's something I'll be bringing up in training this arvo, with the expectation that it shouldn't be a problem moving forward.

bigpipe.co.nz
https://www.facebook.com/BigPipeNZ
https://twitter.com/BigPipeNZ

BarTender

3606 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2184226 20-Feb-2019 10:54

BigPipeNZ:

@BarTender The system we have in place in terms of re-authentication every four hours is infinitely better than the previous situation where it just wouldn't authenticate at all. It's not perfect, but it's a welcome improvement from our perspective.

To be fair, the far simpler solution to this is that the information should be added to our authentication systems properly in the first place. It's part of the process when we place your order, but it was missed with Nathan's connection. If that had happened, he never would have experienced the problem. It's included as part of our troubleshooting steps and our training for this reason - it's one of the first things we should be checking. It's not overly common, but there's always an edge case where it might be the cause of the problem. It's something I'll be bringing up in training this arvo, with the expectation that it shouldn't be a problem moving forward.

You should ask to get emailed the Anonymous reports. I wrote a cron job that emails people in the correct team daily the number of Anonymous users on the network and all the information required for remediation.

Un-provisioned users have had service on the Spark side (not when Bigpipe ran their own stack as that was completely different and I had no visibility of it) since my code changes went in and all customers were moved off the old authentication stack where everyone had a "sticky" IP to a true dynamic IP each time they re-authenticated and were allocated an IP address from the pool on the BNG.

That all changed around 2014 from memory when the authentication stack I built was progressively rolled out across the country for Spark.

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

BigPipeNZ

1170 posts

Uber Geek

Trusted

BigPipe

#2184242 20-Feb-2019 11:20

Not a bad call. I have a feeling that might have already been investigated, but it's definitely worth bringing up again.

bigpipe.co.nz
https://www.facebook.com/BigPipeNZ
https://twitter.com/BigPipeNZ

Nil Einne

469 posts

Ultimate Geek

#2210435 3-Apr-2019 23:57

An obvious issue with redirecting is that as much of the web has moved to HTTPS, people are going to get errors that may cause confusion. Either HTTPS for most sites will need to be blocked so the connection will just fail and people will just think their internet is completely broken, or you'd allow it but try to redirect so most browsers will give security warnings. While most OSes are designed to deal with captive portals to some extent and most of these systems will likely work even if it's an ethernet connection, many of them are fairly uninstrusive so easy to miss if it's not something you're expecting. I mean browsers themselves could directly detect & inform the user of a captive portals but I've never seen one that does.

Note also when the user does become aware, they ultimately need a way to tell the ISP. While most will have mobile phones with the ability to make network calls, increasingly people are prefering email or live chat, and sometimes even social media for support contact. I mean BigPipe don't even have a support number. Sure ultimately need some way to contact their ISP for support when things are genuinely broken. And most will have data. And likewise probably most who actually set up their phone to use their wifi can figure out how to turn it off, (and some phones will automatically disable a non working wifi when there's working mobile data). But ultimately you're adding complications for people trying to get help which don't have to be there and to fix a problem which is probably your fault.

I mean simply whitelisting Gmail will probably cover like 80% of email contact. (Random guess.) Live Mail and Yahoo maybe another 19%. Plus Facebook and Twitter most social media. And your captive portal can also have live chat etc. But still all these seem to be a lot more complicated then the solution Spark chose.

1 | 2