[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
TCP RST sent on incoming UDP packet
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
Main Index |
Thread Index |