10400: Invalid Data Type for attribute

Hi thaab,

could you please tell us whether the two devices in question have a "confirmed" Credit setting within the Registration overview? The devices will only show up in other views (Monitoring, Inventory, System Control) when they are actually confirmed. 

Devices should be auto-confirmed when connecting for the first time. Unconfirmed devices should not be editable on the other hand.

You could try to delete the two devices. They will reappear after a short time and will be auto-confirmed again. After confirmation, you might want to wait a minute before trying to edit the device or looking for it in the dashboard. You will know that a device is correctly initialized if the counter in the treeview will increase to the expected number of devices.

Cheers,
megaposer

I have seen this on ASL using Home/office license.

But on a new installed system (7day trail) it is working.

Maybe it is not supposed to work for Home/office users? [:(]


/gk

Yes the two devices do have the confirmed status. 

Yes both devices are registered home licenses.

hi,
i've got the same problem!!! what does it mean???

It means that for some reason or another ACC has not yet recieved enough information from the ASG to be able to display the edit dialog or show monitoring information, etc. We're currently trying to pin down exactly what went wrong and will fix the problem in a future release. Sorry for the inconvenient error message!

Hi,

could you post an 'ls -l /var/log/reporting' from the ASG causing the issue? Additonally you could check '/var/log/device-agent.log' for possible error messages stating that reporting device accus are not available/initialized.

Thanks!

Hi,

could you post an 'ls -l /var/log/reporting' from the ASG causing the issue? Additonally you could check '/var/log/device-agent.log' for possible error messages stating that reporting device accus are not available/initialized.

Thanks!

ls -l /var/log/reporting
drwxr-xr-x  2 root root  4096 Apr 25 11:22 accu
-rw-r--r--  1 root root 93485 Jun  4 19:30 current_report.ph
drwxr-xr-x  2 root root  4096 Apr 25 11:22 images
drwxr-xr-x  2 root root  4096 Apr 25 11:22 nacctd
drwxr-xr-x  2 root root  4096 Apr 25 11:22 rrd
drwxr-xr-x  2 root log   4096 Jun  4 00:00 sarg


tail device-agent.log
2006:06:04-19:37:26 (none) device-agent[4732]: cannot open client socket to '213.180.179.253:4433' (retry interval: 5 sec | log interval: 5 sec)
2006:06:04-19:37:31 (none) device-agent[4732]: connecting to '213.180.179.253:4433' (SSL: 1)

is there a solution with this problem??? a solution please!!!!

Hmm, the directory structure of your reporting directory looks correct. Does the reporting work as expected in webadmin. Is every graph shown correctly? Could you please have a look into /var/log/command-server.log and /var/log/agent-manager.log on ACC? If there shows up an error at the moment you get the error in the frontend, please copy and paste to the UBB.

> 2006:06:04-19:37:26 (none) device-agent[4732]: cannot open client socket to '213.180.179.253:4433' (retry interval: 5 sec | log interval: 5 sec)

This means that the ASG is not able to connect to ACC at all. In this case the ASG should not appear at all in ACC. Make sure port 4433 is allowed from ASG to ACC.

cheers
Timo

Yes your right! At the moment the machine is not running therefor the error. I will be at the office next friday to check the rest. Sorry for the delay.

The reports show correctly on both ASG's. Here is the first log file from the ACC:

acc:/var/log # tail agent-manager.log
2006:06:09-09:19:14 (none) agent-manager: CCommandSessionProxy::getDeviceAttribs() device session monitoring data not initialized (10404) on device.getSoftwareVersion 
2006:06:09-09:19:14 (none) agent-manager: CCommandSession::receive() device session monitoring data not initialized (10404) on dispatching request 
2006:06:09-09:19:14 (none) agent-manager: CAgentSessionMonitoringMethod::getMonitoringRefresh() invalid response (0) on undef operation
2006:06:09-09:19:14 (none) agent-manager: CAgentSession::refresh() invalid response 
2006:06:09-09:19:18 (none) agent-manager: CAgentSessionMonitoringMethod::getMonitoringRefresh() invalid response (0) on undef operation
2006:06:09-09:19:18 (none) agent-manager: CAgentSession::refresh() invalid response 
2006:06:09-09:19:20 (none) agent-manager: CAgentSessionMonitoringMethod::getMonitoringRefresh() invalid response (0) on undef operation
2006:06:09-09:19:20 (none) agent-manager: CAgentSession::refresh() invalid response 
2006:06:09-09:19:24 (none) agent-manager: CAgentSessionMonitoringMethod::getMonitoringRefresh() invalid response (0) on undef operation
2006:06:09-09:19:24 (none) agent-manager: CAgentSession::refresh() invalid response 

Here is the second log file from the ACC:

acc:/var/log # tail command-server.log
2006:06:09-09:29:29 (none) command-server: [DeviceStoreSwVersion::retrieve] device session monitoring data not initialized
2006:06:09-09:29:29 (none) command-server: [RPCClient::mark_bad] connection marked as bad 4 times.
2006:06:09-09:29:44 (none) command-server: [DeviceStoreSwVersion::retrieve] device session monitoring data not initialized
2006:06:09-09:29:44 (none) command-server: [RPCClient::mark_bad] connection marked as bad 5 times.
2006:06:09-09:29:44 (none) command-server: [DeviceStoreSwVersion::retrieve] device session monitoring data not initialized
2006:06:09-09:29:44 (none) command-server: [RPCClient::mark_bad] connection marked as bad 6 times, which is more than 5, disconnecting!
2006:06:09-09:29:59 (none) command-server: [DeviceStoreSwVersion::retrieve] device session monitoring data not initialized
2006:06:09-09:29:59 (none) command-server: [RPCClient::mark_bad] connection marked as bad 1 times.
2006:06:09-09:29:59 (none) command-server: [DeviceStoreSwVersion::retrieve] device session monitoring data not initialized
2006:06:09-09:29:59 (none) command-server: [RPCClient::mark_bad] connection marked as bad 2 times.

I have the exact same problem. ASG status is automatically confirmed (so connection to ACC on port 4433 is possible), but no information available. It is NOT a home license but has a dynamic IP (V6). Another ASG (but V5) is a home licence with a dynamic IP and it works.

Hi,

we have a known issue with some licenses containing special characters in the owner string. They prevent the device information from being initialized completely. The version information is not retrieved because the license causes a premature error, version information would follow afterwards if no error occured. Hence you get the 10400 error message when trying to edit the device(s) in question.

The issue is not bound to a special kind of license, e.g. home license. ACC does allow any ASG with a valid license to join. The problem lies, as mentioned above, within the special characters. Dynamic IP should not pose any difficulty.

We'll keep you posted. Thanks for your patience and pointing out the issue.

Cheers,
megaposer

There is a fix available. It will be included in the next version of ASG (yes, it's a fix for ASG not ACC). If you don't want to wait for the next up2date, please contact Astaro Support. They will send you a RPM which is easy to install and which will solve the problem.

cheers
Timo

I contacted support, received the patch (rpm), and applied it to a few of my customers impacted by the "special character(s) in the Owner String" problem.  It works... corrected the problem for me.[:)]