Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
Hello all:
I am using ffp 0.5 installed on a USB stick and have configured the rsyncd.conf file so that the rsync --daemon is running on both NSAs. I am trying to synchronize both boxes using rsync. However, rsync stops with the following error:
error in rsync protocol data stream (code 12) at io.c(601)
This happens regardless of the direction of transfer (NSA220 <--> NSA220P)
I have tryed to use NFS and CIFS to mount the remote NSA but this isn't working either. I noticed that simple commands such as cp and scp to the remote filesystem just freeze. (Mounting CIFS of a Centos5.2 Linux box works ok though).
I know that rsync server is properly configured because I can rsync from my linux box (rsync 2.6.8 protocol 29) to both NSAs and works flawlessly either using the daemon or the -e ssh option.
I have tryed using rsync version 3.0.5 in both boxes. I also upgraded both boxes to rsync 3.0.7 with no success.
I used the --protocol=29 switch and think it has no effect because nowhere in the log says that the remote rsync has acknowledged to use this protocol.
I have even tryed to compile rsync 2.6.8 from source
(http://nas-tweaks.net/CH3SNAS:Tutorials … g_software) to no avail, it just compiles rsync but the executable is not able to get a lock on any port and just gives the message "listen() on socket failed: Address already in use" for every port I used (871 - 875).
I am knocking my head over this. Please help me on this matter.
Offline
Thank you Mijzelf,
Yes, I read that page -which by the way was the most informative I could find- prior to my posting. That's why I tryed first upgrading from rsync 3.0.5 to 3.0.7.
Regarding Q3, I ruled out:
-Destination disk is full. I am using 1.5TB free on NSA220P RAID 1 2x2TB and 200GB free on NSA220 RAID 0 2x500GB. Besides, the size of folder used for rsync is no more than 2KB.
-Idle connection. Using Lynksys Wireless N Gigabit router WRT350N in between. Jumbo Frames 4KB enabled on both NSAs.
-Network error. Do you think that Jumbo Frames are causing this? I will report later what happens with Jumbo Frames disabled.
-Remote rsync wasn't found. It reaches the remote NSA and sends the list of files. It even creates the directory and the first file with zero bytes in it.
-I do not know what would I do with the output of strace, but I could try should it be necessary.
I was more concerned with Q2 -although I am not sure whether LDAP or PAM is being used- since rsync is chrooted, but it is not crashing just timing out.
The weird thing is:
1. That from my linux box (rsync 2.6.8 protocol 29) works flawlessly to both NSAs (tests with up to 100 pdf files).
2. That if I erase the smash.gif file in folder test (see experiment setup below) the transfer is successful both ways NSA220 <--> NSA220P regardless of the file's owner.
These facts led me to believe that the problem is not related neither to permissions nor to authentication but to the way protocol 30 is handling the stream (probably size of file smash.gif requires compression??).
I also think that the --protocol argument is being dismissed because there is no visible indication in the logs that protocol 29 is being used.
That's the main reason why I was trying to compile rsync 2.6.8 (protocol 29). Do you think you can compile this for me? Maybe I am doing something dumb that I am not aware of.
The only strange thing that I noticed while issuing the ./configure --prefix=/ffp; make commands is that io.c gives me some warnings and that the resulting rsync binary is unable to grab a handle on any port (it just reports that the port is already in use regardless the number, although I used only 871,872,873,874,875).
By the way, is it normal that any opening session (ssh for instance) takes more than 30 seconds to give the prompt?.
The netstat command takes about 2 minutes to complete and the successful runs or rsync take about 30 seconds from the time the command is issued to the time it opens the remote connection.
I am running out of ideas, but am thinking on modifying the after_booting.sh script to start rsyncd in one NSA and cron rsync on the other unchrooted but I am not sure where the raid array /dev/md0 and the share temp will be mounted (/i-data/md0/temp??). Do you think this might help? and more importantly, do you think you can give me some hints on how to accomplish this?
*** experiment setup ***
I used the transfer method from NSA220P --> NSA220 and viceversa.
For instance, on NSA220
I am issuing the commands as follows:
/ffp/start/rsyncd.sh which spawns the /ffp/bin/rsync --daemon --config=/etc/rsyncd.conf as a root user
and reading the log with
tail -f /var/log/rsyncd.log
#contents of rsyncd.conf log file = /var/log/rsyncd.log secrets file = /etc/rsyncd.secrets max connections = 3 port=872 uid = root gid = root dont compress = *.* use chroot = false strict modes = false timeout = 300 [temp] comment = temp folder auth users = root hosts allow = 192.168.0.3 192.168.0.4 list = yes
#contents of rsyncd.secrets root:root
on NSA220P I issue the following
/ffp/bin/rsync --timeout=300 --port=872 --protocol=29 --rsync-path=/ffp/bin/rsync --password-file=/root/.rsync/passwd -avvr /i-data/md0/temp/test 192.168.0.2::temp
and read the verbose part on screen.
I also used
/ffp/bin/rsync --timeout=300 --port=872 --protocol=29 --rsync-path=/ffp/bin/rsync --password-file=/root/.rsync/passwd -avvre 'ssh -ax -c blowfish' /i-data/md0/temp/test 192.168.0.2::temp
and read the verbose part on screen.
In some tests I have even used -vvr instead of -avvr.
ssh login is passwordless (using RSA certificate).
the contents of test directory are more or less something like this:
-rwxrwxrwx 501 nsausers 766 scuba.ico
-rwxrwxrwx 501 nsausers 1776 smash.gif
-rw-r--r-- root root 5 test
Last edited by zavala (2010-09-23 00:41:42)
Offline
That's the main reason why I was trying to compile rsync 2.6.8 (protocol 29). Do you think you can compile this for me? Maybe I am doing something dumb that I am not aware of.
I compiled it, (I PMmed you an url) and it didn't give a warning on io.c. But my logfile said:
Sep 15 12:19:42 Fileserver rsyncd[3436]: rsyncd version 2.6.8 starting, listening on port 872 Sep 15 12:19:43 Fileserver rsyncd[3436]: rsync: listen() on socket failed: Address already in use (98) Sep 15 12:19:43 Fileserver rsyncd[3436]: Try using --ipv4 or --ipv6 to avoid this listen() error.
So I added --ipv4, and rsync just daemonized without problems.
By the way, is it normal that any opening session (ssh for instance) takes more than 30 seconds to give the prompt?.
The netstat command takes about 2 minutes to complete and the successful runs or rsync take about 30 seconds from the time the command is issued to the time it opens the remote connection.
No, that's not normal. On my box I have a prompt in 5 seconds or so. Netstat takes longer (I'm running a tor server and am seeding some torrents, so there are plenty of connections) but not 2 minutes. About 30 seconds, I think. Can't say anything about rsync.
I'd definitely try to switch off jumbo frames.
I am running out of ideas, but am thinking on modifying the after_booting.sh script to start rsyncd in one NSA and cron rsync on the other unchrooted but I am not sure where the raid array /dev/md0 and the share temp will be mounted (/i-data/md0/temp??). Do you think this might help? and more importantly, do you think you can give me some hints on how to accomplish this?
You want to start ffp-rsync unchrooted? Well, maybe it's possible on newer firmwares (I never upgraded from 2.10). I saw that on newer firmwares the rootfs is in ram, and not in rom. So maybe you can remount the root rw, and create a symlink /ffp which points to the real ffp. In that case you can just start rsync. (Well, maybe you'll have to provide a different path to the conf file.
Without this symlink it cannot be done, I'm afraid, because rsync is dependent on libraries in /ffp/lib.
By the way, you know you can run native Debian?
Offline
Turns out that none of the NSAs is able to understand 4KB jumbo frames.
In the end what solved the problem was to disable jumbo frames on both NSAs.
I am not sure why this caused so much trouble and would like to know if someone has a technical explanation for that?
Not even the Zyxel applications (FTP Uploadr and BackupPlanner) work with jumbo frames enabled. Weird!
Just to be more clear on my setup I provide below a schema of my network:
NSA220 NSA220P CentOS 5.2 _______
| | | | | Other Hosts
|___WRT350N__|___________|________|__ |___DI-524______|___|___|__
1000Mbps segment | 100Mbps segment |
WAN (not used) WAN to Internet
The Gb segment has 3 hosts with Gigabit Ethernet cards and the only slow traffic source comes from the cross-over cable interconnecting the two switches.
It is my understanding that since both NSAs are in the same segment and have GbEthernet cards there should be no problem in communication. However, that was not the case. Any reason for that?
Thank you Mijzelf for sending me the rsync executable.
I would like to abuse your patience a little bit more and I hope you don't mind.
After disabling jumbo frames both rsync 2.6.8 versions (yours and mine) worked equally well with the --ipv4 option.
I am worried why your compilation throwed no errors and why my executable is more than twice the size of yours. I have PMed you the log of my ./configure and make commands so that you can read the few warnings and advice me if something is missing in my host.
I have installed on my USB the following:
autoconf-2.61-2.tgz make-3.81-3.tgz
automake-1.10.1-2.tgz mc-4.1.40-pre9-ffp05.tgz
binutils-2.18.50.0.1-4.tgz ntp-4.2.4p6-1.tgz
bison-2.3-3.tgz (not this one) openvpn-dns-323.tar.bz2
bzip2-1.0.5-2.tgz patch-2.5.9-3.tgz
flex-2.5.33-5.tgz samba-3.3.2-1.tgz
gcc-4.1-2.tgz sudo-1.6.9p17-2.tgz
gettext-0.17-2.tgz tcpdump-4.0.0-1.tgz
grep-2.5.3-2.tgz uclibc-0.9.29-7.tgz
Do I need any other package to get the string functions pass without a warning?
Are you using QEMU to cross-compile your stuff? if so, can I use the instructions provided in http://www.aurel32.net/info/debian_arm_qemu.php to setup my emulated arm machine to cross-compile stuff for the NSA? I have already followed the said procedure but did not install the kernel headers nor the gcc package yet.
Finally, I get the ssh login prompt at 5 seconds as well. However, the password prompt takes 55 more seconds to appear. What could be the root cause for that? Difference in libraries between firmware 2.10 and 3.22? How can I tell which is the firmware linux version? Because when I type uname -a I guess I get the chrooted version, right?
Offline
I am worried why your compilation throwed no errors and why my executable is more than twice the size of yours. I have PMed you the log of my ./configure and make commands so that you can read the few warnings and advice me if something is missing in my host.
Your compilation doesn't throw errors either. The warnings are nothing to worry about. The sourcecode uses some ANSI string functions like strlen(). The official definition of strlen() is 'size_t strlen( const char * )', but for some reason the writer of the sourcecode uses 'unsigned char *' for strings. For strlen() it doesn't really matter. In both cases a string is an array of bytes, terminated with a byte containing zero. But the compiler warns about it. AFAIK there are 2, maybe 3 options to get rid of the warnings:
- Change the source code. On all lines where a warning exist add an explicit cast, strlen( string ) becomes strlen( (const char *)string ). This doesn't actually do anything, the generated binary will not change, but it tells the compiler the string has to be treated as another type.
- Suppress the warning. Using the right comandline switch you can tell gcc to not show this particular warning.
- I've seen a switch to treat chars as unsigned. I can't remember if the compiler was gcc, but it could also suppress the warning. However, doing this could break the program, when it somewhere needs the signedness of a char.
About the size; by default the output of the compile process is an executable containing the actual binary, and extra (debugging) information. This debugging information can be stripped with the 'strip' command:
strip <binary>
I stripped my binary, and I suppose you didn't.
Are you using QEMU to cross-compile your stuff?
No, I compiled it on my NAS, using the ffp tools.
BTW, when you use QEMU to emulate a ARM platform, you are not crosscompiling anymore. Then you are emulating your target platform, so it's just compiling.
It is possible that software compiled on ARM-Debian (or *any* ARM platform) won't run on your NAS, due to wrong or missing libraries.
The trick of FFP is that it uses it's own libraries. 'Normal' linux software use the libraries in /lib, but Fonz patched the FFP build tools to build binaries which uses the libraries in /ffp/lib. That is why the FFP packages are hardly firmware dependent, unlike for instance optware.
Finally, I get the ssh login prompt at 5 seconds as well. However, the password prompt takes 55 more seconds to appear. What could be the root cause for that?
Maybe something is keeping the processor very busy? Have a look with 'top'.
Difference in libraries between firmware 2.10 and 3.22?
Shouldn't be possible. As said FFP is firmware independent. SSH is not using any firmware file, except the kernel itself.
How can I tell which is the firmware linux version? Because when I type uname -a I guess I get the chrooted version, right?
No. uname gives information about the kernel, and chrooting doesn't change the kernel.
Offline
Finally, I get the ssh login prompt at 5 seconds as well. However, the password prompt takes 55 more seconds to appear. What could be the root cause for that?
I saw the same behaviour on another NAS. It turned out to be DNS related. Putting 'UseDNS no' in /etc/ssh/sshd_config solved the problem.
Offline
Thank you Mijzelf.
Yes, it corrected the ssh login delay problem. Now it works just as you described.
I was going to post the solution but you did it earlier than me.
For future reference the link that explains this behaviour is: http://www.openssh.org/faq.html#3.3
Offline
Pages: 1