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

Impressive work!! Well done!!



I've included your findings in the wiki. It would be nice if you could share your knowledge about cross-compiling samba for the DNS on the wiki, e.g. a :howto:crosscompile_samba: would be great.

/Apan

tobyg wrote:

I would love to!  But I'm a wiki-idiot.  Seriously, I just haven't had time to even learn how to do anything on a wiki.  I plan on sharing knowledge as soon as I can figure out how to edit a wiki properly and organize my thoughts/data.

Have you tested the update that I posted?  Any issues?  Does it work for you?

Editing a wiki is very, very simple. It's made to be simple so than anyone can do it. If you want to share this information, jump to the wiki and in the "Seach" input, enter: howto:crosscompile_samba an press "Go".

You will now end up in a page stating "This topic does not exist yet". Click on "Create this page" and start writing your text into the textbox. As said before, very simple. And just share whatever you have. Don't mind formatting and organization, this can be done later by the one wanting it.

I've NOT tested your provided files as this issue havn't bothered me (yet). But; if you want some confirmation I'll gladly throw it at my unit later today and report back.

Once again, I'm impressed by your digging in the depths of Samba. I guess google is a friend of yours. And; as I'm having problems getting Firefly to run in standalone mode I'm very interrested in what you did crosscompiling this.

/Apan

tobyg wrote:

But anyway, if I have some time tomorrow I'll try to work on wiki stuff.  But personally I planned on installing my own wiki at home to 'test' with and then move that data over to this public wiki.

Ok, it's slightly O/T but there's also the "playground" where you can test your stuff, unless you really want your own Wiki. ;-)

http://dns323.kood.org/playground:playground


/Apan

trying to run this smbd ( the new smbd and samba228. is copied to /mnt/HD_a2/smbfix) :

# cd /mnt/HD_a2/smbfix/
# ls
samba228.sh  smbd
# samba228.sh
/opt/bin/ash: samba228.sh: not found
# ls
samba228.sh  smbd
# /mnt/HD_a2/smbfix/samba228.sh
rm: cannot remove '/mnt/HD_a2/smbfix/liblib_p.so.0.0.0': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/libparam_p.so.0.0.0': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/libpassdb_p.so.0.0.0': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/libubiqx_p.so.0.0.0': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/libsmb_p.so.0.0.0': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/nmbd': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/smbclient': No such file or directory
rm: cannot remove '/mnt/HD_a2/smbfix/smbpasswd': No such file or directory
$Shutting down SMB services:
$Shutting down NMB services:
$Starting SMB services:
$Starting NMB services:
# smb stop                                ; here i stop again it because i want to run it with my won config
$Shutting down SMB services:
$Shutting down NMB services:
# smbd -D -s /mnt/HD_a2/smb.conf
# nmbd -D -s /mnt/HD_a2/smb.conf

it runs and works, but due to the errors above, it it running the 2gb+ bugfixed sambd ?


thanx for your work

Hello Toby,

I think the shellscript  is not enough to replace the original bugged dlink-smbd and here's why:

snippet from samba228.sh:

Code:

> rm /usr/bin/smbd 

removes old symlink

> ln -s $PWD/smbd /usr/bin/smbd

places a new symlink at the same place

First problem:

$PWD is not defined and therefore empty, so the script may not always do what it's supposed to do. When called from fun_plug with the recommended file structure it still works as it should. But...

(Second: )

The symlinked smbd from /usr/bin/smbd is never used, not in the original version and not after the scripted re-linking via samba228.sh. (Can be verified by simply renaming "/usr/bin/smbd" to anything else and then trying "smb start": the samba server will start anyway)

Snippet from smb (called by samba228.sh as "smb restart", smb is the shellscript wrapper for starting/stopping smbd and nmbd)

Code:

start() {
        KIND="SMB"
    echo -n $"Starting $KIND services: "
#    daemon smbd $SMBDOPTIONS
#    cd /mnt/tmp/samba-2.2.8a.mips/source/bin
    /usr/sbin/samba/smbd -D                               <---------- Problem lies here
#    RETVAL=$?
...

As you can see, smb calls     /usr/sbin/samba/smbd     which remains untouched by the update procedure (we updated /usr/bin/smbd). It's also a read-only portion of the filesystem, so we can't simply re-link it, but need to fix and replace the smb script as well.

smb.fixed is exactly like the original smb, BUT with the problematic line changed to

/usr/bin/smbd -D

In that location lies the symlink to your updated smbd, which should start then.

My proposed samba228fix.sh:

#!/bin/sh

#stop samba prior to changing anything
smb stop

#make a backup of the old symlinks
mv /usr/bin/smbd /usr/bin/smbd.old
mv /usr/bin/smb /usr/bin/smb.old

#make new symlinks
#usage: ln -s /PATH/FILENAME /PATH/SYMLINKNAME

ln -s /mnt/HD_a2/smbd.fixed /usr/bin/smbd
ln -s /mnt/HD_a2/smb.fixed /usr/bin/smb

#start samba
smb start

Disclaimer: This is still work in progress, so don't put it in fun_plug until some people with telnet access to their 323's tested it and can verify it corrects the "large file problem". I'm trying it tomorrow, as it takes a while to copy and md5sum some backup files with several dozen GBs.

Can anyone positively identify an exact filesize that causes problems, as "2-4 GB" is not exact enough and I had successes with some zip archives that size even with the original samba version, but two ~40GB backup archives went totally wrong.

In the attached archive there are three files:
samba228fix.sh (my proposed version)
smb.fixed (the fixed shellscript)
smbd.fixed (the file from tobyg, BUT with the version string manually set to 2.2.8b to be able to differentiate between the broken dlink and the fixed versions)

Last edited by phoenix (2007-03-11 04:35:24)

phoenix wrote:

Hello Toby,

I think the shellscript  is not enough to replace the original bugged dlink-smbd and here's why:

snippet from samba228.sh:

Code:

> rm /usr/bin/smbd 

removes old symlink

> ln -s $PWD/smbd /usr/bin/smbd

places a new symlink at the same place

First problem:

$PWD is not defined and therefore empty, so the script may not always do what it's supposed to do. When called from fun_plug with the recommended file structure it still works as it should. But...

Isn't $PWD always defined?  "print working directory"?  It works for me.  The reason I used $PWD is so you can put it in any directory you want.  If you run the script from that directory (you have to be in that directory to run the script) then $PWD will be defined.  It's easier than telling people to modify the script with their proper path.  Instead just run the script from the directory you extrated the script and smbd to, and it will run.  $PWD = the directory you're running the script from.

phoenix wrote:

(Second: )

The symlinked smbd from /usr/bin/smbd is never used, not in the original version and not after the scripted re-linking via samba228.sh. (Can be verified by simply renaming "/usr/bin/smbd" to anything else and then trying "smb start": the samba server will start anyway)

Snippet from smb (called by samba228.sh as "smb restart", smb is the shellscript wrapper for starting/stopping smbd and nmbd)

Code:

start() {
        KIND="SMB"
    echo -n $"Starting $KIND services: "
#    daemon smbd $SMBDOPTIONS
#    cd /mnt/tmp/samba-2.2.8a.mips/source/bin
    /usr/sbin/samba/smbd -D                               <---------- Problem lies here
#    RETVAL=$?
...

As you can see, smb calls     /usr/sbin/samba/smbd     which remains untouched by the update procedure (we updated /usr/bin/smbd). It's also a read-only portion of the filesystem, so we can't simply re-link it, but need to fix and replace the smb script as well.

smb.fixed is exactly like the original smb, BUT with the problematic line changed to

/usr/bin/smbd -D

In that location lies the symlink to your updated smbd, which should start then.

My proposed samba228fix.sh:

Code:

#!/bin/sh

#stop samba prior to changing anything
smb stop

#make a backup of the old symlinks
mv /usr/bin/smbd /usr/bin/smbd.old
mv /usr/bin/smb /usr/bin/smb.old

#make new symlinks
#usage: ln -s /PATH/FILENAME /PATH/SYMLINKNAME

ln -s /mnt/HD_a2/smbd.fixed /usr/bin/smbd
ln -s /mnt/HD_a2/smb.fixed /usr/bin/smb

#start samba
smb start

Disclaimer: This is still work in progress, so don't put it in fun_plug until some people with telnet access to their 323's tested it and can verify it corrects the "large file problem". I'm trying it tomorrow, as it takes a while to copy and md5sum some backup files with several dozen GBs.

Can anyone positively identify an exact filesize that causes problems, as "2-4 GB" is not exact enough and I had successes with some zip archives that size even with the original samba version, but two ~40GB backup archives went totally wrong.

In the attached archive there are three files:
samba228fix.sh (my proposed version)
smb.fixed (the fixed shellscript)
smbd.fixed (the file from tobyg, BUT with the version string manually set to 2.2.8b to be able to differentiate between the broken dlink and the fixed versions)

This is useless.  Did you see this part of the script?

rm /usr/sbin/samba ; ln -s $PWD /usr/sbin/samba

That re-links the entire samba228 directory to /usr/sbin/samba which will make /usr/sbin/samba/smbd actually run smbd from your new modified samba path.

Yes, I agree that /usr/bin/smbd never gets called.  But the point is, that link is in the original firmware.  I replaced all instances of smbd (replacing /usr/bin/smbd directly even if it doesn't get called and also /usr/sbin/samba which effectively replaces /usr/sbin/samba/smbd) incase somehow they were called.  Figured it would be best to replace everything than leave leftover bad links.

As far as confirming what files, it also depends on your OS.  XP SP2 and Windows 2003 Server SP1 always had the problems with the file sizes I noted.  And I'm talking specifically about GB.  So a 2GB file of course is 2147483648 bytes.  If you tried a file that was 2000000000 bytes, that's 1.86GB and of course would copy fine without the patched smbd.

bobm5:

I can only confirm it works for me fine on 2 DNS-323 boxes.  I haven't heard anyone else confirm anything, but it fixed my problem.

Last edited by tobyg (2007-03-17 03:51:49)

I can now confirm that this fix DOES INDEED WORK with Windows Vista Ultimate 64-Bit and FIXES problems with 2gb+ file transfers..

running on my fun_plug and works like a champ

Last edited by stevodotorg (2007-04-02 14:02:09)

Ok, sources for the 1.03 firmware were posted and I can confirm that this fix was implemented in the samba release in 1.03


//#define CVAL(buf,pos) (((const unsigned char *)(buf))[pos])
#define CVAL(buf,pos) ((unsigned)(((const unsigned char *)(buf))[pos]))

That is what is now in the byteorder.h

and just a FYI, // remarks out the line.  They just left the old line in the file for reference.

So, this fix is should not be necessary any longer after upgrading to 1.03 (I have yet to upgrade my own boxes)

I still stand firm in my belief that if I had not found this and had this forum not existed, this fix would not have been implemented.  If you look at the samba code they are using, they've been trying for years to fix large file issues. 

Great job everyone!

Last edited by tobyg (2007-04-13 08:47:22)

tobyg wrote:

Ok, sources for the 1.03 firmware were posted and I can confirm that this fix was implemented in the samba release in 1.03


//#define CVAL(buf,pos) (((const unsigned char *)(buf))[pos])
#define CVAL(buf,pos) ((unsigned)(((const unsigned char *)(buf))[pos]))

That is what is now in the byteorder.h

and just a FYI, // remarks out the line.  They just left the old line in the file for reference.

So, this fix is should not be necessary any longer after upgrading to 1.03 (I have yet to upgrade my own boxes)

I still stand firm in my belief that if I had not found this and had this forum not existed, this fix would not have been implemented.  If you look at the samba code they are using, they've been trying for years to fix large file issues. 

Great job everyone!

thanks tobyg!

Like it says in post #16 - the problem described in this thread was resolved in the 1.03 firmware release - what you are experiencing is unrelated.

I think you're missing the point - even if the ftp server does not support resuming - it's not related to the problem or the solution detailed in this thread.

You have a different issue, it's not related to this problem, this problem has been resolved - you will probably get further starting a new thread, and even pointing it out to D-Link themselves at forums.dlink.com