DSM-G600, DNS-3xx and NSA-220 Hack Forum

# # cat upnpav.conf

ShareFolder:/mnt
# #

# cat /etc/unpnpav.conf

ShareFolder:/mnt
# #

The cron entry for dhcp kicks off the UPnP server.

If you do a strings on the getdhcp binary you will find this:

check upnp
ps -aux | grep upnp > /tmp/upnpid
/tmp/upnpid
/upnp/upnp
/bin/upnpscript &
rm /tmp/upnpid
/sys/custom/default/sib.conf

And it is consistent with how my DNS-323 keeps popping up on my LAN. Each time the cronjob is run it will reappear.....

Do you think I could just delete the whole getdhcp line from the cron file?  I am guessing that this code might be responsible for starting up the DHCP server, the UPnP server and the iTunes server.  I am not using any of those.

jmang wrote:

Do you think I could just delete the whole getdhcp line from the cron file?  I am guessing that this code might be responsible for starting up the DHCP server, the UPnP server and the iTunes server.  I am not using any of those.

No, I think you need it so that your DHCH lease is renewed when it expires. However, I think you can remove the symlink named "upnpscript" in /bin . Try linking to busybox...

cd /bin
rm upnpscript
ln -s ../bin/busybox upnpscript

As this is lost on reboot you'll have to put this in your fun_plug.

/Apan

I guess you could remove the cron entry if you configure the box with a static IP.

jmang wrote:

Apan,
I don't see any way of preventing this without modifying rc.sh.  Do you?  I am reluctant to do this due to the possibility of "bricking" the DNS, as I don't think rc.sh is restored to a default state on reboot.

What happens at boot is that rc.sh recreates a bunch of symlinks from RAM-disc into flash. What I suggest is only to remove the link in the RAM-disc during boot, using the fun_plug. You could also kill the upnp server in the fun_plug to make sure it's not started at boot.

The fun_plug should look something like this:

#!/bin/sh

#
# Remove sym-link in RAMdisc
#
rm /bin/upnpscript

#
# Recreate sym-link to a fake script,
# most likely this step is not necesarry...
#
ln -s /bin/busybox /bin/upnpscript

#
# Kill any started instances of UPnP server
#
kill -9 `/bin/pidof upnp`

As long as you're only fooling around with files in RAMdisc, there is no risc bricking the unit.

The above fun_plug has not been tested since I don't have access to the unit right now. However, I've removed the sym-link and got rid of the UPnP server.

jmang wrote:

I noticed that UPnP is not a persistent daemon so it is probably crond that kicks off UPnP's periodically announcing itself.  If I understand correctly, your suggestion is to redirect the link to busybox which should result in crond's calling upnpscript doing nothing.

Well, D-Link are doing interresting stuff all the time. Every time the upnpscript is executed, the UPnP deamon is killed and restarted. I guess they have some kind of memoryleak or something else as they are killing things serving users. I mean, what happens if you actually are using the UPnP server watching a movie and the server is rebooted?!? Ugly as hell, but most likely good for the over all stability of the unit - causing less calls to support.

I mean, which is worse:

Me: Hey, Mr support guy, the film stopped?!?
Support: Try again
Me: Works like a charm
Support: Ok, case closed           
mumbles: Stupid User error


Me: I can no longer watch movies!!
Support: Thats odd, try to reboot
Me: That worked, how often do I have to reboot?
Support: Every now and then...
Me: Really - this is not acceptable, I require a fix or I show it in the microwave!!! RMA, RMA, RMA !!!
Support: OK, I'll open a case - check next firmware           
mumbles: Shit, we have a real problem - management bonus will now drop and I'll get fired for this...



I've noticed this ugly behaviour in many of the applications on the unit.

I can understand that they do this for the non-stable open-source applications, such as mt-daapd 0.2.4, but not the closed source UPnP application. As this seems to be sourced from REDSonic - they should instead require a stable application from them...or maybe theyv'e bougt the sources.

And this my friends, is why we need the custom firmware in this unit....

/Apan

I'm using 1.05 fw and funplug.

There is a serious problem in getdhcp.  Using strings and strace show this program opens both /web/sib.conf  and
/sys/custom/default/sib.conf.   These contain the localized and the edfault parameters.

This program then execs a udhcpc (dhcp client) using the parameter:
/sbin/udhcpc -i %s -H %s -p /var/run/udhcpc.pid -s /usr/share/udhcpc/default.script -x %s -q -b&

Unfortunately it seems to take ALL of the dhcp client parameters from the default=firmware file, and ignores localization.
I get this:
/sbin/udhcpc -i egiga0 -H DNS-323 -p /var/run/udhcpc.pid -s /usr/share/udhcpc/default.script -x 192.168.0.32 -q -b

But my hostname ISN'T DNS-323 and 192.168.0.32 has no significance on my network.
==

The initial dhcp from the /etc/rc.d/rc.init.sh reads ....
/sbin/udhcpc -i egiga0 -H frown -p /var/run/udhcpc.pid -s /usr/share/udhcpc/default.script -x 192.168.0.32 -q -b

So my dns/dhcp server resolves the NAS name as "frown" for a while and aftersome time, crond runs getdhcp and then the DNS server ignores the name "frown" and starts using "DNS-323".  This is a serious error.
===

BTW the /var/spool/cron/crontabs/root file seems to be written by the /web/webs program.  No idea when it runs.