Ethernet Interface = No Link / 100Base-TX Full Duplex

We have a subscriber that has over a 1600 RSSI and 2-3 Jitter, but her Ethernet Interface switches from No Link to 100Base-TX Full Duplex constantly. While logged on her SM, I have it updating every 2 seconds and it goes back and forth. This is obviously a problem with the link from the sm to the computer.

She has this plugged directly into her computer. No other networking equipment.

Has anyone experience this before? Before I go out to her house, what should I look for?

We have tried to solve this over the phone via plug/unplug and rebooting.

thanks in advance

Zach

Bad cable run from the SM to the computer is what usually causes such a problem. Although it could be that her computer is hard set to something like 10Mbps Full duplex or the card in her computer just is not working correctly.

Ok, the first thing I will check is the cable. If the cable and connectors look ok, I will look into the 10/100 settings.

I will be able to plug the link into my laptop also and see if it continues to happen.

Zach

P.S. Its amazing how much/fast you learn in 3 weeks time w/ this canopy stuff. :shock:

The problem could be the auto-negotiation on either her PC’s NIC or the Canopy SM. If it was a bad cable, it seems unlikely the toggle back and forth would be very consistent.

Before your truck-roll, you could force both the SM and PC NIC to the same non-negotiated settings. Even if her PC NIC doesn’t have this capability, you may find a setting on the SM that works.

But before you do that, have you tried powering down both PC and SM rather than just rebooting? If her PC has Wake-on-LAN capability, it’s important to also remove the external power to the PC for at least 10 seconds.

Thanks Teknix I will def. look into that. I’ll keep ya’ll informed.

Zach

This happened to me about a month ago. Customer kept getting “no connection” on his ethernet interface. I tested the SM / cable with my laptop and everything worked great, so the cable was good. What fixed it was putting both the AP and the SM back to all negotiation speeds on the config page (I originally had both set to 100Mbs/FDX). Once both had all four selected, suddenly he had a connection! That’s it.

UPDATE:

I originally had this Rezi configured to detect all Link Neg. Speeds. It turns out that the problem was fixed when I selected 10 Base T Full Duplex ONLY.

Thanks for you help!

Zach

wirelessSolutions wrote:
UPDATE:

I originally had this Rezi configured to detect all Link Neg. Speeds. It turns out that the problem was fixed when I selected 10 Base T Full Duplex ONLY.

Thanks for you help!

Zach


Hey, that sounds familiar! :lol:

Also check the surge suppresor. I have had 100s of these go bad. More often than bad cable.

Jaybug56 wrote:
Also check the surge suppresor. I have had 100s of these go bad. More often than bad cable.


300SS is the devil! :twisted:

yep, its definately the 300SS…

you will have to keep the pc on 10/full for the link to stay on…

I have had 3 cases this week alone with simular problems. turns out the onboard 10/100 was the problem and 1 of them had a virus and it would not clean so i reloaded windows and fixed it. they would just show connected for about 2 sec then disconnect red x then no x so on.

Also my friend fixed one this week by repairing the tcp/ip it would show connected but not go anywhere and the normal network repair would not work he used a program called “winsockxpfix.exe” works wonders.

kmeadows

Another giveaway is the ethernet stats page in the subscriber module management. I have found that often when I have connection problems involving bad cabling it is belied by high inErrors and outErrors. These are usually CarSenseLost. In a good ethernet connecion you shouldn’t see any errors. I would imagine that a bad SS would also cause these types of errors and so would be visible without a truck-roll.

I am also experiencing a similar problem though with an SM that shows none of these errors so… I guess I will try the rest of the suggestions here. thanks!

We have recently found that Motorola has made some “good” software updates to some of its code…for example the CMMmicro v2…and that it “appears” that the code auto-negotiates well with other canopy devices…but some non-canopy devices that ‘claim’ to auto-negotiate do not do those things well.

This requires more care (as the Moto software improves its actual auto-negotiate functions) to make sure that the ‘other’ device knows how to auto-negotiate…

In this case it appears that you have discovered (or already knew) that just because a NIC or router/gateway claims to have auto-negotiate capabilites, that one way to trouble-shoot is to take that variable out of the question and ‘lock it down’… :roll:

HTH…