So … I had the privilege of receiving an ADSL line that is about as bust as a set of lines at one of my clients. And now Telkom wants to charge me a callout charge if “the problem is not on their network”.
Heck, we already know the problem is not on their network. It is the weather! I swear, it’s the feather. I just know it. It’s wet, their cables aren’t properly insulated, it’s under ground. The line is cracking up with it and I can already tell you that in a week’s time when they actually check up on it it’s going to work properly. They already gave me the finger based on the fact that the “line syncs”. Yea, so what? What does a line sync help me if this is what my pppd logs (obviously pruned to keep it shorter) looks like this:
Dec 15 13:43:02 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 13:46:53 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 13:46:53 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:31:39 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 17:32:15 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:32:15 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:40:36 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 17:41:12 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:41:12 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:43:32 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 17:45:26 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:45:26 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:48:40 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 17:49:16 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 17:49:16 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:01:36 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 18:03:19 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:03:19 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:17:18 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 18:17:54 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:17:54 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:21:14 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 18:22:55 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:22:55 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:28:15 xacatecas pppd[6845]: No response to 3 echo-requests
Dec 15 18:30:20 xacatecas pppd[6845]: CHAP authentication succeeded
Dec 15 18:30:20 xacatecas pppd[6845]: CHAP authentication succeeded
Yes, that is an hour’s logs. That is 9 disconnects in a single hour! That is an average connect time of about 5 minutes (and that is favoring to their side on the reconnect times, in other words, the disconnect rate is actually higher – shorter time cycles). Also keep in mind that LCP echo interval on this setup is 20 seconds, with three strikes to fail: Ie, the line has to be “down” for a minute in order for me to actually pick up on it in the first place. So that actually brings us to around 3.5 minutes connected, 2 minutes down. Sorry Telkom, THAT SUCKS!
And I’ve been told previously that periodic disconnects are fine, one or two pages may fail to load but just reload it, no problem. Well, I’m sorry, but it’s not good enough. ABSA, for one, restricts my banking sessions to a single IP. It also doesn’t “resume” my ssh sessions, or ftp downloads, not to mention IPSec VPNs that has to reconfigure itself (which due to the way DNS is cached can take up to two minutes in total). Due to the fact that most of the disconnects ends up being Port-Error style (yes, that’s where THEIR dslam fails to communicate with the NAS) I usually get a different IP when I reconnect (I’m actually lucky, I seem to hop between two IPs) as I actually reconnect before the NAS realized there is a problem with the DSLAM.
Since this usually only happens with wet weather (in my case at least, I’ve had this disaster at a client where after more than a year of to and fro with Telkom we’ve decided to just order a second line and hope for the best – it worked) I can only imagine that they’re going to state “problem not on the Telkom side, callout charge of R189 applicable”. ARGH! I’m so tempted to use some really nasty language at this point but that would just be wrong, and wouldn’t help the situation anyway.
I guess I better end this rant before I end up saying something that could have stayed. It’s been a long day, with us moving offices and all and the electrician also not doing his work properly, both in terms of following requirements/specifications and some of the untidiest work I’ve come across in a while (thank God I’ve never been afraid of electrical wiring … and the fact that one of my newer recruits was originally an electrician). It may come as a surprise (even to some of my friends) but I’ve known the basic principles of electricity since before I could properly do math …
So just to conclude, I got a phone call this morning “Hi, this is XXXX from Telkom calling with regards to the line for Ultimate Linux Solutions”, “The one at Country Gardens Village or our line that you’re supposed to be moving?”, “Uhh, the one you reported”, “Ah ok, yes?”, “Is it working now?”, “It’s always been working, just not particularly well”, “Yes, but is it connecting at the moment?”, “Lady, it never didn’t connect, it just disconnects up to nine – the highest I’ve observed – times per hour. Are you going to get your cables out of the water?”, “It’s working now so I’m closing the call, bye.”.
Ok, Telkom, I’ve got nothing further to say other than “thank you very, very much for some of the shittiest service in South Africa.” Reckon I should actually be speaking with somebody higher up within Telkom, but this crap isn’t acceptable.