ipaddr.IPv4Network object miscalculates network addresses

[Ernesto Alvarez]

When using the IPv4Network.Supernet() call, the resulting address is calculated incorrectly. Instead of presenting the all-zeros address in the host part, the first bit of the host part is kept as it was, causing an incorrect address to be displayed. This only appears to be a display issue, the network objects behave as they should (at least for the equality operator).

The following python program can be used to see the issue.

from sys import argv
import ipaddr

ip1 = ipaddr.IPv4Network(argv[1])
ip2 = ipaddr.IPv4Network(argv[2])

print "Testing ", str(ip1), str(ip2)
while ip1 != ip2:
 print ip1,ip2
 ip1 = ip1.Supernet()
 ip2 = ip2.Supernet()

print "Ending ", ip2

This program takes two addresses and attempts to find the network in common, using the Supernet call to locate it. However, below is the output of the program.

$ python ipaddr-bug-test.py 10.53.45.24 10.53.45.255
Testing 10.53.45.24/32 10.53.45.255/32
10.53.45.24/32 10.53.45.255/32
10.53.45.24/31 10.53.45.255/31
10.53.45.24/30 10.53.45.254/30
10.53.45.24/29 10.53.45.252/29
10.53.45.24/28 10.53.45.248/28
10.53.45.16/27 10.53.45.240/27
10.53.45.0/26 10.53.45.224/26
10.53.45.0/25 10.53.45.192/25
Ending 10.53.45.128/24

Note how the program correctly shows the /32 addresses, but when getting the supernet for the second address, it mistakenly shows 10.53.45.255/31 when the correct value should have been 10.53.45.254/31. The same happens in all the stages, and is very obvious when doing the computation on a broadcast address. Finally, the address is constructed with the wrong network address.

As for system data, here goes all the data indicated in the submission instructions:

$ lsb_release -rd
Description: Ubuntu 14.04.4 LTS
Release: 14.04

$ apt-cache policy python-ipaddr
python-ipaddr:
  Installed: 2.1.10-1
  Candidate: 2.1.10-1
  Version table:
 *** 2.1.10-1 0
        500 http://ar.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: python-ipaddr 2.1.10-1
ProcVersionSignature: Ubuntu 3.19.0-51.58~14.04.1-generic 3.19.8-ckt13
Uname: Linux 3.19.0-51-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed Mar 30 17:17:20 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-02-29 (29 days ago)
InstallationMedia: Xubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
PackageArchitecture: all
SourcePackage: python-ipaddr
UpgradeStatus: No upgrade log present (probably fresh install)

[Ernesto Alvarez (ernesto-alvarez)]

Looks like the issue can be worked around by calling Supernet() with prefixlen_diff=0 at the end of the computation. I have the impression that blanking the host part and shifting the network mask are done in the wrong order, but I haven't seen the code.

New program:

from sys import argv
import ipaddr

ip1 = ipaddr.IPv4Network(argv[1])
ip2 = ipaddr.IPv4Network(argv[2])

print "Testing ", str(ip1), str(ip2)
while ip1 != ip2:
 print ip1,ip2
 ip1 = ip1.Supernet()
 ip2 = ip2.Supernet()

print "Ending ", ip2
print "Fixed ending ", ip2.Supernet(prefixlen_diff=0)

Results:

$ python ipaddr-bug-test.py 10.53.45.24 10.53.45.255
Testing 10.53.45.24/32 10.53.45.255/32
10.53.45.24/32 10.53.45.255/32
10.53.45.24/31 10.53.45.255/31
10.53.45.24/30 10.53.45.254/30
10.53.45.24/29 10.53.45.252/29
10.53.45.24/28 10.53.45.248/28
10.53.45.16/27 10.53.45.240/27
10.53.45.0/26 10.53.45.224/26
10.53.45.0/25 10.53.45.192/25
Ending 10.53.45.128/24
Fixed ending 10.53.45.0/24

[Jon Grimm (jgrimm)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. I appreciate the quality of this bug report and I'm sure it'll be helpful to others experiencing the same issue.

This sounds like an upstream bug to me. Please can you verify this by building directly from the latest upstream source? If this can be confirmed as an upstream bug, the best route to getting it fixed in Ubuntu in this case would be to file an upstream bug if you're able to do that. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem.

I did verify that this behavior still remains with python-ipaddr | 2.1.11-2 | xenial

The upstream issue tracker appears to be
    https://github.com/google/ipaddr-py/issues

I think your issue is described here already:
   https://github.com/google/ipaddr-py/issues/98
, if not please file a bug and report here so we can monitor its progression. Thanks!

[Scott Kitterman (kitterman)]

Note: ipaddr is no longer developed separately upstream. It was the basis for the ipaddress module included in python3.3 and later. It would be useful to see if this issue is present there as well and if it is, forwarding it python upstream.