need full IP address from 'who -R' or 'last -R'

[Borealis]

First, I should say I am a very new poster to this forum. Greetings to one and all! Please patiently bear with my detail below.

While I have been working with a variety of *nix platforms over the last 2 decades, I have had minimal experience with HP/UX. Most of my experience has been with Solaris, FreeBSD and Linux (w/some long-ago experience on Xenix, AIX and SCO OpenServer 5.0.x).

All of that aside, there are a small handful of HP/UX 11.11 and 10.x servers that now fall within my responsibilities. On one of the HP/UX 11.11 9000 servers I need to script-customize access for a client who will be accessing the server through a VPN. The customer needs to access an GUI application on our server and run it on their desktop. This would be *very* straightforward to accomplish if this HP/UX server had an ssh server running on it, but the box was built by a 3rd party vendor who did not include this in their build package. (I know it would be easy to install this package, but that would void the vendor's warranty...). The bottom line is that I am stuck using telnet as the access method. I already know how to export the display back to a remote host using 'xhost + $HOST' on the client side and 'setenv DISPLAY hostname:0.0'. I've done this many times before.

The problem is that the customer will be accessing this box from 3 different /24 netblocks. My server is not on a network segment with available DNS servers and using /etc/hosts to handle up to 759 host aliases doesn't seem practical. What I intended to do was to use output from 'who -R' or 'last -R' to extract the host IP address and use it to set $DISPLAY. But here is where it all falls apart. The output of either command cuts off the much needed last octet of the IP address as seen here:

bjak pts/ti Mar 4 13:46 (::ffff:10.0.76.)

I would gladly give up the useless leading "::ffff:" if I could just get the all important last octet of the IP address! Is there any way to increase the column width for the output of this data within wtmp?

Thanks in advance for any help with this problem.

[Patrick Wallek]

How much has this server been customized bye the "vendor"?

I ask because the 'who -R' / 'last -R' output you are seeing is very non-standard for HP-UX.

Here is an example from one of my 11.11 servers:

$ last -R | head -1
user1 pts/1 hquxs13.xxxx.com Thu Mar 4 20:20 still logged in

$ who -R
user1 pts/0 Mar 3 08:14 (hquxs13.xxxx.com)


You will notice the hostnames here, but that is just because the system I logged in from is in DNS.

What happens if you use /usr/bin/last and /usr/bin/who? Are your results any different?

What does 'whence last' and 'whence who' show on the 11.11 server?

Here is what my last and who commands look like:

$ ll /usr/bin/last /usr/bin/who
-r-xr-xr-x 2 bin bin 16384 Sep 27 2007 /usr/bin/last
-r-xr-xr-x 1 bin bin 24576 Nov 14 2000 /usr/bin/who


If yours are significantly different, then someone changed something.

[Borealis]

Patrick,
Worthwhile questions to begin with - its always good to eliminate something from the equation. As for what I am seeing from my side, the problem still appears to be column width for the hostname/IP information. Your example contained a hostname. Counting the characters in your example, it came to 16 characters. Apologies, I forgot to state that I deliberately munged the host IP, but in doing so, forgot to keep the character count the same. The original 3rd octet of my IP should have contained 3 numbers, not 2. A more accurate facsimile would have looked like this example.

bjak pts/ti Mar 4 13:46 (::ffff:10.0.209.)

As a test, I connected from a host existing within /etc/hosts that had a longer hostname. The hostname information cut off at 16 characters, looking something like this.

bjak pts/td Mar 4 18:50 (server1.int.col.)

If a host has no DNS hostname or no /etc/hosts entry, wtmp records the host's IP, but for some unknown reason, it also inserts the additional ":"s and the hexadecimal "ffff".

Again, if there were some way to increase the column width for that information or remove the "::ffff:" cruft then I could get around the problem.

As for the 'll' output for 'last' and 'who', they looked alright, with the exception that owner/group for who is root:root.

hpux-srvr: ll /usr/bin/last /usr/bin/who
-r-xr-x--- 2 root root 16384 Nov 10 2000 /usr/bin/last
-r-xr-xr-x 1 bin bin 24576 Nov 14 2000 /usr/bin/who

[Patrick Wallek]

It should not matter how long the IP address or name is. It should show the whole thing.

Here's output from the same server, but showing IP addresses.

$ who -R
wallekp pts/ta Mar 4 21:37 (170.7.54.141)

$ last -R | head -1
wallekp pts/ta 170.7.54.141 Thu Mar 4 21:37 still logged in


Something is still fishy here. The :ffff: doesn't make sense.

[Patrick Wallek]

Is IPV6 running anywhere in your network? Could it be possible that the "::ffff:10.0.76." is the non-IPv6 compliant who/last way of seeing a mixed IPv4/IPv6 address?

My knowledge of IPv6 is very very limited, but in doing some quick searches with google, this may kind of make sense.

[Borealis]

True. Even if my system wasn't inexplicably holding the hostname column to 16 characters it doesn't explain the presence of the "::ffff:" that leads the IP address. Trimming that alone would fix it.

I hopped onto a number of my other servers to do a stare and compare. None of the Solaris, FreeBSD or Linux boxes I maintain did anything like this. Long hostnames were not truncated and IP addresses were shown in full *without* the leading "::ffff:". Sadly, I could not immediately test any of the HPUX 10.x servers because they have no outside network connectivity and reside in another physical location.

So the question remains, is it possible to tweak this server to properly display the host column of the 'last -R' and 'who -R' output? How is this done on an HP/UX B.11.11 platform?

[Borealis]

In regards to the IPv6 question, I did run a 'lanscan -i' but there were no IPv6 addresses in evidence. But I do wonder if wtmp stores the netmask information? The netmask does show up in 'lanscan -i' format as a hexadecimal number.

[Borealis]

Aarrgghh! I meant to say I ran 'lanscan -i' and then an 'ifconfig lan0' when I learned the interface name. That is where I pulled the IPv4 information, including the hexadecimal netmask. Sorry for the confusion.

[Patrick Wallek · Accepted solution]

>>...is it possible to tweak this server to
>>properly display the host column of the
>>'last -R' and 'who -R' output? How is this
>>done on an HP/UX B.11.11 platform?

To my knowledge, it's not possible to change the display width.

>>But I do wonder if wtmp stores the netmask
>>information?

No, it doesn't. You can see what the wtmp file actually has by using the 'fwtmp' command.

# fwtmp < /var/adm/wtmp > wtmp.ascii

Then have a look at the wtmp.ascii file.

My most recent login directly from wtmp:

wallekp 1 pts/1 22214 7 0000 0000 1267764154 Mar 4 22:42:34 2010 17
0.7.54.141 hquxs13.rwp.com

[Borealis]

Thank you. The 'fwtmp' tip was very helpful. For one thing, it caused me to examine the wtmp records more closely. The only entries that are generating the "::ffff:" pre-pend to the IP address are the pts entries.

example:

hpappuser pts/tg ::ffff:10.0.209. Thu Mar 4 11:19 - 11:19 (00:00)


But for some reason, the ftp entries do not pre-pend the "::ffff:", as seen here.

brd ftp 192.168.54.11 Thu Mar 4 23:33 - 23:33 (00:00)

Maybe this is an additional clue, but I'm not sure how to read it yet.

[Matti_Kurkela]

The "pts/??" means the connection had a pseudo-TTY allocated, i.e. it was a real login. FTP connections don't need a pseudo-TTY.

"::ffff:" is an IPv6-compatible way to display an IPv4 address, so whatever program is producing the strange wtmp entries is at least minimally IPv6-capable.

If the cut-off entries appear in fwtmp output too, then the application that produced them has been upgraded to IPv6, but the code that produces the wtmp entry has not been upgraded to support the longer address strings required by IPv6. The length of the string "::ffff:10.0.76." is *exactly* the same as the maximum-length IPv4 address, i.e. "nnn.nnn.nnn.nnn". So whatever the program is, it defines a string field or buffer that is too short for its current use. This is clearly a bug.

In HP-UX 11.11, HP begun to introduce IPv6 functionality into HP-UX. The ITRC.hp.com patch database indicates the patches for 11.11 telnetd and r-commands services include some IPv6-related fixes... but there are no specific details about all the problems fixed. As it sounds like your boxes are strictly "vendor-warranty-locked", I guess they are not exactly up to date with patches either, right?

MK

[Borealis]

Matti,
Your answer sounds like it is right on the mark. I and my fellow admins here at the office were beginning to think in the same direction. Many of the boxes that we tested from also produced the "::ffff: we saw from previous vendor and customer connections. The of these test boxes that were used as remotes, all are IPv6 aware, even if they don't specifically use IPv6.

As you guessed, the cut-off entries also appeared in the fwtmp output. Your thoughts that the HP/UX 11.11 server is not patched to current levels is also correct. The vendor is amazingly slow to patch these servers. Patching essentially amounts to a $$$ paid upgrade. And as an annoying "aside", the vendor's approach to security is laughable. Any efforts on our side to tighten it up on the server level run the risk of voiding the warranty. ...but I'm beginning to vent and I need to get back on task.

Short of stumbling across some magic solution with wtmp, I think I will need to rethink my approach and find another way of accommodating the customer's request.

Thanks again to those that have offered input to this problem!

[Borealis]

The assistance from the forum members was very helpful. The provided knowledge helped me to identify that my approach was not optimal for solving the problem at hand, so I am revising my plans and will solve the problem another way.