The addr field of the output from utmpdump contains the ip address of the connection. This is obtained by calling inet_ntoa on the ut.ut_addr field (as depicted in the code below, utmpdump.c, Release 2.88). But in case the ip address is an*IPV6 address, the output contains the wrong ip address (decimal value of first 4 octets only).*
This code should be updated to call inet_ntop and should be checked whether the ut_addr field contains IPV4 or IPV6 address. The check can be made either by checking ut_addr_v6[1:3] for zero (this is based on the assumption that login program zeroes out fields before filling utmp structure, though it is not mentioned in man entry for utmp) or by introducing a flag in the utmp structure that depicts whether the address field contains IPV4 or IPV6 address. *
I would really appreciate your feedback on this.
voidprint_utline(struct utmp ut){** * * *char *addr_string, *time_string;** * * *struct in_addr in;
** * * *in.s_addr = ut.ut_addr;** * * *addr_string = inet_ntoa(in); * //Code statement causes issue in case of IPV6 addresses** * * *time_string = timetostr(ut.ut_time);
On Wed, 09 Feb 2011, Navdeep Bhatia wrote:
> This code should be updated to call inet_ntop and should be checked whether
> the ut_addr field contains IPV4 or IPV6 address. The check can be made
> either by checking ut_addr_v6[1:3] for zero (this is based on the assumption
> that login program zeroes out fields before filling utmp structure, though
> it is not mentioned in man entry for utmp) or by introducing a flag in the
> utmp structure that depicts whether the address field contains IPV4 or IPV6
> address.
>
> I would really appreciate your feedback on this.
Please file a bug against package sysvinit, on the bugs.debian.org
bugtracker. Otherwise, it could get lost. Unfortunately, we are extremely
short on manpower and time on the debian sysvinit/initscripts team.
utmpdump is a debug thing, we don't even ship it on the Debian binary
packages, so we should be able to fix it without worries about any script
parsing its output and croaking on the change.
But I have no clue if the patch you propose is correct or not.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110210204407.GB14100@khazad-dum.debian.net">http://lists.debian.org/20110210204407.GB14100@khazad-dum.debian.net