Also, I have tried the test on this machine (with snv_92) to many different system(including snv_67, snv_91, s10u5), this problem always exist.
2008/7/15, zhihui Chen <[EMAIL PROTECTED]>: > > I can try snoop to check. But I dont think this problem is caused by the > other end. The other end is one machine with S10U5, I have tried this > test on other machines with snv_91 or privious build, no problem. > > 2008/7/15, Brian Utterback <[EMAIL PROTECTED]>: >> >> I don't know what is going on, but to me it looks like the problem is at >> the other end. This shows that rcp is getting a premature EOF indication on >> the data stream. Either the local OS is erroneously delivering an EOF when >> one was received (unlikely) or the other end sent it. You could use snoop to >> check which it is. You could use truss and snoop on the other end to help >> you determine why. A snoop would confirm that the data stream was actually >> closed by the other host, since firewalls have been known to do this kind of >> thing. >> >> >> zhihui Chen wrote: >> >>> Hello all, I have met a strange rcp issue with snv_92. When I copy a file >>> from remote machine to local through rcp, the copy result will be decided by >>> file size. If the size of file <=8k, then rcp is OK, like following: >>> intel6# rcp irperf:`pwd`/test8k . >>> intel6# ls -l test8k >>> -rw-r--r-- 1 root root 8192 Jul 14 23:50 test8k >>> If the size of file >8k, the rcp does work, like following: >>> >>> intel6# rcp irperf:`pwd`/test10k . >>> rcp: dropped connection >>> intel6# ls -l test10k >>> -rw-r--r-- 1 root root 0 Jul 14 23:51 test10k >>> >>> But if I add "truss" before rcp, then rcp works, like following: >>> intel6# truss rcp irperf:`pwd`/test10k . >>> ..... >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 10240) = 7300 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 2940) = 2920 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 20) = 20 >>> write(5, "\0\0\0\0\0\0\0\0\0\0\0\0".., 10240) = 10240 >>> fcntl(5, F_FREESP64, 0x08027B44) = 0 >>> close(5) = 0 >>> read(4, "\0", 1) = 1 >>> write(4, "\0", 1) = 1 >>> read(4, 0x08027C30, 1) = 0 >>> close(4) = 0 >>> _exit(0) >>> intel6# ls -l test10k >>> -rw-r--r-- 1 root root 10240 Jul 14 23:53 test10k >>> >>> If the size of file become larger, then "truss rcp" does not work either, >>> like following: >>> intel6# truss rcp irperf:`pwd`/test100k . >>> ....... >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 65536) = 13140 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 52396) = 4380 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 48016) = 7300 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 40716) = 8760 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 31956) = 10220 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 21736) = 11680 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 10056) = 1624 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8432) = 7300 >>> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0".., 1132) = 328 >>> read(4, 0x080D698C, 804) = 0 >>> llseek(5, 0, SEEK_CUR) = 0 >>> fcntl(5, F_FREESP64, 0x08027B44) = 0 >>> write(4, "01 r c p : d r o p p e".., 25) = 25 >>> rcp: dropped connection >>> write(2, " r c p : d r o p p e d".., 24) = 24 >>> close(5) = 0 >>> _exit(1) >>> intel6# ls -l test100k >>> -rw-r--r-- 1 root root 0 Jul 14 23:45 test100k >>> Does anyone have met similar issue and how to solve this issue? >>> ----- >>> zhihui >>> Intel OpenSolaris Team >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> networking-discuss mailing list >>> [email protected] >>> >> >> -- >> blu >> >> There are two rules in life: >> Rule 1- Don't tell people everything you know >> ---------------------------------------------------------------------- >> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom >> > > > > -- > zhihui > Intel OpenSolaris Team -- zhihui Intel OpenSolaris Team
_______________________________________________ networking-discuss mailing list [email protected]
