DLink DNS-321

[tom229]

Did a search in the forums but couldn't find any information relating to this NAS.

Essentially, the ARM version of btsync doesn't work on this device.

Steps to reproduce:

1) NAS rooted with fun_plug.

2) Download btsync 1.1.42 ARM

3) Copy btsync binary to /ffp/bin on NAS

4) Run ./btsync from /ffp/bin

Results in the following:

root@DNS-321:/ffp/bin# ./btsync
BitTorrent Sync forked to background. pid = 5251

But the process seems to start and stop as indicated by the following:

root@DNS-321:/ffp/bin# ps aux | grep 5251
Unknown HZ value! (0) Assume 100.
root	 5350 0.0 0.5 1756 360 pts/0 S+ 23:54 0:00 grep 5251

You can also immediately call ./btsync again and get a new PID indicating it's either crashed or never started.

Tried the following:

Installed glib-2.32.0-arm-1 via:

root@DNS-321:/ffp/bin# slacker -i glib-2.32.0-arm-1

Also tried to run with config file created both enabling and disabling webgui... same result.

Anyone else having the same issue with this NAS? I've seen many posts of people getting this to work flawlessly on the DNS-320.

[tom229]

The log is also empty:

root@DNS-321:~# cat .sync/sync.log
root@DNS-321:~#

I have a hunch this a problem with fun plug using uClibc instead of glibc.

[tom229]

More progress. At first I thought it was a library issue due to the output of ldd but it turns out ldd just wasnt looking in the right place. This command fixed ldd:

root@DNS-321:~# export LD_LIBRARY_PATH=/lib:/usr/lib:/ffp/lib

which made LDD return:

root@DNS-321:/ffp/bin# ldd btsync
ldd: can't open cache '/ffp/etc/ld.so.cache'
librt.so.1 => /lib/librt.so.1 (0x40002000)
libdl.so.2 => /lib/libdl.so.2 (0x4001d000)
libm.so.6 => /lib/libm.so.6 (0x40028000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400d9000)
libc.so.6 => /lib/libc.so.6 (0x400f2000)
ld-linux.so.3 => /lib/ld-linux.so.3 (0x40207000)

A clue can be given running with the --nodaemon switch

root@DNS-321:/ffp/bin# ./btsync --nodaemon
./btsync: relocation error: ./btsync: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

Looks like some sort of deep seeded error with glibc. Odd that it would work so well with (presumably) the same version of ffp on a DNS-320 as recorded here: http://forum.nas-cen...hp?f=249&t=8605 . Giving up for now. Will keep watching this thread.