> | Maybe putting -u0 back into telnetd isn't such a bad idea after all.
> 
> It is not, but I decided to fix it differently. I have committed changes to
> login and telnetd to pass -a address. Please let me know if this works ok
> for you. I did it this way, because since it already passes -h, awhy not
> pass -a too and be done with it.

We'll try out the patches.  But I wonder if you're not being a bit hasty
in adding more options to login - there may be some unwanted implications
to the additional complexity.

For example, rlogind needs to know about the new login option.  See bug
18210.

I still think the -u0 option should stay in telnetd (and be added to
rlogind).  This is consistent with other Unix streams (at least for
telnetd) and OpenSSH, though I confess I haven't thought about what
happens when you log IPv6 addresses.

	-- Ed



On Sun, Nov 14, 2004 at 01:10:05PM -0500, Christos Zoulas wrote:
> On Nov 14,  2:38am, eravin@panix.com (Ed Ravin) wrote:
> -- Subject: Re: bin/28115
> 
> | The "last -n" changes work as expected.  But there's another problem:
> | /usr/bin/login does not write anything into ut_ss when it is invoked
> | by telnetd.  With our initial tests, an IP address appears in ut_ss when
> | using ftpd with your recent changes, but not when using telnetd.
> | 
> | I see that usr.bin/login/login.c does this:
> | 
> |         (void)getpeername(STDIN_FILENO, (struct sockaddr *)&ss, &len);
> | [...]
> |                utmpx.ut_ss = ss;
> | 
> | But when /usr/bin/login is invoked from telnetd, stdin is a PTY, not a
> | regular socket, so I don't think getpeername will return anything useful.
> | 
> | Maybe putting -u0 back into telnetd isn't such a bad idea after all.
> 
> It is not, but I decided to fix it differently. I have committed changes to
> login and telnetd to pass -a address. Please let me know if this works ok
> for you. I did it this way, because since it already passes -h, awhy not
> pass -a too and be done with it.
> 
> christos
>