On Feb 27, 11:43am, Jonathan Lemon wrote: } Subject: cvs commit: src/sys/netinet ip_input.c } jlemon 2001/02/27 11:43:14 PST } } Modified files: } sys/netinet ip_input.c } Log: } When iterating over our list of interface addresses in order to determine } if an arriving packet belongs to us, also check that the packet arrived } through the correct interface. Skip this check if the packet was locally } generated. } } Revision Changes Path } 1.156 +19 -15 src/sys/netinet/ip_input.c } }-- End of excerpt from Jonathan Lemon This (at least the non-IPFIREWALL_FORWARD case) doesn't look right to me. If I have a server dual homed on two networks with the IP addresses 192.168.1.1 and 192.168.2.1, and a client on the 192.168.1.0 network sends a packet to the 192.168.2.1 address to the 192.168.1.1 interface, it looks like the "ours" test will fail. I suspect this will cause the server to attempt to forward this packet out to the 192.168.2.0 network, if it has IP forwarding enabled. On the other hand, it looks like the server will accept a packet received on the 192.168.1.1 interface with the destination address 192.168.2.255. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
