Considering that Meru as a company is 404 and the brain-drain following
the Fortinet acquisition essentially put the whole product line into
life support mode in terms of customer support, I would not hold my
breath waiting for someone to fix any Meru problems in PF.
We are running PF 5.x with two Meru controllers and 600+ AP's. The
de-associate thing has been a pain point for quite some time. Unless
I'm going crazy, ancient versions of PF used to even write log entries
for every de-associate asking users to pressure Meru to add the proper
de-associate support instead of requiring the ssh/telnet kludge. They
supposedly did add the procedure, but I don't know if PF's Meru code
was ever updated to use it.
Long story short, our de-associate seems to be hit-or-miss with PF 5.x.
I think that we had set some sort of station timeout in the Meru
controllers, which causes them to re-query PF every few minutes to
decide if they should still be connected and to what VLAN. Tradeoff
PF server load for more frequent queries versus user inconvenience having
to wait longer for a de-associate/re-associate after registration.
One piece of debugging advice that I will offer is to make sure that
you run ssh once AS THE USER RUNNING THE PF SERVICE to automatically
add the controller's certificate into the ssh config as a known host.
I don't know if PF is calling out to ssh or using some perl function
to do the connection, but have seen that pesky certificate prompt
break plenty of automation routines that use ssh over the years.
So, as is the case with anything in the open-source community or with
volunteer organizations, I suspect that the only way this will ever get
fixed is if someone who hasn't moved away from Meru/Fortinet takes the
lead and figures out what is needed to do the native de-associate without
ssh/telnet. Everyone that I knew from Meru moved on a long time ago,
so I have no resources to tap outside of the same Fortinet support
department that everyone else has available...
-Arthur
-------------------------------------------------------------------------
Arthur Emerson III Email:
emer...@msmc.edu<mailto:emer...@msmc.edu>
Network Administrator InterNIC: AE81
Mount Saint Mary College MaBell: (845) 561-0800 Ext. 3109
330 Powell Ave. Fax: (845) 562-6762
Newburgh, NY 12550 SneakerNet: Aquinas Hall Room 008-A
From: Derek Brabrook via PacketFence-users
<packetfence-users@lists.sourceforge.net><mailto:packetfence-users@lists.sourceforge.net>
Reply: packetfence-users@lists.sourceforge.net
<packetfence-users@lists.sourceforge.net><mailto:packetfence-users@lists.sourceforge.net>
Date: March 6, 2018 at 12:20:42 PM
To: packetfence-users
<packetfence-users@lists.sourceforge.net><mailto:packetfence-users@lists.sourceforge.net>
Cc: Derek Brabrook
<dbrabr...@qehs.carms.sch.uk><mailto:dbrabr...@qehs.carms.sch.uk>
Subject: [PacketFence-users] So is support for Meru dead now on 7.4 ?
seeing as packetfence won't connect to the meru controller either via telnet or
ssh to de-associate
macs ?
(see previous posts on this issue Meru 3200)
------------------------------------------------------------------------------
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
PacketFence-users@lists.sourceforge.net
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
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
