[Info-vax] TCP/IP Services SSH and new router difficulties

[John Wallace]

On Oct 1, 5:32 pm, MG <marcog... at SPAMxs4all.nl> wrote:
> On 24-9-2011 18:19, MG wrote:
>
> > Problem solved: I returned the last Cisco-Linksys (also a terrible
> > thing, like the NETGEAR, for WAN and NAT) and got another Sitecom
> > again instead (like I had before), which works like a charm!
>
> I spoke too fast.  I'm still having some difficulties.  No timeouts
> this time, but rather a cutoff of some sort.
>
> For example, when I log onto a node remotely and then issue a DCL
> command that returns more than a few lines, like "$ DIRECTORY", it
> 'hangs' and doesn't show anything for almost a whole minute or two!
> Then it finally shows.
>
> I have no idea what this could be.  I've also tried to remote via
> a proxy to my system, then it won't even connect (it times out).
>
> Is someone familiar with this problem?  (Or these problems, I have
> no idea if it's just one or a culmination of several.)
>
>   - MG

This might be the time to make sure you understand the basics of IP
(TCP vs UDP, role of routers, significance of MTU, etc). Then learn a
bit about how to use TCPDUMP or wireshark, and then come back with a
bit more info.

Based more on intuition+experience than anything else, I'd guess you
may have a packet loss problem somewhere, and the intrinsic behaviour
of TCP (guaranteed delivery via timeout+retry) means that eventually
the lost packet and what followed it is retransmitted.

In the absence of supporting evidence other than what's posted here,
I'd start by looking to see whether you have a Path MTU Discovery
problem somewhere along the way between the two end systems of
interest, a problem which is allowing smaller packets through but
fragmenting big ones, but one end isn't aware of the size limit along
the way. The consequence is that if one end occasionally sends
unusually large packets which somebody along the way drops (because
they're too big).

Circumstances like this can occur when a network administrator
foolishly blocks all flavours of "ping" (aka ICMP) packet; when that
happens it is impossible for Path MTU Discovery to work right, which
will lead to problems when perfectly valid (but big) TCP packets need
fragmenting (and re-assembling when received); a router's reply
message to the sender after dropping such a packet is an important
part of Path MTU discovery. The router is an ICMP packet which silly
network admins (including those in commercial ISPs) may sometimes
block.

You can use ping to help diagnose whether this hypothesis is relevant
or not.

A 1300 byte packet gets from me to google OK:

ping -f -l 1300 www.google.co.uk

Pinging www.google.co.uk [209.85.229.147] with 1300 bytes of data:

Reply from 209.85.229.147: bytes=64 (sent 1300) time=51ms TTL=53

<snip>

Ping statistics for 209.85.229.147:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 50ms, Maximum = 51ms, Average = 50ms


ping -f -l 1400 www.google.co.uk

Pinging www.google.co.uk [209.85.229.147] with 1400 bytes of data:

Packet needs to be fragmented but DF set.

<snip>

Ping statistics for 209.85.229.147:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Don't forget all the usual "systematic troubleshooting" stuff, e.g.
Has this ever worked? Did it work recently? Did anybody change
anything at the same time as it stopped working? And the most
important one of the lot: does anybody know you changed whatever broke
it, and if no one knows, can you change it back without anyone being
able to notice?

Grossly oversimplified, and from distant non-error-correcting memory,
apologies for any errors or significant omissions. I had great fun
doing this kind of thing when mass market broadband first arrived in
the UK ten years ago, and various consumer ISPs (and more importantly
their wholesaler connectivity provider) didn't really have much of a
clue.

Good luck, and welcome to the world of IP network debugging. I need to
be elsewhere for a bit, hopefully that may get you started.