Can a bad patch cable cause this?

I have a home network with a linksys router on a cable modem. The
router is about 4 years old and I have only 3 of the 4 ports used. A
few weeks ago I started having some serious slow down and high package
loss when going out to the Internet. There were no problems as long as
I stayed within my network. I did everything I could think of, from
upgrading the router firmware, changing settings, to calling comcast.
The problem seemed to be with the router as plugging one computer into
the cable modem (and cloning the MAC address) worked fine. I was about
to give up and buy a new router when I decided to try connecting only
one computer to the router. For all three of my computers it worked
fine as long as I had only one plugged it. Adding a 2nd computer would
work as long as it wasn't my laptop.

Now the cable to my laptop doesn't fit extremely well and has always
needed to be jiggled to make it work. I ended up trying a new cable
and now all my problems have gone away.

My only conclusion was the cable was the cause of the problem. But it
was working fine when connected to the router alone and only external
traffic was affected. Is this really something a faulty cable would
cause or is it likely that I did something else accidentially to fix
this problem?

Tom Cat wrote:
> I have a home network with a linksys router on a cable modem. The
> router is about 4 years old and I have only 3 of the 4 ports used. A
> few weeks ago I started having some serious slow down and high
package
> loss when going out to the Internet. There were no problems as long
as
> I stayed within my network.

Ie., packet flow, etc was fine within your lan with no noticable signs
of trouble.

>I did everything I could think of, from
> upgrading the router firmware, changing settings, to calling comcast.
> The problem seemed to be with the router as plugging one computer
into
> the cable modem (and cloning the MAC address) worked fine. I was
about
> to give up and buy a new router when I decided to try connecting only
> one computer to the router. For all three of my computers it worked
> fine as long as I had only one plugged it. Adding a 2nd computer
would
> work as long as it wasn't my laptop.
>
> Now the cable to my laptop doesn't fit extremely well and has always
> needed to be jiggled to make it work. I ended up trying a new cable
> and now all my problems have gone away.

If it was _just_ a patch cord problem, signs of it should have shown in
lan connections as well inet traffic.

> My only conclusion was the cable was the cause of the problem. But
it
> was working fine when connected to the router alone and only external
> traffic was affected. Is this really something a faulty cable would
> cause or is it likely that I did something else accidentially to fix
> this problem?

My guess is that your ISP was:
a: experiencing temporary problems
b: in the throws of a new service roll out, etc.
c: reconfiguring the CM setup on the _cable_ side of your modem

To investigate:
a: ping your default GW
ping your DNS servers (in order listed)
http to a site via IP rather than by name
traceroute to an IP then by name
view your CM logs via (usually) http://192.168.100.1/

b: go here and see what you can find for your ISP/area:
http://www.dslreports.com/

c: see b above
difficult to know how they may change your "service level"
by way of the config loaded at boot (a TFTP setup that can
cap service in several ways on a DOCSIS modem)

A _very_ good setup/diagnostic primer is here:
http://homepage.ntlworld.com/robin.d...ips/index.html

Except for dslreports above or your CM logs, you have to try these as
soon as you note any service problems -- once the symptoms are gone, so
are the clues/evidence

hth,
prg
eamil above disabled

prg wrote:
> Tom Cat wrote:

Thanks for the reply

> Ie., packet flow, etc was fine within your lan with no noticable
signs
> of trouble.
>
Yes

>
> If it was _just_ a patch cord problem, signs of it should have shown
in
> lan connections as well inet traffic.
>

That's why I thought i'd ask here.

>
> My guess is that your ISP was:
> a: experiencing temporary problems

I called comcast they claimed there were no problems and no upgrades.

> To investigate:
> a: ping your default GW

did this. Time is just under 30msec(is that slow??)

> ping your DNS servers (in order listed)

primary ping time is just over 9msec
secondary was just over 10msec

> http to a site via IP rather than by name
I didn't think to do this. If the problem reoccurs I try this.

> traceroute to an IP then by name

traceroute by name would have random timeouts. I didn't think to try
by IP. Will do that the next time.

> view your CM logs via (usually) http://192.168.100.1/
>

This was interesting. I have an RCA cable modem (which I'm leasing
from comcast). The page loads except the images all timeout. Could
this be a cable modem problem? However Comcast says the checked my
modem and everything was working correctly.

> b: go here and see what you can find for your ISP/area:
> http://www.dslreports.com/
>

This is a great site. Thanks for telling me about it. Thanks to this
site I found the http://192.168.100.1/moreInfo.html page. This page
loaded except for the images which all timed out. Looking at the
information it provides and the info on dslreports.com, everything
seems to be good with the modem.

> c: see b above
> difficult to know how they may change your "service level"
> by way of the config loaded at boot (a TFTP setup that can
> cap service in several ways on a DOCSIS modem)
>

No discussion or reports of Comcast doing anything in my area.

> A _very_ good setup/diagnostic primer is here:
> http://homepage.ntlworld.com/robin.d...ips/index.html
>

Another good site. Thanks!

> Except for dslreports above or your CM logs, you have to try these as
> soon as you note any service problems -- once the symptoms are gone,
so
> are the clues/evidence
>

Yep looks like once the problem is gone I can't find what caused it.
Thanks.

-Tom

prg <(E-Mail Removed)> wrote:
> If it was _just_ a patch cord problem, signs of it should have shown in
> lan connections as well inet traffic.

Unless perhaps it generated enough bad frames on the network to give
the router trouble and those frames were ignored by the other hosts.
These routers are pretty much all software right? And they don't
exactly have the biggest baddest CPUs in them.

> To investigate:
> a: ping your default GW

I'd also try pinging with increasing packet sizes. Often when I'm
having trouble with my SBC DSL (ok, not cable modem but still... and
it seems to be quite often in the evenings, go figure...) I can get
~decent ping results with the default size, but as I increase the size
of the ICMP Echo Requests the loss rates increase markedly.


rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

Rick Jones wrote:
> prg <(E-Mail Removed)> wrote:
> > If it was _just_ a patch cord problem, signs of it should have
shown in
> > lan connections as well inet traffic.
>
> Unless perhaps it generated enough bad frames on the network to give
> the router trouble and those frames were ignored by the other hosts.
> These routers are pretty much all software right? And they don't
> exactly have the biggest baddest CPUs in them.

That reminds me... I meant to mention that you can usually get an idea
of bad connections by checking $ifconfig -a or $netstat -t -s for some
summary counts indicating errors -- usually hardware related.

> > To investigate:
> > a: ping your default GW
>
> I'd also try pinging with increasing packet sizes. Often when I'm
> having trouble with my SBC DSL (ok, not cable modem but still... and
> it seems to be quite often in the evenings, go figure...) I can get
> ~decent ping results with the default size, but as I increase the
size
> of the ICMP Echo Requests the loss rates increase markedly.

Well, on ethernet the MTU is 1500 -- no need to try larger as they will
fragment. And with pppoe the MTU is 1492. You want to try _smaller_
packet sizes, not larger. The "smallest" recommendation is in the
range of 1320-1380 (rule-of-thumb).

prg