From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 07:30:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBA6016A4B3 for ; Sun, 19 Oct 2003 07:30:01 -0700 (PDT) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E44D43F93 for ; Sun, 19 Oct 2003 07:30:01 -0700 (PDT) (envelope-from joe@genius.tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id 13C9448B6; Sun, 19 Oct 2003 15:30:00 +0100 (BST) Date: Sun, 19 Oct 2003 15:29:59 +0100 From: Josef Karthauser To: Steve Wilson Message-ID: <20031019142959.GA84245@genius.tao.org.uk> References: <000201c3929a$557e5f30$6500a8c0@laptop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <000201c3929a$557e5f30$6500a8c0@laptop> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: Speedtouch internal PCI card support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 14:30:02 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2003 at 10:30:04PM +0100, Steve Wilson wrote: > I have a freebsd 4.8 machine currently using an old speedtouch USB > device to connect to DSL service. >=20 > This works fine so maybe I should leave it alone .. But heyho. I have > notice that Alcatel have now brought out a PCI version of the speedtouch > and I wondered if it is supported by the freebsd driver, but cannot find > any mention of it for freebsd, quite a bit for linux which suggests it > is supported. >=20 > Anybody know, or got it working already? >=20 > Thanks There is no support for it under FreeBSD at the moment. I've got several sites connected with the usb version and that seems to be the favoured connection type. Most ISPs are happier to sell an external usb box than an internal card. If there is linux support it would probably be possible to adapt this for Freebsd but it will only happen if there's a developer with enough time and motivation to make it happen. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iEYEARECAAYFAj+Sn+cACgkQXVIcjOaxUBZVrgCcCr2W0CA2S8N//UsPfIhpp2kp 7VEAnA256W5FAOrGuTAqsYDD1UFYgiZb =GEss -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 07:34:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6201316A4B3 for ; Sun, 19 Oct 2003 07:34:21 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3B8C43F3F for ; Sun, 19 Oct 2003 07:34:17 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from cpc3-ches1-4-0-cust213.lutn.cable.ntl.com ([213.105.213.213]) by mta03-svc.ntlworld.comESMTP <20031019143416.VSSQ6394.mta03-svc.ntlworld.com@cpc3-ches1-4-0-cust213.lutn.cable.ntl.com> for ; Sun, 19 Oct 2003 15:34:16 +0100 From: Dan To: freebsd-net@freebsd.org Date: Sun, 19 Oct 2003 15:32:40 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310191532.40136.dan@ntlbusiness.com> Subject: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 14:34:21 -0000 Hi there. I hope you can help. I've been trying and trying for days to try and get these rules sorted, as whenever they're used, my laptop (which is using my FreeBSD box as a gateway) cannot access the Internet. If I use a "small" set of rules, such as: fwcmd="/sbin/ipfw" $fwcmd -f flush $fwcmd add divert natd all from any to any via sis0 $fwcmd add allow all from any to any it works fine. sis0 is the Ethernet that has the business cable modem attached to it, and sis1 is the Ethernet that has the wireless Access point (netgear HE102) connected to it which the laptop (using a HA501 netgear card) connects to. It's taken me so long just to get this far! I looked through the standard /etc/rc.firewall and that's how I managed to get the priorities for the ones i've done. But if you can tell me where I'm going wrong (as I'm going mind-boggled now with this!) it'd be absolutely gratefully appreciated. Many thanks! The rules: # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Divert all packets through the tunnel interface. $fwcmd add 50 divert natd all from any to any via sis0 # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add pass tcp from any to any established # Allow all localhost connections ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # Allow all connections from my network card that I initiate $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state $fwcmd add allow all from 192.168.0.0/24 to any # Everyone on the Internet is allowed to connect to the following # services on the machine. This example specifically allows connections # to sshd and a webserver. $fwcmd add allow tcp from any to any established $fwcmd add allow tcp from any to me 80 setup $fwcmd add allow tcp from any to me 22 setup # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to me 113 in recv any # Enable ICMP: remove type 8 if you don't want your host to be pingable $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Deny all the rest. $fwcmd add deny log ip from any to any From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 08:31:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 101E116A4DD for ; Sun, 19 Oct 2003 08:31:11 -0700 (PDT) Received: from www.missl.cs.umd.edu (www.missl.cs.umd.edu [128.8.126.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBD8643FBF for ; Sun, 19 Oct 2003 08:31:09 -0700 (PDT) (envelope-from jtm@cs.umd.edu) Received: from www.missl.cs.umd.edu (localhost.missl.cs.umd.edu [127.0.0.1]) by www.missl.cs.umd.edu (8.12.9/8.12.3) with ESMTP id h9JFfJK0098941 for ; Sun, 19 Oct 2003 11:41:19 -0400 (EDT) (envelope-from jtm@cs.umd.edu) Received: from localhost (jtm@localhost)h9JFfJ6S098938 for ; Sun, 19 Oct 2003 11:41:19 -0400 (EDT) X-Authentication-Warning: www.missl.cs.umd.edu: jtm owned process doing -bs Date: Sun, 19 Oct 2003 11:41:19 -0400 (EDT) From: Justin Ma X-X-Sender: jtm@www.missl.cs.umd.edu To: freebsd-net@freebsd.org Message-ID: <20031019113754.G98459-100000@www.missl.cs.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: multiple loopback interfaces in 5-current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 15:31:11 -0000 Is it possible to raise multiple loopback interfaces in 5-current? Justin From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 08:36:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F282E16A4B3 for ; Sun, 19 Oct 2003 08:36:23 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB8A543F85 for ; Sun, 19 Oct 2003 08:36:22 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 00704653AD; Sun, 19 Oct 2003 16:36:21 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 91258-05; Sun, 19 Oct 2003 16:36:20 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 63EA465375; Sun, 19 Oct 2003 16:36:20 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 37F0533; Sun, 19 Oct 2003 16:36:14 +0100 (BST) Date: Sun, 19 Oct 2003 16:36:13 +0100 From: Bruce M Simpson To: Justin Ma Message-ID: <20031019153613.GE10990@saboteur.dek.spc.org> Mail-Followup-To: Justin Ma , freebsd-net@freebsd.org References: <20031019113754.G98459-100000@www.missl.cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031019113754.G98459-100000@www.missl.cs.umd.edu> cc: freebsd-net@freebsd.org Subject: Re: multiple loopback interfaces in 5-current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 15:36:24 -0000 On Sun, Oct 19, 2003 at 11:41:19AM -0400, Justin Ma wrote: > Is it possible to raise multiple loopback interfaces in 5-current? ifconfig loN create. BMS From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 08:53:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F43016A4B3 for ; Sun, 19 Oct 2003 08:53:58 -0700 (PDT) Received: from blacklamb.mykitchentable.net (207-173-254-228.bras01.elk.ca.frontiernet.net [207.173.254.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75D5043FA3 for ; Sun, 19 Oct 2003 08:53:56 -0700 (PDT) (envelope-from drew@mykitchentable.net) Received: from bigdaddy (unknown [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with SMTP id EC7693BF3BA; Sun, 19 Oct 2003 08:53:54 -0700 (PDT) Message-ID: <009501c39659$338fe570$0301a8c0@bigdaddy> From: "Drew Tomlinson" To: "Dan" , References: <200310191532.40136.dan@ntlbusiness.com> Date: Sun, 19 Oct 2003 08:53:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 15:53:58 -0000 ----- Original Message ----- From: "Dan" To: Sent: Sunday, October 19, 2003 7:32 AM Subject: IPFW. > Hi there. > I hope you can help. > I've been trying and trying for days to try and get these rules sorted, as > whenever they're used, my laptop (which is using my FreeBSD box as a gateway) > cannot access the Internet. > If I use a "small" set of rules, such as: > > fwcmd="/sbin/ipfw" > $fwcmd -f flush > $fwcmd add divert natd all from any to any via sis0 > $fwcmd add allow all from any to any > > it works fine. > sis0 is the Ethernet that has the business cable modem attached to it, and > sis1 is the Ethernet that has the wireless Access point (netgear HE102) > connected to it which the laptop (using a HA501 netgear card) connects to. > It's taken me so long just to get this far! I looked through the standard > /etc/rc.firewall and that's how I managed to get the priorities for the ones > i've done. But if you can tell me where I'm going wrong (as I'm going > mind-boggled now with this!) it'd be absolutely gratefully appreciated. > > Many thanks! > > The rules: > > # Define the firewall command (as in /etc/rc.firewall) for easy > # reference. Helps to make it easier to read. > fwcmd="/sbin/ipfw" > > # Force a flushing of the current rules before we reload. > $fwcmd -f flush > > # Divert all packets through the tunnel interface. > $fwcmd add 50 divert natd all from any to any via sis0 > > # Allow all connections that have dynamic rules built for them, > # but deny established connections that don't have a dynamic rule. > # See ipfw(8) for details. > $fwcmd add check-state > $fwcmd add pass tcp from any to any established I'm certainly no expert. However, you might have a problem because you are defining rule numbers. By default, ipfw increments it's rules by 100 if you don't define them. So your first rule is 100, the second 200, etc. But you have defined your first rule as rule 50. Then the 'check-state' and 'established' rules don't have rule numbers defined so I assume they will be numbered 100 and 200 respectively. > # Allow all localhost connections > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny all from any to 127.0.0.0/8 Now you define these rules as 100 and 200. I suspect you are overwriting your previous 'check-state' and 'established' rules. > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > > # Allow all connections from my network card that I initiate > $fwcmd add allow tcp from me to any out xmit any setup keep-state > $fwcmd add deny tcp from me to any This might be a problem. Seems like it would prevent your gateway from communicating with any other node. > $fwcmd add allow ip from me to any out xmit any keep-state > $fwcmd add allow all from 192.168.0.0/24 to any > > # Everyone on the Internet is allowed to connect to the following > # services on the machine. This example specifically allows connections > # to sshd and a webserver. > $fwcmd add allow tcp from any to any established > $fwcmd add allow tcp from any to me 80 setup > $fwcmd add allow tcp from any to me 22 setup > > # This sends a RESET to all ident packets. > $fwcmd add reset log tcp from any to me 113 in recv any > > # Enable ICMP: remove type 8 if you don't want your host to be pingable > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 > > # Deny all the rest. > $fwcmd add deny log ip from any to any The best way I have found to troubleshoot firewall rules is to turn on logging and watch the log real time (tail -f /var/log/security) while attempting connections. I have also had a lot of trouble with 'setup' not doing what I think it's supposed to (I obviously don't understand it) so you might focus on those rules when troubleshooting. Good luck! Drew From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 08:59:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF5FE16A4B3 for ; Sun, 19 Oct 2003 08:59:14 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E79543F3F for ; Sun, 19 Oct 2003 08:59:14 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9JFxDYL047128; Sun, 19 Oct 2003 11:59:13 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9JFxD5U047127; Sun, 19 Oct 2003 11:59:13 -0400 (EDT) (envelope-from barney) Date: Sun, 19 Oct 2003 11:59:13 -0400 From: Barney Wolff To: Dan Message-ID: <20031019155913.GA46989@pit.databus.com> References: <200310191532.40136.dan@ntlbusiness.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310191532.40136.dan@ntlbusiness.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 15:59:15 -0000 On Sun, Oct 19, 2003 at 03:32:40PM +0100, Dan wrote: > Hi there. > I hope you can help. > I've been trying and trying for days to try and get these rules sorted, as > whenever they're used, my laptop (which is using my FreeBSD box as a gateway) > cannot access the Internet. I suggest you put "log" on all your denies, and by ipfw -atde list see which rules are stopping the packets. Aside from whether the ruleset works, it seems inconsistent. If you're going to keep state, you should not be allowing tcp established, but instead setting up state on setup, both ways. btw, "pass" means allow, did you mean "deny"? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 09:00:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B470D16A4B3 for ; Sun, 19 Oct 2003 09:00:34 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C0843F3F for ; Sun, 19 Oct 2003 09:00:33 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from cpc3-ches1-4-0-cust213.lutn.cable.ntl.com ([213.105.213.213]) by mta03-svc.ntlworld.comESMTP <20031019160030.CNUE6394.mta03-svc.ntlworld.com@cpc3-ches1-4-0-cust213.lutn.cable.ntl.com>; Sun, 19 Oct 2003 17:00:30 +0100 From: Dan To: "Drew Tomlinson" Date: Sun, 19 Oct 2003 16:59:04 +0100 User-Agent: KMail/1.5 References: <200310191532.40136.dan@ntlbusiness.com> <009501c39659$338fe570$0301a8c0@bigdaddy> In-Reply-To: <009501c39659$338fe570$0301a8c0@bigdaddy> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310191659.04893.dan@ntlbusiness.com> cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 16:00:34 -0000 On Sunday 19 October 2003 4:53 pm, you wrote: > tail -f /var/log/security Hi - I don't see anything happening when I type that (or read the file afterward) of when the laptop attempts to connect to something. This is very, very strange! Yet, it works fine with those silly little rules!!! Thanks again for your reply. From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 09:06:05 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36ABB16A4B3 for ; Sun, 19 Oct 2003 09:06:05 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id F211F43FAF for ; Sun, 19 Oct 2003 09:06:03 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from cpc3-ches1-4-0-cust213.lutn.cable.ntl.com ([213.105.213.213]) by mta03-svc.ntlworld.comESMTP <20031019160601.DAMO6394.mta03-svc.ntlworld.com@cpc3-ches1-4-0-cust213.lutn.cable.ntl.com>; Sun, 19 Oct 2003 17:06:01 +0100 From: Dan To: Barney Wolff Date: Sun, 19 Oct 2003 17:04:42 +0100 User-Agent: KMail/1.5 References: <200310191532.40136.dan@ntlbusiness.com> <20031019155913.GA46989@pit.databus.com> In-Reply-To: <20031019155913.GA46989@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310191704.42446.dan@ntlbusiness.com> cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 16:06:05 -0000 On Sunday 19 October 2003 4:59 pm, you wrote: > On Sun, Oct 19, 2003 at 03:32:40PM +0100, Dan wrote: > > Hi there. > > I hope you can help. > > I've been trying and trying for days to try and get these rules sorted, > > as whenever they're used, my laptop (which is using my FreeBSD box as a > > gateway) cannot access the Internet. > > I suggest you put "log" on all your denies, and by ipfw -atde list > see which rules are stopping the packets. > > Aside from whether the ruleset works, it seems inconsistent. If you're > going to keep state, you should not be allowing tcp established, but > instead setting up state on setup, both ways. btw, "pass" means allow, > did you mean "deny"? Hi there. Thank you very much for your reply. I couldn't see anything obvious in ipfw -atde list - and I tried requestnig a new page from the laptop, but saw nothing new there. I've taken what you said -- and as far as I can understand (sorry..this is really hard to me) I've come up with: Is this better? thanks again! # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Divert all packets through the tunnel interface. $fwcmd add 50 divert natd all from any to any via sis0 # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add pass tcp from any to any keep-state # Allow all localhost connections ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny log all from any to 127.0.0.0/8 ${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any # Allow all connections from my network card that I initiate $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny log tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state $fwcmd add allow all from 192.168.0.0/24 to any # Everyone on the Internet is allowed to connect to the following # services on the machine. This example specifically allows connections # to sshd and a webserver. $fwcmd add allow tcp from any to any keep-state $fwcmd add allow tcp from any to me 80 setup $fwcmd add allow tcp from any to me 22 setup # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to me 113 in recv any # Enable ICMP: remove type 8 if you don't want your host to be pingable $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Deny all the rest. $fwcmd add deny log ip from any to any From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 09:15:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8100016A4B3 for ; Sun, 19 Oct 2003 09:15:39 -0700 (PDT) Received: from blacklamb.mykitchentable.net (207-173-254-228.bras01.elk.ca.frontiernet.net [207.173.254.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DE643F75 for ; Sun, 19 Oct 2003 09:15:38 -0700 (PDT) (envelope-from drew@mykitchentable.net) Received: from bigdaddy (unknown [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with SMTP id 1B9F83BF372; Sun, 19 Oct 2003 09:15:38 -0700 (PDT) Message-ID: <00ca01c3965c$3beaff40$0301a8c0@bigdaddy> From: "Drew Tomlinson" To: "Dan" References: <200310191532.40136.dan@ntlbusiness.com><009501c39659$338fe570$0301a8c0@bigdaddy> <200310191659.04893.dan@ntlbusiness.com> Date: Sun, 19 Oct 2003 09:15:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 16:15:39 -0000 ----- Original Message ----- From: "Dan" To: "Drew Tomlinson" Cc: Sent: Sunday, October 19, 2003 8:59 AM > On Sunday 19 October 2003 4:53 pm, you wrote: > > tail -f /var/log/security > > Hi - I don't see anything happening when I type that (or read the file > afterward) of when the laptop attempts to connect to something. /var/log/security is the default place ipfw logs. I just checked my kernel conf file and found you need this line to include logging: options IPFIREWALL_VERBOSE #enable logging to syslogd(8) If you don't have it, add it and recompile. > This is very, very strange! > Yet, it works fine with those silly little rules!!! > > Thanks again for your reply. You're welcome. I know how frustrating it can be. But when you get it right, it's all worth it. :) Drew From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 09:22:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 501AD16A4B3 for ; Sun, 19 Oct 2003 09:22:34 -0700 (PDT) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 472C143FB1 for ; Sun, 19 Oct 2003 09:22:33 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from cpc3-ches1-4-0-cust213.lutn.cable.ntl.com ([213.105.213.213]) by mta06-svc.ntlworld.comESMTP <20031019162228.FJKT12263.mta06-svc.ntlworld.com@cpc3-ches1-4-0-cust213.lutn.cable.ntl.com>; Sun, 19 Oct 2003 17:22:28 +0100 From: Dan To: Barney Wolff Date: Sun, 19 Oct 2003 17:21:06 +0100 User-Agent: KMail/1.5 References: <200310191532.40136.dan@ntlbusiness.com> <200310191704.42446.dan@ntlbusiness.com> <20031019161948.GB46989@pit.databus.com> In-Reply-To: <20031019161948.GB46989@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310191721.06509.dan@ntlbusiness.com> cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 16:22:34 -0000 On Sunday 19 October 2003 5:19 pm, you wrote: > First, as somebody else suggested, either use numbers on every rule > or none at all. Second, you want to keep-state only on setup, not > on every tcp packet going in either direction, as that will be wide > open. Third, you don't seem to have any rule allowing udp, so dns > lookups are not likely to work. Fourth, did you actually put the > rules into effect? If so, you should see entries in the logs when > packets are denied. Fifth, the rule with 192.168 in it will never > fire, as the address will have been translated by natd before it > gets there. > > Doing ipfw list will show you the rules that exist, and ipfw -atde list > will show you which rules have matched and when. Hmm .. Ok thanks again for your reply. I probably understood 5% of that though ;) I will go and search on google for some of the pointers you've given me .. but I am finding this really hard..it took me absolutely ages just to get that far. Once again thanks for your help! From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 10:24:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4453516A4B3 for ; Sun, 19 Oct 2003 10:24:04 -0700 (PDT) Received: from internal.mail.uk.tiscali.com (internal.mail.uk.tiscali.com [212.74.96.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BAA143FBF for ; Sun, 19 Oct 2003 10:24:03 -0700 (PDT) (envelope-from chris.scott@uk.tiscali.com) Received: from [10.44.16.196] (helo=viper) by internal.mail.uk.tiscali.com with esmtp (Exim 4.12) id 1ABHHd-0001vI-00; Sun, 19 Oct 2003 18:24:01 +0100 Message-ID: <02d601c39665$c8f664c0$c4102c0a@viper> From: "chris scott" To: "Dan" , "Barney Wolff" References: <200310191532.40136.dan@ntlbusiness.com><200310191704.42446.dan@ntlbusiness.com><20031019161948.GB46989@pit.databus.com> <200310191721.06509.dan@ntlbusiness.com> Date: Sun, 19 Oct 2003 18:23:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-net@freebsd.org Subject: Re: IPFW. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2003 17:24:04 -0000 here is a simple firewall that should do what you need and be statefull they key thing to remember is not to add any stateful stuff ( keep-state rules ) before the divert rule for natd as it really screws things up. Note i have put in a fairly open static rule for ssh before the divert rule, you may want to tighten this, along with changing the internal network ranges and interfaces. The reasn for the statc ssh rule is to safegard against the case where natd dies. If it does you are totally locked out of the box due to all the traffic disappearing into the divert rule, not good. Hope this helps some. #!/usr/local/bin/bash fwcmd="/sbin/ipfw " ${fwcmd} -q flush extif="tuno" intif="xl0" intnet="192.168.0.0/24" # speedup for rule processing ${fwcmd} add skipto 20000 all from any to any via ${intif} ${fwcmd} add skipto 30000 all from any to any via lo0 # lets give ssh a bit more protection ${fwcmd} add allow tcp from any 22 to any out via ${extif} ${fwcmd} add allow tcp from any to any 22 in via ${extif} # stop priv networks being spoofed ${fwcmd} add deny all from any to 172.16.0.0/12 in via ${extif} ${fwcmd} add deny all from any to 10.0.0.0/8 in via ${extif} ${fwcmd} add deny all from any to 192.168.0.0/16 in via ${extif} # let natd do its biz ${fwcmd} add divert natd all from any to any via ${extif} # let connections out ${fwcmd} add allow tcp from any to any out via ${extif} keep-state ${fwcmd} add allow udp from any to any out via ${extif} keep-state ${fwcmd} add allow icmp from any to any out via ${extif} keep-state # let priv networks thru now we are nated ${fwcmd} add allow all from any to 172.16.0.0/12 in via ${extif} ${fwcmd} add allow all from any to 10.0.0.0/8 in via ${extif} ${fwcmd} add allow all from any to 192.168.0.0/16 in via ${extif} # and bog off to the rest of you ${fwcmd} add deny log all from any to any via ${extif} ############################################################################ ###### # lock down internal interface, also acts as a 2nd pass firewall for nated traffic ############################################################################ ###### ${fwcmd} add 20000 tcp from ${intnet} 22 to ${intnet} out via ${intif} ${fwcmd} add allow tcp from ${intnet} to ${intnet} 22 in via ${intif} ${fwcmd} add allow tcp from ${intnet} to any keep-state in via ${intif} ${fwcmd} add allow udp from ${intnet} to any keep-state in via ${intif} ${fwcmd} add allow icmp from ${intnet} to any keep-state in via ${intif} ${fwcmd} add deny all from any to any via ${intif} ${fwcmd} add 30000 allow ip from any to any via lo0 ~ ----- Original Message ----- From: "Dan" To: "Barney Wolff" Cc: Sent: Sunday, October 19, 2003 5:21 PM Subject: Re: IPFW. > On Sunday 19 October 2003 5:19 pm, you wrote: > > First, as somebody else suggested, either use numbers on every rule > > or none at all. Second, you want to keep-state only on setup, not > > on every tcp packet going in either direction, as that will be wide > > open. Third, you don't seem to have any rule allowing udp, so dns > > lookups are not likely to work. Fourth, did you actually put the > > rules into effect? If so, you should see entries in the logs when > > packets are denied. Fifth, the rule with 192.168 in it will never > > fire, as the address will have been translated by natd before it > > gets there. > > > > Doing ipfw list will show you the rules that exist, and ipfw -atde list > > will show you which rules have matched and when. > > Hmm .. Ok thanks again for your reply. > I probably understood 5% of that though ;) > I will go and search on google for some of the pointers you've given me .. but > I am finding this really hard..it took me absolutely ages just to get that > far. > > Once again thanks for your help! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 22:35:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA55916A4BF for ; Thu, 21 Aug 2003 22:35:04 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6058D43FBF for ; Thu, 21 Aug 2003 22:35:04 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id EF4975B64C; Thu, 21 Aug 2003 22:35:02 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Bruce M Simpson , freebsd-net@freebsd.org User-Agent: KMail/1.5.2 References: <20030821142201.GE1417@spc.org> In-Reply-To: <20030821142201.GE1417@spc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308212235.03055.wes@softweyr.com> Subject: Re: IP_ONESBCAST and upcoming RELENG_4_9 freeze X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 22 Aug 2003 05:35:05 -0000 X-Original-Date: Thu, 21 Aug 2003 22:35:03 -0700 X-List-Received-Date: Fri, 22 Aug 2003 05:35:05 -0000 On Thursday 21 August 2003 07:22 am, Bruce M Simpson wrote: > Hi all, > > Does anyone have any major objections to an MFC'ing of IP_ONESBCAST > which I committed yesterday before the upcoming 4.9 code freeze next > Monday? > > If you could let me know before, say, Saturday PM BST, that would be > great. Your change makes it so that broadcasts sent to 255.255.255.255 will be transmitted on all interfaces marked with a ONES_BCAST flag, right? A nice solution to the problem; I was gonna hack it so such packets were sent on all interfaces with IFF_BROADCAST. I like your solution better. I'm happy to know that will be in 5.2 and I have PR or two to assign over to you so you can close them. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 00:34:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5CD516A4B3; Wed, 1 Oct 2003 00:34:29 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id F099C43FF5; Wed, 1 Oct 2003 00:34:27 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h917YM623152; Wed, 1 Oct 2003 09:34:23 +0200 (MEST) From: Harti Brandt To: Brooks Davis In-Reply-To: <20030930182902.GE31908@Odin.AC.HMC.Edu> Message-ID: <20031001093334.S113@beagle.fokus.fraunhofer.de> References: <20030930174815.GC31908@Odin.AC.HMC.Edu> <20030930182902.GE31908@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: net@freebsd.org Subject: Re: adding if_dev member to struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 01 Oct 2003 07:34:29 -0000 X-Original-Date: Wed, 1 Oct 2003 09:34:22 +0200 (CEST) X-List-Received-Date: Wed, 01 Oct 2003 07:34:29 -0000 On Tue, 30 Sep 2003, Brooks Davis wrote: BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>phy feature is not enabled when it is attached to some MACs. A messier BD>example is in the new ATM code where interfaces are looked up by name. Where is this? harti BD>In all cases, usage is limited to a narrow set of code, but it's not BD>generally in the driver itself (in those cases, the softc is often BD>already used, say to hold the unit). BD> BD>-- Brooks BD> BD> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 02:02:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 135C216A4B3 for ; Mon, 20 Oct 2003 02:02:59 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9AFA43F75 for ; Mon, 20 Oct 2003 02:02:56 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])h9K92rs6016977 for ; Mon, 20 Oct 2003 17:02:53 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <3F93A4B5.E5DAF46@kuzbass.ru> Date: Mon, 20 Oct 2003 17:02:45 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: routed(8) problem with route aggregation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 09:02:59 -0000 Hi! It seems there is a bug in routed(8): it aggregates routes in its RIPv2 responses even when /etc/gateways contains: ripv2 no_ag no_super_ag rtquery -t dump always shows full RIP2 table so routed(8) has full information. However, rtquery -n shows only small part of RIP2 table when there is a default route with the same interface as specific routes but default has smaller hopcount. The worst of it is that is announces only default in such case. Please explain if it is expected or I should fill a PR. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 03:46:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CF8816A4B3; Mon, 20 Oct 2003 03:46:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20FF143FAF; Mon, 20 Oct 2003 03:46:22 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1ABXYE-0003L0-00; Mon, 20 Oct 2003 12:46:14 +0200 Received: from [217.227.154.167] (helo=max2400) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ABXYE-0000OL-00; Mon, 20 Oct 2003 12:46:14 +0200 Date: Mon, 20 Oct 2003 12:46:08 +0200 From: Max Laier X-Mailer: The Bat! (v2.00) UNREG / CD5BF9353B3B7091 Organization: n/a X-Priority: 3 (Normal) Message-ID: <132712203.20031020124608@love2party.net> To: Andre Guibert de Bruet In-Reply-To: <20031019214512.F54982@alpha.siliconlandmark.com> References: <20031019214512.F54982@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: net@freebsd.org Subject: Re: Anyone working on a port of OpenBSD's CARP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Max Laier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 10:46:23 -0000 Hello Andre, Monday, October 20, 2003, 4:07:40 AM, you wrote: > I was just wondering if anyone was currently having a look at the > possibility of porting OpenBSD's CARP. I have a bit of free time on my > hands but wouldn't want to duplicate anyone's work... we are working on a pf / pfsync port. There are crosslinks between those two so it would be nice if you got into contact with us. I was about to look into CARP as well (after following the discussion in OpenBSD for a while) ... Maybe that's something for net@ as well? CCed. -- Best regards, Max mailto:max@love2party.net From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 04:47:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 021CD16A4B3 for ; Mon, 20 Oct 2003 04:47:11 -0700 (PDT) Received: from queue.unet.com.mk (queue.unet.com.mk [212.13.64.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC43E43FA3 for ; Mon, 20 Oct 2003 04:47:05 -0700 (PDT) (envelope-from aleksandar@unet.com.mk) Received: from b166-er.unet.com.mk (ppp25.unet.com.mk [212.13.64.90] (may be forged)) by queue.unet.com.mk (8.11.6/8.11.6) with SMTP id h9KAVDq17125 for ; Mon, 20 Oct 2003 12:31:13 +0200 Date: Mon, 20 Oct 2003 13:49:38 +0200 From: Aleksandar Simonovski To: freebsd-net@freebsd.org Message-Id: <20031020134938.2c8deee4.aleksandar@unet.com.mk> Organization: Unet X-Mailer: Sylpheed version 0.9.4-gtk2-20030802 (GTK+ 2.2.4; i686-pc-linux-gnu) X-Operating-System: Slackware 9.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: freebsd+natd+ipfw+DENY P2P X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 11:47:11 -0000 Hi, i wanna allow SSH,SMTP,DNS,WWW,POP3 and nothing else :) on my freebsd gateway, my local net is 192.168.1.0/24 and nat is working fine the point is the deny any P2P applications, and allow normal trafic like SMTP,POP3,WWW,FTP,ICQ. So any suggestions how to do this with ipfw and check-state,established,etc.. Just some examples or any link to them or any HOWTO's because i'm already reading the docs but i'm lettle confused Thank you, Aleksandar From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 04:49:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F26B16A4B3; Mon, 20 Oct 2003 04:49:04 -0700 (PDT) Received: from famine.e-raist.com (69-30-69-105.dq1mn.easystreet.com [69.30.69.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ED5643FBD; Mon, 20 Oct 2003 04:49:03 -0700 (PDT) (envelope-from aburke@nullplusone.com) Received: from thebe (12-224-164-145.client.attbi.com [12.224.164.145]) (authenticated bits=0) by famine.e-raist.com (8.12.8/8.12.8) with ESMTP id h9KBmx7S082591; Mon, 20 Oct 2003 04:49:02 -0700 (PDT) From: "Aaron Burke" To: , , Date: Mon, 20 Oct 2003 04:48:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E8_01C396C5.748FCA10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20031013191044.M25865@yaknetworks.com> Importance: Normal Subject: RE: good solution for VPN? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 11:49:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E8_01C396C5.748FCA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Anyone got a good solution for a freebsd VPN server to windows > clients? Tried > poptop, but not really working for me any other ideas? Thanks in advance. I currently use mpd to run VPN links. The windows machines work the same as if I had a Windows NT/2000/Server 2003 server running the links. I installed the 'mpd' system from ports/net/mpd. Then created the following files in /usr/local/etc/mpd/. mpd.conf mpd.links mpd.secret The installation of the port did not seem to create the files with the appropriate ownerships. So make sure that your files are owned by root:wheel . mpd.conf basically tells mpd (Multi-link PPP daemon) what to load, and the options that each connection needs. mpd.links basically tells mpd what to do with each connection. This is usually a pretty simple file. and mpd.secret tells mpd what the valid users and passwords can be. This file should only be readable by root. Take a look at mpd.secret.sample . I am also including my config files (modified for my security) for you to take a look at. And for the list that may read this as well, I have converted the files to the Microsoft crlf format. All addresses that are listed as 1.2.3.4 gets swapped out with your public internet address. And for firewall rules, if they apply, you need to make sure that port 1723 gets redirected to your VPN server. (even if its the local machine) And finally, you may want to make sure that the following file exists /usr/local/etc/rc.d/mpd.sh with executable permissions set if you want the server to load itself on startup. If it doesnt exist it is attached to this email as well. And yes, I realise that getting a VPN up and running can be a pain in the but. But if you have any questions about it feel free to get in touch with me via email. > > Thanks, And for the sake of everyone else, this question really should be directed to -net. So I request that further discussion on the matter be moved there. This list is for people that wish to discuss comments and report bugs etc about freebsd-stable. > > Jake Aaron Burke aburke@nullplusone.com ------=_NextPart_000_00E8_01C396C5.748FCA10 Content-Type: application/octet-stream; name="mpd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.conf" default: load pptp0 load pptp1 load pptp2 load pptp3 pptp0: new -i ng0 pptp0 pptp0 set iface disable on-demand set bundle disable multilink set iface enable proxy-arp set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 1.2.3.4/32 192.168.0.50/32 set ipcp dns 192.168.0.1 set ipcp nbns 192.168.0.1 set bundle enable compression # set bundle enable encryption set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle yes crypt-reqd pptp1: new -i ng1 pptp1 pptp1 set iface disable on-demand set bundle disable multilink set iface enable proxy-arp set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 1.2.3.4/32 192.168.0.51/32 set ipcp dns 192.168.0.1 set ipcp nbns 192.168.0.1 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle yes crypt-reqd pptp2: new -i ng2 pptp2 pptp2 set iface disable on-demand set bundle disable multilink set iface enable proxy-arp set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 1.2.3.4/32 192.168.0.52/32 set ipcp dns 192.168.0.1 set ipcp nbns 192.168.0.1 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle yes crypt-reqd pptp3: new -i ng3 pptp3 pptp3 set iface disable on-demand set bundle disable multilink set iface enable proxy-arp set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 1.2.3.4/32 192.168.0.53/32 set ipcp dns 192.168.0.1 set ipcp nbns 192.168.0.1 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle yes crypt-reqd ------=_NextPart_000_00E8_01C396C5.748FCA10 Content-Type: application/octet-stream; name="mpd.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.sh" #! /bin/sh pidf=/var/run/mpd.pid case "$1" in # broken - attempting fix # start|"") mpd -b;; # works, But I want to know about its startup # start|"") /usr/local/sbin/mpd -b;; start|"") /usr/local/sbin/mpd -b && echo -n ' mpd';; stop) if [ -r $pidf ]; then kill -TERM `cat $pidf` fi;; *) echo "usage: $0 [start|stop]" 1>&2; exit 1;; esac ------=_NextPart_000_00E8_01C396C5.748FCA10 Content-Type: application/octet-stream; name="mpd.secret" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.secret" # NOTE: this file should not be readable by anyone except root! # each user is limited to one ip address to make my job as an admin # a lot easier. # # login-name password (optional ip address list) aburke "abcd1234" 192.168.0.50 ben "god" 192.168.0.51 dorin "2424" 192.168.0.63 ------=_NextPart_000_00E8_01C396C5.748FCA10 Content-Type: application/octet-stream; name="mpd.links" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.links" pptp0: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp1: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp3: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate ------=_NextPart_000_00E8_01C396C5.748FCA10-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 10:47:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE62516A4B3 for ; Mon, 20 Oct 2003 10:47:52 -0700 (PDT) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by mx1.FreeBSD.org (Postfix) with SMTP id F33A343F3F for ; Mon, 20 Oct 2003 10:47:51 -0700 (PDT) (envelope-from saratchandra_a@yahoo.com) Message-ID: <20031020174751.60464.qmail@web20805.mail.yahoo.com> Received: from [61.95.178.129] by web20805.mail.yahoo.com via HTTP; Mon, 20 Oct 2003 10:47:51 PDT Date: Mon, 20 Oct 2003 10:47:51 -0700 (PDT) From: sarat chandra Annadata To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org cc: mgrooms@shrew.net cc: julian@elischer.org Subject: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 17:47:53 -0000 Hai, I am need of some urgent techinical help to pull me out of a little problem. I have been trying to broadcast a UDP packet(actually it is a DHCP offer packet) but havent' successfully done it sofar. The following is the descripttion about how I have been trying to do it. 1) I am creating a socket with sock_dgram option. 2)Next I am filling up the sockaddr_in structure, with IP address 255.255.255.255 and port number as DHCP client port number. 3)I am using the setsockopt call with at SOL_SOCKET level, with SO_BROADCAST FLAG. This call is not successfully returning. moreover I am successfully setting the flag at the IP-level in either case my send or sendto system calls fail. I want some guidance regarding this, I want to use only socket interface, in UNIX with C. Please pull me out of this, and I shall be grateful to you. A working piece of code will be of great help Thank you, Sincerely Sarat Chandra. --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 10:47:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8A9C16A4BF for ; Mon, 20 Oct 2003 10:47:52 -0700 (PDT) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by mx1.FreeBSD.org (Postfix) with SMTP id 007A143FDD for ; Mon, 20 Oct 2003 10:47:52 -0700 (PDT) (envelope-from saratchandra_a@yahoo.com) Message-ID: <20031020174751.60464.qmail@web20805.mail.yahoo.com> Received: from [61.95.178.129] by web20805.mail.yahoo.com via HTTP; Mon, 20 Oct 2003 10:47:51 PDT Date: Mon, 20 Oct 2003 10:47:51 -0700 (PDT) From: sarat chandra Annadata To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org cc: mgrooms@shrew.net cc: julian@elischer.org Subject: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 17:47:53 -0000 Hai, I am need of some urgent techinical help to pull me out of a little problem. I have been trying to broadcast a UDP packet(actually it is a DHCP offer packet) but havent' successfully done it sofar. The following is the descripttion about how I have been trying to do it. 1) I am creating a socket with sock_dgram option. 2)Next I am filling up the sockaddr_in structure, with IP address 255.255.255.255 and port number as DHCP client port number. 3)I am using the setsockopt call with at SOL_SOCKET level, with SO_BROADCAST FLAG. This call is not successfully returning. moreover I am successfully setting the flag at the IP-level in either case my send or sendto system calls fail. I want some guidance regarding this, I want to use only socket interface, in UNIX with C. Please pull me out of this, and I shall be grateful to you. A working piece of code will be of great help Thank you, Sincerely Sarat Chandra. --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 10:57:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD9CC16A4B3 for ; Mon, 20 Oct 2003 10:57:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE8143F3F for ; Mon, 20 Oct 2003 10:57:14 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (keg.isi.edu [128.9.160.108]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9KHvCj28234; Mon, 20 Oct 2003 10:57:12 -0700 (PDT) Message-ID: <3F9421F8.7050101@isi.edu> Date: Mon, 20 Oct 2003 10:57:12 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sarat chandra Annadata References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> In-Reply-To: <20031020174751.60464.qmail@web20805.mail.yahoo.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020908000500030803050902" cc: freebsd-net@freebsd.org cc: mgrooms@shrew.net cc: julian@elischer.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 17:57:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020908000500030803050902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit W. Richard Stevens UNIX Network Programming Prentice Hall sarat chandra Annadata wrote: > Hai, > I am need of some urgent techinical help to pull me out of a little problem. I have been > trying to broadcast a UDP packet(actually it is a DHCP offer packet) but > havent' successfully done it sofar. The following is the descripttion > about how I have been trying to do it. > 1) I am creating a socket with sock_dgram option. > 2)Next I am filling up the sockaddr_in structure, with IP address > 255.255.255.255 and port number as DHCP client port number. > 3)I am using the setsockopt call with at SOL_SOCKET level, with > SO_BROADCAST FLAG. > This call is not successfully returning. > moreover I am successfully setting the flag at the IP-level in either > case my send or sendto system calls fail. > > I want some guidance regarding this, I want to use only socket > interface, in UNIX with C. > Please pull me out of this, and I shall be grateful to you. > A working piece of code will be of great help > Thank you, > > Sincerely > Sarat Chandra. > > > --------------------------------- > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Lars Eggert USC Information Sciences Institute --------------ms020908000500030803050902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwp2bzANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwMTE3MjkyOVoX DTA0MDczMTE3MjkyOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMb7PuLXnwV+45vwlkgogdSijd5HVqUB14bWvoK0 MjWPnkLPMDMDEezdsMG1BPiZyNeqXlJJtEgdAK8H2Mc9/qLeJUq3CoAeD6Wrjq4QaxJBXgdS KcGDeQAZSDgwUJS9vx9+cXJVfLyOYxJ+CLBcO/eu8PvSi17lk6oeAbrskSGDu/Xi1o2SC4Qm l69k8xcZQEMQDodkIk/U5SJmsCRGGYdy7opHZb58yXI8eiIGp5MlgryFmmgrp1pg3OYzPOR9 zJjn7Pu1vsd97LM5hLnKrmNuYt02jLNSjr8HmpLyWCDZq4Jlfq1YgNYZZ4KOSxipia7Bxjcs nMOsxEWiolkVVT8CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEANRaPsUtrdJzTW0AMj/EQamqxOkZnzwnPWGryqskMKIf+OKa+eaXp zlBv8CHdffv9hrYpvzWUxk0WW+YJ2LRdd4fFiVGXZCGU60eYeZGf7Z8ORoexylJpvUuKZCE4 aPGY2/QZXDfOs1NE82Bhgltx59dpWfH2K0dxbpHslO8/IbowggM5MIICoqADAgECAgMKdm8w DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMzA4MDExNzI5MjlaFw0wNDA3MzExNzI5MjlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG+z7i158FfuOb 8JZIKIHUoo3eR1alAdeG1r6CtDI1j55CzzAzAxHs3bDBtQT4mcjXql5SSbRIHQCvB9jHPf6i 3iVKtwqAHg+lq46uEGsSQV4HUinBg3kAGUg4MFCUvb8ffnFyVXy8jmMSfgiwXDv3rvD70ote 5ZOqHgG67JEhg7v14taNkguEJpevZPMXGUBDEA6HZCJP1OUiZrAkRhmHcu6KR2W+fMlyPHoi BqeTJYK8hZpoK6daYNzmMzzkfcyY5+z7tb7HfeyzOYS5yq5jbmLdNoyzUo6/B5qS8lgg2auC ZX6tWIDWGWeCjksYqYmuwcY3LJzDrMRFoqJZFVU/AgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADUWj7FLa3Sc01tADI/xEGpqsTpG Z88Jz1hq8qrJDCiH/jimvnml6c5Qb/Ah3X37/Ya2Kb81lMZNFlvmCdi0XXeHxYlRl2QhlOtH mHmRn+2fDkaHscpSab1LimQhOGjxmNv0GVw3zrNTRPNgYYJbcefXaVnx9itHcW6R7JTvPyG6 MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCnZvMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMTAyMDE3NTcxMlowIwYJKoZIhvcNAQkEMRYEFEI1RObAMPNur2dVGfSh xt8M/RT0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnZvMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKdm8wDQYJKoZIhvcNAQEBBQAEggEAm4blJubvTwphqpAVGOULitXS8x6XqsdAl+Or +GLGW4SOWZLfvOCHPHZyVt7LuU1UVN3SBnVybbCTuHC+nR61/HIw2jHqj4Ca8z4e7SAbSALo BlYi5UgqmwamH8hR6aCUKtXlk/+JSTxu5FrYLzMIutX20sfY1c8EW5Lpp0qGz8H38WNPt0zm AiswNWACI3/tETdlQQwQ5VTBnMo0jdVOkiK+fzQ9PivQ5j3Ov0UECZ3zKQSv119wItHspl87 eHLny18ti+85UEy5PmlDcpUdwx1vRr+oRtWgRBVdWq6UaDWHTxodr369uD7N+QTv5pXWUddv eAQldKly4XTIj53UawAAAAAAAA== --------------ms020908000500030803050902-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 11:01:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 321E416A4BF for ; Mon, 20 Oct 2003 11:01:34 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2D3F43FB1 for ; Mon, 20 Oct 2003 11:01:21 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9KI1LFY098955 for ; Mon, 20 Oct 2003 11:01:21 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9KI1Kmt098949 for freebsd-net@freebsd.org; Mon, 20 Oct 2003 11:01:20 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 20 Oct 2003 11:01:20 -0700 (PDT) Message-Id: <200310201801.h9KI1Kmt098949@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 18:01:34 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 12:00:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B8EB16A4B3 for ; Mon, 20 Oct 2003 12:00:34 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFE2A43FE9 for ; Mon, 20 Oct 2003 12:00:32 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D33A6653D2; Mon, 20 Oct 2003 20:00:30 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06286-02; Mon, 20 Oct 2003 20:00:30 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E0F36653AD; Mon, 20 Oct 2003 20:00:28 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 9C805D3; Mon, 20 Oct 2003 20:00:19 +0100 (BST) Date: Mon, 20 Oct 2003 20:00:19 +0100 From: Bruce M Simpson To: sarat chandra Annadata Message-ID: <20031020190019.GD8721@saboteur.dek.spc.org> Mail-Followup-To: sarat chandra Annadata , freebsd-net@freebsd.org, mgrooms@shrew.net, julian@elischer.org References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031020174751.60464.qmail@web20805.mail.yahoo.com> cc: freebsd-net@freebsd.org cc: mgrooms@shrew.net cc: julian@elischer.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 19:00:34 -0000 On Mon, Oct 20, 2003 at 10:47:51AM -0700, sarat chandra Annadata wrote: > I am need of some urgent techinical help to pull me out of a little problem. I have been > trying to broadcast a UDP packet(actually it is a DHCP offer packet) but > havent' successfully done it sofar. The following is the descripttion > about how I have been trying to do it. > 1) I am creating a socket with sock_dgram option. > 2)Next I am filling up the sockaddr_in structure, with IP address > 255.255.255.255 and port number as DHCP client port number. [snip] Undirected broadcasts will only work if you do the following:- 1) Use a version of FreeBSD which supports the IP_ONESBCAST socket option. I committed this to HEAD and RELENG_4 branches somewhat over a month ago. Backporting the patch shouldn't be too difficult. 2) Enable the IP_ONESBCAST and SO_BROADCAST ip/socket level options. 3) Discover the IP broadcast address corresponding to the interface upin which you wish to send the datagram. 4) Use the sendto() or send() socket calls to send the datagram, *with the interface's IP broadcast address set as the destination*. The directed broadcast address is substituted with 255.255.255.255 at send time, after routing takes place, and before the datagram is handed off to the lower-layer network card drivers. BMS From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 12:50:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D966516A4B3 for ; Mon, 20 Oct 2003 12:50:08 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C899B43F3F for ; Mon, 20 Oct 2003 12:50:07 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9KJnxYL065150; Mon, 20 Oct 2003 15:49:59 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9KJnxZ4065149; Mon, 20 Oct 2003 15:49:59 -0400 (EDT) (envelope-from barney) Date: Mon, 20 Oct 2003 15:49:59 -0400 From: Barney Wolff To: sarat chandra Annadata , freebsd-net@freebsd.org, mgrooms@shrew.net, julian@elischer.org Message-ID: <20031020194959.GA64879@pit.databus.com> References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031020190019.GD8721@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031020190019.GD8721@saboteur.dek.spc.org> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 19:50:09 -0000 On Mon, Oct 20, 2003 at 08:00:19PM +0100, Bruce M Simpson wrote: > > Undirected broadcasts will only work if you do the following:- I've pointed out before that the gross hack of assigning IP address 255.0.0.0/8 to the desired interface should work. I've just confirmed that doing that, on RELENG_5_1 and RELENG_4, does result in ping 255.255.255.255 sending ICMP packets out with that dest addr. I have not personally tested UDP on FreeBSD, but this hack used to work on Irix, which at least back then had a bsd-derived network stack, to enable bootp to work with no kernel mods. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 15:21:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A887516A4BF for ; Mon, 20 Oct 2003 15:21:39 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF4F843F85 for ; Mon, 20 Oct 2003 15:21:38 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id 2280E5B6B0; Mon, 20 Oct 2003 15:17:59 -0700 (PDT) From: Wes Peters Organization: Softweyr.com To: Barney Wolff , sarat chandra Annadata , freebsd-net@freebsd.org, mgrooms@shrew.net, julian@elischer.org Date: Mon, 20 Oct 2003 15:21:26 -0700 User-Agent: KMail/1.5.2 References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031020190019.GD8721@saboteur.dek.spc.org> <20031020194959.GA64879@pit.databus.com> In-Reply-To: <20031020194959.GA64879@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310201521.26705.wes@softweyr.com> Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 22:21:39 -0000 On Monday 20 October 2003 12:49, Barney Wolff wrote: > On Mon, Oct 20, 2003 at 08:00:19PM +0100, Bruce M Simpson wrote: > > Undirected broadcasts will only work if you do the following:- > > I've pointed out before that the gross hack of assigning IP address > 255.0.0.0/8 to the desired interface should work. I've just > confirmed that doing that, on RELENG_5_1 and RELENG_4, does result in > ping 255.255.255.255 sending ICMP packets out with that dest addr. I > have not personally tested UDP on FreeBSD, but this hack used to work > on Irix, which at least back then had a bsd-derived network stack, to > enable bootp to work with no kernel mods. But does it send the packet to all attached interfaces on a multi-homed host? This is the type of bug that has typically bitten such hackish solutions in the past. One real solution is worth much more than the sum of the sort-of but not really working hacks we have flying about now. Go Bruce! Go Bruce! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 17:42:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8FF416A4B3 for ; Mon, 20 Oct 2003 17:42:59 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D830C43FAF for ; Mon, 20 Oct 2003 17:42:58 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9L0goYL068333; Mon, 20 Oct 2003 20:42:51 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9L0goA4068332; Mon, 20 Oct 2003 20:42:50 -0400 (EDT) (envelope-from barney) Date: Mon, 20 Oct 2003 20:42:50 -0400 From: Barney Wolff To: Wes Peters Message-ID: <20031021004250.GA68072@pit.databus.com> References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031020190019.GD8721@saboteur.dek.spc.org> <20031020194959.GA64879@pit.databus.com> <200310201521.26705.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310201521.26705.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org cc: mgrooms@shrew.net cc: sarat chandra Annadata cc: julian@elischer.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 00:43:00 -0000 On Mon, Oct 20, 2003 at 03:21:26PM -0700, Wes Peters wrote: > > But does it send the packet to all attached interfaces on a multi-homed > host? This is the type of bug that has typically bitten such hackish > solutions in the past. One real solution is worth much more than the > sum of the sort-of but not really working hacks we have flying about > now. Bughood is in the eye of the beholder. RFC1122 has this to say, in section 3.3.6: (255.255.255.255 is the "Limited Broadcast" address) There has been discussion on whether a datagram addressed to the Limited Broadcast address ought to be sent from all the interfaces of a multihomed host. This specification takes no stand on the issue. And of course any application that actually needs to send such a packet on every interface can loop through the interfaces, using the technique on each one, getting the reply, removing the 255.0.0.0/8 alias, and moving on to the next interface. If it were up to me (as of course it is not) I'd leave it at that and not clutter up the kernel. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 18:40:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A63016A4B3 for ; Mon, 20 Oct 2003 18:40:21 -0700 (PDT) Received: from srv1.lonline.com.br (srv1.lonline.com.br [200.211.46.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B73E43FAF for ; Mon, 20 Oct 2003 18:40:20 -0700 (PDT) (envelope-from tpeixoto@widesoft.com.br) Received: from widesoft.com.br (200-208-214-181.papalegua.com.br [200.208.214.181]) by srv1.lonline.com.br (8.12.9/8.12.2) with ESMTP id h9L1eFNm044966; Mon, 20 Oct 2003 22:40:17 -0300 (BRT) Message-ID: <3F948E80.E81906F6@widesoft.com.br> Date: Mon, 20 Oct 2003 23:40:16 -0200 From: "Tobias P. Santos" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: pt-BR,en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 01:40:21 -0000 Hello, I am trying to boot a FreeBSD diskless client with no success. Actually, I can boot the client, the kernel is downloaded and begins to boot. Then it tries to reach the DHCP/BOOT server, but this never occurs and the machine repeats the following messages forever: bootpc_call: sosend: 13 state 00000000 DHCP/BOOTP timeout for server 255.255.255.255 I connected both machines (server and client) with a crossover cable and ran tcpdump on server. Once the kernel is downloaded, there isn't any more talking on the network so the client is not asking for a DHCP/BOOTP server as it should be, or as it says to be. I made these tests with FreeBSD 4.8 and then switched back to 4.4 but got the same behaviour with both versions. With version 5.0, the kernel was downloaded but it didn't boot, so I gave up 5.x. The NIC's are Realtek 8139 detected as rl0 on client and also on server. BTW, I also tried an ed0 interface but it didn't change anything. Anyone could give a hand here? The only thing I can imagine is something wrong with diskless kernel, but I've compiled with the handbook instructions: options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info options BOOTP_COMPAT # Workaround for broken bootp daemons. Any clues? Thank you in advance! Best regards, -- Tobias. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 23:09:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33DD316A4B3 for ; Mon, 20 Oct 2003 23:09:41 -0700 (PDT) Received: from mail.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id EB6AB43FAF for ; Mon, 20 Oct 2003 23:09:39 -0700 (PDT) (envelope-from reichert@numachi.com) Received: (qmail 3982 invoked from network); 21 Oct 2003 06:09:38 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 21 Oct 2003 06:09:38 -0000 Received: (qmail 71086 invoked by uid 1001); 21 Oct 2003 06:09:38 -0000 Date: Tue, 21 Oct 2003 02:09:38 -0400 From: Brian Reichert To: "Tobias P. Santos" Message-ID: <20031021060938.GA70665@numachi.com> References: <3F948E80.E81906F6@widesoft.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F948E80.E81906F6@widesoft.com.br> User-Agent: Mutt/1.5.4i cc: freebsd-net@FreeBSD.ORG Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 06:09:41 -0000 On Mon, Oct 20, 2003 at 11:40:16PM -0200, Tobias P. Santos wrote: > The NIC's are Realtek 8139 detected as rl0 on client and also on server. > BTW, I also tried an ed0 interface but it didn't change anything. Does your client have multiple NICs? Which NIC is dhclient binding to? If you have more than one, have you poked at BOOTP_WIRED_TO (this is from a 4.7 LINT...) /me grasps at straws... > > Any clues? > > Thank you in advance! > Best regards, > -- > Tobias. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 05:21:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56E3716A4BF for ; Tue, 21 Oct 2003 05:21:50 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8572943F75 for ; Tue, 21 Oct 2003 05:21:47 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 7FCB06530D; Tue, 21 Oct 2003 13:21:45 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15163-01; Tue, 21 Oct 2003 13:21:44 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7DBBD652EC; Tue, 21 Oct 2003 13:21:43 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id C22CD2A; Tue, 21 Oct 2003 13:21:42 +0100 (BST) Date: Tue, 21 Oct 2003 13:21:42 +0100 From: Bruce M Simpson To: Barney Wolff Message-ID: <20031021122142.GB666@saboteur.dek.spc.org> Mail-Followup-To: Barney Wolff , Wes Peters , freebsd-net@freebsd.org, mgrooms@shrew.net, sarat chandra Annadata , julian@elischer.org References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031020190019.GD8721@saboteur.dek.spc.org> <20031020194959.GA64879@pit.databus.com> <200310201521.26705.wes@softweyr.com> <20031021004250.GA68072@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031021004250.GA68072@pit.databus.com> cc: julian@elischer.org cc: mgrooms@shrew.net cc: sarat chandra Annadata cc: freebsd-net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 12:21:50 -0000 On Mon, Oct 20, 2003 at 08:42:50PM -0400, Barney Wolff wrote: > And of course any application that actually needs to send such a packet > on every interface can loop through the interfaces, using the technique > on each one, getting the reply, removing the 255.0.0.0/8 alias, and > moving on to the next interface. If it were up to me (as of course it > is not) I'd leave it at that and not clutter up the kernel. I would take the view that applications shouldn't mess with the routing table if they don't have to, particularly if the application in question is a routing daemon... The IP_ONESBCAST socket option doesn't create any clutter; it coexists comfortably with delayed/hardware checksumming and adds virtually no extra latency to the output path. In any event, the idea was borrowed from BSD/OS, and seems to work well there. BMS From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 06:08:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F28BB16A4B3 for ; Tue, 21 Oct 2003 06:08:56 -0700 (PDT) Received: from queue.unet.com.mk (queue.unet.com.mk [212.13.64.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA30843FAF for ; Tue, 21 Oct 2003 06:08:49 -0700 (PDT) (envelope-from aleksandar@unet.com.mk) Received: from b166-er.unet.com.mk (ppp25.unet.com.mk [212.13.64.90] (may be forged)) by queue.unet.com.mk (8.11.6/8.11.6) with SMTP id h9LBqpq26312 for ; Tue, 21 Oct 2003 13:52:51 +0200 Date: Tue, 21 Oct 2003 15:11:22 +0200 From: Aleksandar Simonovski To: freebsd-net@freebsd.org Message-Id: <20031021151122.486f6060.aleksandar@unet.com.mk> Organization: Unet X-Mailer: Sylpheed version 0.9.4-gtk2-20030802 (GTK+ 2.2.4; i686-pc-linux-gnu) X-Operating-System: Slackware 9.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: natd+ipfw+trafic shaping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 13:08:57 -0000 Hi all, can anyone explane why this rules doesn't work: rl0 EXTINF rl1 INTINF add 1000 divert 8668 ip from any to any via rl0 add 1200 allow ip from any to any via lo0 add 1300 deny ip from any to 127.0.0.1/8 add 1400 deny ip from 127.0.0.1/8 to any add 1500 check-state add 1550 allow icmp from any to any keep-state add 1600 allow log udp from any to any 53 keep-state add 1700 queue 1 log tcp from 192.168.1.0/24 to any 20,21,22,23 keep-state add 1800 queue 1 log tcp from any 20,21,22,23 to 192.168.1.0/24 keep-state #add 1900 allow log udp from any 137 to any keep-state add 2000 allow log tcp from 192.168.1.0/24 to any 80 keep-state add 2100 deny log ip from any to any queue 1 config weight 10 pipe 1 mask src-ip 0xffffff00 queue 1 config weight 10 pipe 1 mask dst-ip 0xffffff00 pipe 1 config bw 128kbit/s and when i change "192.168.1.0/24" to "any" it works but the trafic shaping is not as it should be. I now this has something to do with natd and rule 1000 but that's the thing that confuses me,how can i limit or allow trafix to the local net (192.168.1.0/24) any help would be appreciated From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 07:00:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62E5616A507 for ; Tue, 21 Oct 2003 07:00:28 -0700 (PDT) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C2E43FB1 for ; Tue, 21 Oct 2003 07:00:25 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 47D17C6C538 for ; Tue, 21 Oct 2003 10:00:13 -0400 (EDT) To: freebsd-net@freebsd.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Back in Black Date: Tue, 21 Oct 2003 10:00:13 -0400 Sender: mallman@guns.icir.org Message-Id: <20031021140013.47D17C6C538@guns.icir.org> Subject: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 14:00:28 -0000 Hi folks! Are there any plans to incorporate SACK in FreeBSD? It'd sure be handy for me to have (I prefer the *BSDs, and, alas, they are the only remaining SACK-less systems worth mentioning). I think there are research implementations that could be used as a basis (Luigi Rizzo did one, I think.). Any thoughts in this area? Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 11:25:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6725516A4B3 for ; Tue, 21 Oct 2003 11:25:15 -0700 (PDT) Received: from tigger.icir.org (tigger.icir.org [192.150.187.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43D343F93 for ; Tue, 21 Oct 2003 11:25:14 -0700 (PDT) (envelope-from atanu@tigger.icir.org) Received: from tigger.icir.org (localhost [127.0.0.1]) by tigger.icir.org (8.12.9p1/8.12.3) with ESMTP id h9LIPDko023440; Tue, 21 Oct 2003 11:25:14 -0700 (PDT) (envelope-from atanu@tigger.icir.org) To: "Tobias P. Santos" In-reply-to: Your message of "Mon, 20 Oct 2003 23:40:16 -0200." <3F948E80.E81906F6@widesoft.com.br> From: Atanu Ghosh X-Organisation: The International Computer Science Institute X-Phone: +1 510 666 2966 X-Fax: +1 510 666 2956 X-Url: Date: Tue, 21 Oct 2003 11:25:13 -0700 Message-ID: <23439.1066760713@tigger.icir.org> Sender: atanu@icir.org cc: freebsd-net@freebsd.org Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: atanu@icsi.berkeley.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 18:25:15 -0000 >From my notes when trying to get diskless booting working: We usually have the firewall and dummynet enabled in our configs. The default is therefore not to allow any packets in or out. This stops the DHCP packets leaving a diskless kernel. Override this default. options IPFIREWALL_DEFAULT_TO_ACCEPT Atanu. >>>>> "Tobias" == Tobias P Santos writes: Tobias> Hello, I am trying to boot a FreeBSD diskless client with Tobias> no success. Actually, I can boot the client, the kernel Tobias> is downloaded and begins to boot. Then it tries to reach Tobias> the DHCP/BOOT server, but this never occurs and the Tobias> machine repeats the following messages forever: Tobias> bootpc_call: sosend: 13 state 00000000 DHCP/BOOTP timeout Tobias> for server 255.255.255.255 Tobias> I connected both machines (server and client) with a Tobias> crossover cable and ran tcpdump on server. Once the kernel Tobias> is downloaded, there isn't any more talking on the network Tobias> so the client is not asking for a DHCP/BOOTP server as it Tobias> should be, or as it says to be. Tobias> I made these tests with FreeBSD 4.8 and then switched back Tobias> to 4.4 but got the same behaviour with both versions. Tobias> With version 5.0, the kernel was downloaded but it didn't Tobias> boot, so I gave up 5.x. Tobias> The NIC's are Realtek 8139 detected as rl0 on client and Tobias> also on server. BTW, I also tried an ed0 interface but it Tobias> didn't change anything. Tobias> Anyone could give a hand here? The only thing I can Tobias> imagine is something wrong with diskless kernel, but I've Tobias> compiled with the handbook instructions: Tobias> options BOOTP # Use BOOTP to obtain IP address/hostname Tobias> options BOOTP_NFSROOT # NFS mount root filesystem using Tobias> BOOTP info options BOOTP_COMPAT # Workaround for broken Tobias> bootp daemons. Tobias> Any clues? Tobias> Thank you in advance! Best regards, -- Tobias. Tobias> _______________________________________________ Tobias> freebsd-net@freebsd.org mailing list Tobias> http://lists.freebsd.org/mailman/listinfo/freebsd-net To Tobias> unsubscribe, send any mail to Tobias> "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 11:46:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FB2116A4B3 for ; Tue, 21 Oct 2003 11:46:07 -0700 (PDT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F6C243F93 for ; Tue, 21 Oct 2003 11:46:06 -0700 (PDT) (envelope-from dart@nersc.gov) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 097D17762 for ; Tue, 21 Oct 2003 11:46:01 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id B082B7747 for ; Tue, 21 Oct 2003 11:46:01 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 98733F8EB for ; Tue, 21 Oct 2003 11:46:01 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: freebsd-net@freebsd.org In-Reply-To: Your message of Tue, 21 Oct 2003 10:00:13 EDT. <20031021140013.47D17C6C538@guns.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1682077037P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 21 Oct 2003 11:46:01 -0700 From: Eli Dart Message-Id: <20031021184601.98733F8EB@gemini.nersc.gov> Subject: Re: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 18:46:07 -0000 --==_Exmh_1682077037P Content-Type: text/plain; charset=us-ascii In reply to Mark Allman : > > Hi folks! > > Are there any plans to incorporate SACK in FreeBSD? It'd sure be > handy for me to have (I prefer the *BSDs, and, alas, they are the > only remaining SACK-less systems worth mentioning). I think there > are research implementations that could be used as a basis (Luigi > Rizzo did one, I think.). Any thoughts in this area? In fact, OpenBSD has SACK -- this narrows the Field of the SACK-less to FreeBSD and NetBSD..... --eli > > Thanks! > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --==_Exmh_1682077037P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/lX7pLTFEeF+CsrMRAlfRAJ4psX1XLptuLL8oYu7ceUz03A1njQCeNFzs QcbsZ+Dvi42WjyFNZ8kxGjY= =jfXr -----END PGP SIGNATURE----- --==_Exmh_1682077037P-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:04:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2EFB16A4B3 for ; Tue, 21 Oct 2003 12:04:16 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E831543FA3 for ; Tue, 21 Oct 2003 12:04:15 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9LJ4Bgk033157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Tue, 21 Oct 2003 15:04:12 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9LJ4BlP033154; Tue, 21 Oct 2003 15:04:11 -0400 (EDT) (envelope-from wollman) Date: Tue, 21 Oct 2003 15:04:11 -0400 (EDT) From: Garrett Wollman Message-Id: <200310211904.h9LJ4BlP033154@khavrinen.lcs.mit.edu> To: mallman@icir.org In-Reply-To: <20031021140013.47D17C6C538@guns.icir.org> References: <20031021140013.47D17C6C538@guns.icir.org> X-Spam-Score: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org Subject: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:04:17 -0000 < said: > Are there any plans to incorporate SACK in FreeBSD? We plan to add SACK to FreeBSD whan a compatible implementation is available. -GAWollman From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:14:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13E2F16A4BF for ; Tue, 21 Oct 2003 12:14:42 -0700 (PDT) Received: from bast.ocsinternet.com (bast.ocsinternet.com [204.107.76.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1109A43F75 for ; Tue, 21 Oct 2003 12:14:40 -0700 (PDT) (envelope-from mikel.king@ocsny.com) Received: from ocsny.com (fw207.ocsny.com [204.107.76.207]) by bast.ocsinternet.com (8.12.10/8.12.9) with ESMTP id h9LJCXd1045907; Tue, 21 Oct 2003 15:12:33 -0400 (EDT) (envelope-from mikel.king@ocsny.com) Message-ID: <3F9583F4.9020306@ocsny.com> Date: Tue, 21 Oct 2003 15:07:32 -0400 From: Mikel King User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atanu@icsi.berkeley.edu References: <23439.1066760713@tigger.icir.org> In-Reply-To: <23439.1066760713@tigger.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:14:42 -0000 Just curious would it be better to add a rule to allowe 67 & 68 (tcp & udp) in from the dhcp server instead of leaving the box all open? Understand I've never attempted this booting a diskless, but it seems like something worth trying.... Atanu Ghosh wrote: >>From my notes when trying to get diskless booting working: > > We usually have the firewall and dummynet enabled in our configs. The > default is therefore not to allow any packets in or out. This stops > the DHCP packets leaving a diskless kernel. Override this default. > >options IPFIREWALL_DEFAULT_TO_ACCEPT > > Atanu. > > > >>>>>>"Tobias" == Tobias P Santos writes: >>>>>> >>>>>> > > Tobias> Hello, I am trying to boot a FreeBSD diskless client with > Tobias> no success. Actually, I can boot the client, the kernel > Tobias> is downloaded and begins to boot. Then it tries to reach > Tobias> the DHCP/BOOT server, but this never occurs and the > Tobias> machine repeats the following messages forever: > > Tobias> bootpc_call: sosend: 13 state 00000000 DHCP/BOOTP timeout > Tobias> for server 255.255.255.255 > > Tobias> I connected both machines (server and client) with a > Tobias> crossover cable and ran tcpdump on server. Once the kernel > Tobias> is downloaded, there isn't any more talking on the network > Tobias> so the client is not asking for a DHCP/BOOTP server as it > Tobias> should be, or as it says to be. > > Tobias> I made these tests with FreeBSD 4.8 and then switched back > Tobias> to 4.4 but got the same behaviour with both versions. > > Tobias> With version 5.0, the kernel was downloaded but it didn't > Tobias> boot, so I gave up 5.x. > > Tobias> The NIC's are Realtek 8139 detected as rl0 on client and > Tobias> also on server. BTW, I also tried an ed0 interface but it > Tobias> didn't change anything. > > Tobias> Anyone could give a hand here? The only thing I can > Tobias> imagine is something wrong with diskless kernel, but I've > Tobias> compiled with the handbook instructions: > > Tobias> options BOOTP # Use BOOTP to obtain IP address/hostname > Tobias> options BOOTP_NFSROOT # NFS mount root filesystem using > Tobias> BOOTP info options BOOTP_COMPAT # Workaround for broken > Tobias> bootp daemons. > > Tobias> Any clues? > > Tobias> Thank you in advance! Best regards, -- Tobias. > Tobias> _______________________________________________ > Tobias> freebsd-net@freebsd.org mailing list > Tobias> http://lists.freebsd.org/mailman/listinfo/freebsd-net To > Tobias> unsubscribe, send any mail to > Tobias> "freebsd-net-unsubscribe@freebsd.org" >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:28:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DDD416A4B3 for ; Tue, 21 Oct 2003 12:28:29 -0700 (PDT) Received: from mx.carrel.org (adsl-64-91-104-251.gh.customer.centurytel.net [64.91.104.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77F4A43FBD for ; Tue, 21 Oct 2003 12:28:28 -0700 (PDT) (envelope-from william.a@carrel.org) Received: from carrel.org (unknown [172.16.4.3]) by mx.carrel.org (Postfix) with ESMTP id 1D46138 for ; Tue, 21 Oct 2003 12:28:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v581) To: freebsd-net@freebsd.org Message-Id: From: William A.Carrel Date: Tue, 21 Oct 2003 12:28:26 -0700 X-Mailer: Apple Mail (2.581) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: setsockopt IP_ADD_MEMBERSHIP not honored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:28:29 -0000 I've been working on a miniature multicast routing program and am encountering some troubles with getting setsockopt(2) to create the right behavior. I pass in setsockopt(the_sock, IP_ADD_MEMBERSHIP, &the_mreq); with the_mreq having in_addr's for the link-local multicast channel I'm interested in and the primary address of the interface I want the socket to receive packets from. (Inside the setsockopt path the second address is translated into an ifp for the interface that address is on.) I have two such sockets set up, one on each of the interfaces I'm interested in. The problem is that a packet that comes in on one interface winds up in the receive queue for both sockets. Both the queue for the socket that has the membership on the interface I care about, and the receive queue for the socket that has the membership on the other interface. My reading of UNP vol. 1 (pg. 496) and the ip(4) man page would imply that this is not the correct behavior for a multicast membership that was tied to a specific interface. This means that new processes that add membership to the multicast address on a new interface can cause older processes to receive packets on that interface that they did not intend to read. The code involved in the decision (src/sys/netinet/udp_usrreq.c:268-332) has been around a while so I'm loathe to change it willy-nilly. To get the behavior I'm thinking of would involve checking to make sure that the packet came in on the interface that the inp's multicast membership is associated with. Essentially, checking (ip->ip_dst.s_addr, m->m_pkthdr.rcvif) against the values (inp->inp_moptions->imo_membership[]->inm_addr.s_addr, inp->inp_moptions->imo_membership[]->inm_ifp) The following code snippet illustrates what I'm thinking for udp_usrreq.c... /* * Check multicast packets to make sure they are only sent to sockets with * multicast memberships on the same interface the packet arrived on */ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { int mshipno; for (mshipno = 0; mshipno <= inp->inp_moptions->imo_num_memberships; ++mshipno) { if (mshipno == inp->inp_moptions->imo_num_memberships) goto docontinue; if (ip->ip_dst.s_addr == inp->inp_moptions->imo_membership[mshipno]->inm_addr.s_addr && m->m_pkthdr.rcvif == inp->inp_moptions->imo_membership[mshipno]->inm_ifp) break; } } I think this would bring the operation of the IP_ADD_MEMBERSHIP sockopt back into line with the documentation. Anyone have any thoughts on this? From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:39:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1EB16A4B3 for ; Tue, 21 Oct 2003 12:39:00 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A5143FBD for ; Tue, 21 Oct 2003 12:38:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h9LJcxsd050488; Tue, 21 Oct 2003 12:38:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h9LJcxiQ050487; Tue, 21 Oct 2003 12:38:59 -0700 (PDT) (envelope-from rizzo) Date: Tue, 21 Oct 2003 12:38:59 -0700 From: Luigi Rizzo To: Mikel King Message-ID: <20031021123859.A50248@xorpc.icir.org> References: <23439.1066760713@tigger.icir.org> <3F9583F4.9020306@ocsny.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9583F4.9020306@ocsny.com>; from mikel.king@ocsny.com on Tue, Oct 21, 2003 at 03:07:32PM -0400 cc: freebsd-net@freebsd.org cc: atanu@ICSI.Berkeley.EDU Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:39:00 -0000 On Tue, Oct 21, 2003 at 03:07:32PM -0400, Mikel King wrote: > Just curious would it be better to add a rule to allowe 67 & 68 (tcp & > udp) in from the dhcp server instead of leaving the box all open? > Understand I've never attempted this booting a diskless, but it seems > like something worth trying.... all this happens before you have a chance to install an ipfw configuration so what you suggest cannot be done unless you hardwire the rules in the kernel (which you can't, at the moment; not that it couldn't be done, ipfw2 is quite flexible in this respect, but the feature is not implemented now). cheers luigi > Atanu Ghosh wrote: > > >>From my notes when trying to get diskless booting working: > > > > We usually have the firewall and dummynet enabled in our configs. The > > default is therefore not to allow any packets in or out. This stops > > the DHCP packets leaving a diskless kernel. Override this default. > > > >options IPFIREWALL_DEFAULT_TO_ACCEPT > > > > Atanu. From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:51:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B8F716A545 for ; Tue, 21 Oct 2003 12:51:58 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B5A43FBD for ; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h9LJpvsd057227; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h9LJpvSX057226; Tue, 21 Oct 2003 12:51:57 -0700 (PDT) (envelope-from rizzo) Date: Tue, 21 Oct 2003 12:51:56 -0700 From: Luigi Rizzo To: Garrett Wollman Message-ID: <20031021125156.B50248@xorpc.icir.org> References: <20031021140013.47D17C6C538@guns.icir.org> <200310211904.h9LJ4BlP033154@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310211904.h9LJ4BlP033154@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Oct 21, 2003 at 03:04:11PM -0400 cc: freebsd-net@freebsd.org cc: mallman@icir.org Subject: Re: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:51:58 -0000 On Tue, Oct 21, 2003 at 03:04:11PM -0400, Garrett Wollman wrote: > < said: > > > Are there any plans to incorporate SACK in FreeBSD? > > We plan to add SACK to FreeBSD whan a compatible implementation is > available. in my book this reads as "we have no plans" :) And to follow up on the topic, since i wrote one implementation long ago -- my code was probably largely incomplete in the handling of retransmission, also because it predates a lot of research onand RFC's on the topic. I know of another implementation, whose author i forget, which Jitu Padhye tested briefly with tbit -- however that one seemed to process SACK correctly but broke the non-sack case. My strong feeling is that before adding SACK one should do: 1. a bit of refactoring of the TCP code so that some indecently long functions are split in more manageable chunks (e.g. tcp_input() is ~2000 lines now) and there is less overload in state variables so that changes do not risk to break everything. 2. restructure the buffer management so that ack and data processing does not require O(window_size) time as it does now (with very large windows this kills you). Once this is done, probably there is a point in adding SACK. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 12:59:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1D6C16A4B3 for ; Tue, 21 Oct 2003 12:59:50 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05FD643F93 for ; Tue, 21 Oct 2003 12:59:50 -0700 (PDT) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9LJxnTi007927 for ; Tue, 21 Oct 2003 12:59:50 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com ; Tue, 21 Oct 2003 12:59:18 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9LJxXEV029486; Tue, 21 Oct 2003 12:59:33 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-412358293; protocol="application/pkcs7-signature" Message-Id: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> From: Joshua Graessley Date: Tue, 21 Oct 2003 12:59:47 -0700 To: "William A.Carrel" X-Mailer: Apple Mail (2.606) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: setsockopt IP_ADD_MEMBERSHIP not honored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 19:59:51 -0000 --Apple-Mail-13-412358293 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed This is "by design". When you perform IP_ADD_MEMBERSHIP, it assures you that the interface you've selected will receive packets destined for the multicast address you specify. It will deal with any IGMP traffic necessary for joining the group. When a packet is received on any interface, the packet is matched up to any number of sockets. This matching is based on the address and port the socket is bound to. This chunk of the code that matches a packet up to an interface does not check to see if that socket joined the multicast group on that specific interface. Some applications may rely on this behavior, so it might be unwise to change it. If you're going to make this change, you should probably make it some sort of socket option that applications can opt in to on a per socket basis. -josh On Oct 21, 2003, at 12:28 PM, William A.Carrel wrote: > I've been working on a miniature multicast routing program and am > encountering some troubles with getting setsockopt(2) to create the > right behavior. > > I pass in > setsockopt(the_sock, IP_ADD_MEMBERSHIP, &the_mreq); > with the_mreq having in_addr's for the link-local multicast channel > I'm interested in and the primary address of the interface I want the > socket to receive packets from. (Inside the setsockopt path the > second address is translated into an ifp for the interface that > address is on.) > > I have two such sockets set up, one on each of the interfaces I'm > interested in. The problem is that a packet that comes in on one > interface winds up in the receive queue for both sockets. Both the > queue for the socket that has the membership on the interface I care > about, and the receive queue for the socket that has the membership on > the other interface. > > My reading of UNP vol. 1 (pg. 496) and the ip(4) man page would imply > that this is not the correct behavior for a multicast membership that > was tied to a specific interface. This means that new processes that > add membership to the multicast address on a new interface can cause > older processes to receive packets on that interface that they did not > intend to read. > > The code involved in the decision > (src/sys/netinet/udp_usrreq.c:268-332) has been around a while so I'm > loathe to change it willy-nilly. > > To get the behavior I'm thinking of would involve checking to make > sure that the packet came in on the interface that the inp's multicast > membership is associated with. Essentially, checking > (ip->ip_dst.s_addr, m->m_pkthdr.rcvif) against the values > (inp->inp_moptions->imo_membership[]->inm_addr.s_addr, > inp->inp_moptions->imo_membership[]->inm_ifp) > > The following code snippet illustrates what I'm thinking for > udp_usrreq.c... > > /* > * Check multicast packets to make sure they are only sent to sockets > with > * multicast memberships on the same interface the packet arrived on > */ > if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { > int mshipno; > > for (mshipno = 0; mshipno <= inp->inp_moptions->imo_num_memberships; > ++mshipno) { > if (mshipno == inp->inp_moptions->imo_num_memberships) > goto docontinue; > if (ip->ip_dst.s_addr == > inp->inp_moptions->imo_membership[mshipno]->inm_addr.s_addr && > m->m_pkthdr.rcvif == > inp->inp_moptions->imo_membership[mshipno]->inm_ifp) > break; > } > } > > I think this would bring the operation of the IP_ADD_MEMBERSHIP > sockopt back into line with the documentation. Anyone have any > thoughts on this? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --Apple-Mail-13-412358293-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 14:02:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40B3216A4B3 for ; Tue, 21 Oct 2003 14:02:42 -0700 (PDT) Received: from mx.carrel.org (adsl-64-91-104-251.gh.customer.centurytel.net [64.91.104.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA1943F3F for ; Tue, 21 Oct 2003 14:02:41 -0700 (PDT) (envelope-from william.a@carrel.org) Received: from carrel.org (unknown [172.16.4.3]) by mx.carrel.org (Postfix) with ESMTP id E929E25A; Tue, 21 Oct 2003 14:02:29 -0700 (PDT) In-Reply-To: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> References: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v581) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William A.Carrel Date: Tue, 21 Oct 2003 14:02:39 -0700 To: Joshua Graessley X-Mailer: Apple Mail (2.581) cc: freebsd-net@freebsd.org Subject: Re: setsockopt IP_ADD_MEMBERSHIP not honored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 21:02:42 -0000 On Tuesday, October 21, 2003, at 12:59PM, Joshua Graessley wrote: > On Oct 21, 2003, at 12:28 PM, William A.Carrel wrote: > >> I have two such sockets set up, one on each of the interfaces I'm >> interested in. The problem is that a packet that comes in on one >> interface winds up in the receive queue for both sockets. Both the >> queue for the socket that has the membership on the interface I care >> about, and the receive queue for the socket that has the membership >> on the other interface. >> >> My reading of UNP vol. 1 (pg. 496) and the ip(4) man page would imply >> that this is not the correct behavior for a multicast membership that >> was tied to a specific interface. This means that new processes that >> add membership to the multicast address on a new interface can cause >> older processes to receive packets on that interface that they did >> not intend to read. > This is "by design". When you perform IP_ADD_MEMBERSHIP, it assures > you that the interface you've selected will receive packets destined > for the multicast address you specify. It will deal with any IGMP > traffic necessary for joining the group. > > When a packet is received on any interface, the packet is matched up > to any number of sockets. This matching is based on the address and > port the socket is bound to. This chunk of the code that matches a > packet up to an interface does not check to see if that socket joined > the multicast group on that specific interface. Right. This is exactly the issue I'm pointing out, and it is certainly my impression from the documentation of IP_ADD_MEMBERSHIP on this subject that the existing behavior needs fixing, as I'll elucidate in a little bit more detail below. > Some applications may rely on this behavior, so it might be unwise to > change it. If you're going to make this change, you should probably > make it some sort of socket option that applications can opt in to on > a per socket basis. Relying on this behavior doesn't seem to make sense. It would be relying on the kernel to let other programs to make you receive unintended multicast packets. It would also be relying on behavior contrary to the documentation. The only change in behavior would be if the program presumes someone else is holding memberships on all the interfaces (on its behalf) so it only has to open one. For example, in the case of multicast DNS, if the program is really wanting to listen for mDNS traffic on all interfaces, it needs to be adding membership on all interfaces. It would be broken behavior on the part of the application to add membership to the multicast address on one interface and trust that someone else has memberships to that multicast address on all the other interfaces, so it can get the multicast traffic for all interfaces. The example code from Apple in mDNSResponder-58/mDNSPosix/mDNSPosix.c (SetupSocket() at line 464) also seems to acknowledge that the multicast socket is only handling multicast for a specific interface. If a program really wants to get the multicast traffic on all interfaces, then it needs to add membership for all the interfaces. And if it holds membership on all the interfaces, my suggested fix will not keep it from receiving the packets that it wants destined for it. As such, I don't see the potential for a POLA violation in the suggested fix. From the manpage: A host must become a member of a multicast group before it can receive datagrams sent to the group. To join a multicast group, use the IP_ADD_MEMBERSHIP option: struct ip_mreq mreq; setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); where mreq is the following structure: struct ip_mreq { struct in_addr imr_multiaddr; /* multicast group to join */ struct in_addr imr_interface; /* interface to join on */ } imr_interface should be INADDR_ANY to choose the default multicast inter- face, or the IP address of a particular multicast-capable interface if the host is multihomed. Membership is associated with a single inter- face; programs running on multihomed hosts may need to join the same group on more than one interface. Up to IP_MAX_MEMBERSHIPS (currently 20) memberships may be added on a single socket. The assertion that "membership is associated with a single interface" is false under the current implementation. Membership is, at the moment, associated with the interface you specified to join on, and any other interfaces that any other processes on the entire system (possibly even processes in jails) have joined the same multicast address on. W. Richard Stevens wrote similarly on page 496 of UNP Vol. 1 (2nd ed.). "Join a multicast group on a specified local interface. ... If the local interface is specified as the wildcard address (INADDR_ANY for IPv4)..., then the local interface is chosen by the kernel. ... More than one join is allowed on a given socket... This can be used on a multihomed host where, for example, one socket is created and then for each interface a join is performed for a given multicast address." It seems odd that someone would join on a specified local interface and then start receiving packets on from an interface other than the one they had specified. The descriptions given both by Stevens, by Apple's mDNS example code and in the ip(4) man page run counter to the current behavior, hence the code I presented a moment ago to bring the behavior in line with the documentation. From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 15:03:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0FCD16A4B3 for ; Tue, 21 Oct 2003 15:03:58 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC2643FA3 for ; Tue, 21 Oct 2003 15:03:56 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 78722 invoked from network); 21 Oct 2003 22:27:07 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 21 Oct 2003 22:27:07 -0000 Received: (nullmailer pid 760 invoked by uid 136); Tue, 21 Oct 2003 22:05:16 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20031021151122.486f6060.aleksandar@unet.com.mk> To: Aleksandar Simonovski Date: Wed, 22 Oct 2003 02:05:16 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1066773916.587296.759.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: natd+ipfw+trafic shaping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 22:03:58 -0000 Remember that rules checked twice if not defined "in" or "out". Look at net.inet.ip.fw.one_pass sysctl > Hi all, > can anyone explane why this rules doesn't work: > > rl0 EXTINF > rl1 INTINF > > add 1000 divert 8668 ip from any to any via rl0 > add 1200 allow ip from any to any via lo0 > add 1300 deny ip from any to 127.0.0.1/8 > add 1400 deny ip from 127.0.0.1/8 to any > add 1500 check-state > add 1550 allow icmp from any to any keep-state > add 1600 allow log udp from any to any 53 keep-state > add 1700 queue 1 log tcp from 192.168.1.0/24 to any 20,21,22,23 keep-state > add 1800 queue 1 log tcp from any 20,21,22,23 to 192.168.1.0/24 keep-state > #add 1900 allow log udp from any 137 to any keep-state > add 2000 allow log tcp from 192.168.1.0/24 to any 80 keep-state > add 2100 deny log ip from any to any > queue 1 config weight 10 pipe 1 mask src-ip 0xffffff00 > queue 1 config weight 10 pipe 1 mask dst-ip 0xffffff00 > pipe 1 config bw 128kbit/s > > and when i change "192.168.1.0/24" to "any" it works but the trafic shaping is not > as it should be. I now this has something to do with natd and rule 1000 > but that's the thing that confuses me,how can i limit or allow trafix to the local net (192.168.1.0/24) > any help would be appreciated > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 15:23:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04CE116A4B3 for ; Tue, 21 Oct 2003 15:23:10 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5457343FBD for ; Tue, 21 Oct 2003 15:23:08 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9LMN7YL081258 for ; Tue, 21 Oct 2003 18:23:07 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9LMN7K5081257 for net@freebsd.org; Tue, 21 Oct 2003 18:23:07 -0400 (EDT) (envelope-from barney) Date: Tue, 21 Oct 2003 18:23:07 -0400 From: Barney Wolff To: net@freebsd.org Message-ID: <20031021222307.GA80895@pit.databus.com> References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031020190019.GD8721@saboteur.dek.spc.org> <20031020194959.GA64879@pit.databus.com> <200310201521.26705.wes@softweyr.com> <20031021004250.GA68072@pit.databus.com> <20031021122142.GB666@saboteur.dek.spc.org> <20031021193901.GA78633@pit.databus.com> <20031021214932.GA659@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031021214932.GA659@saboteur.dek.spc.org> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 22:23:10 -0000 Bruce M Simpson wrote pointing out AODV (RFC 3561) as an example of a routing protocol needing to send to 255.255.255.255 on multiple interfaces at once. I withdraw my scorn of kernel mods to facilitate this. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 17:12:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7058216A4B3 for ; Tue, 21 Oct 2003 17:12:40 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B20943FAF for ; Tue, 21 Oct 2003 17:12:39 -0700 (PDT) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9M0CdTi002466 for ; Tue, 21 Oct 2003 17:12:39 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com ; Tue, 21 Oct 2003 17:12:08 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h9M0CCww020779; Tue, 21 Oct 2003 17:12:12 -0700 (PDT) In-Reply-To: References: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22-427528834; protocol="application/pkcs7-signature" Message-Id: <71E524D5-0424-11D8-8EA7-000A95B9474C@apple.com> From: Joshua Graessley Date: Tue, 21 Oct 2003 17:12:38 -0700 To: "William A.Carrel" X-Mailer: Apple Mail (2.606) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: setsockopt IP_ADD_MEMBERSHIP not honored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 00:12:40 -0000 --Apple-Mail-22-427528834 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sounds good to me :) At the very least, this would improve the performance of the mDNSResponder. mDNSResponder has some additional code to get the interface the packet was received on so it can filter out the packet if it wasn't received on the interface that socket is bound to/associated with. This results in a packet being copied multiple times (once for every mDNSResponder socket) from the kernel to user space only to have all but one of those packets discarded. -josh On Oct 21, 2003, at 2:02 PM, William A.Carrel wrote: >> Some applications may rely on this behavior, so it might be unwise to >> change it. If you're going to make this change, you should probably >> make it some sort of socket option that applications can opt in to on >> a per socket basis. > > Relying on this behavior doesn't seem to make sense. It would be > relying on the kernel to let other programs to make you receive > unintended multicast packets. It would also be relying on behavior > contrary to the documentation. > > The only change in behavior would be if the program presumes someone > else is holding memberships on all the interfaces (on its behalf) so > it only has to open one. For example, in the case of multicast DNS, > if the program is really wanting to listen for mDNS traffic on all > interfaces, it needs to be adding membership on all interfaces. It > would be broken behavior on the part of the application to add > membership to the multicast address on one interface and trust that > someone else has memberships to that multicast address on all the > other interfaces, so it can get the multicast traffic for all > interfaces. The example code from Apple in > mDNSResponder-58/mDNSPosix/mDNSPosix.c (SetupSocket() at line 464) > also seems to acknowledge that the multicast socket is only handling > multicast for a specific interface. > > If a program really wants to get the multicast traffic on all > interfaces, then it needs to add membership for all the interfaces. > And if it holds membership on all the interfaces, my suggested fix > will not keep it from receiving the packets that it wants destined for > it. As such, I don't see the potential for a POLA violation in the > suggested fix. > > From the manpage: > A host must become a member of a multicast group before it can > receive > datagrams sent to the group. To join a multicast group, use the > IP_ADD_MEMBERSHIP option: > > struct ip_mreq mreq; > setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); > > where mreq is the following structure: > > struct ip_mreq { > struct in_addr imr_multiaddr; /* multicast group to join */ > struct in_addr imr_interface; /* interface to join on */ > } > > imr_interface should be INADDR_ANY to choose the default > multicast inter- > face, or the IP address of a particular multicast-capable > interface if > the host is multihomed. Membership is associated with a single > inter- > face; programs running on multihomed hosts may need to join the > same > group on more than one interface. Up to IP_MAX_MEMBERSHIPS > (currently > 20) memberships may be added on a single socket. > > The assertion that "membership is associated with a single interface" > is false under the current implementation. Membership is, at the > moment, associated with the interface you specified to join on, and > any other interfaces that any other processes on the entire system > (possibly even processes in jails) have joined the same multicast > address on. > > W. Richard Stevens wrote similarly on page 496 of UNP Vol. 1 (2nd > ed.). "Join a multicast group on a specified local interface. ... If > the local interface is specified as the wildcard address (INADDR_ANY > for IPv4)..., then the local interface is chosen by the kernel. ... > More than one join is allowed on a given socket... This can be used > on a multihomed host where, for example, one socket is created and > then for each interface a join is performed for a given multicast > address." > > It seems odd that someone would join on a specified local interface > and then start receiving packets on from an interface other than the > one they had specified. The descriptions given both by Stevens, by > Apple's mDNS example code and in the ip(4) man page run counter to the > current behavior, hence the code I presented a moment ago to bring the > behavior in line with the documentation. > --Apple-Mail-22-427528834-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 18:24:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 859A116A4BF for ; Tue, 21 Oct 2003 18:24:51 -0700 (PDT) Received: from srv1.lonline.com.br (srv1.lonline.com.br [200.211.46.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2945843FAF for ; Tue, 21 Oct 2003 18:24:49 -0700 (PDT) (envelope-from tpeixoto@widesoft.com.br) Received: from widesoft.com.br (200-228-96-171.papalegua.com.br [200.228.96.171] (may be forged)) by srv1.lonline.com.br (8.12.9/8.12.2) with ESMTP id h9M1OeM8022888; Tue, 21 Oct 2003 23:24:46 -0200 (BRST) Message-ID: <3F95DC5A.A9E43FC3@widesoft.com.br> Date: Tue, 21 Oct 2003 23:24:42 -0200 From: "Tobias P. Santos" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: pt-BR,en MIME-Version: 1.0 To: atanu@icsi.berkeley.edu References: <23439.1066760713@tigger.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 01:24:51 -0000 Hi Atanu, you're right. I've recompiled the diskless kernel and now it's working fine. I also would like to thank everybody who took time to help me with this issue. Thank you all! Best regards, Tobias. Atanu Ghosh wrote: > > >From my notes when trying to get diskless booting working: > > We usually have the firewall and dummynet enabled in our configs. The > default is therefore not to allow any packets in or out. This stops > the DHCP packets leaving a diskless kernel. Override this default. > > options IPFIREWALL_DEFAULT_TO_ACCEPT > > Atanu. > > >>>>> "Tobias" == Tobias P Santos writes: > > Tobias> Hello, I am trying to boot a FreeBSD diskless client with > Tobias> no success. Actually, I can boot the client, the kernel > Tobias> is downloaded and begins to boot. Then it tries to reach > Tobias> the DHCP/BOOT server, but this never occurs and the > Tobias> machine repeats the following messages forever: > > Tobias> bootpc_call: sosend: 13 state 00000000 DHCP/BOOTP timeout > Tobias> for server 255.255.255.255 > > Tobias> I connected both machines (server and client) with a > Tobias> crossover cable and ran tcpdump on server. Once the kernel > Tobias> is downloaded, there isn't any more talking on the network > Tobias> so the client is not asking for a DHCP/BOOTP server as it > Tobias> should be, or as it says to be. > > Tobias> I made these tests with FreeBSD 4.8 and then switched back > Tobias> to 4.4 but got the same behaviour with both versions. > > Tobias> With version 5.0, the kernel was downloaded but it didn't > Tobias> boot, so I gave up 5.x. > > Tobias> The NIC's are Realtek 8139 detected as rl0 on client and > Tobias> also on server. BTW, I also tried an ed0 interface but it > Tobias> didn't change anything. > > Tobias> Anyone could give a hand here? The only thing I can > Tobias> imagine is something wrong with diskless kernel, but I've > Tobias> compiled with the handbook instructions: > > Tobias> options BOOTP # Use BOOTP to obtain IP address/hostname > Tobias> options BOOTP_NFSROOT # NFS mount root filesystem using > Tobias> BOOTP info options BOOTP_COMPAT # Workaround for broken > Tobias> bootp daemons. > > Tobias> Any clues? > > Tobias> Thank you in advance! Best regards, -- Tobias. > Tobias> _______________________________________________ > Tobias> freebsd-net@freebsd.org mailing list > Tobias> http://lists.freebsd.org/mailman/listinfo/freebsd-net To > Tobias> unsubscribe, send any mail to > Tobias> "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 19:26:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F058416A4B3 for ; Tue, 21 Oct 2003 19:26:07 -0700 (PDT) Received: from w250.z064001178.sjc-ca.dsl.cnc.net (adsl-66.218.45.239.dslextreme.com [66.218.45.239]) by mx1.FreeBSD.org (Postfix) with SMTP id 3986F43F85 for ; Tue, 21 Oct 2003 19:26:05 -0700 (PDT) (envelope-from jos@catnook.com) Received: (qmail 8729 invoked by uid 1000); 22 Oct 2003 02:26:26 -0000 Date: Tue, 21 Oct 2003 19:26:04 -0700 From: Jos Backus To: freebsd-net@freebsd.org Message-ID: <20031022022626.GA91044@lizzy.catnook.com> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Filtering question: checking for many addresses in a single rule? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jos@catnook.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 02:26:08 -0000 If one has many (thousands) hosts/addresses that the same filter action needs to be taken for, what would be the most efficient way to implement this using, say, ipfw or ipfilter? I'm referring to the ability to create/load a large hashed set of addresses and a way to refer to the set in a filter rule. So rather than having many rules that need to be scanned sequentially there would only be one rule and the matching mechanism would use a hash table instead. Thoughts? -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ jos at catnook.com _/_/ _/_/_/ require 'std/disclaimer' From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 20:59:45 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3E8616A4B3 for ; Tue, 21 Oct 2003 20:59:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1452B43FAF for ; Tue, 21 Oct 2003 20:59:45 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9M3xdj06606; Tue, 21 Oct 2003 20:59:39 -0700 (PDT) Message-ID: <3F9600AA.7000500@isi.edu> Date: Tue, 21 Oct 2003 20:59:38 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jos@catnook.com References: <20031022022626.GA91044@lizzy.catnook.com> In-Reply-To: <20031022022626.GA91044@lizzy.catnook.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040800020107060509060804" cc: freebsd-net@freebsd.org Subject: Re: Filtering question: checking for many addresses in a single rule? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 03:59:45 -0000 This is a cryptographically signed message in MIME format. --------------ms040800020107060509060804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jos Backus wrote: > If one has many (thousands) hosts/addresses that the same filter action needs > to be taken for, what would be the most efficient way to implement this using, > say, ipfw or ipfilter? I'm referring to the ability to create/load a large > hashed set of addresses and a way to refer to the set in a filter rule. So > rather than having many rules that need to be scanned sequentially there would > only be one rule and the matching mechanism would use a hash table instead. > > Thoughts? You can generate a rule set based on matching increasingly specific subnets in combination with skipto, i.e. simulate a trie-like structure with the firewall. This can can get you down to O(log). It's not as automatic as you'd like though, probably. Lars -- Lars Eggert USC Information Sciences Institute --------------ms040800020107060509060804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwp2bzANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwMTE3MjkyOVoX DTA0MDczMTE3MjkyOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMb7PuLXnwV+45vwlkgogdSijd5HVqUB14bWvoK0 MjWPnkLPMDMDEezdsMG1BPiZyNeqXlJJtEgdAK8H2Mc9/qLeJUq3CoAeD6Wrjq4QaxJBXgdS KcGDeQAZSDgwUJS9vx9+cXJVfLyOYxJ+CLBcO/eu8PvSi17lk6oeAbrskSGDu/Xi1o2SC4Qm l69k8xcZQEMQDodkIk/U5SJmsCRGGYdy7opHZb58yXI8eiIGp5MlgryFmmgrp1pg3OYzPOR9 zJjn7Pu1vsd97LM5hLnKrmNuYt02jLNSjr8HmpLyWCDZq4Jlfq1YgNYZZ4KOSxipia7Bxjcs nMOsxEWiolkVVT8CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEANRaPsUtrdJzTW0AMj/EQamqxOkZnzwnPWGryqskMKIf+OKa+eaXp zlBv8CHdffv9hrYpvzWUxk0WW+YJ2LRdd4fFiVGXZCGU60eYeZGf7Z8ORoexylJpvUuKZCE4 aPGY2/QZXDfOs1NE82Bhgltx59dpWfH2K0dxbpHslO8/IbowggM5MIICoqADAgECAgMKdm8w DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMzA4MDExNzI5MjlaFw0wNDA3MzExNzI5MjlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG+z7i158FfuOb 8JZIKIHUoo3eR1alAdeG1r6CtDI1j55CzzAzAxHs3bDBtQT4mcjXql5SSbRIHQCvB9jHPf6i 3iVKtwqAHg+lq46uEGsSQV4HUinBg3kAGUg4MFCUvb8ffnFyVXy8jmMSfgiwXDv3rvD70ote 5ZOqHgG67JEhg7v14taNkguEJpevZPMXGUBDEA6HZCJP1OUiZrAkRhmHcu6KR2W+fMlyPHoi BqeTJYK8hZpoK6daYNzmMzzkfcyY5+z7tb7HfeyzOYS5yq5jbmLdNoyzUo6/B5qS8lgg2auC ZX6tWIDWGWeCjksYqYmuwcY3LJzDrMRFoqJZFVU/AgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADUWj7FLa3Sc01tADI/xEGpqsTpG Z88Jz1hq8qrJDCiH/jimvnml6c5Qb/Ah3X37/Ya2Kb81lMZNFlvmCdi0XXeHxYlRl2QhlOtH mHmRn+2fDkaHscpSab1LimQhOGjxmNv0GVw3zrNTRPNgYYJbcefXaVnx9itHcW6R7JTvPyG6 MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCnZvMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMTAyMjAzNTkzOFowIwYJKoZIhvcNAQkEMRYEFBgDMLAsqEWyHZ45UYns mTGjoGObMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnZvMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKdm8wDQYJKoZIhvcNAQEBBQAEggEAsztBuHeJfNWyrwCdZMYrTxMC5nmFG/A2vUvV oAWrB2/yVhvEI1La4UoPOD0Z/asLoMMlXmW8JvGhAIE3rkfCVUEN3Qv/CG6kruuZ2HTShxCP P+iiMszfA4/1ZBeKHkGtgso/rrLjoDGnsTTjLLXauq2vPM5y2t1t4tnlRvgTdNiSW9uI1Kbx 6h2KJbH0RPNF7BijHq74HaFDiWzR007xKoeNlkdjBuEs5AbgqxioW0aphwuH2FE/+edc7z8e hVlATJ1Qx9Fm+W+iE2CSqWO10IfN1DUy6jGAbMVDteeBochPe4fwvXLQSMDKmftwmKN/u1Kb ceKIV2WESOLy/j4U8gAAAAAAAA== --------------ms040800020107060509060804-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 00:17:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37EE016A4B3 for ; Wed, 22 Oct 2003 00:17:10 -0700 (PDT) Received: from snoopy.pacific.net.au (snoopy.pacific.net.au [61.8.0.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46CC743F75 for ; Wed, 22 Oct 2003 00:17:08 -0700 (PDT) (envelope-from gjb@gbch.net) Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) h9M7H6UC009085 for ; Wed, 22 Oct 2003 17:17:06 +1000 Received: from demon.gbch.net (ppp135.dyn11.pacific.net.au [61.8.11.135]) h9M7Cfst025585 for ; Wed, 22 Oct 2003 17:12:45 +1000 Received: (qmail 2711 invoked by uid 1001); 22 Oct 2003 10:27:19 +1000 Message-ID: Date: Wed, 22 Oct 2003 10:27:18 +1000 From: Greg Black To: "Tobias P. Santos" References: <3F948E80.E81906F6@widesoft.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F948E80.E81906F6@widesoft.com.br> User-Agent: Mutt/1.4.1i; gjb-muttsend.sh 1.4 2003-04-23 X-Uptime: 4:53 X-Operating-System: FreeBSD 4.3-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-PGP-Key-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-Request-PGP: http://www.gbch.net/keys/4B04B7D6.asc cc: freebsd-net@FreeBSD.ORG Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 07:17:10 -0000 On 2003-10-20, Tobias P. Santos wrote: > I am trying to boot a FreeBSD diskless client with no success. > Actually, I can boot the client, the kernel is downloaded and begins > to boot. Then it tries to reach the DHCP/BOOT server, but this never > occurs and the machine repeats the following messages forever: There is a nasty bug in most versions of the ISC DHCP code that gave me a nasty time when attempting just this recently. Upgrading to the current DHCP code is essential. From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 07:11:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14F2216A4B3 for ; Wed, 22 Oct 2003 07:11:19 -0700 (PDT) Received: from queue.unet.com.mk (queue.unet.com.mk [212.13.64.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id B47D943FBF for ; Wed, 22 Oct 2003 07:11:13 -0700 (PDT) (envelope-from aleksandar@unet.com.mk) Received: from b166-er.unet.com.mk (ppp25.unet.com.mk [212.13.64.90] (may be forged)) by queue.unet.com.mk (8.11.6/8.11.6) with SMTP id h9MCtFT18906 for ; Wed, 22 Oct 2003 14:55:15 +0200 Date: Wed, 22 Oct 2003 16:13:53 +0200 From: Aleksandar Simonovski To: freebsd-net@freebsd.org Message-Id: <20031022161353.2deeeeeb.aleksandar@unet.com.mk> Organization: Unet X-Mailer: Sylpheed version 0.9.4-gtk2-20030802 (GTK+ 2.2.4; i686-pc-linux-gnu) X-Operating-System: Slackware 9.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: gateway/firewall script X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 14:11:19 -0000 this is my script, works just fine, it's purpose is to allow just www,ftp and dns requests but i get only 6KB/s transfer with config bw 128Kbit/s, and 3KB/s with 64Kbit/s and so on and it should be 16KB/s with 128Kbit/s and 8KB/s with 64Kbit/s and do on so is this right or i'am missing something? any comments on the script would be fine INTINF = rl1 EXTINF = rl0 # natd is running natd -n rl0 #!/bin/sh -f flush add 1000 divert 8668 ip from any to any via rl0 add 1200 allow ip from any to any via lo0 add 1300 deny ip from any to 127.0.0.1/8 add 1400 deny ip from 127.0.0.1/8 to any add 1500 check-state add 1550 allow icmp from any to any keep-state add 1600 allow log udp from any to any 53 keep-state out add 1610 allow log udp from any to any 53 keep-state in #add 1620 allow log udp from any 53 to any keep-state in add 1700 queue 1 log tcp from any to any 20,21 keep-state out add 1800 queue 2 log tcp from any 20,21 to any keep-state in add 2000 queue 3 log tcp from any to any 80 keep-state out add 2010 queue 4 log tcp from any to any 80 keep-state in #add 2020 queue 5 log tcp from any 80 to any keep-state in add 2100 deny log ip from any to any queue 1 config weight 5 pipe 1 mask all queue 2 config weight 5 pipe 2 mask all queue 3 config weight 5 pipe 3 mask all queue 4 config weight 5 pipe 4 mask all queue 5 config weight 5 pipe 5 mask all pipe 1 config bw 128Kbit/s pipe 2 config bw 128Kbit/s pipe 3 config bw 128Kbit/s pipe 4 config bw 128Kbit/s pipe 5 config bw 128Kbit/s Cheers, Aleksandar From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 09:38:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75EFA16A4B3 for ; Wed, 22 Oct 2003 09:38:11 -0700 (PDT) Received: from w250.z064001178.sjc-ca.dsl.cnc.net (adsl-66.218.45.239.dslextreme.com [66.218.45.239]) by mx1.FreeBSD.org (Postfix) with SMTP id 9289D43F75 for ; Wed, 22 Oct 2003 09:38:10 -0700 (PDT) (envelope-from jos@catnook.com) Received: (qmail 40105 invoked by uid 1000); 22 Oct 2003 16:38:32 -0000 Date: Wed, 22 Oct 2003 09:38:10 -0700 From: Jos Backus To: freebsd-net@freebsd.org Message-ID: <20031022163832.GC39913@lizzy.catnook.com> Mail-Followup-To: freebsd-net@freebsd.org References: <20031022022626.GA91044@lizzy.catnook.com> <3F9600AA.7000500@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9600AA.7000500@isi.edu> User-Agent: Mutt/1.5.4i Subject: Re: Filtering question: checking for many addresses in a single rule? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jos@catnook.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 16:38:11 -0000 On Tue, Oct 21, 2003 at 08:59:38PM -0700, Lars Eggert wrote: > Jos Backus wrote: > >If one has many (thousands) hosts/addresses that the same filter action > >needs to be taken for, what would be the most efficient way to implement > >this using, say, ipfw or ipfilter? > You can generate a rule set based on matching increasingly specific > subnets in combination with skipto, i.e. simulate a trie-like structure > with the firewall. This can can get you down to O(log). > > It's not as automatic as you'd like though, probably. Right. That would be one way of making the existing rule-based mechanism more efficient, but it would presumably still be too slow and cumbersome to maintain. However, Pyun YongHyeon pointed me to pf's table feature which looks like it fits the ticket perfectly, so I'm going to investigate that. Thanks Lars. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ jos at catnook.com _/_/ _/_/_/ require 'std/disclaimer' From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 10:42:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D71A16A4B3 for ; Wed, 22 Oct 2003 10:42:00 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62FE143F3F for ; Wed, 22 Oct 2003 10:41:59 -0700 (PDT) (envelope-from gnagelhout@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <4CQ6N5GP>; Wed, 22 Oct 2003 13:41:58 -0400 Message-ID: From: Gerrit Nagelhout To: freebsd-net@freebsd.org Date: Wed, 22 Oct 2003 13:41:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Non-contiguous ifIndex problems with ifMib sysctl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 17:42:00 -0000 Hi, I am trying to debug a crash (null pointer access) in sysctl_ifdata (in if_mib.c). What I have noticed is that if interfaces (in this case vlans) are created and destroyed dynamically, it is possible to create "holes" in the ifnet_addrs structure. For example, if I start with the following interfaces: 1 em0 2 em1 3 lo0 and then do: ifconfig vlan1 create ifconfig vlan2 create ifconfig vlan1 destroy I end up with: 1 em0 2 em1 3 lo0 4 0 5 vlan2 In this case, the net.link.generic.system.ifcount is set to 4. If an application (like slurm) then calls sysctl on net.link.generic.ifdata., and loops from 1 to 5 for ifIndex, it will crash when it gets to 4 because there are no checks for these holes, and 4 is less than if_index. I have also noticed that an snmpwalk to a system like this will have the proper interface count, but will only show the interfaces before the hole. It's easy enough to add the null check in sysctl_ifdata, and just return ENOENT, but that won't fix the snmpwalk problem. How should applications generally deal with this? Thanks, Gerrit From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 11:09:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26B6E16A4B3 for ; Wed, 22 Oct 2003 11:09:40 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FE4043FBF for ; Wed, 22 Oct 2003 11:09:39 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h9MI9TIp023983; Wed, 22 Oct 2003 11:09:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h9MI9SRI023982; Wed, 22 Oct 2003 11:09:28 -0700 Date: Wed, 22 Oct 2003 11:09:28 -0700 From: Brooks Davis To: Gerrit Nagelhout Message-ID: <20031022180927.GA7831@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: Non-contiguous ifIndex problems with ifMib sysctl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2003 18:09:40 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 22, 2003 at 01:41:57PM -0400, Gerrit Nagelhout wrote: > Hi, >=20 > I am trying to debug a crash (null pointer access) in sysctl_ifdata (in > if_mib.c). What I have noticed is that if interfaces (in this case vlans) > are created and destroyed dynamically, it is possible to create "holes" in > the ifnet_addrs structure. For example, if I start with the following > interfaces: > 1 em0 > 2 em1 > 3 lo0 >=20 > and then do: > ifconfig vlan1 create > ifconfig vlan2 create > ifconfig vlan1 destroy >=20 > I end up with: > 1 em0 > 2 em1 > 3 lo0 > 4 0 > 5 vlan2 >=20 > In this case, the net.link.generic.system.ifcount is set to 4. If an > application (like slurm) then calls sysctl on > net.link.generic.ifdata., and loops from 1 to 5 for ifIndex, it > will crash when it gets to 4 because there are no checks for these holes, > and 4 is less than if_index. > I have also noticed that an snmpwalk to a system like this will have the > proper interface count, but will only show the interfaces before the hole. > It's easy enough to add the null check in sysctl_ifdata, and just return > ENOENT, but that won't fix the snmpwalk problem. How should applications > generally deal with this? This was fixed in current with ENOENT two years ago, but the author forgot to MFC the change. Given how long this has been broken (since we got removable devices), I'm inclined to wait until after 4.9 comes out to do the MFC rather then trying to get it in under the wire. I don't see the behavior you describe with ifcount. The ifcount sysctl is just an export if_index which is the last index, not the number of interfaces. This might be considered a bug in ifcount's implementation. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/lsfOXY6L6fI4GtQRAiXaAJ4pEsaGWQ6KXZfO7jdj8qx7oxGBlgCffyRF Eo9IQTNQQHWak/bTxZyyXrw= =AoCd -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 19:31:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A240516A4B3 for ; Wed, 22 Oct 2003 19:31:52 -0700 (PDT) Received: from mag.barnet.com.au (mag.barnet.com.au [218.185.88.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F20F43F3F for ; Wed, 22 Oct 2003 19:31:51 -0700 (PDT) (envelope-from edwin@mavetju.org) Received: from extmail.barnet.com.au (tim.direct.int.barnet.com.au [10.10.10.2]) by mag.barnet.com.au (Postfix) with ESMTP id 0824720E1 for ; Thu, 23 Oct 2003 12:31:49 +1000 (EST) X-Viruscan-Id: <3F973D9400010EB501A1AE6B@VIRUSCAN-127.0.0.1> Received: from extmail-auth.barnet.com.au (localhost [127.0.0.1]) by extmail.barnet.com.au (Postfix) with ESMTP id 983EA1F1E for ; Thu, 23 Oct 2003 12:31:48 +1000 (EST) Received: from k7.mavetju (p61-max1.syd.ihug.com.au [203.173.155.61]) by extmail-auth.barnet.com.au (Postfix) with ESMTP id 865531F1A for ; Thu, 23 Oct 2003 12:31:47 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 293FF6A7101; Thu, 23 Oct 2003 12:31:46 +1000 (EST) Date: Thu, 23 Oct 2003 12:31:46 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20031023023146.GA34131@k7.mavetju> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: UDP connect: Can't assign requested address or "how to determine the outgoing IP address?" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 02:31:52 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I got a nice piece of code (see attachment) which could be used to determine the outgoing IP address for an UDP socket. It works without problem under Linux, but it fails on FreeBSD (-current and -stable) during the call to connect() with the error: "Can't assign requested address". The code looks like the udpcli09.c example in Richard Stevens 'Unix Network Programming' book, which states it doesn't work on SVR4 derived kernels. So, the question is, how can I determine the outgoing IP address for a socket? Edwin attached code can be compiled with "gcc -Wall -g -o a a.c && ./a" -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/weblog.php --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="a.c" #include #include #include #include #include #include #include #include #include int guess_local_address(char *address_to_reach,char **loc); int main(void) { char *loc; guess_local_address("218.185.88.1",&loc);printf("%s\n",loc); guess_local_address("192.168.1.3",&loc);printf("%s\n",loc); guess_local_address("127.0.0.1",&loc);printf("%s\n",loc); return 0; } int guess_local_address(char *address_to_reach,char **loc){ int s,err; struct addrinfo hints; struct addrinfo *res=NULL; struct sockaddr addr; int sock; *loc=NULL; printf("Trying %s: ",address_to_reach); memset(&hints,0,sizeof(hints)); hints.ai_family=PF_UNSPEC; hints.ai_socktype=SOCK_DGRAM; hints.ai_flags=AI_NUMERICHOST|AI_CANONNAME; err=getaddrinfo(address_to_reach,NULL,&hints,&res); if (err<0){ printf("getaddrinfo: %s\n",gai_strerror(err)); return -1; } if (res==NULL){ printf("getaddrinfo reported nothing !"); return -1; } sock=socket(res->ai_family,SOCK_DGRAM,0); if (err<0){ printf("Error in socket: %s\n",strerror(errno)); return -1; } { struct sockaddr_in servaddr; memset(&servaddr,sizeof(servaddr),0); servaddr.sin_family=AF_INET; servaddr.sin_addr.s_addr=htonl(INADDR_ANY); servaddr.sin_port=htons(0); err=bind(sock,(struct sockaddr *)&servaddr,sizeof(servaddr)); if (err<0){ printf("Error in bind: %s\n",strerror(errno)); return -1; } } s=1; err=setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,&s,sizeof(int)); if (err<0){ printf("Error in setsockopt: %s\n",strerror(errno)); return -1; } err=connect(sock,res->ai_addr,res->ai_addrlen); if (err<0) { printf("Error in connect: %s\n",strerror(errno)); return -1; } freeaddrinfo(res); res=NULL; s=sizeof(addr); err=getsockname(sock,(struct sockaddr*)&addr,&s); if (err<0) { printf("Error in getsockname: %s\n",strerror(errno)); return -1; } *loc=malloc(30); err=getnameinfo(&addr,s,*loc,30,NULL,0,NI_NUMERICHOST); if (err<0){ printf("getnameinfo error:%s",strerror(errno)); return -1; } close(sock); return 0; } --gBBFr7Ir9EOA20Yy-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 19:52:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ADB016A4B3 for ; Wed, 22 Oct 2003 19:52:10 -0700 (PDT) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12F7B43F93 for ; Wed, 22 Oct 2003 19:52:09 -0700 (PDT) (envelope-from vlm@netli.com) Received: (qmail 18679 invoked by uid 84); 23 Oct 2003 02:52:08 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.160765 secs); 23 Oct 2003 02:52:08 -0000 Received: from unknown (HELO netli.com) (172.17.1.12) by mx01-pal-lan.netli.lan with SMTP; 23 Oct 2003 02:52:08 -0000 Message-ID: <3F974296.9040304@netli.com> Date: Wed, 22 Oct 2003 19:53:10 -0700 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031019 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Edwin Groothuis References: <20031023023146.GA34131@k7.mavetju> In-Reply-To: <20031023023146.GA34131@k7.mavetju> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: UDP connect: Can't assign requested address or "how todetermine the outgoing IP address?" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 02:52:10 -0000 Edwin Groothuis wrote: > Hello, > > I got a nice piece of code (see attachment) which could be used to > determine the outgoing IP address for an UDP socket. It works without > problem under Linux, but it fails on FreeBSD (-current and -stable) > during the call to connect() with the error: "Can't assign requested > address". The code looks like the udpcli09.c example in Richard > Stevens 'Unix Network Programming' book, which states it doesn't > work on SVR4 derived kernels. > > So, the question is, how can I determine the outgoing IP address > for a socket? Everything's fine apart from one thing: connect() does not like to connect to places with destination port equal to zero. > attached code can be compiled with "gcc -Wall -g -o a a.c && ./a" > > > > ------------------------------------------------------------------------ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > int guess_local_address(char *address_to_reach,char **loc); > > int main(void) { > char *loc; > > guess_local_address("218.185.88.1",&loc);printf("%s\n",loc); > guess_local_address("192.168.1.3",&loc);printf("%s\n",loc); > guess_local_address("127.0.0.1",&loc);printf("%s\n",loc); > return 0; > } > > int guess_local_address(char *address_to_reach,char **loc){ > int s,err; > struct addrinfo hints; > struct addrinfo *res=NULL; > struct sockaddr addr; > int sock; > > *loc=NULL; > > printf("Trying %s: ",address_to_reach); > > memset(&hints,0,sizeof(hints)); > hints.ai_family=PF_UNSPEC; > hints.ai_socktype=SOCK_DGRAM; > hints.ai_flags=AI_NUMERICHOST|AI_CANONNAME; > > err=getaddrinfo(address_to_reach,NULL,&hints,&res); > if (err<0){ > printf("getaddrinfo: %s\n",gai_strerror(err)); > return -1; > } > if (res==NULL){ > printf("getaddrinfo reported nothing !"); > return -1; > } > sock=socket(res->ai_family,SOCK_DGRAM,0); > if (err<0){ > printf("Error in socket: %s\n",strerror(errno)); > return -1; > } > { > struct sockaddr_in servaddr; > memset(&servaddr,sizeof(servaddr),0); > servaddr.sin_family=AF_INET; > servaddr.sin_addr.s_addr=htonl(INADDR_ANY); > servaddr.sin_port=htons(0); > err=bind(sock,(struct sockaddr *)&servaddr,sizeof(servaddr)); > if (err<0){ > printf("Error in bind: %s\n",strerror(errno)); > return -1; > } > } > s=1; > err=setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,&s,sizeof(int)); > if (err<0){ > printf("Error in setsockopt: %s\n",strerror(errno)); > return -1; > } /* * This will do. Note that it assumes AF_INET. */ ((struct sockaddr_in *)res->ai_addr)->sin_port = htons(80); > err=connect(sock,res->ai_addr,res->ai_addrlen); > if (err<0) { > printf("Error in connect: %s\n",strerror(errno)); > return -1; > } > freeaddrinfo(res); > res=NULL; > s=sizeof(addr); > err=getsockname(sock,(struct sockaddr*)&addr,&s); > if (err<0) { > printf("Error in getsockname: %s\n",strerror(errno)); > return -1; > } > *loc=malloc(30); > err=getnameinfo(&addr,s,*loc,30,NULL,0,NI_NUMERICHOST); > if (err<0){ > printf("getnameinfo error:%s",strerror(errno)); > return -1; > } > close(sock); > return 0; > } > -- Lev Walkin vlm@netli.com From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 20:06:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E28F16A4BF for ; Wed, 22 Oct 2003 20:06:08 -0700 (PDT) Received: from mag.barnet.com.au (mag.barnet.com.au [218.185.88.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3138543F85 for ; Wed, 22 Oct 2003 20:06:05 -0700 (PDT) (envelope-from edwin@mavetju.org) Received: from extmail.barnet.com.au (tim.direct.int.barnet.com.au [10.10.10.2]) by mag.barnet.com.au (Postfix) with ESMTP id 7C99620E3; Thu, 23 Oct 2003 13:06:03 +1000 (EST) X-Viruscan-Id: <3F97459B00013F0F01B29E8C@VIRUSCAN-127.0.0.1> Received: from extmail-auth.barnet.com.au (localhost [127.0.0.1]) by extmail.barnet.com.au (Postfix) with ESMTP id F355F1F24; Thu, 23 Oct 2003 13:06:02 +1000 (EST) Received: from k7.mavetju (p61-max1.syd.ihug.com.au [203.173.155.61]) by extmail-auth.barnet.com.au (Postfix) with ESMTP id 4005F1F22; Thu, 23 Oct 2003 13:06:02 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id CA6386A7101; Thu, 23 Oct 2003 13:06:00 +1000 (EST) Date: Thu, 23 Oct 2003 13:06:00 +1000 From: Edwin Groothuis To: Lev Walkin Message-ID: <20031023030600.GX59349@k7.mavetju> References: <20031023023146.GA34131@k7.mavetju> <3F974296.9040304@netli.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F974296.9040304@netli.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: UDP connect: Can't assign requested address or "how to determine the outgoing IP address?" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 03:06:08 -0000 On Wed, Oct 22, 2003 at 07:53:10PM -0700, Lev Walkin wrote: > Everything's fine apart from one thing: connect() does not like to > connect to places with destination port equal to zero. > /* > * This will do. Note that it assumes AF_INET. > */ > ((struct sockaddr_in *)res->ai_addr)->sin_port = htons(80); Many many many thanks for this! You're a champ! Edwin, will never forgot this lesson. -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/weblog.php From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 20:29:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D49C916A4C0 for ; Wed, 22 Oct 2003 20:29:14 -0700 (PDT) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FD1643FDD for ; Wed, 22 Oct 2003 20:29:12 -0700 (PDT) (envelope-from vulture@netvulture.com) Received: from netvulture.com (bigv.netvulture.com [192.168.2.130]) h9N3T9UP034203; Wed, 22 Oct 2003 20:29:11 -0700 (PDT) Message-ID: <3F974B06.7070304@netvulture.com> Date: Wed, 22 Oct 2003 20:29:10 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandar Simonovski References: <20031022161353.2deeeeeb.aleksandar@unet.com.mk> In-Reply-To: <20031022161353.2deeeeeb.aleksandar@unet.com.mk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: freebsd-net@freebsd.org Subject: Re: gateway/firewall script X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 03:29:15 -0000 Your problem lies in that you are counting the traffic twice in the queue/pipe - once from the internal addr to the dst, and once from the external addr to the dst. Change your rules to specify which IP Block should get the bw limiting. I don't know if the keep-state thing is throwing it out of whack or not. Aleksandar Simonovski wrote: >this is my script, works just fine, it's purpose is to allow just www,ftp and dns requests >but i get only 6KB/s transfer with config bw 128Kbit/s, and 3KB/s with 64Kbit/s and so on >and it should be 16KB/s with 128Kbit/s and 8KB/s with 64Kbit/s and do on so is this right or >i'am missing something? > >any comments on the script would be fine > >INTINF = rl1 >EXTINF = rl0 > ># natd is running >natd -n rl0 > >#!/bin/sh >-f flush >add 1000 divert 8668 ip from any to any via rl0 >add 1200 allow ip from any to any via lo0 >add 1300 deny ip from any to 127.0.0.1/8 >add 1400 deny ip from 127.0.0.1/8 to any >add 1500 check-state >add 1550 allow icmp from any to any keep-state >add 1600 allow log udp from any to any 53 keep-state out >add 1610 allow log udp from any to any 53 keep-state in >#add 1620 allow log udp from any 53 to any keep-state in >add 1700 queue 1 log tcp from any to any 20,21 keep-state out >add 1800 queue 2 log tcp from any 20,21 to any keep-state in >add 2000 queue 3 log tcp from any to any 80 keep-state out >add 2010 queue 4 log tcp from any to any 80 keep-state in >#add 2020 queue 5 log tcp from any 80 to any keep-state in >add 2100 deny log ip from any to any >queue 1 config weight 5 pipe 1 mask all >queue 2 config weight 5 pipe 2 mask all >queue 3 config weight 5 pipe 3 mask all >queue 4 config weight 5 pipe 4 mask all >queue 5 config weight 5 pipe 5 mask all >pipe 1 config bw 128Kbit/s >pipe 2 config bw 128Kbit/s >pipe 3 config bw 128Kbit/s >pipe 4 config bw 128Kbit/s >pipe 5 config bw 128Kbit/s > >Cheers, >Aleksandar >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 01:37:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6AA416A4B3 for ; Thu, 23 Oct 2003 01:37:41 -0700 (PDT) Received: from queue.unet.com.mk (queue.unet.com.mk [212.13.64.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5069A43F3F for ; Thu, 23 Oct 2003 01:37:37 -0700 (PDT) (envelope-from aleksandar@unet.com.mk) Received: from b166-er.unet.com.mk (ppp25.unet.com.mk [212.13.64.90] (may be forged)) by queue.unet.com.mk (8.11.6/8.11.6) with SMTP id h9N7LYT32511 for ; Thu, 23 Oct 2003 09:21:34 +0200 Date: Thu, 23 Oct 2003 10:40:17 +0200 From: Aleksandar Simonovski To: freebsd-net@freebsd.org Message-Id: <20031023104017.4657840f.aleksandar@unet.com.mk> In-Reply-To: <3F974B06.7070304@netvulture.com> References: <20031022161353.2deeeeeb.aleksandar@unet.com.mk> <3F974B06.7070304@netvulture.com> Organization: Unet X-Mailer: Sylpheed version 0.9.4-gtk2-20030802 (GTK+ 2.2.4; i686-pc-linux-gnu) X-Operating-System: Slackware 9.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: Re: gateway/firewall script X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 08:37:41 -0000 On Wed, 22 Oct 2003 20:29:10 -0700 Jonathan Feally wrote: > Your problem lies in that you are counting the traffic twice in the > queue/pipe - once from the internal addr to the dst, and once from the > external addr to the dst. Change your rules to specify which IP Block > should get the bw limiting. > I don't know if the keep-state thing is throwing it out of whack or not. ok, i don't get this quite right, you meen i should change the masks to something like this: queue 1 config weight 5 pipe 1 mask src-ip 0xffffff00 queue 2 config weight 5 pipe 2 mask dst-ip 0xffffff00 queue 3 config weight 5 pipe 3 mask src-ip 0xffffff00 queue 4 config weight 5 pipe 4 mask dst-ip 0xffffff00 From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 01:55:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E52D16A4B3 for ; Thu, 23 Oct 2003 01:55:57 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A786343F85 for ; Thu, 23 Oct 2003 01:55:56 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 818BC72E22; Thu, 23 Oct 2003 01:51:56 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Barney Wolff , net@freebsd.org Date: Thu, 23 Oct 2003 01:55:55 -0700 User-Agent: KMail/1.5.4 References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031021214932.GA659@saboteur.dek.spc.org> <20031021222307.GA80895@pit.databus.com> In-Reply-To: <20031021222307.GA80895@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310230155.55363.wes@softweyr.com> Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 08:55:57 -0000 On Tuesday 21 October 2003 03:23 pm, Barney Wolff wrote: > Bruce M Simpson wrote pointing > out AODV (RFC 3561) as an example of a routing protocol needing to > send to 255.255.255.255 on multiple interfaces at once. I withdraw > my scorn of kernel mods to facilitate this. To me it's not a matter of "boot code" vs. general usefulness so much as it's just obviously the right way to do it. We use all-ones packets well after boot to have our appliances identify each other on the network and share configuration information, and it's not always evident which network interface(s) they should be using to do this. The current code binds to each of the interfaces and blats out a packet, but it just seems obvious that the all-ones address implies all attached interfaces because you have a per-network broadcast address if you want to do per-interface broadcasts. I've been working with Bruce on this and there are parts that still worry me. If you want to poke holes in the thinking we've been doing, I'm always happy to have another set of eyeballs on the design and I'm sure Bruce will too. Interactions with VLANs, for instance. If you send an all-ones broadcast on an interface that has one or more VLANs configured, do you repeat them "on" each VLAN as well? Ugh. What about point-to-point links? Are those always considered gateways to a foreign network, or just another form of locally attached network? I'm pretty certain the code won't be all that difficult if we just fully understand the problem before we jump in, but I'm also pretty certain we don't fully understand the problem, let alone the solution. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 05:31:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B768B16A4B3 for ; Thu, 23 Oct 2003 05:31:15 -0700 (PDT) Received: from tdwyer.arach.net.au (tdwyer.arach.net.au [203.15.140.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F1D43FDD for ; Thu, 23 Oct 2003 05:31:12 -0700 (PDT) (envelope-from sdwyer@arach.net.au) Received: from arach.net.au (hades.ctnet.org.au [10.60.32.12]) by tdwyer.arach.net.au (Postfix) with ESMTP id 973F2152AC; Thu, 23 Oct 2003 20:31:13 +0800 (WST) Message-ID: <3F97CB52.1080100@arach.net.au> Date: Thu, 23 Oct 2003 20:36:34 +0800 From: Shaun Dwyer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030409 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leon Verheem References: <651BBF3EA452AA459E5578E94B0DE30170F11B@exch01.korbitec.int> In-Reply-To: <651BBF3EA452AA459E5578E94B0DE30170F11B@exch01.korbitec.int> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Using multilink ppp(or similar) over 2 bridge mode ADSLconnections... -- WORKS! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 12:31:15 -0000 Hi, Yes, I was successful actually :) The configuraton was as follows(ip addresses changed to hide the box-- s/real.ip.address/192.168.1/g): Co-located machine had 2 IP addresses assigned: fxp0: flags=8843 mtu 1500 inet 192.168.1.11 netmask 0xffffffc0 broadcast 192.168.1.63 inet 192.168.1.14 netmask 0xffffffff broadcast 192.168.1.14 ether 00:02:b3:d1:c5:39 media: Ethernet autoselect (100baseTX ) status: active Machine at office had two bridge mode 1.5Mbit/256kbit ADSL connections(The IP addresses were just ifconfig'd on each NIC). The co-lo machine's ppp.conf is as follows: #---start ppp.conf--- default: #Only enable logging for troubleshooting #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync #set log Connect tun Phase Debug LCP set log Connect tun Phase LCP #set log Chat Connect Command IPCP tun Phase Warning LCP ppp-in: set timeout 0 set speed 0 set device 192.168.1.11:7900/tcp 192.168.1.14:7900/tcp set enddisc MAC set mrru 1450 set mtu 1450 set mru 1450 set dial set login # Addresses for: MyAddr, HisAddr, Netmask # set ifaddr 192.168.2.1/8 192.168.3.1/8 255.255.255.255 # set ifaddr 192.168.2.1 192.168.3.1/24 255.255.255.255 set ifaddr 10.60.50.5 10.60.50.6 255.255.255.252 #Chap is encrypted, pap isnt enable chap disable pap enable MSCHAPv2 enable lqr #---End ppp.conf--- The co-lo machine's ppp.secret contains: #---start ppp.secret--- username_goes_here password_goes_here 10.60.50.6 #---end ppp.secret--- /etc/inetd.conf on the co-lo machine had the following lines added: #--start-- #incoming ppp ppp-in stream tcp nowait root /usr/sbin/ppp ppp -direct ppp-in #--end-- /etc/services had the following added: #--start-- ppp-in 7900/tcp #incoming TCP ppp session #--end-- The Office Machine's ppp.conf is as follows: #---start ppp.conf--- default: #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync set log Connect tun Phase LCP multilink: set escape 0xff # set device 192.168.1.11:7900/tcp 192.168.1.14:7900/tcp set speed sync set ctsrts off set timeout 30 set authname username_goes_here set authkey password_goes_here # enable lqr set mrru 1450 set mtu 1450 set mru 1450 clone 1,2 link 1 set device 192.168.1.11:7900/tcp link 2 set device 192.168.1.14:7900/tcp link deflink remove link 1,2 set mode ddial #---end ppp.conf--- ppp on the office machine was started with: ppp -background multilink The co-lo machine's uname -v: FreeBSD 4.8-STABLE #1: Sat Jul 12 22:10:42 WST 2003 sdwyer@server..com.au:/usr/obj/usr/src/sys/SERVER The office machine's uname -v: FreeBSD 4.8-STABLE #0: Sat Jul 5 17:35:42 WST 2003 root@server..org.au:/usr/obj/usr/src/sys/SERVER Performance increase was about what I expected.. doing an FTP download we were seeing about 280kb/sec. Uploads were going at about 38kb/sec Not too bad considering it was a quick and dirty job. I tried to get it going with UDP but it refused to work for some reason. Perhaps MTU/MRU stuff could be tuned a bit more finely but in the end it wasnt going to be quite fast enough for the client. He was hoping to see 45kb/sec for uploads. Let me know how you go :) ive cc'd this to net@freebsd.org in the hope that it becomes useful to some one else also. Mabye something a bit too obscure for the FAQ or Handbook.. let me know if im wrong :) Cheers, -Shaun *im not subscribed to the net mailing list. Please email me directly* Leon Verheem wrote: > Have you had any luck setting up the multilinking? If so any tips you might have would be appreciated as I have a similar project > Leon Verheem > > Subject: Using multilink ppp(or similar) over 2 bridge mode ADSL connections... > From: sdwyer@arach.net.au (Shaun Dwyer) > Newsgroups: freebsd.net > Organization: TAC News Gateway > Date: Jul 25 2003 09:12:53 > Hi All, > > Please include me in the to: line as I'm not subscribed to this list(Thanks!). > > > I have a project where I need to be able to use the full available bandwidth of > 2x 1.5M/256k ADSL links. I will have a machine co-located at a local ISP shortly > and hope to run a ppp(or other?) server on that machine, and make 2 connections > to it from the home machine (one on each ADSL link). Has anyone done this > before? any ideas as to the best way to achieve this? Secure data transmission > is a must. I'm thinking that ipsec on the tunnel thats established would be > sufficient. > > This is more in an effort to gain full speed access to the machine terminating > the > remote end of the link. Access to the net via this multilink connection is not > important. > > > > TIA, > -Shaun > > > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 08:38:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9740F16A4B3 for ; Thu, 23 Oct 2003 08:38:41 -0700 (PDT) Received: from blake.polstra.com (dsl081-189-066.sea1.dsl.speakeasy.net [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B9F43FBD for ; Thu, 23 Oct 2003 08:38:40 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id h9NFcc8b091598; Thu, 23 Oct 2003 08:38:39 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 23 Oct 2003 08:38:38 -0700 (PDT) From: John Polstra To: Greg Black X-Bogosity: No, tests=bogofilter, spamicity=0.484612, version=0.14.5 cc: freebsd-net@freebsd.org Subject: Re: Remote Boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 15:38:41 -0000 On 22-Oct-2003 Greg Black wrote: > On 2003-10-20, Tobias P. Santos wrote: > >> I am trying to boot a FreeBSD diskless client with no success. >> Actually, I can boot the client, the kernel is downloaded and begins >> to boot. Then it tries to reach the DHCP/BOOT server, but this never >> occurs and the machine repeats the following messages forever: > > There is a nasty bug in most versions of the ISC DHCP code that > gave me a nasty time when attempting just this recently. > > Upgrading to the current DHCP code is essential. Upgrade which? The DHCP client, or the DHCP server? John From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 08:52:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 809CF16A4B3 for ; Thu, 23 Oct 2003 08:52:49 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B45E43FB1 for ; Thu, 23 Oct 2003 08:52:48 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9NFqlYL006952; Thu, 23 Oct 2003 11:52:47 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9NFqlAE006951; Thu, 23 Oct 2003 11:52:47 -0400 (EDT) (envelope-from barney) Date: Thu, 23 Oct 2003 11:52:47 -0400 From: Barney Wolff To: Wes Peters Message-ID: <20031023155247.GA6635@pit.databus.com> References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <20031021214932.GA659@saboteur.dek.spc.org> <20031021222307.GA80895@pit.databus.com> <200310230155.55363.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310230155.55363.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 15:52:49 -0000 On Thu, Oct 23, 2003 at 01:55:55AM -0700, Wes Peters wrote: > > To me it's not a matter of "boot code" vs. general usefulness so much as > it's just obviously the right way to do it. We use all-ones packets well > after boot to have our appliances identify each other on the network and > share configuration information, and it's not always evident which > network interface(s) they should be using to do this. What are you going to do when IPv6 comes into more general use, since it has no broadcast address? > The current code binds to each of the interfaces and blats out a packet, > but it just seems obvious that the all-ones address implies all attached > interfaces because you have a per-network broadcast address if you want > to do per-interface broadcasts. Yes. I would have expected AODV to use the net-broadcast address. I suspect that they did it to take advantage of the prohibition on forwarding packets with 255.255.255.255 dest - but that could have been done just as well by sending with ttl=1. The general answer to all of these issues is to use multicast rather than broadcast, as will be required anyway with IPv6. > I've been working with Bruce on this and there are parts that still worry > me. If you want to poke holes in the thinking we've been doing, I'm > always happy to have another set of eyeballs on the design and I'm sure > Bruce will too. Interactions with VLANs, for instance. If you send an > all-ones broadcast on an interface that has one or more VLANs configured, > do you repeat them "on" each VLAN as well? Ugh. What about > point-to-point links? Are those always considered gateways to a foreign > network, or just another form of locally attached network? The multicast notion would suggest that this be handled as a special case of multicast, with a pseudo group that can't occur naturally. That way you get "for free" to control which interfaces should send the broadcast, based on group membership. The whole VLAN thing is nasty, but I'd say that the general issue is does the box itself have a virtual interface on the VLAN, or is it merely switching on it. If the former, you send packets and process received packets up the stack. If the latter, you just do what any switch/bridge would do, because "you" (ie, higher layers) are not really on that layer-3 network. On point-to-point, I've never been really happy that the two ends can have addresses in different nets, but some people do it that way. I always prefered to define a /30 (or /31 if the code allows) for the link itself. But that difference solves the issue of whether the p2p link should be treated as local or not - if the far end is on a different subnet, it's remote; same subnet, it's local. > I'm pretty certain the code won't be all that difficult if we just fully > understand the problem before we jump in, but I'm also pretty certain we > don't fully understand the problem, let alone the solution. ;^) Allowing packets to 255.255.255.255 out an interface, $1.98. Deciding which interfaces to send on, priceless. Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 09:26:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B77216A4B3; Thu, 23 Oct 2003 09:26:24 -0700 (PDT) Received: from monster.schulte.org (monster.schulte.org [209.134.156.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C8E43F3F; Thu, 23 Oct 2003 09:26:23 -0700 (PDT) (envelope-from schulte+freebsd@nospam.schulte.org) Received: from localhost (localhost [127.0.0.1]) by monster.schulte.org (Postfix) with ESMTP id B90C51FB66; Thu, 23 Oct 2003 11:26:19 -0500 (CDT) Received: from thor (thor.schulte.org [209.134.156.204]) by monster.schulte.org (Postfix) with ESMTP id B424C1FB2F; Thu, 23 Oct 2003 11:26:18 -0500 (CDT) From: "Christopher Schulte" To: , Date: Thu, 23 Oct 2003 11:26:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcOZgnUOPNFCnynETbasNK3ZIPvMGw== Message-Id: <20031023162618.B424C1FB2F@monster.schulte.org> X-Virus-Scanned: by AMaViS 0.3.12pre8 on monster.schulte.org Subject: IPFW + BRIDGE: network capacity question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 16:26:24 -0000 Hello everyone. I have an Intel D815EGEW board with a single PIII 1GHZ, 256MEG RAM, 2 Intel Pro 100MB cards. This will be used as an IPFW+bridging firewall with FreeBSD 4.8 (RELENG_4_8, perhaps RELENG_4_9 when available). My message is about network capacity. Assume that it will be processing at peak all of this at once: 500 TCP connections with long lived sessions (an hour or more at a time) 500 UDP 'connections' 500 web (HTTP port 80 tcp) connections per second (graphics, small html pages) The HTTP sessions will be short lived, so lots of TCP handshakes at *least* a good portion will not utilize persistant HTTP The total bandwidth could be 20-50 megabits, mostly outbound to clients on the internet. Should I tweak the kernel at all for this? NMBCLUSTERS or NMBUFS? Something else? For IPFW, I figure that adding accept rules that catch most of the packets up front will help lower CPU usage. Is this correct? Maybe allow TCP if the session is established, allow setup of outbound TCP, allow setup of incoming TCP/80, allow outbound UDP packets to be happy, etc. Does anyone see any possible issues with this configuration and the expected network load? Thank you, folks! Any suggestions are very appreciated. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 11:24:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1064216A4BF for ; Thu, 23 Oct 2003 11:24:00 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3141C43FBF for ; Thu, 23 Oct 2003 11:23:59 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id h9NIRSbo021816 for ; Thu, 23 Oct 2003 11:27:28 -0700 (PDT) Received: from mac.com (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id h9NINvbn013979 for ; Thu, 23 Oct 2003 11:23:58 -0700 (PDT) Date: Thu, 23 Oct 2003 14:23:57 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Charles Swiger To: net@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <20031023155247.GA6635@pit.databus.com> Message-Id: <109F1559-0586-11D8-92E1-003065ABFD92@mac.com> X-Mailer: Apple Mail (2.552) Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 18:24:00 -0000 On Thursday, October 23, 2003, at 11:52 AM, Barney Wolff wrote: > On Thu, Oct 23, 2003 at 01:55:55AM -0700, Wes Peters wrote: [ ... ] > What are you going to do when IPv6 comes into more general use, since > it has no broadcast address? Are you asking what a IPv4-to-IPv6 translator (like gif?) should do, or are you worried about the case of a machine configured for IPv6 only and not for IPv4? I expect that most people will be using IPv4 for quite some time; we don't have to do something for the IPv6-only case to still have this be useful. >> Interactions with VLANs, for instance. If you send an >> all-ones broadcast on an interface that has one or more VLANs >> configured, >> do you repeat them "on" each VLAN as well? Ugh. What about >> point-to-point links? Are those always considered gateways to a >> foreign >> network, or just another form of locally attached network? > > The multicast notion would suggest that this be handled as a special > case of multicast, with a pseudo group that can't occur naturally. > That way you get "for free" to control which interfaces should send > the broadcast, based on group membership. Multicast and broadcast addressing are working at layer-3, but the point of using VLAN tags is to create logically 'seperate' networks where the flow of traffic is being handled/segregated at layer-2 rather than layer-3. > The whole VLAN thing is nasty, but I'd say that the general issue is > does the box itself have a virtual interface on the VLAN, or is it > merely switching on it. If the former, you send packets and process > received packets up the stack. If the latter, you just do what any > switch/bridge would do, because "you" (ie, higher layers) are not > really > on that layer-3 network. The all-ones broadcast is supposed to go to all physically connected network segments, regardless of whether a particular interface is ifconfig'ured with an IP that is part of a particular layer-3 subnet. You should be able to send the broadcast packet out from an interface which is up but does not have an IPv4 address assigned, right? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 11:37:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49B2316A4BF for ; Thu, 23 Oct 2003 11:37:51 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9F143FAF for ; Thu, 23 Oct 2003 11:37:50 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 43E955B686; Thu, 23 Oct 2003 11:33:37 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Barney Wolff Date: Thu, 23 Oct 2003 11:37:39 -0700 User-Agent: KMail/1.5.4 References: <20031020174751.60464.qmail@web20805.mail.yahoo.com> <200310230155.55363.wes@softweyr.com> <20031023155247.GA6635@pit.databus.com> In-Reply-To: <20031023155247.GA6635@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310231137.39590.wes@softweyr.com> cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 18:37:51 -0000 On Thursday 23 October 2003 08:52 am, Barney Wolff wrote: > On Thu, Oct 23, 2003 at 01:55:55AM -0700, Wes Peters wrote: > > To me it's not a matter of "boot code" vs. general usefulness so much > > as it's just obviously the right way to do it. We use all-ones > > packets well after boot to have our appliances identify each other on > > the network and share configuration information, and it's not always > > evident which network interface(s) they should be using to do this. > > What are you going to do when IPv6 comes into more general use, since > it has no broadcast address? Good question. I hope that happens in my lifetime; I've only got 30 or 40 years left in me. > > The current code binds to each of the interfaces and blats out a > > packet, but it just seems obvious that the all-ones address implies > > all attached interfaces because you have a per-network broadcast > > address if you want to do per-interface broadcasts. > > Yes. I would have expected AODV to use the net-broadcast address. I > suspect that they did it to take advantage of the prohibition on > forwarding packets with 255.255.255.255 dest - but that could have been > done just as well by sending with ttl=1. > > The general answer to all of these issues is to use multicast rather > than broadcast, as will be required anyway with IPv6. Hopefully IPv6 routers will get multicast routing right, too. You certainly can't count on that in the IPv4 realm. Even when the routers do support it, the network administrators usually don't, because they can barely grok IP routing to start with. > > I've been working with Bruce on this and there are parts that still > > worry me. If you want to poke holes in the thinking we've been > > doing, I'm always happy to have another set of eyeballs on the design > > and I'm sure Bruce will too. Interactions with VLANs, for instance. > > If you send an all-ones broadcast on an interface that has one or > > more VLANs configured, do you repeat them "on" each VLAN as well? > > Ugh. What about point-to-point links? Are those always considered > > gateways to a foreign network, or just another form of locally > > attached network? > > The multicast notion would suggest that this be handled as a special > case of multicast, with a pseudo group that can't occur naturally. > That way you get "for free" to control which interfaces should send > the broadcast, based on group membership. Bruce's design allows you to specify which interfaces participate in the "all ones" group with a sockopt (or was it sysctl?) That seems like a reasonable compromise between the logical viewpoint of "it's an all interfaces broadcast" and a security stance where you don't want broadcasts to go to ALL interfaces. > The whole VLAN thing is nasty, but I'd say that the general issue is > does the box itself have a virtual interface on the VLAN, or is it > merely switching on it. If the former, you send packets and process > received packets up the stack. If the latter, you just do what any > switch/bridge would do, because "you" (ie, higher layers) are not > really on that layer-3 network. Ah, excellent. I agree the VLAN implementation we have has a lot of warts. I don't have the dedicated time to tear into it myself, but I try to help other enterprising souls who want to take it on where I can. The last two both exploded, but I have high hopes for Bruce. ;^) > On point-to-point, I've never been really happy that the two ends can > have addresses in different nets, but some people do it that way. > I always prefered to define a /30 (or /31 if the code allows) for the > link itself. But that difference solves the issue of whether the p2p > link should be treated as local or not - if the far end is on a > different subnet, it's remote; same subnet, it's local. And if not, the link itself is usually an isolated network. That'll do. > > I'm pretty certain the code won't be all that difficult if we just > > fully understand the problem before we jump in, but I'm also pretty > > certain we don't fully understand the problem, let alone the > > solution. ;^) > > Allowing packets to 255.255.255.255 out an interface, $1.98. Deciding > which interfaces to send on, priceless. For everything else, there's MasterClue. Thanks for the help. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 11:47:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE5C516A4B3 for ; Thu, 23 Oct 2003 11:47:34 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 522BA43F3F for ; Thu, 23 Oct 2003 11:47:34 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 7E96472DA0; Thu, 23 Oct 2003 11:41:01 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Charles Swiger , net@freebsd.org Date: Thu, 23 Oct 2003 11:45:04 -0700 User-Agent: KMail/1.5.4 References: <109F1559-0586-11D8-92E1-003065ABFD92@mac.com> In-Reply-To: <109F1559-0586-11D8-92E1-003065ABFD92@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310231145.04241.wes@softweyr.com> Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 18:47:35 -0000 On Thursday 23 October 2003 11:23 am, Charles Swiger wrote: > On Thursday, October 23, 2003, at 11:52 AM, Barney Wolff wrote: > > On Thu, Oct 23, 2003 at 01:55:55AM -0700, Wes Peters wrote: > > [ ... ] > > > What are you going to do when IPv6 comes into more general use, since > > it has no broadcast address? > > Are you asking what a IPv4-to-IPv6 translator (like gif?) should do, or > are you worried about the case of a machine configured for IPv6 only > and not for IPv4? I expect that most people will be using IPv4 for > quite some time; we don't have to do something for the IPv6-only case > to still have this be useful. Porting broadcast applications to IPv6 requires re-thinking the problem, because IPv6 sheds some of the problems of IPv4 and introduces a few of it's own. Address assignment, for instance, is much less a problem in IPv6, but not having the addresses centrally managed (by either a program or a human) introduces it's own difficulties. > > The whole VLAN thing is nasty, but I'd say that the general issue is > > does the box itself have a virtual interface on the VLAN, or is it > > merely switching on it. If the former, you send packets and process > > received packets up the stack. If the latter, you just do what any > > switch/bridge would do, because "you" (ie, higher layers) are not > > really > > on that layer-3 network. > > The all-ones broadcast is supposed to go to all physically connected > network segments, regardless of whether a particular interface is > ifconfig'ured with an IP that is part of a particular layer-3 subnet. > You should be able to send the broadcast packet out from an interface > which is up but does not have an IPv4 address assigned, right? So long as it IS configured with the IPv4 protocol, I'd say yes. Ditto for VLANs. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 12:07:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 054AB16A4B3; Thu, 23 Oct 2003 12:07:18 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 111A143FAF; Thu, 23 Oct 2003 12:07:15 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 92B2766DD2; Thu, 23 Oct 2003 12:07:14 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 6DB0FDB3; Thu, 23 Oct 2003 12:07:14 -0700 (PDT) Date: Thu, 23 Oct 2003 12:07:14 -0700 From: Kris Kennaway To: ume@FreeBSD.org Message-ID: <20031023190714.GA84624@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: exclusive sleep mutex ifnet r = 0 (0xc07cc940) locked @ net/if.c:459 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 19:07:18 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Updated to HEAD, booted with WITNESS enabled, and the boot dies here: ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging unlimited malloc() of "16" with the following non-sleepable locks held: exclusive sleep mutex ifnet r = 0 (0xc07cc940) locked @ net/if.c:459 Debugger("witness_warn") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> trace Debugger(c070f058,c0c21ce8,1,c07396e3,c0778ec0) at Debugger+0x54 witness_warn(5,0,c074cdc7,c072620e,c07cc940) at witness_warn+0x19f uma_zalloc_arg(c103a900,0,2,0,c07cce74) at uma_zalloc_arg+0xa0 malloc(10,c0778ec0,2,1c,c077d100) at malloc+0xd3 in6_domifattach(c4742000,8c,c4742000,c07843f0,c26000) at in6_domifattach+0x27 if_attachdomain1(c4742000,0,c073e7c3,1cb,c0755fa4) at if_attachdomain1+0x3e if_attachdomain(0,c1e000,c1ec00,c1e000,0) at if_attachdomain+0x48 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c Can you please investigate? Kris --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/mCbiWry0BWjoQKURAiFzAJ4m0xBcO2qIgjMC+VhtTgNe0XtltQCg9bMg NA8U30VkfQJBqyazQXdlkDA= =Hf7q -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 12:40:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FB3F16A4BF for ; Thu, 23 Oct 2003 12:40:01 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF8343FCB for ; Thu, 23 Oct 2003 12:40:00 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9NJduHx026894; Thu, 23 Oct 2003 12:39:56 -0700 (PDT) Received: from mac.com (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0)h9NJdtbn010317; Thu, 23 Oct 2003 12:39:55 -0700 (PDT) Date: Thu, 23 Oct 2003 15:39:53 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: net@freebsd.org From: Charles Swiger In-Reply-To: <200310231145.04241.wes@softweyr.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 19:40:01 -0000 On Thursday, October 23, 2003, at 02:45 PM, Wes Peters wrote: >> The all-ones broadcast is supposed to go to all physically connected >> network segments, regardless of whether a particular interface is >> ifconfig'ured with an IP that is part of a particular layer-3 subnet. >> You should be able to send the broadcast packet out from an interface >> which is up but does not have an IPv4 address assigned, right? > > So long as it IS configured with the IPv4 protocol, I'd say yes. Ditto > for VLANs. Agreed. Some switches use a VLAN tag of 0 to indicate a "default VLAN", so it perhaps might be reasonable to select that rather than all of the logical VLAN interfaces configured against a physical parent interface. However, if the capability of choosing which interfaces should participate in the "all ones group" is already in Bruce's code, then that same mechanism could also be used to manage which VLAN interfaces get used. Also, Barney's comments here: > On point-to-point, I've never been really happy that the two ends can > have addresses in different nets, but some people do it that way. > I always prefered to define a /30 (or /31 if the code allows) for the > link itself. But that difference solves the issue of whether the p2p > link should be treated as local or not - if the far end is on a > different subnet, it's remote; same subnet, it's local. ...make sense to me as well, for whatever that may be worth.... :-) Take care, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 12:43:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBFD016A4BF for ; Thu, 23 Oct 2003 12:43:51 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C517743FBD for ; Thu, 23 Oct 2003 12:43:50 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9NJhoYL010236; Thu, 23 Oct 2003 15:43:50 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9NJhoRX010235; Thu, 23 Oct 2003 15:43:50 -0400 (EDT) (envelope-from barney) Date: Thu, 23 Oct 2003 15:43:50 -0400 From: Barney Wolff To: Charles Swiger Message-ID: <20031023194350.GA9424@pit.databus.com> References: <20031023155247.GA6635@pit.databus.com> <109F1559-0586-11D8-92E1-003065ABFD92@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <109F1559-0586-11D8-92E1-003065ABFD92@mac.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 19:43:52 -0000 On Thu, Oct 23, 2003 at 02:23:57PM -0400, Charles Swiger wrote: > >What are you going to do when IPv6 comes into more general use, since > >it has no broadcast address? > > Are you asking what a IPv4-to-IPv6 translator (like gif?) should do, or > are you worried about the case of a machine configured for IPv6 only > and not for IPv4? I expect that most people will be using IPv4 for > quite some time; we don't have to do something for the IPv6-only case > to still have this be useful. My expectation is the same as yours, but I strongly believe that anyone doing a new design that deliberately ignores IPv6 is being very shortsighted. "Quite some time" is now only years, not decades. > >>Interactions with VLANs, for instance. If you send an > >>all-ones broadcast on an interface that has one or more VLANs > >>configured, > >>do you repeat them "on" each VLAN as well? Ugh. What about > >>point-to-point links? Are those always considered gateways to a > >>foreign > >>network, or just another form of locally attached network? > > > >The multicast notion would suggest that this be handled as a special > >case of multicast, with a pseudo group that can't occur naturally. > >That way you get "for free" to control which interfaces should send > >the broadcast, based on group membership. > > Multicast and broadcast addressing are working at layer-3, but the > point of using VLAN tags is to create logically 'seperate' networks > where the flow of traffic is being handled/segregated at layer-2 rather > than layer-3. VLANs are meant to allow segregating a physical switch into multiple logical switches. VLAN tagging is used on inter-switch trunks, so that multiple logical switches can be connected by a single physical circuit. In either case, whether the switch *itself* (that is, its management interface) is on a particular VLAN depends on whether it has a level-3 address on that VLAN, at least in the normal case that a VLAN corresponds to an IP subnet. Since we're talking here of sending IP packets, that reasoning would seem to apply. (For level 2 purposes such as spanning tree, of course the switch is "on" every configured VLAN.) > >The whole VLAN thing is nasty, but I'd say that the general issue is > >does the box itself have a virtual interface on the VLAN, or is it > >merely switching on it. If the former, you send packets and process > >received packets up the stack. If the latter, you just do what any > >switch/bridge would do, because "you" (ie, higher layers) are not > >really > >on that layer-3 network. > > The all-ones broadcast is supposed to go to all physically connected > network segments, regardless of whether a particular interface is > ifconfig'ured with an IP that is part of a particular layer-3 subnet. > You should be able to send the broadcast packet out from an interface > which is up but does not have an IPv4 address assigned, right? In what sense are you using "supposed" - required by some standard, or simply what you'd like to have happen? If the former, please point to the standard. Sending a packet out from an interface with no IP address assigned leads immediately to the question of what source IP address to use, and how a responder knows where to send its response. Perhaps functions like this would be better accomplished at the link layer, not using IP at all, like ARP. If that were done, an interface using VLAN tagging should send the frame on each of its configured VLANs. "Physical" doesn't mean much when using VLANs. Among other things, the thing at the other end of the cable from a port using VLAN tagging may not approve of a frame sent with no tag (although cisco's can be configured with a default VLAN for that case). -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 12:47:32 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FFFF16A4B3 for ; Thu, 23 Oct 2003 12:47:32 -0700 (PDT) Received: from perrin.nxad.com (internal.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2281343FAF for ; Thu, 23 Oct 2003 12:47:31 -0700 (PDT) (envelope-from hmp@nxad.com) Received: by perrin.nxad.com (Postfix, from userid 1072) id 9C0AE20F01; Thu, 23 Oct 2003 12:47:30 -0700 (PDT) Date: Thu, 23 Oct 2003 12:47:30 -0700 From: Hiten Pandya To: Eli Dart Message-ID: <20031023194730.GA55808@perrin.nxad.com> References: <20031021140013.47D17C6C538@guns.icir.org> <20031021184601.98733F8EB@gemini.nersc.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20031021184601.98733F8EB@gemini.nersc.gov> X-Operating-System: FreeBSD FreeBSD 4.7-STABLE User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: SACK? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 19:47:32 -0000 On Tue, Oct 21, 2003 at 11:46:01AM -0700, Eli Dart wrote: :=20 : In reply to Mark Allman : :=20 : > =20 : > Hi folks! : >=20 : > Are there any plans to incorporate SACK in FreeBSD? It'd sure be : > handy for me to have (I prefer the *BSDs, and, alas, they are the : > only remaining SACK-less systems worth mentioning). I think there : > are research implementations that could be used as a basis (Luigi : > Rizzo did one, I think.). Any thoughts in this area? :=20 : In fact, OpenBSD has SACK -- this narrows the Field of the SACK-less=20 : to FreeBSD and NetBSD..... Only FreeBSD, because NetBSD has a sack implementation. Regards, --=20 Hiten Pandya hmp@FreeBSD.ORG From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 13:30:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A76016A4B3 for ; Thu, 23 Oct 2003 13:30:15 -0700 (PDT) Received: from mail.inka.de (quechua.inka.de [193.197.184.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E23AA43F3F for ; Thu, 23 Oct 2003 13:30:13 -0700 (PDT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with gbsmtp id 1ACm60-0004qN-01; Thu, 23 Oct 2003 22:30:12 +0200 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.10/8.12.10) with ESMTP id h9NKQ542003269 for ; Thu, 23 Oct 2003 22:26:05 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.10/8.12.10/Submit) id h9NKQ5dn003268 for freebsd-net@freebsd.org; Thu, 23 Oct 2003 22:26:05 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Thu, 23 Oct 2003 20:26:04 +0000 (UTC) Message-ID: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: em(4) and multicast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 20:30:15 -0000 OpenBSD has ported the em(4) driver from FreeBSD. At least on OpenBSD, em(4) is partially broken: it fails to receive multicast ethernet frames. This effectively breaks both IPv4 and IPv6 multicast, including IPv6 neighbor discovery. I have one report that says FreeBSD 4.9's em(4) has the same bug. Can any more people confirm that this breakage exists? In -CURRENT? I don't have a FreeBSD box with em(4). -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:15:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9492216A4D8 for ; Thu, 23 Oct 2003 14:15:23 -0700 (PDT) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id C36B543F75 for ; Thu, 23 Oct 2003 14:15:22 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9NLFK9D012080; Thu, 23 Oct 2003 14:15:20 -0700 (PDT) Received: from mac.com (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0)h9NLFGbn013312; Thu, 23 Oct 2003 14:15:19 -0700 (PDT) Date: Thu, 23 Oct 2003 17:15:14 -0400 Content-Type: text/plain; delsp=yes; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Barney Wolff From: Charles Swiger In-Reply-To: <20031023194350.GA9424@pit.databus.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:15:23 -0000 On Thursday, October 23, 2003, at 03:43 PM, Barney Wolff wrote: > On Thu, Oct 23, 2003 at 02:23:57PM -0400, Charles Swiger wrote: >>> What are you going to do when IPv6 comes into more general use, = since >>> it has no broadcast address? >> >> Are you asking what a IPv4-to-IPv6 translator (like gif?) should do, =20= >> or >> are you worried about the case of a machine configured for IPv6 only >> and not for IPv4? I expect that most people will be using IPv4 for >> quite some time; we don't have to do something for the IPv6-only case >> to still have this be useful. > > My expectation is the same as yours, but I strongly believe that > anyone doing a new design that deliberately ignores IPv6 is being very > shortsighted. "Quite some time" is now only years, not decades. There are people using IPv6 now, certainly. There are also a number of =20= possible opinions with regard to the utility of IPv6-- whether IPv6 can =20= solve problems sufficiently better than IPv4 (or IPv4 plus NAT, =20 particularly) as to make IPv6-only networks a reasonable alternative to =20= existing IPv4 networks is an open question. Perhaps I am being shortsighted in my focus on IPv4, but I don't think =20= that I am ignoring IPv6 so much as concluding that IPv4 all-ones =20 broadcast doesn't need to have a precise cognomen in the realm of IPv6 =20= to still be useful. No doubt the kind and friendly people on this list =20= will continue to point out any major bits of stupidity or =20 shortsightedness on my part in the future. :-) >> Multicast and broadcast addressing are working at layer-3, but the >> point of using VLAN tags is to create logically 'seperate' networks >> where the flow of traffic is being handled/segregated at layer-2 =20 >> rather >> than layer-3. > > VLANs are meant to allow segregating a physical switch into multiple > logical switches. That's the primary usage, certainly. You can use VLAN tags on a =20 non-switched environment, however, just as you can send packets for =20 more than one IP subnet over the same physical cabling. > VLAN tagging is used on inter-switch trunks, so > that multiple logical switches can be connected by a single physical > circuit. In either case, whether the switch *itself* (that is, its > management interface) is on a particular VLAN depends on whether it > has a level-3 address on that VLAN, at least in the normal case that > a VLAN corresponds to an IP subnet. The switches I have experience with-- 3com Superstack 2 and 3 family, =20= and Cisco equivalents-- implement VLAN membership on a per-port basis =20= via 802.1Q tagging of the packets (which can be used for hosts and not =20= just switches), as well as inter-switch connectivity (what 3com calls =20= VLT for Virtual LAN Trunk). > Since we're talking here of sending IP packets, that reasoning would =20= > seem to apply. (For level 2 purposes such as spanning tree, of course = =20 > the switch is "on" every > configured VLAN.) Things aren't always as simple-- please see page 201 of the following =20= document: http://support.3com.com/infodeli/tools/switches/s_stack2/1695/=20 manual.a01/manage.pdf "Figure 50 shows a network containing VLANs 1 and 2, and they are connected using the 802.1Q-tagged link between Switch B and Switch C. By default, this link has a path cost of 100 and is automatically =20 blocked because the other Switch-to-Switch connections have a path cost of 36 (18+18). This means that both VLANs are now subdivided =97 VLAN 1 on Switch units A and B cannot communicate with VLAN 1 on Switch C, and VLAN 2 on Switch units A and C cannot communicate with VLAN 2 on Switch B. [ ...diagram unrepresentable in ASCII... ] To avoid any VLAN subdivision, we recommend that all connections carrying traffic for multiple VLANs have a lower path cost than those carrying traffic for single VLANs. You can do this in two ways: 1=01 Using connections that have a higher bandwidth (which, by default, have a lower path cost) 2=01 Lowering the path cost of the connections using a Network Management application" >> The all-ones broadcast is supposed to go to all physically connected >> network segments, regardless of whether a particular interface is >> ifconfig'ured with an IP that is part of a particular layer-3 subnet. >> You should be able to send the broadcast packet out from an interface >> which is up but does not have an IPv4 address assigned, right? > > In what sense are you using "supposed" - required by some standard, > or simply what you'd like to have happen? If the former, please point > to the standard. Sending a packet out from an interface with no IP > address assigned leads immediately to the question of what source IP > address to use, and how a responder knows where to send its response. They might use a source IP that starts with 169.254, per technologies =20= called Rendevous at Apple, or "zero configuration" (Microsoft). http://www.zeroconf.org has IETF drafts which discuss this, and might =20= also explain my interest in bootstrapping a network without necessarily =20= having host network interfaces explicitly configured with valid IPs. > Among other things, the thing at the other end of the cable from a > port using VLAN tagging may not approve of a frame sent > with no tag (although cisco's can be configured with a default VLAN > for that case). Agreed, using a VLAN tag of 0 or 1 which represents the "default VLAN". --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:25:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADAD516A4B3 for ; Thu, 23 Oct 2003 14:25:57 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D8A43FBD for ; Thu, 23 Oct 2003 14:25:56 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9NLPt9H023880; Thu, 23 Oct 2003 14:25:55 -0700 (PDT) Received: from mac.com (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0)h9NLPjbn016832; Thu, 23 Oct 2003 14:25:54 -0700 (PDT) Date: Thu, 23 Oct 2003 17:25:42 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: net@freebsd.org From: Charles Swiger In-Reply-To: <20031023194350.GA9424@pit.databus.com> Message-Id: <74B738D2-059F-11D8-92E1-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: Barney Wolff Subject: Thoughts on IPv6, was: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:25:57 -0000 On Thursday, October 23, 2003, at 03:43 PM, Barney Wolff wrote: > My expectation is the same as yours, but I strongly believe that > anyone doing a new design that deliberately ignores IPv6 is being very > shortsighted. "Quite some time" is now only years, not decades. It might be useful to consider another perspective on IPv6: Begin forwarded message: > From: "Marcus J. Ranum" > Date: Wed Jul 30, 2003 10:26:00 AM America/New_York > To: Jonn Martell > Cc: firewall-wizards@honor.icsalabs.com > Subject: Re: [fw-wiz] Off topic: Any one know of a good IPV6 reference > book? > > I'm going to try to wrench this topic back to security, after > having taken a heavy-handed swat at the standards geeks. ;) > > Jonn Martell wrote: >> Doesn't V6 allow for end-to-end encryption and authentication? > > Well, if that's what you want, why not use the (various) IPV4 > ESP and AH implementations? Or SSH/SSL? > > From a meta-level, before you throw encryption into a security > solution, ask yourself "what am I trying to accomplish?" I happen > to believe that adding crypto into your network layer is pointless. > Basically, all it gives you is node-to-node trust. Node-to-node > trust is not exactly great, viz: .rhosts, NFS - they don't work > very well in environments where an untrusted user can gain > even a small toe-hold. People are just now *starting* to realize > that VPNs have a transitive trust problem. Node-to-node does > not address transitive trust effectively. IMO. If crypto is the answer, > what is the question? > > But if crypto is what you need, you can field it virtually instantly > using app-space crypto. Switching your whole network architecture > over just to get the same benefits you can get with SSH/SSL > seems like a lot of work to go through to avoid having to install > a single app on your client or server. > >> That would solve a lot of issues for secure networks. > > I really believe that IP crypto does not actually solve any > significant security problem in a compelling or useful manner. > >> And with the cap off addresses, it should make thing very >> interesting. > > If by "interesting" you mean "unmanageable" I've got to agree. :) > > What frustrates me about the whole IPV6 thing is that the nominal > reason for it was because of the address space issues. But there > were so many simpler options available that nobody wanted to > take because, frankly, everyone wanted to be part of the fun of > making up the next big standard. Which was *exactly* the > mindset that made the ISO protocols a slowly-developing > trainwreck. Suggestions for simpler (and equally effective) > approaches were shot down because implementing them would > have been less *fun*. My favorite was my buddy Andrew's > idea: quadruple the address space size, left-fill with zeroes, > bump the version number, and use GPS coordinates on the > left side of the address so that each individual square foot > of the planet had its own class C network. Of course you'd > need to re-do the routing infrastructure but you'll have to do > that with V6 anyhow... Or just double the address space, > bump the version, and left-fill with CIDR-style addresses > and let Moore's law take care of the backbone router > capacity issues. .. > > Anyhow, there were approaches to the address space > problem that were never investigated by the standards > priesthood because, well, they didn't give people a chance > to write gnarly code and re-design packet headers. Remember, > these standards guys are the same guys who called > SNMP "Simple..." their idea of a good time does not > produce efficient, effective real-world solutions. > >> It will change the Internet so that unauthenticated traffic will get >> a different class of service. > > No, it won't. Why? Because if that was going to happen, it would have > happened already. The technical underpinnings to do that already > exist; yet nobody is doing it. Most of the traffic on the Internet is > unauthenticated!! The trust model won't be much better than if you > just went into a load balancer and prioritized SSL, SSH, and known > IP addresses as higher priority than anything else. We can do that > today, but we don't - because it wouldn't make much difference and > it's a pain to manage. > >> NAT was a hack and although it works fine for small environments it >> falls apart for large user networks. The lack of auditing is pure >> nightmare for tracking down abuse from the inside in a large network. > > NAT is an appalling hack. NAT is an abomination. But I won't > apolgize for it. When I first started building firewalls, I NATed > networks not in order to save IP addresses, but because most > companies had existing networks with existing address ranges > and didn't want to re-address their whole infrastructure just to > get on the Internet. Does that sound familiar? My guess is that > the same logic will keep a lot of organizations from re-addressing > just to get the intangible benefits of IPV6. It wasn't until the mid > 1990's that IP addresses became a commodity and ISPs started > shoving NAT down their customers' throats. But now everyone > already has networks. Unless someone can show that IPV6 > is going to solve some problem that is SO VALUABLE it > justifies rebuilding networks. NAT + inertia is gonna kill IPV6... > >> I applaud the DOD efforts, they created the Internet and I have no >> doubt that mandating V6 will tip the scales for adoption. They did >> this in early 80 with IP, they'll do it again. > > It depends on the degree of the mandate. You may call my cynical > but I lived through "C2 by '92" and I don't believe that mandates mean > anything unless they are enforced and enforceable. > >> PS This is the first time that I find myself disagreeing with >> Marcus... > > You're in good company, if you do!!! :) Most of the smartest > people I know disagree with me about something or other!! :) > It's a badge of distinction! :) > > mjr. > > _______________________________________________ > firewall-wizards mailing list > firewall-wizards@honor.icsalabs.com > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:27:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3E216A4B3 for ; Thu, 23 Oct 2003 14:27:28 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138FB43FAF for ; Thu, 23 Oct 2003 14:27:28 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id B38C372E15; Thu, 23 Oct 2003 14:23:21 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Charles Swiger , net@freebsd.org Date: Thu, 23 Oct 2003 14:27:32 -0700 User-Agent: KMail/1.5.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310231427.32197.wes@softweyr.com> Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:27:28 -0000 On Thursday 23 October 2003 12:39, Charles Swiger wrote: > > Also, Barney's comments here: > ...make sense to me as well, for whatever that may be worth.... :-) Worth a lot, actually. If we can get 4 people looking at the problem from such diverse viewpoints and come to a point where we all agree (at least that it sucks less than the alternatives) the design is probably not too far off in the ozone. Now we just have to let Bruce implement it. Where *did* I put that intercontinental bullwhip???? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:40:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B61D16A4B3 for ; Thu, 23 Oct 2003 14:40:10 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A9743FBF for ; Thu, 23 Oct 2003 14:40:09 -0700 (PDT) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h9NLe70x009139 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 23 Oct 2003 14:40:09 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Thu, 23 Oct 2003 14:41:36 -0700 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310231441.36966.sam@errno.com> Subject: anyone believe this KASSERT? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:40:10 -0000 uipc_socket.c has a KASSERT in soreceive that I think is wrong. It dates from a long time ago but I can't tell exactly who created it since some intermediate munging buggered the CVS logs. cvs diff: Diffing . Index: uipc_socket.c =================================================================== RCS file: /usr/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.155 diff -u -r1.155 uipc_socket.c --- uipc_socket.c 21 Oct 2003 18:28:35 -0000 1.155 +++ uipc_socket.c 23 Oct 2003 20:33:04 -0000 @@ -855,9 +855,11 @@ (so->so_rcv.sb_cc < so->so_rcv.sb_lowat || ((flags & MSG_WAITALL) && uio->uio_resid <= so->so_rcv.sb_hiwat)) && m->m_nextpkt == 0 && (pr->pr_flags & PR_ATOMIC) == 0)) { +#if 0 KASSERT(m != 0 || !so->so_rcv.sb_cc, ("receive: m == %p so->so_rcv.sb_cc == %u", m, so->so_rcv.sb_cc)); +#endif if (so->so_error) { if (m) goto dontblock; In particular the m != 0 clause is suspicous since the enclosing if permits m to be 0 and the code inside carefully handles the case. I've been running w/o this assert for several weeks w/o a problem. Previously I was seeing it trip for NFS related traffic. Anyone care to justify keeping this? Sam From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:47:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FE6416A4B3 for ; Thu, 23 Oct 2003 14:47:50 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F87943F85 for ; Thu, 23 Oct 2003 14:47:49 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9NLlmYL012252; Thu, 23 Oct 2003 17:47:48 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9NLlmpV012251; Thu, 23 Oct 2003 17:47:48 -0400 (EDT) (envelope-from barney) Date: Thu, 23 Oct 2003 17:47:48 -0400 From: Barney Wolff To: Charles Swiger Message-ID: <20031023214748.GA11818@pit.databus.com> References: <20031023194350.GA9424@pit.databus.com> <74B738D2-059F-11D8-92E1-003065ABFD92@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74B738D2-059F-11D8-92E1-003065ABFD92@mac.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: net@freebsd.org Subject: Re: Thoughts on IPv6, was: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:47:50 -0000 On Thu, Oct 23, 2003 at 05:25:42PM -0400, Charles Swiger wrote: > On Thursday, October 23, 2003, at 03:43 PM, Barney Wolff wrote: > >My expectation is the same as yours, but I strongly believe that > >anyone doing a new design that deliberately ignores IPv6 is being very > >shortsighted. "Quite some time" is now only years, not decades. > > It might be useful to consider another perspective on IPv6: > > Begin rant from mjr :) There was *plenty* of opportunity to argue for ideas during the requirements and selection phases of IPng. People such as Noel Chiappa did so, lost and have remained critical. (fwiw, I had considerable sympathy for his ideas.) I can't comment on the behind-the-scenes stuff, if any, that went into the eventual selection, because I was not and am not an IETF insider, but there sure was plenty of public debate. Still is. It would be interesting to hear the views of folks from jp.freebsd.org and others from outside North America. But really I didn't intend to rave on about IPv6, just to propound multicast over broadcast, and that mostly because there is already a mechanism to control which interfaces to send on and to multiply packets outward. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 17:27:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C4AD16A4B3 for ; Thu, 23 Oct 2003 17:27:24 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 37DE443F93 for ; Thu, 23 Oct 2003 17:27:23 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 24 Oct 2003 01:27:22 +0100 (BST) To: Sam Leffler In-Reply-To: Your message of "Thu, 23 Oct 2003 14:41:36 PDT." <200310231441.36966.sam@errno.com> Date: Fri, 24 Oct 2003 01:27:20 +0100 From: Ian Dowse Message-ID: <200310240127.aa46705@salmon.maths.tcd.ie> cc: freebsd-net@freebsd.org Subject: Re: anyone believe this KASSERT? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 00:27:24 -0000 In message <200310231441.36966.sam@errno.com>, Sam Leffler writes: >uipc_socket.c has a KASSERT in soreceive that I think is wrong. It dates from > >a long time ago but I can't tell exactly who created it since some >intermediate munging buggered the CVS logs. It was there in revision 1.1 as: m = so->so_rcv.sb_mb; ... if (m == 0 || (...) && m->m_nextpkt == 0 && (pr->pr_flags & PR_ATOMIC) == 0) { #ifdef DIAGNOSTIC if (m == 0 && so->so_rcv.sb_cc) panic("receive 1"); #endif Seems to be clearer there except for the lack of brackets around the (a && b && c) - it's just saying that if sb_mb is NULL then sb_cc should be zero. The current code appears to do the same thing, so looks reasonable unless I'm missing something (sb_mb should be NULL when there is no data queued shouldn't it?). Digging back even further: REV:7.13 uipc_socket.c 1989/04/22 12:26:53 sklower checkpoint for version to be handed to NIST, simple tp4 connection ... - if (so->so_rcv.sb_cc == 0) { + m = so->so_rcv.sb_mb; + if (m == 0) { + if (so->so_rcv.sb_cc) + panic("receive 1"); Ian From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 18:11:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 846B216A4B3 for ; Thu, 23 Oct 2003 18:11:31 -0700 (PDT) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EE3343F75 for ; Thu, 23 Oct 2003 18:11:30 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from cpc3-ches1-4-0-cust213.lutn.cable.ntl.com ([213.105.213.213]) by mta06-svc.ntlworld.comESMTP <20031024011129.PICC12263.mta06-svc.ntlworld.com@cpc3-ches1-4-0-cust213.lutn.cable.ntl.com> for ; Fri, 24 Oct 2003 02:11:29 +0100 From: Dan To: freebsd-net@freebsd.org Date: Fri, 24 Oct 2003 02:10:14 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310240210.14992.dan@ntlbusiness.com> Subject: IPFW rules being weird? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 01:11:31 -0000 Hello there. Odd query for you. My setup is that sis0 is the ethernet which has the business cable modem attached to it - which serves as a gateway. sis1 is the Ethernet which my laptop connects to (wirelessly through a HE501 wireless pc card, and HE102 access point (both by Netgear)). The problem that is occuring, is that if I have the IPFW rules below, everything works GREAT! fwcmd="/sbin/ipfw" $fwcmd -f flush $fwcmd add divert natd all from any to any via sis0 $fwcmd add allow all from any to any $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 However, the above is not "secure" as you might say. The script below stops the laptop from being able to access th enet and i have NO idea why! # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Divert all packets through the tunnel interface. $fwcmd add 50 divert natd all from any to any via sis0 # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add pass tcp from any to any established # Allow all localhost connections ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # Allow all connections from my network card that I initiate $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state $fwcmd add allow all from 192.168.0.0/24 to any # Everyone on the Internet is allowed to connect to the following # services on the machine. This example specifically allows connections # to sshd and a webserver. $fwcmd add allow tcp from any to any established $fwcmd add allow tcp from any to me 80 setup $fwcmd add allow tcp from any to me 21 setup $fwcmd add allow tcp from any to me 22 setup # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to me 113 in recv any # Enable ICMP: remove type 8 if you don't want your host to be pingable $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Deny all the rest. $fwcmd add deny log ip from any to any If you can help with this it'd be much appreciated. Thanks!!! Running FreeBSD 4.8-RELEASE. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 18:48:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CC6E16A4B3 for ; Thu, 23 Oct 2003 18:48:17 -0700 (PDT) Received: from mx.carrel.org (adsl-64-91-104-251.gh.customer.centurytel.net [64.91.104.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65ADD43FAF for ; Thu, 23 Oct 2003 18:48:14 -0700 (PDT) (envelope-from william.a@carrel.org) Received: from carrel.org (teacup198.carrel.org [172.16.1.198]) by mx.carrel.org (Postfix) with ESMTP id 69B2438; Thu, 23 Oct 2003 18:48:17 -0700 (PDT) In-Reply-To: <71E524D5-0424-11D8-8EA7-000A95B9474C@apple.com> References: <1F8C654D-0401-11D8-8EA7-000A95B9474C@apple.com> <71E524D5-0424-11D8-8EA7-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v581) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2163F72A-05C4-11D8-B2E9-003065D5E9A4@carrel.org> Content-Transfer-Encoding: 7bit From: William A.Carrel Date: Thu, 23 Oct 2003 18:48:13 -0700 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.581) Subject: kern/58359 (was: setsockopt IP_ADD_MEMBERSHIP not honored) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 01:48:17 -0000 I've filed PR's with a patch for this issue now to most of the affected operating systems. It's basically anything derived from 4.4BSDLite that hasn't already corrected for this issue. FreeBSD: kern/58359 NetBSD: kern/23221 OpenDarwin: bugzilla id 1062 OpenBSD: no reply, I'll refile later this evening. DragonflyBSD: sent mail I've done some testing against the FreeBSD-STABLE and -CURRENT flavors of this patch and it seems to (a) fix the problem behavior described earlier in this thread (b) have no detrimental effect to the rest of the system. -- Andy From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 20:02:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3595116A4B3; Thu, 23 Oct 2003 20:02:18 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE79943FD7; Thu, 23 Oct 2003 20:02:16 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 2109766DCC; Thu, 23 Oct 2003 20:02:16 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id E990ECBE; Thu, 23 Oct 2003 20:02:15 -0700 (PDT) Date: Thu, 23 Oct 2003 20:02:15 -0700 From: Kris Kennaway To: Kris Kennaway Message-ID: <20031024030215.GA86892@rot13.obsecurity.org> References: <20031023190714.GA84624@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20031023190714.GA84624@rot13.obsecurity.org> User-Agent: Mutt/1.4.1i cc: net@freebsd.org cc: ume@freebsd.org cc: current@freebsd.org Subject: Re: exclusive sleep mutex ifnet r = 0 (0xc07cc940) locked @ net/if.c:459 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 03:02:18 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2003 at 12:07:14PM -0700, Kris Kennaway wrote: > Updated to HEAD, booted with WITNESS enabled, and the boot dies here: >=20 > ipfw2 initialized, divert disabled, rule-based forwarding enabled, defaul= t to accept, logging unlimited > malloc() of "16" with the following non-sleepable locks held: > exclusive sleep mutex ifnet r =3D 0 (0xc07cc940) locked @ net/if.c:459 > Debugger("witness_warn") > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 > db> trace > Debugger(c070f058,c0c21ce8,1,c07396e3,c0778ec0) at Debugger+0x54 > witness_warn(5,0,c074cdc7,c072620e,c07cc940) at witness_warn+0x19f > uma_zalloc_arg(c103a900,0,2,0,c07cce74) at uma_zalloc_arg+0xa0 > malloc(10,c0778ec0,2,1c,c077d100) at malloc+0xd3 > in6_domifattach(c4742000,8c,c4742000,c07843f0,c26000) at in6_domifattach+= 0x27 > if_attachdomain1(c4742000,0,c073e7c3,1cb,c0755fa4) at if_attachdomain1+0x= 3e > if_attachdomain(0,c1e000,c1ec00,c1e000,0) at if_attachdomain+0x48 > mi_startup() at mi_startup+0xb5 > begin() at begin+0x2c >=20 > Can you please investigate? I turned off WITNESS_DDB and it gives a lot of other warnings, including a number of these: exclusive sleep mutex ifnet r =3D 0 (0xc07cc940) locked @ netinet6/in6.c:22= 95 malloc() of "16" with the following non-sleepable locks held: Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/mJY3Wry0BWjoQKURAoiAAJ9kOZ8+qVcQ7xKeULPioRa1hWL/7gCaAmDc 6q+gL56tWDWDgdmr+/zqs5M= =kX4G -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 08:27:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ED6D16A4B3 for ; Fri, 24 Oct 2003 08:27:53 -0700 (PDT) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B50A43F3F for ; Fri, 24 Oct 2003 08:27:52 -0700 (PDT) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 696D96C810 for ; Fri, 24 Oct 2003 17:27:51 +0200 (CEST) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id A8A4A5B375; Fri, 24 Oct 2003 17:26:49 +0200 (CEST) To: Mailing List FreeBSD Network From: Eric Masson X-Operating-System: FreeBSD 4.9-PRERELEASE i386 Date: Fri, 24 Oct 2003 17:26:49 +0200 Message-ID: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 15:27:53 -0000 Hello, I'm facing a problem with the following setup : +-----------------+ DMZ +----+ LAN +------+ Internet ---------+ Tunnel Endpoint +-----+ Fw +-----+ Host | +-----------------+ +----+ +------+ "Tunnel Endpoint" : FreeBSD 4.8-RELEASE with fastipsec on a NET4801 "Fw" : Firewall 1 "Host" : Any host (tested with FreeBSD 5.1-CURRENT, Linux RH9) When I'm connecting to "Host" in "Lan" from a box connected to the other end of a tunnel managed by "Tunnel Endpoint", the following happens : - back traffic is composed of small sized packets, everything works fine - back traffic is composed of packets Lan mtu sized, connexion freezes. >From a tcpdump on the dmz interface of "Tunnel Endpoint", traffic from "Host" comes fine. Traffic on "Internet" interface differs depending on the size of packets coming from "Host" : - small sized packets : ESP tunnel packets with correct SPI flows out - Lan mtu sized packets : ESP tunnel packets frags If i reduce lan interface mtu on "Host" to approximately 1450, the tunnel works fine, so it seems that "Tunnel Endpoint" can't process correctly packets with a size of 1500 bytes. If more information regarding this issue is needed, just ask. Is this a known issue ? Except playing with mtu, is there a fix ? TIA Regards Eric Masson -- Attention tous message a l'encontre d'un usager de mediabarre sera signalé aux autoriter compétente -+- Crétin in : Con pas pétant signalé. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 09:19:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 677D416A4BF for ; Fri, 24 Oct 2003 09:19:04 -0700 (PDT) Received: from tenebras.com (dnscache.tenebras.com [66.92.188.165]) by mx1.FreeBSD.org (Postfix) with SMTP id A498443FBF for ; Fri, 24 Oct 2003 09:19:03 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 99114 invoked from network); 24 Oct 2003 16:19:03 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 24 Oct 2003 16:19:03 -0000 Message-ID: <3F9950F6.6000208@tenebras.com> Date: Fri, 24 Oct 2003 09:19:02 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Mailing List FreeBSD Network References: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> In-Reply-To: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 16:19:04 -0000 Eric Masson wrote: > If i reduce lan interface mtu on "Host" to approximately 1450, the > tunnel works fine, so it seems that "Tunnel Endpoint" can't process > correctly packets with a size of 1500 bytes. You should allow for an IP header with options and the ESP header, which is smaller than 1450. For SKIP I use 1366 as the advertised MTU, and for IPsec usually 1436, unless I need to accomodate ESP and AH, in which case it's smaller. > If more information regarding this issue is needed, just ask. > > Is this a known issue ? It's a known feature of any sort of IP encapsulation. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 12:05:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A9716A4B3 for ; Fri, 24 Oct 2003 12:05:50 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 422D243FA3 for ; Fri, 24 Oct 2003 12:05:49 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (rwcrmhc12) with ESMTP id <200310241905480140099ke7e>; Fri, 24 Oct 2003 19:05:48 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.8) with ESMTP id h9OJ5kJp044675; Fri, 24 Oct 2003 12:05:46 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p2/8.12.8/Submit) id h9OJ5iaR044674; Fri, 24 Oct 2003 12:05:44 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 24 Oct 2003 12:05:44 -0700 From: "Crist J. Clark" To: Dan Message-ID: <20031024190544.GA44312@blossom.cjclark.org> References: <200310240210.14992.dan@ntlbusiness.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310240210.14992.dan@ntlbusiness.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: IPFW rules being weird? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 19:05:50 -0000 On Fri, Oct 24, 2003 at 02:10:14AM +0100, Dan wrote: > Hello there. > Odd query for you. > > My setup is that sis0 is the ethernet which has the business cable modem > attached to it - which serves as a gateway. sis1 is the Ethernet which my > laptop connects to (wirelessly through a HE501 wireless pc card, and HE102 > access point (both by Netgear)). > > The problem that is occuring, is that if I have the IPFW rules below, > everything works GREAT! > > fwcmd="/sbin/ipfw" > $fwcmd -f flush > $fwcmd add divert natd all from any to any via sis0 > $fwcmd add allow all from any to any > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 That last rule is kinda useless considering the rule before it, no? > However, the above is not "secure" as you might say. > The script below stops the laptop from being able to access th enet and i have > NO idea why! Many problems. The most basic being: use setup-established orr use keep-state for a given traffic flow. Mixing them will likely cause administrator confusion. You may have some reasons to use both in this ruleset, but it is very confusion as is. The question of which to use for your NATed adresses is answered by Big Problem Two, keep-state and natd(8) do not play well together. See the many, many, many threads on this here, on -ipfw, and on -questions. The basic issue is that the address at your end of two-way connections has the unNATed address when it hits the keep-state rules coming in from the Internet and has the NATed address when going out. Thus, you get two dynamic rules that do not match up. That spells trouble. As for what precisely is breaking here, from a quick read, I would expect TCP connections to work briefly, but quickly timeout. My guess is the reason it seems you are unable to access the 'Net at all is that DNS lookups are totally broken. (All non-TCP traffic is totally blocked, unlike TCP which will limp along a little.) On the way out, your rule, allow ip from me to any out xmit any keep-state Will create a dynamic rule for the UDP traffic from the NAT address to the DNS server. But the response will go through the rules with a source of the remote DNS server and destination in 192.168.0.0/24 which will NOT match at the keep-state or any other rule until the default drop. Are you seeing these in the logs? Or are you running DNS server on the firewall (which would actually work)? > # Define the firewall command (as in /etc/rc.firewall) for easy > # reference. Helps to make it easier to read. > fwcmd="/sbin/ipfw" > > # Force a flushing of the current rules before we reload. > $fwcmd -f flush > > # Divert all packets through the tunnel interface. > $fwcmd add 50 divert natd all from any to any via sis0 > > # Allow all connections that have dynamic rules built for them, > # but deny established connections that don't have a dynamic rule. > # See ipfw(8) for details. > $fwcmd add check-state > $fwcmd add pass tcp from any to any established > > # Allow all localhost connections > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny all from any to 127.0.0.0/8 > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > > # Allow all connections from my network card that I initiate > $fwcmd add allow tcp from me to any out xmit any setup keep-state > $fwcmd add deny tcp from me to any > $fwcmd add allow ip from me to any out xmit any keep-state > $fwcmd add allow all from 192.168.0.0/24 to any > > # Everyone on the Internet is allowed to connect to the following > # services on the machine. This example specifically allows connections > # to sshd and a webserver. > $fwcmd add allow tcp from any to any established > $fwcmd add allow tcp from any to me 80 setup > $fwcmd add allow tcp from any to me 21 setup > $fwcmd add allow tcp from any to me 22 setup > > # This sends a RESET to all ident packets. > $fwcmd add reset log tcp from any to me 113 in recv any > > # Enable ICMP: remove type 8 if you don't want your host to be pingable > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 > > # Deny all the rest. > $fwcmd add deny log ip from any to any -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 12:28:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DADDE16A4B3 for ; Fri, 24 Oct 2003 12:28:30 -0700 (PDT) Received: from manganese.bos.dyndns.org (manganese.bos.dyndns.org [63.208.196.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF96243FD7 for ; Fri, 24 Oct 2003 12:28:29 -0700 (PDT) (envelope-from twilde@dyndns.org) Received: from manganese.bos.dyndns.org (twilde@localhost [127.0.0.1]) h9OJSSfx043237 for ; Fri, 24 Oct 2003 15:28:28 -0400 (EDT) (envelope-from twilde@dyndns.org) Received: from localhost (twilde@localhost)h9OJSSvw043234 for ; Fri, 24 Oct 2003 15:28:28 -0400 (EDT) X-Authentication-Warning: manganese.bos.dyndns.org: twilde owned process doing -bs Date: Fri, 24 Oct 2003 15:28:28 -0400 (EDT) From: Tim Wilde X-X-Sender: twilde@manganese.bos.dyndns.org To: net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: -5.8 () BAYES_01,USER_AGENT_PINE,X_AUTH_WARNING X-Scanned-By: MIMEDefang 2.36 Subject: Bridging Packet Loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 19:28:31 -0000 I'm experiencing 2-3% packet loss in a bridging configuration on a FreeBSD 4.8-p13 box, Intel Celeron 700MHz with 256MB RAM, dual fxp NICs (it's a Dell Poweredge 350). I'm running ipfw2 rules on the bridge, but have ruled them out as the cause of the loss by clearing them out - the loss still occurs. We're seeing around 5Mbps of traffic bidirectionally across the server. We were running this exact same packet load, with the same server and the same firewall rules, as a router, without this loss. The packet loss is observed pinging the IP on the firewall from the inside network, as well as pinging across the bridge. Output from ifconfig and relevant sysctls is below. Anyone have any suggestions as to what might be causing this or how we could rectify it? Both ends of both connections are locked down to 100Mbps full-duplex (server and switches). Thanks! fxp0: flags=8943 mtu 1500 inet6 fe80::202:b3ff:fe86:8afc%fxp0 prefixlen 64 scopeid 0x1 ether 00:02:b3:86:8a:fc media: Ethernet 100baseTX status: active fxp1: flags=8943 mtu 1500 inet6 fe80::202:b3ff:fe86:8afd%fxp1 prefixlen 64 scopeid 0x2 inet 63.208.196.57 netmask 0xffffff80 broadcast 63.208.196.127 ether 00:02:b3:86:8a:fd media: Ethernet 100baseTX status: active net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.bridge_cfg: fxp0,fxp1 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 net.link.ether.verbose: 0 net.link.ether.bdg_split_pkts: 0 net.link.ether.bdg_thru: 352262925 net.link.ether.bdg_copied: 0 net.link.ether.bdg_copy: 0 net.link.ether.bdg_predict: 481965741 net.link.ether.bdg_fw_avg: 0 net.link.ether.bdg_fw_ticks: 0 net.link.ether.bdg_fw_count: 0 net.link.ether.ipfw: 0 If anyone needs anything else to diagnose, let me know. Thanks. Tim Wilde -- Tim Wilde twilde@dyndns.org Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 14:24:46 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D7216A4B3 for ; Fri, 24 Oct 2003 14:24:46 -0700 (PDT) Received: from manganese.bos.dyndns.org (manganese.bos.dyndns.org [63.208.196.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C98343FBF for ; Fri, 24 Oct 2003 14:24:45 -0700 (PDT) (envelope-from twilde@dyndns.org) Received: from manganese.bos.dyndns.org (twilde@localhost [127.0.0.1]) h9OLOifx055786 for ; Fri, 24 Oct 2003 17:24:44 -0400 (EDT) (envelope-from twilde@dyndns.org) Received: from localhost (twilde@localhost)h9OLOit8055783 for ; Fri, 24 Oct 2003 17:24:44 -0400 (EDT) X-Authentication-Warning: manganese.bos.dyndns.org: twilde owned process doing -bs Date: Fri, 24 Oct 2003 17:24:44 -0400 (EDT) From: Tim Wilde X-X-Sender: twilde@manganese.bos.dyndns.org To: net@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: -7.1 () BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING X-Scanned-By: MIMEDefang 2.36 Subject: Re: Bridging Packet Loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 21:24:46 -0000 On Fri, 24 Oct 2003, Tim Wilde wrote: > I'm experiencing 2-3% packet loss in a bridging configuration on a FreeBSD > 4.8-p13 box, Intel Celeron 700MHz with 256MB RAM, dual fxp NICs (it's a > Dell Poweredge 350). Okay, ignore this - my switch was being stupid. Locked on both ends, packet loss. Auto-neg both ends, works fine. Sorry to waste everyone's time/bandwidth. Tim -- Tim Wilde twilde@dyndns.org Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 14:34:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0219416A4C3; Fri, 24 Oct 2003 14:34:34 -0700 (PDT) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F5A443F75; Fri, 24 Oct 2003 14:34:32 -0700 (PDT) (envelope-from dan@ntlbusiness.com) Received: from mta2-svc ([10.137.100.67]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20031024213431.CCCH8170.mta02-svc.ntlworld.com@mta2-svc>; Fri, 24 Oct 2003 22:34:31 +0100 X-Originating-IP: [213.105.213.213] From: To: "Crist J. Clark" , freebsd-net@freebsd.org Date: Fri, 24 Oct 2003 21:34:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20031024213431.CCCH8170.mta02-svc.ntlworld.com@mta2-svc> Subject: Re: Re: IPFW rules being weird? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2003 21:34:34 -0000 Hi there. Thank you for your reply! This is all very confusing, hehe! I'm not running a DNS server, the laptop which access through NAT I've set the nameservers as those of my ISP (and those listed in /etc/resolv.conf) of the FreeBSD box. Is there anything to particulary think should not be there, apart from that: > > allow ip from me to any out xmit any keep-state > Your help is really appreciated on this. Many thanks! > > From: "Crist J. Clark" > Date: 2003/10/24 Fri PM 07:05:44 GMT > To: Dan > CC: freebsd-net@freebsd.org > Subject: Re: IPFW rules being weird? > > On Fri, Oct 24, 2003 at 02:10:14AM +0100, Dan wrote: > > Hello there. > > Odd query for you. > > > > My setup is that sis0 is the ethernet which has the business cable modem > > attached to it - which serves as a gateway. sis1 is the Ethernet which my > > laptop connects to (wirelessly through a HE501 wireless pc card, and HE102 > > access point (both by Netgear)). > > > > The problem that is occuring, is that if I have the IPFW rules below, > > everything works GREAT! > > > > fwcmd="/sbin/ipfw" > > $fwcmd -f flush > > $fwcmd add divert natd all from any to any via sis0 > > $fwcmd add allow all from any to any > > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 > > That last rule is kinda useless considering the rule before it, no? > > > However, the above is not "secure" as you might say. > > The script below stops the laptop from being able to access th enet and i have > > NO idea why! > > Many problems. The most basic being: use setup-established orr use > keep-state for a given traffic flow. Mixing them will likely cause > administrator confusion. You may have some reasons to use both in this > ruleset, but it is very confusion as is. > > The question of which to use for your NATed adresses is answered by > Big Problem Two, keep-state and natd(8) do not play well together. See > the many, many, many threads on this here, on -ipfw, and on > -questions. The basic issue is that the address at your end of two-way > connections has the unNATed address when it hits the keep-state rules > coming in from the Internet and has the NATed address when going > out. Thus, you get two dynamic rules that do not match up. That spells > trouble. > > As for what precisely is breaking here, from a quick read, I would > expect TCP connections to work briefly, but quickly timeout. My guess > is the reason it seems you are unable to access the 'Net at all is > that DNS lookups are totally broken. (All non-TCP traffic is totally > blocked, unlike TCP which will limp along a little.) On the way out, > your rule, > > allow ip from me to any out xmit any keep-state > > Will create a dynamic rule for the UDP traffic from the NAT address to > the DNS server. But the response will go through the rules with a > source of the remote DNS server and destination in 192.168.0.0/24 > which will NOT match at the keep-state or any other rule until the > default drop. Are you seeing these in the logs? Or are you running DNS > server on the firewall (which would actually work)? > > > # Define the firewall command (as in /etc/rc.firewall) for easy > > # reference. Helps to make it easier to read. > > fwcmd="/sbin/ipfw" > > > > # Force a flushing of the current rules before we reload. > > $fwcmd -f flush > > > > # Divert all packets through the tunnel interface. > > $fwcmd add 50 divert natd all from any to any via sis0 > > > > # Allow all connections that have dynamic rules built for them, > > # but deny established connections that don't have a dynamic rule. > > # See ipfw(8) for details. > > $fwcmd add check-state > > $fwcmd add pass tcp from any to any established > > > > # Allow all localhost connections > > ${fwcmd} add 100 pass all from any to any via lo0 > > ${fwcmd} add 200 deny all from any to 127.0.0.0/8 > > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > > > > # Allow all connections from my network card that I initiate > > $fwcmd add allow tcp from me to any out xmit any setup keep-state > > $fwcmd add deny tcp from me to any > > $fwcmd add allow ip from me to any out xmit any keep-state > > $fwcmd add allow all from 192.168.0.0/24 to any > > > > # Everyone on the Internet is allowed to connect to the following > > # services on the machine. This example specifically allows connections > > # to sshd and a webserver. > > $fwcmd add allow tcp from any to any established > > $fwcmd add allow tcp from any to me 80 setup > > $fwcmd add allow tcp from any to me 21 setup > > $fwcmd add allow tcp from any to me 22 setup > > > > # This sends a RESET to all ident packets. > > $fwcmd add reset log tcp from any to me 113 in recv any > > > > # Enable ICMP: remove type 8 if you don't want your host to be pingable > > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 > > > > # Deny all the rest. > > $fwcmd add deny log ip from any to any > > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > From owner-freebsd-net@FreeBSD.ORG Sat Oct 25 00:01:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B31F16A4B3; Sat, 25 Oct 2003 00:01:30 -0700 (PDT) Received: from mx.carrel.org (adsl-64-91-104-251.gh.customer.centurytel.net [64.91.104.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C7E443FE3; Sat, 25 Oct 2003 00:00:47 -0700 (PDT) (envelope-from william.a@carrel.org) Received: from carrel.org (teacup198.carrel.org [172.16.1.198]) by mx.carrel.org (Postfix) with ESMTP id 694331BF; Sat, 25 Oct 2003 00:00:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v581) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William A.Carrel Date: Sat, 25 Oct 2003 00:00:47 -0700 To: freebsd-gnats-submit@FreeBSD.org, William A.Carrel X-Mailer: Apple Mail (2.581) cc: freebsd-net@freebsd.org Subject: Re: kern/58359: Strict Multicast Membership (patch w/ sysctl knob) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2003 07:01:30 -0000 I've been told thirdhand that there has been some amount of handwringing regarding this PR. My impression is that the worries mainly surround the fact that certain programs may depend on the fairly sparsely documented (http://www.kohala.com/start/mcast.api.txt) behavior currently shown. Change in behavior of decades old code can certainly be a concern, yet I would also like to see the option of the new behavior (which I'm told matches Solaris), therefore... Here is a new patch which provides a sysctl to turn this "extra" filtering on and off. net.inet.udp.strict_mcast_mship. It defaults to off so as to reduce any risk of POLA violation to zero. This also can help push any bikeshed discussions about the default into the future. ;-) If it would help, I can also work on providing a patch for the ip(4) manpage to reflect this option and/or note the current stack behavior more explicitly. Please feel free to let me know what you think, or feel free to let word of what you think drift through a few layers of indirection before it gets to me. I'll do what I can to mitigate concerns either way. :-) Thanks for reading. --- freebsd_current_udp_usrreq.c.orig Fri Oct 24 12:35:36 2003 +++ freebsd_current_udp_usrreq.c Fri Oct 24 23:19:11 2003 @@ -108,6 +108,10 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blackhole, CTLFLAG_RW, &blackhole, 0, "Do not send port unreachables for refused connects"); +static int strict_mcast_mship = 0; +SYSCTL_INT(_net_inet_udp, OID_AUTO, strict_mcast_mship, CTLFLAG_RW, + &strict_mcast_mship, 0, "Only send multicast to member sockets"); + struct inpcbhead udb; /* from udp_var.h */ #define udb6 udb /* for KAME src sync over BSD*'s */ struct inpcbinfo udbinfo; @@ -306,6 +310,28 @@ ip->ip_src.s_addr || inp->inp_fport != uh->uh_sport) goto docontinue; + } + /* + * Check multicast packets to make sure they are only + * sent to sockets with multicast memberships for the + * packet's destination address and arrival interface + */ + if (strict_mcast_mship && + IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && + inp->inp_moptions != NULL) { + int mshipno; + + for (mshipno = 0; + mshipno <= inp->inp_moptions->imo_num_memberships; + ++mshipno) { + if (ip->ip_dst.s_addr == inp->inp_moptions->imo_membership[mshipno]->inm_addr.s_addr && m->m_pkthdr.rcvif == inp->inp_mo +ptions->imo_membership[mshipno]->inm_ifp) + break; + } + if (mshipno == + inp->inp_moptions->imo_num_memberships) + goto docontinue; + } if (last != NULL) { --- freebsd_stable_udp_usrreq.c.orig Fri Oct 24 12:35:46 2003 +++ freebsd_stable_udp_usrreq.c Fri Oct 24 23:22:01 2003 @@ -102,6 +102,10 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blackhole, CTLFLAG_RW, &blackhole, 0, "Do not send port unreachables for refused connects"); +static int strict_mcast_mship = 0; +SYSCTL_INT(_net_inet_udp, OID_AUTO, strict_mcast_mship, CTLFLAG_RW, + &strict_mcast_mship, 0, "Only send multicast to member sockets"); + struct inpcbhead udb; /* from udp_var.h */ #define udb6 udb /* for KAME src sync over BSD*'s */ struct inpcbinfo udbinfo; @@ -290,6 +294,27 @@ if (inp->inp_faddr.s_addr != ip->ip_src.s_addr || inp->inp_fport != uh->uh_sport) + continue; + } + /* + * Check multicast packets to make sure they are only + * sent to sockets with multicast memberships for the + * packet's destination address and arrival interface + */ + if (strict_mcast_mship && + IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && + inp->inp_moptions != NULL) { + int mshipno; + + for (mshipno = 0; + mshipno <= + inp->inp_moptions->imo_num_memberships; + ++mshipno) { + if (ip->ip_dst.s_addr == inp->inp_moptions->imo_membership[mshipno]->inm_addr.s_addr && m->m_pkthdr.rcvif == inp->inp_moptions->imo_membership[mshipno]->inm_ifp) + break; + } + if (mshipno == + inp->inp_moptions->imo_num_memberships) continue; } From owner-freebsd-net@FreeBSD.ORG Sat Oct 25 12:04:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52F2E16A4B3 for ; Sat, 25 Oct 2003 12:04:44 -0700 (PDT) Received: from imhotep.yuckfou.org (cust.89.117.adsl.cistron.nl [195.64.89.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4DC43FD7 for ; Sat, 25 Oct 2003 12:04:42 -0700 (PDT) (envelope-from nivo+sender+8eb026@yuckfou.org) Received: from localhost (localhost [127.0.0.1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 5A431A4 for ; Sat, 25 Oct 2003 21:05:56 +0200 (CEST) Received: from imhotep.yuckfou.org ([127.0.0.1]) by localhost (imhotep.yuckfou.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19952-09 for ; Sat, 25 Oct 2003 21:05:55 +0200 (CEST) Received: from localhost.yuckfou.org (localhost [IPv6:::1]) by imhotep.yuckfou.org (Postfix) with ESMTP id ABD918E for ; Sat, 25 Oct 2003 21:05:55 +0200 (CEST) Received: from yuckfou.org (turbata-xp [192.168.2.236]) by localhost.yuckfou.org (tmda-ofmipd) with ESMTP; Sat, 25 Oct 2003 21:05:42 +0200 (CEST) Message-ID: <3F9AC937.4070200@yuckfou.org> Date: Sat, 25 Oct 2003 21:04:23 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Nils Vogels X-Delivery-Agent: TMDA/0.86 (Venetian Way) X-TMDA-Fingerprint: KKcf9hvUpVnbiraobHG26gRrC7M X-Virus-Scanned: by amavisd-new at yuckfou.org Subject: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nils Vogels List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2003 19:04:44 -0000 Hi there! I'm trying to solve a situation that I have with a device which needs SNMP polling, but is not normally reachable to the outside world, because it cannot install a default gateway. In short, a situation scetch: SNMP-server (192.168.2.2/24) ----------- +------------+ +-------------+ | | WWW |--------------------| Gateway | --------------+ +------------+ +-------------+ | 192.168.0.2/24 192.168.0.1 IP: 195.x.x.x.x \-----> Internet (0.0.0.0/0) (rl0) Alias: 192.168.2.1 (ed0) Now what I am trying to do is get statistics from the SNMP-server into the WWW box, but I am stuck on the following: WWW is a FreeBSD-4.8 box. Gateway is a FreeBSD-4.8 box with IP Filter Since the SNMP-server does not have a default route, the traffic needs to originate from an IP address within the same subnet as the Gateway. To that end, I have added an alias IP of 192.168.2.1 to the gateway. When I run an snmpwalk from the gateway all goes fine. Since the traffic is coming from WWW and heading through the Gateway, which does not bridge, I have to perform some form of NATting in the gateway. I've been searching and attempting various redirects and map entries, and am now stuck at: map rl0 from 192.168.0.0/24 to 192.168.2.0/24 port = 161 -> 192.168.2.1/32 I think I'm close .. can someone give me the final hint ? ;-) Thanks, Nils. From owner-freebsd-net@FreeBSD.ORG Sat Oct 25 17:32:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F40516A4B3 for ; Sat, 25 Oct 2003 17:32:16 -0700 (PDT) Received: from pike.mail.pike.ru (pike.mail.pike.ru [194.135.18.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB25743F3F for ; Sat, 25 Oct 2003 17:32:14 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 7803 invoked from network); 26 Oct 2003 00:33:39 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by pike.mail.pike.ru with SMTP; 26 Oct 2003 00:33:39 -0000 Received: (nullmailer pid 16845 invoked by uid 136); Sun, 26 Oct 2003 00:32:28 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <3F9AC937.4070200@yuckfou.org> To: Nils Vogels Date: Sun, 26 Oct 2003 03:32:28 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1067128348.400238.16844.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 00:32:16 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > Hi there! > > I'm trying to solve a situation that I have with a device which needs > SNMP polling, but is not normally reachable to the outside world, > because it cannot install a default gateway. > > In short, a situation scetch: > > > > > SNMP-server (192.168.2.2/24) > > ----------- > +------------+ +-------------+ > | > | WWW |--------------------| Gateway | --------------+ > +------------+ > +-------------+ | > 192.168.0.2/24 192.168.0.1 IP: 195.x.x.x.x > \-----> Internet (0.0.0.0/0) > (rl0) Alias: > 192.168.2.1 > > (ed0) > > Now what I am trying to do is get statistics from the SNMP-server into > the WWW box, but I am stuck on the following: > > WWW is a FreeBSD-4.8 box. > Gateway is a FreeBSD-4.8 box with IP Filter > Since the SNMP-server does not have a default route, the traffic needs > to originate from an IP address within the same subnet as the Gateway. > To that end, I have added an alias IP of 192.168.2.1 to the gateway. > When I run an snmpwalk from the gateway all goes fine. > > Since the traffic is coming from WWW and heading through the Gateway, > which does not bridge, I have to perform some form of NATting in the > gateway. > > I've been searching and attempting various redirects and map entries, > and am now stuck at: > > map rl0 from 192.168.0.0/24 to 192.168.2.0/24 port = 161 -> 192.168.2.1/32 > > I think I'm close .. can someone give me the final hint ? ;-) configure port with SNMP-server as 192.168.0.17/30 for example instead 192.168.2.1/24, and sysctl net.link.ether.inet.proxyall=1 and configure SNMP-server as 192.168.0.18/24 If you can change mask of SNMP-server, you can use 192.168.0/24 and 192.168.1/24 on gateway and 192.168.0/25 on SNMP-server. No NAT is needed. From owner-freebsd-net@FreeBSD.ORG Sat Oct 25 19:00:55 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4873716A4B3 for ; Sat, 25 Oct 2003 19:00:55 -0700 (PDT) Received: from imhotep.yuckfou.org (cust.89.117.adsl.cistron.nl [195.64.89.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFE2B43FAF for ; Sat, 25 Oct 2003 19:00:53 -0700 (PDT) (envelope-from nivo+sender+8eb026@yuckfou.org) Received: from localhost (localhost [127.0.0.1]) by imhotep.yuckfou.org (Postfix) with ESMTP id AE8E48B for ; Sun, 26 Oct 2003 03:00:51 +0100 (CET) Received: from imhotep.yuckfou.org ([127.0.0.1]) by localhost (imhotep.yuckfou.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37504-07 for ; Sun, 26 Oct 2003 03:00:51 +0100 (CET) Received: from localhost.yuckfou.org (localhost [IPv6:::1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 33E668A for ; Sun, 26 Oct 2003 03:00:51 +0100 (CET) Received: from yuckfou.org (turbata-xp [192.168.2.236]) by localhost.yuckfou.org (tmda-ofmipd) with ESMTP; Sun, 26 Oct 2003 03:00:48 +0100 (CET) Message-ID: <3F9B2AD0.3050005@yuckfou.org> Date: Sun, 26 Oct 2003 03:00:48 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1067128348.400238.16844.nullmailer@cicuta.babolo.ru> In-Reply-To: <1067128348.400238.16844.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From: Nils Vogels X-Delivery-Agent: TMDA/0.86 (Venetian Way) X-TMDA-Fingerprint: 3/ljHBgTBy/G5rRMx67Q70142II X-Virus-Scanned: by amavisd-new at yuckfou.org Subject: Re: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nils Vogels List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 02:00:55 -0000 "."@babolo.ru wrote: >>WWW is a FreeBSD-4.8 box. >>Gateway is a FreeBSD-4.8 box with IP Filter >>Since the SNMP-server does not have a default route, the traffic needs >>to originate from an IP address within the same subnet as the Gateway. >>To that end, I have added an alias IP of 192.168.2.1 to the gateway. >>When I run an snmpwalk from the gateway all goes fine. >> >>Since the traffic is coming from WWW and heading through the Gateway, >>which does not bridge, I have to perform some form of NATting in the >>gateway. >> >> >> >configure port with SNMP-server as 192.168.0.17/30 for example >instead 192.168.2.1/24, and >sysctl net.link.ether.inet.proxyall=1 > >and configure SNMP-server as 192.168.0.18/24 > >If you can change mask of SNMP-server, you can >use 192.168.0/24 and 192.168.1/24 on gateway >and 192.168.0/25 on SNMP-server. > > Since I have the internet on the same interface, but on the primary IP instead, would enabling ARP PROXY not fill the ARP table with every host on the internet, that tries to contact the gateway ? Greetings, Nils. From owner-freebsd-net@FreeBSD.ORG Sat Oct 25 20:06:33 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FF6716A4B3 for ; Sat, 25 Oct 2003 20:06:33 -0700 (PDT) Received: from imhotep.yuckfou.org (cust.89.117.adsl.cistron.nl [195.64.89.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8241543FBF for ; Sat, 25 Oct 2003 20:06:31 -0700 (PDT) (envelope-from nivo+sender+8eb026@yuckfou.org) Received: from localhost (localhost [127.0.0.1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 34EF3B0 for ; Sun, 26 Oct 2003 03:35:08 +0100 (CET) Received: from imhotep.yuckfou.org ([127.0.0.1]) by localhost (imhotep.yuckfou.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39283-09 for ; Sun, 26 Oct 2003 03:35:06 +0100 (CET) Received: from localhost.yuckfou.org (localhost [IPv6:::1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 959B6A4 for ; Sun, 26 Oct 2003 03:35:05 +0100 (CET) Received: from yuckfou.org (turbata-xp [192.168.2.236]) by localhost.yuckfou.org (tmda-ofmipd) with ESMTP; Sun, 26 Oct 2003 03:34:58 +0100 (CET) Message-ID: <3F9B32D2.7080804@yuckfou.org> Date: Sun, 26 Oct 2003 03:34:58 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1067128348.400238.16844.nullmailer@cicuta.babolo.ru> In-Reply-To: <1067128348.400238.16844.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From: Nils Vogels X-Delivery-Agent: TMDA/0.86 (Venetian Way) X-TMDA-Fingerprint: 7399RBAdoKjZi9vgBjezt0FOQBM X-Virus-Scanned: by amavisd-new at yuckfou.org Subject: Re: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nils Vogels List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 03:06:33 -0000 "."@babolo.ru wrote: >configure port with SNMP-server as 192.168.0.17/30 for example >instead 192.168.2.1/24, and >sysctl net.link.ether.inet.proxyall=1 > >and configure SNMP-server as 192.168.0.18/24 > >If you can change mask of SNMP-server, you can >use 192.168.0/24 and 192.168.1/24 on gateway >and 192.168.0/25 on SNMP-server. > >No NAT is needed. > > I just tried this, but unfortunately, the same thing happens as with ipfilter: The primary address of the interface ed0 on the gateway (the public adress) is used to forward the arp request. Taken from a dump on the gateay, when attempting telnet: Incoming on rl0: 03:35:05.867883 192.168.0.2.1511 > 192.168.2.2.23: S 1377718084:1377718084(0) win 57344 (DF) [tos 0x10] Outgoing on ed0: 03:35:05.868333 195.0.0.1.15009 > 192.168.2.2.23: S 1377718084:1377718084(0) win 57344 (DF) [tos 0x10] Since 195.0.0.1 (obviously obfuscated) does not fall within the subnet the 192.168.2.2 box is on, there will never be a reply from the 192.168.2.2 box. ARP proxying goes fine, on the WWW box, I can see the proxied reply coming from my gateway for the 192.168.1.1 address ..... Can anyone tell me, how I can make the box use the secondary address (alias) automatically for forwarding the telnet session? Could it be that since the gateway is running many-to-one NAT as well, this is conflicting ? Greetings, Nils.