> Digging through the code I see what the problem is.. You're *only* > looking for Cisco IP Phones.. Ick..
Can you point me that part of code ? > I guess that means I need to roll my own for this check? Are there > plans to implement something broader for this, or will this check go > away completely like the method description suggests? > > # 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. I'll reevaluate this thing :) > In fact, what happens if I change this so it just returns a 0 every time > and never checks anything? What is the worst that will happen there? > Is is possible that packetfence may receive a trap from an uplink > accidentally? If so, how? Since PacketFence is access port based, if you configure port-security/radius auth/"whatever floats your boat auth" on an uplink and PacketFence is receiving the "Access-Request" and doesn't know that it is currently dealing with an uplink, you may lose that port ;) I'll let you imagine what it can cause :P > Also, this? Love comments like this.. :P > > # TODO: what the hell is this supposed to do? I'll reevaluate this thing too ;) We looove to put some comments in the code ahah :) Cheers! dw. -- Derek Wuelfrath [email protected] :: +1.514.447.4918 (x110) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) On 2013-07-22, at 8:06 PM, Jason Frisvold <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jason Frisvold wrote: >> Greetings, >> >> How does the "Dynamic Uplinks" option for a switch work? I'm >> running into a problem where I'm being told a port is an uplink when >> it's not. The error is as follows : >> >> Jul 16 14:41:44 pfsetvlan(7) INFO: reAssignVlan trap received on >> 10.0.10.10 ifindex 10102 which is uplink and we don't manage uplinks >> (pf::vlan:oWeActOnThisTrap) > > Upgrading to 4.0.3 doesn't appear to have solved this for me. I'm still > getting the same error : > > Jul 22 19:45:05 pfsetvlan(3) INFO: reAssignVlan trap received on > 10.0.10.10 ifindex 10102 which is uplink and we don't manage uplinks > (pf::vlan::doWeActOnThisTrap) > > Digging through the code I see what the problem is.. You're *only* > looking for Cisco IP Phones.. Ick.. > > I guess that means I need to roll my own for this check? Are there > plans to implement something broader for this, or will this check go > away completely like the method description suggests? > > # 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. > > In fact, what happens if I change this so it just returns a 0 every time > and never checks anything? What is the worst that will happen there? > Is is possible that packetfence may receive a trap from an uplink > accidentally? If so, how? > > Also, this? Love comments like this.. :P > > # TODO: what the hell is this supposed to do? > > - -- > - --------------------------- > Jason 'XenoPhage' Frisvold > [email protected] > - --------------------------- > > "Any sufficiently advanced magic is indistinguishable from technology." > - - Niven's Inverse of Clarke's Third Law > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlHtyQEACgkQ8CjzPZyTUTS5ggCfd/viRJcsQWNHGW61gt4NMKOa > SVsAoJXHxz9zQGeGprqSMGSB8mANwIIx > =TE8C > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
