Captive portal error: exception in switch_group.pm

[caralo]

Debian 8.11, PF 8.1 Captive portal error "Application error : Caught exception in captiveportal::Controller::Root->getLanguages "Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/lib/pf/condition/switch_group.pm line 52." Caught exception in captiveportal::Controller::Root->setupLanguage "Can't use string ("0") as an ARRAY ref while "strict refs" in use at /usr/local/pf/lib/captiveportal/PacketFence/Controller/Root.pm line 189." Caught exception in captiveportal::Controller::Root->setupDynamicRouting "Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/lib/pf/condition/switch_group.pm line 52." Caught exception in captiveportal::Controller::Root->dynamic_application "Can't call method "execute" on an undefined value at /usr/local/pf/lib/captiveportal/PacketFence/Controller/Root.pm line 156."

In packetfence.log: Jan 14 13:55:38 pf1 pfqueue: pfqueue(11338) ERROR: [mac:] WARNING ! Unknown switch(es) 192.168.18.7 (pf::SwitchFactory::instantiate) Jan 14 13:55:38 pf1 pfqueue: pfqueue(11338) ERROR: [mac:] Error occured while handling trap : Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/lib/pf/condition/switch_group.pm line 52.

The IP 192.168.18.7 is used by PF for inline. It is not a real switch. There is a switch group created but only a few of the switches belong to a switch group

[julsemaan]

From what that log line says, SNMP traps are being received for that switch.

Can you post your pf.conf, switches.conf and networks.conf so I can try to get some context around this issue.

Please obfuscate passwords and non-public information of the files before posting them here.

[caralo]

The node was previously connected to inline, and now it is connected out-of-band to a real switch that has no group_switch. If I delete the last locationlog for that node (directly at the database), then the captive portal works. pf.conf ... [interface eth0.802] type=management,high-availability,portal mask=255.255.255.0 ip=XXXXXXXXX

[interface eth0.818] ip=192.168.18.7 mask=255.255.255.0 type=internal enforcement=inlinel2

[interface eth0.819] enforcement=vlan type=internal mask=255.255.255.0 ip=192.168.19.7

[interface eth0.820] type=internal enforcement=vlan mask=255.255.255.0 ip=192.168.20.7

networks.conf: [192.168.18.0] dhcp_default_lease_time=86400 gateway=192.168.18.4 netmask=255.255.255.0 domain-name=inlinel2.xxx dhcp_max_lease_time=86400 type=inlinel2 named=enabled dhcp_start=192.168.18.10 split_network=disabled fake_mac_enabled=disabled dns=xxxxxxxxxxx dhcp_end=192.168.18.246 nat_enabled=enabled dhcpd=enabled

[192.168.19.0] dhcp_end=192.168.19.246 dhcpd=enabled nat_enabled=disabled dns=192.168.19.4 fake_mac_enabled=disabled dhcp_start=192.168.19.10 split_network=disabled type=vlan-registration named=enabled domain-name=vlan-registration.xxx dhcp_max_lease_time=30 gateway=192.168.19.4 dhcp_default_lease_time=30 netmask=255.255.255.0

[192.168.20.0] netmask=255.255.255.0 dhcp_default_lease_time=30 gateway=192.168.20.4 dhcp_max_lease_time=30 domain-name=vlan-isolation.xxx named=enabled type=vlan-isolation split_network=disabled dhcp_start=192.168.20.10 fake_mac_enabled=disabled dns=192.168.20.4 dhcpd=enabled dhcp_end=192.168.20.246 nat_enabled=disabled

switches.conf [default] vlans=XXX normalVlan=XXX registrationVlan=819 isolationVlan=820 macDetectionVlan=821 inlineVlan=818 normalRole=normal registrationRole=registration isolationRole=isolation macDetectionRole=macDetection SNMPCommunityRead=xxx SNMPCommunityWrite=xxx SNMPCommunityTrap=xxx deauthMethod=SNMP ... many switches without group like this [10.0.1.72] description=D64 type=Netgear::GS110 uplink_dynamic=0 uplink=1,8 SNMPVersion=2c mode=production defaultVlan=830 ldapVlan=830 SNMPVersionTrap=2c

Others with group like this [10.0.1.221] group=Hedy description=H-1

[group Hedy] description=Switches Hedy type=Netgear::GS110 uplink_dynamic=0 uplink=1,2,7,8 SNMPVersion=2c SNMPVersionTrap=2c SNMPCommunityTrap=xxx SNMPCommunityRead=xxx SNMPCommunityWrite=xxx

[julsemaan]

Can you confirm what is the new IP address of the out-of-band switch the device is connecting to.

Then, please also provide the content of /usr/local/pf/logs/snmptrapd.log while the issue is happening.

[caralo]

The IP address of the out-of-band switch is 10.0.1.72 ***snmptrapd.log 2019-01-14|12:55:36|UDP: [10.0.1.72]:1025->[XXXPublic-IP-PFXXX]:162|0.0.0.0|BEGIN TYP E 0 END TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.1.3 .0 = Timeticks: (105459300) 12 days, 4:56:33.00|.1.3.6.1.6.3.1.1.4.1.0 = OID: .1 .3.6.1.6.3.1.1.5.4|.1.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3|.1.3.6.1.2.1.2.2.1.7.3 = INTEGER: up(1)|.1.3.6.1.2.1.2.2.1.8.3 = INTEGER: up(1) END VARIABLEBINDINGS perl callback function 0x1bb3410 returns 1

[julsemaan]

Its like if the switch that gets instantiated when swtiching from inline to SNMP traps is the one from the locationlog (so the virtual inline switch) instead of the one where the trap is coming from.

This is fairly hard to troubleshoot i our lab since its so corner case.

I'll try to see if I can find time to do a bit of code diving to see if I can find something

[caralo]

It is not so corner case. It also occurs with a new computer connected to inline (no SNMP traps this time) In packetfence.log: Jan 21 19:10:57 pf2 packetfence_httpd.portal: httpd.portal(16428) ERROR: [mac:xx:xx:xx:xx:xx:xx] WARNING ! Unknown switch(es) 192.168.18.7 (pf::SwitchFactory::instantiate) Jan 21 19:10:57 pf2 packetfence_httpd.portal: httpd.portal(16428) ERROR: [mac:xx:xx:xx:xx:xx:xx] Caught exception in captiveportal::Controller::Root->getLanguages "Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/lib/pf/condition/switch_group.pm line 52." (captiveportal::PacketFence::Controller::Root::end) Jan 21 19:10:57 pf2 packetfence_httpd.portal: httpd.portal(16428) ERROR: [mac:xx:xx:xx:xx:xx:xx] Caught exception in captiveportal::Controller::Root->setupLanguage "Can't use string ("0") as an ARRAY ref while "strict refs" in use at /usr/local/pf/lib/captiveportal/PacketFence/Controller/Root.pm line 189." (captiveportal::PacketFence::Controller::Root::end) Jan 21 19:10:57 pf2 packetfence_httpd.portal: httpd.portal(16428) ERROR: [mac:xx:xx:xx:xx:xx:xx] Caught exception in captiveportal::Controller::Root->setupDynamicRouting "Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/local/pf/lib/pf/condition/switch_group.pm line 52." (captiveportal::PacketFence::Controller::Root::end) Jan 21 19:10:57 pf2 packetfence_httpd.portal: httpd.portal(16428) ERROR: [mac:xx:xx:xx:xx:xx:xx] Caught exception in captiveportal::Controller::Root->dynamic_application "Can't call method "execute" on an undefined value at /usr/local/pf/lib/captiveportal/PacketFence/Controller/Root.pm line 156." (captiveportal::PacketFence::Controller::Root::end)

I forgot to mention that we have a connection profile with a filter for a specific switch group. That may help you.

[julsemaan]

I've pushed a fix in the maintenance for this.

You can apply the maintenance by running:

/usr/local/pf/addons/pf-maint.pl

And then restarting PacketFence

[caralo]

Thank you very much. The only "wrong" thing that I can see in packetfence.log is: Jan 24 18:51:55 pf1 packetfence_httpd.aaa: httpd.aaa(1907) WARN: [mac:xx:xx:xx:xx:xx:xx] Use of uninitialized value in string eq at /usr/local/pf/lib/pf/condition/switch_group.pm line 53. It seems to work anyway.

[julsemaan]

Tracked it down to an issue with the logical condition

Should be fixed in 1c3e09da1cb2006ffb97ea95eb6aa4c2f690513e

You can get the fix through the maintenance as well

[caralo]

Thank you again. It is all fixed now.