FreeBSD receives a (clearly broken) IP unicast packet encapsulated in an ethernet broadcast frame. Unicast packet is addressed to another machine on the local net (other machine happens to be down). FreeBSD attempts to forward the IP packet: ARPs for destination address, and issues an ICMP redirect. Arguably the packet should just be dropped silently, but in any case FreeBSD should not be sending an ICMP error message in response to a broadcast packet. Fix: RFC-1122 section 2.4 mandates the existance of a flag indicating link-layer broadcast in a received packet. I don't know the BSD stack well enough to know whether that flag exists, but if it does, checking it before sending ICMP error messages or forwarding the packet should do the trick. (Sorry, I know IP stacks pretty well, but mostly deeply embedded devices, not BSD kernel.) How-To-Repeat: Generate a unicast IP packet with IP destination address of an unused address on the local net. Send this encapsulated in an ethernet broadcast frame (use BPF, or find a Windows machine that's broken in the same strange way as the one that caused me to notice this). Run tcpdump to watch the traffic pattern.
State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE?
On Sat, Jul 21, 2001 at 06:15:33PM -0400, Rob Austein wrote: > Date: Sat, 21 Jul 2001 11:36:51 -0700 (PDT) > From: <mike@FreeBSD.org> > > Synopsis: FreeBSD 3.3 sends ICMP reply to IP unicast received as ethernet broadcast > > State-Changed-From-To: open->feedback > State-Changed-By: mike > State-Changed-When: Sat Jul 21 11:36:37 PDT 2001 > State-Changed-Why: > > Does this problem still occur in newer versions of FreeBSD, > such as 4.3-RELEASE? > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16013 > > Dunno. The particular misconfigured production network that triggered > the bad reply no longer exists. I'll see if I can reproduce the > problem in the lab when I get a chance and get back to you on that. Thanks. Best regards, Mike Barcroft
State Changed From-To: feedback->closed Automatic feedback timeout. If additional feedback that warrants the re-opening of this PR is available but not included in the audit trail, please include the feedback in a reply to this message (preserving the Subject line) and ask that the PR be re-opened.