On Sep 18, 7:02 pm, NightStrike wrote:
> On Sep 14, 4:50 pm, Darren Tucker wrote:
>
>
>
> > On 2007-09-13, NightStrike wrote:

>
> > > On Sep 8, 2:25 am, Darren Tucker wrote:
> > >> On 2007-09-07, NightStrike wrote:

>
> > >> > Packets 6 and 7 were handshaking packets. They never go through, and
> > >> > packet 6 is retried 5 times until it times out.

>
> > >> That's interesting. If you do a "netstat -n" and pick out the TCP
> > >> connection in question, can you see the value of the "Send-Q" on
> > >> both ends? If so, does it remain non-zero?

>
> > > I'm afraid you lost me on that one. The connection is in the state of
> > > ESTABLISHED. Where do I find this Send-Q information?

>
> > Ah, I see from you reply below that you're using Windows. Netstat on
> > Windows helpfully does not provide that information in order to prevent
> > you from being confused by information that might help you understand
> > what's going on. I don't know of any other way to get the information.

>
> Yes, cygwin. I could boot with a knoppix cd if it would help.
>
>
>
> > >> Actually, you've reminded me of something else: some NAT devices
> > >> choke on TCP connections where the IP TOS changes. Try either
> > >> rebuilding with "./configure --with-cflags=-DIP_TOS_IS_BROKEN"
> > >> or using a proxycommand such as netcat which doesn't set the ToS flags:

>
> > >> ssh -o 'ProxyCommand nc %h %p' youserver

>
> > >> Might be time to add these to the FAQ...

>
> > > I don't see any difference in either the triple-verbose output of the
> > > ssh client nor the Wireshark readout. I am using the version of
> > > netcat that comes with cygwin. Can you elaborate more on what this
> > > "proxycommand nc" thing is doing?

>
> > A ProxyCommand is run by ssh to make the network connection instead of
> > ssh making a TCP connection itself. The command above tells ssh to use
> > the "nc" ("netcat") command to make the connection (you'll need to install
> > it if it's not already installed).

>
> Ah, I see. So you are trying to write more "raw" data, yes?
>
> Here is what I found with some more digging using Wireshark:
>
> I loaded up Wireshark to monitor the connection, and I made a telnet
> connection. This would allow me to have finer control over what was
> going on. What I found was that the usual sequence occurs:
>
> SYN
> SYN/ACK
> ACK
> SSH Version string (server to client)
> ACK (client to server)
>
> Now since I'm using telnet, I can control what I do next. I tried
> sending a simple carriage return (\r\n). This packet never goes
> anywhere (it just keeps getting retried.) This says to me that
> communication got blocked once the server sent its version string. Is
> it possible that the firewall is monitoring the packet contents for
> this, and is blocking anything transmission once it sees the
> beginnings of SSH handshaking? I think it's clear at this point that
> the issue is before the KEXINIT packet. The issue starts right after
> the server sends a version string.
>
> What I'd like to do (if possible) would be to try sending a munged
> version string. Any ideas on that? The only server right now is
> gentoo (my other server running cygwin just got a reformat last
> night.. I corrupted the registry, and yada yada yada, it got
> formatted . Gentoo is by its nature all from source, so I imagine
> I'd have to edit the source somehow. Or maybe I could create a driver
> program that does something useful?
>
> Do you have any ideas in this regard?


bump