dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5330
share rss forum feed

SBG6580 Ethernet Slower than Wireless

Why is that? How do I fix it?



Trebonious
Premium
join:2001-06-29
Dallas, TX
Reviews:
·Time Warner Cable

Without knowing your entire setup, try a few of the following if you haven't yet.

•Power Cycle the modem
•Try a different cable to connect the pc
•Try setting your network settings to "Obtain automatically" if you have it set for a static LAN address
•Try a different port on the Modem itself
•Try a different PC

Those are just some basic troubleshooting steps. Failing all that, try a factory reset on the modem itself.

Beyond that, without more information there's not a lot to determine where the issue is.

If all the above fails to yield a satisfactory result, I would exchange the modem for a new one if at all possible.

The SBG6580 has gig-E for devices capable.



Nick21

join:2010-02-03
New York, NY
reply to ineedhelp123

Uncheck everything under the firewall tab, especially IP Flood Detection.



Jameson
Premium
join:2004-05-28
united state
kudos:1
reply to ineedhelp123

Please run this test:

»netalyzr.icsi.berkeley.edu/

When it's finished, post the result URL here.


Twisted337

join:2011-05-18
Las Vegas, NV

I am also running the same modem.Can someone please tell me if these results are bad and how to fix my issues?TY so much.

Summary of Noteworthy Events –
Major Abnormalities
Your DNS resolver manipulates results for IPv6 addresses
Minor Aberrations
Certain TCP protocols are blocked in outbound traffic
Network packet buffering may be excessive
Virus filtering appears to be present on your host or network
Your DNS resolver returns results even when no such server exists
Address-based Tests +
NAT detection (?): NAT Detected
Local Network Interfaces (?): OK
DNS-based host information (?): OK
NAT support for Universal Plug and Play (UPnP) (?): Not found
Reachability Tests –
TCP connectivity (?): Note
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 prohibited.
This means you cannot send email via SMTP to arbitrary mail servers. Such blocking is a common countermeasure against malware abusing infected machines for generating spam. Your ISP likely provides a specific mail server that is permitted. Also, webmail services remain unaffected.
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 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 OpenVPN servers (port 1194) is allowed.
Direct TCP access to remote PPTP Control servers (port 1723) is allowed.
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.
UDP connectivity (?): OK
Basic UDP access is available.
The applet was able to send fragmented UDP traffic.
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 OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote MSSQL servers (port 1434) is blocked.
This is most likely due to a filtering rule against the Slammer worm.
Traceroute (?): OK
It takes 10 network hops for traffic to pass from our server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses.
10.248.108.3 (0 ms)
ec2-75-101-160-166.compute-1.amazonaws.com (0 ms)
216.182.232.64 (0 ms)
*
*
*
*
72.21.221.10 (1 ms)
sestdsrj01-ae1.0.rd.lv.cox.net (72 ms)
24-234-6-26.ptp.lvcm.net (80 ms)
Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.
Network Access Link Properties –
Network latency measurements (?): Latency: 94ms Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 94 msec, which is good.
We recorded no packet loss between your system and our server.
TCP connection setup latency (?): 94ms
The time it takes your computer to set up a TCP connection with our server is 94 msec, which is good.
Network background health measurement (?): no transient outages
During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages.
Network bandwidth measurements (?): Upload 3.4 Mbit/sec, Download 13 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 3.4 Mbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 13 Mbit/sec. This level of bandwidth works well for many users.
During this test, the applet observed one reordered packet.
Network buffer measurements (?): Uplink 490 ms, Downlink 150 ms
We estimate your uplink as having 490 msec of buffering. This level can in some situations prove somewhat high, and you may experience degraded performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. Real-time applications, such as games or audio chat, may also work poorly when conducting large uploads at the same time.
We estimate your downlink as having 150 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 (?): OK
We detected no explicit sign of HTTP proxy via IP address changes.
Content-based HTTP proxy detection (?): OK
No HTTP header or content changes hint at the presence of a proxy.
HTTP proxy detection via malformed requests (?): OK
Deliberately malformed HTTP requests arrive at our server unchanged. We are not able to detect a proxy along the path to our server using this method.
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.
HTTP caching behavior (?): OK
We detected no signs of a transparent HTTP cache in your network path.
JavaScript-based tests (?): OK
The applet did not execute within a frame.
Your web browser reports the following cookies for our web page:
netAlizEd = BaR (set by our server)
netalyzrStatus = running (set by our server)
Your web browser was unable to fetch an image using IPv6.
DNS Tests –
Restricted domain DNS lookup (?): OK
We can successfully look up 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 can successfully look up arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
Direct DNS support (?): OK
All tested DNS types were received OK.
Direct EDNS support (?): OK
EDNS-enabled requests for small responses are answered successfully.
EDNS-enabled requests for medium-sized responses are answered successfully.
EDNS-enabled requests for large responses are answered successfully.
DNS resolver address (?): OK
The IP address of your ISP's DNS Resolver is 208.67.219.13, which resolves to bld3.pao.opendns.com.
DNS resolver properties (?): Lookup latency 35ms
Your ISP's DNS resolver requires 35 msec to conduct an external lookup. It takes 4 msec for your ISP's DNS resolver to lookup a name on our server.
Your resolver correctly uses TCP requests when necessary.
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 DNS resolver accepts DNS responses of up to 512 bytes.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
Your ISP's DNS server cannot use IPv6.
No transport problems were discovered which could affect the deployment of DNSSEC.
Direct probing of DNS resolvers (?)
Your system is configured to use 5 DNS resolver(s).
The resolver at 208.67.222.222 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 67.215.65.132.
The resolver at 208.67.220.220 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 67.215.65.132.
The resolver at 68.105.28.12 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 72.215.225.9. The resolver reports the following properties:
Hostname: N/A
Version: N/A
The resolver at 68.105.29.12 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 72.215.225.9. The resolver reports the following properties:
Hostname: N/A
Version: N/A
The resolver at 68.105.28.11 can process all tested types. It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 72.215.225.9. The resolver reports the following properties:
Hostname: N/A
Version: N/A
DNS glue policy (?): OK
Your ISP's DNS resolver does not accept generic additional (glue) records — good.
Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers.
Your ISP's DNS resolver follows CNAMEs when it is in a subdomain of the queried 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.

DNS lookups of popular domains (?): OK
79 of 79 popular names were resolved successfully. Show all names.
8 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.
3 popular names have 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.
DNS external proxy (?): OK
Your host ignores external DNS requests.
DNS results wildcarding (?): OpenDNS
You appear to be using OpenDNS. OpenDNS, by default, deliberately returns addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 67.215.65.132, which resolves to hit-nxdomain.opendns.com. You can inspect the resulting HTML content here.
This is central to OpenDNS's business model. In order to support an otherwise free service, OpenDNS presents the users with advertisements whenever they make a typo in their web browser. You can disable this behavior through the OpenDNS Dashboard.
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.
www.{random}.com is mapped to 67.215.65.132.
www.{random}.org is mapped to 67.215.65.132.
fubar.{random}.com is mapped to 67.215.65.132.
www.yahoo.cmo [sic] is mapped to 67.215.65.132.
nxdomain.{random}.netalyzr.icsi.berkeley.edu is mapped to 67.215.65.132.
Another problem with the DNS server is its response to a server failure. Instead of properly returning an error when it cannot contact the DNS authority, the DNS server returns an address of 67.215.66.132. Since transient failures are quite common this can be significantly disruptive, turning a transient failure into a wrong answer without any notification to the application doing the name lookup.
DNS-level redirection of specific sites (?): OK
Your ISP does not appear to be using DNS to redirect traffic for specific websites.
IPv6 Tests –
DNS support for IPv6 (?): Warning
The DNS resolver you are using deliberately manipulates results. This can prove problematic, as you will be unable to contact an IPv6-only site: the DNS resolver is giving incorrect results for a system which has only an IPv6 address. We expected the applet to only receive cafe:babe:66:0:0:0:0:1 (an IPv6 address), instead it received the following address: 67.215.65.132.
Your DNS resolver is not on Google's IPv6 "whitelist", which means that Google does not enable IPv6 access to their services for you.
IPv4, IPv6, and Your Web Browser (?): No IPv6 Support
Your browser was unable to fetch a test image from an IPv6-only server. IPv4 performance to our IPv4-only server did not differ substantially from our IPv4/IPv6 dual-stacked one.
IPv6 Connectivity (?): No IPv6 Support
Your system appears to have no IPv6 connectivity as it was unable to contact our IPv6 test server.
Host Properties +
System clock accuracy (?): OK
Browser properties (?): OK
Uploaded Data (?): OK
Feedback