Hi Antonio, On 22/02/11 3:05 PM, Manueco, Antonio wrote: > Considering the fact that Meru might not want to support deauth through SNMP > I'd like to see if we can do something. When you configure a switch to use > ssh (haven't tested telnet but I am guessing it uses the same parameters) > that it spawns a new SSH session with the switch (in our case it's a Meru > Controller) for every time someone registers to deauth the wireless client. > > Considering we have 41,000+ wireless registered devices and about 5k > simultaneous users on the network, this is going to crash the Meru controller > no doubt. >
So far, that assumption has been mitigated by the fact that with PacketFence you only do registration once. In other words, your 5k+ users will only be deauth (through SSH) once when they register on the captive portal. That is, unless you de-register them automatically or periodically. On WPA-Enterprise (802.1X) since they provide credentials you can even skip the whole registration phase and send them straight to proper VLAN. So if you perform no massive de-registration, a gradual roll-out should be enough to cope with the SSH deauth rate. Then, for your next semesters students arrive gradually enough for the controller to be really busy on Monday mornings but not overloaded. Again, testing is always preferable to making assumptions. Have a look into the t/stress-test/soap-calls-snort[1] script. With some modifications, this multi-threaded Web Services tester could be transformed into a massive SSH deauth testing tool. In the thread loop, spawning a copy of the Meru object with a switchFactory instance and then calling ->deauthenticateMac(..) with fake MACs (or, even better, real ones) should be very educative about Meru's and PF's behaviors. > What I want to do is tweak the process that PF is using to ssh into the > switches and see if it's possible to maintain one session open and feed it > the parameters it needs to deauth clients from the controller. Any input on > how PF is configured to do this and where to look would be awesome, I think > some users might benefit from this. What do you guys think? Any other > suggestions that don't depend on the vendor? > It's a great idea! However, it's a rather intrusive change with foreseeable concurrency issues (the daemon handling SSH disconnects - pfsetvlan - is already multi-threaded..). I would add a new task (thread) to pfmon which would hold the SSH connection open and have IPC between pfsetvlan in the Meru Controller module and pfmon to tell him to perform deauth. pfmon would take care of re-connecting if connectivity has been lost and idle otherwise. When it gets the IPC call it would call the Meru controller module's _deauthMac(..) passing in the Net::Appliance::Session handle. My advice: test if you need it. If you do, try to pressure your Vendor again for RFC3576 support or Web Services calls (it seems Meru's SNMP stack is read-only, reason for no SNMP deauth). If it fails, look into developing your idea. I'm very surprised that with a wireless network your size you don't have more leverage on your vendor. I hope this helps, Cheers! [1] http://mtn.inverse.ca/revision/file/8575a6a8a246a2e8096a9e58a451f59cfd179fa2/pf/t/stress-test/soap-calls-snort -- Olivier Bilodeau obilod...@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
