Bug 895357 - net-snmp-python adds zeros to end of IP address (IPADDR type), which is not valid
Summary: net-snmp-python adds zeros to end of IP address (IPADDR type), which is not v...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: net-snmp
Version: 18
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Jan Safranek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-15 05:57 UTC by Chris Smart
Modified: 2013-02-02 10:44 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-01-30 00:48:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Test python file for purposes of tcpdump to verify invalid IP address (332 bytes, text/x-python)
2013-01-15 05:57 UTC, Chris Smart
no flags Details
Test bash script for purposes of tcpdump to verify _valid_ IP address (653 bytes, application/x-shellscript)
2013-01-15 05:58 UTC, Chris Smart
no flags Details
Patch to update net-snmp spec file to apply ipaddr fix. (749 bytes, patch)
2013-01-17 05:14 UTC, Chris Smart
no flags Details | Diff
Patch to fix IPADDR long issue (681 bytes, patch)
2013-01-17 05:15 UTC, Chris Smart
no flags Details | Diff

Description Chris Smart 2013-01-15 05:57:20 UTC
Created attachment 678653 [details]
Test python file for purposes of tcpdump to verify invalid IP address

Description of problem:
I'm trying to simply get a Cisco device to dump its config to a tftp server. This entails a set of 7 snmpset commands, which work fine via the command line using snmpset (attached snmp_test.sh).

The problem I'm having is with the python implementation at the step of setting the IP address of the tftp server, specifically that the IP address is gaining extra zeros on the end making it an invalid IP address.

For example, the IP address 192.168.0.1 becomes:
192.168.0.1.0.0.0.0

I can see this in a tcpdump capture:
SetRequest(43)  .1.3.6.1.4.1.9.9.96.1.1.1.1.5.666=[inetaddr len!=4]192.168.0.1.0.0.0.0

And in wireshark in SNMP payload under variable-bindings:
snmp.value.addr == c0:a8:00:01:00:00:00:00

A tcpdump of the snmpsets running via snmpset on command line shows that the IP address is as expected:
snmp.value.addr == c0:a8:00:01

It would appear that the issues is caused by whatever python is doing to the IPADDR type, effectively rendering IPADDR type unusable.

Version-Release number of selected component (if applicable):
net-snmp-agent-libs-5.7.2-4.fc18.x86_64
net-snmp-5.7.2-4.fc18.x86_64
net-snmp-python-5.7.2-4.fc18.x86_64
net-snmp-utils-5.7.2-4.fc18.x86_64
net-snmp-libs-5.7.2-4.fc18.x86_64
python-libs-2.7.3-13.fc18.x86_64
python-2.7.3-13.fc18.x86_64

How reproducible:
Every time I try it.

Steps to Reproduce:
1. run a python script (attached snmp_test.py) which uses type IPADDR (doesn't need to work, it's the outgoing packets that are broken)
2. capture the traffic and note the IP is wrong (tcpdump -i eth0 -nn port 161)
  
Actual results:
SNMP fails to set IP address as the IP address is invalid.

Expected results:
SNMP should set a valid IP address, and the command should succeed.

Additional info:
Details on how to retrieve data from Cisco devices as per:
https://supportforums.cisco.com/docs/DOC-1860

This also occurs on RHEL 6.3 (with older packages).

Comment 1 Chris Smart 2013-01-15 05:58:08 UTC
Created attachment 678654 [details]
Test bash script for purposes of tcpdump to verify _valid_ IP address

Comment 2 Chris Smart 2013-01-16 05:33:17 UTC
Upstream bug report:
https://sourceforge.net/p/net-snmp/bugs/2436/

Comment 3 Chris Smart 2013-01-17 05:12:44 UTC
This is a 64bit bug, caused by the use of a long (64 bits) for storing 32 bit IP address. Changing this to use in_addr_t instead of long (which will change depending on arch) solves the problem. It's also the type that will be returned by inet_addr().

It would be great to get this fixed, so that IPADDR isn't broken on 64bit machines. Attaching patch for 5.7.2 (also submitted upstream), and a patch for net-snmp.spec

Comment 4 Chris Smart 2013-01-17 05:14:16 UTC
Created attachment 680000 [details]
Patch to update net-snmp spec file to apply ipaddr fix.

Comment 5 Chris Smart 2013-01-17 05:15:37 UTC
Created attachment 680001 [details]
Patch to fix IPADDR long issue

Comment 6 Jan Safranek 2013-01-17 11:46:12 UTC
Thanks for the patch and upstream report!

Comment 7 Fedora Update System 2013-01-17 12:10:57 UTC
net-snmp-5.7.2-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/net-snmp-5.7.2-5.fc18

Comment 8 Fedora Update System 2013-01-20 03:11:20 UTC
Package net-snmp-5.7.2-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing net-snmp-5.7.2-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1050/net-snmp-5.7.2-5.fc18
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2013-01-30 00:48:51 UTC
net-snmp-5.7.2-5.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Chris Smart 2013-02-02 10:44:21 UTC
This could probably also be applied to the f17 package, as the problem exists there too.

-c


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