Re: TCP RST sent on incoming UDP packet

[Andy Ruhl <acruhl%gmail.com@localhost>]

On Wed, May 18, 2022 at 11:51 AM Edgar Fuß <ef%math.uni-bonn.de@localhost> wrote:
>
> 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?

You said "someone is replying". What about the MAC address then? Does
that tell you who it is?

Andy