I hope this is the correct forum for this question...

I run the "last" command on my Debian 8, for checking system accesses.
Running it without parameters has only showed every login on my machine, with what I think it was an ipv6 for localhost (:0), correct me if I'm wrong.

$ last
myuser console :0 Tue Dec 13 20:13 still logged in
reboot system boot 3.16.0-4-amd64 Tue Dec 13 20:13 - 20:58 (00:45)
myuser console :0 Tue Dec 13 08:01 - 08:38 (00:37)
reboot system boot 3.16.0-4-amd64 Tue Dec 13 08:00 - 08:38 (00:38)
myuser console :0 Mon Dec 12 21:12 - 22:29 (01:17)

Reading the manual I saw that the parameter -d shows the ip address of the login recorded.
But I think something is wrong in this, because I see IP of kind 255.* instead of 0.0.0.0

$ last -d
myuser console 254.127.0.0 Tue Dec 13 20:13 still logged in
reboot system boot 0.0.0.0 Tue Dec 13 20:13 - 20:26 (00:13)
myuser console 252.127.0.0 Tue Dec 13 08:01 - 08:38 (00:37)
reboot system boot 0.0.0.0 Tue Dec 13 08:00 - 08:38 (00:38)
myuser console 253.127.0.0 Mon Dec 12 21:12 - 22:29 (01:17)
reboot system boot 0.0.0.0 Mon Dec 12 21:10 - 22:29 (01:18)

The same command on a Linux Mint shows me what I think is the correct IP.
Is there maybe some configuration somewhere in Debian that makes my local address in "last" to be translated to 255.* ?

Thanks in advance for your help

-d

For non-local logins, Linux stores not only the host name of the remote host but its IP number as well. This option translates the IP number back into a hostname.

I think this is what you mean??

Hi jefro, thanks for your response.
Yes, I want to look the associated IP to the login, but since all of this records are from my localhost, why they are in the form of 255.*?
I looked at ifconfig and route, none of them show this IP, I wonder where they come from...

Here's the output of both:

$ ifconfig
eth0 Link encap:Ethernet HWaddr ac:9e:17:81:99:a7
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::ae9e:17ff:fe81:99a7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
collisions:0 txqueuelen:1000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4873 (4.7 KiB) TX bytes:4873 (4.7 KiB)

$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 1024 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0

Is "253.127.0.0" the actual IP reported by last -d ?

If it were me, I'd assume the worst.

Yes, it is.
I think that ip is a translation of the ipv6 one, but not sure...
If start my machine without any connection (modem unlinked), it logs the same IP, I wonder why...
Anyway, that IP seems to be a reserved type for internal use, according to wikipedia.

That's better than what I was 'thinking' (or not w\out facts).
And yours sounds reasonable. Always a Good Idea. "What's reasonable".
Me, I just look for the obvious.

+1 for you, no soup for me.
Have a Great Day!

Hehe, thanks!
For you too :]

I found that the file /var/run/utmp has the correct IP instead...

$ last -wd -f /var/run/utmp
myuser :0 0.0.0.0 Wed Dec 14 18:51 still logged in
reboot system boot 0.0.0.0 Wed Dec 14 18:51 - 19:02 (00:10)

utmp begins Wed Dec 14 18:51:12 2016

The mistery continues :]

Doesn't last get the infor from two files one of which you looked at already?

According to man last:
"Last searches back through the file /var/log/wtmp"

and

"-d For non-local logins, Linux stores not only the host name of the
remote host but its IP number as well. This option translates
the IP number back into a hostname."

The file /var/run/utmp are not readed by default.

I think there is a problem in the IP translation, or something related to the X11 session manager according to this bug that maybe is related to mine problem: https://groups.google.com/forum/#!to...st/1TtWQhD2cZs

I wonder why it's correct in /var/run/utmp and not in /var/log/wtmp...

I'd trust /var over last command if that helps.