Bug 451002 - rhpl will always pad single-digit octets in IP address with a 0
Summary: rhpl will always pad single-digit octets in IP address with a 0
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhpl
Version: 4.8
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact:
URL:
Whiteboard:
Depends On: 157657
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-12 10:10 UTC by Michael Mráka
Modified: 2012-06-20 15:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 15:56:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
suggested patch (416 bytes, patch)
2008-06-12 10:12 UTC, Michael Mráka
no flags Details | Diff

Description Michael Mráka 2008-06-12 10:10:05 UTC
+++ This bug was initially created as a clone of Bug #157657 +++

Related to bug 129840

FC4 test3 but goes back to RHEL3 and probably even earlier:

python -c "from rhpl import ethtool; print ethtool.get_ipaddr('lo')"
127.00.00.01

This means we cannot use the output to popuate things like ifcfg-* because of
the padded octet.

up2date uses rhpl.ethtool to extract network interface information, and that
information is put in RHN, and RHN tries to deploy configuration files by doing
macro expansion with info from the database.

-- Additional comment from mihai.ibanescu on 2005-05-13 11:00 EST --
The problem seems to be in ethtool.c line 196

  sprintf(ipaddr, "%02u.%02u.%02u.%02u",
          (unsigned int)ifr.ifr_addr.sa_data[2] % 256,
          (unsigned int)ifr.ifr_addr.sa_data[3] % 256,
          (unsigned int)ifr.ifr_addr.sa_data[4] % 256,
          (unsigned int)ifr.ifr_addr.sa_data[5] % 256);


Is there a reason why it's doing the padding?

-- Additional comment from clumens on 2005-05-16 11:54 EST --
None that I can see.  Fixed in CVS.

Comment 1 Michael Mráka 2008-06-12 10:12:37 UTC
Created attachment 309050 [details]
suggested patch

Comment 2 Michael Mráka 2008-06-12 10:15:33 UTC
Bug is still present in RHEL4 and breaks Satellite's provisioning.

Comment 5 RHEL Program Management 2008-10-31 16:39:49 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 6 John Sefler 2009-08-13 14:38:06 UTC
setting flag rhel4.9 ?

This bug has a downstream effect on Satellite provisioning (see bug 129840).
A fix should be considered in the next release.

Comment 7 RHEL Program Management 2010-10-22 18:51:56 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 8 Jiri Pallich 2012-06-20 15:56:43 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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