glpi-project / glpi-agent

GLPI Agent
GNU General Public License v2.0
212 stars 51 forks source link

GLPI Agent creates duplicate BenQ monitors because of incorrect/incomplete serial number #651

Closed petertuharsky closed 1 month ago

petertuharsky commented 2 months ago

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Hi We started GLPI-Agent on our computers after we already had most HW in our DB. Now, the Agent creates hundreds duplicate monitors because there is slight difference in representation of SN in BenQ monitors. The actual SN on the back of monitor, corresponding with barcode, starts with letters "ET". However, the value given by GLPI Agent omits these two leading letters and only reads the code after. Therefore, there is no SN match.

To reproduce

Run GLPI agent and allow updating and importing monitors based on serial number. The actual serial number does not match the one reported by GLPI Agent.

Expected behavior

The agent-reported serial number should match the real one.

Operating system

Windows

GLPI Agent version

1.7.3

GLPI version

10.0.14

GLPIInventory plugin or other plugin version

Not applicable

Additional context

No response

g-bougard commented 1 month ago

Hi @petertuharsky

some manufacturers are know to not correctly report the serialnumber via the edid block of the monitor. I guess BenQ is one of them.

For that purpose, you can enable an option in GLPI to ask serialnumber matching on partial match. I think this is really what you need to enable in the context you're speaking about.

The option is named "Import monitor on serial partial match". It's a checkbox in Administration > Inventory > General configuration.

petertuharsky commented 1 month ago

Hi,

thank You for Your answer. I have already considered the option, however I cannot find in documentation, how long part of the SN would suffice for partial match, or whether it is configurable. Therefore I am afraid that it could lead to even more mess, if the partial match connects a device that is in reality different.

OTOH, I still think, that the Agent should make up for the discrepancy whenever possible.

g-bougard commented 1 month ago

Hi,

as I said, manufacturers are not always perfect in the way they store the S/N in the moniteur to be reported via the edid block. In the agent, we are doing our best to take the available data. We still know how to interpret correctly the found datas for few faulty manufacturers like Acer, Philips or Samsung. But we are not even confident with our interpretation as these manufacturers didn't publish any info on how to found the correct S/N.

But most of the time, this is a matter of a missing prefix or suffix. And this is way we developed the monitor partial serial matching. The S/N we find is still uniq against another monitor (as far we know of course). And this is why monitor partial serial matching option in GLPI can be sufficient in your case.

Anyway, we can also develop a BenQ monitors module if you share the required information. We need for that few monitor cases with:

  1. the monitor model
  2. the expected monitor serial, the one you entered when you manually registered the monitor in glpi, and it should be the one you found on the monitor packaging
  3. and the "monitors" section of the output generated by the following command run in an administrative console and from the agent installation folder: glpi-inventory --partial monitor and it should looks like:
      "monitors": [
         {
            "base64": "...very long string...",
            "caption": "...",
            "description": "...",
            "manufacturer": "...",
            "serial": "..."
         }
      ],
petertuharsky commented 1 month ago

Hi,

I understand, that manufacturers are less-than-thorough in these things, and I'm willing to help the way I can.

Example output 1. First monitor is HP, reported well, then BenQ reported with incorrect SN. The real data on the BenQ (according to label) are: Type: BL2423-PT Model: BL2420-TF SN: ETX1J08410019

Output of GLPI-Agent: "monitors": [ { "base64": "AP///////wAi8FUpAQEBATAVAQOANCB4KvyBpFVNnSUSUFQhCADRwIHAgUCBgJUAqUCzAAEBKDyAoHCwI0AwIDYABkQhAAAaAAAA/QAYPBhQEQAKICAgICAgAAAA/ABIUCBaUjI0NDB3CiAgAAAA/wBDTlQxNDhDMllTCiAgAAs=", "caption": "HP ZR2440w", "description": "48/2011", "manufacturer": "Hewlett Packard", "serial": "CNT148C2YS" }, { "base64": "AP///////wAJ0SeARVQAAAUcAQOANR54LgVlp1ZSnCcPUFSla4DRwLMAqcCBgIEAgcABAQEBAjqAGHE4LUBYLEUADyghAAAeAAAA/wBYMUowODQxMDAxOQogAAAA/QAyTB5TEQAKICAgICAgAAAA/ABCZW5RIExDRAogICAgALk=", "caption": "BenQ LCD", "description": "5/2018", "manufacturer": "BenQ Corporation", "serial": "X1J08410019" } ],

The examples 2 and 3 are same Type and Model. SNs: ETV5J00208019 ET44H01046019

Output of the agent: "monitors": [ { "base64": "AP///////wAJ0SeARVQAABUcAQMONR54LgVlp1ZSnCcPUFSla4DRwLMAqcCBgIEAgcABAQEBAjqAGHE4LUBYLEUADyghAAAeAAAA/wBWNUowMDIwODAxOQogAAAA/QAyTB5TFQAKICAgICAgAAAA/ABCZW5RIExDRAogICAgABg=", "caption": "BenQ LCD", "description": "21/2018", "manufacturer": "BenQ Corporation", "serial": "V5J00208019" }, { "base64": "AP///////wAJ0SeARVQAAA4bAQSlNR54OgVlp1ZSnCcPUFSla4DRwLMAqcCBgIEAgcABAQEBAjqAGHE4LUBYLEUADyghAAAeAAAA/wA0NEgwMTA0NjAxOQogAAAA/QAyTB5TEQEKICAgICAgAAAA/ABCZW5RIExDRAogICAgAaI=", "caption": "BenQ LCD", "description": "14/2017", "manufacturer": "BenQ Corporation", "serial": "44H01046019" } ],

In all cases, all the reported SNs miss an "ET" prefix, that is included also in barcode.

g-bougard commented 1 month ago

Okay thank you.

I realized "ET" is indeed encoded as the old serial number at the address 0x0C at the beginning of the block: I see 0x45 0x56 0x00 0x00, which in principle is a 32 bits integer in the standard, but can be read as "ET" string... When I said manufacturer does really bad things...

I think I can read the prefix at this address so.

g-bougard commented 1 month ago

Then I just pushed a fix to support reading the prefix from the first serial number. I limited the discovery to only match upper case characters like this I think we should expect.

You will be able to test next nightly build or you can wait for next release coming next week.

petertuharsky commented 1 month ago

Thank You!

petertuharsky commented 1 month ago

Confirming, it works.