|
From: mourik j. h. <he...@gm...> - 2015-07-13 08:17:08
|
Hi Fabrice, Thanks for your reply. I'll test if this is what is happening. Thanks! On 07/10/2015 05:36 PM, Fabrice DURAND wrote: > Hello Mourik, > > my answer bellow. > > Regards > Fabrice > > Le 2015-07-10 08:41, mourik jan heupink a écrit : >> Hi Andy, list, >> >> Yes, you are totally right. :-) Sorry. Let me try again. >> >> I'm running packetfence 5.2.0, debian wheezy, installed from the repo's, >> inline mode. My inline NATted network is 10.19.0.0/16 and packetfence >> has ip 10.19.0.1 on eth0 as the gateway for the NATted network. We have >> enabled the captive portal, with self registration. >> >> Anyway: Things seem to work 'unpredictable'. After registration, >> sometimes network detection works, but sometimes clients become trapped >> in the "Sorry, your network should be enabled within a minute or two". > We found that chrome and other brother use a internal dns cache. > So let's say your browser want to go on www.cisco.com, your laptop send > a dns request to packetfence and return the portal ip (dns cached in the > system for 15s and in the browser for 1 minute). > Your browser is redirected to the captive portal, you register, the > javascript try to fetch the giff (Success) and the javascript redirect > you on www.cisco.com. > > So what happen, imagine you register took 1,2 minutes , then the laptop > ask for www.cisco.com but now fetch the real ip, so you can see the web > page. > > You registration took 45s, the dns cache for www.cisco.com is still the > ip of the portal so you hit the portal with the Sorry page. > > What you can do is to force the redirection url on the captive portal to > other thing that www.cisco.com. > Or you can set the progress bar timer to something more than 1 minute > (or use that > https://github.com/inverse-inc/packetfence/compare/feature/hybrid_mode_by_vlan_filter.diff) > > >> Having said that, we notice the following warnings in the logs: >> >>> WARN: Problem trying to run command: LANG=C sudo ipset del >>> PF-iL2_ID4_10.19.0.0 10.19.218.65 2>&1 called from >>> iptables_update_set. Child exited with non-zero value 1 >>> (pf::util::pf_run) > Because your category changed but your device wasn't in the ipset > session (first time you register) >> (NOTE: manually running the same command as pf user seems to work!) >> >>> Jul 08 18:55:55 httpd.webservices(3636) WARN: Problem trying to run >>> command: LANG=C sudo /usr/sbin/conntrack -D -s 10.19.218.65 2>&1 >>> called from iptables_unmark_node. Child exited with non-zero value 1 >>> (pf::util::pf_run) > If there is no conntrack you have this message. (normal from unreg to reg) >> (NOTE again: manually running the same command as pf also seems to work) >> >>> Jul 08 20:37:04 httpd.portal(3623) ERROR: WARNING ! Unknown >>> switch(es) 10.19.0.1 (pf::SwitchFactory::instantiate) > I fixed that in the patch above >> (NOTE: this ip is the packetfence NAT address, gateway/dhcp, and there >> is NO switch configured with this ip) (verified in switches.conf) >> >>> WARN: Problem trying to run command: LANG=C sudo ipset del >>> PF-iL2_ID_10.19.0.0 10.19.218.65 2>&1 called from >>> iptables_update_set. Child exited with non-zero value 1 >>> (pf::util::pf_run) >> Judging from that, I assume that the ipset PF-iL2_ID_10.19.0.0 exists, >> however it does not? See: >> >>> root@pf:/usr/local/pf/logs# su pf >>> $ sudo ipset -L >>> Name: PF-iL2_ID1_10.19.0.0 >>> Type: bitmap:ip >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 8312 >>> References: 2 >>> Members: >>> >>> Name: PF-iL2_ID2_10.19.0.0 >>> Type: bitmap:ip >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 8312 >>> References: 2 >>> Members: >>> >>> Name: PF-iL2_ID3_10.19.0.0 >>> Type: bitmap:ip >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 8312 >>> References: 2 >>> Members: >>> >>> Name: PF-iL2_ID4_10.19.0.0 >>> Type: bitmap:ip >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 8312 >>> References: 2 >>> Members: >>> 10.19.218.65 >>> >>> Name: PF-iL2_ID5_10.19.0.0 >>> Type: bitmap:ip >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 8312 >>> References: 2 >>> Members: >>> >>> Name: pfsession_Unreg_10.19.0.0 >>> Type: bitmap:ip,mac >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 1048688 >>> References: 1 >>> Members: >>> 10.19.218.61,3C:97:0E:2F:14:F8 >>> >>> Name: pfsession_Reg_10.19.0.0 >>> Type: bitmap:ip,mac >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 1048688 >>> References: 1 >>> Members: >>> 10.19.218.65,60:67:20:5D:74:98 >>> >>> Name: pfsession_Isol_10.19.0.0 >>> Type: bitmap:ip,mac >>> Header: range 10.19.0.0-10.19.255.255 >>> Size in memory: 1048688 >>> References: 1 >>> Members: >> So... I hope someone has the time to read/react to this. I know I'm >> leaving out config files, but if those are relevant, I'll gladly post >> them, of course. (but it's such a long email already...) >> >> MJ >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> PacketFence-users mailing list >> Pac...@li... >> https://lists.sourceforge.net/lists/listinfo/packetfence-users > > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > > > > _______________________________________________ > PacketFence-users mailing list > Pac...@li... > https://lists.sourceforge.net/lists/listinfo/packetfence-users > |