What is "asd" process?

[zitev]

The .asd process is nothing new, this thread started over a year ago.

As Merlin explained it is an ASUS security process, for what should be obvious reasons there is no way he would ever discuss or detail how to stop it running .

ok, for the first time I faced the problem that the hdd works continuously, without reason, and cannot go into standby mode, because of the incriminated process, so I have to find a permanent solution for this immediately (it is not a good solution to constantly disconnect the hdd, because this is a server with external/internal shares - but intermittent operation). On the one hand, the continuous search process does not know what it is looking for, what it does with the data, where it is sent, what they do with it there, etc., and on the other hand, it constantly causes a cpu load of around 15%, in addition to chasing the hdd. I don't miss this solution at all.

 

[AndreiV]

ok, for the first time I faced the problem that the hdd works continuously, without reason, and cannot go into standby mode, because of the incriminated process, so I have to find a permanent solution for this immediately (it is not a good solution to constantly disconnect the hdd, because this is a server with external/internal shares - but intermittent operation). On the one hand, the continuous search process does not know what it is looking for, what it does with the data, where it is sent, what they do with it there, etc., and on the other hand, it constantly causes a cpu load of around 15%, in addition to chasing the hdd. I don't miss this solution at all.

Your best course of action is to ask ASUS direct. In your ASUS GUI > Administration there is a feedback form. Use that or contact ASUS support.

 

[zitev]

Your best course of action is to ask ASUS direct. In your ASUS GUI > Administration there is a feedback form. Use that or contact ASUS support.

I'll try, but I don't have a lot of confidence in it, if they found such a solution, they probably don't care about the fate of the devices connected to the router, I think I'll disable this process permanently sooner, for now it's stopped manually, I'll have to repeat it after a reboot, but if I have time, I solve it. I was hoping there was someone here who was still bothered by this, but it seems I'm alone...

--
I'm looking at the gui now, is it possible for the disable button in the administration/security menu turn off this function? it was turned on for me now, although I vividly remember that I did not allow it to work..

 

[RMerlin]

Are you running a recent firmware? In the early days, asd was scanning the router more frequently that it needed to, Asus eventually toned down the frequency of these scans. The scanning process was also optimized at one point to even further reduce the load on the router.

If it still causes HDD issues even with an up-to-date firmware, then you need to contact them about it, in case it might be a regression caused by a recent update.

I'm looking at the gui now, is it possible for the disable button in the administration/security menu turn off this function?

As already stated, there is no option to turn this off, otherwise it would be completely useless since any malware would be able to turn it off itself before installing its payload.

 

[zitev]

Are you running a recent firmware? In the early days, asd was scanning the router more frequently that it needed to, Asus eventually toned down the frequency of these scans. The scanning process was also optimized at one point to even further reduce the load on the router.

If it still causes HDD issues even with an up-to-date firmware, then you need to contact them about it, in case it might be a regression caused by a recent update.


As already stated, there is no option to turn this off, otherwise it would be completely useless since any malware would be able to turn it off itself before installing its payload.

I always run fresh firmware, currently v386.9 is up. Running asd has not caused any problems so far, I didn't even notice it, but now it scans continuously. By the way, just as I was able to suspend the running of the process with a simple kill -SIGSTOP, anything else (even malware) can turn it off in the same way, so this is an illusion, it only provides a false sense of security, in addition to destroying the hdd.

 

[RMerlin]

can turn it off in the same way

It will be automatically restarted, with a full scan being done the instant it gets restarted.

 

[zitev]

It will be automatically restarted, with a full scan being done the instant it gets restarted.

But in what cases? In my case, it didn't restart (I didn't kill the process, but just suspended it), the system has been running fine ever since, without running the scan. Obviously, after a reboot, I have to suspend the running scan manually again, but I think this can be automated. I'm using it this way for now until I have some time to work with it.

 

[Morris]

ok i don't want to refer to that. I consider it an unfortunate solution that causes more harm than good. How can i turn this off permanently? Maybe can i prevent the find command from running with a workaround, a postboot script?

If you are worried about what is written to your hard drive then you should stop logging everything to your hard drive.

 

[zitev]

If you are worried about what is written to your hard drive then you should stop logging everything to your hard drive.

If you are worried about what is written to your hard drive then you should stop logging everything to your hard drive.

Nothing is logged on the hdd, it's just a data drive, the system uses an ssd, there is swap, jffs, and logs. There is no reason for the hdd to work continuously, only smb, sftp, dlna can access it, and at all other times it must go to standby. Continuous running of find prevents this.

 

[lucian]

same problem here.
RT-AX86U latest firmware.

ASD uses all cores constantly with 15% load each.

not happy either. kill -SIGSTOP didnt work for me though.

(lol - now that i am writing this - it seems to have stopped)

 

[zitev]

same problem here.
RT-AX86U latest firmware.

ASD uses all cores constantly with 15% load each.

not happy either. kill -SIGSTOP didnt work for me though.

(lol - now that i am writing this - it seems to have stopped)

try installing htop (opkg install htop), then after starting it, select the running process, then F9, and select sigstop from the list on the left!..

"(lol - now that i am writing this - it seems to have stopped)"
- lol - now while I was writing this, you wrote it too..

 

[lucian]

interesting read here - scroll down to the ASUS part.

The flash memory is used by these devices to store the operating system, configuration, and all files from the file system. Our research was carried out on the RT-AC68U, but other Asus routers such as RT-AC56U might be affected as well.

Cyclops Blink Sets Sights on Asus Routers

www.trendmicro.com

 

[zitev]

interesting read here - scroll down to the ASUS part.

Cyclops Blink Sets Sights on Asus Routers

www.trendmicro.com

 

[zitev]

Yes. Never use weak keys, passwords, and do not open remote access to the router from the WAN side, so you don't have to worry about external attacks. If it does, it could be outdated firmware, or a backdoor (manufacturer's responsibility, a scanning script can't be used afterwards), or culpable negligence on the user's side (LAN-side infection of some service...) I don't have any of these, so I can safely turn off the search script.
By the way, Asus also recommends not to open remote access from the outside - it is closed by default:
"Please note that if you choose not to install this new firmware version then, to avoid any potential unwanted intrusion, we strongly recommend that you disable remote access from WAN and reset your router to its default settings." (https://www.asus.com/content/asus-product-security-advisory/)

 

[D0m3L]

I'll try, but I don't have a lot of confidence in it, if they found such a solution, they probably don't care about the fate of the devices connected to the router, I think I'll disable this process permanently sooner, for now it's stopped manually, I'll have to repeat it after a reboot, but if I have time, I solve it. I was hoping there was someone here who was still bothered by this, but it seems I'm alone...

--
I'm looking at the gui now, is it possible for the disable button in the administration/security menu turn off this function? it was turned on for me now, although I vividly remember that I did not allow it to work..

You are not alone. I've just updated to 386.9 on my RT-AC68U and this /usr/bin/find /tmp -iname crrt* drives me crazy. I've got NAS shares mounted under /tmp/mnt folder and it is searching for crrt* 10h now (it was looking for .config* earlier).
This is something new in 386.9 as on previous fw there was no such a silly find command running.
I do not question the legitimacy of scanning for malware, but it should rather scan internal resources rather that anything mounted on the router (/tmp/mnt), especially for the data that is already protected/scanned by my NAS OS internally.
As for now I unmounted network shares as searching for a list of files constantly on plenty of TB data is overkill for me (and the 'find' process seems to be restarted once a day - probably by asd's check_version_from_server function).

Looking forward for a way of exclusion /tmp/mnt path from this burdensome process.

 

[ColinTaylor]

Looking forward for a way of exclusion /tmp/mnt path from this burdensome process.

Install stock firmware and verify that the same problem exists. If it does then report it using the Feedback page. If it's a bug Asus might then be able to push out an update. Asus aren't going to fix a problem if they're unaware of it. RMerlin can't fix it as it's closed-source.

 

[zitev]

Install stock firmware and verify that the same problem exists. If it does then report it using the Feedback page. If it's a bug Asus might then be able to push out an update. Asus aren't going to fix a problem if they're unaware of it. RMerlin can't fix it as it's closed-source.

I think almost 100% of users are average users, they don't even notice if something is behaving strangely on the router. Those who regularly install updates will notice and try to fix the malfunction. I don't think it's the users' job to look for bug fixes, to improve the manufacturer's thoughtlessly applied solutions, in order to protect the health of their own hardware... I think it's sad that this manufacturer, without publishing what it will do, suddenly introduced it under the grass such a cheap solution without giving the user a chance to decide if he wants to use this option..

 

[L&LD]

A, (any), manufacturer offers a product for an intended use case.

It is up to the consumer to decide if that fits with their requirements. Always.

It is always the user's job to verify it continues to fit with their requirements. Manufacturers' focus and actions do not always correspond 100% to what a random individual may need/want. They are following their own 'best practices' for their industry).

 

[zitev]

A, (any), manufacturer offers a product for an intended use case.

It is up to the consumer to decide if that fits with their requirements. Always.

It is always the user's job to verify it continues to fit with their requirements. Manufacturers' focus and actions do not always correspond 100% to what a random individual may need/want. They are following their own 'best practices' for their industry).

ok but how does this relate to this?

 

[L&LD]

I think almost 100% of users are average users, they don't even notice if something is behaving strangely on the router. Those who regularly install updates will notice and try to fix the malfunction. I don't think it's the users' job to look for bug fixes, to improve the manufacturer's thoughtlessly applied solutions, in order to protect the health of their own hardware... I think it's sad that this manufacturer, without publishing what it will do, suddenly introduced it under the grass such a cheap solution without giving the user a chance to decide if he wants to use this option..

ok but how does this relate to this?

Directly.

Your assumptions (quoted above) are not correct.