Re: rtentry and rtrequest

On Thu, Apr 19, 2007 at 11:50:00PM +1000, Alan Garfield wrote:
[...]

BUT! Now I have a weird bug.

SSH on the SP whinges about :-

----
localhost $ ssh -v 169.254.101.3
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to 169.254.101.3 [169.254.101.3] port 22.
debug1: Connection established.
debug1: identity file /home/manager/.ssh/identity type -1
debug1: identity file /home/manager/.ssh/id_rsa type -1
debug1: identity file /home/manager/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.5p1 FreeBSD-20061110
debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
d475 078f 7eae aef6
Disconnecting: Bad packet length -730527857.
debug1: Calling cleanup 0x1001fc68(0x0)
localhost $
----

... bad packet length! UGH! :)

Since there is no telnet, vi or any other _testable_ services on the SP
I'm stuffed to figure out what's wrong with the packets on the SP side.
I can tcpdump on the platform side and everything looks peachy.

1. Ping the Linux side with packets close to the MTU in size (ping
-s), use different data patterns (ping -p), see with tcpdump -X if
the data gets damaged.

2. Capture a broken SSH session (tcpdump -s0 -w ssh.cap) and analyze
it off-line with Ethereal/Wireshark (I hope it has a dissector for
SSH). The sessions doesn't reash encryption, so the damage should be
clear.

How can I look at the tcp packet length in the data?

tcpdump -v, but it seems to be SSH packet length, not TCP one.
AFAIK, the SSH protocol utilizes packets of its own over the
TCP stream.

Yeah it's what the Linux driver is called. Can be something else, got a
better name? :)

Perhaps just "jn"? Some utilities still have trouble with long
interface names[1], and they are a drag to type in. :-) So I'd
rather keep the name as short as possible.

Yeah 'jn' sounds ok to me. Although it's really not going to be that
common unless you have these SunFire or NewISys servers. :)

Nevertheless, it can be a reference driver working with real hardware
for other folks to study.

--
Yar
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages