Bryan, Have a good news. I installed Jaunt (9.04) on a new VM and I could push the Large size files without any issues over IPv6.
So it looks like OS/ Kernl level issue. I can use the new machine (Jaunt) and can push to both Hardy and Jaunt machines. At least it solved one issue, but we may need to re-test our product with new OS. Thanks Prasad On Apr 3, 2009, at 8:18 PM, Prasad Tadi wrote: > > Bryan, > > Thanks for the details.... > > Here is some more data following your mail. > The problem still persists... > > > However, when I run the command on local link (local machine's) , It > completes and not even a single trace on tshark ip6 -i eth1 > > But when I traced on " lo", it did show the data. > > cru...@cc-branch:~/newcc/projects/branch-build/dt-RelEng$ scp > desktone.tar [fe80::250:56ff:fe8d:1ddc%eth1]:/tmp/x.tar > cru...@fe80::250:56ff:fe8d:1ddc%eth1's password: > desktone.tar > 100% 71MB 35.3MB/s 00:02 > cru...@cc-branch:~/newcc/projects/branch-build/dt-RelEng$ > > # tshark ip6 -i lo > <SNIP> > > 8.381329 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc SSHv2 > Encrypted response packet len=48 > 8.381401 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc > SSHv2 Encrypted request packet len=32 > 8.382301 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc > SSHv2 Encrypted response packet len=128 > 8.383901 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc > SSHv2 Encrypted request packet len=32 > 8.383932 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc TCP > 42214 > ssh [FIN, ACK] Seq=74203897 Ack=30225 Win=39040 Len=0 > TSV=7656054 TSER=7656054 > 8.419376 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc TCP > ssh > 42214 [ACK] Seq=30225 Ack=74203898 Win=852224 Len=0 TSV=7656058 > TSER=7656054 > 8.469483 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc TCP > ssh > 42214 [FIN, ACK] Seq=30225 Ack=74203898 Win=852224 Len=0 > TSV=7656063 TSER=7656054 > 8.469504 fe80::250:56ff:fe8d:1ddc -> fe80::250:56ff:fe8d:1ddc TCP > 42214 > ssh [ACK] Seq=74203898 Ack=30226 Win=39040 Len=0 TSV=7656063 > TSER=7656063 > > So I think though the Document suggests that it should use its own, > the OS /APP is intelligent to route the packets through LOOP BACK > (lo). > > > Now the data while transferring to next node..... > > I tried both eth1 and eth0. > > First the SCP command > ru...@cc-branch:~/newcc/projects/branch-build/dt-RelEng$ scp > desktone.tar [fe80::250:56ff:fe8d:403c%eth0]:/tmp/x.tar > cru...@fe80::250:56ff:fe8d:403c%eth0's password: > desktone.tar > 2% 2112KB 2.1MB/s 00:33 ETA > desktone.tar > 2% 2112KB 1.7MB/s 00:41 ETA > desktone.tar > 2% 2112KB 1.5MB/s 00:45 ETA > desktone.tar > 2% 2112KB 1.2MB/s - stalled - > desktone.tar > 2% 2112KB 1.1MB/s - stalled - > desktone.tar > 3% 2208KB 918.8KB/s 01:16 ETA > desktone.tar > 3% 2208KB 744.2KB/s 01:34 > etacru...@cc-branch:~/newcc/projects/branch-build/dt-RelEng$ > > I killed after some time.... > > > tshark ip6 output.... on the originator.... No Errors > > <SNIP> > 16.447595 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c SSHv2 > Encrypted request packet len=2856 > 16.657429 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 16.657777 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=158913 Win=64128 Len=0 TSV=78934229 > TSER=7554125 > 16.657806 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 Encrypted request packet len=2856 > 16.867469 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 16.867773 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=160341 Win=64128 Len=0 TSV=78934250 > TSER=7554146 > 16.867797 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 Encrypted request packet len=2856 > 17.077691 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.078810 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=161769 Win=64128 Len=0 TSV=78934271 > TSER=7554167 > 17.078837 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.078843 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079060 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=163197 Win=64128 Len=0 TSV=78934271 > TSER=7554167 > 17.079071 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079075 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=164625 Win=62720 Len=0 TSV=78934271 > TSER=7554167 > 17.079086 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079330 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=166053 Win=64128 Len=0 TSV=78934271 > TSER=7554167 > 17.079340 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079345 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=167481 Win=62720 Len=0 TSV=78934271 > TSER=7554167 > 17.079353 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079566 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=170337 Win=62720 Len=0 TSV=78934271 > TSER=7554167 > 17.079572 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079577 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079581 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.079788 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=173193 Win=62720 Len=0 TSV=78934271 > TSER=7554167 > 17.111825 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=174621 Win=64128 Len=0 TSV=78934275 > TSER=7554167 > 17.111849 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.151649 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=176049 Win=64128 Len=0 TSV=78934279 > TSER=7554170 > 17.151673 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c > SSHv2 [TCP Retransmission] Encrypted request packet len=1428 > 17.155241 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [ACK] Seq=2209 Ack=177478 Win=64128 Len=0 TSV=78934279 > TSER=7554174 > 17.155521 fe80::250:56ff:fe8d:403c -> fe80::250:56ff:fe8d:5c00 TCP > ssh > 53692 [FIN, ACK] Seq=2209 Ack=177478 Win=64128 Len=0 > TSV=78934279 TSER=7554174 > 17.155534 fe80::250:56ff:fe8d:5c00 -> fe80::250:56ff:fe8d:403c TCP > 53692 > ssh [ACK] Seq=177478 Ack=2210 Win=10496 Len=0 TSV=7554174 > TSER=78934279 > 335 packets captured > r...@cc-branch:~# > > Thanks > Prasad > > > On Apr 3, 2009, at 4:53 PM, Bryan McLellan wrote: > >> On Fri, Apr 3, 2009 at 12:23 PM, Prasad Tadi <pt...@roshitech.com> >> wrote: >>> I am not really an expert, but I think the "Local link" may use >>> Loop back >>> >>> Link-local is the fe80 addresses that refer to devices on a >>> particular data link, such as a single Ethernet network, or a >>> point-to-point serial connection. If you're using your own link- >>> local address, then yes, that traffic will - I believe - traverse >>> the loopback interface. >> >> This is not correct. If you read the link I provided earlier it >> starts >> with "All interfaces have an associated link-local address". Loopback >> is it's own interface (lo) and is independent of your ethN >> interfaces. >> The loopback interface also has it's own inet6 address (ifconfig >> lo0 | >> grep inet6) in the specified ipv6 loopback address range. >> >>> eth1 Link encap:Ethernet HWaddr 00:50:56:b5:52:c1 >>> inet6 addr: fdf8:c879:493e:1:250:56ff:feb5:52c1/64 >>> Scope:Global >>> inet6 addr: fe80::250:56ff:feb5:52c1/64 Scope:Link >> >> The second address, that starts with fe80::, and additionally says >> "Scope: Link" is the "Link Local" address. This is because this >> address is for the local link only. >> >> Try copying between two hosts using these address with Scope:Link to >> rule out any addressing problems. Because these are local addresses, >> you may need to specify the interface you want scp to use by adding >> '%interface' to the end of the address, such as: >> >> scp -6 desktone.tar [fdf8:c879:493e:1:250:56ff:feb5:52c1%eth1]:/tmp >> >> It may be helpful to run 'sudo tshark ip6' on the originating host >> while copying the file to look for any network errors. >> >> -- >> SCP over IPv6 address is very Slow. Takes Hours >> https://bugs.launchpad.net/bugs/352841 >> You received this bug notification because you are a direct >> subscriber >> of the bug. >> >> Status in “openssh” source package in Ubuntu: New >> >> Bug description: >> Binary package hint: openssh-server >> >> Hi, >> >> I am using Ubutu Hardy release 8.04 and openssh 4.7P1 >> >> >> lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 8.04.1 >> Release: 8.04 >> Codename: hardy >> r...@htaf1:~# >> OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 >> >> >> When I copy a 50+ MB file from one system to another Ubuntu >> >> Using IPv4 address it took just less than 3 sec. >> Same thing over IPv6 took more than an hour ( 1 Hr and 20 Min) >> >> I copied the file using local IPv6 address. It ran fine. May be it >> is using loop back, instead of real IPv6 address >> >> >> When I initiate the same from a free BSD box to BSD It took less >> than 3 sec on both Ipv4 and IPv6. >> I can also copy from Ubuntu to a FreeBSD box faster both Ipv4 and >> IPv6 addreses. >> >> I just can't copy the same from a Ubutu to Ubutu or other machines >> to Ubuntu over IPv6 address. >> >> It is very critical for our product :-( >> >> I even tried getting the latest OpenSSH package from openssh.org >> and compiled that module and ran that sshd. >> Still no use. Same old behaviour. >> >> It starts negotiating at 1.5 Mb/ sec and slowly drops to few KB / >> sec and stalls the copy process during the time. >> >> Any updates or known issues. >> >> thanks in advance for your information on this issue. > > ====== Together we can build a better process ======= > Prasad Tadi > pt...@roshitech.com > http://www.roshitech.com > Fax: (270) 568-6295 > cell: 603-809-7186 > > -- > SCP over IPv6 address is very Slow. Takes Hours > https://bugs.launchpad.net/bugs/352841 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in “openssh” source package in Ubuntu: New > > Bug description: > Binary package hint: openssh-server > > Hi, > > I am using Ubutu Hardy release 8.04 and openssh 4.7P1 > > > lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 8.04.1 > Release: 8.04 > Codename: hardy > r...@htaf1:~# > OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 > > > When I copy a 50+ MB file from one system to another Ubuntu > > Using IPv4 address it took just less than 3 sec. > Same thing over IPv6 took more than an hour ( 1 Hr and 20 Min) > > I copied the file using local IPv6 address. It ran fine. May be it > is using loop back, instead of real IPv6 address > > > When I initiate the same from a free BSD box to BSD It took less > than 3 sec on both Ipv4 and IPv6. > I can also copy from Ubuntu to a FreeBSD box faster both Ipv4 and > IPv6 addreses. > > I just can't copy the same from a Ubutu to Ubutu or other machines > to Ubuntu over IPv6 address. > > It is very critical for our product :-( > > I even tried getting the latest OpenSSH package from openssh.org > and compiled that module and ran that sshd. > Still no use. Same old behaviour. > > It starts negotiating at 1.5 Mb/ sec and slowly drops to few KB / > sec and stalls the copy process during the time. > > Any updates or known issues. > > thanks in advance for your information on this issue. ====== Together we can build a better process ======= Prasad Tadi pt...@roshitech.com http://www.roshitech.com Fax: (270) 568-6295 cell: 603-809-7186 -- SCP over IPv6 address is very Slow. Takes Hours https://bugs.launchpad.net/bugs/352841 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
