ssh problem

[randall-22]

hi all,

having a problem since a few months and i cant really figure it out.

i have a debian machine standing in China and i connect from Europe, so
going over there just for this is slightly cumbersome.

i did have some driver issues in the past but after replacing the
network cards it worked fine.

At the moment:
i can login using SSH and issue commands.
but when opening a file or starting top the screen goes black until the
connection times out, reset by peer.

i can copy files to the machine using SCP but i can not copy them back,
it stalls until the time out.

a website is hosted on the machine and you can connect to it but it
keeps on waiting for the server till the morning comes.

the machines acts as a router for a local LAN, eth1 faces the LAN and
eth0 faces the net, no problems for the people on the LAN

not sure what it is but my first suspect would be the firewall/routing,
i use shorewall.

so, before i try disabling the firewall etc... to see if it has any
results and risk losing the working LAN part of the story i wonder if
somebody here has a clue on what it could be.

Thanks anyways,

Randall


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

randall wrote:

> hi all,
>
> having a problem since a few months and i cant really figure it out.
>
> i have a debian machine standing in China and i connect from Europe, so
> going over there just for this is slightly cumbersome.
>
> i did have some driver issues in the past but after replacing the
> network cards it worked fine.
>
> At the moment:
> i can login using SSH and issue commands.
> but when opening a file or starting top the screen goes black until the
> connection times out, reset by peer.
>
> i can copy files to the machine using SCP but i can not copy them back,
> it stalls until the time out.
>
> a website is hosted on the machine and you can connect to it but it
> keeps on waiting for the server till the morning comes.
>
> the machines acts as a router for a local LAN, eth1 faces the LAN and
> eth0 faces the net, no problems for the people on the LAN
>
> not sure what it is but my first suspect would be the firewall/routing,
> i use shorewall.
>
> so, before i try disabling the firewall etc... to see if it has any
> results and risk losing the working LAN part of the story i wonder if
> somebody here has a clue on what it could be.
>
> Thanks anyways,
>
> Randall
>

sorry, wrong list.

but if anybody has some idea its not forbidden to respond anyway.

apologies

Randall


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bertrand Yvain-2]

Hi,

On Wed, Aug 26, 2009 at 04:52:38PM +0200, randall wrote:

> i can login using SSH and issue commands.
> but when opening a file or starting top the screen goes black until the
> connection times out, reset by peer.
>
> i can copy files to the machine using SCP but i can not copy them back,
> it stalls until the time out.
>
> a website is hosted on the machine and you can connect to it but it
> keeps on waiting for the server till the morning comes.
>
> the machines acts as a router for a local LAN, eth1 faces the LAN and
> eth0 faces the net, no problems for the people on the LAN

Looks like a PMTU issue.
Would you happen to have net.ipv4.ip_no_pmtu_disc = 1 in your sysctls?

--
Bertrand Yvain
http://www.lost-oasis.fr/


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

Bertrand Yvain wrote:

> Hi,
>
> On Wed, Aug 26, 2009 at 04:52:38PM +0200, randall wrote:
>> i can login using SSH and issue commands.
>> but when opening a file or starting top the screen goes black until the
>> connection times out, reset by peer.
>>
>> i can copy files to the machine using SCP but i can not copy them back,
>> it stalls until the time out.
>>
>> a website is hosted on the machine and you can connect to it but it
>> keeps on waiting for the server till the morning comes.
>>
>> the machines acts as a router for a local LAN, eth1 faces the LAN and
>> eth0 faces the net, no problems for the people on the LAN
>
> Looks like a PMTU issue.
> Would you happen to have net.ipv4.ip_no_pmtu_disc = 1 in your sysctls?
>

just noticed that i do can cat small files, it hangs on more substantial
sized files though.

but below answers the question, nope.



host:~# cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com
#net/ipv4/icmp_echo_ignore_broadcasts=1

# Uncomment the following to stop low-level messages on console
#kernel.printk = 4 4 1 7

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next line to enable Spoof protection (reverse-path filter)
#net.ipv4.conf.default.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.conf.default.forwarding=1

# Uncomment the next line to enable packet forwarding for IPv6
#net.ipv6.conf.default.forwarding=1


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bertrand Yvain-2]

On Wed, Aug 26, 2009 at 05:12:36PM +0200, randall wrote:
> Bertrand Yvain wrote:
> > Looks like a PMTU issue.
> > Would you happen to have net.ipv4.ip_no_pmtu_disc = 1 in your sysctls?
> >
> but below answers the question, nope.

The resource might be set by something else. You can check the actual
value like this:

# /sbin/sysctl net.ipv4.ip_no_pmtu_disc

If it's still 0, my guess stays on MTU.

> just noticed that i do can cat small files, it hangs on more substantial
> sized files though.

I guess that "small" is around your MTU on eth0.  Should be 1500 for
regular ethernet, but there might be an encapsulation layer somewhere...

You should try lowering it to something safe:

# ifconfig eth0 mtu 1280

This will most probably fix your problem.  Then you'll have to
investigate why the default MTU is not good for your network and what
should be the max allowed value.

--
Bertrand Yvain
http://www.lost-oasis.fr/


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

randall wrote:

> Bertrand Yvain wrote:
>> On Wed, Aug 26, 2009 at 05:12:36PM +0200, randall wrote:
>>> Bertrand Yvain wrote:
>>>> Looks like a PMTU issue.
>>>> Would you happen to have net.ipv4.ip_no_pmtu_disc = 1 in your sysctls?
>>>>
>>> but below answers the question, nope.
>> The resource might be set by something else. You can check the actual
>> value like this:
>>
>> # /sbin/sysctl net.ipv4.ip_no_pmtu_disc
>>
>> If it's still 0, my guess stays on MTU.
>

host:~# sysctl net.ipv4.ip_no_pmtu_disc
net.ipv4.ip_no_pmtu_disc = 0
>
setting ifconfig eth0 mtu 1280
does seem to help and solves the immediate problem, i have a working
connection again. Thanks ;)

not sure what i did to ***** this up, actually no idea what the MTU
actually does apart from what i read on google the last ten minutes.

>
>
>
>
>
>>> just noticed that i do can cat small files, it hangs on more substantial
>>> sized files though.
>> I guess that "small" is around your MTU on eth0.  Should be 1500 for
>> regular ethernet, but there might be an encapsulation layer somewhere...
>>
>> You should try lowering it to something safe:
>>
>> # ifconfig eth0 mtu 1280
>>
>> This will most probably fix your problem.  Then you'll have to
>> investigate why the default MTU is not good for your network and what
>> should be the max allowed value.
>>
>
>

--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adi Tirla]

i suggest you try to find where is the mtu problem coming from because you might have issues connecting to different servers which drop ICMP

don't forget to make your change permanent to avoid reboot problems if you don't fix the issue :)

Adrian

On Wed, Aug 26, 2009 at 6:57 PM, randall <randall@...> wrote:

randall wrote:
> Bertrand Yvain wrote:
>> On Wed, Aug 26, 2009 at 05:12:36PM +0200, randall wrote:
>>> Bertrand Yvain wrote:
>>>> Looks like a PMTU issue.
>>>> Would you happen to have net.ipv4.ip_no_pmtu_disc = 1 in your sysctls?
>>>>
>>> but below answers the question, nope.
>> The resource might be set by something else. You can check the actual
>> value like this:
>>
>> # /sbin/sysctl net.ipv4.ip_no_pmtu_disc
>>
>> If it's still 0, my guess stays on MTU.
>

host:~# sysctl net.ipv4.ip_no_pmtu_disc
net.ipv4.ip_no_pmtu_disc = 0
>
setting ifconfig eth0 mtu 1280
does seem to help and solves the immediate problem, i have a working
connection again. Thanks ;)

not sure what i did to ***** this up, actually no idea what the MTU
actually does apart from what i read on google the last ten minutes.

>
>
>
>
>
>>> just noticed that i do can cat small files, it hangs on more substantial
>>> sized files though.
>> I guess that "small" is around your MTU on eth0.  Should be 1500 for
>> regular ethernet, but there might be an encapsulation layer somewhere...
>>
>> You should try lowering it to something safe:
>>
>> # ifconfig eth0 mtu 1280
>>
>> This will most probably fix your problem.  Then you'll have to
>> investigate why the default MTU is not good for your network and what
>> should be the max allowed value.
>>
>
>


--

To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

--
ing. Adrian TIRLA

[Bertrand Yvain-2]

On Wed, Aug 26, 2009 at 05:57:38PM +0200, randall wrote:
> not sure what i did to ***** this up, actually no idea what the MTU
> actually does apart from what i read on google the last ten minutes.

Did you check if it was set to 1500 beforehand?

The Maximum Transmission Unit defines the maximum size of the payload in
every single frame sent on the interface.

For ethernet, it's normalized to 1500 bytes.  Virtual no ethernet device
does not support this value.  However, some devices silently discard
larger frames.  On the other side, gigabit ethernet supports larger
sizes and people tend to increase it around 9000.

Things that affect the MTU are (mainly?) linked to encaspulation. Most
commonly: ATM encap (like in DSL devices, or SONET/SDH links), 802.1q
tagged vlan on a dumb switch...

You'll have to calculate, depending on the network setup, the largest
MTU you can use.  


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

Bertrand Yvain wrote:
> On Wed, Aug 26, 2009 at 05:57:38PM +0200, randall wrote:
>> not sure what i did to ***** this up, actually no idea what the MTU
>> actually does apart from what i read on google the last ten minutes.
>
> Did you check if it was set to 1500 beforehand?

yes, Tirla Adrian pointed this out to me.

host:~# ip link show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:07:e9:0f:74:61 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:07:e9:0f:74:24 brd ff:ff:ff:ff:ff:ff
4: dummy0: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue
    link/ether a6:36:8d:f9:09:5b brd ff:ff:ff:ff:ff:ff
5: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

>
> The Maximum Transmission Unit defines the maximum size of the payload in
> every single frame sent on the interface.
>
> For ethernet, it's normalized to 1500 bytes.  Virtual no ethernet device
> does not support this value.  However, some devices silently discard
> larger frames.  On the other side, gigabit ethernet supports larger
> sizes and people tend to increase it around 9000.
>
> Things that affect the MTU are (mainly?) linked to encaspulation. Most
> commonly: ATM encap (like in DSL devices, or SONET/SDH links), 802.1q
> tagged vlan on a dumb switch...

think i have some serious reading to do before i can follow you on this
one ;)
i do have an internal "network" on that box with Vservers with a local
address, i did some rumbling in the configs there but is it correct that
you are saying it could be caused by my external ISP?

>
> You'll have to calculate, depending on the network setup, the largest
> MTU you can use.  





--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bertrand Yvain-2]

On Wed, Aug 26, 2009 at 07:20:04PM +0200, randall wrote:
> i do have an internal "network" on that box with Vservers with a local
> address, i did some rumbling in the configs there but is it correct that
> you are saying it could be caused by my external ISP?

It could, but it's rather unlikely.  ISP are quite reluctant to mess
with those things as it makes more support to do.

If I read between the lines, you have a DSL connection here.  It's more
probably an issue with the modem/router.  You should enquire about the
technology used (PPPoE, PPPoA, whatever) and seek info on the correct
setting.

For instance, for PPPoE: http://www.mynetwatchman.com/kb/ADSL/pppoemtu.htm


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

Bertrand Yvain wrote:

> On Wed, Aug 26, 2009 at 07:20:04PM +0200, randall wrote:
>> i do have an internal "network" on that box with Vservers with a local
>> address, i did some rumbling in the configs there but is it correct that
>> you are saying it could be caused by my external ISP?
>
> It could, but it's rather unlikely.  ISP are quite reluctant to mess
> with those things as it makes more support to do.
>
> If I read between the lines, you have a DSL connection here.  It's more
> probably an issue with the modem/router.  You should enquire about the
> technology used (PPPoE, PPPoA, whatever) and seek info on the correct
> setting.
>
> For instance, for PPPoE: http://www.mynetwatchman.com/kb/ADSL/pppoemtu.htm
>
>

DSL? what makes you think that?

to be honest i'm not a 100% sure about the environment it is placed in.
its a glas fiber connection as i was told a year ago when i installed
the machine remotely, its placed in an office building where most (all)
  internal clients are on DHCP but they made an exception for us since
we needed a fixed external IP.

till so far i understood and the upload speed pushing to 1000kb on a
very lucky day reaffirms my believe that it can't be DSL

but at least i can do some testing now to find the culprit so thanks a
million for that.


Randall


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matt Ryan-2]

randall wrote:
> till so far i understood and the upload speed pushing to 1000kb on a
> very lucky day reaffirms my believe that it can't be DSL


If its not MTU then it could be a firewall that dislikes TCP window
scaling. See http://www.richweb.com/tcp_window_scale_mf_issue for options.


Matt.


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[randall-22]

Matt Ryan wrote:

> randall wrote:
>> till so far i understood and the upload speed pushing to 1000kb on a
>> very lucky day reaffirms my believe that it can't be DSL
>
>
> If its not MTU then it could be a firewall that dislikes TCP window
> scaling. See http://www.richweb.com/tcp_window_scale_mf_issue for options.
>
>
> Matt.
>
>

mmmm,

screwing up the firewall?

yep, that sounds more like me ;)

thanks,

Randall


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bogdan-16]

hi,

I've read all the responses to this email, but it is still unclear to me if described behavior could be the result of a damaged ethernet cable. The logic would be that smaller packets have higher chances of getting through, both on initial send event and when re-sending non-ACKed packets. I could be totally wrong here, so that is why I'm asking.

I had recently deteriorating link quality to my server, which manifested itself as rising (on the scale of dozens of hours) percentage of lost packets when running mtr or ping from my server to some external server. This had finally led to complete loss of connectivity. I did get higher link reliability by decreasing link speed to 10MBps, I haven't tried MTU though. Link was fixed by tech support doing something either to the patch-panel or a patch-cord between the server and patch-panel.

> hi all,
>
> having a problem since a few months and i cant really figure it out.
>
> i have a debian machine standing in China and i connect from Europe, so
> going over there just for this is slightly cumbersome.
>
> i did have some driver issues in the past but after replacing the
> network cards it worked fine.
>
> At the moment:
> i can login using SSH and issue commands.
> but when opening a file or starting top the screen goes black until the
> connection times out, reset by peer.
>
> i can copy files to the machine using SCP but i can not copy them back,
> it stalls until the time out.
>
> a website is hosted on the machine and you can connect to it but it
> keeps on waiting for the server till the morning comes.
>
> the machines acts as a router for a local LAN, eth1 faces the LAN and
> eth0 faces the net, no problems for the people on the LAN
>
> not sure what it is but my first suspect would be the firewall/routing,
> i use shorewall.
>
> so, before i try disabling the firewall etc... to see if it has any
> results and risk losing the working LAN part of the story i wonder if
> somebody here has a clue on what it could be.
>
> Thanks anyways,
>
> Randall

-- реклама -----------------------------------------------------------
Лучший хостинг от $3.45
Домен в подарок - www.hostpro.ua


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Eden Caldas]

Just a thought

I had a similar issue in the past.

I connect to several servers over ssh from my ubuntu 8.10 machine.
Servers were debian 4, opensuse and ubuntu 8.04. The ssh connection
would freeze if I issued a long ls command "ls -l /etc" for example.
cat a big text file. Editing with vi was an almost sure freeze. Guess
what. I tried windows and putty to connect and no freezes. So I think
"ssh client problem?" I try messing with lots of ssh_config options
and no success, I try to run putty over wine and FREEZE! I found no
solution but to reboot to windows and use putty. Eventually it stopped
freezing without a reason. I now use ubuntu 9.04 as desktop but it
stopped freezing while still using ubuntu 8.10. I really don't know
what was happening that time.

2009/8/29 Bogdan <do.IT@...>:

> hi,
>
> I've read all the responses to this email, but it is still unclear to me if described behavior could be the result of a damaged ethernet cable. The logic would be that smaller packets have higher chances of getting through, both on initial send event and when re-sending non-ACKed packets. I could be totally wrong here, so that is why I'm asking.
>
> I had recently deteriorating link quality to my server, which manifested itself as rising (on the scale of dozens of hours) percentage of lost packets when running mtr or ping from my server to some external server. This had finally led to complete loss of connectivity. I did get higher link reliability by decreasing link speed to 10MBps, I haven't tried MTU though. Link was fixed by tech support doing something either to the patch-panel or a patch-cord between the server and patch-panel.
>
>
>> hi all,
>>
>> having a problem since a few months and i cant really figure it out.
>>
>> i have a debian machine standing in China and i connect from Europe, so
>> going over there just for this is slightly cumbersome.
>>
>> i did have some driver issues in the past but after replacing the
>> network cards it worked fine.
>>
>> At the moment:
>> i can login using SSH and issue commands.
>> but when opening a file or starting top the screen goes black until the
>> connection times out, reset by peer.
>>
>> i can copy files to the machine using SCP but i can not copy them back,
>> it stalls until the time out.
>>
>> a website is hosted on the machine and you can connect to it but it
>> keeps on waiting for the server till the morning comes.
>>
>> the machines acts as a router for a local LAN, eth1 faces the LAN and
>> eth0 faces the net, no problems for the people on the LAN
>>
>> not sure what it is but my first suspect would be the firewall/routing,
>> i use shorewall.
>>
>> so, before i try disabling the firewall etc... to see if it has any
>> results and risk losing the working LAN part of the story i wonder if
>> somebody here has a clue on what it could be.
>>
>> Thanks anyways,
>>
>> Randall
>
> -- реклама -----------------------------------------------------------
> Лучший хостинг от $3.45
> Домен в подарок - www.hostpro.ua
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...