TCP RST sent on incoming UDP packet

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

I'm trying to move my Captive Portal (which, for complicated reasons, includes 
a DHCP server) from a -6 machine to a -8 one.
It doesn't work: the DHCP part doesn't receive any requests.

The strange thing is that tcpdump shows me that someone is replying to the 
incoming DHCP traffic (UDP, 0.0.0.0:bootpc -> 255.255.255.255:bootps) by 
sending a TCP RST packet! This is not an IPFilter return-rst rule because
a) tcpdump wouldn't see such traffic and b) I even temporarily stopped ipf 
just to be absolutely sure.
This is also not my application because a) ktruss shows it doesn't receive 
the request and b) it also happens if I stop it.

So who the hell is sending this?

Unfortunately, I'm unable to mimic the real DHCP packets (even minus the 
payload) with nc because it seems to be unable to send to 255.255.255.255. 
It is, however, able to send to that network's broadcast address, in which 
case my application receives the (bogus) packet.

Any hints how to track this down? Is there a way to determine which process 
sent a specific outgoing packet? Can it be the kernel getting confused by 
the unspecified sender address and sending a noone-is-listening-on-that-port 
RST?