From owner-freebsd-arch Fri May 11 18:46:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id B904B37B424; Fri, 11 May 2001 18:46:51 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA00722; Fri, 11 May 2001 18:46:44 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAh3a4vb; Fri May 11 18:46:35 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA24408; Fri, 11 May 2001 18:52:27 -0700 (MST) From: Terry Lambert Message-Id: <200105120152.SAA24408@usr06.primenet.com> Subject: Re: FreeBSD breaks sockets two ways... To: freebsd-net@FreeBSD.ORG Date: Sat, 12 May 2001 01:52:17 +0000 (GMT) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ] Are you sure it's failing to allocate the port? ] ] I had a similar problem in trying to connect to a service, but ] found out that aliasing an IP didn't add the arp entry in the routing ] table (local connections were failing). If I added the arp entry by ] hand, everything was happy (is IP aliasing a part of the scneario ] you're describing?). ] ] arp -s a.b.c.d 00:60:08:aa:aa:aa pub ] arp -s a.b.c.e 00:60:08:aa:aa:ab pub ] ] A tad annoying, but it seems to work (yeah, I know about the ] ethers file, but I refuse to use it). -sc Unfortunately, I'm very certain. I talked to Bill Paul about the gratuitous ARP problem last night; I was well aware of it; we added the ARP entries by hand to the target for the aliases on the source machine. I'm _positive_ on the outbound connection problem (the code fragment I attached should have done the job, and I've seen the FreeBSD code that's the problem, but am still pondering about how to fix it; I think I'll have to do two lookups, or hang a chain off a hash bucket indexed by IP last (instead of port). Hopefully, someone will get to this before I do. We've also tried by setting up the ARP table for the target machine, and then written the aforementioned BPF program to stage the connection attempts from a single client machine. We did the same thing from a second client on the same segment. The single client, two IP attempt failed, while the two machine attempt succeeded. The only difference in the packets that was reported by tcpdump was the source MAC address -- otherwise, they were byte-for-byte identical. So there is definitely a problem there with the index being by MAC instead of IP. Maybe this came in as part of the "aliased IP NFS client being seen as an attacker by the server" fix? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message