Afrihost Uncapped ADSL Feedback (Pt3)

Status
Not open for further replies.
That is correct.

While SSL does encrypt the contents of the data - the IP address the data is sent to from the client and retrieved from the host is still visible to the ISP. So while Afrihost would not be able to - without some effort - see the contents of the ssl packet, they can still pretty much tell that it is NNTP. Therefor shaped.

Pretty interesting. Will go read some articles on SSL and encryption to educate myself. Don't want to sound like an idiot.
 
Pm me details of one please? I don't have one of those

Go to their website and capped products, under the 1GB option you'll see that it is free :)

Just sign up normally for it. It will get added to you client zone as an additional product and username and password will be mailed to you :D

Each month it resets to 1GB. For free hehe.
 
That is correct.

While SSL does encrypt the contents of the data - the IP address the data is sent to from the client and retrieved from the host is still visible to the ISP. So while Afrihost would not be able to - without some effort - see the contents of the ssl packet, they can still pretty much tell that it is NNTP. Therefor shaped.

Pretty interesting. Will go read some articles on SSL and encryption to educate myself. Don't want to sound like an idiot.

I do understand that the port, source and destination are visible and should be otherwise no routing will be possible.
So an assumption is made based on ports used and destination address as to what type of data is in the packet? Maybe even usage patterns are used to classify what data it is?
 
Thought I would change to a different port now, what a mistake

Capture3.PNG

I don't understand what you complaining about I've been stuck on 18.8% / 6.25% for the past two days on a 4mb line.

I'm at 18.8% / 6.25% as well now. I get like 1 hour a day where it is 75% and maybe 3 hours a week of unshaped. Even through the night I can see my downloads' average speed is about 200kb/s, so based on this I am concluding that shaping is not relieved through out the night
 
I do understand that the port, source and destination are visible and should be otherwise no routing will be possible.
So an assumption is made based on ports used and destination address as to what type of data is in the packet? Maybe even usage patterns are used to classify what data it is?

I don't think we make any assumptions based on the port. As I understand, any port can be used for anything as long as the sender and receiver both agree that that's what they'd like to use the port for. We also see a lot of torrents can be routed via HTTP or HTTPS so using the port would never work well. We use the information from the traffic packets themselves, though the specific part of the packet that gets scanned - I couldn't say. There's a reason these systems cost kazillions of rands - they're pretty sophisticated.
 
Go to their website and capped products, under the 1GB option you'll see that it is free :)

Just sign up normally for it. It will get added to you client zone as an additional product and username and password will be mailed to you :D

Each month it resets to 1GB. For free hehe.

Have you used an Afrihost Free GB account - this would show whether it's a shaping issue vs a network routing issue.

Thanksthanks :)

Just tried both, and both seem 100% ok now.

Will compare them again if I have D3 issues again!
 
So this is my test below, even though it looks goog my speedtest shows my download speed under 1mb

Ping Test:

ping 197.242.144.102

64 bytes from 197.242.144.102: icmp_req=1 ttl=58 time=35 ms
64 bytes from 197.242.144.102: icmp_req=2 ttl=58 time=32 ms
64 bytes from 197.242.144.102: icmp_req=3 ttl=58 time=35 ms
64 bytes from 197.242.144.102: icmp_req=4 ttl=58 time=34 ms
64 bytes from 197.242.144.102: icmp_req=5 ttl=58 time=60 ms


ping 8.8.8.8

Request timeout for icmp_seq 1
64 bytes from 8.8.8.8: icmp_req=2 ttl=43 time=222 ms
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
64 bytes from 8.8.8.8: icmp_req=5 ttl=43 time=216 ms


Trace Test:

traceroute -n 197.242.144.102

1 192.168.0.1 2 ms 5 ms
2 105.236.234.6 8 ms 12 ms
3 41.181.54.8 22 ms 21 ms
4 196.44.18.2 19 ms
41.181.198.1 11 ms
5 196.44.31.1 11 ms 13 ms
6 196.44.31.6 122 ms 43 ms
7 196.44.0.2 40 ms
196.44.31.9 40 ms
8 196.31.220.1 31 ms 36 ms
9 196.31.220.2 38 ms 36 ms
10 196.30.42.1 32 ms
196.31.63.2 37 ms
11 197.242.144.1 36 ms
196.30.42.1 32 ms
12 197.242.144.1 42 ms


traceroute -n 8.8.8.8

1 192.168.0.1 9 ms
2 105.236.234.6 41 ms
3 41.181.201.9 11 ms
4 41.181.198.1 31 ms
5 196.44.18.2 15 ms
6 196.44.31.1 49 ms
7 196.44.31.6 32 ms
8 72.14.194.7 33 ms
9 Request timed out *
10 8.8.8.8 217 ms


DNS Test:

nslookup www.afrihost.com

Name: www.afrihost.com
Address: 197.242.144.102


nslookup www.google.com

Name: www.google.com
Address: 173.194.34.114
Name: www.google.com
Address: 173.194.34.113
Name: www.google.com
Address: 173.194.34.112
Name: www.google.com
Address: 173.194.34.116
Name: www.google.com
Address: 173.194.34.115


nslookup thishouldfail.afrihost.com

** server can't find thisshouldfail.com: NXDOMAIN
 
Have just tried my 1GB Capped fall-back and even that gives my under 1MB:mad: D/L with ping of 160ms (ping is fine happy there)

Download Speed: 146 kbps (18.3 KB/sec transfer rate)
Upload Speed: 782 kbps (97.8 KB/sec transfer rate)
Latency: 158 ms
‎21‎/‎05‎/‎2014‎ ‎17‎:‎30
 
Last edited:

Dodgey...

We should still be able to determine the packet signature whether it's SSL encrypted. Most of the info we need is probably in the headers and not in the data itself. Might need to speak to the more clever people, who are obviously very secretive for network security reasons. But I don't think SSL interferes with our shaping, though I can imagine the whole heartbleed thing has made a lot of traffic more SSL based that previously.

This is correct unfortunately. Over SSL, the data is encrypted, meaning you cannot see what it is being transferred, and it is being transferred over the SSL port, however, the method of transfer will still be NNTP, which is why they can still identify it.
 
Last edited:
Go to their website and capped products, under the 1GB option you'll see that it is free :)

Just sign up normally for it. It will get added to you client zone as an additional product and username and password will be mailed to you :D

Each month it resets to 1GB. For free hehe.

Dodgey...



This is correct unfortunately. Over SSL, the data is encrypted, meaning you cannot see what it is being transferred, and it is being transferred over the SSL port, however, the method of transfer will still be NNTP, which is why they can still identify it.

Not correct, strictly speaking.
The only way to "identify" SSL traffic is by means of destination port. NNTP traffic generally doesn't go over port 119 (normal nntp) or 443 (HTTPS). You can't actually identify the type of traffic at all other than by the port numbers without decrypting it.
 
Having the same problem as yesterday, my ping online is high but throughout the day it was fine.
 
Not correct, strictly speaking.
The only way to "identify" SSL traffic is by means of destination port. NNTP traffic generally doesn't go over port 119 (normal nntp) or 443 (HTTPS). You can't actually identify the type of traffic at all other than by the port numbers without decrypting it.


Yes, that is true, what I meant by method is that they could have a filter on sending addresses, such as news.AfrihostShapesmystuff.com, since they are saying they do not shape ports, but packets.

edit: I must add though, the above is unlikely, unless they have scripting methods in place to lookup the Name of the source IP for the packets.
 
Last edited:
And this is the result after "Magically Fixed My Line"

Last Result:
Download Speed: 256 kbps (32 KB/sec transfer rate)
Upload Speed: 471 kbps (58.9 KB/sec transfer rate)
Latency: 163 ms
‎21‎/‎05‎/‎2014‎ ‎19‎:‎08

Ping Test:

ping 197.242.144.102

64 bytes from 197.242.144.102: icmp_req=1 ttl=58 time=74 ms
64 bytes from 197.242.144.102: icmp_req=2 ttl=58 time=35 ms
64 bytes from 197.242.144.102: icmp_req=3 ttl=58 time=88 ms
64 bytes from 197.242.144.102: icmp_req=4 ttl=58 time=38 ms
64 bytes from 197.242.144.102: icmp_req=5 ttl=58 time=43 ms


ping 8.8.8.8

64 bytes from 8.8.8.8: icmp_req=1 ttl=43 time=217 ms
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_req=3 ttl=43 time=230 ms
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5


Trace Test:

traceroute -n 197.242.144.102

1 192.168.0.1 20 ms 30 ms
2 105.236.234.6 12 ms 9 ms
3 41.181.53.1 11 ms 30 ms
4 41.181.198.1 12 ms 10 ms
5 196.44.18.2 15 ms 33 ms
6 196.44.31.1 34 ms 13 ms
7 196.44.0.2 60 ms
196.44.31.9 32 ms
8 196.31.220.1 49 ms 34 ms
9 196.31.220.2 38 ms 35 ms
10 196.31.63.2 33 ms 38 ms
11 196.30.42.1 37 ms
197.242.144.1 40 ms
12 197.242.144.1 42 ms


traceroute -n 8.8.8.8

1 192.168.0.1 14 ms 99 ms 34 ms
2 105.236.234.6 11 ms 32 ms 12 ms
3 41.181.53.1 29 ms 18 ms 12 ms
4 41.181.198.1 95 ms 16 ms 38 ms
5 196.44.18.2 15 ms 16 ms
196.44.31.1 27 ms
6 196.44.31.1 17 ms 38 ms
196.44.31.6 70 ms
7 196.44.31.6 42 ms
41.181.139.1 53 ms 49 ms
8 41.181.139.1 57 ms
72.14.194.7 39 ms
209.85.253.1 200 ms
9 Request timed out * * *
10 Request timed out *
11 Request timed out *
12 Request timed out *


DNS Test:

nslookup www.afrihost.com

Name: www.afrihost.com
Address: 197.242.144.102


nslookup www.google.com

Name: www.google.com
Address: 173.194.34.116
Name: www.google.com
Address: 173.194.34.114
Name: www.google.com
Address: 173.194.34.112
Name: www.google.com
Address: 173.194.34.113
Name: www.google.com
Address: 173.194.34.115


nslookup thishouldfail.afrihost.com

** server can't find thisshouldfail.com: NXDOMAIN
 
Not correct, strictly speaking.
The only way to "identify" SSL traffic is by means of destination port. NNTP traffic generally doesn't go over port 119 (normal nntp) or 443 (HTTPS). You can't actually identify the type of traffic at all other than by the port numbers without decrypting it.

This was exactly my point. My NNTP runs over port 443 or 563. NNTP over port 563 is about 11kb/s. With port 443 is max 2mbps. They either classify the traffic based on usage patterns, destination and port and shape according to this class or they decrypt the traffic?
 
This was exactly my point. My NNTP runs over port 443 or 563. NNTP over port 563 is about 11kb/s. With port 443 is max 2mbps. They either classify the traffic based on usage patterns, destination and port and shape according to this class or they decrypt the traffic?

Can't decrypt the traffic and reencrypt it without the private key of the server.
 
Can't decrypt the traffic and reencrypt it without the private key of the server.

However you can play man in the middle. Have a look at a tool called Fiddler2. It almost like wireshark, but you are able to decrypt the SSL packets and view the contents
 
However you can play man in the middle. Have a look at a tool called Fiddler2. It almost like wireshark, but you are able to decrypt the SSL packets and view the contents

Interesting, will have a poke around.
Does it need the entire conversation from key exchange onward?
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X