On one particular SM, for every outgoing unicast packet there is a CarSenseLost Error. The Ethernet pigtail is not currently terminated into any equipment. The only thing present is the RF link. Power level is -78 and link test is 100/100.
Could a bad power supply cause this? I have seen in and outerrors before on units with bad cables, but never CarSenseLost. Could it also be because the Ethernet pigtail is unterminated? I just got a Cisco 2514 with AOI interfaces which just have Ethernet 10-Base-T Tranceivers plugged into them. One thing I noticed is that if I have one of the interfaces up, but not terminated into anything, there is an error for every outgoing packet. As soon as the interface is termianted, the errors go away. Same thing with Canopy maybe?
Thanks in advance.
Just a guess, but are you running 8.1.4? I think I read something in the release notes regarding this as a known issue.
Aaron
Nope, 6.1.
I get the same thing with 7.3.6 and 7.2.9. Typically when I see the high CarSense Loss there is also no Ethernet link. If the cable is not connected to anything the CarSense Lose seems to climb. I just ignore the figures and wait for the client to plug the computer back in then I reboot the SM when they aren;t using it to reset the stats.
Thanks for the reply. It makes me feel a little better about the install. I will have to wait until I terminate it into my Cisco.
What I can’t seem to understand is how it is even possible to have any type of Ethernet error if the unit is non terminated? If you ping the IP address of an unterminated radio, to my understanding it simply comes in over the RF and stops at the unit. Nothing passes down to/through the Ethernet interface.
The strange thing is that there are outgoing packets listed in the Ethernet stats, but absolutely ZERO incoming packets. There are no incoming packets because it is not plugged into anything, so how is it possible anything is going out?
Thanks again.
The outgoing stats just indicate that packets were sent to the ethernet interface. Obviously they’re not going anywhere. The stats are collected at the ethernet chip, not at the connector, so any packets coming that way will show up in the outgoing stats.
It’s like somebody watching a locked door and counting how many people go and pull on the handle. The people aren’t getting in, but they are counted.
Maybe you should take the bottom off the radio so it doesn’t fill up with bits. :lol:
But why then aren’t there corresponding IN-packets for the OUT-packets?
inoctects Count 0
inucastpkts Count 0
Innucastpkts Count 0
indiscards Count 0
inerrors Count 0
inunknownprotos Count 0
outoctets Count 1278423
outucastpktsCount 0
outnucastpkts Count 15823
outdiscards Count 0
outerrors Count 15823
RxBabErr 0
TxHbErr 0
EthBusErr 0
CRCError 0
RxOverrun 0
LateCollision 0
RetransLimitExp 0
TxUnderrun 0
CarSenseLost 15823
But why then aren't there corresponding IN-packets for the OUT-packets?
Ummm... probably because nothing is connected to the port. So where would incoming packets come from? If you are looking for incoming packets on the RF interface, try Expanded Stats-> RF Stat.
Aaron
Because there are no packets coming in. If you visualize the packet flow, you’ve got this:
Radio<---->processor<---->ethernet chip<---->RJ-45 Jack
Packets come in to the radio, and if they are not for the processor, they pass on to the ethernet. The packets are counted at the ethernet chip, so outgoing stats are updated. The packet goes nowhere, it’s just dead and gone at that point. Since there is no connection to the RJ-45 jack, there are no packets coming in, therefore none to be counted.
Make sense?
Yes that makes sense, but I still don’t follow what is generating the outgoing Ethernet packets if there is nothing connected.
Like you said, there are no incoming stats because nothing is connected. Wouldn’t it be the same for outgoing or am i just stupid?
They are likely broadcast or multicast packets (ARP, DHCP req, etc.) and the processor forwards them on to the physical Ethernet chipset and counts them. Since there is no link on the Ethernet chipset it discards them. The processor has already counted them though.
Aaron
Makes sense. I guess I will just have to wait until it’s terminated and/or replace the power supply and see where it leads me!
Carrier Sense is how Ethernet Chips know there is another connected. The radio is just indicating that it cannot detect the Carrier Sense on the Ethernet and counting it as an error.
If you were to turn off the Ethernet Port on the radio, those errors would stop.
http://en.wikipedia.org/wiki/Carrier_Se … ple_Access
Duh. What a dummy I am. Thanks for the troubleshooting tip!