View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
2083RackTablesdefaultpublic2023-05-23 00:232024-01-26 18:14
ReporterRC Assigned Toinfrastation  
PrioritylowSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Product Version0.22.0 
Target Version0.22.1Fixed in Version0.22.1 
Summary2083: Search for WWPN/WWNN works only if colons are removed
DescriptionSearching for WWPN doesn't work if colons are included.
e.g.
A search for 21:00:00:e0:8b:05:05:04 returns: Nothing found for '21:00:00:e0:8b:05:05:04'
A search for 210000e08b050504 takes us right to the correct port.

Annoying as the colon notation is how Racktables displays the WWPN addresses. It was only upon looking into the database that I saw they are stored without punctuation and tried to search that way, successfully.

Less importantly, some equipment reports WWPNs without colons, but with a leading "0x". e.g.: 0x210000F08B050504
It would be desirable for search to handle that notation as well.

With (shorter) MAC addresses, search handles similar colon notation as well as periods (Cisco) properly.
Steps To ReproduceCreate a port with a WWPN of 21:00:00:e0:8b:05:05:04.
Search for 21:00:00:e0:8b:05:05:04
Search for 210000e08b050504

TagsNo tags attached.

Activities

RC

RC

2023-05-23 01:12

reporter   ~0004489

Attached is fix-search.php which can be placed in the plugins directory. It very simply removes all colons from the search string. This fixes the WWPN/WWNN search issue for us. Unsure if it may cause issues for others, perhaps using colons in Object names, file names, etc.?
fix-search.php (895 bytes)    
<?php

$page['search']['handler'] = 'searchHandler_Local';

function searchHandler_local()
{
	try
	{
		$terms = trim (genericAssertion ('q', 'string'));
	}
	catch (InvalidRequestArgException $irae)
	{
		$terms = '';
	}
	if (preg_match("/:/", $terms))
	{
		$pattern = '/\:/';	// Remove colons so WWPN/WWNN will find a match
		$replace = '';
		$terms = preg_replace($pattern, $replace, $terms);
	}
	if ($terms == '')
	{
		showError ('Search string cannot be empty.');
		redirectUser (buildRedirectURL ('index', 'default'));
	}

	try
	{
		parseSearchTerms ($terms);
		// Discard the return value as searchEntitiesByText() and its retriever
		// functions expect the original string as the parameter.
	}
	catch (InvalidArgException $iae)
	{
		showError ($iae->getMessage());
		redirectUser (buildRedirectURL ('index', 'default'));
	}

	renderSearchResults ($terms, searchEntitiesByText ($terms));
}
fix-search.php (895 bytes)   
infrastation

infrastation

2023-05-23 01:24

administrator   ~0004491

Thank you for this bug report. The RE_L2_WWN_COLON regexp pattern was supposed to match this format, but obviously it does not: the bug reproduces as described. I except to be able to debug this later this week, if you decide to do that sooner, please post a comment with the root cause.
infrastation

infrastation

2023-05-23 09:48

administrator   ~0004493

The reason is, a colon-separated WWN address also matches IPv6 address syntax, which sends searchEntitiesByText() code flow down an unexpected branch. This should not be difficult to fix.
infrastation

infrastation

2023-05-23 23:39

administrator   ~0004495

Please try this patch and confirm whether it resolves the problem completely.
--- a/wwwroot/inc/functions.php
+++ b/wwwroot/inc/functions.php
@@ -5040,7 +5040,7 @@ function searchEntitiesByText ($terms)
    if ($net_id = getIPv4AddressNetworkId ($ip_bin))
      $summary['ipv4addressbydq'][$ip_bin] = array ('net_id' => $net_id, 'ip' => $ip_bin);
  }
- elseif (FALSE !== ($ip_bin = ip6_checkparse ($terms)))
+ elseif (FALSE !== ($ip_bin = ip6_checkparse ($terms)) && $ip_bin[0] != "\x00")
  // Search for IPv6 address
  {
    if ($net_id = getIPv6AddressNetworkId ($ip_bin))
RC

RC

2023-05-24 02:36

reporter   ~0004497

The patch works nicely to get WWPN searches working, and doesn't appear to have any regressions (does not break IPv6 searches, MAC addresses, etc).

Now that I'm testing search, I'm noticing how it very rarely (but sometimes) matches on port "Local name", though it does match on "Visible label". Not an issue, I can't think of a case where I'd need to search for a port by name across systems.

Thanks very much
infrastation

infrastation

2023-05-31 22:54

administrator   ~0004499

Thank you for confirming, the next release will include the bug fix (perhaps that's a good reason to make a release soon).

Port names typically are not a good search material, as they tend to repeat if the hardware and the software are the same ("eth0", "fa0", "e1" etc.). Labels are more likely to be unique because typically the purpose of a cable label is to identify a cable in a building no matter if connected or not. I vaguely remember that the search function in the past required a number of changes to account for peculiarities such as that.

Issue History

Date Modified Username Field Change
2023-05-23 00:23 RC New Issue
2023-05-23 01:12 RC Note Added: 0004489
2023-05-23 01:12 RC File Added: fix-search.php
2023-05-23 01:24 infrastation Status new => acknowledged
2023-05-23 01:24 infrastation Note Added: 0004491
2023-05-23 09:48 infrastation Note Added: 0004493
2023-05-23 23:39 infrastation Note Added: 0004495
2023-05-23 23:40 infrastation Assigned To => infrastation
2023-05-23 23:40 infrastation Status acknowledged => assigned
2023-05-23 23:40 infrastation Target Version => 0.22.1
2023-05-24 02:36 RC Note Added: 0004497
2023-05-31 22:54 infrastation Note Added: 0004499
2024-01-26 18:14 infrastation Fixed in Version => 0.22.1