Official Web Africa thread

Any one else getting packet loss issues in Dota2 on Webafrica? :cry: I've had a call open with them for ages now, 100mbps fibre line, and when playing Dota2 one game will be fine, next game up to 66% packet loss regularly. Tested all equipment, lowered MTU on router, Telkom/Openserve has come and respliced and tested the line. Telkom technician said I was second person that day in my suburb complaining of packet loss through WebAfrica. It's infuriating. You can't even predict it. Even rebooting router between games doesn't help. Going to try a trial account with another ISP, and if that works, then I'm ditching webAfrica. Been a customer of theirs for about 10 years, was fine for adsl, but no fix or real help so far for this :(
 
Please DM us with your account details and we will get support for this asap
 
DSL Console

So, since a few days into this month the DSL Console has not been working properly, so on the 7th I told WA Helper who looked into the matter and got this reply from the developers "Usage is one day behind for whole base. We expect catch up in 1 day"

Well as on now my last update was at 05:44 yesterday morning. So much for catching up within a day :mad: On top of this, this issue has been happening on a regular basis over the months in various forms

What amazes me is that WA takes no ownership and doesn't bother to inform people. They say it will be fixed, and then it gets worse. My mind boggles and I wonder how many other things go wrong that we do not know about (I guess that is why WA goes with no communication)
 
Fulton17 said:
So, since a few days into this month the DSL Console has not been working properly, so on the 7th I told WA Helper who looked into the matter and got this reply from the developers "Usage is one day behind for whole base. We expect catch up in 1 day"

Well as on now my last update was at 05:44 yesterday morning. So much for catching up within a day :mad: On top of this, this issue has been happening on a regular basis over the months in various forms

What amazes me is that WA takes no ownership and doesn't bother to inform people. They say it will be fixed, and then it gets worse. My mind boggles and I wonder how many other things go wrong that we do not know about (I guess that is why WA goes with no communication)
Click to expand...

We have replied to your direct email
 
Guys please help? I have a ticket open from the 3rd with NO feedback to date - 5812709

Also when I upgraded my fibre line it was a back and forth for days with your team telling me to do speedtests etc and send results

What transpired was that although the speed was 'upgraded' it wasnt done on the backend and that took a whole 5 seconds for a competent techy to fix
 
TheTwo said:
Guys please help? I have a ticket open from the 3rd with NO feedback to date - 5812709

Also when I upgraded my fibre line it was a back and forth for days with your team telling me to do speedtests etc and send results

What transpired was that although the speed was 'upgraded' it wasnt done on the backend and that took a whole 5 seconds for a competent techy to fix
Click to expand...

The team will be in contact shortly to ensure your support Sir - thank you for your time
 
Anyone else experiencing issues with browsing which look to be related to DNS (pages load sometimes and then don't when you try again). This started from last night. The default DNS servers assigned by WA are IS and then Google as a backup. I'm getting a lot of packet loss to the IS DNS server which is probably why my web browsing is so erratic.

Ping test to WA assigned primary DNS (dnscache1.is.co.za):

PING 168.210.2.2 (168.210.2.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 168.210.2.2: icmp_seq=4 ttl=57 time=15.647 ms
64 bytes from 168.210.2.2: icmp_seq=5 ttl=46 time=22.033 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 168.210.2.2: icmp_seq=10 ttl=57 time=15.832 ms
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 168.210.2.2: icmp_seq=13 ttl=57 time=18.325 ms
Request timeout for icmp_seq 14
64 bytes from 168.210.2.2: icmp_seq=15 ttl=57 time=15.599 ms
64 bytes from 168.210.2.2: icmp_seq=16 ttl=57 time=15.180 ms
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
64 bytes from 168.210.2.2: icmp_seq=19 ttl=57 time=15.810 ms
64 bytes from 168.210.2.2: icmp_seq=20 ttl=57 time=15.854 ms
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
^C
--- 168.210.2.2 ping statistics ---
24 packets transmitted, 8 packets received, 66.7% packet loss
round-trip min/avg/max/stddev = 15.180/16.785/22.033/2.177 ms

Ping test to secondary DNS server (Google):

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=16.999 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=19.205 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.448 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=16.339 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=16.334 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=16.863 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=16.558 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=16.283 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=16.331 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=17.968 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=29.486 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=55 time=33.269 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=55 time=14.929 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=55 time=18.040 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=55 time=16.507 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.929/18.771/33.269/5.082 ms

In any case, just hard coded the primary and secondary DNS on my router to Google (8.8.8.8 and 8.8.4.4). If anyone is having the same symptoms then this should resolve it.
 
ndocrat said:
Anyone else experiencing issues with browsing which look to be related to DNS (pages load sometimes and then don't when you try again). This started from last night. The default DNS servers assigned by WA are IS and then Google as a backup. I'm getting a lot of packet loss to the IS DNS server which is probably why my web browsing is so erratic.

Ping test to WA assigned primary DNS (dnscache1.is.co.za):

PING 168.210.2.2 (168.210.2.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 168.210.2.2: icmp_seq=4 ttl=57 time=15.647 ms
64 bytes from 168.210.2.2: icmp_seq=5 ttl=46 time=22.033 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 168.210.2.2: icmp_seq=10 ttl=57 time=15.832 ms
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 168.210.2.2: icmp_seq=13 ttl=57 time=18.325 ms
Request timeout for icmp_seq 14
64 bytes from 168.210.2.2: icmp_seq=15 ttl=57 time=15.599 ms
64 bytes from 168.210.2.2: icmp_seq=16 ttl=57 time=15.180 ms
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
64 bytes from 168.210.2.2: icmp_seq=19 ttl=57 time=15.810 ms
64 bytes from 168.210.2.2: icmp_seq=20 ttl=57 time=15.854 ms
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
^C
--- 168.210.2.2 ping statistics ---
24 packets transmitted, 8 packets received, 66.7% packet loss
round-trip min/avg/max/stddev = 15.180/16.785/22.033/2.177 ms

Ping test to secondary DNS server (Google):

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=16.999 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=19.205 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=16.448 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=16.339 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=16.334 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=16.863 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=16.558 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=16.283 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=16.331 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=17.968 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=29.486 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=55 time=33.269 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=55 time=14.929 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=55 time=18.040 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=55 time=16.507 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.929/18.771/33.269/5.082 ms

In any case, just hard coded the primary and secondary DNS on my router to Google (8.8.8.8 and 8.8.4.4). If anyone is having the same symptoms then this should resolve it.
Click to expand...

Please DM us with your details - are you still having this issue and at what time? Might be our upstream DNS cache server . If need be you could configure your router with the google public DNS settings
 
Anyone else with webafrica experience outage from about 00:10? Frustrating
 
Reported fibre outages from our providers are as follows - Engineers are on site in process of resolving as we speak - please see below:

Fibre services in the FTTH : Telkom : Moreleta / Pretoria and surrounding areas area may still be inaccessible due to an outage. Logged on : 18-Aug 08:51 Updated on : {outageApi.getOutageUpdateDate()} {outageApi.getOutageUpdateTime()}
Start Date: 2017-08-18 08:51:20
Status: Open


Fibre Service services in the FTTH : Fibrehoods : Glenhazel, Orange Grove, Northriding area may still be inaccessible due to an outage. Logged on : 2017-08-18 11:18:25

ADSL services in the Stellenbosch 2 (021880, 021882-021883, 021886-021887) area may be inaccessible due to an outage. Logged on : 18-Aug 01:05
Start Date: 2017-08-18 01:05:48
Status: Open
 
ADSL services in the aspen hill sdc e6a9a msan (011432, 011682) area may be inaccessible due to an outage. Logged on : 22-Sep 06:53
Start Date: 2017-09-22 06:53:56
 
Mine is also very slow. I see the Afrihost people are also complaining.
 
Hi,

I have also noticed the really slow WebAfrica connections as of late. This happens at my home and at my father's home. We are both on 20mbit ADSL connections which are connecting at 20mbit (with no line issues) yet when running a Speedtest from both locations I get very different results. Both are not acceptable, but my Dad's is way worse than mine. We are also both using capped accounts, I am on a 200Gb (Gold I think, the one that costs more) and he is on the standard 100Gb. They can't use their 20mbit line to watch Netflix, which is all they really use it for, as it buffers constantly.

Mine:
https://imgur.com/f46TJAY

My Dad's:
https://imgur.com/CJlTHBg

What's going on, this isn't acceptable...
 
KRayn3r said:
Hi,

I have also noticed the really slow WebAfrica connections as of late. This happens at my home and at my father's home. We are both on 20mbit ADSL connections which are connecting at 20mbit (with no line issues) yet when running a Speedtest from both locations I get very different results. Both are not acceptable, but my Dad's is way worse than mine. We are also both using capped accounts, I am on a 200Gb (Gold I think, the one that costs more) and he is on the standard 100Gb. They can't use their 20mbit line to watch Netflix, which is all they really use it for, as it buffers constantly.

Mine:
https://imgur.com/f46TJAY

My Dad's:
https://imgur.com/CJlTHBg

What's going on, this isn't acceptable...
Click to expand...
+1
My 10mbs 100GB is literally crawling. Struggling to get more than 5kb/s on a torrent. Streaming isn't that great either.
 
A suggestion for netflix is the moment you have buffering issues is to lower your download quality in your profile. Uses way less data and honestly you cannot tell the difference unless you have an UHD TV and are stream UHD.
That said WebAfrica are starting to drop the ball, I am also a capped customer and they seem to have started throttling accounts during peak periods.
 
Please DM us your customer code - with a brief description of the issue - so we are able to investigate and tackle the root causes - or at the very least ensure you are guys are fully informed of whats happening - thank you guys for always being superb and helping us to help you !
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X