Bug 573346 - last incorrectly displays IPv6 addresses
Summary: last incorrectly displays IPv6 addresses
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sysvinit
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 585880 690939
TreeView+ depends on / blocked
 
Reported: 2010-03-14 10:26 UTC by Frank Crawford
Modified: 2011-03-25 21:18 UTC (History)
3 users (show)

Fixed In Version: sysvinit-2.87-4.dsf.fc12
Clone Of:
: 585880 (view as bug list)
Environment:
Last Closed: 2010-05-13 19:24:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
change ipv4 vs ipv6 recognition in last command (1.22 KB, patch)
2010-04-12 11:56 UTC, Petr Lautrbach
no flags Details | Diff

Description Frank Crawford 2010-03-14 10:26:05 UTC
Description of problem:
If login occurs from an IPv6 host and last is used to display the IP address it displays an incorrect IPv4 style address

Version-Release number of selected component (if applicable):
sysvinit-tools-2.87-1.dsf.fc12.i686

How reproducible:
100%

Steps to Reproduce:
1.Login in to host through an IPv6 address (e.g. with ssh)
2.Run last -ai to display IP address
3.Compare address with sshd details in /var/log/messages
  
Actual results:
The IP address reported is an IPv4 style address of the first 32bits of the actual address.

Expected results:
The correct IP address in IPv6 format.

Additional info:
/usr/include/bits/utmp.h indicates that the full IP address should be in wtmp, and octal dump also indicates the correct IP address is stored.

Comment 1 Petr Lautrbach 2010-03-31 12:48:09 UTC
Can you please specify more your problem? 


$ ssh fec0:0:a22:1c00:223:81ff:fe09:fde9
Last login: Wed Mar 31 14:39:30 2010 from fec0:0:a22:1c00:221:9bff:fe36:7a22

$ last -ai -2
bach     pts/0        Wed Mar 31 14:42   still logged in    fec0:0:a22:1c00:221:9bff:fe36:7a22
bach     pts/0        Wed Mar 31 14:39 - 14:42  (00:02)     fec0:0:a22:1c00:221:9bff:fe36:7a22

$ rpm -q sysvinit-tools
sysvinit-tools-2.87-1.dsf.fc12.i686

Comment 2 Frank Crawford 2010-03-31 22:00:08 UTC
Petr,

That isn't the result I get.  For similar actions:

[frank@bits ~]$ host pbc
pbc.crawford.emu.id.au has address 203.16.204.8
pbc.crawford.emu.id.au has IPv6 address fdd2:7aad:d478:1::cb10:cc08
pbc.crawford.emu.id.au mail is handled by 10 bits.crawford.emu.id.au.
[frank@bits ~]$ slogin fdd2:7aad:d478:1::cb10:cc08
The authenticity of host 'fdd2:7aad:d478:1::cb10:cc08 (fdd2:7aad:d478:1::cb10:cc08)' can't be established.
RSA key fingerprint is 17:28:4e:2f:80:cd:2c:70:c6:64:4c:41:61:69:67:f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'fdd2:7aad:d478:1::cb10:cc08' (RSA) to the list of known hosts.
Last login: Thu Apr  1 08:52:19 2010 from bits.crawford.emu.id.au
[frank@pbc ~]$ last -ai -2
frank    pts/0        Thu Apr  1 08:53   still logged in    253.210.122.173
frank    pts/0        Thu Apr  1 08:52 - 08:53  (00:00)     203.16.204.1

wtmp begins Sun Jun 28 12:48:44 2009
[frank@pbc ~]$ rpm -q sysvinit-tools
sysvinit-tools-2.87-2.dsf.fc12.x86_64
[frank@pbc ~]$ host bits
bits.crawford.emu.id.au has address 203.16.204.1
bits.crawford.emu.id.au has IPv6 address fdd2:7aad:d478:1::cb10:cc01
bits.crawford.emu.id.au mail is handled by 5 bits.crawford.emu.id.au.
[frank@pbc ~]$ slogin fdd2:7aad:d478:1::cb10:cc01
Last login: Thu Apr  1 08:49:55 2010 from piccadilly.ac3.com.au
[frank@bits ~]$ last -ai -2
frank    pts/1        Thu Apr  1 08:54   still logged in    253.210.122.173
frank    pts/0        Thu Apr  1 08:49   still logged in    203.202.1.251

wtmp begins Mon Nov 23 11:54:56 2009
[frank@bits ~]$ rpm -q sysvinit-tools
sysvinit-tools-2.87-2.dsf.fc12.i686

The address 253.210.122.173 corresponds to the 1st 32 bits of the IPv6 address (i.e. fdd2:7aad)

It may be a regression in the later version of sysvinit-tools?

Comment 3 Petr Lautrbach 2010-04-01 15:54:43 UTC
The problem seems be in this part of sysvinit-2.87dsf/src/last.c:

	/*
	 *	IPv4 or IPv6 ? We use 2 heuristics:
	 *	1. Current IPv6 range uses 2000-3fff or fec0-feff.
	 *	   Outside of that is illegal and must be IPv4.
	 *	2. If last 3 bytes are 0, must be IPv4
	 *	3. If IPv6 in IPv4, handle as IPv4
	 *
	 *	Ugly.
	 */
	if (a[0] == 0 && a[1] == 0 && a[2] == htonl (0xffff))
		mapped = 1;
        topnibble = ntohl((unsigned int)a[0]) >> 28;
        
        azero = ntohl((unsigned int)a[0]) >> 16;
	sitelocal = (azero >= 0xfec0 && azero <= 0xfeff) ? 1 : 0;
	
	if (((topnibble < 2 || topnibble > 3) && (!sitelocal)) || mapped ||
	    (a[1] == 0 && a[2] == 0 && a[3] == 0)) {
		/* IPv4 */


so your ipv6 address falls into ipv4 addresses although this is correct Unique Local Unicast address according to [1].

[1] http://www.iana.org/assignments/ipv6-address-space/

Comment 4 Frank Crawford 2010-04-02 01:30:48 UTC
Yep, that sounds like the problem, because it is a Unique Local Unicast address, properly generated, etc.

I'm not even sure why it wants to test for site local.  If the bottom 3 words (not bytes) are non-zero it should be treate as IPv6, and then only test then is really if it is IPv4 (i.e. ::ffff:abcd format).

I can't think of any way the host part of the IPv6 address could be all zero, even if the second word of the network part was.

I'm not even sure why the test for sitelocal is in there, since even if it is, it should still be reported as an IPv6 address and login.

Comment 5 Petr Lautrbach 2010-04-12 11:56:59 UTC
Created attachment 405943 [details]
change ipv4 vs ipv6 recognition in last command

This patch changes recognition process used in last command:

1. If last 3 4bytes are 0, must be IPv4
2. If IPv6 in IPv4, handle as IPv4
3. Anything else is IPv6 

This should be more resistant to fail positives in changing ipv6 ranges.

Scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=2109905

Sent to upstream https://savannah.nongnu.org/bugs/?29497

Comment 6 Fedora Update System 2010-04-26 10:10:02 UTC
sysvinit-2.87-4.dsf.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/sysvinit-2.87-4.dsf.fc12

Comment 7 Fedora Update System 2010-04-26 10:13:51 UTC
sysvinit-2.87-4.dsf.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/sysvinit-2.87-4.dsf.fc13

Comment 8 Fedora Update System 2010-04-27 02:26:55 UTC
sysvinit-2.87-4.dsf.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update sysvinit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/sysvinit-2.87-4.dsf.fc12

Comment 9 Fedora Update System 2010-05-13 19:24:21 UTC
sysvinit-2.87-4.dsf.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2010-05-13 19:31:31 UTC
sysvinit-2.87-4.dsf.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.