> Ditto here with PF 3.6 and certain Android devices, including one that > is issued to a co-worker. I haven't dug into the problem much, but > suspect that the problem is that Android is trying to contact the last > DHCP server it spoke to when it wakes up, even though it is on a > different SSID/network. PF's rogue DHCP detector sees those packets > addressed to an unknown DHCP server, and it sets off the rogue alarm > when in fact there's no server answering. It seems to happen most > after we close for a break or long weekend, since the students go home > and then come back with phones that are still looking for their home > router's 192.168.1.1 DHCP server.
That is correct. As for the rogue DHCP “false positives issues” in PacketFence, we are currently working on the best way to handle different use cases including this one. Cheers! dw. -- Derek Wuelfrath [email protected] :: www.inverse.ca +1.514.447.4918 (x110) :: +1.866.353.6153 (x110) Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) On May 14, 2014, at 8:51 AM, Arthur Emerson III <[email protected]> wrote: > On May 13, 2014, at 8:10 PM, Jason Frisvold <[email protected]> wrote: > >> Are you sure they're not rogues? We're seeing a lot of this on wireless >> and it appears to be misbehaving android phones... > > Ditto here with PF 3.6 and certain Android devices, including one that > is issued to a co-worker. I haven't dug into the problem much, but > suspect that the problem is that Android is trying to contact the last > DHCP server it spoke to when it wakes up, even though it is on a > different SSID/network. PF's rogue DHCP detector sees those packets > addressed to an unknown DHCP server, and it sets off the rogue alarm > when in fact there's no server answering. It seems to happen most > after we close for a break or long weekend, since the students go home > and then come back with phones that are still looking for their home > router's 192.168.1.1 DHCP server. > > In many cases, I've noticed that the IP address history doesn't show > the offending device getting a valid DHCP address on our network, so > I just put them into 24-hour quarantine (send them to the "timeout" > corner) and they usually come back and work properly after that... > > -Arthur > > ------------------------------------------------------------------------- > Arthur Emerson III Email: [email protected] > 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 11 > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
