[c-nsp] rancid and inventory with "^"

[Tassos Chatzithomaoglou]

I believe i'm talking about a different issue.
In my case it's like rancid's parser cuts randomly a part of the 
inventory whenever a string with "^" is met.
I have checked the cli output and this doesn't change.

--
Tassos


Alexander Clouter wrote on 08/09/2010 10:58:
> Hi,
>
> * john heasley<heas at shrubbery.net>  [2010-09-07 13:35:26-0700]:
>    
>> Tue, Sep 07, 2010 at 09:39:00AM +0100, Alexander Clouter:
>>      
>>>>    !NAME: "temperature outlet 9 ", DESCR: "module 9 outlet temperature Sensor"
>>>>    !NAME: "temperature inlet 9 ",  DESCR: "module 9 inlet temperature Sensor"
>>>> + !NAME: "temperature device-1 9 ", DESCR: "module 9 device-1 temperature Sensor"
>>>> + !NAME: "temperature device-2 9 ", DESCR: "module 9 device-2 temperature Sensor"
>>>>    !opv1^T^LB
>>>>          
>> fwiw, this would strike me a either failing hardware (SMbuss or sensor)
>> or a s/w bug thats reading outside of device ID buffer range or an
>> improperly flashed device ID.  if it flaps, its probably not the latter.
>>
>>      
> Cisco said "there might be an I2C glitch".  Makes me wonder if Cisco
> bitbang the I2C bus off some GPIO pins and much up the timing if the
> router is under load.
>
>    
>> it could also be a s/w bug that is just writing junk to the tty when this
>> command is run.  you can speculate based upon the bahavior.
>>
>>      
> Indeed, you could speculate pretty much anything regarding an opaque
> box.  :)
>
>    
>>> Anyway, there was a thread here that kicked this off into life:
>>>
>>> http://marc.info/?l=cisco-nsp&m=126780984709176&w=2
>>>        
>> and that could be the s/w just not being patient enough for those devices.
>> if the command returns an error when it fails to reach devices it knows to
>> exist, then rancid can be altered to fail and retry.
>>
>>      
> There is no error.  To me that looks like either a buffer length not
> being properly checked, a NULL byte at the end of a string going AWOL
> (think 'strncpy') or there is crud just coming off the I2C bus (for
> whatever reason) and IOS is trying it's best to make the output usable;
> even if that means removing unusable guff.
>
> To be frank, it's rare that the vendor ever does the right thing so I
> doubt it's IOS trying to do the Right Thing(tm) :)
>
> Cheers
>
>