Hi All,

I have noticed this problem when I try to connect to two different machines in
two different continents. One is on cable (US) the other on ISDN ADSL
(Greece). In the evening and sometimes weekends ssh connections from my
laptop to these two PCs are either taking ages or time out. This is ssh
connections to sshd which is listening to random ports in the 200+ or 12000+
ranges. If I eventually manage to connect the latency is ridiculous - up to
5 seconds! Sometimes I enter a passwd, if I can get that far and then wait
for hours with no response. Eventually, I have to close the terminal.

Tracerouting does not get through although some clever tcptraceroute strings
may on occasions (intermittently) get through.

Both servers run on domestic networks. BTW, ssh-ing to servers in datacenters
with their big fiber-optic pipes, although relatively slow in peak times,
always gets through.

The strange thing is that there is no problem talking to these boxen while
they run Google-Talk, it's only the ssh connection that seems to suffer.

Have you come across such a problem before? How can I troubleshoot it? In
this day and age of broadband connections it seems strange to get worse
performance than on a dialup network . . . I mean I have run VNC connections
over a 56k dial up with more responsiveness than this!
--
Regards,
Mick

> Hi All,
>
> I have noticed this problem when I try to connect to two different
> machines in
> two different continents. One is on cable (US) the other on ISDN ADSL
> (Greece). In the evening and sometimes weekends ssh connections from my
> laptop to these two PCs are either taking ages or time out. This is ssh
> connections to sshd which is listening to random ports in the 200+ or
> 12000+
> ranges. If I eventually manage to connect the latency is ridiculous - up
> to
> 5 seconds! Sometimes I enter a passwd, if I can get that far and then
> wait
> for hours with no response. Eventually, I have to close the terminal.
>
> Tracerouting does not get through although some clever tcptraceroute
> strings
> may on occasions (intermittently) get through.
>
> Both servers run on domestic networks. BTW, ssh-ing to servers in
> datacenters
> with their big fiber-optic pipes, although relatively slow in peak times,
> always gets through.
>
> The strange thing is that there is no problem talking to these boxen while
> they run Google-Talk, it's only the ssh connection that seems to suffer.
>
> Have you come across such a problem before? How can I troubleshoot it?
> In
> this day and age of broadband connections it seems strange to get worse
> performance than on a dialup network . . . I mean I have run VNC
> connections
> over a 56k dial up with more responsiveness than this!
> --
> Regards,
> Mick
>

Hi Mick,

I have noticed these problems myself as well sometimes when connecting to
a server connected to ADSL in the UK (I am currently in NL myself)

Fortunately for me, I have full access to the ADSL-router from that server
when I can connect and I found it usually coincides with connection
problems between the router and the ISP.

Can you (or someone else) check if there are any problems with this?

Another cause could be that the ISP (you did mention these are domestic
networks) is throttling/blocking certain ports/services/connection types.
I have heard of ISPs in NL and Belgium (not sure if it's true) that tend
to change these policies depending on the time of day.

This could also be done by your ISP.
Are the SSH-ports of the servers in DataCenters on 22 (default) or in the
higher 200+ and 12000+ range?

Kind regards,

Joost Roeleveld

--
gentoo-user@gentoo.org mailing list

On 27 Nov 2007, at 10:19, Mick wrote:


Hi All,

I have noticed this problem when I try to connect to two different
machines in

two different continents. One is on cable (US) the other on ISDN ADSL
(Greece). In the evening and sometimes weekends ssh connections
from my
laptop to these two PCs are either taking ages or time out. This is
ssh
connections to sshd which is listening to random ports in the 200+
or 12000+
ranges. If I eventually manage to connect the latency is ridiculous
- up to
5 seconds! Sometimes I enter a passwd, if I can get that far and
then wait

for hours with no response. Eventually, I have to close the terminal.

Tracerouting does not get through although some clever tcptraceroute
strings

may on occasions (intermittently) get through.

Both servers run on domestic networks. BTW, ssh-ing to servers in
datacenters
with their big fiber-optic pipes, although relatively slow in peak
times,

always gets through.

The strange thing is that there is no problem talking to these boxen
while
they run Google-Talk, it's only the ssh connection that seems to
suffer.


Have you come across such a problem before? How can I troubleshoot
it? In
this day and age of broadband connections it seems strange to get
worse
performance than on a dialup network . . . I mean I have run VNC
connections

over a 56k dial up with more responsiveness than this!
--
Regards,
Mick


I've run across the same kind of issues on certain ISPs when using non-
standard ports for sshd. Given other connections (Gtalk) are working,
the first thing I would try in your position is to see if there is a
difference when using 22 versus your random port. With certain ISPs in
the UK I've found SSH connections to be unusable on anything but the
default port. Of course it has everything to do with the "smart"
traffic shaping at the ISP and there was nothing I could do about it.

--
Christopher
--
gentoo-user@gentoo.org mailing list

On 11/27/07, Mick <michaelkintzios@gmail.com> wrote:
Have you come across such a problem before?Â*Â*How can I troubleshoot it?Â*Â*In
this day and age of broadband connections it seems strange to get worse
performance than on a dialup network . . .Â*Â*I mean I have run VNC connections

over a 56k dial up with more responsiveness than this!

Tune QoS (Quality of Service). It's not very trivial, but there are some good howtos/articles.
--
Vladimir Rusinov

GreenMice Solutions: IT-решени� на базе Linux
http://greenmice.info/

Christopher Copeland wrote:
>
> On 27 Nov 2007, at 10:19, Mick wrote:
>
>> Hi All,
>>
>> I have noticed this problem when I try to connect to two different
>> machines in
>> two different continents. One is on cable (US) the other on ISDN ADSL
>> (Greece). In the evening and sometimes weekends ssh connections from my
>> laptop to these two PCs are either taking ages or time out. This is ssh
>> connections to sshd which is listening to random ports in the 200+ or
>> 12000+
>> ranges. If I eventually manage to connect the latency is ridiculous
>> - up to
>> 5 seconds! Sometimes I enter a passwd, if I can get that far and
>> then wait
>> for hours with no response. Eventually, I have to close the terminal.
>>
>> Tracerouting does not get through although some clever tcptraceroute
>> strings
>> may on occasions (intermittently) get through.
>>
>> Both servers run on domestic networks. BTW, ssh-ing to servers in
>> datacenters
>> with their big fiber-optic pipes, although relatively slow in peak
>> times,
>> always gets through.
>>
>> The strange thing is that there is no problem talking to these boxen
>> while
>> they run Google-Talk, it's only the ssh connection that seems to suffer.
>>
>> Have you come across such a problem before? How can I troubleshoot
>> it? In
>> this day and age of broadband connections it seems strange to get worse
>> performance than on a dialup network . . . I mean I have run VNC
>> connections
>> over a 56k dial up with more responsiveness than this!
>> --
>> Regards,
>> Mick
>
> I've run across the same kind of issues on certain ISPs when using
> non-standard ports for sshd. Given other connections (Gtalk) are
> working, the first thing I would try in your position is to see if
> there is a difference when using 22 versus your random port. With
> certain ISPs in the UK I've found SSH connections to be unusable on
> anything but the default port. Of course it has everything to do with
> the "smart" traffic shaping at the ISP and there was nothing I could
> do about it.
> --
> Christopher

I also ran into something like this on a local network. I corrected
this by adding the remote systems to my hosts file and putting the entry
in the host file on the remote system. I'm not sure what affect this
had but it worked like a charm after that. I guess it lets each other
know who the other is or something.

Hope that helps.

Dale

:-) :-) :-) :-)
--
gentoo-user@gentoo.org mailing list

> Christopher Copeland wrote:
>>
>> On 27 Nov 2007, at 10:19, Mick wrote:
>>
>>> Hi All,
>>>
>>> I have noticed this problem when I try to connect to two different
>>> machines in
>>> two different continents. One is on cable (US) the other on ISDN ADSL
>>> (Greece). In the evening and sometimes weekends ssh connections from
>>> my
>>> laptop to these two PCs are either taking ages or time out. This is
>>> ssh
>>> connections to sshd which is listening to random ports in the 200+ or
>>> 12000+
>>> ranges. If I eventually manage to connect the latency is ridiculous
>>> - up to
>>> 5 seconds! Sometimes I enter a passwd, if I can get that far and
>>> then wait
>>> for hours with no response. Eventually, I have to close the terminal.

<snip>

>> I've run across the same kind of issues on certain ISPs when using
>> non-standard ports for sshd. Given other connections (Gtalk) are
>> working, the first thing I would try in your position is to see if
>> there is a difference when using 22 versus your random port. With
>> certain ISPs in the UK I've found SSH connections to be unusable on
>> anything but the default port. Of course it has everything to do with
>> the "smart" traffic shaping at the ISP and there was nothing I could
>> do about it.
>> --
>> Christopher
>
> I also ran into something like this on a local network. I corrected
> this by adding the remote systems to my hosts file and putting the entry
> in the host file on the remote system. I'm not sure what affect this
> had but it worked like a charm after that. I guess it lets each other
> know who the other is or something.
>
> Hope that helps.
>
> Dale

Hi Dale,

Your comment might actually indicate a problem with the DNS-server
involved. Configuring the server(s) in the "hosts" file would be one
solution.

Mick, do you use IP-addresses or hostnames when you try to connect?
If you are using hostnames, can you test with IP-addresses instead?

Kind regards,

Joost Roeleveld

--
gentoo-user@gentoo.org mailing list

Dale wrote:
> <snipped>
>
> I also ran into something like this on a local network. I corrected
> this by adding the remote systems to my hosts file and putting the entry
> in the host file on the remote system. I'm not sure what affect this
> had but it worked like a charm after that. I guess it lets each other
> know who the other is or something.
>
> Hope that helps.
>
> Dale
>
> :-) :-) :-) :-)

I've had this problem as well. I've added "UseDNS no" to the
sshd_config file and that had the same result. I usually only had high
latency establishing the connection though. Once the connection was
established and I was logged in, everything was fast again.

I've also had connection issues while transferring files through ssh,
and I got around that (somewhat) by added "-l" to the scp command. This
tries to throttle the connection speed, and I can usually keep a
connection going with that. I say that is somewhat fixed the issue
because I also need to use ssh to port forward to an internal database
and run scripts there, but there's no way that I know to do the same
throttling with a port forwarding ssh command.

Chris

--
gentoo-user@gentoo.org mailing list

Thank you all for your replies,

On Tuesday 27 November 2007, Chris Frederick wrote:
> Dale wrote:

> > I also ran into something like this on a local network. I corrected
> > this by adding the remote systems to my hosts file and putting the entry
> > in the host file on the remote system.
[ship...]

> I've had this problem as well. I've added "UseDNS no" to the
> sshd_config file and that had the same result. I usually only had high
> latency establishing the connection though. Once the connection was
> established and I was logged in, everything was fast again.

The problem is not with the DNS servers. I use IP addresses to access these
machines and when I have tried FQDNs it makes no odds.

> I've also had connection issues while transferring files through ssh,
> and I got around that (somewhat) by added "-l" to the scp command. This
> tries to throttle the connection speed, and I can usually keep a
> connection going with that. I say that is somewhat fixed the issue
> because I also need to use ssh to port forward to an internal database
> and run scripts there, but there's no way that I know to do the same
> throttling with a port forwarding ssh command.

The -l option is to apply a protocol specific type of QoS and limit the
bandwidth consumed by scp so that other critical services on the server don't
run dry. My problem is that I do not seem to have enough bandwidth to start
with.

The ports of the servers are random numbers in the 200+ and 12000+ range and I
have checked that no other applications are using/listening on these ports.
I've not tried port 22 yet, but I'll give it a go tonight. I tend to use
higher random ports just to achieve some basic 'security by obscurity' from
script kiddies and botnets. The issue with port 22 is that the
world-and-his-wife will try to hack in and cause DoS to the little bandwidth
that seems to be available. Ha! I'll deal with this at the firewall.

The datacenter servers are listening on port 22. This difference in
performance between the production and the domestic servers also made me
think that there may well be some traffic shaping by the ISPs at their
routers, but don't know if I can test this for definite somehow.

I don't think that setting up QoS at the domestic servers is going to make any
difference. These machines are not stressed at all and off peak I can access
them fine. It is at peak times that things really go pear shape, hence it
should be a network congestion/traffic shaping issue. I don't know if people
started going mad at the pre-Christmas online shopping and things have been
particularly bad since last Saturday, or if it is just some ISP network
maintenance that made my connections impossible.

More about my trials and tribulations on port 22 tomorrow . . .
--
Regards,
Mick

Mick wrote:

Thank you all for your replies,

On Tuesday 27 November 2007, Chris Frederick wrote:


Dale wrote:






I also ran into something like this on a local network. I corrected
this by adding the remote systems to my hosts file and putting the entry
in the host file on the remote system.



[ship...]



I've had this problem as well. I've added "UseDNS no" to the
sshd_config file and that had the same result. I usually only had high
latency establishing the connection though. Once the connection was
established and I was logged in, everything was fast again.



The problem is not with the DNS servers. I use IP addresses to access these
machines and when I have tried FQDNs it makes no odds.



I've also had connection issues while transferring files through ssh,
and I got around that (somewhat) by added "-l" to the scp command. This
tries to throttle the connection speed, and I can usually keep a
connection going with that. I say that is somewhat fixed the issue
because I also need to use ssh to port forward to an internal database
and run scripts there, but there's no way that I know to do the same
throttling with a port forwarding ssh command.



The -l option is to apply a protocol specific type of QoS and limit the
bandwidth consumed by scp so that other critical services on the server don't
run dry. My problem is that I do not seem to have enough bandwidth to start
with.

The ports of the servers are random numbers in the 200+ and 12000+ range and I
have checked that no other applications are using/listening on these ports.
I've not tried port 22 yet, but I'll give it a go tonight. I tend to use
higher random ports just to achieve some basic 'security by obscurity' from
script kiddies and botnets. The issue with port 22 is that the
world-and-his-wife will try to hack in and cause DoS to the little bandwidth
that seems to be available. Ha! I'll deal with this at the firewall.

The datacenter servers are listening on port 22. This difference in
performance between the production and the domestic servers also made me
think that there may well be some traffic shaping by the ISPs at their
routers, but don't know if I can test this for definite somehow.

I don't think that setting up QoS at the domestic servers is going to make any
difference. These machines are not stressed at all and off peak I can access
them fine. It is at peak times that things really go pear shape, hence it
should be a network congestion/traffic shaping issue. I don't know if people
started going mad at the pre-Christmas online shopping and things have been
particularly bad since last Saturday, or if it is just some ISP network
maintenance that made my connections impossible.

More about my trials and tribulations on port 22 tomorrow . . .




Just to add to this, I was using the IP address too and it was very
slow.* This was also on a local network.* After adding the lines to my
host files, it was fast no matter whether I used the name or the IP
address.* I still don't understand why this matters tho.



Just a thought.



Dale



:-)* :-)* :-)

On Tue, 27 Nov 2007 13:26:18 -0600
Dale <dalek1967@bellsouth.net> wrote:

> Just to add to this, I was using the IP address too and it was very
> slow. This was also on a local network. After adding the lines to my
> host files, it was fast no matter whether I used the name or the IP
> address. I still don't understand why this matters tho.
>
> Just a thought.
>
> Dale

I am guessing your /etc/nsswitch.conf says:
hosts: files dns

in this case, the /etc/hosts file will be consulted before the dns. If
you provide an IP address, it will probably want to do a reverse lookup
to the name (for .ssh/known-hosts for one); if provided a domain name,
it will have to look it up.
--
gentoo-user@gentoo.org mailing list