ISCSI Storage Serial Number Parse Error

Bug #1249006 reported by Thibaut Charry
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OCS Inventory: Windows Agent
Fix Committed
Medium
Didier Liroulet

Bug Description

Hello,

We are having issues with the parsing of Serial Numbers on "SYNOLOGY iSCSI Storage SCSI Disk Device" mount points on Windows Server 2008 R2 Standard with OCS Inventory NG Agent Version 2.0.5.2

Apache on OCS server is responding with HTTP Error 500 because "Parser.pm" perl script is not able to completely parse the inventory XML file:

[error] [client X.X.X.X] \nnot well-formed (invalid token) at line 1658, column 29, byte 59576 at /usr/lib64/perl5/XML/Parser.pm line 187\n

The error refers to the line of the SERIAL NUMBER in the inventory file sent by the Windows Agent:

[OCS XML]
<STORAGES>
 <MANUFACTURER>(Standard disk drives)</MANUFACTURER>
 <NAME>SYNOLOGY iSCSI Storage SCSI Disk Device</NAME>
 <MODEL>//./PHYSICALDRIVE3</MODEL>
 <DESCRIPTION>Disk drive</DESCRIPTION>
 <TYPE>Fixed hard disk media</TYPE>
 <DISKSIZE>11427902</DISKSIZE>
 <SERIALNUMBER>Ylᅬ￾R￱5 ￸ᅳ ユᄚル T○│</SERIALNUMBER>
 <FIRMWARE>3.1</FIRMWARE>
</STORAGES>

As I understand, I believe WMI object Win32_DiskDrive is used by the agent to retrieve storage information.

Here is the result of powershell command "Get-WmiObject Win32_DiskDrive | Select-Object DeviceId, SerialNumber":

DeviceId SerialNumber
-------- ------------
\\.\PHYSICALDRIVE2 078b2f10-c8c2-31e4-acdd-c70273f52367
\\.\PHYSICALDRIVE3 6c59fecf-f521-35da-8952-99b05413e8ee

PHYSICALDRIVE2 is correctly parsed. Here is the corresponding XML in the inventory file:

[OCS XML]
<STORAGES>
 <MANUFACTURER>(Standard disk drives)</MANUFACTURER>
 <NAME>SYNOLOGY iSCSI Storage SCSI Disk Device</NAME>
 <MODEL>//./PHYSICALDRIVE2</MODEL>
 <DESCRIPTION>Disk drive</DESCRIPTION>
 <TYPE>Fixed hard disk media</TYPE>
 <DISKSIZE>22855811</DISKSIZE>
 <SERIALNUMBER>ヒ /フ￴1 ￶¦ ᅪ ᅦ￵sg#</SERIALNUMBER>
 <FIRMWARE>3.1</FIRMWARE>
</STORAGES>

Thank you for your help.

Regards,

Changed in ocsinventory-windows-agent:
assignee: nobody → Didier Liroulet (dliroulet)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Didier Liroulet (dliroulet) wrote :

Hi,

Could you try with OCS Agent 2.1rc1 using /DEBUG=2 command line parameter, and send me SysInfo.log file created ?

Cheers

Revision history for this message
Didier Liroulet (dliroulet) wrote :

Hi.

This bug may not appear with OCS agent 2.1 rc1 or higher.

Can you check this ?

Regards

Revision history for this message
Loïc BRONDIN (l-brondin) wrote :

Hello,

The bug always appear with the OCS agent 2.1 rc1.

I join the file SysInfo.log...

Thank you for your help.

regards,

Revision history for this message
Keith Jones (k-e-jones) wrote :

Hi,

 I'm bugging a very similar issue that looks like the flipside of the same thing. Bug #1353559 if you want to have a look :-)

Revision history for this message
Keith Jones (k-e-jones) wrote :

Hi again,

 I found an interesting thread on technet's social forums. It's a little....ummm... fiery so if you have a sensitive nature I'd make sure you're prepared for some full-on geek arguments. The engineering details do seem very relevant though. It's worth reading through (http://social.technet.microsoft.com/Forums/scriptcenter/en-US/0333dd28-3207-4df8-85c3-7ff540f98464/wmi-disk-serial-number?forum=ITCG).

 It appears from some of the content, that the serial number field returned by WMI suffers from a lot differing approaches by the vendors. The data stored can suffer from endian problems and under different circumstances be variously considered as hex coded,raw binary strings or ASCII text.There even appears to be widely unpredictable expectations of whether the field should be interpreted as ASCII or Unicode depending on OS facilities.

Didier - It seems clear to me that you're devices have serial numbers that are long enough to trigger OCS to think they're hex encoded and the reality is they are just simply named in a hex-like way.

 I'll pop back to my bug and un-suggest some ideas :-)

Keith

Revision history for this message
p.deprey@linkbynet.com (p-deprey) wrote :

Hello,

We have the same problem on a physical server:

<STORAGES>
            <MANUFACTURER>(Standard disk drives)</MANUFACTURER>
            <NAME>LEFTHAND iSCSIDisk Multi-Path Disk Device</NAME>
            <MODEL>//./PHYSICALDRIVE1</MODEL>
            <DESCRIPTION>Disk drive</DESCRIPTION>
            <TYPE>Fixed hard disk media</TYPE>
            <DISKSIZE>3040866</DISKSIZE>
            <SERIALNUMBER>|￾￞ᅠP)ユᄌW C/]ᅱᅠ</SERIALNUMBER>
            <FIRMWARE>9500</FIRMWARE>
</STORAGES>

When trying to load XML manually, an error 500 occurs.

Regards,

Pierre

Revision history for this message
Keith Jones (k-e-jones) wrote :

Hi again,

 If it's of any benefit, MPIO, iSCSI and virtual volumes of many types are given abstract serial numbers because they don't have physical ones. I think that's the key to the problem. I believe I would have exactly that problem if the agent didn't crash first :-)

in SysInfo.log I get;

<Manufacturer: (Standard disk drives)>
<Caption: HP MSA2312sa Multi-Path Disk Device>
<Description: Disk drive>
<Name: //./PHYSICALDRIVE18>
<MediaType: Fixed hard disk media>
<Size: 15257>
<S/N:
....and then the agent crashes...

Looking at the same disk using wmic gives me the serial number of "00c0ff10eef70000a43e9e4d01000000" which decodes to;
char(0),char(192),char(255),char(16),char(238),char(247),char(0),char(0),char(19),char(230),char(139),S,char(1),char(0),char(0),char(0)

 I doubt it would look very meaningful in XML but ,at least on the surface, it seems that the hex decode has harsher side-effects for some of my servers :-/

Regards,

Keith

Revision history for this message
Didier Liroulet (dliroulet) wrote :

Hi All.

I've build a new release 2.1.1.2 of agent (https://bugs.launchpad.net/ocsinventory-windows-agent/+bug/1353559/+attachment/4187301/+files/OCS-NG-Windows-Agent-2.1.1.2.zip)

I've applied the follwoing algorythm:

If Disk S/N is hex encoded, try to decode it and ensure it is printable
otherwise if not is printable, hex encode it

Could you check if it is working for you ?

Cheers

Changed in ocsinventory-windows-agent:
status: In Progress → Fix Committed
Revision history for this message
Keith Jones (k-e-jones) wrote :

Hi Folks,

 Didier's fix worked for my systems. As the disk it was crashing at has a hex-like serial number (like iSCSI volumes) it's likely that v2.1.1.2 will fix your problems too. It would be good to know your results though :-)

Regards,

Keith

Revision history for this message
p.deprey@linkbynet.com (p-deprey) wrote :

Hello,

This problem is corrected. But...

BEFORE:

  <STORAGES>
            <MANUFACTURER>(Standard disk drives)</MANUFACTURER>
            <NAME>DataCore Virtual Disk SCSI Disk Device</NAME>
            <MODEL>//./PHYSICALDRIVE2</MODEL>
            <DESCRIPTION>Disk drive</DESCRIPTION>
            <TYPE>Fixed hard disk media</TYPE>
            <DISKSIZE>30718</DISKSIZE>
            <SERIALNUMBER>6￑7 x ヘCᅭᆵ g↑￟￾レ</SERIALNUMBER>
            <FIRMWARE>DCS</FIRMWARE>
        </STORAGES>

AFTER:

      <STORAGES>
            <MANUFACTURER>(Standard disk drives)</MANUFACTURER>
            <NAME>DataCore Virtual Disk SCSI Disk Device</NAME>
            <MODEL>//./PHYSICALDRIVE2</MODEL>
            <DESCRIPTION>Disk drive</DESCRIPTION>
            <TYPE>Fixed hard disk media</TYPE>
            <DISKSIZE>30718</DISKSIZE>
            <SERIALNUMBER>6000c29df6616199e709c6f2eaaa990e</SERIALNUMBER>
            <FIRMWARE>1.0</FIRMWARE>
        </STORAGES>

This version (2.1.1.2) is working OK on windows 2008 or more. But on windows 2003, all plugins are not running anymore:

AGENT => Launching hardware and software checks
ERROR *** EXECUTABLE PLUGIN => Failed to start executable plugin <C:\LinkByNet\OCS_Inventory\plugins\000.vbs
ERROR *** EXECUTABLE PLUGIN => Failed to start executable plugin (etc...)

So this version couldn't be used.

Best regards.

Pierre

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.