PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001451PacketFencecorepublic2012-05-11 16:302013-07-31 19:43
Reporterobilodeau 
Assigned Tofdurand 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
Summary0001451: get rid of the uplinks=... concept
DescriptionAfter doing 7264ede and a1b4cc8 I wrote:

# FIXME I just refactored that method but I think we should simply get rid
# of the uplinks=... concept. If you've configured access-control on an
# uplink then it's your problem. Anyway we don't do anything on RADIUS based
# requests. I guess this was there at first because of misconfigured up/down
# traps causing concerns.

Plus we haven't implemented dynamic support on most vendor other vendors and maintaining a list manually is just painful.

We'll discuss it and then decide whether we should do it or not.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-11 16:30obilodeauNew Issue
2012-10-19 11:57fgaudreaultTarget Versionlong-term => general
2013-07-22 20:26Xen0PhageNote Added: 0003343
2013-07-31 19:42fdurandNote Added: 0003354
2013-07-31 19:43fdurandStatusnew => resolved
2013-07-31 19:43fdurandResolutionopen => fixed
2013-07-31 19:43fdurandAssigned To => fdurand

Notes
(0003343)
Xen0Phage   
2013-07-22 20:26   
I'd like to ping this instead of opening a new bug request on it. We're having a problem with this now. Basically, the SNMP module for Cisco has "Cisco IP Phone" hardcoded as an identifier for a VoIP phone, but we don't use Cisco VoIP phones. I can easily make the change myself to support our phones, but then I run into maintenance issues with future upgrades.

Removing the uplinks concept entirely sounds viable, except that then there's no "gut check" when a trap comes in to catch any traps sourced from actual uplinks. I'm not sure when, if ever, such a trap would be sent, but having a check to prevent problems may be better than breaking the network.

I can think of two possible solutions. One, have a configurable option where the user can list the CDP/LLDP values of the IP phones they use. Another would be to reverse the check and have users list the CDP/LLDP values of switches they use. Either would solve this problem, I think, and would then put the onus of making the list on the user. Some simple help documentation on how to get the list from the switch should be sufficient.
(0003354)
fdurand   
2013-07-31 19:42   
it has been fixed, so now we fetch the bit to detect if it's an ip phone in CDP flag.