On Wed, 11 Jul 2007 04:56:33 -0700 (PDT)
Lenin <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Am implementing RFC 2767 ( BIS ) in solaris.
Just wondering why? Bump in the stack isn't considered a viable
implementation mechanism these days and Solaris has a fairly complete
IPv6 offering alreadying.
[...]
> A snoop on those occasions showed me something strange. My user/passwd
> credentials are sent as :
>
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746 l
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33746
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746 e
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33746
> [u]2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746 ni
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746 ni
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33746 ni[/u]
>
> If you notice the above three lines, the passwd is not being sent properly.
> It should be something like:
>
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33728 l
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33728
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33728 e
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33728
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33728 n
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33728
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33728 i
> 2001:410:0:1::2 -> 2001:410:0:1:203:baff:fe05:31b2 TELNET R port=33728
> 2001:410:0:1:203:baff:fe05:31b2 -> 2001:410:0:1::2 TELNET C port=33728 n
>
> What could be the issue. It's pretty strange and am finding it difficult to
> debug this issue.
[...]
The thing to look at is why ::2 isn't sending 31b2 an ack. I'd probably
use at least -t to look at these packets if not -V or -v. The fact
that 31b2 sent "ni" together would suggest that the ack before that one
was delayed. Assuming this machine is relatively quiet I'd look at the
kstats starting at the link and working up the protocol stack. If you
find something and its not immediately clear whats going on then I'd
probably use dtrace to narrow in. And if the kstats don't suggest
anything I'd probably still use dtrace...
mph
_______________________________________________
networking-discuss mailing list
[email protected]
