[Bug 352841] Re: SCP over IPv6 address is very Slow. Takes Hours
Prasad Tadi
ptadi at roshitech.com
Sat Apr 4 01:18:11 BST 2009
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.
cruise at CC-branch:~/newcc/projects/branch-build/dt-RelEng$ scp
desktone.tar [fe80::250:56ff:fe8d:1ddc%eth1]:/tmp/x.tar
cruise at fe80::250:56ff:fe8d:1ddc%eth1's password:
desktone.tar
100% 71MB 35.3MB/s 00:02
cruise at 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
ruise at CC-branch:~/newcc/projects/branch-build/dt-RelEng$ scp
desktone.tar [fe80::250:56ff:fe8d:403c%eth0]:/tmp/x.tar
cruise at 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
ETAcruise at 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
root at 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 <ptadi at 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
> root at 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
ptadi at 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.
More information about the Ubuntu-server-bugs
mailing list