Hi,

Issue happen for AWS instance.
When i tried to trigger ps -ef, ls -rtlh a folder with a lot files, and issue a top command, the putty session when hang on the session did not provide any output, I am also not able to quit with CTRL + C or CTRL + Z.

This issues only occur in putty, when i tried to use others terminal such as mobaXterm, is working fine.

I had enabled the log, but i give output below:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2019.10.02 09:16:27 =~=~=~=~=~=~=~=~=~=~=~= login as: xxx
Authenticating with public key "xxx"
Last login: Wed Oct 2 09:11:29 2019 from xxx.xxx.xxx.xxx

0;xxx:~[xxx ~]$ cd ps -ef

Kindly assist.
Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, October 2, 2019 at 11:17:00 AM UTC+8, Grant Taylor wrote:

On 10/1/19 7:46 PM, weicheng1989@gmail.com wrote:

When i tried to trigger ps -ef, ls -rtlh a folder with a lot files,
and issue a top command, the putty session when hang on the session
did not provide any output, I am also not able to quit with CTRL +
C or CTRL + Z.

I'm guessing that there's something wrong at the TCP layer. MTU and /
or MSS.

Small packets make it just find. Big packets, like those containing
quite a bit of output, cause problems.

I'd suggest a packet sniffer.

--
Grant. . . .
unix || die

Hi,
But my putty able to give me a output when i issue the command in other Linux instance or servers.

Also without any issue when i use other terminal like mobaXterm to execute the command on the affected instance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/1/19 7:46 PM, weicheng1989@gmail.com wrote:

When i tried to trigger ps -ef, ls -rtlh a folder with a lot files,
and issue a top command, the putty session when hang on the session
did not provide any output, I am also not able to quit with CTRL +
C or CTRL + Z.

I'm guessing that there's something wrong at the TCP layer. MTU and /
or MSS.

Small packets make it just find. Big packets, like those containing
quite a bit of output, cause problems.

I'd suggest a packet sniffer.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/1/19 9:40 PM, weicheng1989@gmail.com wrote:

Hi,

Hi,

But my putty able to give me a output when i issue the command in
other Linux instance or servers.

It has to do with the amount of output that commands give, and how this
effects the way the data is sent on the wire.

Also without any issue when i use other terminal like mobaXterm to
execute the command on the affected instance.

PuTTY is more than just a terminal emulator. It's controlling the SSH connection, thus the TCP connection underneath. As such, PuTTY can
behave differently than other SSH connections, e.g. mobaXterm.

I'm not familiar with mobaXterm, but a quick search for it tells me that
it's also a terminal emulator and SSH client. As such, mobaXterm can
behave differently than other SSH connections, e.g. PuTTY.

I have sporadically run into similar problems where ssh will connect and provide some (small) output, but not other (larger) output, or things
like SCP / SFTP will fail. Every time it has come down to networking
issues. Usually, something filtering the ICMP messages telling one end
of the connection or the other that it needs to fragment the TCP packet
but can't because the Don't Fragment flag is turned on.

This may not be what's happening in your case. But it sure does sound
like what I've experienced many times in the last 18+ years.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, October 2, 2019 at 10:23:38 PM UTC+8, Grant Taylor wrote:

On 10/1/19 9:40 PM, weicheng1989@gmail.com wrote:

Hi,

Hi,

But my putty able to give me a output when i issue the command in
other Linux instance or servers.

It has to do with the amount of output that commands give, and how this effects the way the data is sent on the wire.

Also without any issue when i use other terminal like mobaXterm to
execute the command on the affected instance.

PuTTY is more than just a terminal emulator. It's controlling the SSH connection, thus the TCP connection underneath. As such, PuTTY can
behave differently than other SSH connections, e.g. mobaXterm.

I'm not familiar with mobaXterm, but a quick search for it tells me that
it's also a terminal emulator and SSH client. As such, mobaXterm can
behave differently than other SSH connections, e.g. PuTTY.

I have sporadically run into similar problems where ssh will connect and provide some (small) output, but not other (larger) output, or things
like SCP / SFTP will fail. Every time it has come down to networking
issues. Usually, something filtering the ICMP messages telling one end
of the connection or the other that it needs to fragment the TCP packet
but can't because the Don't Fragment flag is turned on.

This may not be what's happening in your case. But it sure does sound
like what I've experienced many times in the last 18+ years.

--
Grant. . . .
unix || die

Hi Taylor,

Thanks your advice, i had tired to use packet tracer to trace the packet passing, and i am getting "TCP Previous segment not capture, Encrypted packet (len=1281)" do you have any advice for this?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, October 3, 2019 at 12:30:41 PM UTC+8, Grant Taylor wrote:

On 10/2/19 9:34 PM, weicheng1989@gmail.com wrote:

Thanks your advice, i had tired to use packet tracer to trace the
packet passing, and i am getting "TCP Previous segment not capture, Encrypted packet (len=1281)" do you have any advice for this?

Previous segment not captured /usually/ has to do with when the capture
is started vs when the connection was started. I.e. if you start the
packet capture after the connection is established.

Previous segment not captured in and of itself is not a problem,
especially if it can be explained.

--
Grant. . . .
unix || die

Hi Taylor,

I start the packet capture before i start SSH.
and the "TCP Previous segment not capture, Encrypted packet (len=1281)" appear when i initiate the ps -ef command. Then the putty went hang.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/2/19 9:34 PM, weicheng1989@gmail.com wrote:

Thanks your advice, i had tired to use packet tracer to trace the
packet passing, and i am getting "TCP Previous segment not capture,
Encrypted packet (len=1281)" do you have any advice for this?

Previous segment not captured /usually/ has to do with when the capture
is started vs when the connection was started. I.e. if you start the
packet capture after the connection is established.

Previous segment not captured in and of itself is not a problem,
especially if it can be explained.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/2/19 10:46 PM, weicheng1989@gmail.com wrote:

Hi Taylor,

Hi,

"Grant" please. ;-)

I start the packet capture before i start SSH.

Okay.

and the "TCP Previous segment not capture, Encrypted packet (len=1281)" appear when i initiate the ps -ef command. Then the putty went hang.

Hum. If the "TCP Previous segment not captured" is associated with the
SSH connection, that's a good sign that your sniffer thinks that it's
missing a packet. This could be because a big packet was sent with part
of the data, but never made it in, and then a smaller packet with the
rest of the data comes in. Thus the sniffer sees the second smaller
packet referencing the missing larger packet.

This sounds like supporting evidence that something is preventing big
packets from making it in.

I would expect that if you leave the sniffer running and the hung
connection sitting there long enough, 3–5 minutes should be sufficient,
you will likely see retransmissions of the smaller packet and the
associated "previous segment not captured" message.

I'd be tempted to also start a packet capture on the server from one of
the other functional terminal emulator ssh client combinations.

ProTip: Write the capture to a file, transfer it, and analyze it locally.

You can also use a sniffer to compare the traffic from one of the other functional terminal emulator ssh clients. I'm guessing that the MTU, or
TCP MSS, or other TCP parameters, will likely be different.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, October 2, 2019 at 9:46:22 AM UTC+8, weiche...@gmail.com wrote:

Hi,

Issue happen for AWS instance.
When i tried to trigger ps -ef, ls -rtlh a folder with a lot files, and issue a top command, the putty session when hang on the session did not provide any output, I am also not able to quit with CTRL + C or CTRL + Z.

This issues only occur in putty, when i tried to use others terminal such as mobaXterm, is working fine.

I had enabled the log, but i give output below:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2019.10.02 09:16:27 =~=~=~=~=~=~=~=~=~=~=~= login as: xxx
Authenticating with public key "xxx"
Last login: Wed Oct 2 09:11:29 2019 from xxx.xxx.xxx.xxx

]0;xxx:~ [?1034h[xxx ~]$ cd [K [K [Kps -ef

Kindly assist.
Thank you.

Hi Taylor,

Thanks your input, i will not able to solve the issue without your input.
We found that, is the network MTU setting was incorrect.

To connect to AWS VPN must set the MTU lower than 1500, because it does not support Jumbo frames.

Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/16/19 3:18 AM, weicheng1989@gmail.com wrote:

Hi Taylor,

Hi,

Thanks your input, i will not able to solve the issue without your input.
We found that, is the network MTU setting was incorrect.

To connect to AWS VPN must set the MTU lower than 1500, because it does not support Jumbo frames.

Thank you.

You're welcome.

I'm glad that you figured it out.

I'm guessing that something is filtering ICMP as it /usually/ helps
avoid MTU issues.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)