Bug 113637

Summary: ioctl SIOCGIFCONF returns incorrect value/count
Product: [Fedora] Fedora Reporter: Gene Czarcinski <gczarcinski>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: 64bit_fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-16 13:06:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test program to demonstrate problem none

Description Gene Czarcinski 2004-01-16 00:36:24 UTC 
Description of problem:

I am trying to get nessus to build and run correctly on an AMD64
system ... you Red Hat folks may want to try this, it sure seems to
find bugs.

Anyway, one of the routines gets the names, etc. of the network
interfaces.  A key is using ioctl with the SIOCGIFCONF parameter.

When this is compiled and run on an ia32 system (Athlon in my case) it
prints out the correct number and names of the network interfaces. 
When it is compiled and run on an AMD64 (Opteron)_ system, it only has
the first(?) interface: lo.

The correct component may or may not be named.

Version-Release number of selected component (if applicable):
FC-1 preview with kernel-2.4.22-1.2135.nptl

How reproducible:
every time

Steps to Reproduce:
compile and run the attached test program on a IA32 and AMD64 system.  

the compile command was gcc -O2 -o testxx test.c
Comment 1 Gene Czarcinski 2004-01-16 00:37:27 UTC 
Created attachment 97047 [details]
test program to demonstrate problem
Comment 2 Gene Czarcinski 2004-01-16 12:42:39 UTC 
Oops ... just realized that since the 32 bit test application ran OK
on the 64 bit kernel, the problem could not be the kernel ... but
instead glibc.  I have changed the component and assignment.
Comment 3 Jakub Jelinek 2004-01-16 13:06:21 UTC 
No, this has nothing to do with glibc, but neither with kernel.
The test program is broken.
Look at how is struct ifreq defined.  Among other things it contains
ifr_map field, and on 64-bit machines struct ifmap is bigger than
struct sockaddr (the former 24 bytes (16 bytes on 32-bits), the
latter 16 bytes (the same as on 32-bit)).
So struct ifreq is 40 bytes on AMD64, while
sizeof (ifr->ifr_name) + sizeof (struct sockaddr) is 32.