Here is the link for the download:
http://www.mikrotik.com/download/dude-i ... 3.0rc1.exe

Changelog:

v3.0rc1:
*) bug fixes

- background image scrolling bug still remains
- (edit): Open Devices list, do a search for something which does not exist, Dude client hangs (new bug?)

Werent there icons next to the names in the contents pane next to the items (address lists, charts, devices, etc) ? All i have are little black and white boxes and a couple of icons (admins, files, services)

Where is the changelog?

using custom image for background causing CPU to max out and The Dude display to become basically useless for non-responsiveness. Having to revert back to 3.0b7 where this issue does not exist.

Custom image problem still exists on mine too. It doesnt crash but is incredibly slow when moving around.

Custom image problem still exists on mine too. It doesnt crash but is incredibly slow when moving around.

Same here.. thought it was only happening because i was connecting via Remote Desktop or Dude Remote... but even local it becomes extremely slow...

Whyyyyyyyyyyyy?

Whyyyyyyyyyyyy?

because the download is defective, it remains just before the end of the download stops it .. at about 3.4 mb.

I have the same problem .. can someone from the support fixed?

not the download file is the problem - the antivirus software !!
having no probems here .....

I found the same trojan with two other virus checkers.
I suggest that the people who created the file upgrade their virus scanners before the final compile.

1. changelog is in the first post
2. background problem has been found and verified, developers are working on it for the next release
3. hopefully next release will be out soon
4. there is no virus in the installer, as you see only NOD reports it. contact NOD to report as a false positive
5. download probably didn't compleate because of the NOD alarm

WHY?

remember that Dude is designed to scan network and access devices on it. That is Dudes purpose. Probably some anti virus software don't like this behavior, so please make an exception rule for Dude!

remember that Dude is designed to scan network and access devices on it. That is Dudes purpose. Probably some anti virus software don't like this behavior, so please make an exception rule for Dude!

McAfee here, latest DAT. Ran a scan with heuristic scanning (find unwanted programs, trojans, macros) and unwanted program detection... there's no virus. Installed it and there's no abnormal activity (or any virus reports).

Make sure you're downloading off the Mikrotik site, and you should be safe.


And great to hear you're fixing the background bug... how about an object copy/paste or at least a move-map feature now? .. and maybe even a manual bulk-addition feature ... or maybe - ok i'll stop

I upgraded today to rc1. Here are my findings... But first I want to give a HUGE THANK YOU TO MikroTik, If I dreamed up a network monitor I would have created "The Dude".

Most of the issues I have found are easily ignored or worked around. The biggest fix I have found is Networks only appear on the settings for the submap that you have added the network to... see below.

The time of an added note is not correct if you click apply then click ok, It puts Dec/31/1969 17:00 as the time but if you just click ok the correct time seems to be added.

It looks like the outline device function has been completely removed. It had stopped working in rc8 anyhow... Or did it move, I can't find it.

The issue where all networks are visible on all maps looks like it has been fixed. This only caused a problem when you edited a network on a map it didn't belong to. I would like to hear about this from others. If you add a network to a submap and go to another submap you won't see the network in the settings for the 1st submap in the settings for the 2nd submap. So if you want to keep track of every device on your network it should be safe to use discovery and not worry about devices showing up on a submap that the device doesn't belong to. I don't know how many devices The Dude can handle but we have way too many devices to let auto discover run on all networks although I would like to use it to find things at the start. Anyhow it is really nice that this feature is fixed.

The maximum speed on any interface is 4294967295 that is due to the counter used for the link. If you have 10 Gigabit interfaces you might need to use the MIB to get the correct counter. I saw someone mention the correct MIB but I have not tried to make a custom link that reads from the correct mib for Cisco devices. This isn't really an issue unless you have 10G links that are heavily used. Is it possible to get/set a link speed from a MIB?

On the general page for a single device if it has lots of addresses and lots of mac addresses a scroll bar doesn't appear and you have to remove some mac addresses to be able to see the "type" box. It is also not a big deal since it will re-discover the mac addresses. Removing some mac addresses is an easy work around.

I did not test copying files from the client to the server which would crash the client. In beta8 you could simply drag and drop the file and avoid crashing the client. I would recommend using just drag and drop, it works better, instead of clicking the add file and using the dialog.

I have not tested modifying many devices which would eventually crash the client.

If you don't install the server files the server doesn't start automatically. Nice fix...

It starts up way faster. I suppose they keep the file local now instead of downloading it every time you connect to the server?

I will post more as time permits and thanks again for the great tool...

GREAT WORK on The Dude!!!
Sweet! DUDE!

HI All and Dude Support Team/Develops. This is really an GREAT Product.

I have already submitted this to Support and here is the summary.

Problem Definition:
DUDE client hangs after second load with Panel containing more than one elements.

Implementation Description:
Agents: 9.
Network Elements: Average 12 objects per Map
SNMP Def: 10
Syslog Elements: 6
Polling bandwidth: 200 Kbps

Dude Client does not crash so no crash report. Dude Client hangs. I have been able to determine that it happens with panels that contains a least one chart in a panel. It also occurs after dude client has been loaded the second time even after the Dude Server service is restarted.

Is the v3rc1 available as ROS package?

The application is phenomenal, for being free. Thank you for supplying the public with your software - free of charge! With that being said, however, there are (as you're well aware) of a few issues still needing to be addressed.

1. I've tried The Dude's client-side application on a number of Windows platforms: XP, Vista, and Server 2003. The application hang still occurs and occurs frequently. Vista is actually able to recover from it without having to close the app and reopening it. The other 2 OSes, I've had to completely shut the client down. This behavior has been around since 2.2 or earlier.

2. When devices generate a notification alerting that a service/device is down and there is more than one client-side application open and connected to the server, if one disables that particular service/device from one client-side machine, server included, it still generates the notifications and sends out emails even though that service/device has been placed in somewhat of a "maintenance" mode configuration, meaning polling and notifications are no longer enabled.

Do the clients cache the server information? This behavior would lead one to believe so as once a device is disabled these notifications should stop being generated but only if the clients are running in real-time with the database.

Example: I was working from home and I got an email alert stating there was a NIC down on one of the servers. Upon logging in through the VPN and connecting to the server-side client that runs The Dude, I disabled polling and notifications on the device. Since my laptop was still at work and connected to The Dude server through the client-side application the notifications were still coming to me 20 mins after I disabled polling and notifications on that device.

Is this a misconfiguration error on my part, or could this actually be an issue? There may be times when 2-3 ppl have the client-side application open and may need to place devices in "maintenance" mode when alerts alarm. If someone disables polling on a device, all of the client-side apps should reflect that change.

3. When creating a new notification and clicking the "Advanced" tab, the program completely crashes.

4. When trying to submit the crash report via email, no details are included automatically as it did previously.


G-

Another way to cause a crash.

Running Snmpwalk multiple times will eventually crash the client.

The editing of many devices one after another has not crashed, which it used to.

Still minor and great progress on rc1...

10Gbit link speed still don't work

Any ETA for the new RC with the Background image bug fixed? We have resorted to using the Web Client because the Windows Client is unusable..

Any ETA for the new RC with the Background image bug fixed? We have resorted to using the Web Client because the Windows Client is unusable..

umm, refresh the Dude forum page please

I have thoroughly examined The Dude v3.0rc1. I have experienced all the same concerns that sweetdude posted on Tue Sep 02, 2008 11:28 am as well as gdrew Wed Sep 03, 2008 11:24 am. Out of all the bugs they list, the one that needs some immediate attention is the notification e-mails. At first, I disabled netbios services alerts, but I still received ping and netbios alerts every time a device went offline. I went ahead and removed netbios as a service all together from the server. I am still receiving ping and netbios e-mail alerts. Like gdrew mentioned, is there a cache or something to clear out? Where is the server still pulling netbios from when the service no longer exists?

Does The Dude work for effectively as a service or just the application?

If you're still using RC1, try getting the new version.

It is up to RC3 now, and several bugs have been fixed.