Cisco Spectrum Expert - Device (UNK)

Answered Question
Jul 27th, 2009
User Badges:

Hi all,


Im finding some dificult in search the type of device that is shown me by the Cisco Spectrum Expert.


I capture the picture in attach, where it identifies a Device, which is woriking on the 802.11g RF, and the Application identifies it as a Generic WideBand Device, given the Examples of Cordless Phones or wireless routers/bridges.


I try to follow the Device Power, but where ever i was, it never goes up of -60dBm, which was only two times, and i search all the time where it appears. I'he seen no Wireless Routers/Bridges, or Cordless Phones in my site.


Any ideas of what kind of equipment it could be ?

And the (UNK), stands for what ? Unkwown ?


Best Regards,

Bruno Petrónio



Attachment: 
Correct Answer by jiflorwi about 7 years 11 months ago

Hello Bruno,


There are some definite Duty Cycle (DC) Spikes in your trace. I believe that these are responsible for your Generic Wideband interference reports. 2414 - 2412 is pretty much center frequency of channel 1, and 2462 (the other one that I saw) is the center of channel 11. This is a dead giveaway. Your card is the first generation hardware, and this hardware see's very high wi-fi DC as a generic Wideband. It was a function of the hardware, and relative lack of CPU compared to the second generation cards. Interestingly back in 2005 when this hardware was released by Cognio, there where not a lot of WLAN's that would operate at DC above 30 % in a stable fashion, which is the trigger for this classification.


This is not a bug, but a hardware limitation - and one of the reasons why the second generation of hardware was released.


Now - as for your user issues. It looks like there are some AP's (very distant) on channels in between your 1-6-11 layout. These may have a bearing - in this trace they are not loud enough to see their DC.


I would check the lowest rates enabled on the AP's - try to eliminate 1,2,5 if you can, this will lower the overall duty cycle. DC as a whole on this network does not look bad at all - just in brief bursts.


As to your question on how DC afects a wifi network. 100% is the maximum number of timeslots available on the medium. Energy in the channel causes ED to go high, and CCA (clear channel assessment) to be set negative - which of course causes all our adapters to wait. If DC is bad enough - you will have nothing working.


Now think about how Wifi works - an AP is essentially a half duplex device and must spend at least as much time listening as it does talking. In a wifi network there are only two things that 802.11 can do to recover from a failed transfer attempt - it can retransmit the packet - which will turn on the radio a second time to send data that already was sent (increasing duty cycle) or rate shift to a slower rate - since the size of the data will not change - this will also increase the duty cycle significantly.


When things are really bad - you will see a heavily loaded network gradually approach 40-50% DC and then spike to 90-100%.


I'm not certain that this is what is happening on your network. The DC overall looks good on average. But there is something spiking it periodically, and depending on the clients this can be enough to cause issues at the application layer. Hence my suggestion to eliminate the lowest rates.


You might also try changing up some of the channels. From where this capture was taken - there was virtually no activity on channel 6 and very little on 11 - there was one artifact that I saw with High DC a couple of times in channel 11 - you will see this if you run the trace through and look at the Real Time DC plot with the max hold on....I'm not certain what that is - but possibly this could be causing you issues on the site as well.


As for tracking down the generic wideband - in the trace I saw it was not active long enough to really track it down. When an interference source quits transmitting - or we quit seeing it in classification you will see the time since last update counter at the top of the device finder tab start to increment. As long as you have the device in device finder - the classification event will remain true - up to 5 minutes after the last received transmission from the device.


Hope this helps.


Jim Florwick



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
jiflorwi Mon, 07/27/2009 - 13:01
User Badges:
  • Cisco Employee,

Hi Bruno,


I can't tell much from the view that you've submitted. I'd be interested and might be able to help more with a capture file of the event. Unfortunately there are a number of devices in the world that use the same RF transmitters to do their jobs - and determining one from another at the RF layer with certainty is less than an exact science. What we can determine is that it is a transmitter and it is in your wi-fi band.


Yes - UNK stands for Unknown.


If you have a capture with this event - i can probably help you narrow this down quite a bit.



b.petronio Mon, 07/27/2009 - 14:06
User Badges:

Thank You very much Jim,


I was finding for that Device "UNK" for some days... lol


I have not that capture anymore from that previous figure, but have a real capture from a client, where im facing real problems. Disassociations, and Lower Data-Rates. Almost all quick events.



I attached a zip file, with a SiteSurvey i had made, where i could found the following occurrences, where i captured the following events:


14:32:03 - Channel Group2 @ 2414.33MHz, Device 1 , Generic WideBand (1 Sec duration, but with a high Duty-Cycle)

14:35:39 - Channel Group3 @ 2414.88MHz, Device 1 , Generic WideBand (2 Sec duration, but with a high Duty-Cycle)

14:36:06 - Channel Group4 @ 2412.28MHz, Device 1 (UNK) , Generic WideBand with High Power -55.4dBm (1 Sec duration, with a high Duty-Cycle)

14:42:43 - Channel Group5 @ 2412.82MHz, Device 1 , Generic WideBand with High Power -66.2dBm (+/- 2 Min, with a high Duty-Cycle)


and so on .. and so on... :(


The Legal SSID is the CSTDADOSWIFI, and i'm concluding that i have much more interference events i ever imagine, including from my own system. That i could manage, but the other's... i just dont know what to do ...


What it happens for instance, if the Duty-Cycle of a Channel in production reachs the 100% ? the clients disassociate ?

And the SNR decreasing from good values to near 0dB ? It decreases the Data-Rate for the users ?



The clients are complaining about loss of connectivity, and sometimes lower Data-Rates...I think that its all explained, but if i miss something, please correct me.


Interference events of 1 sec, 2 sec ??? 1 min.. 2 min..and i could not find them .. im lost in this mess.. :(


Best Regards,

Bruno Petrónio



Correct Answer
jiflorwi Tue, 07/28/2009 - 05:02
User Badges:
  • Cisco Employee,

Hello Bruno,


There are some definite Duty Cycle (DC) Spikes in your trace. I believe that these are responsible for your Generic Wideband interference reports. 2414 - 2412 is pretty much center frequency of channel 1, and 2462 (the other one that I saw) is the center of channel 11. This is a dead giveaway. Your card is the first generation hardware, and this hardware see's very high wi-fi DC as a generic Wideband. It was a function of the hardware, and relative lack of CPU compared to the second generation cards. Interestingly back in 2005 when this hardware was released by Cognio, there where not a lot of WLAN's that would operate at DC above 30 % in a stable fashion, which is the trigger for this classification.


This is not a bug, but a hardware limitation - and one of the reasons why the second generation of hardware was released.


Now - as for your user issues. It looks like there are some AP's (very distant) on channels in between your 1-6-11 layout. These may have a bearing - in this trace they are not loud enough to see their DC.


I would check the lowest rates enabled on the AP's - try to eliminate 1,2,5 if you can, this will lower the overall duty cycle. DC as a whole on this network does not look bad at all - just in brief bursts.


As to your question on how DC afects a wifi network. 100% is the maximum number of timeslots available on the medium. Energy in the channel causes ED to go high, and CCA (clear channel assessment) to be set negative - which of course causes all our adapters to wait. If DC is bad enough - you will have nothing working.


Now think about how Wifi works - an AP is essentially a half duplex device and must spend at least as much time listening as it does talking. In a wifi network there are only two things that 802.11 can do to recover from a failed transfer attempt - it can retransmit the packet - which will turn on the radio a second time to send data that already was sent (increasing duty cycle) or rate shift to a slower rate - since the size of the data will not change - this will also increase the duty cycle significantly.


When things are really bad - you will see a heavily loaded network gradually approach 40-50% DC and then spike to 90-100%.


I'm not certain that this is what is happening on your network. The DC overall looks good on average. But there is something spiking it periodically, and depending on the clients this can be enough to cause issues at the application layer. Hence my suggestion to eliminate the lowest rates.


You might also try changing up some of the channels. From where this capture was taken - there was virtually no activity on channel 6 and very little on 11 - there was one artifact that I saw with High DC a couple of times in channel 11 - you will see this if you run the trace through and look at the Real Time DC plot with the max hold on....I'm not certain what that is - but possibly this could be causing you issues on the site as well.


As for tracking down the generic wideband - in the trace I saw it was not active long enough to really track it down. When an interference source quits transmitting - or we quit seeing it in classification you will see the time since last update counter at the top of the device finder tab start to increment. As long as you have the device in device finder - the classification event will remain true - up to 5 minutes after the last received transmission from the device.


Hope this helps.


Jim Florwick



b.petronio Wed, 07/29/2009 - 13:30
User Badges:

Thank you so much,


The lowest rates were already eliminated.


I have 3 Access Points in this captured floor, distributed by channels 1,6 and 11.


Below and above that floor, another client APs, with maximum power in same channels, but not in same spot.


"there was one artifact that I saw with High DC a couple of times in channel 11"


What do u mean, by "artifact" ?

The only devices i saw (in that view), was from SSID CSTDADOSWIFI, and other hiden SSID from the same Wireless System, (00:0B:0E, is the same vendor, is that it ?)


Best Regards,

Bruno Petrónio

nathanjscott Thu, 11/04/2010 - 12:24
User Badges:

Bruno,


I have run into a similar scenerio that you uncovered in this post.  Were you ever able to find the source of the interference?  I have three of these Wideband interferers in a large hospital that are causing users to drop.  My suggestion at this point for the hospital is to move to 5GHz.


Nate

b.petronio Tue, 07/26/2011 - 16:11
User Badges:

Hello All,


Just recently i could understand that this type of interference could be an Wifi Client.

My last discover, was make traffic in a given wifi client PC, and this type of event shows up imediatly.

I dont know why, but the program doesnt identify the signal as an wifi signal, as it dont appears any mac-address of the signal as it does with a Bluetooth device.


If we go near the signal source, then we could detect an interference as "Device (OFDM)" ...hum... OFDM ?!?!?... like wifi modulation ??? hummm.. that was suspicious.

Then i went out to Spectral Graphic and realize that the Duty-Cycle had a High Percentage and perfectly affecting the WIFI channels. In this example, we had a perfect curve between the channels 4 to 8. (Channel 6)


Does anyone knows why we cant detect clients transmiting, and only BSSID's ? even if we are associated with an SSID.


Best Regards,

Bruno Petrónio

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode