Not exactly sure how to word this and can't find any info in the docs.

When a device is added to a map and the device list, it will usually show up on the ROUTEROS tab with "OK" status and a secure icon and snmp like statistics are available in the device's settings under the routeros tab. However, several devices show as "failed" and no dynamic information is available. I cannot find any difference between working devices and non-working ones. And a few devices that exist on multiple maps will work properly in one instance and not another. This also causes link stats to not work properly and makes push upgrades impossible.

Is there some flag or setting that I am missing?

1. Does this RouterOS device have SNMP enabled ? (In RouterOS)
2. did you set the RouterOS password in the Dude device properties? (In Dude)

Yes, the SNMP data is reporting properly, just not ROS data. and yes the user/pass are correct and I can winbox from the device list without a login challenge.

Is there any solution?
We have the same problem here.....

We have not come up with anything yet. Have not heard more than the response above.

I experienced this problem as well. However it is slightly different, but might point you to the fix. I have a Dude agent running on a remotely monitored network. Everything worked fine except the RouterOS data wasnt showing up. Having exploited EOIP to great benefit before, I had a wild idea. I created an EOIP tunnel directly to the Dude on ROS on X86 machine. The tunnel endpoints were on the 'gateway' MT radio running the Dude agent, and on the Dude machine. This is another advantage of Dude on ROS. By creating that tunnel to pass data directly to the Dude on the correct subnet, it immediately delivered all RouterOS data to the Dude server and displays very reliably. On top of that, the 333 running the agent was also running NAT for the HotSpot I had running on the second wireless NIC. Therefore, that nifty proprietary EOIP tunnel just poked a hole right through NAT, directly to the Dude server. I thought the 333 would choke running the Dude, the Hotspot, two mini-PCI NICS and passing significant traffic. The only available routerboard I had on me was a 333, so I had to try it, and its just idling along at about 5-25% CPU utilization, with 35.7MB RAM free, and 18.5MB HDD free. Pretty efficient I must say, even though the direct access to the Dude server in the 333 is slow. Still get 20Mbps throughput to boot.

So the moral of the story is that the Dude server must be able to directly communicate with the remote network, even though the agent is already directly connected. SNMP doesnt have this problem. I would look into any router, NAT, or especially firewall transversal because it seems to be a one-way street. Now that I think about it, the EOIP tunnel would actually allow the main Dude server to monitor the remote network. That is of course if your customer doesnt consider this a breach of security. On-the-ball network administrators should be asking 'where are those unknown IPs and MACs located? Word to the wise...

The agent is still my preferred solution because it can be configured to be quite transparent to probing network administrators that have nothing better to do...Personnel at one of these agent locations still are oblivious to the fact that I can tell them what is down on their network, even though I am not anywhere close to their network and have never thought to ask me 'How did you know that?'.

Stealth is good...

The problem is not connectivity. As I said above there are a number of devices that exist on two different maps and one instance works fine, the other does not. I can see no difference between the device instances that would explain it and obviously, if the problem were connectivity or a config error on the router neither instance would work.

That said, since we pushed the 3.20 upgrade out, most of this has fixed itself and there are only a few that still show the issue.

I had the same problem.
Try to remove "secure mode" from General. It works.
After, you can select "secure mode" without problems.