> There appear to be discrepencies in both the Admin and Dev docs as it > pertains to flexible VLAN assignment. The custom.pm module lists the > subroutine as getNormalVlan and the admin docs call it get_normal_vlan.
It's a mistake, the name of the call changed really late in the 2.x cycle and we forgot to update the Admin guide. It's fixed now. > Either way, either it returns no vlan and is followed by a "VLAN not > managed" error, or it keeps returning the normal vlan when it shouldn't. > I forgot to mention in my previous email that yesterday I made this problem easier to spot: If getNormalVlan returns undef (which is what getVlanByName will return on a mistake) then we issue a warning in the logs and replace the undef VLAN (which causes all sorts of problems) with the MacDetectionVlan. -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
