Hi there, what is the status of this project?

I see the updates to this repo basically stopped in early 2017. Is the project permanently dead/dormant/just taking a break? I know ipaddress was added to the Python 3 stdlib in 2012 and has much of the same functionality, and wouldn't be surprised if you had decided to focus your time on other things. If so, it would be nice to know if you are not planning to work on this anymore so the community can focus on porting to ipaddress.

Also, one minor thing...I can't use this library in anything > Python 3.6 due to a small bug. I see https://github.com/netaddr/netaddr/pull/167 was merged to fix it, but it hasn't been published to pypi.org. Any chance you're planning to push this out? Python 3.7 was released almost 2 years ago and I'd like to upgrade to keep up with the latest Python releases.

Many thanks! I know from my own experience that maintaining open-source can be a thankless job. I really appreciate your effort and thank you for sharing your code with the world :)

Integrating different systems sometimes requires comparing L2 addresses. That makes a problem when data to compare is a complex data structure and the integration script should be agnostic to its internals.

This patch allows to compare EUI objects for equality and unequality with their valid representations and therefore makes integration of several different systems easier.

Hi,

With the whl netaddr-0.7.13-py2.py3-none-any.whl, the bin file which is getting generated is with this executable : #!/Users/drkjam/pythonenv/netaddr/bin/python

Can you please fix this?

Before this commit, we had this erroneous condition:

>>> netaddr.IPNetwork('1.1/24')
IPNetwork('1.1.0.0/24')

Correctly place 0 octets depending on how many octets we're given. This should fix the above to:

>>> netaddr.IPNetwork('1.1/24')
IPNetwork('1.0.0.1/24')

Obtained proper token placement by empirical testing:

$ ping -c 1 -i 0.2 -W 0.2 1
PING 1 (0.0.0.1) 56(84) bytes of data.

--- 1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping -c 1 -i 0.2 -W 0.2 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=59 time=4.48 ms

--- 1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.476/4.476/4.476/0.000 ms
$ ping -c 1 -i 0.2 -W 0.2 1.1.1
PING 1.1.1 (1.1.0.1) 56(84) bytes of data.

--- 1.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping -c 1 -i 0.2 -W 0.2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=4.44 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.443/4.443/4.443/0.000 ms

Fix the following warning in python3.8

/usr/local/lib/python3.8/site-packages/netaddr-0.7.19-py3.8.egg/netaddr/strategy/__init__.py:189: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if word_sep is not '':

This function allows to format an EUI into any dialect, regardless of the dialect given during construction. This allows clients to generate a representation of the EUI according to the needed format without modifying the object.

Hi David. I apologise in advance if this is the wrong way to ask a question, but I couldn't find a mailing list of netaddr users. I have just observed something curious. One part of my code uses the cidr_merge() function of netaddr. Under cPython on my MacOSX laptop, a given merge takes about 3 seconds. The exact same program with the same inputs, running under pypy, takes 18 seconds for the merge.

Normally, just about any code given to pypy runs faster than under cPython. However, it seems that netaddr, or at least some parts of it, such as the cidr_merge, are running much more slowly. Is this a known issue?

Most of the utilities use zero-filled representations for mac address on *nix systems. The existing mac_unix formatting strategy, however, crops leading zeroes which may cause different kinds of problems when integrating several services or software.

This patch adds a mac_unix_expanded formatting strategy which allows to represent mac addresses as zeros-filled strings.

IPAddress is unable to add/subtract two IPs together:

address1 = netaddr.IPAddress('0.0.0.1')
address2 = netaddr.IPAddress('0.0.0.2')
address3 = address1 + address2

The error that is returned is an out of range error. IndexError('result outside valid IP address boundary!')

After diving into the problem, in the mathematical methods in __init__.py, on the lines that say: if 0 <= new_value <= self._module.max_int:

If the line is edited to be: if 0 <= int(new_value) <= self._module.max_int: The problem does not occur.

I am unaware if this causes any other issues.

Thank you very much.

http://pypi-externals.caremad.io/netaddr/

netaddr packages are not hosted on PyPI, which prevents it from being installed using pip configured with allow-all-external = false.

The advantage of this option is that pip runs much faster, having much less links to crawl for finding installation candidates. This options is part of an ongoing plan to make PyPI faster and more secure and -- I think -- will become the default in the future.

Would you consider switching netaddr to PyPI hosting mode and upload packages to PyPI? All the information is here: http://pypi-externals.caremad.io/help/what/

This is a simple solution for #126 (but still unfinished).

In [1]: from netaddr.ip import IPNetwork

In [2]: x = IPNetwork('127.0.0.0/16')

In [3]: x.netmask = '255.255.255.0'

In [4]: x
Out[4]: IPNetwork('127.0.0.0/24')

In [5]: x.prefixlen
Out[5]: 24

In [6]: x.netmask
Out[6]: IPAddress('255.255.255.0')

Note: x.netmask can also be set with the same values as prefixlen e.g. "24" and 24 are valid inputs.

I'll also add some tests and docs.

Hi,

EUI constructor seems to ignore dialect when input is another EUI object:

$ python3
Python 3.10.6 (main, Nov  2 2022, 18:53:38) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import netaddr
>>> from netaddr.strategy import eui48
>>> netaddr.EUI('FA-16-3E-34-24-4F', dialect=eui48.mac_unix_expanded)
EUI('fa:16:3e:34:24:4f')
>>> netaddr.EUI(netaddr.EUI('FA-16-3E-34-24-4F'), dialect=eui48.mac_unix_expanded)
EUI('FA-16-3E-34-24-4F')
>>> netaddr.__version__
'0.8.0'

The doc seems to allow this input.

Best regards, Bence Romsics

From /usr/share/ieee-data/oui.txt out of ieee-data 20210605.1 on Debian Bullseye:

F4-6D-04   (hex)        ASUSTek COMPUTER INC.
F46D04     (base 16)        ASUSTek COMPUTER INC.
                15,Li-Te Rd.,Peitou,
                Taipei    112    
                TW

Using netaddr 0.7.19 (from the Debian Bullseye python3-netaddr package version 0.7.19-5) I get completely incorrect / corrupt results:

>>> oui = OUI('F4-6D-04')
>>> oui
OUI('F4-6D-04')
>>> oui.re
oui.records        oui.reg_count      oui.registration(  
>>> oui.registration()
{'address': [')\t\tCisco Systems, Inc',
             '80 West Tasman Drive',
             'San Jose  CA  94568',
             'US'],
 'idx': 16018692,
 'offset': 821392,
 'org': 'eero inc.',
 'oui': 'F4-6D-04',
 'size': 141}

The OUI constructor OUI.__init__ claims to support accepting a regular old MAC address as an input:

Also accepts and parses full MAC/EUI-48 address strings (but not MAC/EUI-48 integers)

https://github.com/netaddr/netaddr/blob/e84688f7034b7a88ac00a676359be57eb7a78184/netaddr/eui/init.py#L64-L72

It handles a hyphen-separated OUI okay:

>>> OUI('f4-6d-04')
OUI('F4-6D-04')

But doesn't work as advertised in the doc string with any of the formats (supported by EUI parser):

Bare MAC:

>>> oui = OUI('f46d04112233')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/netaddr/eui/__init__.py", line 101, in __init__
    raise NotRegisteredError('OUI %r not registered!' % oui)
netaddr.core.NotRegisteredError: OUI 'f46d04112233' not registered!

Hyphen-separated MAC:

>>> oui = OUI('f4-6d-04-11-22-33')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/netaddr/eui/__init__.py", line 101, in __init__
    raise NotRegisteredError('OUI %r not registered!' % oui)
netaddr.core.NotRegisteredError: OUI 'f4-6d-04-11-22-33' not registered!

Colon-separated MAC:

>>> OUI('f4:6d:04:11:22:33')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/netaddr/eui/__init__.py", line 83, in __init__
    self._value = int(oui.replace('-', ''), 16)
ValueError: invalid literal for int() with base 16: 'f4:6d:04:11:22:33'

FWIW I'm testing on version 0.7.19 (Debian bullseye) but the code I've linked to is in master.

There are a number of TODOs here:

https://github.com/netaddr/netaddr/blob/e84688f7034b7a88ac00a676359be57eb7a78184/netaddr/eui/init.py#L79-L83

Hi,

I was wondering if you would like to integrate continuous fuzzing by way of OSS-Fuzz? In this PR https://github.com/google/oss-fuzz/pull/7725 I do exactly that, namely created the necessary logic from an OSS-Fuzz perspective.

Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.

If you would like to integrate, the only thing I need is as list of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. Notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.

In the event your unfamiliar with fuzzing, then it's a technique used to automate test case generation. It's been used frequently over the last decade to analyse projects in memory unsafe languages to catch memory corruption issues, but is now moving into supporting memory safe languages (hence this PR). In the Python world, the expected bugs to be found at the moment is uncaught exceptions. I'm happy to answer any questions you may have!

Hi,

the reverse_dns method works properly to derive the full reverse DNS name for a given IPv6 address. However, when generating zone names for IPv6 reverse zones, shorter prefixes must be used. For example, reverse_dns(2001:db8:1:2:3:4:5::/64) and reverse_dns(2001:db8:1:2::/64) should both result in 2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa and not 0.0.0.0.5.0.0.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa respective 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

The generation of the prefix should be cut once the prefix length is reached. Having a default of /128 is fine as this is by far the most common case.

If you're worried about preserving reverse_dns's backwards compatibility, please consider a new method reverse_dns_prefix or reverse_dns_delegation (although downstream software such as ansible would need to follow that).

Greetings Marc