Nice sites Gary.
Ive been having a problem now for ages with PPPOE Connections on my desktop.
Maybe you guys can help me out.
I have a few ADSL Accounts (Telkom, Webafrica and Axxess )
The local and unshaped ( Axxess ) Accounts I connect to through Vista's PPPOE.
HOWEVER, it freezes then comes back to life. I use netlimiter to monitor it and everything works fine then around 20 seconds later all incoming and outgoing traffic stops. I wait a few more seconds ( 10 - 20 ) and then it starts up again. Speeds are also erratic and never consistent.
If I use my laptop to connect to these accounts everything is PERFECT ( Running XP )
One other strange thing worth noting. If I play COD4 connected to my local only account through the PPPOE Connection, it never dies, it only seems to happen whilst browsing or streaming/downloading.
Any Ideas guys, im soooo annoyed. Same happens in Windows 7.
Router is a Netgear DG834G
Here are my results from the ICSI Neralyzr.
Noteworthy Events
Minor Aberrations
* None of the server's bandwidth measurement packets arrived at the client
* Network packet buffering may be excessive
* An HTTP proxy was detected based on address difference
* An HTTP proxy was detected based on added or changed HTTP traffic
* Virus filtering appears to be present on your host or network
Address-based Tests
NAT detection: No NAT Detected
Your global IP address is 196.210.156.148 and matches your local one. You are not behind a NAT.
Your machine numbers TCP source ports sequentially. The following graph shows connection attempts on the X-axis and their corresponding source ports on the Y-axis.
port sequence plot
DNS-based host information: OK
You are not a Tor exit node for HTTP traffic.
You are listed on the Spamhaus Policy Based Blacklist, meaning that your provider has designated your address block as one that should not be sending any email.
The SORBS DUHL believes you are using a dynamically assigned IP address.
Reachability Tests
General connectivity: OK
Basic UDP access is available.
Direct UDP access to remote DNS servers (port 53) is allowed.
The applet was also able to directly request a large DNS response.
Direct UDP access to remote MSSQL servers (port 1434) is allowed.
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote NetBIOS servers (port 139) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is blocked.
This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Network Access Link Properties
Network latency measurements: Latency: 300ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 300 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency: 220ms
The time it takes your computer to set up a TCP connection with our server is 220 msec, which is good.
Network bandwidth measurements: Upload 6.7 Kbit/sec, Download 3.3 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 6.7 Kbit/sec. This rate could be considered quite slow, and will affect your user experience if you perform large transfers.
Your Downlink: We measured your downlink's receiving bandwidth at 3.3 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 5700 ms, Downlink 390 ms
We estimate your uplink as having 5700 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
We estimate your downlink as having 390 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic.
HTTP Tests
Address-based HTTP proxy detection: Warning
An I/O error occurred during the test. The test result code is 34.
Header-based HTTP proxy detection: Warning
Changes to headers or contents sent between the applet and our HTTP server show the presence of an otherwise unadvertised HTTP proxy
The following headers had their capitalization modified by the proxy:
* Content-Length
* Content-Type
The following headers were added by the proxy to HTTP responses:
* Via: [1.1 nc5-rba (NetCache NetApp/6.0.3)]
The detected proxy reordered the headers sent from the server
The detected HTTP proxy changed either the headers the applet sent or the HTTP response from the server. We have captured the changes for further analysis.
HTTP proxy detection via malformed requests: OK
Deliberately malformed HTTP requests arrive at our server unchanged. Thus, the proxies along your path are able to transparently forward invalid HTTP traffic.
Filetype-based filtering: Note
Files of type exe remain unmodified by the network.
Files of type mp3 remain unmodified by the network.
Files of type torrent remain unmodified by the network.
A test "virus" (the benign EICAR test file that antivirus vendors recognize as a test) was blocked or modified in transit.
JavaScript-based tests: OK
The applet was not run from within a frame.
Your web browser reports the following cookies for our web page:
* netAlizEd = BaR (set by our server)
* netalyzrComplete = True (set by our server)
Your web browser was unable to fetch an image using IPv6.
HTTP caching behavior: OK
There is no suggestion that a transparent HTTP cache exists in your network.
DNS Tests
Restricted domain DNS lookup: OK
We are able to successfully lookup a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server.
Unrestricted domain DNS lookup: OK
We are able to successfully lookup arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
DNS resolver address: OK
The IP address of your ISP's DNS Resolver is 196.26.52.130, which resolves to dnscache2-rba-qsa.is.co.za.
DNS resolver properties: Lookup latency: 390ms
Your ISP's DNS resolver requires 390 msec to conduct an external lookup, and 50 msec to lookup an item in the cache.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver does not use EDNS.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
Your ISP's DNS resolver respects a TTL of 0 seconds.
Your ISP's DNS resolver respects a TTL of 1 seconds.
DNS glue policy: OK
Your ISP's DNS resolver accepts generic glue records located in subdomains of the queried domain.
Your ISP's DNS resolver accepts additional (glue) records for nameservers located in subdomains of the queried domain.
Your ISP's DNS resolver follows CNAMEs when it is in the same domain.
DNS resolver port randomization: OK
Your ISP's DNS resolver properly randomizes its local port number.
The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis.
port sequence plot
DNS lookups of popular domains: OK
74 of 74 popular names were resolved successfully. Show all names.
In the following table reverse lookups that failed but for which a Start Of Authority (SOA) entry indicated correct name associations are shown using an "X", followed by the SOA entry. Absence of both IP address and reverse name indicates failed forward lookups.
Name IP Address Reverse Name/SOA
3 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names.
Name IP Address Reverse Name/SOA
www.f-secure.com 196.33.166.209 X (ns1.is.co.za)
www.trendmicro.com 196.33.166.232 X (ns1.is.co.za)
www.visa.com 196.33.166.210 X (ns1.is.co.za)
1 popular name has a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names.
Name IP Address Reverse Name/SOA
www.postbank.de 195.50.155.73 X
DNS results wildcarding: OK
Your ISP correctly leaves non-resolving names untouched.
Host Properties
System clock accuracy: OK
Your computer's clock agrees with our server's clock.
