Re: [PacketFence-users] pfqueue gets wedged

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Charles,

Can you try this patch to see if it helps your issue

Patch instructions

cd /usr/local/pf

curl 
https://github.com/inverse-inc/packetfence/commit/5818ec6e37c396a68bef8411601c1c8131fa26a9.diff 
 > 5818ec6e37c396a68bef8411601c1c8131fa26a9.diff

service packetfence stop

copy to /usr/local/pf

patch -p1 < 5818ec6e37c396a68bef8411601c1c8131fa26a9.diff

service packetfence start

James Rouzier
jro...@in... :: +1.514.447.4918 (x115)  ::  http://www.inverse.ca
Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence (http://www.packetfence.org)

On 2017-04-27 12:28 PM, Charles Rumford wrote:
> On 4/27/17 10:49 AM, James Rouzier wrote:
>> Charles what version of packetfence are you using?
> 6.5.1
>
> I restarted packetfence as a whole, and has been sending CoAs just fine
> for about an hour. The only correlation that I could find while
> troubleshooting was pfqueue. It's clearly a load related issue.
>
> Do there exist any documents about performance tuning?
>
>> James Rouzier
>> jro...@in... :: +1.514.447.4918 (x115)  ::  http://www.inverse.ca
>> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence (http://www.packetfence.org)
>>
>> On 2017-04-27 9:49 AM, Charles Rumford wrote:
>>> On 4/27/17 9:42 AM, Fabrice Durand wrote:
>>>> Hello Charles,
>>>>
>>>> api:desAssociate is when a device is in process of registration or when
>>>> the unreg date is reached.
>>>>
>>>> api:fingerbank_process is probably based on the dhcp traffic the server
>>>> receive.
>>>>
>>>> Do you have some errors in the pfqueue.log ?
>>> I'm seeing some of the following:
>>> Apr 27 09:32:28 pfqueue(125776) WARN: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $n_status in string eq at
>>> /usr/local/pf/lib/pf/roles.pm line 105.
>>>    (pf::roles::getRoleForNode)
>>> Apr 27 09:32:28 pfqueue(125776) ERROR: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $n_status in string eq at
>>> /usr/local/pf/lib/pf/roles.pm line 105.
>>>    (pf::roles::getRoleForNode)
>>> Apr 27 09:32:28 pfqueue(125776) WARN: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $n_status in string eq at
>>> /usr/local/pf/lib/pf/roles.pm line 105.
>>>    (pf::roles::getRoleForNode)
>>> Apr 27 09:32:28 pfqueue(125776) ERROR: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $n_status in string eq at
>>> /usr/local/pf/lib/pf/roles.pm line 105.
>>>    (pf::roles::getRoleForNode)
>>> Apr 27 09:32:28 pfqueue(125776) WARN: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $mac in concatenation (.) or string at
>>> /usr/local/pf/lib/pf/roles.pm line 134.
>>>    (pf::roles::performRoleLookup)
>>> Apr 27 09:32:28 pfqueue(125776) ERROR: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value $mac in concatenation (.) or string at
>>> /usr/local/pf/lib/pf/roles.pm line 134.
>>>    (pf::roles::performRoleLookup)
>>> Apr 27 09:32:28 pfqueue(125776) WARN: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value in concatenation (.) or string at
>>> /usr/local/pf/lib/pf/roles.pm line 157.
>>>    (pf::roles::_assignRoleFromCategory)
>>> Apr 27 09:32:28 pfqueue(125776) ERROR: [mac:74:75:48:1a:f5:09] Use of
>>> uninitialized value in concatenation (.) or string at
>>> /usr/local/pf/lib/pf/roles.pm line 157.
>>>    (pf::roles::_assignRoleFromCategory)
>>>
>>> and
>>> Apr 27 09:43:01 pfqueue(123784) WARN: [mac:cc:44:63:0b:4d:c6] Use of
>>> uninitialized value in numeric eq (==) at /usr/local/pf/lib/pf/iplog.pm
>>> line 870.
>>>    (pf::iplog::__ANON__)
>>> Apr 27 09:43:01 pfqueue(123784) ERROR: [mac:cc:44:63:0b:4d:c6] Use of
>>> uninitialized value in numeric eq (==) at /usr/local/pf/lib/pf/iplog.pm
>>> line 870.
>>>    (pf::iplog::__ANON__)
>>>
>>> And a lot of these:
>>>
>>> Apr 27 09:43:28 pfqueue(123784) WARN: [mac:ec:9b:f3:95:02:52] Unable to
>>> perform a Fingerbank lookup for device with MAC address
>>> 'ec:9b:f3:95:02:52' (pf::fingerbank::__ANON__)
>>>
>>> The only thing that I'm getting with relation to CoAs is:
>>> Apr 27 09:26:27 pfqueue(115173) WARN: [mac:50:7a:55:5a:e8:10] Unable to
>>> perform RADIUS Disconnect-Request. CoA-NAK received with Error-Cause:
>>> Session-Context-Not-Found. (pf::Switch::Aruba::radiusDisconnect)
>>>
>>> but I'd guess that this is from the pfqueue dumping the back log of CoAs
>>> and the user no longer on the controller.
>>>
>>>
>>>
>>>> Regards
>>>> Fabrice
>>>>
>>>> Le 2017-04-27 à 09:36, Charles Rumford a écrit :
>>>>> This morning we put our PacketFence installation into production.
>>>>>
>>>>> One of the first things that I noticed was that it appears that the
>>>>> pfqueue gets wedged with task types api:desAssociate and
>>>>> api:fingerbank_process with ever increasing outstanding task counters.
>>>>>
>>>>> If I restart the pfqueue, I see radius CoAs being send for a short
>>>>> period of time, and then nothing, until I restart the pfqueue again.
>>>>>
>>>>> Has anyone else seen this? If so, suggestions on how to fix it?
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> PacketFence-users mailing list
>> Pac...@li...
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> PacketFence-users mailing list
> Pac...@li...
> https://lists.sourceforge.net/lists/listinfo/packetfence-users