Global search for IPv4 and IPv6 behaves differently and unexpectedly #4592

Closed
opened 2025-12-29 18:38:03 +01:00 by adam · 3 comments
Owner

Originally created by @cs-1 on GitHub (Feb 25, 2021).

Environment

  • Python version: 3.8.5
  • NetBox version: v2.10.4

Steps to Reproduce

IPv4

  1. Search for a partial IPv4 prefix in global search without a trailing "." (e. g. for prefix "192.168.1.0/24" this partial search would be "192.168.1".
  2. The search yields prefix "192.168.1.0/24" as a result.

IPv6

  1. Search for a partial IPv6 prefix without a trailing ":" (e. g. for prefix "2001:DB8:11::/64" the partial search would be "2001:DB8:11").
  2. The search doesn't yield any results.

Expected Behavior

IPv4

The search result for "192.168.1" yields the prefix "192.168.1.0/24".

IPv6

The search result for "2001:DB8:11" yields the prefix "2001:DB8:11::/64".

Observed Behavior

You only find a result for IPv4 prefixes when not adding a trailing separator.

As described above, IPv4 and IPv6 prefix searches behave differently. Like for IPv4 prefixes, searches for IPv6 prefix without trailing separators should yield a result.

Originally created by @cs-1 on GitHub (Feb 25, 2021). ### Environment * Python version: 3.8.5 * NetBox version: v2.10.4 ### Steps to Reproduce #### IPv4 1. Search for a partial IPv4 prefix in global search without a trailing "." (e. g. for prefix "192.168.1.0/24" this partial search would be "192.168.1". 2. The search yields prefix "192.168.1.0/24" as a result. #### IPv6 1. Search for a partial IPv6 prefix without a trailing ":" (e. g. for prefix "2001:DB8:11::/64" the partial search would be "2001:DB8:11"). 2. The search doesn't yield any results. ### Expected Behavior #### IPv4 The search result for "192.168.1" yields the prefix "192.168.1.0/24". #### IPv6 The search result for "2001:DB8:11" yields the prefix "2001:DB8:11::/64". ### Observed Behavior You only find a result for IPv4 prefixes when not adding a trailing separator. As described above, IPv4 and IPv6 prefix searches behave differently. Like for IPv4 prefixes, searches for IPv6 prefix without trailing separators should yield a result.
adam closed this issue 2025-12-29 18:38:03 +01:00
Author
Owner

@DanSheps commented on GitHub (Feb 25, 2021):

I would first start by having an equivalent test case. In the IPv4 search, you include the trailing ".", but in the IPv6 you omit the trailing :.

However that is irrelevant as both 192.168.0. and 2001:DB8:11: return results from IP addresses but not from prefixes, so the behavior is consistent. Please revise this BR/FR when appropriate.

@DanSheps commented on GitHub (Feb 25, 2021): I would first start by having an equivalent test case. In the IPv4 search, you include the trailing ".", but in the IPv6 you omit the trailing :. However that is irrelevant as both 192.168.0. and 2001:DB8:11: return results from IP addresses but not from prefixes, so the behavior is consistent. Please revise this BR/FR when appropriate.
Author
Owner

@cs-1 commented on GitHub (Feb 26, 2021):

Hi Dan,

you're right, the bug description wasn't clear enough. I rephrased it and I hope that it's clearer now.

Christian

@cs-1 commented on GitHub (Feb 26, 2021): Hi Dan, you're right, the bug description wasn't clear enough. I rephrased it and I hope that it's clearer now. Christian
Author
Owner

@jeremystretch commented on GitHub (Mar 17, 2021):

This is due to how the netaddr library casts strings to IPNetwork objects:

>>> import netaddr
>>> netaddr.IPNetwork('192.168.1')
IPNetwork('192.168.1.0/32')
>>> netaddr.IPNetwork('2001:DB8:11')
Traceback (most recent call last):
  File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/strategy/ipv4.py", line 125, in str_to_int
    return _struct.unpack('>I', _inet_pton(AF_INET, addr))[0]
OSError: illegal IP address string passed to inet_pton

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/ip/__init__.py", line 311, in __init__
    self._value = self._module.str_to_int(addr, flags)
  File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/strategy/ipv4.py", line 129, in str_to_int
    raise AddrFormatError('%r is not a valid IPv4 address string!' % (addr,))
netaddr.core.AddrFormatError: '2001:DB8:11' is not a valid IPv4 address string!
...
>>> netaddr.IPNetwork('2001:DB8:11::')
IPNetwork('2001:db8:11::/128')

Because of the subtle differences between how IPv4 and IPv6 addresses are formatted, "192.168.1" can be evaluated as a valid network, but "2001:DB8:11" cannot.

Instead, you can search for "2001:DB8:11::", with the trailing double colon. This will return the expected results.

@jeremystretch commented on GitHub (Mar 17, 2021): This is due to how the `netaddr` library casts strings to IPNetwork objects: ``` >>> import netaddr >>> netaddr.IPNetwork('192.168.1') IPNetwork('192.168.1.0/32') >>> netaddr.IPNetwork('2001:DB8:11') Traceback (most recent call last): File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/strategy/ipv4.py", line 125, in str_to_int return _struct.unpack('>I', _inet_pton(AF_INET, addr))[0] OSError: illegal IP address string passed to inet_pton During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/ip/__init__.py", line 311, in __init__ self._value = self._module.str_to_int(addr, flags) File "/opt/netbox/venv/lib/python3.7/site-packages/netaddr/strategy/ipv4.py", line 129, in str_to_int raise AddrFormatError('%r is not a valid IPv4 address string!' % (addr,)) netaddr.core.AddrFormatError: '2001:DB8:11' is not a valid IPv4 address string! ... >>> netaddr.IPNetwork('2001:DB8:11::') IPNetwork('2001:db8:11::/128') ``` Because of the subtle differences between how IPv4 and IPv6 addresses are formatted, "192.168.1" can be evaluated as a valid network, but "2001:DB8:11" cannot. Instead, you can search for "2001:DB8:11::", with the trailing double colon. This will return the expected results.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4592