tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: TCP RST sent on incoming UDP packet

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.


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

Home | Main Index | Thread Index | Old Index