PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001054PacketFenceweb adminpublic2010-08-27 13:582015-02-18 10:59
Reporterobilodeau 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityrandom
StatusclosedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
Summary0001054: locationlog's port is not always relevant to humans
DescriptionWe show this port in the node lookup information but it's not always relevant to humans. But even worse, it the Cisco 3550's case they are like interchanged in an non-obvious way (48 is 19, 19 is 21, 21 is 48, etc.) which causes confusion among users.

I suggest a new mandatory interface call: getHumanReadablePort that would do the right thing per switch and maybe default to ifIndex + "might not be accurate" in pf::SNMP.

Then, in there, we could do what we want, dot1d, ifDescr, ifName, etc.

Add the mandatory interface to a new SNMP switch interface test.
Steps To Reproduce
Additional Information
Tagsusability
Relationships
has duplicate 0000703resolved fgaudreault ifDesc instead of ifIndex 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-08-27 13:58obilodeauNew Issue
2010-09-22 16:02obilodeauTarget Version1.9.2 => 1.9.3
2010-11-02 12:49obilodeauTag Attached: usability
2011-02-02 17:01obilodeauRelationship addedhas duplicate 0000703
2011-12-14 09:21obilodeauNote Added: 0002471
2012-10-19 12:41fgaudreaultTarget Version1.9.3 => long-term
2013-07-11 09:44roadracer96Note Added: 0003340
2013-07-29 12:40Xen0PhageNote Added: 0003347
2013-07-29 12:50Xen0PhageNote Added: 0003348
2013-07-29 12:55roadracer96Note Added: 0003349
2015-02-18 10:59lmunroNote Added: 0003949
2015-02-18 10:59lmunroStatusnew => closed

Notes
(0002471)
obilodeau   
2011-12-14 09:21   
potential candidates:
IF-MIB::ifIndex
IF-MIB::ifName
IF-MIB::ifDescr

BRIDGE-MIB::dot1dBasePortIfIndex (1.3.6.1.2.1.17.1.4.1.2) is also of interest. This one needs to be walked per VLAN on Cisco (with community@<vlanid> on v1, v2 and SNMPv3 contexts on v3).
(0003340)
roadracer96   
2013-07-11 09:44   
This would be advantageous to us. We would know exactly which room/termination point a device is plugged into.
(0003347)
Xen0Phage   
2013-07-29 12:40   
ifName, I believe, is supposed to be the standard way to get this information. What if the ifName and ifDescr values were grabbed at the same time the locationlog entry is created and stored with it. This is a bit more to stuff in the database, but would allow for quick lookup.

The only real problem I see with this is if the switch is not configured for persistent ifIndex values. But that would likely cause other problems anyway.

This information can then be shown on the overlay that appears when you click on a mac address.

Would there be a need to have a "refresh" button to retrieve fresh values from the switch? Arguably, the only value that should be changeable there is the ifDescr. ifName shouldn't change.
(0003348)
Xen0Phage   
2013-07-29 12:50   
Looking over the code, you already have functions for getIfName and getIfDesc in SNMP.pm. I don't see getIfName used anywhere, but getIfDesc is at least called in pfcmd_vlan.

Identifying where to plug these in and adding the relevant code to insert/update the locationlog database seems fairly straightforward. If I can wrap my head around the logic, I'll see if I can come up with a patch for this.
(0003349)
roadracer96   
2013-07-29 12:55   
Dont forget ifAlias. Thats what is changed in SNMP when we change our port display string. ifDescr isnt editable on our switches. Leave some versatility.

Personally, I would say a scheduled refresh with a gui button for a manual refresh would be best. I dont think the information inserted in the database should be persistent to the session when it happened and not change after the fact. Say switch 1.2.3.4 port 2041 is asigned "Room 2033-1", the session should show "Room 2033-1" even if we go through next week and re-patch a closet and port 2041 becomes "Room 2048-3".

Make sense?
(0003949)
lmunro   
2015-02-18 10:59   
Obsolete bug tracker entries.
PF 4 introduced changes that either make these irrelevant or impossible to reproduce.

New issues are moving to github issues.