From owner-freebsd-hackers Thu Jan 30 03:05:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04720 for hackers-outgoing; Thu, 30 Jan 1997 03:05:10 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04713 for ; Thu, 30 Jan 1997 03:05:04 -0800 (PST) Received: from dibble.utell.net (dibble.utell.net [97.3.0.10]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id KAA00746; Thu, 30 Jan 1997 10:57:47 GMT Message-Id: <199701301057.KAA00746@ui-gate.utell.co.uk> From: "Brian Somers" To: Cc: , , , , Subject: Re: ipdivert & masqd Date: Thu, 30 Jan 1997 10:53:04 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've essentially got the following: > > > > ---------------- ---------------------- > > | 10.0.10.2 |------------------| 10.0.10.1 | > > ---------------- | | > > | 10.0.1.254 (ed0) | > > ---------------------- > > | > > | > > ----------------- | > > | 10.0.1.1 |--------------------------- > > ----------------- > > > > with a mask of ffffff00 everywhere and the machine in the middle using > > the following: > > > > ipfw add 100 divert 6668 all from any to any via ed0 > > A-HAH! :-) > > Could you try the following patch? > > Thanks, > - -Archie > > [.....] I tried it, and I'm a bit confused about the results ! It allows connections in both directions between 10.0.1.1 and 10.0.1.254, but sending a packet from 10.0.10.2 to 10.0.1.1 goes to 10.0.10.1, gets aliased as 10.0.1.254->10.0.1.1, gets accepted and replied to by 10.0.1.1 and gets changed from 10.0.1.1->10.0.1.254 to 10.0.1.1->10.0.10.3 by the PacketAlias stuff and then disappears. Maybe the problem is with the forwarding code - where ip_input() calls ip_output(). I didn't realize this happened ! Surely, we should be remembering and zero'ing ip_divert_ignore before calling ip_output here, and restoring it afterwards. I'll check this when I get home this evening ! Brian Don't _EVER_ lose your sense of humour