Forum GLPI-Project

stoatwblr

Member

Registered: 2014-04-13

Posts: 118

Bug: Mac entries

At the moment MACs are not stored as pure hexadecimal numbers.

This means that AA:BB:CC:DD:EE:FF ,  aa:bb:cc:dd:ee:ff , aabbccddeeff and aa-bb-cc-dd-ee-ff are stored differently if not careful.
some equipment (Huawei and 3com) also outputs aabb-ccdd-eeff or AABB:CCDD:EEFF

Unlike postgresql which has a "macaddr" field type, mysql needs MACs to be validated and converted to a standard format.

There are several recipes for achieving this (case smash, remove separators, validate as a 6 digit hex number)

Cleaning this up would solve a few problems we're seeing here :
   VMS outputs everything as AA-BB-CC-DD-EE-FF
   3com outputs things as aabb-ccdd-eeff

Just to be even more painful, some equipment outputs MAC with stripped leading zeros

ie:  a:b:cc:d::ff

Whenever a human is pasting data into webforms, there's a risk of problems if the format isn't what GLPI is expecting.

(Postgres macaddr field type handles all these natively)

yllen

GLPI-DEV

From: Sillery (51)

Registered: 2008-01-14

Posts: 15,278

Re: Bug: Mac entries

Version of glpi used?
Which automatic inventory do you used (ocsng or fusion inventory)?

---

CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6  - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)