/build/static/layout/Breadcrumb_cap_w.png

Agent Not Checking In with BAD_MAC_IP Log Entry

Hello,

Whilst trying to troubleshoot a problem I performed full uninstall and reinstall of  the AMPAgent on a Mac based system (10.6.8) upgrading from agent 5.5.30275 to 6.0.1079, the Mac will not check in with the K1000 appliance.

I'm very sure that the Mac can communicate with the K1000 because the logs tell me this at both ends, but the Mac will not check in with the K1000 and give its inventory, like it once did before. I happen to have this issue on two Mac systems both running 10.6.8 Server.

The log file located at /Library/Application Support/Dell/KACE/data/user/KAgent.log

tells me that there is a file upload error http://<K1000>/service/kbot_upload.php?BAD_MAC_IP=<ipaddressofagent>&filename=KBOT_LOG.txt&mac=<KUID>&KBOTit=1 upload speed XXXXXXXX

I've searched for an idea on what this error could be and people hint a Mac address problem on the ethernet adapter or a problem with the kuid.txt file but neither of these seem to be an issue for me.

Has anyone had and resolved this issue?

Thanks,

Paul.





1 Comment   [ + ] Show comment
  • You should check this thread here:
    http://www.itninja.com/question/10-6-client-not-checking-in - Nico_K 9 years ago

Answers (6)

Posted by: KACE_Karl 9 years ago
White Belt
1

The first reason you would get a BAD_MAC_IP error is if you have duplicate KUIDs trying to check in. This is because the K1000,by default, is set to detect duplicate assets and not allow them into inventory.


Putting the amp agent directly intothe image you are using, rather than installing the amp agent post installation will cause this problem. There is ascript in the K1000 that allows you to reset your client KUID: K1000/Adminui >Scripting > Scripts > Reset KUID.

Also, you can manually reset the KUID by following the steps inthis article to delete the keys manually and have them re-populate: http://www.kace.com/support/resources/kb/solutiondetail?sol=111253

 

Here isanother article that addresses duplicate machines, disappearing inventory devices, and the over-arching question of duplicate asset management: http://www.kace.com/support/resources/kb/article/understanding-and-dealing-with-duplicate-machines-in-inventory

 

Anotherreason we have seen machines not propagating inventory, while giving theBAD_MAC_IP error, is due to altering a virtual K1000's hardware resources.

 

If youare dealing with a K1000 virtual appliance, you have the ability to alter theamount of resources that you allocate to the K1000. If the hardware in the virtualappliance is reduced below 4 cores and 8 gigabytes of memory, you may run intoissues with provisioning.

 

This isan example that I saw last week:

I was provisioning a group of 130 computers that were all freshly imaged. After they were provisioned they wouldn't populate into the K1000 inventory. Furthermore, the K1000 log was showingthe error 'BAD_MAC_IP=xxx.xxx.xxx.xxx' for the computers that I was provisioning. They were not populating into the K1000 at all. This is what turned out fixing this issue:

The Virtual K1000 was configured as such:

>OriginalHardware Configuration:  (4) cores and (8) gigs of ram.
>The K1000 hardware was altered to:  (1)core and (4) gigs of ram.
*This worked for a while until it reached roughly 1700 assets, then it startedthrowing out BAD_MAC_IP.*
>The hardware for virtual K1000 appliance was then changed to: (2) cores and (8) gigs ofram, and then rebooted. This fixed the problem and all of the machines startedchecking into inventory.

I would like to hear if anyone else has a weigh in tothis issue. There are other possibilities that I haven’t been able to fullytest in my lab environment, like the possibility for this to be caused byIP/DNS related problems.

Posted by: kentwest 4 years ago
Second Degree Brown Belt
0

I had a similar problem on a Debian GNU/Linux 9.9 box. They had been working fine until the latest upgrade on the SMA. I finally found the page athttps://support.quest.com/kb/129683/bad_mac_ip-provisioned-devices-not-populating-inventory, which pointed me in the right direction: The <OS> field in inventory.xml was empty. So I manually ran "/opt/quest/kace/bin/KInventory -machine -output /root/inventory.xml" and looking in
the newly-created "/root/inventory.xml" I found:

[2019-07-08.15:26:32][KInventory:fetch_OperatingSystem]
[fetch_OperatingSystem] Could not find major/minor from ""
sh: 1: lsb_release: not found

Doing an "aptitude search lsb" I found that lsb-base was installed, but lsb-compat was not. Shooting in the dark I did an "aptitude install lsb-compat", and then re-ran "runkbot 2/4/6 0", and bang! My machine shows up in my SMA's inventory screen, and seems to be working correctly. I was even able to force an inventory.

For me, I think I can consider my issue solved. The solution was to install "lsb-compat".

/Kent


Comments:
  • However, just a day later, with the release of Debian 10 (Buster), the problem returned. I documented my steps at https://lists.debian.org/debian-user/2019/07/msg00739.html, but the short answer was to edit the "/usr/lib/os-release" file, changing the "PRETTY__NAME" line to report "10.0" instead of simply "10". - kentwest 4 years ago
Posted by: a83547 8 years ago
Orange Belt
0
I'm having precisely the same issue. Let me know if you found a way to resolve it...

Comments:
  • Hi, I didn't find a resolution to this issue, but I found a work around and understand better the scenario when this happens.

    This only happens for Macs with an Ethernet bond. The agent doesn't seem to be able to understand the IP address of the computer if there is a bond link in place. The amp.conf file does not contain an ip address for the Mac.

    If I add another network adapter to the Mac, such as a Firewire adapter (doesn't even need to be connected and live), and then gave this an IP address, subnet and gateway, then the amp.conf file would then contain an IP address and the agent would then check in to the K1000.

    As I say this is a work around for any Macs that have an ethernet bond and are running the agent.

    Hope this helps.

    P. - Rubicon-IT 8 years ago
Posted by: a83547 8 years ago
Orange Belt
0
I'm having precisely the same issue. Let me know if you found a way to resolve it...
Posted by: AbhayR 9 years ago
Red Belt
0
Paul,

This error is not related to MAC address problem. What K1000 server and agent version you have?

You need to check the "K1000 Log" on server from the "Logs" tab. Please look for some error mentioned against your MAC agent's KUID.
Posted by: Rubicon-IT 9 years ago
White Belt
0
Hi All,

Apologies for the delayed response to this thread. I've spent much time advancing this once and the only machines that I have thjis issue with are Mac systems with an aggregated LACP ethernet bond - if I break the bond and restart the Ampagent then the Mac will check in fine. This problem still exists regardless of the resources added to my K1000 VM and I don't see the 'dyld: lazy symbol binding failed:' error in the log files, so I'm sure it's not related to this issue.

I've got an open case with Kace support and they've confirmed that there is an issue with Mac clients on 10.6 but I've got this with mac clients on 10.6 (soon to be upgraded anyway) and now 10.8.5 clients.

Not sure if anyone else has this issue and can confirm that it's related to an ethernet bond?

Thanks,

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ