Hello,
after upgrading The Dude server from 6.45.8 to 6.47.10 we keep having problems of clients that are unable to load, they stay in "getting stuff" indefinitely and just a few kbs are flowing.
Obviously we updated all the clients manually with the corresponding version. Sometimes we are able to start them by clicking multiple times on "connect" button. After the client is started it seems that for a while the problem is solved (closing and reopening the client without problems).
I tried also to upgrade to 6.48.3, server and clients, but the problem persists.
Do you have any advice on how to fix this?
Thanks!

Have you tried running the dude as admin ? is should pull down and install an update.

The update may not have been installed correctly, try reinstalling it.

@nikc: We did not upgrade the client with the automatic procedure, we downloaded the installer and run with admin rights.

@KayBur: tried reinstalling but nothing changes.

I confirm that a workaround is to click compulsively on Connect button, after a few seconds the connection is established.

I can also confirm this issue is plaguing us. Occurred after updating dude server and clients. We did not upgrade the dude client with the automatic update, we installed from the download.
Running as admin does not make a difference. Spamming the connect will cause it to spontaneously being communicating.
When in the 'Getting stuff' stage there is no traffic flowing between the Dude server and client.

Affecting many different computers all running various builds of Windows 10 (20H2 up to 21H1).

As a workaround to the silly and frustrating amount of time everyone is waiting and/or spamming connect, I installed the Dude in a linux VM using WINE. Works like a charm, no spamming the connect button, it works without fail every time albeit a bit slower then native but much less frustrating.

I came across a similar problem. In our case the Dude server was a x86 server. The client trying to connect on the LAN through the Ethernet card would get stuck at "getting stuff". But remote clients connecting through an EoIP tunnel with one end terminating at the x86 server worked fine. Doing a packet capture, it looked like an MTU problem at the x86 server. It appeared that the Dude server module was ignoring the MTU setting and trying to shove more bytes out the Ethernet card than it could handle.

I resolved our problem by changing the server out to a 1100AHx4 Dude Edition, which I'd been looking for an excuse to do for some time.

For us this issue started after crossing the 6.46.3 working line, after that is where dude went to garbage and doesnt like to use rOS tags and connecting is a pain. We have grown used to it at this point and are looking to replace the crap software and go elsewhere since it no longer functions how it should.

These are the words of those who cannot use it, and not wanting to blame, takes it out on MikroTik, instead of on himself.

I also went through some problems from 4.x to the current 6.47.10 that I use, but after having understood,
it continues to work perfectly, allowing me among all The Dudes to monitor more than 4000 devices.

These are the words of those who cannot use it, and not wanting to blame, takes it out on MikroTik, instead of on himself.

I also went through some problems from 4.x to the current 6.47.10 that I use, but after having understood,
it continues to work perfectly, allowing me among all The Dudes to monitor more than 4000 devices.

We are still actively using it ~5200 devices as it still works for recording cambium snmp/PL, it just no longer serves its "mikrotik" functionality with rOS. We had to disable rOS to keep it from dying 2 minutes after spinning up.
(yes he have tried hardware appliances and multiple x86 and CHR, currently on a CHR with 16c 16gb)
I had started spinning up a completely fresh data base on another CHR but at ~400 rOS connections, it dies again

(occasionally try another version but currently running 6.47.1 network wide with dude since no longer have working rOS dude to push updates)

For your curiosity, I use only RB1100Dx4 [RB1100AHx4 Dude Edition] with SSD inside.
Current database are near 200MB, is ridiculos amount compared to 256GB space on SSD
Has 774MiB free memory (1024GiB total) and the CPU ~20%.
I monitor RouterBOARDS, Cambium PMP450i, PMP450m, PMP450b , PMP550, Ubiquiti AF5XHD, AF60-LR, Ceragon 24GHz, Licensed S.I.A.E. 13GHz and 18GHz,
and I use mikrotik 8P, 16P and 24P models for control solar array. I have 50% of users on towers than work only on solar power...

For your curiosity, I use only RB1100Dx4 [RB1100AHx4 Dude Edition] with SSD inside.
Current database are near 200MB, is ridiculos amount compared to 256GB space on SSD
Has 774MiB free memory (1024GiB total) and the CPU ~20%.
I monitor RouterBOARDS, Cambium PMP450i, PMP450m, PMP450b , PMP550, Ubiquiti AF5XHD, AF60-LR, Ceragon 24GHz, Licensed S.I.A.E. 13GHz and 18GHz,
and I use mikrotik 8P, 16P and 24P models for control solar array. I have 50% of users on towers than work only on solar power...

I assume your recording time is shorter? Our 5200 DB is sitting around 1.4gb and my separate fresh sits at 450mb with ~1400 devices

We "ping" and rOS router boards
SNMP and ping epmp1000
snmp/ping/chains on mimosa b11/b5c and ubiquiti PTP

Per tower site we also SNMP record data passes from each AP, rOS recording between tower routers, and rOS recording in a "cores" map to record and show how much data each tower moves for recording.

Other than that, the only thing we use rOS for is sub device management if a customer has multiple devices, port reading at towers, and pushing firmware


I had tried using a nonDUDE 1100x4 (so had to use crappy storage) and it crashed it, same for trying on a CCR1036 with 16gb ram, and a 1009

Non-SSD dude "dead" after some minutes too much data on "disk" cache....
We do not do "syslog" on dude (we use separate GrayLog machine)
We obviously ping all, default probes are at 1min,
history set to raw 2 min, 10min 1d, 2h 2d, 1day 7d,
we increase keeping values only if needed,
ros interval 1 min
but we move all possible to oid

@MyThoughts: Thanks for confirming the problem and for sharing your workaround. After your experience I suppose the client is to blame.

@nje431: I checked the MTU along the whole path from server to client and back, seems fine to me so I assume mine is a different problem.

You may have misunderstood me. Our MTU path was fine too. The problem appears to be internal to the x86 router which causes it to ignore MTU.

i have also problem with dude
hosted on hex r3
with version 6.38 all good, and then via upgrade to newer dude is unstable
i monitor only mikrotik stuff and 1 service 88+44 devices and service is routeros manager
if device go down, telegram message i get and that is all, nothing special
now hexr3 cant handle 132 device, CPU is 30%
Before 6.38 version all was good .. how ? where is problem ?

I also have the Dude with hundreds clients on it and it works great up until the time that I accidentally press the X (close) button at the top right...
Then I need to wait for a couple of hours to load. I can't tell why. It is running on a CHR and while it is running it runs instantly! My only issue is to start up! I posted a topic in the past but no solution

The Dude internal database and the Image and tne MIBs etc. are transferred at ridiculous speed from The Dude to PC before it open.
it is probably why you must wait so much time to open The Dude on PC...

Is the same on my, if I clean, for test, all the history / log /errors from the database with sql3 open instantly...

As suggested by another poster, who's post I cannot find,apologies as you deserve the credit for this.

The problem does indeed seem to be MTU related. A simple fix is to run an EOIP tunnel to the DUDE server and access it via the tunnel. I am currently running dude v 6.49.2 on an x86. Runs perfect with no crashes and loads almost instantly. My DB is over 250MB with something like 300 monitored devices over 12 maps.

Before adding the tunnel it took many hits on the connect button to actually load and often crashed when loading a large graph

As suggested by another poster, who's post I cannot find,apologies as you deserve the credit for this.

The problem does indeed seem to be MTU related. A simple fix is to run an EOIP tunnel to the DUDE server and access it via the tunnel. I am currently running dude v 6.49.2 on an x86. Runs perfect with no crashes and loads almost instantly. My DB is over 250MB with something like 300 monitored devices over 12 maps.

Before adding the tunnel it took many hits on the connect button to actually load and often crashed when loading a large graph

Hi!

I guess I found that post for you: viewtopic.php?p=870954&hilit=Eoip#p870954

I'll try to replicate your EoIP fix through some other (firewall rule, I hope) mean...

mine is solved too.... I tried a lot playing with the mtu and finally I ended up adding the ether interface in a bridge and now it works in less than 1 second

mine is solved too.... I tried a lot playing with the mtu and finally I ended up adding the ether interface in a bridge and now it works in less than 1 second

Thank you for your feedback. Did you change something in bridge configuration about MTU or did you leave it as default?

mine is solved too.... I tried a lot playing with the mtu and finally I ended up adding the ether interface in a bridge and now it works in less than 1 second

Thank you for your feedback. Did you change something in bridge configuration about MTU or did you leave it as default?

I tried changing both the ether and the windows interface mtu... nothing... I changed them back to default and added the ether interface in a bridge... and it works amazingly fast now, instant load with hundreds of devices monitoring

We finally managed to fix it!
By simply exchanging the network driver of the VM from e1000 to vmxnet3 the problem was gone. Finally.

I also have the Dude with hundreds clients on it and it works great up until the time that I accidentally press the X (close) button at the top right...

.
Try unchecking all options in the Preferences box.
ie "Auto Connect At Startup", "Auto Reconnect If Connection Lost", "Auto Update To Server Version", etc.

Thank you for your feedback. Did you change something in bridge configuration about MTU or did you leave it as default?

I tried changing both the ether and the windows interface mtu... nothing... I changed them back to default and added the ether interface in a bridge... and it works amazingly fast now, instant load with hundreds of devices monitoring

Obrigado, solução simples e rapido !!!!