Re: krb5 port: -current behaves differently than 4.X w.r.t rsh (possibly EPERM from bind)

On Tue, Dec 14, 2004 at 10:51:44AM -0600, Tillman Hodgson wrote:
> Howdy folks,
> 
> I'm this on trying on -current_at_ to see if I can work with someone here to
> get this problem trouble-shot and fixed.

I'm still trying to resolve this proble. I have a ktrace.dump available
(using `ktrace -di rsh -x -d athena uptime`), but it doesn't seem to
show anything out of the ordinary. I'm not very proficient with ktrace
and kdump, however. For instance, I didn't see the socket operations ...
I imagien that takes place in a library and simply wasn't captured.

I also have a tcpdump capture. It looks like the connect to port kshell
passes the 3-way handshake. This is where things get weird. The kshd
host sends a new SYN back to the client on the client's source port + 1.
The client sends a reset packet back to the host (it seems it's not
listening there). The host then sends a FIN to the original source port,
closing off the original connection attempt.

I'm not sure what the connect-back is all about ... 

Any ideas out there? I'd really like to get the Kerberos rsh client
working on a 5.X system.

-T


> Date: Tue, 23 Nov 2004 16:00:09 -0600
> From: Tillman Hodgson <tillman_at_seekingfire.com>
> Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh
> To: FreeBSD-Ports <freebsd-ports_at_freebsd.org>
> 
> Howdy folks,
> 
> [I'm not sure that ports_at_ is the right place for this, but thought I'd
>  start here and see what happens.]
> 
> I run a couple of Kerberos realms. I recently installed some new 5.3R
> machines and then immediately upgraded them to -current. Cursory testing
> (I know, I know) seemed to show that the MIT Kerberos port
> (security/krb5) was working correctly. Over time, I've found a
> difference between it and my older 4.X systems.
> 
> While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic
> tools work correctly, the kerberos rsh client (not the server, it's
> fine) doesn't seem to work.
> 
> Here's a a 4-stable box connecting via rsh to anotehr 4-stable box as
> well as to a -current box:
> 
> [root_at_athena ~]# rsh -x coyote uname -a
> This rsh session is encrypting input/output data transmissions.
> FreeBSD coyote.seekingfire.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Thu Nov 18 13:10:32 CST 2004
> toor_at_athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE  i386
> 
> [root_at_athena ~]# rsh -x backforty uname -a
> This rsh session is encrypting input/output data transmissions.
> FreeBSD backforty.seekingfire.prv 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Nov 19 08:03:52 CST 2004
> tillman_at_backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY  i386
> 
> When I try to connect from the -current box ('backforty' from the
> example above) outwards to either type of box I get a failure:
> 
> $ rsh -x coyote uptime
> socket: protocol error or closed connection in circuit setup
> 
> $ rsh -x caliban uptime
> socket: protocol error or closed connection in circuit setup
> 
> (caliban is another -current box).
> 
> The auth.log on the server-side system shows: 
> 
> Nov 23 15:55:10 athena kshd[4565]: connect second port: Connection refused
> 
> Note that all otehr client Kerberos apps work: I can telnet -x, ftp -x,
> rlogin, etc to my hearts connect. Only rsh displays this behaviour.
> 
> I've confirmed that I'm running the right rsh binary:
> 
> $ which rsh
> /usr/local/krb5/bin/rsh
> 
> And I've confirmed that they're both running up-to-date ports trees and
> the most current version fo security/krb5.
> 
> I've googled for the auth.log message. It seems that the connection
> "back" for stderr is being denied. By what, I don't know ...  the host
> backforty isn't runnign any sort of firewall:
> 
> root_at_backforty# ipfw list
> ipfw: getsockopt(IP_FW_GET): Protocol not available
> root_at_backforty# ipfstat -hin
> open: No such file or directory
> root_at_backforty# pfctl -s rules
> pfctl: /dev/pf: No such file or directory
> 
> Any ideas?