Response Invalid MAC address format Windows 7 Client

Sebastian Roth

@Daryl-Lee Thanks for testing. We have been discussing this a while ago in the forums already but never got to a finite solution. Possibly a good point to pick this up again and find a proper solution.

Daryl Lee

@Sebastian-Roth I never noticed how the MAC Address for the tunnel adapters has extra octets, but that definitely explains the issue. I can work around this for now by just removing those adapters (a quick test looks good). Thanks for the info and appreciate the effort looking into it.

Daryl Lee

@Sebastian-Roth I ended up removing the tunnel adapters and currently only one adapter is on the system, however it still comes back with the same error even with the normal, single, MAC. Here is the output:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 3/27/2019 11:31 AM Client-Info Version: 0.11.16
 3/27/2019 11:31 AM Client-Info OS:      Windows
 3/27/2019 11:31 AM Middleware::Authentication Waiting for authentication timeout to pass
 3/27/2019 11:31 AM Middleware::Communication Download: http://<ip>/fog/management/other/ssl/srvpublic.crt
 3/27/2019 11:31 AM Middleware::Authentication Cert OK
 3/27/2019 11:31 AM Middleware::Authentication MACAddresses: 64:00:6A:51:5E:D9
 3/27/2019 11:31 AM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before
 3/27/2019 11:31 AM Middleware::Authentication ERROR: Could not get security token
 3/27/2019 11:31 AM Middleware::Authentication ERROR: Could not find file 'C:\Program Files (x86)\FOG\token.dat'.
 3/27/2019 11:31 AM Middleware::Communication POST URL: http://<ip>/fog/management/index.php?sub=requestClientInfo&authorize&newService
 3/27/2019 11:31 AM Middleware::Response ERROR: Could not parse data
 3/27/2019 11:31 AM Middleware::Response ERROR: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
 3/27/2019 11:31 AM Middleware::Authentication ERROR: Could not authenticate
 3/27/2019 11:31 AM Middleware::Authentication ERROR: Object reference not set to an instance of an object.

x23piracy

@x23piracy said in Response Invalid MAC address format Windows 7 Client:

@Daryl-Lee try to reset encryption data for the specific host and try again, should be found in the host definition.

Regards X23

Sebastian Roth

@x23piracy Sorry to say this but I am fairly sure this is not gonna help here. The error is quite different. I will look into this soon.

Sebastian Roth

@Daryl-Lee Do you see the “Unable to parse data” error over and over or is it working properly sometimes? I ask because the character it complains about, <, is the start of a HTML tag. I suppose the webserver answers with a HTTP error page instead of returning proper JSON data…

Take a look at the apache logs (see my signature) and try to match client requests with logging on the client and your server.

Does the web UI still work properly?

Daryl Lee

@Sebastian-Roth said in Response Invalid MAC address format Windows 7 Client:

@Daryl-Lee Do you see the “Unable to parse data” error over and over or is it working properly sometimes? I ask because the character it complains about, <, is the start of a HTML tag. I suppose the webserver answers with a HTTP error page instead of returning proper JSON data…

Take a look at the apache logs (see my signature) and try to match client requests with logging on the client and your server.

Does the web UI still work properly?

Sorry for the delay getting back to you. I finally had some time to circle back to this. I can see the client and the web server talking, but fails after this log entry.

Answers to your questions:

httpd error_log contains nothing relevant to this error. The server never shows up in the log.
httpd access.log contains relevant access data (included below).
php www-error.log and error.log contain nothing relevant to this error.
Web UI still works great.
Matched log files with client and server:

Here is the scenario, let me know what else I can check.

Brand new CLEAN install of Windows 10. The only network device is the single network adapter. I install the client and it reaches out, gets the cert info from the webserver and then tries to POST the above line, which triggers the failure. I have both web logs and the log of the client, from the same moment.

FOG CLIENT:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 7/22/2019 7:42 PM Client-Info Version: 0.11.16
 7/22/2019 7:42 PM Client-Info OS:      Windows
 7/22/2019 7:42 PM Middleware::Authentication Waiting for authentication timeout to pass
 7/22/2019 7:42 PM Middleware::Communication Download: http://<FOG SERVER>/fog/management/other/ssl/srvpublic.crt
 7/22/2019 7:42 PM Middleware::Authentication Cert OK
 7/22/2019 7:42 PM Middleware::Authentication MACAddresses: 64:00:6A:51:5E:EC
 7/22/2019 7:42 PM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before
 7/22/2019 7:42 PM Middleware::Authentication ERROR: Could not get security token
 7/22/2019 7:42 PM Middleware::Authentication ERROR: Could not find file 'C:\Program Files (x86)\FOG\token.dat'.
 7/22/2019 7:42 PM Middleware::Communication POST URL: http://<FOG SERVER>/fog/management/index.php?sub=requestClientInfo&authorize&newService
 7/22/2019 7:42 PM Middleware::Response ERROR: Could not parse data
 7/22/2019 7:42 PM Middleware::Response ERROR: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
 7/22/2019 7:42 PM Middleware::Authentication ERROR: Could not authenticate
 7/22/2019 7:42 PM Middleware::Authentication ERROR: Object reference not set to an instance of an object.

FOG SERVER - APACHE LOG (same time period)

<FOG CLIENT> - - [22/Jul/2019:19:42:23 -0700] "GET /fog/management/other/ssl/srvpublic.crt HTTP/1.1" 302 246 "-" "-"

<FOG CLIENT> - - [22/Jul/2019:19:42:23 -0700] "GET //fog/management/other/ssl/srvpublic.crt HTTP/1.1" 200 1684 "-" "-"
<FOG CLIENT> - - [22/Jul/2019:19:42:23 -0700] "POST /fog/management/index.php?sub=requestClientInfo&authorize&newService HTTP/1.1" 302 283 "-" "-"

So the fog client reached out to the fog server, gets the SSL certs, then tries to check in getting the response that it couldn’t parse the data. This is the last we see of it for a while before it starts again. This repeats over and over. At the time of this error above, the client did not exist as a host on the website. I did enter the host on the website, but the error does not change. All other website operations are fine.

I’m surprised others aren’t having this. When I made this setup it was literally a brand new server install with brand new clients. The clients don’t even exist in the database (so no fancy reset to encryption needed) and these are all being built on very standard dell systems.

If i were to guess, i would say its something to do with the SSL process. It was working before this.

Sebastian Roth

@Daryl-Lee said in Response Invalid MAC address format Windows 7 Client:

If i were to guess, i would say its something to do with the SSL process. It was working before this.

Ohhhhhh my… I must have missed that part in your initial post!! As SSL is still not too heavily used in FOG that being your problem didn’t come to my mind.

Please edit C:\Program Files (x86)\FOG\settings.json and change value for HTTPS from 0 to 1. Then restart the client.

Daryl Lee

@Sebastian-Roth
Awesome, that did it thanks!

Sebastian Roth

I added some more checks and a more appropriate error message so people will find out more easy in future versions of the fog-client.

Response Invalid MAC address format Windows 7 Client

187

11.6k

17.1k

154.6k