FPAD packets killing server?

[Glenn Satchell]

Hi Paul

You definitely need to upgrade to a newer version of ISC DHCPD. 3.0pl2
is about 6-7 years old bow, with only 2 security fixes since then. Even
3.0.1 is about 4 years old, so neither of those is a reasonable
candidate.

You should install 3.0.5, which is the latest production release. There
have been some bug fixes that have tightened the behaviour of the
syntax checker, so configurations that loaded on 3.0 might not load on
the newer releases.

The only statement you might like to add is 'authoritative' since the
default behaviour changed somewhere along the way.

The new releases are otherwise completely compatible with the
dhcpd.conf and dhcpd.leases files.

regards,
-glenn

>Date: Sun, 25 Feb 2007 18:35:41 -0500
>From: Paul Keck <pkeck at uga.edu>
>To: dhcp-users at isc.org
>Subject: FPAD packets killing server?
>
>Hi all,
>
>I am having a problem where it seems like FPAD (Flash Proxy Auto-Discovery)
>packets are killing the server.
>
>I have been running isc-dhcpd-V3.0pl2 successfully for quite some time.  I
>saw occasional messages like:
>
>Feb  4 16:34:40 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:35:31 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:35:31 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:35:56 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 128.192.55.1
>Feb  4 16:36:10 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:36:10 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:37:22 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:37:22 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:37:36 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>
>but they don't seem to hurt anything, and some googling and list searching
>didn't show any concern, so I ignored them.
>
>Recently I need to support some Cisco lightweight wireless access points
>which need some extra options.  So I added:
>
>option space cisco-ap;
>option cisco-ap.controller code 241 = array of ip-address;
>option cisco-ap-encap code 43 = encapsulate cisco-ap;
>
>This works in a testbed to assign the proper stuff to the LWAPs.  So I added
>it to the production config and ran with it.  However, as soon as it was in
>the config, I started seeing:
>
>Feb  4 16:37:36 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:38:04 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:38:04 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:38:42 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:38:42 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:38:42 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:38:42 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:39:04 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:39:04 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:39:04 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:39:04 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 0.0.0.0
>Feb  4 16:40:07 dhcpserver dhcpd: parse_option_buffer: option #116 (97) larger 
than buffer.
>Feb  4 16:40:07 dhcpserver dhcpd: DHCPINFORM from 4.0.0.0 via eth0: unknown 
subnet 172.18.2.129
>
>
>I never saw the buffer messages except right before the 4.0.0.0 lines. So, I
>did some googling and list searching and didn't see much.  I figured it
>would probably just be more harmless messages and decided not to worry too
>much because we are on a deadline.
>
>Now, I have a script that regenerates the dhcpd.conf from a database, tests
>it with -t, and if good, stops and restarts the dhcpd, every 5 minutes. 
>This script started telling me it failed to stop dhcpd, and further
>investigation showed that dhcpd was dying sometimes as soon as a minute into
>its restart and sometimes at 4 minutes.  It SOMETIMES made it all the way to
>5 minutes and did not die.  At the moment of dying there was nothing special
>in the logs.
>
>After over an hour of fooling around, and dhcpd dying most every 5 minutes,
>I decided I could not go into Monday like that so I backed out the cisco
>options and the parse_option_buffer messages went away, and dhcpd stopped
>dying.
>
>Since then I have been trying to address this without much luck.  iptables
>can't block 4.0.0.0 because of the raw sockets business.  I also tried
>blocking that address at the switch port the DHCP server uses but no luck
>there either- after some sniffing it turns out that the packets come from a
>valid router somewhere on campus, not 4.0.0.0.  My sysadmins told me I
>should upgrade the server to isc-dhcpd-V3.0.1, the version they put on a
>newer server that is built and ready to replace the old one.  Problem is,
>due to some interesting usage of pool statements by my predecessors, the
>config will not load up on the newer version.  I rewrote the config
>generator so it makes a config that WILL load, but when pointing a small
>network at the new server for DHCP I got parse_option_buffer messages (and
>of course 4.0.0.0 messages) in the logs so I am not confident I could roll
>that out to the whole campus and have it not crash.
>
>Any ideas?  I'm not positive the FPAD is causing the server to die but it is
>extremely suspicious.  Once I backed out the changes the buffer messages
>stopped and the crashes stopped.
>
>If there was a way to toss any packet with the string "Adobe Flash Proxy
>Auto-Discovery" in it that would work, but I don't have deep inspection
>possible in the network devices there.  Can the dhcpd itself do something
>like that?  Or can anyone think of any other way to handle this, perhaps by
>doing the cisco stuff differently?  The goal is to supply the cisco options
>after all.
>
>I appreciate the consideration.
>
>
>-- 
>Paul Keck       pkeck at uga.edu         http://www.arches.uga.edu/~pkeck
>University of Georgia                 http://www.uga.edu/ucns/telecom
>EITS Network Engineering              mailto:pkeck at ediacara.org
>    --Opinions mine.--                Go fighting anomalocaridids!!!
>