FPAD packets killing server?

Sun Feb 25 23:35:41 UTC 2007

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!!!