Bug 113637 - ioctl SIOCGIFCONF returns incorrect value/count
ioctl SIOCGIFCONF returns incorrect value/count
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-15 19:36 EST by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-16 08:06:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program to demonstrate problem (2.99 KB, text/plain)
2004-01-15 19:37 EST, Gene Czarcinski
no flags Details

  None (edit)
Description Gene Czarcinski 2004-01-15 19:36:24 EST
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-15 19:37:27 EST
Created attachment 97047 [details]
test program to demonstrate problem
Comment 2 Gene Czarcinski 2004-01-16 07:42:39 EST
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 08:06:21 EST
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.

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