utmp inconsistency between versions -- FreeBSD 7.1-PRELEASE (OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007) vs. Mac OS/X 10.5.5 (OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006)

["Richard.Conto" <richard.conto@xxxxxxxxx>]

I just noticed a utmp annoyance when when connecting between my  
collection of Mac OS/X (Intel and PowerPC) and FreeBSD (i86)  
machines.  This has occurred since FreeBSD updated it's openssh to  
OpenSSH_5.1p1.

Before the upgrade, the (canonical DNS) name  of the ssh client  
machine would show up in the serve machines utmp entry (as evidenced  
by "who".)  This was nice and pleasant.  This would even happen when I  
had IPv6 enabled (with appropriate entries in my local DNS server).

After the upgrade to the FreeBSD boxes, when I would use ssh to  
connect from the Macs to the FreeBSD boxes, the IP address (either  
IPv4 or IPv6) would show up in utmp.  However, if I used ssh from  
FreeBSD box to FreeBSD box, the DNS name would show up.

This was especially irritating when the IPv6 address would be dropped  
into utmp because the darn addresses are so long, the host part was  
truncated.  Only the IPv6 network prefix would be readable - which  
begs the question:  What should be put here?  An unreadable IPv6  
prefix or a truncated hostname, given that the limits on "utmp" are so  
awful?


DNS is still working correctly.  The FreeBSD boxes report the  
connections correctly with "netstat -f inet" and "netstat -f inet6".

I discovered that before the upgrade, FreeBSD had patched something  
called "loginrec.c" to use "realhostname_sa()" instead of the "libssh"  
"get_remote_name_or_ip()".

I also discovered that every call to "get_remote_name_or_ip()" used  
"utmp_len" to decide whether to use the returned (canonical?) DNS name  
or the IP (v4 or V6) address - no matter whether or not the string  
representation of the IPv6 address was shorter or longer.

Anyway, I started playing with the source code, adding debugging code,  
etc. and discovered that if I made MINOR changes to the code (like  
harvesting the return value of "getnameinfo()" into an existing  
variable on the stack), my "problem" would go away and the DNS name  
would show up again.

This strongly suggests use of an uninitialized variable somewhere.   
I've prowled the code, including the FreeBSD code involved but haven't  
been able to easily identify anything obvious.

I did find a minor memory leak:  In "canohost.c",  
"get_remote_hostname()", the first call to "getnameinfo()" might  
return something in "struct addrinfo *ai", but there is no  
"freeaddrinfo(ai)" for this.  I initialized "ai" to NULL, and then  
checked against NULL before trying to "freeaddrinfo()" afterwords.  I  
doubt this has any practical effect, but not freeing it when my  
documentation for "getaddrinfo()" says that something is returned  
there offended my professional sensibilities.


--- Richard Conto