similar to: openssh-based file transfers (e.g. rsync, scp, ...) are running 40 (!!) times faster via IPv4 than IPv6

Displaying 20 results from an estimated 200 matches similar to: "openssh-based file transfers (e.g. rsync, scp, ...) are running 40 (!!) times faster via IPv4 than IPv6"

2018 Nov 07
2
openssh-based file transfers (e.g. rsync, scp, ...) are running 40 (!!) times faster via IPv4 than IPv6
Vincenzo, thanks for answering !!! As I found out before that this slow down only happens for encrypted transmissions, I've followed your suggestion and tested with a https-based download, from my Nextcloud instance on my VPS. Same slow speed when connecting via IPv6, and as fast as expected when connecting via IPv4. Just to confirm: There's NO dependency/relation between openssh and
2018 Nov 07
2
openssh-based file transfers (e.g. rsync, scp, ...) are running 40 (!!) times faster via IPv4 than IPv6
Servus Philipp, Unfortunately the traceroute(6) results are both more or less random. Sometimes traceroute "hangs" a while, wherever, sometimes traceroute6. Sometimes traceroute is faster, sometimes traceroute6. Not reliable. Your MTU question, tried as adviced: Maximum size for IPv4 is 1466, and max size for IPv6 is 1444. Exceeding these values leads to a "ping: local error:
2020 Apr 28
3
Diagnosing IPv6 routing
On 4/28/2020 3:17 PM, Chris Adams wrote: > - gateway sends a router solicitation and gets a router advertisement > with "stateful config" set, which tells gateway to do DHCPv6 (but > default route comes from RA) I'm not seeing any outbound IPv6 traffic from my CentOS 7 box on the WAN interface. I do see RA's emitting from the LAN interface, from radvd. Is there
2015 Feb 28
3
Update
Hi Sandy, Please can you provide the output from an *i**fconfig -a* command? This should give an idea of what is going on. Turning off IPv6 will not be necessary if you can find the actual cause of the problem. You would not get this error message if you only have a link local address configured on your interface. You must have some form of global address. Also, the IPv6 address is that of
2015 Mar 02
3
Update
Hi Sandy, Thanks! Curious. Do you have any other interfaces? ifconfig -a should show them all including loopback. What is puzzling me is that it should not even attempt to use IPv6 to reach a global address when it only has a link-local address. It should gracefully fall back to IPv4 (as per RFC 6724 or RFC 3484 depending on the kernel version). Since you have an IPv4 address and I assume an
2015 Mar 02
3
Update
On 02/03/15 15:05, sandy.napoles at eccmg.cupet.cu wrote: > ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:0c:29:82:ec:80 > inet addr:172.18.68.8 Bcast:172.18.68.31 Mask:255.255.255.224 > inet6 addr: fe80::20c:29ff:fe82:ec80/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:107940 errors:0
2015 Mar 02
2
Update
Thanks. No other interfaces (ifconfig -a)? Also output of ip -f inet6 route would be useful. David ------------------------------------------------------------------------ Dr David Holder CEng FIET MIEEE Erion Ltd, An Cala, Inverkirkaig, Lochinver, Sutherland, IV27 4LR, UK Reception: +44 (0)1422 207000 Direct Dial: +44 (0)131 2026317 http://www.erion.co.uk Registered in England and
2020 Apr 30
2
Diagnosing IPv6 routing
I discovered that IPv6 is sort of working when I got an email rejection from Comcast for not having an IPv6 PTR record. I discovered I could telnet to port 25 on their MX server over IPv6! I then found I could tracroute6 to them, but I couldn't to my Linode VPS in Fremont. It gets to the data center and stops. Going the other way, my Linode can traceroute6 almost to my AT&T-hosted
2015 Mar 02
5
Update
On 02/03/15 16:21, sandy.napoles at eccmg.cupet.cu wrote: > My OS is Debian 7 and I only writte git pull > >> On 02/03/15 15:05, sandy.napoles at eccmg.cupet.cu wrote: >>> ifconfig -a >>> eth0 Link encap:Ethernet HWaddr 00:0c:29:82:ec:80 >>> inet addr:172.18.68.8 Bcast:172.18.68.31 >>> Mask:255.255.255.224 >>>
2015 Mar 02
7
Update
On 02/03/15 16:45, sandy.napoles at eccmg.cupet.cu wrote: > root at samba:/home/samba-master# git pull > error: Failed to connect to 2001:638:603:d06e::80:230: Network is > unreachable while accessing http://git.samba.org/samba.git/info/refs > fatal: HTTP request failed > root at samba:/home/samba-master# > > > >> On 02/03/15 16:21, sandy.napoles at eccmg.cupet.cu
2008 Jun 26
1
6to4 suddenly stopped working to 2001: addresses
I've got three installations of FreeBSD using 6to4 in three different physical locations, attached to three different ISPs. Sometime in the last few days all of them have stopped talking to IPv6 addesse which are not also 6to4. I can still talk to 2002: addresses, but not to 2001: addresses. This all worked fine a few days ago, and nothing has changed in the config of any of these machines. I
2015 Mar 02
3
Update
Try lynx http://git.samba.org/ Or indeed telnet git.samba.org 80 GET / HTTP/1.0 OR telnet6 git.samba.org 80 GET / HTTP/1.0 There are blank lines after the GETs. These will show if you have connectivity over HTTP to the Samba git repository over v4 and/or v6. David ------------------------------------------------------------------------ Dr David Holder CEng FIET MIEEE Erion Ltd, An
2015 Mar 02
2
Update
Perfect thanks. Do you have a web proxy in your network? That would explain this sequence of events. ------------------------------------------------------------------------ Dr David Holder CEng FIET MIEEE Erion Ltd, An Cala, Inverkirkaig, Lochinver, Sutherland, IV27 4LR, UK Reception: +44 (0)1422 207000 Direct Dial: +44 (0)131 2026317 http://www.erion.co.uk Registered in England and Wales.
2015 Mar 02
1
Update
On 02/03/15 17:20, David Holder wrote: > Hi Roland, > > It will be useful to see the resolv.conf. However, I don't think that > this is a name resolution issue as it is clear that git.samba.org is > being resolved to at least the v6 address. If that works then A & AAAA > records should be returned to the resolver regardless of the transport > used. There must be
2015 Mar 02
1
Update
I do not understand that you say me???? > Any reason you are not using the git protocol? > > git://git.samba.org > > David > ------------------------------------------------------------------------ > Dr David Holder CEng FIET MIEEE > > Erion Ltd, An Cala, Inverkirkaig, Lochinver, Sutherland, IV27 4LR, UK > > Reception: +44 (0)1422 207000 > > Direct Dial: +44
2015 Feb 28
4
Update
I do not working with ipv6, I have disable, but I have the same error, I can read in internet that this ipv6 ip 2001:638:603:d06e::80:230: belong to url samba.org.... If I try to connect to this url using some navegator I connected perfect....but when I run git pull using command line I can not connect.. > Am 28.02.2015 um 15:37 schrieb sandy.napoles at eccmg.cupet.cu: >> Hello list,
2015 Sep 23
2
UPS/NUT with openSUSE 13.1
On Sep 22, 2015, at 3:47 PM, Rob Groner <rgroner at RTD.com> wrote: > So, here is what I think I know: > > NUT is using the libusb-1.0.20 library, by way of the libusb-compat layer. When I check the configure log, it says "libusb-0.1.12" I'm not sure why it says that, as in where it gets that value, as that version doesn't correspond to anything I installed. I
2015 Mar 02
0
Update
eth0 Link encap:Ethernet HWaddr d0:27:88:64:e4:01 inet addr:172.18.70.100 Mask:255.255.255.224 inet6 addr: fe80::d227:88ff:fe64:e401/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1413908 errors:0 dropped:0 overruns:0 frame:0 TX packets:447039 errors:0 dropped:0 overruns:0 carrier:0 collisions:0
2015 Mar 02
0
Update
in /etc/gai.conf all is coment > Hi Sandy, > > Thanks! Curious. Do you have any other interfaces? ifconfig -a should > show them all including loopback. > > What is puzzling me is that it should not even attempt to use IPv6 to > reach a global address when it only has a link-local address. It should > gracefully fall back to IPv4 (as per RFC 6724 or RFC 3484 depending on
2015 Mar 02
0
Update
ifconfig -a eth0 Link encap:Ethernet HWaddr 00:0c:29:82:ec:80 inet addr:172.18.68.8 Bcast:172.18.68.31 Mask:255.255.255.224 inet6 addr: fe80::20c:29ff:fe82:ec80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:107940 errors:0 dropped:0 overruns:0 frame:0 TX packets:109315 errors:0 dropped:0 overruns:0 carrier:0