Re: TCP RST sent on incoming UDP packet

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

lsof from pkgsrc is your friend, something like "lsof -i udp:bootps".

I'm pretty sure it is possible to arrange for multiple processes to 
listen on the same UDP port, but it has been years since I played around 
with that so I don't remember what the precise rules are.

A TCP RST also makes it sound like something is trying to translate the 
UDP request into a TCP request and then the TCP connection is getting 
broken (e.g. the server handling the TCP connection is crashing). If 
there was no TCP server listening at all, you would get an ICMP message 
instead of a TCP reset. This paragraph is largely speculation.

Cheers,
Lloyd

On 19/05/22 06:50, Edgar Fuß 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?