1
0
-1

Hi all,

I have a discovery that runs every hour and I don't know how to retreive mac address of offline devices in my DB. With some devices I can look in the discovery log where I can find a line like "MAC XX:XX:XX:XX:XX:XX matched to manufacturer XXXXXX", but with other devices that were offline when the last discovery runs I don't have the discovery log. I can see the manufacturer, so the mac address was known but I can't retreive it.

How to find the mac address of those devices?

    CommentAdd your comment...

    6 answers

    1.  
      1
      0
      -1

      Hi Mark,

      I have run discovery after having updated the two files, now I have only two devices that duplicates on every run:

      - the Open Audit server on his own "default_network_address", it doesn't store the mac address of this interface. This is not a big problem, I can exclude this ip from discovery

      - an access point Apple Airport Extreme which seems to have multiple network interfaces.

      Here you can see the exported csv from the duplicated Airport Extreme device:

      1. Mark Unwin

        Hi Davide, The issue with the AirPort is that Open-AudIT is receiving two different IPs, each with its own MAC and has no way to associated that the two are from the same device. Are there ANY ports open on the device we can use to query it (I'm guessing not). If not, then I think you're stuck with "two" devices. You could extract the relevant rows from the IP table, massage them, delete the second AirPort device and insert new IP rows. The next time a discovery runs it would see the MAC and associate it with the first device. But we're getting beyond community forum support here and into paid support territory. I'm happy to make an internal ticket to (try to, unsure) facilitate this in the GUI, but I cannot allocate any time to it unless asked for by a customer. Sorry I'm not of more use, but you can see the issue - two different IPs with different MAC and no way to associate them to a single device...

      2. Mark Unwin

        Davide, I just reread the discovery log and see that SNMP is working. In that case if we are able to retrieve a serial, that would be enough and should cause the match and hence only a single device. I'll see if I can find the correct SNMP OID to query for this. Stay tuned and apologies for the bum steer above.

      3. Mark Unwin

        I have found the issue. SNMP on an AirPort doesn't provide a serial number. It's likely your IPs are attached to the "bridge" (a virtual) adapter. Those adapter in SNMP (for an AirPort) don't have a MAC address. If Nmap doesn't retrieve the MAC, we have noting to match the device to. I have made modifications to the code (which you already have) so that if Nmap does retrieve the MAC, it should be stored. It should not remove the MAC if it's stored. I'm guessing at least one of the AirPorts IPs is on a different subnet? This would explain no MAC and hence no match :-( See my answer above about being able to "combine" devices (see, I wasn't far off after all!).

      4. Mark Unwin

        I'll see if I can have the code ALSO check the network card table (as well as the IP table) for matching mac addresses. I "think" in this particular case it might resolve the issue.

      CommentAdd your comment...
    2.  
      1
      0
      -1

      I've upgraded to Open-Audit Enterprise 2.1 and the new IP Addresses section has appeared but MAC address on existing hosts was not populated despite the discovery job had run several time since upgrade.

      I need that mac address of existing devices will be stored in Open-Audit.

       

      1. Mark Unwin

        If the device is on a remote subnet and you have no credentials (as indicated by "nmap" scans, you cannot retrieve the MAC address. That is a fundamental networking issue and nothing to do with Open-AudIT. You could put a Collector on the remote subnet and (because it's on the same subnet as the devices) it would be able to retrieve the MAC address. Or you could use appropriate credentials. https://community.opmantek.com/pages/viewpage.action?pageId=24676399

      2. Davide Yachaya

        Devices are all on the same subnet and in the same LAN. Open Audit has stored the device manufacturer correctly in the device data, so the mac address is known. The problem is that Open Audit 2.1 doesn't add mac address to device already discovered before the upgrade. To solve this I have deleted all devices and run discovery task again, now mac address are stored correctly.

      3. Mark Unwin

        Hi Davide, I have (finally) found this bug. There are actually 2x bugs here. First, we were not using the MAC address as reported by the discover_subnet script. Second, we were only populating the IP table on a NEW device. If a device was subsequently discovered in a following run (this time with a MAC), it was not updated. There are valud reasons for this - but I know that doesn't help you. I have rewritten the code to now allow for this scenario. I shall post the updated files ASAP. These are obviously included for our next release. Stay tight - a fix is on its way. Apologies for the inconvenience cause, and thanks for persisting. Mark.

      4. Mark Unwin

        Davide, I have created a wiki page for this with a detailed explanation and the required files for the fix. You can find it below. Once you have updated with the fix and rerun a discovery on an affected IP, please advise if this is then working as intended. https://community.opmantek.com/display/OA/Errata+-+2.1+Updating+MAC+Addresses+from+Nmap

      CommentAdd your comment...
    3.  
      1
      0
      -1

      Thanks for persisting. I have found and fixed a bug in the discovery processing routine. FYI, we were using $device->mac instead of $device->mac_address. Silly mistake on my part. My apologies.

      This is now working and I have also added display code so when a device doesn't have network card records but does have IP records, we display a new section called IP Addresses.

      This code will be available in the next release of Open-AudIT (2.1).

      Click the image below to enlarge.

        CommentAdd your comment...
      1.  
        1
        0
        -1

        So the answer is - it depends...

        If you don't have the Hardware menu item, this indicates that only Nmap was used in Discovery and that you do not have valid credentials for these devices (SSH, SNMP, WMI, etc).

        In this case, there may or may not be an entry in the network cards table.

        The best option is to work through these devices and get working credentials for them. That way you will not only get the MAC Addresses but a whole lot more information as well.

         

        1. Davide Yachaya

          Many of those devices are smartphones connected over wifi and they don't have credentials to use. Why OpenAudit doesn't store mac addresses obtained from nmap scan in any table?

        CommentAdd your comment...
      2.  
        1
        0
        -1

        I don't have "Hardware" voice in the left menu on those devices but I can see the manufacturer so mac addresses were discovered when devices were seen the first time. OpenAudit server is on the same network.

        I can't see those devices in "network" table.

        It seems that when a device goes offline network table and discovery log are cleaned by the next discovery task.

        This is an example:

         

          CommentAdd your comment...
        1.  
          1
          0
          -1

          Any found MAC addresses are stored in the "network" table and associated to the device.

          On the device details page, in the left side menu, click Hardware -> Network.

          1. Davide Yachaya

            I don't have "Hardware" voice in the left menu on those devices but I can see the manufacturer so mac addresses were discovered when devices were seen the first time. OpenAudit server is on the same network. I can't see those devices in "network" table. It seems that when a device goes offline network table and discovery log are cleaned by the next discovery task.

          CommentAdd your comment...