Jump to content



Photo

Windows 7 Networking: Upload


  • Please log in to reply
72 replies to this topic

#1 Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 06 October 2012 - 01:47

Hey,

I have been getting some really bad connections when playing Minecraft. It is just so laggy. Now, I thought, why don't I do a speedtest? Png was fine, at 10ms. Download was fine, at 20Mbps But the upload just hanged, never finishing.

I test this on other computers around the house, and I get fine upload time at 900Kbps. I try switching the cable on this system. No dice.

So, I thought, why not just try a different OS? I pop my Ubuntu 12.04 x64 disk in, and ran another speedtest on it. Had to run from testmy.net because I didn't have java on there. This ran fine. So It wasn't my hardware, but my software.

Now, what is the problem with Windows? I did recently clone it to my new Samsung 830 128GB from my OCZ Vertex 60GB. But everything seems to work no problem.

Do I need to flush something?


#2 remixedcat

remixedcat

    meow!

  • Tech Issues Solved: 1
  • Joined: 28-December 10
  • Location: Vmware ESXi and Hyper-V happy clouds
  • OS: Windows Server 2012 R2
  • Phone: I use telepathy and cat meows to communicate

Posted 06 October 2012 - 20:09

update your LAN drivers.... also check windows firewall settings...

#3 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 06 October 2012 - 21:25

Updated drivers to latest version, Firewall settings are all turned off. Still no dice. I can't get an upload test. Meaning, AFAIK, that I am not getting very good upload on this system only.

#4 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 07 October 2012 - 02:20

329 views and only remixed replied? Geez, I'm tearing out my hair about this! Please guys, help!

#5 BeerFan

BeerFan

    Neowinian Senior

  • Joined: 19-July 06

Posted 07 October 2012 - 11:23

Does the testmy.net site work ok on your Windows PC?

#6 remixedcat

remixedcat

    meow!

  • Tech Issues Solved: 1
  • Joined: 28-December 10
  • Location: Vmware ESXi and Hyper-V happy clouds
  • OS: Windows Server 2012 R2
  • Phone: I use telepathy and cat meows to communicate

Posted 07 October 2012 - 11:25

can you try a different network card?

#7 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 106
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 07 October 2012 - 12:57

I would look to firewall or antivirus suites/security software your running to be the problem

#8 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 07 October 2012 - 13:26

Does the testmy.net site work ok on your Windows PC?


Umm, no?

can you try a different network card?


The network card is not the issue. I booted a Ubuntu Live-CD and did a testmy.net test and it worked with flying colors.

I would look to firewall or antivirus suites/security software your running to be the problem


I disabled MSE, just took off msconfig startup. I have no firewall.

#9 +djdanster

djdanster

    Neowin elite

  • Tech Issues Solved: 2
  • Joined: 28-October 08
  • Location: England, Great Britain
  • OS: Windows 8.1
  • Phone: Samsung Galaxy S4 White Frost

Posted 07 October 2012 - 13:41

I disabled MSE, just took off msconfig startup. I have no firewall.


Windows firewall?

#10 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 106
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 07 October 2012 - 14:10

so you have no other security software? Only MSE, I wouldn't worry too much about it to be honest -- do a file download from this box and another machine on your network via file sharing, is that working? Then its prob just security issue with either flash or java depending on site your using or port problem.

have to do a sniff to see what speedtest.net actually uses for upload - I would guess udp? Could be a problem with that -- look more into the details of the site your using for details of how the upload test is actually done so you can troubleshoot what might be causing that to fail.

sniff of the traffic never hurts. Im not home currenty or even on my own machine so can look deeper myself - but when I get home I can fire up a sniff and try a few different speed test sites to see how they differ in testing the upload speed and which ones might work for you if speedtest.net does not.

#11 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 07 October 2012 - 14:59

Windows firewall?


http://windows.micro...rity-essentials

so you have no other security software? Only MSE, I wouldn't worry too much about it to be honest -- do a file download from this box and another machine on your network via file sharing, is that working? Then its prob just security issue with either flash or java depending on site your using or port problem.

have to do a sniff to see what speedtest.net actually uses for upload - I would guess udp? Could be a problem with that -- look more into the details of the site your using for details of how the upload test is actually done so you can troubleshoot what might be causing that to fail.

sniff of the traffic never hurts. Im not home currenty or even on my own machine so can look deeper myself - but when I get home I can fire up a sniff and try a few different speed test sites to see how they differ in testing the upload speed and which ones might work for you if speedtest.net does not.


speedtest uses java and flash. testmy just uses flash I think.

#12 Detection

Detection

    Detecting stuff...

  • Joined: 30-October 10
  • Location: UK
  • OS: 7 SP1 x64

Posted 07 October 2012 - 15:14

http://windows.micro...rity-essentials



speedtest uses java and flash. testmy just uses flash I think.


Try running this test and post the results here, someone might spot something

http://netalyzr.icsi.berkeley.edu/

#13 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 07 October 2012 - 16:17


Summary of Noteworthy Events  + [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url] 



Major Abnormalities [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–



[list]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#DNSNX"]Your DNS resolver returns IP addresses for names that do not exist [img]http://n2.netalyzr.icsi.berkeley.edu/arr_err.gif[/img][/url]

[/list][/url]





Minor Aberrations [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–



[list]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#tcp_connectivity"]Certain TCP protocols are blocked in outbound traffic [img]http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif[/img][/url]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#udp_connectivity"]Fragmented UDP traffic is blocked [img]http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif[/img][/url]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#latency"]The measured packet loss was somewhat high [img]http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif[/img][/url]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#BufferResult"]Network packet buffering may be excessive [img]http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif[/img][/url]

[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#resolverProbing"]Not all DNS types were correctly processed [img]http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif[/img][/url]

[/list]



Address-based Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] – 





NAT detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_nat_detect.html"]?[/url]): NAT Detected [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Local Network Interfaces ([url="http://n2.netalyzr.icsi.berkeley.edu/info_local_interface.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS-based host information ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_hostinfo.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





NAT support for Universal Plug and Play (UPnP) ([url="http://n2.netalyzr.icsi.berkeley.edu/info_upnp.html"]?): Yes [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]



Reachability Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url] [/url]





TCP connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_tcp_connectivity.html"]?): Note [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]



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 POP3 servers (port 110) is allowed.

Direct TCP access to remote RPC servers (port 135) is allowed.

Direct TCP access to remote NetBIOS servers (port 139) is allowed.

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 allowed.

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 OpenVPN servers (port 1194) is allowed.

Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.

The applet received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.

Direct TCP access to remote SIP servers (port 5060) is allowed.

Direct TCP access to remote BitTorrent servers (port 6881) is allowed.

Direct TCP access to remote TOR servers (port 9001) is allowed.[/url]





UDP connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_udp_connectivity.html"]?): Note [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]



Basic UDP access is available.

The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.The maximum packet successfully sent was 1472 bytes of payload.

The applet was able to receive fragmented UDP traffic.

Direct UDP access to remote DNS servers (port 53) is allowed.

Direct UDP access to remote NTP servers (port 123) is allowed.

Direct UDP access to remote NetBIOS NS servers (port 137) is allowed.

Direct UDP access to remote NetBIOS DGM servers (port 138) is allowed.

Direct UDP access to remote IKE key exchange servers (port 500) is allowed.

Direct UDP access to remote OpenVPN servers (port 1194) is allowed.

Direct UDP access to remote Slammer servers (port 1434) is allowed.

Direct UDP access to remote L2 tunneling servers (port 1701) is allowed.

Direct UDP access to remote IPSec NAT servers (port 4500) is allowed.

Direct UDP access to remote RTP servers (port 5004) is allowed.

Direct UDP access to remote RTCP servers (port 5005) is allowed.

Direct UDP access to remote SIP servers (port 5060) is allowed.

Direct UDP access to remote VoIP servers (port 7078) is allowed.

Direct UDP access to remote VoIP servers (port 7082) is allowed.

Direct UDP access to remote SCTP servers (port 9899) is allowed.

Direct UDP access to remote Steam gaming servers (port 27005) is allowed.

Direct UDP access to remote Steam gaming servers (port 27015) is allowed.[/url]





Traceroute ([url="http://n2.netalyzr.icsi.berkeley.edu/info_traceroute.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Path MTU ([url="http://n2.netalyzr.icsi.berkeley.edu/info_mtu.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]



Network Access Link Properties  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url] [/url]





Network latency measurements ([url="http://n2.netalyzr.icsi.berkeley.edu/info_latency.html"]?): Latency: 59ms Loss: 7.0% [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]



The round-trip time (RTT) between your computer and our server is 59 msec, which is good.

We recorded a packet loss of 7%. This loss is very significant and will lead to serious performance problems. It could be due either to very high load on our servers due to a large number of visitors, or problems in your network. Of the packet loss, at least 7.0% of the packets appear to have been lost on the path from your computer to our servers.[/url]





TCP connection setup latency ([url="http://n2.netalyzr.icsi.berkeley.edu/info_tcp_latency.html"]?): 61ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Network background health measurement ([url="http://n2.netalyzr.icsi.berkeley.edu/info_burst_loss.html"]?): no transient outages [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Network bandwidth ([url="http://n2.netalyzr.icsi.berkeley.edu/info_bandwidth.html"]?): Upload 970 Kbit/sec, Download 6.7 Mbit/sec [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Network buffer measurements ([url="http://n2.netalyzr.icsi.berkeley.edu/info_buffer.html"]?): Uplink 6100 ms, Downlink 3400 ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]



We estimate your uplink as having 6100 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 3400 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 downloads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large downloads at the same time.



HTTP Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] – [/url]





Address-based HTTP proxy detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_addr.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Content-based HTTP proxy detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_header.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





HTTP proxy detection via malformed requests ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_malformed.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Filetype-based filtering ([url="http://n2.netalyzr.icsi.berkeley.edu/info_content_filters.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





HTTP caching behavior ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpcache.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





JavaScript-based tests ([url="http://n2.netalyzr.icsi.berkeley.edu/info_javascript.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

DNS Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url] 





Restricted domain DNS lookup ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_restricted.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]





Unrestricted domain DNS lookup ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_unrestricted.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Direct DNS support ([url="http://n2.netalyzr.icsi.berkeley.edu/info_direct_dns.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Direct EDNS support ([url="http://n2.netalyzr.icsi.berkeley.edu/info_edns_connectivity.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]





DNS resolver address ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS resolver properties ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver_behavior.html"]?): Lookup latency 100ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





Direct probing of DNS resolvers ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver_probes.html"]?) [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]



Your system is configured to use 1 DNS resolver(s).

The resolver at 192.168.0.1 (clboh-dns-cac-112) could not process the following tested types:[list]

[*]Medium (~1300B) TXT records

[*]Large (~3000B) TXT records

[/list]It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 69.16.143.110, 66.152.109.110. The resolver reports a number of additional properties. [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]Show them.[/url][/url]





DNS glue policy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_glue.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS resolver port randomization ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_random.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS lookups of popular domains ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dnslookups.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS external proxy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_proxy.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





DNS results wildcarding ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_wildcarding.html"]?): Warning [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]–[/url]





Your ISP's DNS server returns IP addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 69.16.143.110, which does not resolve. You can inspect the resulting HTML content [url="http://n2.netalyzr.icsi.berkeley.edu/uploaded/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8/key=nxpage"]here[/url].

There are several possible explanations for this behavior. The most likely cause is that the ISP is attempting to profit from customer's typos by presenting advertisements in response to bad requests, but it could also be due to an error or misconfiguration in the DNS server.

The big problem with this behavior is that it can potentially break any network application which relies on DNS properly returning an error when a name does not exist.

The following lists your DNS server's behavior in more detail.[list]

[*]www.{random}.com is mapped to 69.16.143.110.

[*]www.{random}.org is mapped to 69.16.143.110.

[*]fubar.{random}.com is correctly reported as an error.

[*]www.yahoo.cmo [sic] is mapped to 69.16.143.110.

[*]nxdomain.{random}.netalyzr.icsi.berkeley.edu is correctly reported as an error.

[/list][/url]





DNS-level redirection of specific sites ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_mitm.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]





Direct probing of DNS roots ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_roots.html"]?[/url]): [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]



IPv6 Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] – [/url]





DNS support for IPv6 ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_dns.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





IPv4, IPv6, and your web browser ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_javascript.html"]?): No IPv6 support [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]





IPv6 connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_connectivity.html"]?): No IPv6 support [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

Host Properties  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img]http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif[/img] – 

[/url]





System clock accuracy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_system_clock.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

[/url]





Browser properties (<a href="http://n2.netalyzr.icsi.berkeley.edu/info_browser_properties.html" target="_blank">?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]



Uploaded data ([url="http://n2.netalyzr.icsi.berkeley.edu/info_upload.html"]?[/url]): OK



#14 OP Mindovermaster

Mindovermaster

    Neowinian Senior

  • Tech Issues Solved: 13
  • Joined: 25-January 07
  • Location: /USA/Wisconsin/
  • OS: Debian Jessie
  • Phone: Samsung Galaxy SIII

Posted 08 October 2012 - 02:03

Update: I ran the same test as above on my Linux rig, I get the exact same outcome. So, my network is not to blame, as I understand it. Maybe I should just reinstall Windows...

#15 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 106
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 08 October 2012 - 04:37

Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.
"The applet received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.

"Latency: 59ms Loss: 7.0%"

"We recorded a packet loss of 7%. This loss is very significant and will lead to serious performance problems"

"Fragmented UDP traffic is blocked"

The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.The maximum packet successfully sent was 1472 bytes of payload.
The applet was able to receive fragmented UDP traffic.


So you got the same result when running it on linux? Strange - I don't get any of those responses at all - and if your machine/network was working correctly you sure and the hell would not have 7% packet loss. And you should be able to send and recv fragmented udp - that would explain your issue with upload tests. So your Sure your linux box got the same exact results?

"Direct TCP access to remote PPTP Control servers (port 1723) is allowed."

"Network latency measurements (?): Latency: 36ms Loss: 0.0% "

"The applet was able to send fragmented UDP traffic.
The applet was able to receive fragmented UDP traffic."

"We recorded no packet loss between your system and our server."