From owner-freebsd-net Sun Sep 17 8:14:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id 0FA8F37B422 for ; Sun, 17 Sep 2000 08:14:15 -0700 (PDT) Received: from pooh.honeypot (root@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.0/8.11.0) with ESMTP id e8HFEDZ79749 for ; Sun, 17 Sep 2000 10:14:14 -0500 (CDT) (envelope-from kirk@strauser.com) Received: (from kirk@localhost) by pooh.honeypot (8.11.0/8.11.0/Debian 8.11.0-6) id e8HFECN16284; Sun, 17 Sep 2000 10:14:12 -0500 X-Authentication-Warning: pooh.honeypot: kirk set sender to kirk@strauser.com using -f To: freebsd-net@freebsd.org Subject: IPv6 woes From: Kirk Strauser Reply-To: kirk@strauser.com Date: 17 Sep 2000 10:14:12 -0500 Message-ID: <87og1nuk3f.fsf@pooh.honeypot> Lines: 29 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm running a FreeBSD 4.1-stable system. I went to www.freenet6.net to get a v6 address, and selected the FreeBSD/KAME option. Along with the tunkame.*.pl script, it sent me: Your IPv6 address : 3ffe:b00:c18:1fff:0:0:0:455 Freenet6 IPv6 address (server side) : 3ffe:b00:c18:1fff:0:0:0:454 Freenet6 IPv4 address (server side): 206.123.31.102 Your IPv4 address : 216.224.193.50 The script executed without errors. However, while I can ping the local and remote IPv4 address, and I can ping6 the local IPv6 address, I can't pin6 the remote end. The only error message I get, at all, is from /var/log/messages: /kernel: nd6_lookup: failed to add route for a neighbor(3ffe:0b00:0c18:1fff::0454), errno=17 Now, it's my understanding from what documentation I've been able to scrap up (I tried to RTFM, honest!), I shouldn't need to do any additional configuration on my system other than executing the tunkame Perl script. Am I missing something obvious? I'd *really* love to get up and running on the 6bone, but I can't seem to get past the starting gate. As always, any help is appreciated. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 9:23:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 74A0637B424 for ; Sun, 17 Sep 2000 09:23:46 -0700 (PDT) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.11.0/8.11.0) id e8HGNXt67029; Sun, 17 Sep 2000 12:23:33 -0400 (EDT)?g (envelope-from morganw)œ Date: Sun, 17 Sep 2000 12:23:33 -0400 (EDT) From: Wesley Morgan To: Kirk Strauser Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes In-Reply-To: <87og1nuk3f.fsf@pooh.honeypot> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17 Sep 2000, Kirk Strauser wrote: > I'm running a FreeBSD 4.1-stable system. I went to > www.freenet6.net to get a v6 address, and selected the > FreeBSD/KAME option. Along with the tunkame.*.pl script, it > sent me: > > Your IPv6 address : 3ffe:b00:c18:1fff:0:0:0:455 > Freenet6 IPv6 address (server side) : 3ffe:b00:c18:1fff:0:0:0:454 > Freenet6 IPv4 address (server side): 206.123.31.102 > Your IPv4 address : 216.224.193.50 > > The script executed without errors. However, while I can ping > the local and remote IPv4 address, and I can ping6 the local > IPv6 address, I can't pin6 the remote end. The only error > message I get, at all, is from /var/log/messages: > > /kernel: nd6_lookup: failed to add route for a > neighbor(3ffe:0b00:0c18:1fff::0454), errno=17 Make sure you delete any pre-existing default routes etc before running the script. Check your route table with 'netstat -rf inet6'. The best way to set up the tunnel you want would be with the proper rc.conf options: ipv6_enable="YES" gif_interfaces="gif0" ipv6_network_interfaces="gif0" #ipv6_static_routes="gif0" #ipv6_route_gif0="default 3ffe:b00:c18:1fff:0:0:0:455" gifconfig_gif0="216.224.193.50 206.123.31.102" ifconfig_gif0="inet6 3ffe:b00:c18:1fff:0:0:0:455 3ffe:b00:c18:1fff:0:0:0:454" You may or may not need the static routes, depending on your setup. This is based off my setup (not a freenet6 tunnel) and I think it will work, provided I did not get any of the addresses backwards. You may also need to set an "ipv6_default_interface" if you have multiple tunnels etc. BTW I run -current, so there may be some cosmetic differences... And of course there might be a "more correct" way to set it up with your init scripts. -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 9:54: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from rmx452-mta.mail.com (rmx452-mta.mail.com [165.251.48.46]) by hub.freebsd.org (Postfix) with ESMTP id 5F1DF37B424 for ; Sun, 17 Sep 2000 09:53:59 -0700 (PDT) Received: from web624-wrb.mail.com (web624-wrb.mail.com [165.251.33.64]) by rmx452-mta.mail.com (8.9.3/8.9.3) with SMTP id MAA20566; Sun, 17 Sep 2000 12:53:58 -0400 (EDT) Message-ID: <382805774.969209639079.JavaMail.root@web624-wrb.mail.com> Date: Sun, 17 Sep 2000 12:53:58 -0400 (EDT) From: Chris C To: Emmanuel Gravel , freebsd-net@FreeBSD.ORG Subject: RE: Strange TTL Exceeded messages Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 165.121.17.66 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------Original Message------ From: Emmanuel Gravel To: freebsd-net@FreeBSD.ORG Sent: September 10, 2000 5:07:13 PM GMT Subject: Strange TTL Exceeded messages According to "Hackers Exposed: Network Security Secrets and Solutions" by Stuart McClure, Joel Scambray and George Kurtz page 326 "Firewalk (http://www.packetfactory.net/firewalk/) is a nifty tool that, like a port scanner, will discover ports open behind a firewall..." "Firewalk works by constructing packets with an IP TTL calculated to expire one hop past the firewall. The theory is that if the packet is allowed by the firewall, it will be allowed to pass and will expire as expected, eliciting an "ICMP TTL expired in transit" message. On the other hand, if the packet is blocked by the firewall's ACL, it will be dropped, and either no response will be sent, or an ICMP type 13 admin prohibited filter packet will be sent" Prevention: block ICMP TTL Expired packets at external interface level You're under attack, this book i quoted is a really good way to glean a lot of information and preventative methods for system admins, and i garuantee that hackers are reading it, why shouldn't you? cc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 10: 5:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id A6C4737B422 for ; Sun, 17 Sep 2000 10:05:31 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA12684; Mon, 18 Sep 2000 01:48:51 +0900 (JST) Date: Mon, 18 Sep 2000 02:04:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kirk@strauser.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes In-Reply-To: In your message of "17 Sep 2000 10:14:12 -0500" <87og1nuk3f.fsf@pooh.honeypot> References: <87og1nuk3f.fsf@pooh.honeypot> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 10:11:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 4156A37B43C for ; Sun, 17 Sep 2000 10:11:24 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA12732; Mon, 18 Sep 2000 01:54:53 +0900 (JST) Date: Mon, 18 Sep 2000 02:10:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kirk@strauser.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes In-Reply-To: In your message of "17 Sep 2000 10:14:12 -0500" <87og1nuk3f.fsf@pooh.honeypot> References: <87og1nuk3f.fsf@pooh.honeypot> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 10:16:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 4F15837B422 for ; Sun, 17 Sep 2000 10:16:52 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA12792; Mon, 18 Sep 2000 02:00:22 +0900 (JST) Date: Mon, 18 Sep 2000 02:16:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kirk@strauser.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes In-Reply-To: In your message of "17 Sep 2000 10:14:12 -0500" <87og1nuk3f.fsf@pooh.honeypot> References: <87og1nuk3f.fsf@pooh.honeypot> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org XXX uhhh, sorry for the noisy messages...I hope this message has meaning... >>>>> On 17 Sep 2000 10:14:12 -0500, >>>>> Kirk Strauser said: > The script executed without errors. However, while I can ping > the local and remote IPv4 address, and I can ping6 the local > IPv6 address, I can't pin6 the remote end. The only error > message I get, at all, is from /var/log/messages: > /kernel: nd6_lookup: failed to add route for a > neighbor(3ffe:0b00:0c18:1fff::0454), errno=17 I believe this does not mean that your node failed to send packets. It was just a warning. So, if you don't mind, could you tell us the following information? 1. result of "ifconfig -a" 2. result of "gifconfig -a" 3. result of "netstat -rn" 4. output of "tcpdump -i gif0 -n" Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 10:57:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from casagate.staub.net (dsl-pstaub.pacifier.net [216.65.144.154]) by hub.freebsd.org (Postfix) with ESMTP id ED93C37B424 for ; Sun, 17 Sep 2000 10:57:08 -0700 (PDT) Received: by casagate.staub.net (Postfix, from userid 1000) id 8649C1B27; Sun, 17 Sep 2000 10:56:09 -0700 (PDT) Date: Sun, 17 Sep 2000 10:56:09 -0700 From: Phil Staub To: freebsd-net@freebsd.org Subject: Re: IPv6 woes Message-ID: <20000917105609.A94367@staub.net> Reply-To: phils@staub.net References: <87og1nuk3f.fsf@pooh.honeypot> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <87og1nuk3f.fsf@pooh.honeypot>; from kirk@strauser.com on Sun, Sep 17, 2000 at 10:14:12AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org By any chance are you trying to run this script from a machine behind a NATD firewall? I tried to do this and got exactly the same error message. A note to the freenet6 folks revealed that NATD doesn't yet know how to deal with the tunnelling packets. HTH Phil On Sun, Sep 17, 2000 at 10:14:12AM -0500, Kirk Strauser wrote: > I'm running a FreeBSD 4.1-stable system. I went to > www.freenet6.net to get a v6 address, and selected the > FreeBSD/KAME option. Along with the tunkame.*.pl script, it > sent me: > > Your IPv6 address : 3ffe:b00:c18:1fff:0:0:0:455 > Freenet6 IPv6 address (server side) : 3ffe:b00:c18:1fff:0:0:0:454 > Freenet6 IPv4 address (server side): 206.123.31.102 > Your IPv4 address : 216.224.193.50 > > The script executed without errors. However, while I can ping > the local and remote IPv4 address, and I can ping6 the local > IPv6 address, I can't pin6 the remote end. The only error > message I get, at all, is from /var/log/messages: > > /kernel: nd6_lookup: failed to add route for a > neighbor(3ffe:0b00:0c18:1fff::0454), errno=17 > -- Phil Staub, KE7HC phils@staub.net Unix: because reboots are for hardware upgrades To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 11: 1: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 8B23A37B424 for ; Sun, 17 Sep 2000 11:00:59 -0700 (PDT) Received: from localhost (localhost [::1]) (authenticated) by peace.mahoroba.org (8.11.0/8.11.0/peace) with ESMTP/inet6 id e8HI0AG00552; Mon, 18 Sep 2000 03:00:10 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 18 Sep 2000 03:00:07 +0900 (JST) Message-Id: <20000918.030007.78700259.ume@mahoroba.org> To: kirk@strauser.com Cc: freebsd-net@freebsd.org Subject: Re: IPv6 woes From: Hajimu UMEMOTO In-Reply-To: <87og1nuk3f.fsf@pooh.honeypot> References: <87og1nuk3f.fsf@pooh.honeypot> X-Mailer: xcite1.20> Mew version 1.95b38 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On 17 Sep 2000 10:14:12 -0500 >>>>> Kirk Strauser said: kirk> I'm running a FreeBSD 4.1-stable system. I went to kirk> www.freenet6.net to get a v6 address, and selected the kirk> FreeBSD/KAME option. Along with the tunkame.*.pl script, it kirk> sent me: Since I have 6bone reachability, I don't using freenet6. I just tried to create freenet6 tunnel and it seems working for me. I'm using 4.1-STABLE. kirk> The script executed without errors. However, while I can ping kirk> the local and remote IPv4 address, and I can ping6 the local kirk> IPv6 address, I can't pin6 the remote end. The only error kirk> message I get, at all, is from /var/log/messages: kirk> /kernel: nd6_lookup: failed to add route for a kirk> neighbor(3ffe:0b00:0c18:1fff::0454), errno=17 Do you have any IPv4 firewall or NAT box between freenet6 and you? If so, it may breaks IPv6 over IPv4 tunnel. If you don't have such obstruction, please show me the infomation of following: ifconfig -au gifconfig -au netstat -rnf inet6 ndp -I ndp -i gif0 kirk> Now, it's my understanding from what documentation I've been kirk> able to scrap up (I tried to RTFM, honest!), I shouldn't need to kirk> do any additional configuration on my system other than kirk> executing the tunkame Perl script. Am I missing something kirk> obvious? No, you should run only tunkame.pl without any additional IPv6 setups. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 12:37:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id E1DB837B422 for ; Sun, 17 Sep 2000 12:37:55 -0700 (PDT) Received: from pooh.honeypot (root@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.0/8.11.0) with ESMTP id e8HJbsL22456; Sun, 17 Sep 2000 14:37:54 -0500 (CDT) (envelope-from kirk@strauser.com) Received: (from kirk@localhost) by pooh.honeypot (8.11.0/8.11.0/Debian 8.11.0-6) id e8HJbrB00673; Sun, 17 Sep 2000 14:37:53 -0500 X-Authentication-Warning: pooh.honeypot: kirk set sender to kirk@strauser.com using -f To: phils@staub.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes References: <87og1nuk3f.fsf@pooh.honeypot> <20000917105609.A94367@staub.net> From: Kirk Strauser Reply-To: kirk@strauser.com Date: 17 Sep 2000 14:37:53 -0500 In-Reply-To: Phil Staub's message of "Sun, 17 Sep 2000 10:56:09 -0700" Message-ID: <87itrudd2m.fsf@pooh.honeypot> Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Phil Staub writes: > By any chance are you trying to run this script from a machine > behind a NATD firewall? I tried to do this and got exactly the > same error message. A note to the freenet6 folks revealed that > NATD doesn't yet know how to deal with the tunnelling packets. Now that you mention it, I'm running in a private (10./24) block being NAT on the router. I honestly didn't suspect that of being a problem, mainly become I'm using static-mapped NAT - you know, one public IP <-> one private IP. I'll play around with my network and see what I can come up with. > HTH It does - thanks! -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 12:43:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id 4878837B424 for ; Sun, 17 Sep 2000 12:43:49 -0700 (PDT) Received: from pooh.honeypot (root@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.0/8.11.0) with ESMTP id e8HJhmL35167; Sun, 17 Sep 2000 14:43:48 -0500 (CDT) (envelope-from kirk@strauser.com) Received: (from kirk@localhost) by pooh.honeypot (8.11.0/8.11.0/Debian 8.11.0-6) id e8HJhlx00695; Sun, 17 Sep 2000 14:43:47 -0500 X-Authentication-Warning: pooh.honeypot: kirk set sender to kirk@strauser.com using -f To: Hajimu UMEMOTO Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes References: <87og1nuk3f.fsf@pooh.honeypot> <20000918.030007.78700259.ume@mahoroba.org> From: Kirk Strauser Reply-To: kirk@strauser.com Date: 17 Sep 2000 14:43:47 -0500 In-Reply-To: Hajimu UMEMOTO's message of "Mon, 18 Sep 2000 03:00:07 +0900 (JST)" Message-ID: <8766nudcss.fsf@pooh.honeypot> Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hajimu UMEMOTO writes: > Do you have any IPv4 firewall or NAT box between freenet6 and > you? If so, it may breaks IPv6 over IPv4 tunnel. Actually, someone just send that same concern via email. Yes, I am behind a NAT router (Toshiba TR-650). I didn't think that would be a problem since I'm running in what Toshiba refers to as "list mode NAT", which statically maps one public IP <-> one private IP. My LAN is in the 10./8 block and each of my machines, including the FreeBSD box in question, are directly and uniquely addressable by a public IP. Thanks for the tips. I may have to play around with my network setup again. -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 13:41:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id 5E73837B422 for ; Sun, 17 Sep 2000 13:41:54 -0700 (PDT) Received: from pooh.honeypot (root@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.0/8.11.0) with ESMTP id e8HKfrc04651 for ; Sun, 17 Sep 2000 15:41:53 -0500 (CDT) (envelope-from kirk@strauser.com) Received: (from kirk@localhost) by pooh.honeypot (8.11.0/8.11.0/Debian 8.11.0-6) id e8HKfqZ01002; Sun, 17 Sep 2000 15:41:52 -0500 X-Authentication-Warning: pooh.honeypot: kirk set sender to kirk@strauser.com using -f To: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 woes References: <87og1nuk3f.fsf@pooh.honeypot> From: Kirk Strauser Reply-To: kirk@strauser.com Date: 17 Sep 2000 15:41:52 -0500 In-Reply-To: Kirk Strauser's message of "17 Sep 2000 10:14:12 -0500" Message-ID: <87vgvulpin.fsf@pooh.honeypot> Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks to a tip, I checked out the IPv6-behind-NAT instructions at http://www.daemonnews.org/200009/ipv6.html , and am now happily ping6'ing external hosts freely. Thanks for the tips, everyone! -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 14: 2:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 136F137B440 for ; Sun, 17 Sep 2000 14:02:43 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8HL2fK18924; Sun, 17 Sep 2000 14:02:41 -0700 (PDT) Date: Sun, 17 Sep 2000 14:02:41 -0700 From: Alfred Perlstein To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: Your comment re so_gencnt Message-ID: <20000917140241.O15156@fw.wintelcom.net> References: <20000908142322.I12231@fw.wintelcom.net> <200009082234.SAA56346@khavrinen.lcs.mit.edu> <20000908155712.L12231@fw.wintelcom.net> <200009082354.TAA56853@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009082354.TAA56853@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Fri, Sep 08, 2000 at 07:54:14PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [000908 16:54] wrote: > < said: > > > I'm tempted to remove it, am I missing something though? > > Yes, you're missing the entire point. > > Read the CVS log messages, and if you still don't understand, I'll > explain it to you in private. Ok, I get it now. Is it possible for you to come up with an alternate scheme for doing this or seeing about making zalloci MPsafe? I'd really rather not have to grab Giant for each socket allocated/freed. I honestly don't like the fact this change creates yet another boot time hard limit, do you have the time to possibly rethink it? One suggestion would just to go back to using the system malloc and keeping a freelist which should achive the same effect as stable storage , this could be tuned later as we should move to a slab allocator in the future anyhow. Would you be ok with a change to that effect for the time being? thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 14:21:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 816EF37B422 for ; Sun, 17 Sep 2000 14:21:55 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id RAA60479; Sun, 17 Sep 2000 17:21:53 -0400 (EDT) (envelope-from wollman) Date: Sun, 17 Sep 2000 17:21:53 -0400 (EDT) From: Garrett Wollman Message-Id: <200009172121.RAA60479@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: Your comment re so_gencnt In-Reply-To: <20000917140241.O15156@fw.wintelcom.net> References: <20000908142322.I12231@fw.wintelcom.net> <200009082234.SAA56346@khavrinen.lcs.mit.edu> <20000908155712.L12231@fw.wintelcom.net> <200009082354.TAA56853@khavrinen.lcs.mit.edu> <20000917140241.O15156@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is it possible for you to come up with an alternate scheme for > doing this or seeing about making zalloci MPsafe? I'd really rather > not have to grab Giant for each socket allocated/freed. Fixing zalloci would be really out of my department, and it will probably be a few months before I'm up to speed on the New World Order. However, I think the right thing in general for the zone allocator is to have the call to zinit() specify a lock, possibly specific to each zone, which the allocator will grab when necessary. The fact that zalloci() currently blocks out all interrupts is a remnant of the fact that there was no general mutual-exclusion mechanism in the Old World Order. > One suggestion would just to go back to using the system malloc > and keeping a freelist which should achive the same effect as stable > storage This would work as well. The important property is that the allocations be type-stable once a reference has been created; before any references exist it's irrelevant. Also, if the zone allocator learns to do locking, then it can also learn to do the appropriate tricks to make ``interrupt'' zones behave the same way as ``top-half'' zones currently do wrt expansion. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 17: 6:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 8ECEA37B422 for ; Sun, 17 Sep 2000 17:06:33 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8I06XD24619 for ; Sun, 17 Sep 2000 17:06:33 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma024616; Sun, 17 Sep 2000 17:06:04 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id RAA91358 for freebsd-net@freebsd.org; Sun, 17 Sep 2000 17:06:04 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009180006.RAA91358@bubba.whistle.com> Subject: ng_bridge(4) patch.. To: freebsd-net@freebsd.org Date: Sun, 17 Sep 2000 17:06:04 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To anyone who's playing with the new ng_bridge(4) node, here is an untested patch that should quiet the ARP messages about receving packets on the wrong interface; feedback warmly welcomed.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Index: ng_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_bridge.c,v retrieving revision 1.1 diff -u -r1.1 ng_bridge.c --- ng_bridge.c 2000/09/01 01:37:13 1.1 +++ ng_bridge.c 2000/09/18 00:04:27 @@ -68,6 +68,7 @@ #include #include +#include #include #include @@ -83,6 +84,7 @@ struct ng_bridge_link { hook_p hook; /* netgraph hook */ u_int16_t loopCount; /* loop ignore timer */ + struct ifnet *ifp; /* ether interface */ struct ng_bridge_link_stats stats; /* link stats */ }; @@ -115,6 +117,7 @@ static ng_shutdown_t ng_bridge_rmnode; static ng_newhook_t ng_bridge_newhook; static ng_rcvdata_t ng_bridge_rcvdata; +static ng_connect_t ng_bridge_connect; static ng_disconnect_t ng_bridge_disconnect; /* Other internal functions */ @@ -274,7 +277,7 @@ ng_bridge_rmnode, ng_bridge_newhook, NULL, - NULL, + ng_bridge_connect, ng_bridge_rcvdata, ng_bridge_rcvdata, ng_bridge_disconnect, @@ -373,6 +376,44 @@ } /* + * Final confirmation of hook connection. At this point we identify + * the peer node, and set a flag if it's an ng_ether(4) node and + * we're connected to it's "upper" hook. This is so we can make + * mbuf's sent to the peer all appear as if they arrived on the + * Ethernet interface. This avoids annoying ARP messages complaining + * about ARP packets arriving on the wrong interface. + */ +static int +ng_bridge_connect(hook_p hook) +{ + const node_p node = hook->node; + const node_p peer = hook->peer->node; + const priv_p priv = node->private; + const int linkNum = LINK_NUM(hook); + + /* Check for ng_ether(4) "upper" hook */ + if (strcmp(peer->type->name, NG_ETHER_NODE_TYPE) == 0 + && strcmp(hook->peer->name, NG_ETHER_HOOK_UPPER) == 0) { + struct ng_mesg *msg, *resp = NULL; + char path[32]; + + snprintf(path, sizeof(path), + "[%lx]:", (u_long)ng_node2ID(peer)); + NG_MKMESSAGE(msg, NGM_ETHER_COOKIE, + NGM_ETHER_GET_IFNAME, 0, M_NOWAIT); + if (msg == NULL) + return (ENOMEM); + if (ng_send_msg(node, msg, path, &resp) != 0) + return (0); + if (resp != NULL) { + priv->links[linkNum]->ifp = ifunit((char *)resp->data); + FREE(resp, M_NETGRAPH); + } + } + return (0); +} + +/* * Receive a control message */ static int @@ -649,6 +690,10 @@ return (0); } + /* Modify packet's receive interface if appropriate */ + if (destLink->ifp != NULL) + m->m_pkthdr.rcvif = destLink->ifp; + /* Deliver packet out the destination link */ destLink->stats.xmitPackets++; destLink->stats.xmitOctets += m->m_pkthdr.len; @@ -703,6 +748,10 @@ destLink->stats.xmitBroadcasts++; break; } + + /* Modify packet's receive interface if appropriate */ + if (destLink->ifp != NULL) + m->m_pkthdr.rcvif = destLink->ifp; /* Send packet */ NG_SEND_DATA(error, destLink->hook, m2, meta2); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 17 17:32: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from gluttony.henshaw.net (gluttony.henshaw.net [63.70.222.4]) by hub.freebsd.org (Postfix) with SMTP id 4456337B424 for ; Sun, 17 Sep 2000 17:32:05 -0700 (PDT) Received: (qmail 63057 invoked from network); 18 Sep 2000 00:32:01 -0000 Received: from dhcp-64-58-25-247.henshaw.net (HELO Ben.henshaw.net) (64.58.25.247) by gluttony.henshaw.net with SMTP; 18 Sep 2000 00:32:01 -0000 Message-Id: <5.0.0.25.2.20000917182707.01c52a20@pop.henshaw.net> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 17 Sep 2000 18:32:35 -0600 To: Julian Elischer From: Ben Schumacher Subject: Re: netgraph based MAC authentication (core dump information) Cc: freebsd-net@freebsd.org In-Reply-To: <39C326FD.41C67EA6@elischer.org> References: <5.0.0.25.2.20000913221340.00a04950@pop.henshaw.net> <5.0.0.25.2.20000915183859.026c2310@pop.henshaw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:53 AM 9/16/2000 -0700, Julian Elischer wrote: >Enable kernel core-dumps >and compile your kernel with -g so that you can examine >the core-dump and see where the crash was. Alright here's what I gathered from the core dump. I don't know much about the networking code in the kernel, so I'm not certain exactly what's going on, but I hope somebody else can figure it out. (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:302 #1 0xc013e84d in panic (fmt=0xc023f854 "from debugger") at ../../kern/kern_shutdown.c:552 #2 0xc011d8f9 in db_panic (addr=-1072107089, have_addr=0, count=-1, modif=0xc93babec "") at ../../ddb/db_command.c:433 #3 0xc011d899 in db_command (last_cmdp=0xc0269758, cmd_table=0xc02695b8, aux_cmd_tablep=0xc0283f2c) at ../../ddb/db_command.c:333 #4 0xc011d95e in db_command_loop () at ../../ddb/db_command.c:455 #5 0xc011fa6b in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71 #6 0xc021dfc2 in kdb_trap (type=12, code=0, regs=0xc93bad40) at ../../i386/i386/db_interface.c:158 #7 0xc022cebc in trap_fatal (frame=0xc93bad40, eva=38) at ../../i386/i386/trap.c:922 #8 0xc022cb95 in trap_pfault (frame=0xc93bad40, usermode=0, eva=38) at ../../i386/i386/trap.c:820 #9 0xc022c723 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = -918835756, tf_esi = -1065955662, tf_ebp = -918835836, tf_isp = -918835860, tf_ebx = -16369088, tf_edx = 65534, tf_ecx = -1065955682, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072107089, tf_cs = 8, tf_eflags = 66178, tf_esp = -1065955840, tf_ss = -918835756}) at ../../i386/i386/trap.c:426 #10 0xc018f1af in in_broadcast (in={s_addr = 4278598208}, ifp=0x0) at ../../netinet/in.c:736 #11 0xc019a446 in udp_input (m=0xc076ce00, off=20, proto=17) at ../../netinet/udp_usrreq.c:238 #12 0xc01921e9 in ip_input (m=0xc076ce00) at ../../netinet/ip_input.c:738 #13 0xc0192247 in ipintr () at ../../netinet/ip_input.c:766 #14 0xc021fd65 in swi_net_next () #15 0xc015d72d in sendit (p=0xc89c3260, s=4, mp=0xc93baf10, flags=0) at ../../kern/uipc_syscalls.c:520 #16 0xc015d821 in sendto (p=0xc89c3260, uap=0xc93baf80) at ../../kern/uipc_syscalls.c:572 #17 0xc022d195 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1078004048, tf_esi = 671511360, tf_ebp = -1078004024, tf_isp = -918835244, tf_ebx = 671511548, tf_edx = -1078003928, tf_ecx = -7, tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 671741624, tf_cs = 31, tf_eflags = 647, tf_esp = -1078004116, tf_ss = 47}) at ../../i386/i386/trap.c:1126 #18 0xc021e905 in Xint0x80_syscall () #19 0x8048add in ?? () #20 0x8048651 in ?? () (kgdb) up 10 #10 0xc018f1af in in_broadcast (in={s_addr = 4278598208}, ifp=0x0) at ../../netinet/in.c:736 736 if (in.s_addr == INADDR_BROADCAST || (kgdb) list 731 struct ifnet *ifp; 732 { 733 register struct ifaddr *ifa; 734 u_long t; 735 736 if (in.s_addr == INADDR_BROADCAST || 737 in.s_addr == INADDR_ANY) 738 return 1; 739 if ((ifp->if_flags & IFF_BROADCAST) == 0) 740 return 0; (kgdb) print in $1 = {s_addr = 6422528} (kgdb) print in.s_addr $2 = 6422528 (kgdb) up #11 0xc019a446 in udp_input (m=0xc076ce00, off=20, proto=17) at ../../netinet/udp_usrreq.c:238 238 if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || (kgdb) up #12 0xc01921e9 in ip_input (m=0xc076ce00) at ../../netinet/ip_input.c:738 738 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh); (kgdb) up #13 0xc0192247 in ipintr () at ../../netinet/ip_input.c:766 766 ip_input(m); (kgdb) up #14 0xc021fd65 in swi_net_next () (kgdb) up #15 0xc015d72d in sendit (p=0xc89c3260, s=4, mp=0xc93baf10, flags=0) at ../../kern/uipc_syscalls.c:520 520 error = so->so_proto->pr_usrreqs->pru_sosend(so, to, &auio, 0, control, (kgdb) up #16 0xc015d821 in sendto (p=0xc89c3260, uap=0xc93baf80) at ../../kern/uipc_syscalls.c:572 572 return (sendit(p, uap->s, &msg, uap->flags)); (kgdb) up #17 0xc022d195 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1078004048, tf_esi = 671511360, tf_ebp = -1078004024, tf_isp = -918835244, tf_ebx = 671511548, tf_edx = -1078003928, tf_ecx = -7, tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 671741624, tf_cs = 31, tf_eflags = 647, tf_esp = -1078004116, tf_ss = 47}) at ../../i386/i386/trap.c:1126 1126 error = (*callp->sy_call)(p, args); (kgdb) quit BTW- Since this is my first time doing this, I might have missed somebody. If you need me to go deep into any section (maybe print out more variables), please let me know. Thanks for your help, - Ben Schumacher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 7: 4:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id C0D4A37B422 for ; Mon, 18 Sep 2000 07:04:35 -0700 (PDT) Received: from jules.elischer.org (reggae-34-29.nv.iinet.net.au [203.59.167.29]) by urban.iinet.net.au (8.8.7/8.8.7) with SMTP id WAA20236; Mon, 18 Sep 2000 22:04:13 +0800 Message-ID: <39C620D3.167EB0E7@elischer.org> Date: Mon, 18 Sep 2000 07:04:03 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Ben Schumacher Cc: freebsd-net@freebsd.org Subject: Re: netgraph based MAC authentication (core dump information) References: <5.0.0.25.2.20000913221340.00a04950@pop.henshaw.net> <5.0.0.25.2.20000915183859.026c2310@pop.henshaw.net> <5.0.0.25.2.20000917182707.01c52a20@pop.henshaw.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org maybe someone can say what the trap address was... BTW, next time set "set print pretty" and "set radix 16" Ben Schumacher wrote: > > #9 0xc022c723 in trap (frame={ > tf_fs = 16, tf_es = 16, tf_ds = 16, > tf_edi = -918835756, tf_esi = -1065955662, > tf_ebp = -918835836, tf_isp = -918835860, > tf_ebx = -16369088, tf_edx = 65534, > tf_ecx = -1065955682, tf_eax = 0, > tf_trapno = 12, tf_err = 0, > tf_eip = -1072107089, tf_cs = 8, > tf_eflags = 66178, > tf_esp = -1065955840, tf_ss = -918835756}) > at ../../i386/i386/trap.c:426 > #10 0xc018f1af in in_broadcast (in={s_addr = 4278598208}, ifp=0x0) at > ../../netinet/in.c:736 looking at this I wonder if the problim is actually 2 lines further down at line 738. ifp is 0x00 and it is dereferenced there. > #11 0xc019a446 in udp_input (m=0xc076ce00, off=20, proto=17) at > ../../netinet/udp_usrreq.c:238 > #12 0xc01921e9 in ip_input (m=0xc076ce00) at ../../netinet/ip_input.c:738 > #13 0xc0192247 in ipintr () at ../../netinet/ip_input.c:766 > #14 0xc021fd65 in swi_net_next () > #15 0xc015d72d in sendit (p=0xc89c3260, s=4, mp=0xc93baf10, flags=0) at > ../../kern/uipc_syscalls.c:520 > #16 0xc015d821 in sendto (p=0xc89c3260, uap=0xc93baf80) at > ../../kern/uipc_syscalls.c:572 > #17 0xc022d195 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > tf_edi = -1078004048, tf_esi = 671511360, > tf_ebp = -1078004024, tf_isp = -918835244, tf_ebx = 671511548, > tf_edx = -1078003928, tf_ecx = -7, > tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 671741624, tf_cs = > 31, tf_eflags = 647, > tf_esp = -1078004116, tf_ss = 47}) at ../../i386/i386/trap.c:1126 > #18 0xc021e905 in Xint0x80_syscall () > #19 0x8048add in ?? () > #20 0x8048651 in ?? () > (kgdb) up 10 > #10 0xc018f1af in in_broadcast (in={s_addr = 4278598208}, ifp=0x0) at > ../../netinet/in.c:736 > 736 if (in.s_addr == INADDR_BROADCAST || > (kgdb) list > 731 struct ifnet *ifp; > 732 { > 733 register struct ifaddr *ifa; > 734 u_long t; > 735 > 736 if (in.s_addr == INADDR_BROADCAST || > 737 in.s_addr == INADDR_ANY) > 738 return 1; > 739 if ((ifp->if_flags & IFF_BROADCAST) == 0) > 740 return 0; > (kgdb) print in > $1 = {s_addr = 6422528} > (kgdb) print in.s_addr > $2 = 6422528 > (kgdb) up > #11 0xc019a446 in udp_input (m=0xc076ce00, off=20, proto=17) at > ../../netinet/udp_usrreq.c:238 > 238 if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > (kgdb) up > #12 0xc01921e9 in ip_input (m=0xc076ce00) at ../../netinet/ip_input.c:738 > 738 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh); > (kgdb) up > #13 0xc0192247 in ipintr () at ../../netinet/ip_input.c:766 > 766 ip_input(m); Now, this is actually possible. and in fact almost any UDP packet might cause this problem. it seems that the packet you are reinjecting into the system does not include a pointer to theinterface it comes from, and udp_input() is calling in_broadcast with this packet's ifp pointer which is NULL. try the following patch.. Index: ng_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v retrieving revision 1.9 diff -u -r1.9 ng_ether.c --- ng_ether.c 2000/09/01 00:28:03 1.9 +++ ng_ether.c 2000/09/18 14:03:13 @@ -657,6 +657,7 @@ m->m_data += sizeof(*eh); m->m_len -= sizeof(*eh); m->m_pkthdr.len -= sizeof(*eh); + m->m_pkthdr.rcvif = priv->ifp; /* Route packet back in */ NG_FREE_META(meta); -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 8: 0:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f135.law4.hotmail.com [216.33.149.135]) by hub.freebsd.org (Postfix) with ESMTP id 8490037B422 for ; Mon, 18 Sep 2000 08:00:45 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Sep 2000 08:00:43 -0700 Received: from 159.10.4.47 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 18 Sep 2000 15:00:42 GMT X-Originating-IP: [159.10.4.47] From: "Konan Houphoue" To: ari@suutari.iki.fi, cjclark@alum.mit.edu, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Port 80 redirect: Good news!! Date: Mon, 18 Sep 2000 10:00:42 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Sep 2000 15:00:43.0305 (UTC) FILETIME=[378FE990:01C02181] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks to all of you who tried to help me with this problem. And I with Ari about the rules a the begining of /etc/rc.firewall A little reminder. The issue was that I'm trying to redirect all tcp/port 80 requests that arrive on the outside interface of my firewall to an IIS server that resides on my internal private network. Before the idea to redirect port 80, my web pages were served by Apache 1.3 on the firewall server, and everything was working just fine. So I was advided to use the "-redirect_port proto targetIP:port port" flag in /etc/rc.conf: firewall_enable="YES" firewall_type="simple" natd_flags="-redirect_port tcp 192.168.1.40:80 80" But the port forwarding rule was not working. Howerver, with firewall_type="open", the forwarding works. I tried all the sugestions I recieved but the forwarding always fails if firewall_type="simple". Then I went on to comment out the rules one by one. Here'e the rule in the "simple" section of /etc/rc.firewall that's blocking the forwarding: # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup When this rule is commented, everything works well. Now could you tell me whether doing so opens a security breach? Here's the "simple" section of /etc/rc.firewall: [Ss][Ii][Mm][Pp][Ll][Ee]) ############ # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. ############ # set these to your outside interface network and netmask and ip oif="fxp0" onet="207.208.254.0" omask="255.255.255.0" oip="207.208.254.234" # set these to your inside interface network and netmask and ip iif="xl0" inet="192.168.1.0" imask="255.255.255.0" iip="192.168.1.2" #/sbin/ipfw add divert natd all from any to any via oif # Stop draft-manning-dsua-01.txt nets on the outside interface ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${oip} 25 setup # Allow access to our DNS ${fwcmd} add pass tcp from any to ${oip} 53 setup ${fwcmd} add pass udp from any to ${oip} 53 ${fwcmd} add pass udp from ${oip} 53 to any # Allow access to our WWW ${fwcmd} add pass tcp from any to ${oip} 80 setup #My rules #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} setup #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from any 53 to ${oip} ${fwcmd} add pass udp from ${oip} to any 53 # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to ${oip} ${fwcmd} add pass udp from ${oip} to any 123 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. ;; Thanks a lot, Konan ----Original Message Follows---- From: "Ari Suutari" To: "Konan Houphoue" Subject: Re: Port 80 redirect Date: Mon, 18 Sep 2000 09:05:15 +0300 MIME-Version: 1.0 Received: from [213.28.98.4] by hotmail.com (3.2) with ESMTP id MHotMailBB8EFB9D00BFD821EECED51C620412570; Sun Sep 17 23:05:19 2000 Received: from coffee (adsl-nat.syncrontech.com [213.28.98.3])by osku.suutari.iki.fi (8.9.3/8.9.3) with SMTP id JAA85067for ; Mon, 18 Sep 2000 09:05:16 +0300 (EEST)(envelope-from ari@suutari.iki.fi) From ari@suutari.iki.fi Sun Sep 17 23:08:46 2000 Message-ID: <004501c02136$6a9627f0$0e05a8c0@intranet.syncrontech.com> References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Hi, Your rc.firewall doesn't look good. First, I wouldn't add rules as you have done to beginning of it - it won't work since the variables you are referring (fwcmd, inet etc...) are not yet defined at that point. Better way might be to choose a most suitable from provided choices, I think the "simple" might work for you. So, set firewall_type to "simple" in /etc/rc.conf and edit that part in /etc/rc.firewall to match your needs. There is also one catch: You shoudn't have lines like ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} since these rules forbid any traffic to your internal network. Ari S. ----- Original Message ----- From: "Konan Houphoue" To: Sent: 15. syyskuuta 2000 17:17 Subject: Re: Port 80 redirect > Ari, > > There's something new: > > Setting the firewall_type="open" > works well. > but if it is set to "simple" or "client" > the port forwarding fails. > So, some rules in the firewall are causing the problems. > > Attached ar my configuration files: > > Thanks > > > ----Original Message Follows---- > From: "Ari Suutari" > To: "Konan Houphoue" > Subject: Re: Port 80 redirect > Date: Fri, 15 Sep 2000 08:39:30 +0300 > MIME-Version: 1.0 > Received: from [213.28.98.4] by hotmail.com (3.2) with ESMTP id > MHotMailBB8B0115006CD821EEE4D51C620411AE0; Thu Sep 14 22:39:34 2000 > Received: from coffee (adsl-nat.syncrontech.com [213.28.98.3])by > osku.suutari.iki.fi (8.9.3/8.9.3) with SMTP id IAA74360for > ; Fri, 15 Sep 2000 08:39:31 +0300 (EEST)(envelope-from > ari@suutari.iki.fi) > >From ari@suutari.iki.fi Thu Sep 14 22:40:00 2000 > Message-ID: <00bf01c01ed7$529fa510$0e05a8c0@intranet.syncrontech.com> > References: > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 5.00.2919.6600 > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > > Hi, > > > > >>Set firewall_type="open an did not help. > > gateway_enable="yes" already existed > > defaultrouter="207.208.254.1" #that's on the ISP side > > > > Should I specify a router to the IIS machine? > > > > The default gateway on IIS machine should be > the address of your natd box. > > > Ari S. > > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 15: 6:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from web314.mail.yahoo.com (web314.mail.yahoo.com [216.115.105.79]) by hub.freebsd.org (Postfix) with SMTP id 39A5537B422 for ; Mon, 18 Sep 2000 15:06:38 -0700 (PDT) Message-ID: <20000918220637.14089.qmail@web314.mail.yahoo.com> Received: from [24.164.238.27] by web314.mail.yahoo.com; Mon, 18 Sep 2000 15:06:37 PDT Date: Mon, 18 Sep 2000 15:06:37 -0700 (PDT) From: Benjamin Gavin Subject: Re: Port 80 redirect: Good news!! To: Konan Houphoue , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Actually you are halfway there. You want to make sure to deny setup to your internal network so noone can use your firewall as a router to your internal net. What you can do is add the following line to your rc.firewall right before the "deny all setup" statement: +++ # Allow traffic to internal web server +++ $(fwcmd) add allow tcp from any to 192.168.1.40 80 # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup ... This could probably be secured a little tighter than this, but this line should do the trick. The thing you have to remember is that the rules get run through again after the NATD call, and I am not completely convinced that the packets get injected back into the stream where they should. Here's what I think is happening: $oip = outside IP of firewall $oif = outside interface of firewall $iip = inside IP of firewall $iif = inside interface of firewall $iis = inside address of IIS request: packet (192.88.0.1:2345 ==> $oip:80) via $oif --> NATD --> ($iip:2345 ==> $iis:80) via $oif --> (out to internal server) response: packet ($iis:80 ==> $iip:2345) via $iif --> NATD --> ($oip:2345 ==> 192.88.0.1:2345) via $iif --> (back to client) It would seem to me that it should look like this: request: packet (192.88.0.1:2345 ==> $oip:80) via $oif --> NATD --> ($iip:2345 ==> $iis:80) via $iif --> (out to internal server) response: packet ($iis:80 ==> $iip:2345) via $iif --> NATD --> ($oip:2345 ==> 192.88.0.1:2345) via $oif --> (back to client) Is this how it really works?? It seems that the packets are injected back into the stream, but the interface associations are not changed for the second run through ipfw. If my first guess is correct, can someone please explain the rationale behind this?? I'm not slamming anyone, I've just been genuinely confused about this for some time... Sorry for the extra question housed as an answer :), the good news is that the rule I talked about at the begining should fix your problem. Ben --- Konan Houphoue wrote: > A little reminder. > The issue was that I'm trying to redirect all tcp/port 80 requests that > arrive on the outside interface of my firewall to an IIS server that > resides > on my internal private network. __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 20:55:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 7D20837B422 for ; Mon, 18 Sep 2000 20:55:48 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 18 Sep 2000 20:53:50 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8J3sOe09324; Mon, 18 Sep 2000 20:54:24 -0700 (PDT) (envelope-from cjc) Date: Mon, 18 Sep 2000 20:54:23 -0700 From: "Crist J . Clark" To: Konan Houphoue Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Re: Port 80 redirect: Good news!! Message-ID: <20000918205423.E367@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Mon, Sep 18, 2000 at 10:00:42AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 18, 2000 at 10:00:42AM -0500, Konan Houphoue wrote: > Thanks to all of you who tried to help me with this problem. > And I with Ari about the rules a the begining of /etc/rc.firewall > > A little reminder. > The issue was that I'm trying to redirect all tcp/port 80 requests that > arrive on the outside interface of my firewall to an IIS server that resides > on my internal private network. > Before the idea to redirect port 80, my web pages were served by Apache 1.3 > on the firewall server, and everything was working just fine. > > So I was advided to use the "-redirect_port proto targetIP:port port" flag > in /etc/rc.conf: > > firewall_enable="YES" > firewall_type="simple" > natd_flags="-redirect_port tcp 192.168.1.40:80 80" > > But the port forwarding rule was not working. > Howerver, with firewall_type="open", the forwarding works. > > I tried all the sugestions I recieved but the forwarding always fails if > firewall_type="simple". > > Then I went on to comment out the rules one by one. > Here'e the rule in the "simple" section of /etc/rc.firewall that's blocking > the forwarding: > > # Reject&Log all setup of incoming connections from the outside > ${fwcmd} add deny log tcp from any to any in via ${oif} setup > > When this rule is commented, everything works well. > > Now could you tell me whether doing so opens a security breach? Yes. You pretty much might as well be using the 'open' configuration if you comment that out. Like it says, that's rule that disallows arbitrary incoming connections. Now, let's see how to edit these rules. [snip] > # Allow access to our WWW > ${fwcmd} add pass tcp from any to ${oip} 80 setup This rule is useless since we redirect this traffic. You want, ${fwcmd} add pass tcp from any to ${internal_http} 80 in via ${oif} setup > #My rules > #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} setup This rule seems strange. Pass traffic FROM the outer IP address to the INTERNAL net that is coming IN the internal interface? I think s/in/out/? > #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup Again, huh? The previous rule is a subset of this rule, i.e. anything that was passed in the previous rule would pass this one. The previous rule is unnecessary. Once you get this figured out, you can make it a stateful firewall rather than having the 'pass established' rule. ;) -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 21:27:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id D958B37B423 for ; Mon, 18 Sep 2000 21:27:31 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8J4RQH09114; Mon, 18 Sep 2000 21:27:26 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma009108; Mon, 18 Sep 2000 21:26:57 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id VAA01480; Mon, 18 Sep 2000 21:26:57 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009190426.VAA01480@bubba.whistle.com> Subject: Re: netgraph based MAC authentication In-Reply-To: <5.0.0.25.2.20000913221340.00a04950@pop.henshaw.net> "from Ben Schumacher at Sep 13, 2000 10:27:17 pm" To: Ben Schumacher Date: Mon, 18 Sep 2000 21:26:57 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ben Schumacher writes: > I'm working on a project where I need to be able to authenticate people by > their MAC address against a RADIUS server. While looking into the best way > to develop this, I starting toying around with netgraph and think it is the > perfect framework for what I'm trying to do. Basically what I'm going to > need to do (AFAIK) is divert the packets coming from one ethernet card > (dc0) to my netgraph node, verify their MAC address, and then push their > packet on its way. However, I'm still not entirely certain how to > implement this. You might be able to do this without writing your own node. Just use ng_bpf(4) and maintain the BPF program to match the MAC addresses you want to accept. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 18 23:34:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from gluttony.henshaw.net (gluttony.henshaw.net [63.70.222.4]) by hub.freebsd.org (Postfix) with SMTP id 98BEC37B422 for ; Mon, 18 Sep 2000 23:34:33 -0700 (PDT) Received: (qmail 85965 invoked from network); 19 Sep 2000 06:34:28 -0000 Received: from dhcp-64-58-25-247.henshaw.net (HELO Ben.henshaw.net) (64.58.25.247) by gluttony.henshaw.net with SMTP; 19 Sep 2000 06:34:28 -0000 Message-Id: <5.0.0.25.2.20000919002842.025be470@pop.henshaw.net> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Sep 2000 00:35:02 -0600 To: Julian Elischer From: Ben Schumacher Subject: Re: netgraph based MAC authentication (core dump information) Cc: freebsd-net@freebsd.org In-Reply-To: <39C620D3.167EB0E7@elischer.org> References: <5.0.0.25.2.20000913221340.00a04950@pop.henshaw.net> <5.0.0.25.2.20000915183859.026c2310@pop.henshaw.net> <5.0.0.25.2.20000917182707.01c52a20@pop.henshaw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:04 AM 9/18/2000 -0700, Julian Elischer wrote: >it seems that the packet you are reinjecting into the >system does not include a pointer to theinterface it comes from, >and udp_input() is calling in_broadcast with this packet's ifp >pointer which is NULL. > >try the following patch.. Julian- The patch worked. Everything seems to be working fine now. The patched seem to fix both the DHCP issue (the kernel panics) and the ARP issue. One quick question though, if I do decide to go the node route, can you suggest any reference on mbuf packets? I don't care if its a book or website or man page, etc. I just haven't been able to find much, except the information I gleaned from reading through mbuf.h. I just figure there must be something else out there. So far my daemon is working the way its suppose to, but CPU usage gets pretty high (3% or more) when I'm testing with just one client box, so I'm worried about what may happen if I connect 100 or more. Anyway, thanks for all your help. - Ben Schumacher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 3:22:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 6921437B422 for ; Tue, 19 Sep 2000 03:22:41 -0700 (PDT) Received: from jules.elischer.org ([203.59.169.203]) by urban.iinet.net.au (8.8.7/8.8.7) with SMTP id SAA25130; Tue, 19 Sep 2000 18:22:25 +0800 Message-ID: <39C73E56.15FB7483@elischer.org> Date: Tue, 19 Sep 2000 03:22:14 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Ben Schumacher Cc: freebsd-net@freebsd.org Subject: Re: netgraph based MAC authentication (core dump information) References: <5.0.0.25.2.20000913221340.00a04950@pop.henshaw.net> <5.0.0.25.2.20000915183859.026c2310@pop.henshaw.net> <5.0.0.25.2.20000917182707.01c52a20@pop.henshaw.net> <5.0.0.25.2.20000919002842.025be470@pop.henshaw.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ben Schumacher wrote: > > > Julian- > > The patch worked. Everything seems to be working fine now. The patched > seem to fix both the DHCP issue (the kernel panics) and the ARP issue. > Ok I committed it. > One quick question though, if I do decide to go the node route, can you > suggest any reference on mbuf packets? I don't care if its a book or > website or man page, etc. I just haven't been able to find much, except > the information I gleaned from reading through mbuf.h. I just figure there > must be something else out there. So far my daemon is working the way its > suppose to, but CPU usage gets pretty high (3% or more) when I'm testing > with just one client box, so I'm worried about what may happen if I connect > 100 or more. you should also read uipc_mbuf.c I don't know any docs. Possibly the daemon book might have a few words on the topic (see the FreeBSD bibliography) (Design and Implementation of the BSD4.4 OS) possibly the stevens books (tcp/ip Illustrated, Vol 1,2) may say something too.. I just read the files. I think mbufs are really pretty simple.. they are linked together to hold as much data as a packet needs, and they have a second link to allow packets to be linked together in a queue. they can have the data stored internally, or in a separate external storage type. The mbuf system has a default external storage type (called clusters) but you can define your own as well by supplying the methods for freeing (etc) to the mbuf you are attaching it to. The first mbuf in a packet uses a different layout (it's a union of several different layouts) as do mbufs with external storage. Julian > > Anyway, thanks for all your help. > - Ben Schumacher -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 3:39:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id C86C237B423 for ; Tue, 19 Sep 2000 03:39:54 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id SAA28147; Tue, 19 Sep 2000 18:39:51 +0800 Received: from jules.elischer.org ([203.59.169.203]) by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id SAA13521; Tue, 19 Sep 2000 18:39:44 +0800 Message-ID: <39C74264.FF6D5DF@elischer.org> Date: Tue, 19 Sep 2000 03:39:32 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: Ben Schumacher , freebsd-net@FreeBSD.ORG Subject: Re: netgraph based MAC authentication References: <200009190426.VAA01480@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > Ben Schumacher writes: > > I'm working on a project where I need to be able to authenticate people by > > their MAC address against a RADIUS server. While looking into the best way > > to develop this, I starting toying around with netgraph and think it is the > > perfect framework for what I'm trying to do. Basically what I'm going to > > need to do (AFAIK) is divert the packets coming from one ethernet card > > (dc0) to my netgraph node, verify their MAC address, and then push their > > packet on its way. However, I'm still not entirely certain how to > > implement this. > > You might be able to do this without writing your own node. > Just use ng_bpf(4) and maintain the BPF program to match the > MAC addresses you want to accept. I haven't yet been able to work out how to set rules into it.... ( I guess you need to get the compiled bpf program from tcpdump and somehow load it into the node, but I don't see a way of doing that yet) > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 8:58: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from tesseract.intercosmos.net (tesseract.intercosmos.net [64.16.142.88]) by hub.freebsd.org (Postfix) with ESMTP id 3F89037B422 for ; Tue, 19 Sep 2000 08:58:06 -0700 (PDT) Received: from localhost (weston@localhost) by tesseract.intercosmos.net (8.9.3/8.9.3) with ESMTP id KAA21494 for ; Tue, 19 Sep 2000 10:57:21 -0500 X-Authentication-Warning: tesseract.intercosmos.net: weston owned process doing -bs Date: Tue, 19 Sep 2000 10:57:20 -0500 (CDT) From: William Weston X-Sender: weston@tesseract.intercosmos.net To: freebsd-net@freebsd.org Subject: sendfile() questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm updating my company's web server software for use under FreeBSD-4.1, and I'm having troubles with the new? behavior of sendfile(). I'm only getting partial writes on files larger than about 16k, using both blocking and non-blocking IO on the network sockets. Our implementation using sendfile() works fine under FreeBSD-3.1 through FreeBSD-3.5.1. Ok.... so here's my questions: Has behavior of sendfile() changed since FreeBSD-3.X? What can cause a zero-write condition (without errors!) on a socket descriptor deemed by select() to be ready for writing? Are there any buffer sizes in the kernel that can be increased to make sendfile() happier with larger files? (I wouldn't expect this, because sendfile() is supposed to be "zero-copy"...) Are there any socket options I should be using when utilising sendfile()? Is it better to put a packet header into an iovec and have sendfile() take care of it, or to write the header to the socket using writev() (or something similar) and then use sendfile just for sending the file off the filesystem? Any help here (even a "sendfile is broken, so use something else" reply) will be greatly appreciated. --William Weston -- /********************************************************************** * William Weston * * Corporate Wizard / C Hacker * * InterCosmos Media Group, Inc. http://www.intercosmos.com * * * * "Disco and mainframes...we've sure come a long way since the 70s!" * **********************************************************************/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 9:18:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id C907E37B424 for ; Tue, 19 Sep 2000 09:18:44 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8JGIBX15023; Tue, 19 Sep 2000 09:18:11 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma015013; Tue, 19 Sep 2000 09:17:56 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id JAA03658; Tue, 19 Sep 2000 09:17:56 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009191617.JAA03658@bubba.whistle.com> Subject: Re: netgraph based MAC authentication In-Reply-To: <39C74264.FF6D5DF@elischer.org> "from Julian Elischer at Sep 19, 2000 03:39:32 am" To: Julian Elischer Date: Tue, 19 Sep 2000 09:17:56 -0700 (PDT) Cc: Archie Cobbs , Ben Schumacher , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > > > I'm working on a project where I need to be able to authenticate people by > > > their MAC address against a RADIUS server. While looking into the best way > > > to develop this, I starting toying around with netgraph and think it is the > > > perfect framework for what I'm trying to do. Basically what I'm going to > > > need to do (AFAIK) is divert the packets coming from one ethernet card > > > (dc0) to my netgraph node, verify their MAC address, and then push their > > > packet on its way. However, I'm still not entirely certain how to > > > implement this. > > > > You might be able to do this without writing your own node. > > Just use ng_bpf(4) and maintain the BPF program to match the > > MAC addresses you want to accept. > > I haven't yet been able to work out how to set rules into > it.... ( I guess you need to get the compiled bpf program > from tcpdump and somehow load it into the node, > but I don't see a way of doing that yet) For an example of how to do it, load the net/mpd-netgraph port on your machine and look at the "gDemandProg" variable in the file src/ngfunc.c. This example shows a static BPF program (to determine if an outgoing packet consitutes "demand") but you could easily write your own "assembler" to generate the BPF program dynamically. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 9:27:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from home.pl (matrix.home.net.pl [212.85.112.32]) by hub.freebsd.org (Postfix) with SMTP id 2765537B423 for ; Tue, 19 Sep 2000 09:27:35 -0700 (PDT) Received: from gateway.home.net.pl (HELO haven) (212.85.112.31) by home.pl with SMTP; 19 Sep 2000 16:29:32 -0000 Message-ID: <039301c02257$25521790$0201000a@haven> From: "Steven Jurczyk" To: References: Subject: Re: sendfile() questions Date: Tue, 19 Sep 2000 18:32:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm updating my company's web server software for use under FreeBSD-4.1, > and I'm having troubles with the new? behavior of sendfile(). I'm only > getting partial writes on files larger than about 16k, using both blocking > and non-blocking IO on the network sockets. Our implementation using > sendfile() works fine under FreeBSD-3.1 through FreeBSD-3.5.1. I use sendfile() in my web server and this function work OK under 3.x and 4.x. 0 bytes sent status (return value == 0 and *sbytes == 0) is returned in async mode when socket is clossed (network error, timeout or something like this). Is "sbytes variable" a off_t (unsigned long long - 64 bit) type? > Are there any buffer sizes in the kernel that can be increased to make > sendfile() happier with larger files? (I wouldn't expect this, because > sendfile() is supposed to be "zero-copy"...) yes... options NSFBUFS But I don't change this value (only incrase MAXUSERS) and my web server supports 1K concurent connections without any problem. > Is it better to put a packet header into an iovec and have sendfile() take > care of it, or to write the header to the socket using writev() (or > something similar) and then use sendfile just for sending the file off the > filesystem? sendfile with iovec is better (faster) - headers and first bytes of file is sent in one packet. pozdrawiam Stefan Jurczyk ---------------------------------------------------------------------------- HomeNet - http://home.pl - info@home.pl - 0801 325555 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 11:36: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f43.law4.hotmail.com [216.33.149.43]) by hub.freebsd.org (Postfix) with ESMTP id D207837B422 for ; Tue, 19 Sep 2000 11:35:59 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Sep 2000 11:35:56 -0700 Received: from 159.10.4.47 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 19 Sep 2000 18:35:56 GMT X-Originating-IP: [159.10.4.47] From: "Konan Houphoue" To: cjclark@alum.mit.edu Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Re: Port 80 redirect: Good news!! Date: Tue, 19 Sep 2000 13:35:56 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Sep 2000 18:35:56.0730 (UTC) FILETIME=[72F9F1A0:01C02268] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Crist, This is my "creation" out of desperation. THese rules are not being used. ----------- #My rules #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} setup #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup ----------- What do you think about the points made by Ben? It should be a standard and (somehow) easy rules to do what I'm planning to to. I don't think I am the first person to do this, am I? How do I join the FreeBSD-net discussion thread? Thanks all ----Original Message Follows---- From: "Crist J . Clark" Reply-To: cjclark@alum.mit.edu To: Konan Houphoue CC: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Re: Port 80 redirect: Good news!! Date: Mon, 18 Sep 2000 20:54:23 -0700 MIME-Version: 1.0 Received: from [64.6.192.82] by hotmail.com (3.2) with ESMTP id MHotMailBB902ECA003240042A164006C05209680; Mon Sep 18 20:55:55 2000 Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 18 Sep 2000 20:53:50 -0700 Received: (from cjc@localhost)by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8J3sOe09324;Mon, 18 Sep 2000 20:54:24 -0700 (PDT)(envelope-from cjc) From cjc@149.211.6.64.reflexcom.com Mon Sep 18 20:56:57 2000 Message-ID: <20000918205423.E367@149.211.6.64.reflexcom.com> References: X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Mon, Sep 18, 2000 at 10:00:42AM -0500 Return-Path: cjc@149.211.6.64.reflexcom.com On Mon, Sep 18, 2000 at 10:00:42AM -0500, Konan Houphoue wrote: > Thanks to all of you who tried to help me with this problem. > And I with Ari about the rules a the begining of /etc/rc.firewall > > A little reminder. > The issue was that I'm trying to redirect all tcp/port 80 requests that > arrive on the outside interface of my firewall to an IIS server that resides > on my internal private network. > Before the idea to redirect port 80, my web pages were served by Apache 1.3 > on the firewall server, and everything was working just fine. > > So I was advided to use the "-redirect_port proto targetIP:port port" flag > in /etc/rc.conf: > > firewall_enable="YES" > firewall_type="simple" > natd_flags="-redirect_port tcp 192.168.1.40:80 80" > > But the port forwarding rule was not working. > Howerver, with firewall_type="open", the forwarding works. > > I tried all the sugestions I recieved but the forwarding always fails if > firewall_type="simple". > > Then I went on to comment out the rules one by one. > Here'e the rule in the "simple" section of /etc/rc.firewall that's blocking > the forwarding: > > # Reject&Log all setup of incoming connections from the outside > ${fwcmd} add deny log tcp from any to any in via ${oif} setup > > When this rule is commented, everything works well. > > Now could you tell me whether doing so opens a security breach? Yes. You pretty much might as well be using the 'open' configuration if you comment that out. Like it says, that's rule that disallows arbitrary incoming connections. Now, let's see how to edit these rules. [snip] > # Allow access to our WWW > ${fwcmd} add pass tcp from any to ${oip} 80 setup This rule is useless since we redirect this traffic. You want, ${fwcmd} add pass tcp from any to ${internal_http} 80 in via ${oif} setup > #My rules > #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} setup This rule seems strange. Pass traffic FROM the outer IP address to the INTERNAL net that is coming IN the internal interface? I think s/in/out/? > #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup Again, huh? The previous rule is a subset of this rule, i.e. anything that was passed in the previous rule would pass this one. The previous rule is unnecessary. Once you get this figured out, you can make it a stateful firewall rather than having the 'pass established' rule. ;) -- Crist J. Clark cjclark@alum.mit.edu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 21:37:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id DE4DD37B422 for ; Tue, 19 Sep 2000 21:37:24 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 19 Sep 2000 21:35:33 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8K4aSr17598; Tue, 19 Sep 2000 21:36:28 -0700 (PDT) (envelope-from cjc) Date: Tue, 19 Sep 2000 21:36:27 -0700 From: "Crist J . Clark" To: Konan Houphoue Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Re: Port 80 redirect: Good news!! Message-ID: <20000919213627.N367@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Tue, Sep 19, 2000 at 01:35:56PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 19, 2000 at 01:35:56PM -0500, Konan Houphoue wrote: > Crist, > > This is my "creation" out of desperation. THese rules are not being used. > > ----------- > #My rules > #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} > setup > #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup > ----------- > > What do you think about the points made by Ben? I am not on -net either and did not get CC'ed. But I looked up the thread. It looks like he recommended you add the same rule I did. However, his next remarks are in error. Given the same conventions for the outer interface and IP, and the inner interface and IP, this is what NAT does, incoming request: 192.0.2.132:2014 -> ${oip}:80 == NAT ==> 192.0.2.132:2014 -> 192.168.1.40:80 outgoing reply: 192.168.1.40:80 -> 192.0.2.132:2014 == NAT ==> ${oip}:80 -> 192.0.2.132:2014 That is the external address that is the source of the query is not translated. Only your end of the transaction is translated. > It should be a standard and (somehow) easy rules to do what I'm planning to > to. I don't think I am the first person to do this, am I? *grin* It _is_ easy, adding that one rule _should_ fix things. People ask questions like this all of the time. The problem is that it is not possible to write a set of generic rules that are (a) as secure (i.e. as strict) as possible yet (b) allow through any traffic anyone might want to be passing for their setup. The logical course is to make the rules as reasonably strict as they can be and then have each individual poke the extra holes they need.. In your case, not only are you poking a hole for port 80, but you are doing NAT, _and_ a redirect. That makes it a little more fun, but not too tough. > How do I join the FreeBSD-net discussion thread? I believe it is like joining any other list. However, you might actually be best served by, freebsd-ipfw@freebsd.org -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 19 23:23:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from sanson.reyes.somos.net (freyes.static.inch.com [216.223.199.224]) by hub.freebsd.org (Postfix) with ESMTP id A92A237B424; Tue, 19 Sep 2000 23:23:09 -0700 (PDT) Received: from tomasa (tomasa.reyes.somos.net [10.0.0.11]) by sanson.reyes.somos.net (8.9.3/8.9.3) with SMTP id CAA59230; Wed, 20 Sep 2000 02:13:52 -0400 (EDT) (envelope-from fran@reyes.somos.net) Message-Id: <200009200613.CAA59230@sanson.reyes.somos.net> From: "Francisco Reyes" To: "Jeremy Norris" , "Matthew N. Dodd" Cc: "net@FreeBSD.ORG" , "security@FreeBSD.ORG" Date: Wed, 20 Sep 2000 02:17:48 -0400 Reply-To: "Francisco Reyes" X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: ip filtering along side ipx Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Sep 2000 19:04:58 -0400 (EDT), Matthew N. Dodd wrote: >I setup my 2 ethernet interfaces with differnet IPX networks, enabled >ipxgateway and IPXrouted and everything works. Care to share some info on how you setup the IPX/netware compatibility on your FreeBSD box. The instructions at freebsd.org/~bp are probably complete, but not the most intuitive (maybe is just my lack of ipx knowledge). For instance there is a part of the docs at freebsd.org/~bp which reads: "select network number exactly the same as on NetWare server for Ethernet_II frame. " How does one find the network number for existing netware servers? francisco Moderator of the Corporate BSD list http://www.egroups.com/group/BSD_Corporate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 2:10:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 9627737B423 for ; Wed, 20 Sep 2000 02:10:41 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id CAA05341; Wed, 20 Sep 2000 02:06:14 -0700 (PDT) Message-Id: <200009200906.CAA05341@implode.root.com> To: William Weston Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() questions In-reply-to: Your message of "Tue, 19 Sep 2000 10:57:20 CDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 20 Sep 2000 02:06:14 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm updating my company's web server software for use under FreeBSD-4.1, >and I'm having troubles with the new? behavior of sendfile(). I'm only >getting partial writes on files larger than about 16k, using both blocking >and non-blocking IO on the network sockets. Our implementation using >sendfile() works fine under FreeBSD-3.1 through FreeBSD-3.5.1. > > >Ok.... so here's my questions: > >Has behavior of sendfile() changed since FreeBSD-3.X? > >What can cause a zero-write condition (without errors!) on a socket >descriptor deemed by select() to be ready for writing? > >Are there any buffer sizes in the kernel that can be increased to make >sendfile() happier with larger files? (I wouldn't expect this, because >sendfile() is supposed to be "zero-copy"...) > >Are there any socket options I should be using when utilising sendfile()? > >Is it better to put a packet header into an iovec and have sendfile() take >care of it, or to write the header to the socket using writev() (or >something similar) and then use sendfile just for sending the file off the >filesystem? > > >Any help here (even a "sendfile is broken, so use something >else" reply) will be greatly appreciated. How many concurrent TCP connections are you using sendfile with? You could be running out of sf_bufs. This is controlled with the NSFBUFS kernel option. I'm not aware of any bugs in sendfile() at this time. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 2:14:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id DD3FA37B422 for ; Wed, 20 Sep 2000 02:14:10 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id CAA05368; Wed, 20 Sep 2000 02:09:49 -0700 (PDT) Message-Id: <200009200909.CAA05368@implode.root.com> To: William Weston Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() questions In-reply-to: Your message of "Tue, 19 Sep 2000 10:57:20 CDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 20 Sep 2000 02:09:49 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Is it better to put a packet header into an iovec and have sendfile() take >care of it, or to write the header to the socket using writev() (or >something similar) and then use sendfile just for sending the file off the >filesystem? It's better to use header/trailer iovecs with sendfile(). You save a couple of system calls that way. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 2:28:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from ursa.neonatus.net (clj1-49.dial-up.arnes.si [194.249.36.49]) by hub.freebsd.org (Postfix) with ESMTP id 3161637B424 for ; Wed, 20 Sep 2000 02:28:29 -0700 (PDT) Received: from neonatus.local.net (neonatus [192.168.1.2]) by ursa.neonatus.net (Postfix) with ESMTP id 5AAE7261AA for ; Wed, 20 Sep 2000 11:28:16 +0200 (CEST) Received: by neonatus.local.net (Postfix, from userid 0) id E907D60608; Wed, 20 Sep 2000 11:28:12 +0200 (CEST) Date: Wed, 20 Sep 2000 11:28:12 +0200 From: Bostjan Muller To: FreeBSD-net mailing list Subject: pcmcia compex enet-b help please Message-ID: <20000920112800.A7561@neonatus.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Mailer: Mutt 1.2.5i (2000-07-28) [Linux 2.2.17 i586] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I was trying to install FreeBSD 4.1 r to my laptop. I have never installed FreeBSD before and my laptop doesn't even have a CD-rom. All I have is a PCMCIA Compex Enet-B card (10mb combo). I was looking all over the net to find the sollution and I have found out that there is support for it in FreeBSD, but I only found it mentioned on CVS. Can someone please help me and tell me if it is even possible to install it this way and how to make FreeBSD recognize my PCMCIA Eth card, the PCMCIA device itself is recognized and knows slot 1 has something inserted.. it just doesn't know what that is. Please help me anyone if you can. Bostjan -- Bo¹tjan Müller [NEONATUS], neonatus@neonatus.net, http://surf.to/NEONATUS For my PGP key finger: neonatus@neonatus.net, RSA id: 0x90178DBD, ICQ #:7506644 Celular: +386(0)41243189, Powered by S.u.S.E. Linux 6.2, Student of VFUL Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 5:39:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from telcom.columbia.k12.mo.us (telcom.columbia.k12.mo.us [198.209.97.194]) by hub.freebsd.org (Postfix) with ESMTP id 1ECDB37B422 for ; Wed, 20 Sep 2000 05:39:25 -0700 (PDT) Received: (from ishmael@localhost) by telcom.columbia.k12.mo.us (8.9.3/8.9.3) id HAA03765; Wed, 20 Sep 2000 07:37:53 -0500 (CDT) (envelope-from ishmael) Date: Wed, 20 Sep 2000 07:37:53 -0500 From: Jeremy Norris To: Francisco Reyes Cc: net@FreeBSD.ORG Subject: Re: ip filtering along side ipx Message-ID: <20000920073753.A3717@telcom.columbia.k12.mo.us> References: <200009200613.CAA59230@sanson.reyes.somos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009200613.CAA59230@sanson.reyes.somos.net>; from fran@reyes.somos.net on Wed, Sep 20, 2000 at 02:17:48AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To get the IPX/netware compatibility working on my FreeBSD workstation at work I just ifconfig'ed my ethernet card with our LAN's IPX network number and enabled IPXrouted with the -q option. If you don't know the IPX network number on your LAN, you probably should just ask your network admin what it is. Jeremy On Wed, Sep 20, 2000 at 02:17:48AM -0400, Francisco Reyes wrote: > On Fri, 15 Sep 2000 19:04:58 -0400 (EDT), Matthew N. Dodd wrote: > > >I setup my 2 ethernet interfaces with differnet IPX networks, enabled > >ipxgateway and IPXrouted and everything works. > > Care to share some info on how you setup the IPX/netware > compatibility on your FreeBSD box. > The instructions at freebsd.org/~bp are probably complete, but > not the most intuitive (maybe is just my lack of ipx knowledge). > > For instance there is a part of the docs at freebsd.org/~bp > which reads: > "select network number exactly the same as on NetWare server for > Ethernet_II frame. " > > How does one find the network number for existing netware > servers? > > > francisco > Moderator of the Corporate BSD list > http://www.egroups.com/group/BSD_Corporate > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 6: 4:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from drawbridge.ctc.com (drawbridge.ctc.com [147.160.99.35]) by hub.freebsd.org (Postfix) with ESMTP id F0F2A37B422 for ; Wed, 20 Sep 2000 06:04:36 -0700 (PDT) Received: from server2.ctc.com (server2.ctc.com [147.160.1.4]) by drawbridge.ctc.com (8.10.1/8.10.1) with ESMTP id e8KD4T319446; Wed, 20 Sep 2000 09:04:30 -0400 (EDT) Received: from ctcjst-mail1.ctc.com (ctcjst-mail1.ctc.com [147.160.34.14]) by server2.ctc.com (8.9.3/8.9.3) with ESMTP id JAA01809; Wed, 20 Sep 2000 09:04:24 -0400 (EDT) Received: by ctcjst-mail1.ctc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 09:06:46 -0400 Message-ID: From: "Cameron, Frank" To: "'Francisco Reyes'" Cc: "'net@freebsd.org'" Subject: RE: ip filtering along side ipx Date: Wed, 20 Sep 2000 09:06:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From the NetWare console run 'config' EX: > config File Server Name: <..> IPX internal network number: <..> Server Up Time: <..> Hardware setting: <..> Node address: <..> Frame type: <..> Board name: <..> LAN protocol: IPX network <..> LAN protocol: ... -----Original Message----- From: Francisco Reyes [mailto:fran@reyes.somos.net] "select network number exactly the same as on NetWare server for Ethernet_II frame. " How does one find the network number for existing netware servers? francisco Moderator of the Corporate BSD list http://www.egroups.com/group/BSD_Corporate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 7:58:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f44.law4.hotmail.com [216.33.149.44]) by hub.freebsd.org (Postfix) with ESMTP id D9A4B37B424 for ; Wed, 20 Sep 2000 07:58:40 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Sep 2000 07:58:40 -0700 Received: from 159.10.4.47 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 20 Sep 2000 14:58:40 GMT X-Originating-IP: [159.10.4.47] From: "Konan Houphoue" To: cjclark@alum.mit.edu Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Date: Wed, 20 Sep 2000 09:58:40 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Sep 2000 14:58:40.0734 (UTC) FILETIME=[43548FE0:01C02313] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Crist, thanks for your comments about what I said about finding a solution to my problems. Listening and reading all you (all) said actually helped me understand a little deeper what's going on in the rc.firewall rules. I'd probably not have gotten this knowledge if someone just gave me the magic answer. I apologize if I ofended anyone. Ben, thanks and hope that Crist's input provided answer to your questions. Here's my final rc.firewall file. And it WORKS!!!!!! ############ # Setup system for firewall service. # $FreeBSD: src/etc/rc.firewall,v 1.30 2000/02/06 19:24:37 paul Exp $ # Suck in the configuration variables. if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi ############ # Define the firewall type in /etc/rc.conf. Valid values are: # open - will allow anyone in # client - will try to protect just this machine # simple - will try to protect a whole network # closed - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # # For ``client'' and ``simple'' the entries below should be customized # appropriately. ############ # # If you don't know enough about packet filtering, we suggest that you # take time to read this book: # # Building Internet Firewalls # Brent Chapman and Elizabeth Zwicky # # O'Reilly & Associates, Inc # ISBN 1-56592-124-0 # http://www.ora.com/ # # For a more advanced treatment of Internet Security read: # # Firewalls & Internet Security # Repelling the wily hacker # William R. Cheswick, Steven M. Bellowin # # Addison-Wesley # ISBN 0-201-6337-4 # http://www.awl.com/ # if [ -n "${1}" ]; then firewall_type="${1}" fi ############ # Set quiet mode if requested # case ${firewall_quiet} in [Yy][Ee][Ss]) fwcmd="/sbin/ipfw -q" ;; *) fwcmd="/sbin/ipfw" ;; esac ############ # Flush out the list before we begin. # ${fwcmd} -f flush ############ # These rules are required for using natd. All packets are passed to # natd before they encounter your remaining rules. The firewall rules # will then be run again on each packet after translation by natd, # minus any divert rules (see natd(8)). # case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add divert natd all from any to any via ${natd_interface} fi ;; esac ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # then you will want to change the default policy to open. You can also # do this as your only action by setting the firewall_type to ``open''. # # ${fwcmd} add 65000 pass all from any to any ############ # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # If you're using 'options BRIDGE', uncomment the following line to pass ARP ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 # Prototype setups. # case ${firewall_type} in [Oo][Pp][Ee][Nn]) ${fwcmd} add 65000 pass all from any to any ;; [Cc][Ll][Ii][Ee][Nn][Tt]) ############ # This is a prototype setup that will protect your system somewhat # against people from outside your own network. ############ # set these to your network and netmask and ip net="192.168.1.0" mask="255.255.255.0" ip="192.168.1.2" # Allow any traffic to or from my own net. ${fwcmd} add pass all from ${ip} to ${net}:${mask} ${fwcmd} add pass all from ${net}:${mask} to ${ip} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${ip} 25 setup # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from ${ip} to any setup # Disallow setup of all other TCP connections ${fwcmd} add deny tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from any 53 to ${ip} ${fwcmd} add pass udp from ${ip} to any 53 # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to ${ip} ${fwcmd} add pass udp from ${ip} to any 123 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. ;; [Ss][Ii][Mm][Pp][Ll][Ee]) ############ # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. ############ # set these to your outside interface network and netmask and ip oif="fxp0" onet="207.208.254.0" omask="255.255.255.0" oip="207.208.254.234" # set these to your inside interface network and netmask and ip iif="xl0" inet="192.168.1.0" imask="255.255.255.0" iip="192.168.1.2" # set this my internal web server ip ihttpip="192.168.1.40" #/sbin/ipfw add divert natd all from any to any via oif # Stop draft-manning-dsua-01.txt nets on the outside interface ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${oip} 25 setup # Allow access to our DNS ${fwcmd} add pass tcp from any to ${oip} 53 setup ${fwcmd} add pass udp from any to ${oip} 53 ${fwcmd} add pass udp from ${oip} 53 to any # Allow access to our WWW #${fwcmd} add pass tcp from any to ${oip} 80 setup # >>>>>>>>>> New rule <<<<<<<<<<<<<<<<<<<<<<< ${fwcmd} add pass tcp from any to ${ihttpip} 80 in via ${oif} setup # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from any 53 to ${oip} ${fwcmd} add pass udp from ${oip} to any 53 # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to ${oip} ${fwcmd} add pass udp from ${oip} to any 123 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. ;; [Uu][Nn][Kk][Nn][Oo][Ww][Nn]) ;; *) if [ -r "${firewall_type}" ]; then ${fwcmd} ${firewall_flags} ${firewall_type} fi ;; esac Thanks again, Konan ----Original Message Follows---- From: "Crist J . Clark" Reply-To: cjclark@alum.mit.edu To: Konan Houphoue CC: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org Subject: Re: Port 80 redirect: Good news!! Date: Mon, 18 Sep 2000 20:54:23 -0700 MIME-Version: 1.0 Received: from [64.6.192.82] by hotmail.com (3.2) with ESMTP id MHotMailBB902ECA003240042A164006C05209680; Mon Sep 18 20:55:55 2000 Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 18 Sep 2000 20:53:50 -0700 Received: (from cjc@localhost)by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8J3sOe09324;Mon, 18 Sep 2000 20:54:24 -0700 (PDT)(envelope-from cjc) From cjc@149.211.6.64.reflexcom.com Mon Sep 18 20:56:57 2000 Message-ID: <20000918205423.E367@149.211.6.64.reflexcom.com> References: X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Mon, Sep 18, 2000 at 10:00:42AM -0500 Return-Path: cjc@149.211.6.64.reflexcom.com On Mon, Sep 18, 2000 at 10:00:42AM -0500, Konan Houphoue wrote: > Thanks to all of you who tried to help me with this problem. > And I with Ari about the rules a the begining of /etc/rc.firewall > > A little reminder. > The issue was that I'm trying to redirect all tcp/port 80 requests that > arrive on the outside interface of my firewall to an IIS server that resides > on my internal private network. > Before the idea to redirect port 80, my web pages were served by Apache 1.3 > on the firewall server, and everything was working just fine. > > So I was advided to use the "-redirect_port proto targetIP:port port" flag > in /etc/rc.conf: > > firewall_enable="YES" > firewall_type="simple" > natd_flags="-redirect_port tcp 192.168.1.40:80 80" > > But the port forwarding rule was not working. > Howerver, with firewall_type="open", the forwarding works. > > I tried all the sugestions I recieved but the forwarding always fails if > firewall_type="simple". > > Then I went on to comment out the rules one by one. > Here'e the rule in the "simple" section of /etc/rc.firewall that's blocking > the forwarding: > > # Reject&Log all setup of incoming connections from the outside > ${fwcmd} add deny log tcp from any to any in via ${oif} setup > > When this rule is commented, everything works well. > > Now could you tell me whether doing so opens a security breach? Yes. You pretty much might as well be using the 'open' configuration if you comment that out. Like it says, that's rule that disallows arbitrary incoming connections. Now, let's see how to edit these rules. [snip] > # Allow access to our WWW > ${fwcmd} add pass tcp from any to ${oip} 80 setup This rule is useless since we redirect this traffic. You want, ${fwcmd} add pass tcp from any to ${internal_http} 80 in via ${oif} setup > #My rules > #${fwcmd} add pass tcp from ${oip} to ${inet}:${imask} 80 in via ${iip} setup This rule seems strange. Pass traffic FROM the outer IP address to the INTERNAL net that is coming IN the internal interface? I think s/in/out/? > #${fwcmd} add pass tcp from ${oif} to any in via ${iif} setup Again, huh? The previous rule is a subset of this rule, i.e. anything that was passed in the previous rule would pass this one. The previous rule is unnecessary. Once you get this figured out, you can make it a stateful firewall rather than having the 'pass established' rule. ;) -- Crist J. Clark cjclark@alum.mit.edu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 11:58:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 43B8E37B422 for ; Wed, 20 Sep 2000 11:58:23 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 20 Sep 2000 11:56:25 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8KIvUM22867; Wed, 20 Sep 2000 11:57:30 -0700 (PDT) (envelope-from cjc) Date: Wed, 20 Sep 2000 11:57:30 -0700 From: "Crist J . Clark" To: Konan Houphoue Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Message-ID: <20000920115730.B22272@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Wed, Sep 20, 2000 at 09:58:40AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 20, 2000 at 09:58:40AM -0500, Konan Houphoue wrote: > Hi, > > Crist, thanks for your comments about what I said about finding a solution > to my problems. Listening and reading all you (all) said actually helped me > understand a little deeper what's going on in the rc.firewall rules. I'd > probably not have gotten this knowledge if someone just gave me the magic > answer. I apologize if I ofended anyone. > Ben, thanks and hope that Crist's input provided answer to your questions. > > Here's my final rc.firewall file. And it WORKS!!!!!! Great. One question tho', [snip] > # If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 Why is this uncommented? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 14:44:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from jinn.laser.ru (mx.mtu.gpi.ru [212.30.167.230]) by hub.freebsd.org (Postfix) with ESMTP id 5E84237B424 for ; Wed, 20 Sep 2000 14:44:16 -0700 (PDT) Received: from w9g8j7 (30.6.87.194.dynamic.dol.ru [194.87.6.30]) by jinn.laser.ru (8.8.8/8.8.8) with SMTP id BAA10525 for ; Thu, 21 Sep 2000 01:44:13 +0400 (MSD) (envelope-from kuzmin@laser.ru) Message-ID: <003801c0234c$1f7c4b60$1e0657c2@w9g8j7> From: "Michael Kuzmin" To: Subject: Dying multi-link PPP Date: Thu, 21 Sep 2000 01:43:17 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Our configuration is fairly standard, user-ppp with two modems and MP enabled at both sides of the channel (see ppp.conf below), the only pecularity is frequent redials due to telco (30 min call limit). It always works OK after reload and initial connects, but subsequent modem redials amont to accumulation of problems and performance degradation with unavoidable death in several hours. The usual final (dead) state of the channel is an infinite series of short connects each with LCP RecvTerminateReq in 15 sec after successful authorization and lcp -> open. The origin of this dead state could be tentitavely traced to simultaneous redial of both modem links, at that moment old ppp master at answering side exits and all new ppp processes born after that seems to unable to continue... This picture appeared to be rather generic: we tried dialing from both sides, -ddial and -auto modes, answering directly by ppp and through mgetty, many other options - nothing helped... One-link variant (MP disabled) always works without problems arbitrary long. Any ideas as to possible reason of our problems are greately welcome. We already installed mpd and are going to get it a try shortly. Can anybody advise me which one (user-ppp or mpd) is a better choise in our case? Thanks, Sincerely yours, Michael Kuzmin, LASERnet ________________________ ppp.conf's at both sides of the channel are almost identical, below is config from answering side, it is started from mgetty by ppp -direct mpd Dialing ppp is started by ppp -auto mp Its config differs in minor details: different authname (ata), phone numbers, and no add default. ________________________ default: accept dns accept lqr enable lqr enable pap set log Command Connect Chat ID0 Phase TUN LCP IPCP CCP set speed 115200 # Dial-out to ata over cuaa1, dummy entry _cuaa1_: set device /dev/cuaa1 set dial "ABORT RING ABORT BUSY TIMEOUT 4 \"\" ATZ2 OK ATM1L2E0 OK ATS7=90 OK \\dATDP\\T TIMEOUT 85 CONNECT" set phone 8,,,09732190 # Dial-out to ata over cuaa2, dummy entry _cuaa2_: set device /dev/cuaa2 set dial "ABORT NO\\sDIAL\\sTONE ABORT BUSY TIMEOUT 4 \"\" ATZ OK AT&F1M1L1E0*M34=-50#Line=1 OK AT*MSF+128 OK ATS7=90 OK \\dATDP\\T TIMEOUT 85 CONNECT" set phone 8W09732191 # Multi-link (direct mode) mpd: disable vjcomp enable keep-session set authname atd set authkey ******** set server +3000 ******* set timeout 600 set urgent none set mrru 1500 set mru 1504 # Multi-link (dial-out) mp: set ifaddr 195.209.192.1 195.209.192.2 set login "TIMEOUT 30 ogin:--ogin: atd" set reconnect 1 60 set redial 3.1 60 add default HISADDR load mpd clone 1,2 link deflink remove link * set mode auto link 1 load _cuaa2_ link 2 load _cuaa1_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 20 15: 0:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 38DD937B424 for ; Wed, 20 Sep 2000 15:00:25 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8KM0Rv62119; Wed, 20 Sep 2000 23:00:27 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8KLuws19704; Wed, 20 Sep 2000 22:56:58 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009202156.e8KLuws19704@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Michael Kuzmin" Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Dying multi-link PPP In-Reply-To: Message from "Michael Kuzmin" of "Thu, 21 Sep 2000 01:43:17 +0400." <003801c0234c$1f7c4b60$1e0657c2@w9g8j7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Sep 2000 22:56:54 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Our configuration is fairly standard, user-ppp with two modems and MP > enabled at both sides of the channel (see ppp.conf below), the only > pecularity is frequent redials due to telco (30 min call limit). It always > works OK after reload and initial connects, but subsequent modem redials > amont to accumulation of problems and performance degradation with > unavoidable death in several hours. > > The usual final (dead) state of the channel is an infinite series of short > connects each with LCP RecvTerminateReq in 15 sec after successful > authorization and lcp -> open. The origin of this dead state could be > tentitavely traced to simultaneous redial of both modem links, at that > moment old ppp master at answering side exits and all new ppp processes born > after that seems to unable to continue... [.....] I think the first thing to find out is why the SendTerminateReq is being sent. If you enable debug, lcp, ipcp & tcp/ip logs on that end (the server?), hopefully we'll see why it thinks it's a good idea to give up. You could also try disable pred1 deflate deny pred1 deflate in your mpd profile - I believe there may be a problem with compression at the moment. Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 1:53: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns.bsag.ch (ns.bsag.ch [195.246.88.210]) by hub.freebsd.org (Postfix) with ESMTP id EB9A137B422; Thu, 21 Sep 2000 01:52:55 -0700 (PDT) Received: (from hpr@localhost) by ns.bsag.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id KAA10131; Thu, 21 Sep 2000 10:52:48 +0200 Date: Thu, 21 Sep 2000 10:52:48 +0200 From: Hanspeter Roth Bsag To: freebsd-isdn@freebsd.org, freebsd-net@freebsd.org Subject: rc.isdn hangs the system Message-ID: <20000921105248.A9893@bs11.bsag.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, if I start isdnd at system startup via rc.isdn (rc.network) the keyboard is locked. I can only press the PC's reset button. What can be the reason? My Isdn parameters are: isdn_enable="yes" isdn_flags="-d0x038" isdn_trace="NO" isdn_traceflags="-f /var/tmp/isdntrace0" I can start isdnd via /usr/local/etc/rc.d/isdnd.sh. Then the almost everything seems to work fine. The only problem I encounter is dxpc doesn't listen on the tun0 interface opened by ppp. (Dxpc is not started at system startup.) Named which I don't whant to listen on the tun0 interface I have to configure explicitly. What determines on which interface/address a ip-listen is connected to? -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 2:26:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from jinn.laser.ru (mx.mtu.gpi.ru [212.30.167.230]) by hub.freebsd.org (Postfix) with ESMTP id 9FD4E37B422 for ; Thu, 21 Sep 2000 02:25:44 -0700 (PDT) Received: from w9g8j7 (30.6.87.194.dynamic.dol.ru [194.87.6.30]) by jinn.laser.ru (8.8.8/8.8.8) with SMTP id NAA29004; Thu, 21 Sep 2000 13:25:03 +0400 (MSD) (envelope-from kuzmin@laser.ru) Message-ID: <009801c023ae$078c70e0$1e0657c2@w9g8j7> From: "Michael Kuzmin" To: "Brian Somers" Cc: References: <200009202156.e8KLuws19704@hak.lan.Awfulhak.org> Subject: Re: Dying multi-link PPP Date: Thu, 21 Sep 2000 13:16:08 +0400 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Our configuration is fairly standard, user-ppp with two modems and MP >> enabled at both sides of the channel (see ppp.conf below), the only >> pecularity is frequent redials due to telco (30 min call limit). It always >> works OK after reload and initial connects, but subsequent modem redials >> amont to accumulation of problems and performance degradation with >> unavoidable death in several hours. >> >> The usual final (dead) state of the channel is an infinite series of short >> connects each with LCP RecvTerminateReq in 15 sec after successful >> authorization and lcp -> open. The origin of this dead state could be >> tentitavely traced to simultaneous redial of both modem links, at that >> moment old ppp master at answering side exits and all new ppp processes >> born after that seems to unable to continue... > [.....] > > I think the first thing to find out is why the SendTerminateReq is > being sent. If you enable debug, lcp, ipcp & tcp/ip logs on that end > (the server?), hopefully we'll see why it thinks it's a good idea to > give up. > > You could also try > > disable pred1 deflate > deny pred1 deflate > > in your mpd profile - I believe there may be a problem with compression > at the moment. Thank you for this idea - I'll try it a bit later. Meanwhile, it should be noted that we really _have_ many CCP-related errors in logs, e.g. sequenses like that 15:56:30 atd ppp[336]: tun0: CCP: mp: RecvResetReq(11) state = Opened 15:56:30 atd ppp[336]: tun0: CCP: Deflate: Output channel reset 15:56:30 atd ppp[336]: tun0: CCP: mp: SendResetAck(11) state = Opened repeated tens or hundreds time in a line (or even for half an hour - our max lifetime of the link) And I can also post some logs that I already have archived - these logs seems to be relevant. Here is what is going on around when SendTerminateReq is being sent (all logging you requested exept debug were on, configs are just that I posted last time): 19:52:00 atd ppp[915]: tun0: Phase: deflink: his = PAP, mine = PAP 19:52:00 atd ppp[915]: tun0: Phase: Pap Output: atd ******** 19:52:00 atd ppp[915]: tun0: Phase: Pap Input: REQUEST (ata) 19:52:00 atd ppp[915]: tun0: ID0: 0x28168fa4 =fopen("/etc/ppp/ppp.secret", "r") 19:52:00 atd ppp[915]: tun0: Phase: Pap Output: SUCCESS 19:52:00 atd ppp[915]: tun0: ID0: login("cuaa1", "ata") 19:52:00 atd ppp[915]: tun0: Phase: Pap Input: SUCCESS (Greetings!!) 19:52:00 atd ppp[915]: tun0: ID0: 1 = socket(1, 2, 0) 19:52:00 atd ppp[915]: tun0: ID0: 0 = bind(1, "/var/run/ppp-ata-00-",106) 19:52:00 atd ppp[915]: tun0: Phase: mp: Listening on /var/run/ppp-ata-00- 19:52:00 atd ppp[915]: tun0: Phase: First link: deflink 19:52:00 atd ppp[915]: tun0: CCP: FSM: Using "mp" as a transport 19:52:00 atd ppp[915]: tun0: CCP: mp: State change Initial --> Closed 19:52:00 atd ppp[915]: tun0: CCP: mp: LayerStart. 19:52:00 atd ppp[915]: tun0: CCP: mp: SendConfigReq(1) state = Closed 19:52:00 atd ppp[915]: tun0: CCP: DEFLATE[4] win 15 19:52:00 atd ppp[915]: tun0: CCP: PRED1[2] 19:52:00 atd ppp[915]: tun0: CCP: mp: State change Closed -->Req-Sent 19:52:00 atd ppp[915]: tun0: ID0: 0x28168fa4 = fopen("/etc/ppp/ppp.secret", "r") 19:52:00 atd ppp[915]: tun0: CCP: FSM: Using "deflink" as a transport 19:52:00 atd ppp[915]: tun0: CCP: deflink: State change Initial -->Closed 19:52:00 atd ppp[915]: tun0: CCP: deflink: State change Closed -->Stopped 19:52:00 atd ppp[915]: tun0: Phase: deflink: lcp -> open 19:52:00 atd ppp[915]: tun0: Phase: bundle: Network 19:52:00 atd ppp[915]: tun0: IPCP: FSM: Using "mp" as a transport 19:52:00 atd ppp[915]: tun0: IPCP: mp: State change Initial -->Closed 19:52:00 atd ppp[915]: tun0: IPCP: mp: LayerStart. 19:52:00 atd ppp[915]: tun0: IPCP: mp: SendConfigReq(1) state =Closed 19:52:00 atd ppp[915]: tun0: IPCP: IPADDR[6] 195.209.192.1 19:52:00 atd ppp[915]: tun0: IPCP: mp: State change Closed -->Req-Sent 19:52:00 atd ppp[915]: tun0: Phase: Unknown protocol 0x00fd (1st choice compression) 19:52:00 atd ppp[915]: tun0: LCP: mp: SendProtocolRej(1) state =Opened 19:52:00 atd ppp[915]: tun0: Warning: ip_Input: IPCP not open - packet dropped 19:52:00 atd ppp[915]: tun0: Phase: Unknown protocol 0x00fd (1st choice compression) 19:52:00 atd ppp[915]: tun0: LCP: mp: SendProtocolRej(1) state = Opened 19:52:03 atd ppp[915]: tun0: CCP: mp: SendConfigReq(1) state = Req-Sent 19:52:03 atd ppp[915]: tun0: CCP: DEFLATE[4] win 15 19:52:03 atd ppp[915]: tun0: CCP: PRED1[2] 19:52:03 atd ppp[915]: tun0: IPCP: mp: SendConfigReq(1) state =Req-Sent 19:52:03 atd ppp[915]: tun0: IPCP: IPADDR[6] 195.209.192.1 19:52:06 atd ppp[915]: tun0: CCP: mp: SendConfigReq(1) state =Req-Sent 19:52:06 atd ppp[915]: tun0: CCP: DEFLATE[4] win 15 19:52:06 atd ppp[915]: tun0: CCP: PRED1[2] 19:52:06 atd ppp[915]: tun0: IPCP: mp: SendConfigReq(1) state =Req-Sent 19:52:06 atd ppp[915]: tun0: IPCP: IPADDR[6] 195.209.192.1 19:52:09 atd ppp[915]: tun0: CCP: mp: SendConfigReq(1) state =Req-Sent 19:52:09 atd ppp[915]: tun0: CCP: DEFLATE[4] win 15 19:52:09 atd ppp[915]: tun0: CCP: PRED1[2] 19:52:09 atd ppp[915]: tun0: IPCP: mp: SendConfigReq(1) state =Req-Sent 19:52:09 atd ppp[915]: tun0: IPCP: IPADDR[6] 195.209.192.1 19:52:12 atd ppp[915]: tun0: CCP: mp: SendConfigReq(1) state =Req-Sent 19:52:12 atd ppp[915]: tun0: CCP: DEFLATE[4] win 15 19:52:12 atd ppp[915]: tun0: CCP: PRED1[2] 19:52:12 atd ppp[915]: tun0: IPCP: mp: SendConfigReq(1) state =Req-Sent 19:52:12 atd ppp[915]: tun0: IPCP: IPADDR[6] 195.209.192.1 19:52:15 atd ppp[915]: tun0: CCP: mp: LayerFinish. 19:52:15 atd ppp[915]: tun0: CCP: mp: State change Req-Sent -->Stopped 19:52:15 atd ppp[915]: tun0: IPCP: mp: LayerFinish. 19:52:15 atd ppp[915]: tun0: IPCP: Connect time: 15 secs: 0 octets in, 0 octets out 19:52:15 atd ppp[915]: tun0: IPCP: total 0 bytes/sec, peak 0 bytes/sec on Thu 19:52:15 2000 19:52:15 atd ppp[915]: tun0: IPCP: mp: State change Req-Sent -->Stopped 19:52:15 atd ppp[915]: tun0: Phase: bundle: Terminate 19:52:15 atd ppp[915]: tun0: ID0: 0 = unlink("/var/run/ppp-ata-00-") 19:52:15 atd ppp[915]: tun0: CCP: mp: State change Stopped --> Closed 19:52:15 atd ppp[915]: tun0: CCP: mp: State change Closed --> Initial 19:52:15 atd ppp[915]: tun0: CCP: deflink: State change Stopped -->Closed 19:52:15 atd ppp[915]: tun0: CCP: deflink: State change Closed -->Initial 19:52:15 atd ppp[915]: tun0: LCP: deflink: LayerDown 19:52:15 atd ppp[915]: tun0: LCP: deflink: SendTerminateReq(2) state= Opened 19:52:15 atd ppp[915]: tun0: LCP: deflink: State change Opened -->Closing 19:52:15 atd ppp[915]: tun0: Phase: deflink: open -> lcp 19:52:15 atd ppp[915]: tun0: IPCP: mp: State change Stopped -->Closed 19:52:15 atd ppp[915]: tun0: IPCP: mp: State change Closed -->Initial 19:52:16 atd ppp[915]: tun0: LCP: deflink: RecvTerminateAck(2) state = Closing 19:52:16 atd ppp[915]: tun0: LCP: deflink: LayerFinish 19:52:16 atd ppp[915]: tun0: LCP: deflink: State change Closing --> Closed 19:52:16 atd ppp[915]: tun0: LCP: deflink: State change Closed -->Initial 19:52:16 atd ppp[915]: tun0: Phase: deflink: Disconnected! 19:52:16 atd ppp[915]: tun0: ID0: logout("cuaa1") 19:52:16 atd ppp[915]: tun0: ID0: logwtmp("cuaa1", "", "") 19:52:16 atd ppp[915]: tun0: Phase: deflink: Connect time: 17 secs: 472 octets in, 619 octets out 19:52:16 atd ppp[915]: tun0: Phase: total 64 bytes/sec, peak 301 bytes/sec on Thu 19:52:16 2000 19:52:16 atd ppp[920]: tun0: ID0: 0x28168fa4 = fopen("/var/run/tun0.pid", "w") 19:52:16 atd ppp[920]: tun0: ID0: 0 = unlink("/var/run/cuaa1.if") 19:52:16 atd ppp[920]: tun0: Phase: deflink: lcp -> closed 19:52:16 atd ppp[920]: tun0: ID0: 0 = socket(2, 2, 0) 19:52:16 atd ppp[920]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbfd044) 19:52:16 atd ppp[920]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbfd044) 19:52:16 atd ppp[920]: tun0: Phase: bundle: Dead 19:52:16 atd ppp[920]: tun0: Phase: PPP Terminated (normal). 19:52:16 atd ppp[920]: tun0: ID0: 0 = socket(2, 2, 0) 19:52:16 atd ppp[920]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbfdbac) 19:52:16 atd ppp[920]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbfdbac) 19:52:16 atd ppp[920]: tun0: ID0: 0 = unlink("/var/run/tun0.pid") This is repeated for each incoming call... When looking at that myself, I suspected that they faled to negotiate a compression protocol and then tried to switch off one of them (deflate) to make the negotiation easier :-) That did not help. If it actually compression, what may happen here?... It _did_ work an hour earlier, the same run, same configs... Sincerely yours, Michael Kuzmun, LASERnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 7:26:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f3.law4.hotmail.com [216.33.149.3]) by hub.freebsd.org (Postfix) with ESMTP id 91AB637B423 for ; Thu, 21 Sep 2000 07:26:30 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Sep 2000 07:26:28 -0700 Received: from 159.10.4.47 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 21 Sep 2000 14:26:28 GMT X-Originating-IP: [159.10.4.47] From: "Konan Houphoue" To: cjclark@alum.mit.edu Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Date: Thu, 21 Sep 2000 09:26:28 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2000 14:26:28.0162 (UTC) FILETIME=[EDD73A20:01C023D7] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #If you're using 'options BRIDGE', uncomment the following line to pass ARP ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 I believe it is uncommented to keep the 2 interfaces on different network but yet allowing local traffic on this computer. Konan ----Original Message Follows---- From: "Crist J . Clark" Reply-To: cjclark@alum.mit.edu To: Konan Houphoue CC: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Date: Wed, 20 Sep 2000 11:57:30 -0700 MIME-Version: 1.0 Received: from [64.6.192.82] by hotmail.com (3.2) with ESMTP id MHotMailBB9253D3002DD820F3BB4006C052111B0; Wed Sep 20 11:58:28 2000 Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 20 Sep 2000 11:56:25 -0700 Received: (from cjc@localhost)by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8KIvUM22867;Wed, 20 Sep 2000 11:57:30 -0700 (PDT)(envelope-from cjc) From cjc@149.211.6.64.reflexcom.com Wed Sep 20 12:03:02 2000 Message-ID: <20000920115730.B22272@149.211.6.64.reflexcom.com> References: X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Wed, Sep 20, 2000 at 09:58:40AM -0500 Return-Path: cjc@149.211.6.64.reflexcom.com On Wed, Sep 20, 2000 at 09:58:40AM -0500, Konan Houphoue wrote: > Hi, > > Crist, thanks for your comments about what I said about finding a solution > to my problems. Listening and reading all you (all) said actually helped me > understand a little deeper what's going on in the rc.firewall rules. I'd > probably not have gotten this knowledge if someone just gave me the magic > answer. I apologize if I ofended anyone. > Ben, thanks and hope that Crist's input provided answer to your questions. > > Here's my final rc.firewall file. And it WORKS!!!!!! Great. One question tho', [snip] > # If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 Why is this uncommented? -- Crist J. Clark cjclark@alum.mit.edu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 9:30:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by hub.freebsd.org (Postfix) with ESMTP id D7ECD37B42C for ; Thu, 21 Sep 2000 09:30:08 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA16273 for ; Thu, 21 Sep 2000 09:30:07 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA08030 for ; Thu, 21 Sep 2000 09:28:41 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for freebsd-net@FreeBSD.org; Thu, 21 Sep 2000 09:30:03 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id SAA24377 for freebsd-net@FreeBSD.org.DELIVER; Thu, 21 Sep 2000 18:30:01 +0200 (METDST) Received: from garfield.crm.mot.com (root@garfield.crm.mot.com [140.101.173.38]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id SAA24343; Thu, 21 Sep 2000 18:30:00 +0200 (METDST) Received: (from hennequi@localhost) by garfield.crm.mot.com (8.9.3/8.9.3) id SAA11854; Thu, 21 Sep 2000 18:29:40 +0200 X-Authentication-Warning: garfield.crm.mot.com: hennequi set sender to hennequi@garfield.crm.mot.com using -f To: freebsd-net@FreeBSD.org, pavlin@catarina.usc.edu Subject: IPv6 multicasting, pim6dd, MLD, icmp raw socket From: Eric Hennequin Date: 21 Sep 2000 18:29:40 +0200 Message-Id: Lines: 56 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Has anyone experience with pim6dd on FreeBSD 4.1 Release ? I have tried without success to use MLD (IGMPv6) with pim6dd, with the following setup : (host "b" has kernel with MROUTING support compiled in.) host "f" ethernet host "b" FreeBSD 4.0-------------------random linux with ipv6 enabled. pim6dd -d a udp client doing a IPV6_JOIN_GROUP on FF0E::57 | | unused ifaces tcpdump on host "f" shows the ICMPv6 MLD Membership Report for FF0E::57 . then the Done when I kill the client. but pim6dd doesn't show it in it's debug log. Now if I first run the same udp client on host f, (ifmcstat show me that the interface on host f is in the group FF0E::57) pim6dd gets the report/done from host "b" ! I tried using FreeBSD 4.1 Release on host "f", or FreeBSD on host "b", playing also with mldquery with the same results. (was mldquery written to test this in the first place ?) pim6dd set correctly the interface to ALLMULTI. Yet it seems the pim6dd ICMPv6 raw socket doesn't let the multicast message go through when there is no member in the group on the host. May I have misconfigured something ? A sysctl ? Could it be hardware ? (3COM 3c900-COMBO on host "b") Is it a know problem ? (Not found in the gnat database, nor by searching into the mailling list.) Just curious to know if it was just me who was unable to set up the thing ;-) -- Cordialement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 10:31:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 6004A37B422 for ; Thu, 21 Sep 2000 10:31:09 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 21 Sep 2000 10:29:11 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8LHUIM30796; Thu, 21 Sep 2000 10:30:18 -0700 (PDT) (envelope-from cjc) Date: Thu, 21 Sep 2000 10:30:18 -0700 From: "Crist J . Clark" To: Konan Houphoue Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Message-ID: <20000921103018.B30474@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Thu, Sep 21, 2000 at 09:26:28AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 21, 2000 at 09:26:28AM -0500, Konan Houphoue wrote: > #If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 > > I believe it is uncommented to keep the 2 interfaces on different network > but yet allowing local traffic on this computer. You are doing routing and NAT on this gateway, AND it is a bridge?! That's not a great idea. Did you really put, options BRIDGE In the kernel and flip the sysctl switches to turn bridging on? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 11:33: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f37.law4.hotmail.com [216.33.149.37]) by hub.freebsd.org (Postfix) with ESMTP id 3FE1937B42C for ; Thu, 21 Sep 2000 11:33:04 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Sep 2000 11:33:04 -0700 Received: from 159.10.4.47 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 21 Sep 2000 18:33:03 GMT X-Originating-IP: [159.10.4.47] From: "Konan Houphoue" To: cjclark@alum.mit.edu Cc: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Date: Thu, 21 Sep 2000 13:33:03 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2000 18:33:04.0089 (UTC) FILETIME=[60E68490:01C023FA] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'll check my configuration and get back to you on this tonight. KOnan ----Original Message Follows---- From: "Crist J . Clark" Reply-To: cjclark@alum.mit.edu To: Konan Houphoue CC: ari@suutari.iki.fi, marcs@draenor.org, archie@whistle.com, freebsd-net@freebsd.org, virtual_olympus@yahoo.com Subject: Re: Port 80 redirect: Good news!! Date: Thu, 21 Sep 2000 10:30:18 -0700 MIME-Version: 1.0 Received: from [64.6.192.82] by hotmail.com (3.2) with ESMTP id MHotMailBB9390DB00B0D82197A04006C0520BF90; Thu Sep 21 10:31:12 2000 Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 21 Sep 2000 10:29:11 -0700 Received: (from cjc@localhost)by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8LHUIM30796;Thu, 21 Sep 2000 10:30:18 -0700 (PDT)(envelope-from cjc) From cjc@149.211.6.64.reflexcom.com Thu Sep 21 10:35:11 2000 Message-ID: <20000921103018.B30474@149.211.6.64.reflexcom.com> References: X-Mailer: Mutt 1.0i In-Reply-To: ; from bahobab@hotmail.com on Thu, Sep 21, 2000 at 09:26:28AM -0500 Return-Path: cjc@149.211.6.64.reflexcom.com On Thu, Sep 21, 2000 at 09:26:28AM -0500, Konan Houphoue wrote: > #If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 > > I believe it is uncommented to keep the 2 interfaces on different network > but yet allowing local traffic on this computer. You are doing routing and NAT on this gateway, AND it is a bridge?! That's not a great idea. Did you really put, options BRIDGE In the kernel and flip the sysctl switches to turn bridging on? -- Crist J. Clark cjclark@alum.mit.edu _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 21 12:35:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 3238937B43F for ; Thu, 21 Sep 2000 12:35:21 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8LJVIv68265; Thu, 21 Sep 2000 20:31:18 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8LJQws65571; Thu, 21 Sep 2000 20:26:58 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009211926.e8LJQws65571@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Michael Kuzmin" Cc: "Brian Somers" , freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: Dying multi-link PPP In-Reply-To: Message from "Michael Kuzmin" of "Thu, 21 Sep 2000 13:16:08 +0400." <009801c023ae$078c70e0$1e0657c2@w9g8j7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 20:26:58 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> Our configuration is fairly standard, user-ppp with two modems and MP > >> enabled at both sides of the channel (see ppp.conf below), the only > >> pecularity is frequent redials due to telco (30 min call limit). It always > >> works OK after reload and initial connects, but subsequent modem redials > >> amont to accumulation of problems and performance degradation with > >> unavoidable death in several hours. > >> > >> The usual final (dead) state of the channel is an infinite series of short > >> connects each with LCP RecvTerminateReq in 15 sec after successful > >> authorization and lcp -> open. The origin of this dead state could be > >> tentitavely traced to simultaneous redial of both modem links, at that > >> moment old ppp master at answering side exits and all new ppp processes > >> born after that seems to unable to continue... > > [.....] > > > > I think the first thing to find out is why the SendTerminateReq is > > being sent. If you enable debug, lcp, ipcp & tcp/ip logs on that end > > (the server?), hopefully we'll see why it thinks it's a good idea to > > give up. > > > > You could also try > > > > disable pred1 deflate > > deny pred1 deflate > > > > in your mpd profile - I believe there may be a problem with compression > > at the moment. > > Thank you for this idea - I'll try it a bit later. > Meanwhile, it should be noted that we really _have_ many CCP-related errors > in logs, e.g. sequenses like that > > 15:56:30 atd ppp[336]: tun0: CCP: mp: RecvResetReq(11) state = Opened > 15:56:30 atd ppp[336]: tun0: CCP: Deflate: Output channel reset > 15:56:30 atd ppp[336]: tun0: CCP: mp: SendResetAck(11) state = Opened > > repeated tens or hundreds time in a line (or even for half an hour - our max > lifetime of the link) > > And I can also post some logs that I already have archived - these logs seems > to be relevant. > Here is what is going on around when SendTerminateReq is being sent > (all logging you requested exept debug were on, configs are just > that I posted last time): [.....] The only response that the peer makes after authentication in the log you sent is: > 19:52:16 atd ppp[915]: tun0: LCP: deflink: RecvTerminateAck(2) state = Closing It completely ignores all CCP and IPCP requests, and ppp ends up getting fed up and closing the link. I think you'll need to enclose a log of the entire conversation. > Sincerely yours, > Michael Kuzmun, > LASERnet -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 22 5: 4:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from new-urth.wamnet.com (mail-gw.wamnet.com [208.50.249.20]) by hub.freebsd.org (Postfix) with ESMTP id 6137637B422; Fri, 22 Sep 2000 05:04:07 -0700 (PDT) Received: from ndm.wamnet.com([172.17.38.2]) (2170 bytes) by new-urth.wamnet.com via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Wed, 20 Sep 2000 14:45:33 -0500 (CDT) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-7) Received: from ds.cops.wamnet.com (ds.cops.wamnet.com [172.17.31.2]) by ndm.wamnet.com (8.9.1a/8.9.1) with ESMTP id OAA1483945; Wed, 20 Sep 2000 14:45:33 -0500 (CDT) Received: from y.cops.wamnet.com (y.cops.wamnet.com [172.17.31.43]) by ds.cops.wamnet.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id OAA35645; Wed, 20 Sep 2000 14:45:32 -0500 (CDT) Date: Wed, 20 Sep 2000 14:45:18 -0500 (CDT) From: Lee J Carmichael X-Sender: lcarmich@y.cops.wamnet.com Reply-To: Lee J Carmichael To: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: network interface problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Everyone, I am having a problem with a network interface driver for a netfinity 4500R. The ethernet interface on this box is a AMD PCnet chip set(at least AMD). The issue is that ethernet interface is detected correctly on the PCI bus, but it logs the following message in dmesg: lnc0: port 0x2000-0x201f mem 0xfeb7fc00-0xfeb71c1f irq 11 at device 2.0 on pci0 lnc0: driver is using old-style compatability shims I edited the kernel config to only have: device lnc0 # without the ?isa parameters and, I tried device lnc # like other pci ethernet devices I did read through both '/usr/src/sys/i386/isa/if_lnc.c' and '/usr/src/sys/i386/pci/if_lnc_p.c'. But they didn't yield anything helpful. This could be due to my lack of understanding with how these drivers are loaded at boot time. One last piece of info, in my /etc/rc.conf file, I have: network_interfaces="lo0 lnc0" ifconfig_lnc0="inet xxx.xxx.xxx.xxx" Not that this really matters, since it just generates a 'lnc0 interface not found' or something like that. Any Ideas? Thanks for the help, in advance. -------- Lee Carmichael WAM!NET Inc. System Engineer 655 Lone Oak Rd Building E 651-256-5292 Eagan, MN 55121 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 22 12:58: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from server.osny.com.br (osny.com.br [200.215.110.57]) by hub.freebsd.org (Postfix) with ESMTP id 5061837B423 for ; Fri, 22 Sep 2000 12:57:53 -0700 (PDT) Received: from osny.com.br ([172.20.185.22]) by server.osny.com.br (8.10.1/8.10.1) with ESMTP id e8MJxQs12042 for ; Fri, 22 Sep 2000 16:59:28 -0300 (EST) Message-ID: <39CB90F2.16548DA8@osny.com.br> Date: Fri, 22 Sep 2000 17:03:46 +0000 From: Michelangelo Pisa Organization: Agencia Maritima Osny X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: free inglish Subject: Virus Filter Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi!! Can I do a protect configuration in my server Free to filter de atach of the message to don't come a virus in it? Case the atach is *.pif, *.vbs, *.shs, the server delete it, before the user get de messages... Is on firewall? Plis help-me Best Regards... -- Agencia Marítima Osny LTDA Mica's Michelangelo Pisa Administrador de Sistemas e Flamenguista E-mail: michelangelo@osny.com.br Fone: (0xx47) 348 2800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 22 17:41:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from milquetoast.cs.mcgill.ca (milquetoast.CS.McGill.CA [132.206.2.5]) by hub.freebsd.org (Postfix) with ESMTP id 7BAC137B422 for ; Fri, 22 Sep 2000 17:41:38 -0700 (PDT) Received: (from andrewb@localhost) by milquetoast.cs.mcgill.ca (8.9.3/8.9.3) id UAA02087 for freebsd-net@freebsd.org; Fri, 22 Sep 2000 20:41:37 -0400 (EDT) Date: Fri, 22 Sep 2000 20:41:37 -0400 From: Andrew BOGECHO To: freebsd-net@freebsd.org Subject: nfs error Message-ID: <20000922204137.P15880@cs.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: SOCS, McGill University, Montreal, CANADA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fri Sep 22 20:39:49 EDT 2000 Hi, We have recently been moving more and more to FreeBSD. The enjoyment of such a stable platform allows us to see that we are making the right decision. We do have one error message that shows up all the time. It does not affect us or our users, but it does make me curious. I have searched everywhere, and have only found one reference to this error, but no repies. The error message is as follows: /kernel: nfs send error 32 for server blah:/partitiona The above error message occurs sometimes several times a minute, a few times an hour, there is no preset frequency, but it is often. Our set up is as follows: Solaris 7 fileserver x86 FreeBSD 4.1 clients. amd.home entry: partitiona -type:=nfs;rfs:=/partitiona;opts:=rw,intr,nosuid,quota \ rhost:=blah This also occurred with 4.0 clients. Any help or insight into this message would be great. Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 22 19:14:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id EDBC837B42C; Fri, 22 Sep 2000 19:14:11 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1B00G14I7MY1@field.videotron.net>; Fri, 22 Sep 2000 22:14:10 -0400 (EDT) Date: Fri, 22 Sep 2000 22:17:49 -0400 (EDT) From: Bosko Milekic Subject: mbuf system and SMPng To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello folks, Well, I'm presently ready to receive and act upon comments following review of SMPng-related changes to the mbuf system. I urge everybody to glance over at the following: http://people.freebsd.org/~bmilekic/mtx_journal and http://people.freebsd.org/~bmilekic/mbuf_mtx-v5.diff The latter is a ~40k diff to the mbuf system, mostly, that adds mutex locking, and generally cleans it up a bit. I realize that this description is not so clear, which is why I've - following Alfred Perlstein's suggestion - kept a log of changes/informal journal, and that's what the first link is. If you're reviewing the code, please make sure to check out all of the entries. As mentionned, I'm looking for feedback: technical, stylistic, etc. Please be advised that some of the stuff can probably use a little of a style makeover, and if you stumble upon such a thing, let me know and I'll adjust the diff once enough comments are gathered. As I still don't have SMP hardware, I'm also looking for people with these resources to run this and provide me with comments/notes. I'm looking forward to getting a hold of some better equipment to test with. If there's anything I missed, please let me know. Thanks, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 22 22:51:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 0072137B424 for ; Fri, 22 Sep 2000 22:51:12 -0700 (PDT) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e8MB3bv17350 for freebsd-net@freebsd.org; Fri, 22 Sep 2000 13:03:38 +0200 (MEST) From: Frank Bonnet Message-Id: <200009221103.e8MB3bv17350@bart.esiee.fr> Subject: Simple NAT config / help ? To: freebsd-net@freebsd.org Date: Fri, 22 Sep 2000 13:03:37 MEST X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have to setup a machine that will act as NAT server I don't need much rules except I want to be able to filter clients accesses with IP addresses and maybe also MAC address. As I'm pretty new in nat/firewalling I need some basic examples to test my configuration. Any help welcome release is 4.1 and the machine is a P350 with two 10/100 ethernet boards. Thanks for any help. -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 2: 3: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 15EC937B422 for ; Sat, 23 Sep 2000 02:03:02 -0700 (PDT) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 582C66A901 for ; Sat, 23 Sep 2000 11:03:00 +0200 (CEST) Received: from sv.Go2France.com [212.73.210.79] by mail.Go2France.com with ESMTP (SMTPD32-6.04) id A2AA45630086; Sat, 23 Sep 2000 11:06:50 +0200 Message-Id: <5.0.0.25.0.20000923105128.02ee5840@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 23 Sep 2000 11:03:23 +0200 To: freebsd-net@FreeBSD.ORG From: Len Conrad Subject: Re: Virus Filter In-Reply-To: <39CB90F2.16548DA8@osny.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Mike > Can I do a protect configuration in my server Free to filter de >atach of the message to don't come a virus in it? > Case the atach is *.pif, *.vbs, *.shs, the server delete it, before >the user get de messages... > Is on firewall? Plis help-me > > Best Regards... These components can be built into a $99 SMTP in-line A-V scanning machine, unlimited domains and mailboxes (vs $30K for TrendMicro equivalent): 1. FreeBSD 2. postfix 3. avavis-perl, www.amavis.org 4. a-v scanner for FreeBSD mail servers, KasperskyLab.rom http://www.kaspersky.com/products.asp?tgroup=0&pgroup=3&id=34 a-v scanning is heavy slogging, (memory, CPU, disk i/o speed (RAID 1 + O is good), disk storage (incoming mail queue directory for mail tailback waiting to be scanned) can reduce the throughput of a good mail relay hub to just 10% or 20% of its non-AV-scanning capacity, esp if the SMTP traffic has lots of largish attachments. Len Http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 installable binary for NT4 http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 2:15:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.suxx.eu.org (os-kam.cust.KKS.net [195.250.198.225]) by hub.freebsd.org (Postfix) with ESMTP id 0497237B422 for ; Sat, 23 Sep 2000 02:15:43 -0700 (PDT) Received: by spider.suxx.eu.org (Postfix, from userid 1000) id 0258382; Sat, 23 Sep 2000 11:14:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by spider.suxx.eu.org (Postfix) with ESMTP id D53E01A; Sat, 23 Sep 2000 11:14:58 +0200 (CEST) Date: Sat, 23 Sep 2000 11:14:58 +0200 (CEST) From: MadDave To: Frank Bonnet Cc: freebsd-net@freebsd.org Subject: Re: Simple NAT config / help ? In-Reply-To: <200009221103.e8MB3bv17350@bart.esiee.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi First you must compile a new kernel with (Some of this choices are optional): options IPFIREWALL options IPDIVERT options IPFIREWALL_FORWARD options IPFILTER options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET #If you want to use traffic shaper options TCP_DROP_SYNFIN Fot NAT we use deamon called `natd` (see man page for details). Natd muse be binded to interface which is connected to internet. Then you run natd deamon. I run it like this: `/sbin/natd -unregistered_only -interface ed0 -s -dynamic`. In my case ed0 is the external NIC. Then you set up `ipfw` rules like `ipfw add divert natd ip from any to any via ed0` (change ed0 with your NIC name). Then you must also enable IP Forwarding. This is done by `sysctl -w net.inet.ip.forwarding=1`. Then you can filter clients by setting up a firewall (see `man ipfw`). Bye, David On Fri, 22 Sep 2000, Frank Bonnet wrote: > Hi > > I have to setup a machine that will act as NAT server > I don't need much rules except I want to be able to > filter clients accesses with IP addresses and maybe also > MAC address. > > As I'm pretty new in nat/firewalling I need some basic > examples to test my configuration. > > Any help welcome > > release is 4.1 and the machine is a P350 with two > 10/100 ethernet boards. > > Thanks for any help. > -- > Frank Bonnet > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 2:54:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 3340037B423 for ; Sat, 23 Sep 2000 02:54:46 -0700 (PDT) Received: from [193.189.182.161] ([193.189.182.161]:51500 "EHLO user.over.net") by mail.over.net with ESMTP id ; Sat, 23 Sep 2000 11:54:22 +0200 Message-Id: <4.3.2.7.2.20000923114808.02ff9a90@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Sep 2000 11:48:21 -0100 To: Michelangelo Pisa From: Tomaz Borstnar Subject: Re: Virus Filter Cc: free inglish In-Reply-To: <39CB90F2.16548DA8@osny.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:03 PM 22/09/00, Michelangelo Pisa wrote the following message: > Hi!! > Can I do a protect configuration in my server Free to filter de >atach of the message to don't come a virus in it? > Case the atach is *.pif, *.vbs, *.shs, the server delete it, before >the user get de messages... > Is on firewall? Plis help-me http://www.wolfenet.com/~jhardin/ Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 7: 6:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id 715B537B422; Sat, 23 Sep 2000 07:06:21 -0700 (PDT) Received: from jupiter.delta.ny.us (nyf-ny7-20.ix.netcom.com [198.211.17.148]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA04499; Sat, 23 Sep 2000 10:06:18 -0400 (EDT) Received: (from vsilyaev@localhost) by jupiter.delta.ny.us (8.9.3/8.9.3) id KAA00417; Sat, 23 Sep 2000 10:06:14 -0400 (EDT) (envelope-from vsilyaev) Date: Sat, 23 Sep 2000 10:06:14 -0400 (EDT) From: "Vladimir N. Silyaev" Message-Id: <200009231406.KAA00417@jupiter.delta.ny.us> To: nsayer@quack.kfu.com Cc: emulation@freebsd.org, net@freebsd.org Subject: Re: Bridging fix In-Reply-To: <39CCAC0A.ABCB738D@quack.kfu.com> References: <39CCAC0A.ABCB738D@quack.kfu.com> Reply-To: vns@delta.odessa.ua Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oh, great. Do you know, does that fixed problem with bridging code in the case when active more than two network interfaces? And probably that fix should significantly reduce perfomance for the case when bridging are used not for VMware needs ;-(. Vladimir In muc.lists.freebsd.emulation, you wrote: >This doesn't really have anything to do with emulation, except that lots >of vmware users hang out here. :-) > >I have figured out that the upper protocol layers are not yet completely >read-only with regards to mbufs coming in from downstream. What this >means is that the bridge code must use m_dup rather than m_copypacket >(the latter only bumps up refcounts to make it LOOK like you copied the >packet). > >So if you are having trouble getting a vmware guest to be a DHCP client >or otherwise participate correctly with broad- or multi-cast services, >change all instances of m_copypacket in /sys/net/bridge.c and >/sys/netgraph/ng_bridge.c to m_dup. That should fix it. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-emulation" in the body of the message > -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 11: 8:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 643CF37B424; Sat, 23 Sep 2000 11:08:20 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA18066; Sat, 23 Sep 2000 12:08:19 -0600 (MDT) Message-Id: <200009231808.MAA18066@berserker.bsdi.com> To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Fri, 22 Sep 2000 22:17:49 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 12:08:19 -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bosko, It looks like you can reduce the number of mutex operations and the number of locked operations if you call m_mballoc and m_mballoc_wait with the mmbfree mutex held. for the interim you may have to drop the lock in m_mballoc before acquiring Giant and calling kmem_malloc with the M_NOWAIT flag. Eventually you should just be able to call kmem_malloc with the M_NOWAIT flag and not release you lock. You will be able to get rid of some of the the atomic_add_long()s. For m_mballoc_wait you can get rid of the immediate re-acquire of the lock on entry. You would need to make a version of MGET which doesn't acquire the lock for use inside these routines. If you really want only one version of the code you could do this my creating a lower level macro the MGET calls, with macro aguments that are non-existance or (mtx_enter(...) and mtx_exit(...)). You can then replace the asleep and await with a msleep(&mmbfree.m_mtx). The way the code is now you could end up with the wakeup occurring before you even call asleep and then never waking up. Also calling asleep and await are more expensive than a single call to msleep() You also don't want to be calling MBWAKEUP on every MFREE. You should hold the state you need to decided to do this under the mmbfree mutex which you are already getting and releasing. You don't want to call wakeupone if you don't have to, it is yet another locked operation. I put this together real quick so if it isn't clear I'll be glad to expand. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 11:43:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 945B637B422; Sat, 23 Sep 2000 11:43:36 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1C00MG5RZQMP@field.videotron.net>; Sat, 23 Sep 2000 14:43:03 -0400 (EDT) Date: Sat, 23 Sep 2000 14:46:44 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng In-reply-to: <200009231808.MAA18066@berserker.bsdi.com> To: Chuck Paterson Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23 Sep 2000, Chuck Paterson wrote: > Bosko, > It looks like you can reduce the number of mutex operations > and the number of locked operations if you call m_mballoc and m_mballoc_wait > with the mmbfree mutex held. > > for the interim you may have to drop the lock in m_mballoc > before acquiring Giant and calling kmem_malloc with the M_NOWAIT flag. > Eventually you should just be able to call kmem_malloc with the > M_NOWAIT flag and not release you lock. Right, now that I look at it, MGET(HDR) can indeed be simplified a bunch by doing it this way. > You will be able to get rid of some of the the atomic_add_long()s. > > For m_mballoc_wait you can get rid of the immediate re-acquire > of the lock on entry. You would need to make a version of MGET which > doesn't acquire the lock for use inside these routines. If you really > want only one version of the code you could do this my creating a > lower level macro the MGET calls, with macro aguments that are non-existance > or (mtx_enter(...) and mtx_exit(...)). Indeed, the lock being released before the asleep() being called in m_mballoc_wait() is somewhat of a race. I was planning to get rid of the asleep/await combo anyway (noted in my journal). In fact, MGET() can be called even with the mutex held, it will just result in recursive grabbing of the mutex, but it's better to just re-arrange the macro with a lower-level one, as you say (I noticed BSD/OS does something like this). > You can then replace the asleep and await with a > msleep(&mmbfree.m_mtx). The way the code is now you could end up > with the wakeup occurring before you even call asleep and then > never waking up. Also calling asleep and await are more expensive > than a single call to msleep() Well, if it happens before asleep, it's not so bad because it will be woken up on the next MFREE(), since m_mballoc_wid will be incremented. But I agree that it should be changed to even rid ourselves of this race. > You also don't want to be calling MBWAKEUP on every MFREE. > You should hold the state you need to decided to do this under the mmbfree > mutex which you are already getting and releasing. You don't > want to call wakeupone if you don't have to, it is yet another > locked operation. Actually, MBWAKEUP() first makes sure to check m_mballoc_wid, and does so with the lock held, so it will not call wakeup_one() if nobody is sleeping. Note that MBWAKEUP() is always called with the necessary mutex held (whether it be the mclfree or mmbfree one). > I put this together real quick so if it isn't clear I'll be > glad to expand. > > Chuck Thanks, Chuck! I will be reviewing this tonight and rolling up a new diff. In the meantime, let me know if there's anything else... Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 12:21: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from quack.kfu.com (quack.kfu.com [205.178.90.194]) by hub.freebsd.org (Postfix) with ESMTP id 9240137B422; Sat, 23 Sep 2000 12:21:00 -0700 (PDT) Received: from morpheus.kfu.com (morpheus.kfu.com [205.178.90.230]) by quack.kfu.com (8.11.0/8.9.3) with ESMTP id e8NJKwe89812; Sat, 23 Sep 2000 12:20:58 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com by morpheus.kfu.com with ESMTP (8.11.0//ident-1.0) id e8NJKwK09352; Sat, 23 Sep 2000 12:20:58 -0700 (PDT) Message-ID: <39CD029A.ACCBF4A6@quack.kfu.com> Date: Sat, 23 Sep 2000 12:20:58 -0700 From: Nick Sayer X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en-GB, en-US, en MIME-Version: 1.0 To: vns@delta.odessa.ua Cc: emulation@freebsd.org, net@freebsd.org Subject: Re: Bridging fix References: <39CCAC0A.ABCB738D@quack.kfu.com> <200009231406.KAA00417@jupiter.delta.ny.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Vladimir N. Silyaev" wrote: > > Oh, great. > Do you know, does that fixed problem with bridging code in the case > when active more than two network interfaces? Packets that are for hosts not in the bridging table could be affected by the same corruption, but packets sent to only one destination would not be. Broadcast and multicast packets certainly would be. The best solution to problems of bridging two interfaces together you don't want bridged when running vmware is the ng_bridge solution. With the ng_bridge, you specifically attach vmware to a single Ethernet interface. None of the others are fiddled in any way. It's the cleanest solution. But it too suffers from broad/multicast UDP corruption, thus the need for this fix. > And probably that fix should significantly reduce perfomance for the > case when bridging are used not for VMware needs ;-(. I don't know if I'd use the word "significantly". Only packets that are sent to multiple destinations (that is, hosts not yet in the bridge table or broad/multicasts) would need to be copied. It's not as bad as it sounds. > > Vladimir > > In muc.lists.freebsd.emulation, you wrote: > >This doesn't really have anything to do with emulation, except that lots > >of vmware users hang out here. :-) > > > >I have figured out that the upper protocol layers are not yet completely > >read-only with regards to mbufs coming in from downstream. What this > >means is that the bridge code must use m_dup rather than m_copypacket > >(the latter only bumps up refcounts to make it LOOK like you copied the > >packet). > > > >So if you are having trouble getting a vmware guest to be a DHCP client > >or otherwise participate correctly with broad- or multi-cast services, > >change all instances of m_copypacket in /sys/net/bridge.c and > >/sys/netgraph/ng_bridge.c to m_dup. That should fix it. > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-emulation" in the body of the message > > > > -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 15:35:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 8688E37B42C; Sat, 23 Sep 2000 15:35:47 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA19401; Sat, 23 Sep 2000 16:35:27 -0600 (MDT) Message-Id: <200009232235.QAA19401@berserker.bsdi.com> To: Bosko Milekic Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Sat, 23 Sep 2000 14:46:44 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 16:35:27 -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } } Actually, MBWAKEUP() first makes sure to check m_mballoc_wid, and } does so with the lock held, so it will not call wakeup_one() if nobody is } sleeping. Note that MBWAKEUP() is always called with the necessary mutex } held (whether it be the mclfree or mmbfree one). } Right, you are. When you change the this it looks like you can also get rid of the atomic op in MBWAKEUP. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 15:43:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 834A237B422; Sat, 23 Sep 2000 15:43:14 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA19490; Sat, 23 Sep 2000 16:43:07 -0600 (MDT) Message-Id: <200009232243.QAA19490@berserker.bsdi.com> To: Bosko Milekic Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Sat, 23 Sep 2000 14:46:44 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 16:43:07 -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Date: Sat, 23 Sep 2000 14:46:44 -0400 From: Bosko Milekic To: Chuck Paterson Subject: Re: mbuf system and SMPng cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT } Indeed, the lock being released before the asleep() being called in } m_mballoc_wait() is somewhat of a race. I was planning to get rid of the } asleep/await combo anyway (noted in my journal). In fact, MGET() can be } called even with the mutex held, it will just result in recursive } grabbing of the mutex, but it's better to just re-arrange the macro with } a lower-level one, as you say (I noticed BSD/OS does something like } this). } One thing to remember about the recursive stuff is that passing a recursively held mutex to msleep() will not get the mutex released, it will only release it one time. This means that you likely won't be able to get a wakeup. This could be changed, but ->>in general<<- something has gone very wrong if the mutex passed in to msleep() is recursively held. There is likely a layer of code that is expecting that its data is protected, and is not expecting some other process to be able to get at it. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 16:40:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 59E7837B43E; Sat, 23 Sep 2000 16:39:45 -0700 (PDT) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8NNdMi98638; Sat, 23 Sep 2000 16:39:26 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.0/8.11.0) id e8NNbqS18868; Sat, 23 Sep 2000 16:37:52 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200009232243.QAA19490@berserker.bsdi.com> Date: Sat, 23 Sep 2000 16:37:51 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Chuck Paterson Subject: Re: mbuf system and SMPng Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, Bosko Milekic Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23-Sep-00 Chuck Paterson wrote: > > Date: Sat, 23 Sep 2000 14:46:44 -0400 > From: Bosko Milekic > To: Chuck Paterson > Subject: Re: mbuf system and SMPng > cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG > > Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT > > } Indeed, the lock being released before the asleep() being called in > } m_mballoc_wait() is somewhat of a race. I was planning to get rid of the > } asleep/await combo anyway (noted in my journal). In fact, MGET() can be > } called even with the mutex held, it will just result in recursive > } grabbing of the mutex, but it's better to just re-arrange the macro with > } a lower-level one, as you say (I noticed BSD/OS does something like > } this). > } > > One thing to remember about the recursive stuff is that > passing a recursively held mutex to msleep() will not get the > mutex released, it will only release it one time. This means > that you likely won't be able to get a wakeup. This could > be changed, but ->>in general<<- something has gone very wrong > if the mutex passed in to msleep() is recursively held. There > is likely a layer of code that is expecting that its data is protected, > and is not expecting some other process to be able to get at it. Hmm, do we want to add a KASSERT() to msleep() then to verify that the mutex isn't recursed when we release it? > Chuck -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 16:54:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 53F9637B424; Sat, 23 Sep 2000 16:54:42 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1D00H836F4KM@falla.videotron.net>; Sat, 23 Sep 2000 19:54:40 -0400 (EDT) Date: Sat, 23 Sep 2000 19:58:20 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng In-reply-to: To: John Baldwin Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23 Sep 2000, John Baldwin wrote: > Hmm, do we want to add a KASSERT() to msleep() then to verify > that the mutex isn't recursed when we release it? Yes... This is very important for the work that I'm doing because, although it would be out of the ordinary, I don't want to trip over some obfuscated way a protocol drain routine may end up in one of the mbuf "wait" routines (theoretically, this isn't possible, but let's just be 101% sure). Are you going to do it, or shall I? > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 17:15:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 88A7437B42C; Sat, 23 Sep 2000 17:15:38 -0700 (PDT) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8O0FMi99151; Sat, 23 Sep 2000 17:15:22 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.0/8.11.0) id e8O0Dqg19141; Sat, 23 Sep 2000 17:13:52 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 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: Sat, 23 Sep 2000 17:13:51 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Bosko Milekic Subject: Re: mbuf system and SMPng Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23-Sep-00 Bosko Milekic wrote: > > On Sat, 23 Sep 2000, John Baldwin wrote: > >> Hmm, do we want to add a KASSERT() to msleep() then to verify >> that the mutex isn't recursed when we release it? > > Yes... This is very important for the work that I'm doing because, > although it would be out of the ordinary, I don't want to trip over some > obfuscated way a protocol drain routine may end up in one of the mbuf > "wait" routines (theoretically, this isn't possible, but let's just be > 101% sure). > Are you going to do it, or shall I? I'm testing to make sure it builds ok, and I'll commit it once it does. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 23 23:19:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 5584337B422; Sat, 23 Sep 2000 23:19:02 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1D0042JO7OXQ@field.videotron.net>; Sun, 24 Sep 2000 02:19:00 -0400 (EDT) Date: Sun, 24 Sep 2000 02:22:41 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng (new revised diff) In-reply-to: To: Chuck Paterson Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Following Chuck Paterson's suggestions, I've reviewed the mbuf diff once again and diff'ed up a new revised version: http://people.freebsd.org/~bmilekic/mbuf_mtx-v6.diff I've really "axed" up sys/sys/mbuf.h, and have seperated the macros into more logical divisions, and ones that minimize code bloat (in fact, the diff is a TAD smaller, ~1.5k smaller). In effect, I've gotten rid of m_mballoc_wait_hdr and now just use m_mballoc_wait; much cleaner. Following Chuck's advice, I've minimized the hysterics over grabbing locks before and after the allocator routines. The only thing to note is that despite a mutex being held, certain mbstat members still need to be manipulated with atomic()s as they may sometimes be modified from code holding the mmbfree lock, and sometimes from code holding the mclfree lock (there are only 2 such members, if I recall). If you're reviewing, be sure to carefully look at the changes in sys/sys/mbuf.h. I've also tested this diff under heavy network load and a local mbuf starvation simulation, and it seemed to hold up pretty well (on UP hardware). Same deal for this version of the diff as before, comments/reports requested! Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message