From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:01:02 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E31C837B405 for ; Sun, 30 Mar 2003 11:01:02 -0800 (PST) Received: from cheer.mahoroba.org (flets20-070.kamome.or.jp [218.45.20.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C510643FAF for ; Sun, 30 Mar 2003 11:01:00 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:00Ui8Y93Hn1njthOnkFQxA3WlEbC9sS8F/THspZdcp6d6aAaLFsC8TDcojQ7qu8M@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)h2UJ0pq6056454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2003 04:00:51 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 31 Mar 2003 04:00:51 +0900 Message-ID: From: Hajimu UMEMOTO To: "Jeff W. Boote" In-Reply-To: <3E838784.F2F4E330@internet2.edu> References: <20030326134823.A7029@jamaica.grc.nasa.gov> <20030327104649.B18679@jamaica.grc.nasa.gov> <3E838784.F2F4E330@internet2.edu> User-Agent: xcite1.38> Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 dual-stack server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:01:04 -0000 Hi, >>>>> On Thu, 27 Mar 2003 16:21:40 -0700 >>>>> "Jeff W. Boote" said: boote> In any case - my server code works fine on 4.6 and 4.7 binding to both boote> address families. However, I have just received a report of it only boote> binding the v6 address on a FreeBSD 5.0 system. (As reported from boote> "netstat -a -p tcp" - and by the fact that clients that try and use the boote> v4 address are unable to get a connection.) boote> It is behaving as if the IPV6_BINDV6ONLY sockopt is set... Has the boote> "default" value for this changed? Yes. BTW, IPV6_BINDV6ONLY has been superseded by IPV6_V6ONLY. boote> Is it recommended that any server that wants to bind to the dual-stack boote> needs to make sure this sockopt is unset? I am not doing that... Yup, where you can do it, you should do so. However, I suggest opening two sockets, one is for IPv6 and the other is for IPv4, instead of using IPv4-mapped IPv6 address. boote> I just found the net.inet6.ip6.bindv6only sysctl variable doing a web boote> search... What is the default value for this sysctl on 5.0? net.inet6.ip6.bindv6only=1 by default on 5-CURRENT. boote> (I guess I may need to install 5.0 on a box, and stop bothering boote> others...) You don't need to install 5.0. You can simply get same effect by setting net.inet6.ip6.bindv6only=1. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:28:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA8A37B401 for ; Sun, 30 Mar 2003 11:28:16 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D3F243FB1 for ; Sun, 30 Mar 2003 11:28:16 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id A8BBE42D30; Sun, 30 Mar 2003 11:28:10 -0800 (PST) From: Wes Peters Organization: Softweyr To: "M. Warner Losh" , net@freebsd.org Date: Sun, 30 Mar 2003 11:28:09 -0800 User-Agent: KMail/1.5 References: <20030329.195108.133248709.imp@bsdimp.com> In-Reply-To: <20030329.195108.133248709.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303301128.09717.wes@softweyr.com> Subject: Re: ifconfig question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:28:20 -0000 On Saturday 29 March 2003 18:51, M. Warner Losh wrote: > The code that prints out the keys for the 802.11 wireless stuff has > the following it it: > > void > ieee80211_status (int s, struct rt_addrinfo *info __unused) > { > ... > if (ireq.i_len == 0 || ireq.i_len > 13) > continue; > ... > } > > Should that check really be there? Newer wep does 256bits.... Not > that the rest of the code supports that, but I was just curious. Only if the spec says those are the only valid ranges. Then we have to keep up to date with changes in the spec, too. Either some simple sanity checks or checking for truly valid lengths -- 0, 40 bits, 128 bits -- makes even better sense. > Second, should ifconfig report the wep key if run as root? wicontrol > does if it is run as root, for example. Any objections for fixing > this? That would be convenient. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 11:37:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C9337B401 for ; Sun, 30 Mar 2003 11:37:18 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B06043F85 for ; Sun, 30 Mar 2003 11:37:17 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h2UJbGA7021407; Sun, 30 Mar 2003 12:37:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 30 Mar 2003 12:35:44 -0700 (MST) Message-Id: <20030330.123544.51948571.imp@bsdimp.com> To: wes@softweyr.com From: "M. Warner Losh" In-Reply-To: <200303301128.09717.wes@softweyr.com> References: <20030329.195108.133248709.imp@bsdimp.com> <200303301128.09717.wes@softweyr.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: ifconfig question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:37:21 -0000 In message: <200303301128.09717.wes@softweyr.com> Wes Peters writes: : Only if the spec says those are the only valid ranges. Then we have to : keep up to date with changes in the spec, too. Either some simple sanity : checks or checking for truly valid lengths -- 0, 40 bits, 128 bits -- : makes even better sense. 128 bits isn't a valid length either. Only 40 and 104 bits, which we currently semi-bogusly report as 64-bit and 128-bit. Warner From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 12:11:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 939E137B408 for ; Sun, 30 Mar 2003 12:11:29 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27CC443F75 for ; Sun, 30 Mar 2003 12:11:27 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8FAE87B4A1; Sun, 30 Mar 2003 15:11:26 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2AA3C7B46E; Sun, 30 Mar 2003 15:11:25 -0500 (EST) Message-ID: <3E874F6C.A76F99E8@internet2.edu> Date: Sun, 30 Mar 2003 13:11:24 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20030326134823.A7029@jamaica.grc.nasa.gov> <20030327104649.B18679@jamaica.grc.nasa.gov> <3E838784.F2F4E330@internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 dual-stack server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 20:11:38 -0000 Hajimu UMEMOTO wrote: > boote> It is behaving as if the IPV6_BINDV6ONLY sockopt is set... Has the > boote> "default" value for this changed? > > Yes. > BTW, IPV6_BINDV6ONLY has been superseded by IPV6_V6ONLY. Ah - thanks. > boote> Is it recommended that any server that wants to bind to the dual-stack > boote> needs to make sure this sockopt is unset? I am not doing that... > > Yup, where you can do it, you should do so. > However, I suggest opening two sockets, one is for IPv6 and the other > is for IPv4, instead of using IPv4-mapped IPv6 address. Hmm. So the trade-off is calling select or using IN6_IS_ADDR_V4MAPPED? (My applications need to understand the addresses at a pretty detailed level anyway - I'll probably stick to the dual-stack method.) > boote> I just found the net.inet6.ip6.bindv6only sysctl variable doing a web > boote> search... What is the default value for this sysctl on 5.0? > > net.inet6.ip6.bindv6only=1 by default on 5-CURRENT. This seems to contradict the recommendation in RFC 3493 (which I realize is only informational)... I've been doing a web search to try and find some kind of record for the rational used for making this default to v6only. I haven't found anything substantial yet. Does anyone on this list know why? (I'm guessing there must be a good reason - and if so, I want to make sure I'm dealing with those issues in my applications.) > boote> (I guess I may need to install 5.0 on a box, and stop bothering > boote> others...) > > You don't need to install 5.0. You can simply get same effect by > setting net.inet6.ip6.bindv6only=1. Thanks! jeff From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 01:58:46 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FD4C37B401; Mon, 31 Mar 2003 01:58:46 -0800 (PST) Received: from c81-48.cable.netissat.bg (c81-48.cable.netissat.bg [213.130.81.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A1A43FBF; Mon, 31 Mar 2003 01:58:43 -0800 (PST) (envelope-from vladimir.terziev@sun-fish.com) Received: from sun-fish.com (postfix@fs.cmotd.com [192.168.33.253]) h2V8rqQo019644; Mon, 31 Mar 2003 10:53:54 +0200 (CEST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by antivirus.software (Postfix) with SMTP id A8B6F14A05; Mon, 31 Mar 2003 10:53:51 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.33.170]) by sun-fish.com (Postfix) with SMTP id 7E8A414A0B; Mon, 31 Mar 2003 10:53:50 +0200 (CEST) Date: Mon, 31 Mar 2003 11:53:52 +0300 From: Vladimir Terziev To: freebsd-hackers@FreeBSD.ORG Message-Id: <20030331115352.14573848.vlady@sun-fish.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.8.6claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.ORG Subject: vm_fault and nfs_getpages errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 09:58:49 -0000 Hi All, I have a diskless machine, which runs FreeBSD 4.7-R and samba on it. The machine has NFS mounted swap and filesystems on one of my servers. In fact the server is FreeBSD 4.7-R too. From time to time I get the following messages from kernel: nfs_getpages: error 13 vm_fault: pager read error, pid 3955 (smbd) pid 3955 (smbd), uid 65534: exited on signal 6 Does anybody have an idea, where is the problem? Vladimir From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 02:23:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E9B337B401 for ; Mon, 31 Mar 2003 02:23:22 -0800 (PST) Received: from mail.1system.ru (ns.1system.ru [62.205.190.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9426B43F93 for ; Mon, 31 Mar 2003 02:23:21 -0800 (PST) (envelope-from null@mail.1system.ru) Received: by mail.1system.ru (Postfix, from userid 1001) id C9C1149814; Mon, 31 Mar 2003 14:26:58 +0400 (MSD) Date: Mon, 31 Mar 2003 14:26:58 +0400 From: "Dennis S. Davidoff" To: freebsd-net Message-ID: <20030331102658.GA66056@mail.1system.ru> Mail-Followup-To: freebsd-net Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4i Subject: Need to frag (DF) :) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: null@1system.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 10:23:23 -0000 Hi all. After successful authorization and setting tunnel by mpd I've got a problem with packet fragmentation. rl0: flags=8843 mtu 1500 net 172.16.1.2 netmask 0xffffff00 broadcast 172.16.1.255 ether 00:02:44:2e:35:da media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 ether 00:10:dc:06:e8:91 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ng0: flags=88d1 mtu 1392 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff As you can see, mtu is 1392. So any attempt to open big content from site or download a big file will fail. tcpdump shows: 14:13:09.876867 172.16.1.2 > 217.106.231.104: icmp: 192.168.0.168 unreachable - need to frag (mtu 1392) (DF) ...and so on. Also I'll trying to test my gateway like that: C:\Documents and Settings\null>ping -f -l 1500 172.16.0.1 Pinging 172.16.0.1 with 1500 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 172.16.0.1: Packets: Sent = 2, Received = 0, Lost = 2 (100% loss), Control-C Someone from obsd tells me that in obsd pf it could be solved by the rule: scrub in all no-df fragment reassemble ...which defragments all packets and removes DF flag (i guess) P.S. On my gateway I have an ipfw rule that allows any icmp type. Thanks for any advices. -- Sincerely, Dennis From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 03:28:03 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACE6037B401 for ; Mon, 31 Mar 2003 03:28:03 -0800 (PST) Received: from mail.procreditbank.com (mail.procreditbank.com [212.95.179.198]) by mx1.FreeBSD.org (Postfix) with SMTP id B356443FBD for ; Mon, 31 Mar 2003 03:28:01 -0800 (PST) (envelope-from i.tanusheff@procreditbank.com) Received: (qmail 66563 invoked from network); 31 Mar 2003 11:27:59 -0000 Received: from unknown (HELO itaush) (172.16.248.250) by proxy.procreditbank.bg with SMTP; 31 Mar 2003 11:27:59 -0000 From: "Ivailo Tanusheff" To: Date: Mon, 31 Mar 2003 14:27:58 +0300 Organization: ProCredit Bank Message-ID: <060e01c2f778$9528a400$faf810ac@sof.procreditbank.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20030331102658.GA66056@mail.1system.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal cc: FreeBSD Net Subject: RE: Need to frag (DF) :) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: I.Tanusheff@procreditbank.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 11:28:05 -0000 Hi, I think you should lower the mtu value of the ng0 interface. This is because of the packet overhead. If you are using Windows XP, than you should enable multilink or you can't bypass this. Ivailo Tanusheff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Dennis S. Davidoff Sent: Monday, March 31, 2003 1:27 PM To: freebsd-net Subject: Need to frag (DF) :) Hi all. After successful authorization and setting tunnel by mpd I've got a problem with packet fragmentation. rl0: flags=8843 mtu 1500 net 172.16.1.2 netmask 0xffffff00 broadcast 172.16.1.255 ether 00:02:44:2e:35:da media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 ether 00:10:dc:06:e8:91 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ng0: flags=88d1 mtu 1392 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff As you can see, mtu is 1392. So any attempt to open big content from site or download a big file will fail. tcpdump shows: 14:13:09.876867 172.16.1.2 > 217.106.231.104: icmp: 192.168.0.168 unreachable - need to frag (mtu 1392) (DF) ...and so on. Also I'll trying to test my gateway like that: C:\Documents and Settings\null>ping -f -l 1500 172.16.0.1 Pinging 172.16.0.1 with 1500 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 172.16.0.1: Packets: Sent = 2, Received = 0, Lost = 2 (100% loss), Control-C Someone from obsd tells me that in obsd pf it could be solved by the rule: scrub in all no-df fragment reassemble ...which defragments all packets and removes DF flag (i guess) P.S. On my gateway I have an ipfw rule that allows any icmp type. Thanks for any advices. -- Sincerely, Dennis _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 07:53:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2BCB37B401 for ; Mon, 31 Mar 2003 07:53:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 215D743FCB for ; Mon, 31 Mar 2003 07:53:30 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h2VFrQv04580; Mon, 31 Mar 2003 07:53:26 -0800 (PST) Message-ID: <3E88646A.4050909@isi.edu> Date: Mon, 31 Mar 2003 07:53:14 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: null@1system.ru References: <20030331102658.GA66056@mail.1system.ru> In-Reply-To: <20030331102658.GA66056@mail.1system.ru> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020708040606040704070104" cc: freebsd-net Subject: Re: Need to frag (DF) :) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 15:53:34 -0000 This is a cryptographically signed message in MIME format. --------------ms020708040606040704070104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 3/31/2003 2:26 AM, Dennis S. Davidoff wrote: [snip] > > As you can see, mtu is 1392. So any attempt to open big content from > site or download a big file will fail. tcpdump shows: > > 14:13:09.876867 172.16.1.2 > 217.106.231.104: icmp: 192.168.0.168 > unreachable - need to frag (mtu 1392) (DF) > ...and so on. Try tcpmssd from ports, and bind it to ng0 after it comes up. It should diddle the MSS values in your TCP SYNs on the fly. (You may also have to do something similar on the tunnel endpoint for inbound connections.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms020708040606040704070104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDMzMTE1NTMxNFowIwYJKoZIhvcNAQkEMRYEFMu0WB0CEUSxAVoLwdSp 7PzenaorMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAgkLC8qE+pnRSylxgTSXhluIFklkEWOGLoHkN PMOxpbN9xphzLNON5pxpFWNdA+3gqWETlil1ISrWsIVTeJOTR04bjbD6ed61wCtt51AU3tTF zlewUdLx/w/hNzzr4eDSnsdPQHgfm3pu43MiaeddK8H0YkgX/E02EDRV2igkdMt1tBIR9eUo FwGY5G+5BE5gvsjV36cFocBSj/GZE0bDwZCLP0LbpnLDtMEKEK+aNc0xyu2ndvbx1btJtfJ1 Pt1frSNkumJc/KKREUc0sfJEwbf/nxz0uCznd+i38bS1KLGC0LbbtLIfjqM8n6jUPOdAhEI7 XpKYDPr665rVrfGTmAAAAAAAAA== --------------ms020708040606040704070104-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 08:13:45 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 521CC37B401 for ; Mon, 31 Mar 2003 08:13:45 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D4343F93 for ; Mon, 31 Mar 2003 08:13:44 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.8/8.12.3) with ESMTP id h2VGDWLA019545; Mon, 31 Mar 2003 08:13:32 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.8/8.12.3/Submit) id h2VGDWZc019544; Mon, 31 Mar 2003 08:13:32 -0800 Date: Mon, 31 Mar 2003 08:13:32 -0800 From: Brooks Davis To: "M. Warner Losh" Message-ID: <20030331081331.A27067@Odin.AC.HMC.Edu> References: <20030329.195108.133248709.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030329.195108.133248709.imp@bsdimp.com>; from imp@bsdimp.com on Sat, Mar 29, 2003 at 07:51:08PM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: ifconfig question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 16:13:46 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 29, 2003 at 07:51:08PM -0700, M. Warner Losh wrote: > The code that prints out the keys for the 802.11 wireless stuff has > the following it it: >=20 > void > ieee80211_status (int s, struct rt_addrinfo *info __unused) > { > ... > if (ireq.i_len =3D=3D 0 || ireq.i_len > 13) > continue; > ... > } >=20 > Should that check really be there? Newer wep does 256bits.... Not > that the rest of the code supports that, but I was just curious. It could probably be safely removed. > Second, should ifconfig report the wep key if run as root? wicontrol > does if it is run as root, for example. Any objections for fixing > this? That seems reasonable. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+iGkqXY6L6fI4GtQRAjhnAJ45/rc47RVaIUuNJoaxyEx9GDnhtQCfQn2g LWsSzP/qIEY5sfyj1ixcQnk= =dJOD -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 08:59:55 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCF8337B401 for ; Mon, 31 Mar 2003 08:59:55 -0800 (PST) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-181.gen.twtelecom.net [66.162.33.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13CF543F3F for ; Mon, 31 Mar 2003 08:59:55 -0800 (PST) (envelope-from jeff@expertcity.com) Received: from [10.4.1.134] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 1902dW-0000xi-00 for freebsd-net@freebsd.org; Mon, 31 Mar 2003 08:59:54 -0800 Message-ID: <3E88740A.5000606@expertcity.com> Date: Mon, 31 Mar 2003 08:59:54 -0800 From: Jeff Behl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Broadcom BCM5703X causing reboot? 4.8-RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 16:59:59 -0000 I saw some threads that seemed to relate to the bge driver in -net, so i thought i'd post here as well... FreeBSD blade7-bc2.sjc 4.8-RC2 FreeBSD 4.8-RC2 #1: Wed Mar 26 20:17:42 GMT 2003 i've had two reboots in the last 30 mins on a fairly heavly loaded web server (apache). the following immediately precedes both reboots (no more messages after this): Mar 28 19:15:29 blade7-bc2 /kernel: NMI ISA 24, EISA 0 Mar 28 19:15:29 blade7-bc2 /kernel: Mar 28 19:15:29 blade7-bc2 /kernel: NMI ISA 24, EISA 0 Mar 28 19:15:37 blade7-bc2 /kernel: bge1: watchdog timeout -- resetting Mar 28 19:15:38 blade7-bc2 /kernel: bge1: gigabit link up here's how the cards are detected: Mar 28 19:18:36 blade7-bc2 /kernel: bge0: mem 0xfbff0000-0xfbffffff irq 10 at device 1.0 on pci1 Mar 28 19:18:36 blade7-bc2 /kernel: bge0: Ethernet address: 00:09:6b:00:4f:ff Mar 28 19:18:36 blade7-bc2 /kernel: pcib2: on motherboard Mar 28 19:18:36 blade7-bc2 /kernel: pci2: on pcib2 Mar 28 19:18:36 blade7-bc2 /kernel: bge1: mem 0xf9ff0000-0xf9ffffff irq 11 at device 1.0 on pci2 Mar 28 19:18:36 blade7-bc2 /kernel: bge1: Ethernet address: 00:09:6b:00:50:00 any ideas or help? these are the first blades we've put into production (IBM bladecenter)...which isn't boding well at all for using the remaining 12 blades. the machines are only pumping out around 9Mb/s. from other threads on this list, it would seem others have seen these watchdog timeouts and related it to a possible error in the chipset itself. has this been confirmed? will disabling checksum offload, as someone mentioned, fix this? i wouldn't be surprised if this was some sort of chipset issue as the management module for the blades logs errors whenever i get a reboot: 09:56:25 (image1.sjc) PFA Alert, see preceding error in system error log. 09:56:22 (image1.sjc) 00150500 PERR: Master Read parity error Slot=00 VendID=14E4 DevID=16A7 Status=83 09:56:21 (image1.sjc) 00150700 PERR: Slave signaled parity error Slot=00 VendID=1166 DevID=0101 Status any help greatly appreciated. we would really like to keep this bladecenter and not have to look into moving to linux...bleh jeff From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 10:04:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956A437B401 for ; Mon, 31 Mar 2003 10:04:30 -0800 (PST) Received: from bal.ru (gw-balakovo-arcon.arcon.ru [195.42.159.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 565CD43F3F for ; Mon, 31 Mar 2003 10:04:23 -0800 (PST) (envelope-from oleg@bal.ru) Received: from 195.42.138.3 (oleg.bal.ru [195.42.138.3]) by bal.ru (8.11.0/8.11.1) with ESMTP id h2VI4DI82510 for ; Mon, 31 Mar 2003 22:04:15 +0400 (MSD) (envelope-from oleg@bal.ru) Date: Mon, 31 Mar 2003 22:04:17 +0400 From: Oleg Borowkov X-Mailer: The Bat! (v1.61) Personal Organization: LAI Firm X-Priority: 3 (Normal) Message-ID: <36215233799.20030331220417@bal.ru> To: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Trouble with wi (prism2.5_pci) in bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Oleg Borowkov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 18:04:34 -0000 Hi! Help me with config bridge - FreeBSD 4.8 Release # ifconfig wi0: flags=8943 mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:60:b3:6a:6a:0d media: IEEE 802.11 Wireless Ethernet autoselect status: associated ssid test 1:test stationname "FreeBSD WaveLAN/IEEE node" channel 1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 ed0: flags=8843 mtu 1500 ether 00:c0:df:fa:cd:7c sysctl net.link.ether.bridge_cfg=wi0,ed0 sysctl net.link.ether.bridge=1 sysctl net.inet.ip.forwarding=1 -- Oleg e-mail:oleg@bal.ru icq:34687903 From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 10:07:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9262337B401 for ; Mon, 31 Mar 2003 10:07:26 -0800 (PST) Received: from bal.ru (gw-balakovo-arcon.arcon.ru [195.42.159.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB7043F75 for ; Mon, 31 Mar 2003 10:07:21 -0800 (PST) (envelope-from oleg@bal.ru) Received: from 195.42.138.3 (oleg.bal.ru [195.42.138.3]) by bal.ru (8.11.0/8.11.1) with ESMTP id h2VI7GI83108 for ; Mon, 31 Mar 2003 22:07:16 +0400 (MSD) (envelope-from oleg@bal.ru) Date: Mon, 31 Mar 2003 22:07:20 +0400 From: Oleg Borowkov X-Mailer: The Bat! (v1.61) Personal Organization: LAI Firm X-Priority: 3 (Normal) Message-ID: <118215417514.20030331220720@bal.ru> To: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Trouble with wi (prism2.5_pci) in bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Oleg Borowkov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 18:07:27 -0000 Hi! Help me with config bridge - FreeBSD 4.8 Release: # ifconfig wi0: flags=8943 mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:60:b3:6a:6a:0d media: IEEE 802.11 Wireless Ethernet autoselect status: associated ssid test 1:test stationname "FreeBSD WaveLAN/IEEE node" channel 1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 ed0: flags=8843 mtu 1500 ether 00:c0:df:fa:cd:7c sysctl net.link.ether.bridge_cfg=wi0,ed0 sysctl net.link.ether.bridge=1 sysctl net.inet.ip.forwarding=1 all work fine, but birdging don't work :-(( how i can debug bridge? Thank's... -- Oleg e-mail:oleg@bal.ru icq:34687903 From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 10:14:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A010937B401 for ; Mon, 31 Mar 2003 10:14:30 -0800 (PST) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EABE43F93 for ; Mon, 31 Mar 2003 10:14:29 -0800 (PST) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.11.6/8.11.6) with ESMTP id h2VIEIR2274269; Mon, 31 Mar 2003 22:14:18 +0400 (MSD) Date: Mon, 31 Mar 2003 22:14:18 +0400 (MSD) From: Maxim Konovalov To: Oleg Borowkov In-Reply-To: <118215417514.20030331220720@bal.ru> Message-ID: <20030331221322.J73152@news1.macomnet.ru> References: <118215417514.20030331220720@bal.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Trouble with wi (prism2.5_pci) in bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 18:14:32 -0000 On 22:07+0400, Mar 31, 2003, Oleg Borowkov wrote: > Hi! > > Help me with config bridge - FreeBSD 4.8 Release: > > # ifconfig > wi0: flags=8943 mtu 1500 > inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 > ether 00:60:b3:6a:6a:0d > media: IEEE 802.11 Wireless Ethernet autoselect > status: associated > ssid test 1:test > stationname "FreeBSD WaveLAN/IEEE node" > channel 1 authmode OPEN powersavemode OFF powersavesleep 100 > wepmode OFF weptxkey 1 > ed0: flags=8843 mtu 1500 > ether 00:c0:df:fa:cd:7c > > > sysctl net.link.ether.bridge_cfg=wi0,ed0 > sysctl net.link.ether.bridge=1 > sysctl net.inet.ip.forwarding=1 > > all work fine, but birdging don't work :-(( > how i can debug bridge? s/#define DEB(x)/#define DEB(x) x/ in sys/net/bridge.c, recompile and reload bridge.ko. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 11:55:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04C1737B401 for ; Mon, 31 Mar 2003 11:55:40 -0800 (PST) Received: from andrea.pop4.net (216-234-109-11.ded.det2.hexcom.net [216.234.109.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 12B5343FAF for ; Mon, 31 Mar 2003 11:55:39 -0800 (PST) (envelope-from vev@michvhf.com) Received: (qmail 62217 invoked by uid 1008); 31 Mar 2003 19:55:43 -0000 Received: from vev@michvhf.com by www.pop4.net with qmail-scanner-0.96 (uvscan: v4.1.40/v4156. . Clean. Processed in 4.172945 secs); 31 Mar 2003 19:55:43 -0000 Received: from unknown (HELO paprika.michvhf.com) (67.36.71.182) by 0 with SMTP; 31 Mar 2003 19:55:37 -0000 Received: (qmail 5633 invoked by uid 1001); 31 Mar 2003 19:55:25 -0000 Date: Mon, 31 Mar 2003 14:55:25 -0500 (EST) From: Vince Vielhaber To: Maxim Konovalov In-Reply-To: <20030331221322.J73152@news1.macomnet.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Oleg Borowkov Subject: Re: Trouble with wi (prism2.5_pci) in bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 19:55:41 -0000 On Mon, 31 Mar 2003, Maxim Konovalov wrote: > On 22:07+0400, Mar 31, 2003, Oleg Borowkov wrote: > > > Hi! > > > > Help me with config bridge - FreeBSD 4.8 Release: Don't you have to be in hostap mode to bridge? Or was that changed in 4.8? > > > > # ifconfig > > wi0: flags=8943 mtu 1500 > > inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 > > ether 00:60:b3:6a:6a:0d > > media: IEEE 802.11 Wireless Ethernet autoselect > > status: associated > > ssid test 1:test > > stationname "FreeBSD WaveLAN/IEEE node" > > channel 1 authmode OPEN powersavemode OFF powersavesleep 100 > > wepmode OFF weptxkey 1 > > ed0: flags=8843 mtu 1500 > > ether 00:c0:df:fa:cd:7c > > > > > > sysctl net.link.ether.bridge_cfg=wi0,ed0 > > sysctl net.link.ether.bridge=1 > > sysctl net.inet.ip.forwarding=1 > > > > all work fine, but birdging don't work :-(( > > how i can debug bridge? > > s/#define DEB(x)/#define DEB(x) x/ in sys/net/bridge.c, recompile and > reload bridge.ko. > > -- > Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 04:26:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C7C437B401 for ; Tue, 1 Apr 2003 04:26:38 -0800 (PST) Received: from cheer.mahoroba.org (flets20-070.kamome.or.jp [218.45.20.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055E243FBD for ; Tue, 1 Apr 2003 04:26:36 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:X2imlJ3dUWmwN8c4i/lfqa60366u+HbF2mix4R4QLLhLIbuBE6ic+k4+MFZJQsc/@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)h31CQOq6075322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2003 21:26:24 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 01 Apr 2003 21:26:23 +0900 Message-ID: From: Hajimu UMEMOTO To: "Jeff W. Boote" In-Reply-To: <3E874F6C.A76F99E8@internet2.edu> References: <20030326134823.A7029@jamaica.grc.nasa.gov> <20030327104649.B18679@jamaica.grc.nasa.gov> <3E838784.F2F4E330@internet2.edu> <3E874F6C.A76F99E8@internet2.edu> User-Agent: xcite1.38> Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 dual-stack server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 12:26:38 -0000 Hi, >>>>> On Sun, 30 Mar 2003 13:11:24 -0700 >>>>> "Jeff W. Boote" said: boote> Hmm. So the trade-off is calling select or using IN6_IS_ADDR_V4MAPPED? Yes. boote> (My applications need to understand the addresses at a pretty detailed boote> level anyway - I'll probably stick to the dual-stack method.) What do you mean the dual-stack method, here? If you mean that you want to format IP address to string form, you can use getnameinfo() for this purpose. getnameinfo() is address family independent function. boote> This seems to contradict the recommendation in RFC 3493 (which I realize boote> is only informational)... I've been doing a web search to try and find boote> some kind of record for the rational used for making this default to boote> v6only. I haven't found anything substantial yet. Does anyone on this boote> list know why? (I'm guessing there must be a good reason - and if so, I boote> want to make sure I'm dealing with those issues in my applications.) Yes, this breakage against RFC2553/3493 is intentional. Please refer: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 08:15:33 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECEED37B401 for ; Tue, 1 Apr 2003 08:15:33 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAC5B43FA3 for ; Tue, 1 Apr 2003 08:15:32 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id F323972511 for ; Tue, 1 Apr 2003 18:15:30 +0200 (CEST) Received: by notbsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 6BF295A9F8; Tue, 1 Apr 2003 18:15:20 +0200 (CEST) To: Mailing List FreeBSD Network From: Eric Masson X-Operating-System: FreeBSD 4.8-RC i386 Date: Tue, 01 Apr 2003 18:15:20 +0200 Message-ID: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.4 (Common Lisp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 16:15:34 -0000 Hello I'm using IPSEC tunnels to join different gateways over the Internet. I've made some trials with FAST_IPSEC today (I've received a Soekris VPN1201) and i'm facing a problem with incoming packets. The following code snippet from /sys/netinet/ip_input.c permits detunneled packets to flow without being filtered by ipf/ipfw : #if defined(IPSEC) && !defined(IPSEC_FILTERGIF) /* * Bypass packet filtering for packets from a tunnel (gif). */ if (ipsec_gethist(m, NULL)) goto pass; #endif Is there any counterpart for FAST_IPSEC (I've dug thru the code, but no luck atm) ? Regards. Eric Masson -- je me suis créé un tas d'amis virtuels. Pourquoi cette sympathie? le flux peut-être magnétique que je dégage, vu que je guéris les brûlures par pression de mes mains sur les plaies et cloques. Et c'est vrai. -+- DD in C'est vrai je l'ai lu sur usenet -+- From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 08:29:32 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6EF237B401 for ; Tue, 1 Apr 2003 08:29:31 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4031543F75 for ; Tue, 1 Apr 2003 08:29:26 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 27DBF7B4CA; Tue, 1 Apr 2003 11:29:23 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AEBAF7B4C1; Tue, 1 Apr 2003 11:29:21 -0500 (EST) Message-ID: <3E89BE61.3EDE4AEF@internet2.edu> Date: Tue, 01 Apr 2003 09:29:21 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20030326134823.A7029@jamaica.grc.nasa.gov> <20030327104649.B18679@jamaica.grc.nasa.gov> <3E838784.F2F4E330@internet2.edu> <3E874F6C.A76F99E8@internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 dual-stack server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 16:29:32 -0000 Hajimu UMEMOTO wrote: > boote> This seems to contradict the recommendation in RFC 3493 (which I realize > boote> is only informational)... I've been doing a web search to try and find > boote> some kind of record for the rational used for making this default to > boote> v6only. I haven't found anything substantial yet. Does anyone on this > boote> list know why? (I'm guessing there must be a good reason - and if so, I > boote> want to make sure I'm dealing with those issues in my applications.) > > Yes, this breakage against RFC2553/3493 is intentional. Please refer: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Thanks! So... This would mean an application that wanted to be address independent would have to create a socket for every single wildcard sockaddr returned from getaddrinfo. And then use select/accept instead of just accept. That is kind of ugly... But, I guess it does make sense in the new world of multiple addresses and address families per host. jeff From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 11:03:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7714037B401 for ; Tue, 1 Apr 2003 11:03:40 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E349443FCB for ; Tue, 1 Apr 2003 11:03:39 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h31J3cWJ049008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Apr 2003 11:03:39 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <05b901c2f881$67e907f0$52557f42@errno.com> From: "Sam Leffler" To: "Mailing List FreeBSD Network" , "Eric Masson" References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> Date: Tue, 1 Apr 2003 11:03:05 -0800 Organization: Errno Consulting 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.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 19:03:40 -0000 > I'm using IPSEC tunnels to join different gateways over the Internet. > > I've made some trials with FAST_IPSEC today (I've received a Soekris > VPN1201) and i'm facing a problem with incoming packets. > > The following code snippet from /sys/netinet/ip_input.c permits > detunneled packets to flow without being filtered by ipf/ipfw : > > #if defined(IPSEC) && !defined(IPSEC_FILTERGIF) > /* > * Bypass packet filtering for packets from a tunnel (gif). > */ > if (ipsec_gethist(m, NULL)) > goto pass; > #endif > > Is there any counterpart for FAST_IPSEC (I've dug thru the code, but no > luck atm) ? Wow, someone besides me actually using fast ipsec! :) Packets are tagged once they've been processed on input. I think you can do a similar check with something like: if (m_tag_find(PACKET_TAG_IPSEC_IN_DONE) != NULL) goto pass; Long term, I intend is to associate packets with an enc device so there's a way to identify these packets when writing firewall rules. Sam From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 12:19:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B556C37B401 for ; Tue, 1 Apr 2003 12:19:48 -0800 (PST) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 12C4B43FA3 for ; Tue, 1 Apr 2003 12:19:48 -0800 (PST) (envelope-from kudzu@tenebras.com) Received: (qmail 56861 invoked from network); 1 Apr 2003 20:19:45 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 1 Apr 2003 20:19:45 -0000 Message-ID: <3E89F45F.1060506@tenebras.com> Date: Tue, 01 Apr 2003 12:19:43 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> In-Reply-To: <05b901c2f881$67e907f0$52557f42@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 20:19:49 -0000 Sam Leffler wrote: > Wow, someone besides me actually using fast ipsec! :) At least two of us, besides you... > > Packets are tagged once they've been processed on input. I think you can do > a similar check with something like: > > if (m_tag_find(PACKET_TAG_IPSEC_IN_DONE) != NULL) > goto pass; > > Long term, I intend is to associate packets with an enc device so there's a > way to identify these packets when writing firewall rules. That would be really helpful. From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 14:22:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C783037B401 for ; Tue, 1 Apr 2003 14:22:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E2B43FAF for ; Tue, 1 Apr 2003 14:22:49 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (tether-13.isi.edu [128.9.235.13]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h31MMb124275; Tue, 1 Apr 2003 14:22:37 -0800 (PST) Message-ID: <3E8A1122.5040304@isi.edu> Date: Tue, 01 Apr 2003 14:22:26 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> In-Reply-To: <05b901c2f881$67e907f0$52557f42@errno.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020207090401060203000608" cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 22:22:50 -0000 This is a cryptographically signed message in MIME format. --------------ms020207090401060203000608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 4/1/2003 11:03 AM, Sam Leffler wrote: > > Long term, I intend is to associate packets with an enc device so > there's a way to identify these packets when writing firewall rules. Alternatively (and already working), you can replace IPsec tunnel mode with IPIP (gif) tunnels and transport mode, and then use the gif device in your firewall rules. It doesn't give you the full expressiveness of IPsec selectors, but it's good enough for many VPN schemes (and routing works!) (See ftp://ftp.rfc-editor.org/internet-drafts/draft-touch-ipsec-vpn-04.txt; I have the -05 update almost ready, which will then go to Informational.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms020207090401060203000608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQwMTIyMjIyNlowIwYJKoZIhvcNAQkEMRYEFO/8UsOZkza12lqV1aIa r2tV3sdRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAZXNBH2/lEpQBZOf96NACuge8sgI9GVfajlqG Acg6qvFWC82b5Y92EQDSn8grWzy8zErChBR/aNSSF14H8r9hGITE811KJ/4Cz3rWRHIpedTw hAb8STtMm7rfjNACUlE0upOrsYrBUC/94SI6sBUkSOpK5WLAFe3DZ+0w+ftwYL1exWSIHT9s EuyPo44MGbszhiMuozkWv8WRwPGmr6UmnAdsyKGplQzDvLm2aIAxuuSL5YdL2iw7p3WSGiRX 9OyRecYXqoBxDy5v8szMrg0Yqj2wQV58mZeomXJpbJbimTttvDp1nK43k7iT6Cw/OZ9XRi1U w9MwlRVlgwJK9cNYfwAAAAAAAA== --------------ms020207090401060203000608-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 14:32:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E35737B401 for ; Tue, 1 Apr 2003 14:32:40 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DD1743F85 for ; Tue, 1 Apr 2003 14:32:39 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h31MWcWJ049993 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Apr 2003 14:32:38 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <075f01c2f89e$99dffdf0$52557f42@errno.com> From: "Sam Leffler" To: "Lars Eggert" References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com><05b901c2f881$67e907f0$52557f42@errno.com> <3E8A1122.5040304@isi.edu> Date: Tue, 1 Apr 2003 14:32:38 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 22:32:40 -0000 > On 4/1/2003 11:03 AM, Sam Leffler wrote: > > > > Long term, I intend is to associate packets with an enc device so > > there's a way to identify these packets when writing firewall rules. > > Alternatively (and already working), you can replace IPsec tunnel mode > with IPIP (gif) tunnels and transport mode, and then use the gif device > in your firewall rules. > > It doesn't give you the full expressiveness of IPsec selectors, but it's > good enough for many VPN schemes (and routing works!) Yes, but for folks that want to use fast ipsec as a plug-compatible replacement for KAME having an equivalent facility is important. I'm actually more interested in the ability to monitor traffic post-IPSEC processing (e.g. with tcpdump). But as I said privately to another person, I haven't decided exactly how to deal with this issue yet. I watched all the discussion on this and other mailing lists and when I have time I'll deal with it. Someone with time now is free to work on it... Sam From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 05:31:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF3DE37B401; Wed, 2 Apr 2003 05:31:11 -0800 (PST) Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7F5643FA3; Wed, 2 Apr 2003 05:31:08 -0800 (PST) (envelope-from matt@gsicomp.on.ca) Received: from gabby.gsicomp.on.ca ([65.95.176.5]) by tomts13-srv.bellnexxia.netESMTP <20030402133107.SNMB21994.tomts13-srv.bellnexxia.net@gabby.gsicomp.on.ca>; Wed, 2 Apr 2003 08:31:07 -0500 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by gabby.gsicomp.on.ca (8.12.6/8.12.6) with SMTP id h32DS4iG040963; Wed, 2 Apr 2003 08:28:04 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <00bc01c2f91b$f5bd1cc0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Dan Langille" , References: <3E8A9B83.6325.D150C9A@localhost> Date: Wed, 2 Apr 2003 08:29:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 cc: freebsd-net@freebsd.org Subject: Re: How do I specify a unit for ppp? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 13:31:12 -0000 ----- Original Message ----- From: "Dan Langille" To: Sent: Wednesday, April 02, 2003 8:12 AM Subject: How do I specify a unit for ppp? > >From man ppp I see this: > > The -unit flag tells ppp to only attempt to open /dev/tunN. > > I want it to use tun0. I can't see a way to specify a unit in > /etc/rc.conf. > > Clues? > -- > Dan Langille : http://www.langille.org/ We really need a ppp_flags variable in /etc/rc.conf which is recognized by /etc/rc.network for this kind of thing. Then you could specificy ppp_flags="-unit 0" in /etc/rc.conf and be on your way. Patches against 4.7-REL (sorry, I don't have an up-to-date -stable box). Comments requested; I will submit a PR with patches against -stable later today. --- rc.network.orig Wed Apr 2 08:23:43 2003 +++ rc.network Wed Apr 2 08:24:07 2003 @@ -284,7 +284,7 @@ ;; esac - ppp_command="${ppp_command} ${ppp_profile}" + ppp_command="${ppp_command} ${ppp_flags} ${ppp_profile}" echo "Starting ppp as \"${ppp_user}\"" su -m ${ppp_user} -c "exec ${ppp_command}" --- defaults/rc.conf.orig Wed Apr 2 08:23:12 2003 +++ defaults/rc.conf Wed Apr 2 08:23:36 2003 @@ -108,6 +108,7 @@ ppp_nat="YES" # Use PPP's internal network address translation or NO. ppp_profile="papchap" # Which profile to use from /etc/ppp/ppp.conf. ppp_user="root" # Which user to run ppp as +ppp_flags="" # Additional flags to pass to ppp(8). ### Network daemon (miscellaneous) ### syslogd_enable="YES" # Run syslog daemon (or NO). -- Matt Emmerton From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 06:55:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 244F037B401 for ; Wed, 2 Apr 2003 06:55:29 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591D343F3F for ; Wed, 2 Apr 2003 06:55:27 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id C44FC72512; Wed, 2 Apr 2003 16:55:24 +0200 (CEST) Received: by notbsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 0CAA75AA43; Wed, 2 Apr 2003 16:55:14 +0200 (CEST) To: "Sam Leffler" From: Eric Masson In-Reply-To: <05b901c2f881$67e907f0$52557f42@errno.com> (Sam Leffler's message of "Tue, 1 Apr 2003 11:03:05 -0800") References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> X-Operating-System: FreeBSD 4.8-RC i386 Date: Wed, 02 Apr 2003 16:55:13 +0200 Message-ID: <8665pxrlta.fsf@notbsdems.interne.kisoft-services.com> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.4 (Common Lisp, berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 14:55:29 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Sam" == Sam Leffler writes: Sam> Wow, someone besides me actually using fast ipsec! :) You're not alone ;) Sam> Packets are tagged once they've been processed on input. I think Sam> you can do a similar check with something like: Ok patch against 4.8-RELEASE attached. Sam> Long term, I intend is to associate packets with an enc device so Sam> there's a way to identify these packets when writing firewall Sam> rules. Fine. Thanks a lot Eric Masson -- > Nous recherchons une streap-teaseuse confirmée pour animer des dîners > dansants en région parisienne. Cette offre est sérieuse. Email pour > premier contact : gxxxx@club-internet.fr Tél Philippe : 0142458XXX -+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+- --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ip_input.c.diff *** ip_input.c.orig Wed Apr 2 16:50:54 2003 --- ip_input.c Wed Apr 2 16:18:57 2003 *************** *** 432,437 **** --- 432,445 ---- goto pass; #endif + #if defined(FAST_IPSEC) && !defined(IPSEC_FILTERGIF) + /* + * Bypass packet filtering for packets from a tunnel (gif). + */ + if (m_tag_find(m, PACKET_TAG_IPSEC_IN_DONE, NULL) != NULL) + goto pass; + #endif + /* * IpHack's section. * Right now when no processing on packet has done --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 07:58:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1AD37B404 for ; Wed, 2 Apr 2003 07:58:34 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C179943F3F for ; Wed, 2 Apr 2003 07:58:32 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id 0678372532; Wed, 2 Apr 2003 17:58:30 +0200 (CEST) Received: by notbsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 815ED5A7A5; Wed, 2 Apr 2003 17:58:02 +0200 (CEST) To: Lars Eggert From: Eric Masson In-Reply-To: <3E8A1122.5040304@isi.edu> (Lars Eggert's message of "Tue, 01 Apr 2003 14:22:26 -0800") References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> <3E8A1122.5040304@isi.edu> X-Operating-System: FreeBSD 4.8-RC i386 Date: Wed, 02 Apr 2003 17:58:02 +0200 Message-ID: <86fzp0riwl.fsf@notbsdems.interne.kisoft-services.com> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.4 (Common Lisp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Sam Leffler cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 15:58:34 -0000 >>>>> "Lars" == Lars Eggert writes: Lars> Alternatively (and already working), you can replace IPsec tunnel Lars> mode with IPIP (gif) tunnels and transport mode, and then use the Lars> gif device in your firewall rules. If transport mode can be used to connect to a pix, it's a solution to consider, but atm, I've found no reference to such a setup on the pix. I've tried gif tunnels with ipsec tunnel mode and didn't get reproduceable results, this setup worked once with the following gif setup : #!/bin/sh if ! PREFIX=$(expr $0 : "\(/.*\)/etc/rc\.d/${0##*/}\$"); then echo "$0: Cannot determine the PREFIX" >&2 exit 1 fi case "$1" in start) # Setup Chantilly local_extern=XXX.XXX.XXX.XXX remote_extern=XXX.XXX.XXX.XXX local_intern=192.168.1.0 remote_intern=192.168.0.0 local_mask=255.255.255.0 remote_mask=255.255.255.0 ifconfig gif0 create ifconfig gif0 tunnel $local_extern $remote_extern ifconfig gif0 inet $local_intern netmask $local_mask $remote_intern netmask $remote_mask echo -n ' tunnel' ;; stop) ifconfig gif0 destroy echo -n ' tunnel' ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Next time, after a reboot (kernel switch) no packets were flowing thru the gif tunnel. I gave up and switched back to plain ipsec tunnel without gifs, hence the original question. Eric Masson -- PR> tu es en avance d'un an pour le nouveau millénaire il me semble que (2000) est bien le nouveau millenaire justement par contre on change de siecle l'annee prochaine en 2001 -+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile. From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 08:21:09 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9CDF37B401 for ; Wed, 2 Apr 2003 08:21:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 268C343FBF for ; Wed, 2 Apr 2003 08:21:09 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (tether-13.isi.edu [128.9.235.13]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h32GL3103556; Wed, 2 Apr 2003 08:21:03 -0800 (PST) Message-ID: <3E8B0DE1.1030500@isi.edu> Date: Wed, 02 Apr 2003 08:20:49 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Masson References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> <3E8A1122.5040304@isi.edu> <86fzp0riwl.fsf@notbsdems.interne.kisoft-services.com> In-Reply-To: <86fzp0riwl.fsf@notbsdems.interne.kisoft-services.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003080109060300040500" cc: Sam Leffler cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 16:21:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040003080109060300040500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric, On 4/2/2003 7:58 AM, Eric Masson wrote: >>>>>>"Lars" == Lars Eggert writes: > > Lars> Alternatively (and already working), you can replace IPsec tunnel > Lars> mode with IPIP (gif) tunnels and transport mode, and then use the > Lars> gif device in your firewall rules. > > If transport mode can be used to connect to a pix, it's a solution to > consider, but atm, I've found no reference to such a setup on the pix. what's a pix? But chances are, you will need to control both endpoints for my suggestion to work. > I've tried gif tunnels with ipsec tunnel mode and didn't get > reproduceable results, this setup worked once with the following gif > setup : [snip] > Next time, after a reboot (kernel switch) no packets were flowing thru > the gif tunnel. Yes, combining tunnel mode and IPIP tunnels is not a good idea. Basically, that approach creates two parallel virtual topologies, one out of IPIP tunnels, and one out of IPsec tunnel mode SAs. People often do this, because they want to route traffic into an IPsec tunnel, and the SA itself doesn't have a route entry, since they aren't devices. When using IPIP tunnels with tunnel mode, they abuse the route created by the gif device for routing, but packets will be hijacked by the tunnel mode SA, so they never actually enter gif processing (IPsec does the IPIP encapsulation internally.) Using IPIP tunnels with transport mode is valid, since packets will actually flow through the gif device, and get IPsec'ed after they are IPIP encapsulated. (In multihop topologies, they'll then need to be IPIP encapsulated again - the virtual network needs both virtual link and network layers.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms040003080109060300040500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQwMjE2MjA0OVowIwYJKoZIhvcNAQkEMRYEFFIKOW0sze/Qekvg6TLU 6c42PNQkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAc05EI+vQCyAQ1CZfroX1IyHMSt/KMd8+fedU ixtgdGvnKCdlDHMAQI8/VZWXkDC0pgS9XnCIYN1jvpGmG4b86HK6xjAikWUMNeIuBrdvAXJ+ K3oUA0Xn3uqYYXeydEvg60orIDEz8nNYjcLz229pEdDBCJQdeZYvnyb3kRBNbMPt9l2z4B6j m6qxMVVO0E+s2CNlAuqUs9SVawagkqmXkHgulrnzObSD1EdxIlmuQHP0Y/Xs9NUk9wuQIOUy D9WV+aMLBMidvIl7EVWpf0JfHOJlRr5zoIjh2eAYt5VxYYYR/NXxI4D89zzJeONaTtAtrXX6 zVv0c+XL98o1J3HAVgAAAAAAAA== --------------ms040003080109060300040500-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 08:35:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7737B401 for ; Wed, 2 Apr 2003 08:35:39 -0800 (PST) Received: from yama.openaccess.org (ns1.openaccess.org [216.57.214.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD81E43FBF for ; Wed, 2 Apr 2003 08:35:38 -0800 (PST) (envelope-from michael@staff.openaccess.org) Received: from [192.168.1.2] (mfdAP.bcs.openaccess.org [216.57.214.35]) by yama.openaccess.org (8.12.3/8.11.6) with ESMTP id h32GG68a086911 for ; Wed, 2 Apr 2003 08:16:07 -0800 (PST) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 02 Apr 2003 08:35:38 -0800 From: Michael DeMan To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: IPSEC/IPFILTER, was options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 16:35:39 -0000 Hi, I'm going to jump in here too. We have an issue where we use IPSec tunneling to wireless clients. Currently we associate two IP on the external interface, the public one and then tunneled one. We are however forced to use NATD instead of IPFILTER for NAT because IPFILTER does its NAT work before IPSEC does its work which breaks the VPN. I looked in the some of the code and saw where IPFILTER is processed before NAT. I am wondering if it would be possible to swap the locations of the chunks of code and get the effect we want - IPSEC before IPFILTER. Is this as easy as it seems or will there be other troubles? I'm hoping somebody is familiar with this so I can avoid hours of trial and error. In the ideal world, I would like to be able to specify 'IPSEC before IPFILTER' either in my kernel config or, even better, in rc.conf - mike From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 10:54:03 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22F9F37B404 for ; Wed, 2 Apr 2003 10:54:03 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 961AF43F93 for ; Wed, 2 Apr 2003 10:54:01 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id A914E6C820; Wed, 2 Apr 2003 20:53:58 +0200 (CEST) Received: by notbsdems.interne.kisoft-services.com (Postfix, from userid 1001) id E68765AADA; Wed, 2 Apr 2003 20:53:46 +0200 (CEST) To: Lars Eggert From: Eric Masson In-Reply-To: <3E8B0DE1.1030500@isi.edu> (Lars Eggert's message of "Wed, 02 Apr 2003 08:20:49 -0800") References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> <3E8A1122.5040304@isi.edu> <86fzp0riwl.fsf@notbsdems.interne.kisoft-services.com> <3E8B0DE1.1030500@isi.edu> X-Operating-System: FreeBSD 4.8-RC i386 Date: Wed, 02 Apr 2003 20:53:46 +0200 Message-ID: <86brzorarp.fsf@notbsdems.interne.kisoft-services.com> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) XEmacs/21.4 (Common Lisp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Sam Leffler cc: Mailing List FreeBSD Network Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 18:54:03 -0000 >>>>> "Lars" == Lars Eggert writes: Hello Lars, Lars> what's a pix? A firewall appliance from cisco : http://www.cisco.com/warp/public/cc/pd/fw/ Lars> But chances are, you will need to control both endpoints for my Lars> suggestion to work. In this case, I don't even know if a pix can use transport mode and gre tunnels. I'll dig in the docs asap. Thanks for the detailled explanation. Regards Eric Masson -- CJ> Les censeurs agitent plus de vent que les moulins des Pays Bas. Tiens, je savais pas que c'étaient les moulins qui créaient le vent. -+- GR in GNU : Dame qui se shoote et sang chaud pensa -+- From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 11:53:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D70A37B401 for ; Wed, 2 Apr 2003 11:53:00 -0800 (PST) Received: from yama.openaccess.org (ns1.openaccess.org [216.57.214.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99CEB43FBD for ; Wed, 2 Apr 2003 11:52:59 -0800 (PST) (envelope-from michael@staff.openaccess.org) Received: from [192.168.1.2] (mfdAP.bcs.openaccess.org [216.57.214.35]) by yama.openaccess.org (8.12.3/8.11.6) with ESMTP id h32JXUr0089346 for ; Wed, 2 Apr 2003 11:33:30 -0800 (PST) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 02 Apr 2003 11:53:04 -0800 From: Michael DeMan To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Patch updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 19:53:00 -0000 Hi All, We have a couple of boxes overlooked for patches since mid-summer. We cvsup all our boxes. Is it possible to do a make buildworld / make installworld and restart appropriate services to pick up latest security patches? What could go wrong with this? Lots of things? Our cvsup is release specific, RELENG_4_6, RELENG_4_7, etc, so in theory things should run as-always, except sendmail and a few other goodies will have updated binaries? - mike Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 13:28:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01D2E37B401 for ; Wed, 2 Apr 2003 13:28:50 -0800 (PST) Received: from rigel.cs.pdx.edu (rigel.cs.pdx.edu [131.252.208.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2500C43FB1 for ; Wed, 2 Apr 2003 13:28:49 -0800 (PST) (envelope-from sashi@cs.pdx.edu) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [131.252.208.57]) by rigel.cs.pdx.edu (8.12.8/8.12.8) with ESMTP id h32LSmjw011784 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Apr 2003 13:28:48 -0800 (PST) Received: from sirius.cs.pdx.edu (sashi@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.12.8/8.12.8) with ESMTP id h32LSm2J025104 for ; Wed, 2 Apr 2003 13:28:48 -0800 (PST) Received: from localhost (sashi@localhost)h32LSllQ025101 for ; Wed, 2 Apr 2003 13:28:47 -0800 (PST) Date: Wed, 2 Apr 2003 13:28:47 -0800 (PST) From: Sashikiran Rachakonda To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Question Regarding IP Alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 21:28:50 -0000 Hi,i have a question regarding the IP Alias. If i bind my interface to 2 ip addresses say 1) ifconfig xl0 add w.x.y.z netmask 255.255.255.0 2) ifconfig xl0 add p.q.r.s netmask 255.255.0.0 Is there a way that i can force the packets coming-out of this interface to have ipSrc = p.q.r.s and not w.x.y.z. My question is is there a way that you can tell the interface to have the IPsrc set to the one we want to, for all packets coming out of this interface. Thanx in Advance, --Sashi. From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 14:55:20 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AFE637B401 for ; Wed, 2 Apr 2003 14:55:20 -0800 (PST) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F61743F85 for ; Wed, 2 Apr 2003 14:55:19 -0800 (PST) (envelope-from anthonyv@brainlink.com) Received: from [24.185.4.7] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 19000206 for net@freebsd.org; Wed, 02 Apr 2003 17:55:18 -0500 Message-ID: <3E8B6A51.6040305@brainlink.com> Date: Wed, 02 Apr 2003 17:55:13 -0500 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <86pto6mbxj.fsf@notbsdems.interne.kisoft-services.com> <05b901c2f881$67e907f0$52557f42@errno.com> <3E8A1122.5040304@isi.edu> <86fzp0riwl.fsf@notbsdems.interne.kisoft-services.com> <3E8B0DE1.1030500@isi.edu> <86brzorarp.fsf@notbsdems.interne.kisoft-services.com> In-Reply-To: <86brzorarp.fsf@notbsdems.interne.kisoft-services.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 22:55:20 -0000 Hey If you are interested, I've just connected to a PIX515 from a 4.7-STABLE machine in tunnel mode using racoon. In my setup I did not use a gif tunnel. There is a doc available here: http://klub.chip.pl/nolewajk/work/freebsd/FreeBSD-howto.htm. that explains the procedure, however it doesnt work exactly as it appears. I can send you my PIX/racoon configs if you want. Anthony Volodkin Eric Masson wrote: >>>>>>"Lars" == Lars Eggert writes: >>>>>> >>>>>> > >Hello Lars, > > Lars> what's a pix? > >A firewall appliance from cisco : >http://www.cisco.com/warp/public/cc/pd/fw/ > > Lars> But chances are, you will need to control both endpoints for my > Lars> suggestion to work. > >In this case, I don't even know if a pix can use transport mode and gre >tunnels. I'll dig in the docs asap. > > > >Thanks for the detailled explanation. > >Regards > >Eric Masson > > > From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 16:32:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85C0737B401; Wed, 2 Apr 2003 16:32:48 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71FBF43FA3; Wed, 2 Apr 2003 16:32:46 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id DAD303D28; Wed, 2 Apr 2003 19:32:45 -0500 (EST) From: "Dan Langille" To: "Matthew Emmerton" Date: Wed, 02 Apr 2003 19:32:45 -0500 MIME-Version: 1.0 Message-ID: <3E8B3ADD.22128.F838E40@localhost> Priority: normal In-reply-to: <00bc01c2f91b$f5bd1cc0$1200a8c0@gsicomp.on.ca> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: How do I specify a unit for ppp? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:32:48 -0000 On 2 Apr 2003 at 8:29, Matthew Emmerton wrote: > ----- Original Message ----- > From: "Dan Langille" > To: > Sent: Wednesday, April 02, 2003 8:12 AM > Subject: How do I specify a unit for ppp? > > > > >From man ppp I see this: > > > > The -unit flag tells ppp to only attempt to open /dev/tunN. > > > > I want it to use tun0. I can't see a way to specify a unit in > > /etc/rc.conf. > > > > Clues? > > We really need a ppp_flags variable in /etc/rc.conf which is recognized by > /etc/rc.network for this kind of thing. > Then you could specificy ppp_flags="-unit 0" in /etc/rc.conf and be on your > way. > > Patches against 4.7-REL (sorry, I don't have an up-to-date -stable box). > Comments requested; I will submit a PR with patches against -stable later > today. That patch works well for me. Thank you. -- Dan Langille : http://www.langille.org/ From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 21:51:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F7B937B401 for ; Wed, 2 Apr 2003 21:51:19 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B66343F93 for ; Wed, 2 Apr 2003 21:51:19 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id C0F0943C0C; Wed, 2 Apr 2003 21:51:17 -0800 (PST) From: Wes Peters Organization: Softweyr To: Michael DeMan , Date: Wed, 2 Apr 2003 21:51:17 -0800 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304022151.17249.wes@softweyr.com> Subject: Re: Patch updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 05:51:19 -0000 On Wednesday 02 April 2003 11:53, Michael DeMan wrote: > Hi All, > > We have a couple of boxes overlooked for patches since mid-summer. > > We cvsup all our boxes. > > Is it possible to do a make buildworld / make installworld and restart > appropriate services to pick up latest security patches? > > What could go wrong with this? Lots of things? > > Our cvsup is release specific, RELENG_4_6, RELENG_4_7, etc, so in > theory things should run as-always, except sendmail and a few other > goodies will have updated binaries? Watch the cvsup output to see what changed. Watch for system header file changes, those can be pretty far-reaching. If the kernel doesn't change, you're pretty safe with buildworld, installworld, and selectively restarting any long-lived daemons that changed. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 00:27:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB3937B401 for ; Thu, 3 Apr 2003 00:27:35 -0800 (PST) Received: from hubsch.org (as1-3-6.ars.s.bonet.se [194.236.5.112]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A7BD43F93 for ; Thu, 3 Apr 2003 00:27:34 -0800 (PST) (envelope-from micke@hubsch.org) Received: (qmail 13484 invoked by uid 204); 3 Apr 2003 08:27:31 -0000 Received: from unknown (HELO snaps.home) (172.16.1.3) by 0 with SMTP; 3 Apr 2003 08:27:31 -0000 Date: Thu, 3 Apr 2003 10:27:31 +0200 (CEST) From: Mikael Hubsch X-X-Sender: micke@snaps.home To: freebsd-net@freebsd.org In-Reply-To: <05b901c2f881$67e907f0$52557f42@errno.com> Message-ID: <20030403101114.H13386-100000@snaps.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: options FAST_IPSEC & tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 08:27:35 -0000 On Tue, 1 Apr 2003, Sam Leffler wrote: > Packets are tagged once they've been processed on input. I think you can do > a similar check with something like: > > if (m_tag_find(PACKET_TAG_IPSEC_IN_DONE) != NULL) > goto pass; > > Long term, I intend is to associate packets with an enc device so there's a > way to identify these packets when writing firewall rules. > If the packets are tagged wouldn't it be better to add an ipfw option instead of changing the interface? Then you could add a rule that both test on correct incoming interface and the fact that ipsec processing was done. For example, ipfw add pass esp from 10.1.1.0/24 to any in via fxp1 ipfw add deny all from any to any in via fxp1 not ipsecdone -- Mikael Hubsch From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 11:39:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C8A37B401 for ; Thu, 3 Apr 2003 11:39:29 -0800 (PST) Received: from smtp07.wxs.nl (smtp07.wxs.nl [195.121.6.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC57A43F3F for ; Thu, 3 Apr 2003 11:39:28 -0800 (PST) (envelope-from pblok@inter.NL.net) Received: from bsdpc (ip503cf841.speed.planet.nl [80.60.248.65]) 2002))freebsd-net@freebsd.org; Thu, 03 Apr 2003 21:39:27 +0200 (MEST) Date: Thu, 03 Apr 2003 21:39:23 +0200 From: "Peter J. Blok" To: freebsd-net@freebsd.org Message-id: <200304032139.23490.pblok@inter.NL.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5 Subject: FAST_IPSEC issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 19:39:30 -0000 Hi, So here is FAST_IPSEC user # 4, or is it 5 ;-) Initially I was not able to make FAST_IPSEC work. I had a working environment with normal IPSEC, but after I switched on FAST_IPSEC it didn't work anymore. The tcpdump looked ok, but now I realize I have missed a tiny detail. To make FAST_IPSEC work, you also have to allow proto ipencap to pass ipfilter. With the original IPSEC only proto esp was enough. Peter From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 12:55:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8A7037B401; Thu, 3 Apr 2003 12:55:40 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6EF43FBF; Thu, 3 Apr 2003 12:55:39 -0800 (PST) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h33KtcRp018050; Thu, 3 Apr 2003 22:55:38 +0200 Received: (nullmailer pid 3161 invoked by uid 1000); Thu, 03 Apr 2003 20:55:25 -0000 Date: Thu, 3 Apr 2003 22:55:25 +0200 From: Mark Santcroos To: Craig Boston Message-ID: <20030403205524.GA2346@laptop.6bone.nl> References: <1049304662.10796.27.camel@owen1492.uf.corelab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1049304662.10796.27.camel@owen1492.uf.corelab.com> User-Agent: Mutt/1.4.1i X-Handles: MS6-6BONE, MS18417-RIPE cc: net@freebsd.org Subject: Re: IPv6 MTU bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 20:55:41 -0000 [ moved to net@; current@ bcc'ed ] Hi Craig, I think I saw the same behaviour while developing a path-mtu discovery tool. As I'm quite busy right now I didn't really dig into it, but I will at some point. I took the liberty to reply to freebsd-net@, because this is not only a -CURRENT problem. Mark On Wed, Apr 02, 2003 at 11:31:02AM -0600, Craig Boston wrote: > I was trying some network diagnostics yesterday and needed to generate a > continuous stream of small packets going across a few routers. So I > used ifconfig to set my MTU to some very low values (100, 300, 500, and > a few others). I know there's probably a better way to accomplish that, > but couldn't think of any at the time so that's what I did :) > > Anyway, when I was done, I reset the MTU on my ethernet interface back > to 1500. IPv4 is working fine, but IPv6 is still acting like I have a > low MTU set. All IPv6 TCP connections are limiting the MSS to around 28 > bytes of data per packet, and ping6 complains with ping sizes more than > around 50. > > I think I've tracked down the problem to this code in nd6.c, > specifically in nd6_setmtu(ifp). > > Note that at this point ndi->maxmtu has just been set to > MIN([user-requested MTU], [biggest MTU possible for this interface > type]). ndi->linkmtu hasn't been touched yet and is still set to > whatever the previous linkmtu was. > > if (ndi->linkmtu == 0 || > ndi->maxmtu < ndi->linkmtu) { > ndi->linkmtu = ndi->maxmtu; > /* also adjust in6_maxmtu if necessary. */ > if (oldlinkmtu == 0) { > /* > * XXX: the case analysis is grotty, but > * it is not efficient to call in6_setmaxmtu() > * here when we are during the initialization > * procedure. > */ > if (in6_maxmtu < ndi->linkmtu) > in6_maxmtu = ndi->linkmtu; > } else > in6_setmaxmtu(); > } > > It looks to me that in the case of raising an interface's MTU, > ndi->maxmtu will be >= ndi->linkmtu, causing linkmtu to never get > reset. I may be missing something, but I can't quite figure out the > logical reason for that test. > > Luckily I had a kernel.debug lying around so I used gdb to peek into the > kernel memory. In the nd_ifinfo for that interface, linkmtu=100 and > maxmtu=1500. Once I manually reset linkmtu to 1500, IPv6 started > working properly again, without having to sacrifice my uptime :) > > Anyway, the behavior looks like a bug, but the code makes it look like > this may be an intentional effect. Any kernel networking gurus care to > comment? > > Thanks, > Craig > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 13:05:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5AF437B401 for ; Thu, 3 Apr 2003 13:05:31 -0800 (PST) Received: from chronozon.artofdns.com (CPE00e0293a847c-CM014400123697.cpe.net.cable.rogers.com [24.43.64.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3832843FAF for ; Thu, 3 Apr 2003 13:05:31 -0800 (PST) (envelope-from stef@chronozon.artofdns.com) Received: from testlin.hades (unknown [192.168.2.110]) by chronozon.artofdns.com (Postfix) with ESMTP id 908844C22D for ; Thu, 3 Apr 2003 11:12:36 -0500 (EST) From: Stef Telford To: freebsd-net@freebsd.org Content-Type: text/plain Organization: Message-Id: <1049490400.16435.26.camel@testlin.hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2-3mdk Date: 04 Apr 2003 16:06:41 -0500 Content-Transfer-Encoding: 7bit Subject: atmel drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 21:05:32 -0000 Hello there, First of all, apologies if this is the wrong mailing list (did think that maybe mobile or perhaps hardware was the 'right' one). If this is horribly out of the mailing list topic let me know. Anyway, guess the topic really says it all. I can find linux atmel drivers (http://atmelwlandriver.sourceforge.net/) so, is it not possible to take a snapshot from there and perhaps code up even alpha drivers ? There are more and more 'legacy' or old 11mbp's wireless 802.11b cards that are using this and even new versions of some prism based cards are 'becoming' atmel cards (the one i have that causes me the most 'irk' is the SMC 2632W v2. v1 was prism2, v2 is atmel. way to go SMC) and also 3com's (as someone on irc pointed out). It really would be great to buy another card and ditch this 'atmel' card, however, my poor funds dont normally allow that, and others are probably in the same boat. help me get away from 'lesser os's :) regards Stef Telford From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 18:22:13 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4CFB37B401 for ; Thu, 3 Apr 2003 18:22:13 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C0243F75 for ; Thu, 3 Apr 2003 18:22:12 -0800 (PST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fea7:b6e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8E96C15210; Fri, 4 Apr 2003 11:22:37 +0900 (JST) Date: Fri, 04 Apr 2003 11:22:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mark Santcroos In-Reply-To: <20030403205524.GA2346@laptop.6bone.nl> References: <1049304662.10796.27.camel@owen1492.uf.corelab.com> <20030403205524.GA2346@laptop.6bone.nl> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 cc: Craig Boston cc: net@freebsd.org Subject: Re: IPv6 MTU bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 02:22:13 -0000 >>>>> On Thu, 3 Apr 2003 22:55:25 +0200, >>>>> Mark Santcroos said: > Hi Craig, > I think I saw the same behaviour while developing a path-mtu discovery > tool. As I'm quite busy right now I didn't really dig into it, but I will > at some point. > I took the liberty to reply to freebsd-net@, because this is not only a > -CURRENT problem. Yes, this is a bug of the IPv6 code, and has been fixed in KAME snapshots. The fix should eventually be merged to the freebsd repository, but I'm not a committer and thus cannot tell when. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 01:13:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C643037B401 for ; Fri, 4 Apr 2003 01:13:15 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id D67B943F75 for ; Fri, 4 Apr 2003 01:13:14 -0800 (PST) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h349DDRp019234; Fri, 4 Apr 2003 11:13:13 +0200 Received: (nullmailer pid 9108 invoked by uid 1000); Fri, 04 Apr 2003 09:12:57 -0000 Date: Fri, 4 Apr 2003 11:12:57 +0200 From: Mark Santcroos To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20030404091257.GA9056@laptop.6bone.nl> References: <1049304662.10796.27.camel@owen1492.uf.corelab.com> <20030403205524.GA2346@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Handles: MS6-6BONE, MS18417-RIPE cc: Craig Boston cc: net@freebsd.org Subject: Re: IPv6 MTU bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 09:13:16 -0000 On Fri, Apr 04, 2003 at 11:22:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > Yes, this is a bug of the IPv6 code, and has been fixed in KAME > snapshots. The fix should eventually be merged to the freebsd > repository, but I'm not a committer and thus cannot tell when. Ah, I saw you're the person who actually fixed it ;-) The KAME snapshot of FreeBSD is quite old, do you know the "procedure" of when and why it get's updated? I might try to extract only the mtu stuff from the changes and apply that locally though. Thanks for the ACK. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 09:46:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id 1F94E37B404; Fri, 4 Apr 2003 09:46:29 -0800 (PST) Date: Fri, 4 Apr 2003 09:46:28 -0800 From: Prafulla Deuskar To: freebsd-net@freebsd.org Message-ID: <20030404094628.A59969@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD 4.8-RC on an i386 Subject: Disable/Enable Interrupts in ISR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 17:46:30 -0000 All, foo_intr() { ... disable_intr; ... process data; ... enable_intr; } Most of the network drivers currently do something like this in the ISR. Is this really necessary as by the time ISR is called interrupts have already been disabled on APIC and disabling interrupts on network card has no effect. Is there an issue on non-x86 architectures? Thanks, Prafulla From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 15:28:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9382037B401; Fri, 4 Apr 2003 15:28:10 -0800 (PST) Received: from mail01.stbernard.com (mail01.stbernard.com [64.154.93.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7B8043FBF; Fri, 4 Apr 2003 15:28:09 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com ([192.168.4.61]) by mail01.stbernard.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 15:28:09 -0800 From: Wes Peters Organization: Softweyr.com To: Stef Telford , freebsd-net@freebsd.org Date: Fri, 4 Apr 2003 15:28:09 -0800 User-Agent: KMail/1.5 References: <1049490400.16435.26.camel@testlin.hades> In-Reply-To: <1049490400.16435.26.camel@testlin.hades> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304041528.09231.wes@softweyr.com> X-OriginalArrivalTime: 04 Apr 2003 23:28:09.0443 (UTC) FILETIME=[DA37E330:01C2FB01] cc: imp@freebsd.org cc: freebsd-mobile@freebsd.org Subject: Re: atmel drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 23:28:11 -0000 On Friday 04 April 2003 13:06, Stef Telford wrote: > Hello there, > > First of all, apologies if this is the wrong mailing > list (did think that maybe mobile or perhaps hardware was the > 'right' one). If this is horribly out of the mailing list topic > let me know. It's off-topic for this mailing list, but quite understandable. The best place to bring it up is probably mobile; I've directed replies there. The best *person* to contact is most likely Warner Losh, who has written and/or coordinated much of the support for PCCards, CardBus, etc. in FreeBSD, so I cc'ed him too. > Anyway, guess the topic really says it all. I can find > linux atmel drivers (http://atmelwlandriver.sourceforge.net/) > so, is it not possible to take a snapshot from there and perhaps > code up even alpha drivers ? There are more and more 'legacy' > or old 11mbp's wireless 802.11b cards that are using this and > even new versions of some prism based cards are 'becoming' atmel > cards (the one i have that causes me the most 'irk' is the SMC > 2632W v2. v1 was prism2, v2 is atmel. way to go SMC) and also > 3com's (as someone on irc pointed out). > > It really would be great to buy another card and ditch > this 'atmel' card, however, my poor funds dont normally allow > that, and others are probably in the same boat. help me get > away from 'lesser os's :) Sounds like something we need. I've got a prism1 and prism2 card I could donate, but that won't solve the larger problem; I'd rather have support for the new chipset instead. Warner, let me know if I can help by sending a card or something. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 4 22:44:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BC5337B401; Fri, 4 Apr 2003 22:44:54 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F8D043F93; Fri, 4 Apr 2003 22:44:53 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA27354; Sat, 5 Apr 2003 16:44:50 +1000 Date: Sat, 5 Apr 2003 16:44:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Prafulla Deuskar In-Reply-To: <20030404094628.A59969@hub.freebsd.org> Message-ID: <20030405163141.T37137@gamplex.bde.org> References: <20030404094628.A59969@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Disable/Enable Interrupts in ISR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 06:44:54 -0000 On Fri, 4 Apr 2003, Prafulla Deuskar wrote: > All, > > foo_intr() > { > ... > disable_intr; > ... > process data; > ... > enable_intr; > } > > Most of the network drivers currently do something like this in the ISR. > Is this really necessary as by the time ISR is called interrupts have already been > disabled on APIC and disabling interrupts on network card has no effect. What sort of interrupt disabling? I suppose disabling at the device level might be useful (e.g., so that the interrupt handler can be returned from, with the actual interrupt handling mostly done in a lower priority thread), but most drivers shouldn't need or do this. Maybe it is needed for DEVICE_POLLING? > Is there an issue on non-x86 architectures? Not AFAIK. Not far, but SMP and FreeBSD's ithread implementation need something like an x86 ICU to work right. The interrupt mask must be global, and per-cpu ipls don't (naturally) work right even in the 1-cpu case since they are designed for masking interrupts in a nested way with the CPU determining the prioritization, but ithreads are non-nested and want their own prioritization. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 11:59:56 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BD9537B401; Sat, 5 Apr 2003 11:59:55 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2345443F85; Sat, 5 Apr 2003 11:59:55 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h35JxrMS029644 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 5 Apr 2003 14:59:53 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h35JxmD38616; Sat, 5 Apr 2003 14:59:48 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16015.13748.503036.374679@grasshopper.cs.duke.edu> Date: Sat, 5 Apr 2003 14:59:48 -0500 (EST) To: Bruce Evans In-Reply-To: <20030405163141.T37137@gamplex.bde.org> References: <20030404094628.A59969@hub.freebsd.org> <20030405163141.T37137@gamplex.bde.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Disable/Enable Interrupts in ISR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 19:59:56 -0000 Bruce Evans writes: > > Is there an issue on non-x86 architectures? > > Not AFAIK. Not far, but SMP and FreeBSD's ithread implementation need > something like an x86 ICU to work right. The interrupt mask must be > global, and per-cpu ipls don't (naturally) work right even in the 1-cpu > case since they are designed for masking interrupts in a nested way with > the CPU determining the prioritization, but ithreads are non-nested and > want their own prioritization. > > Bruce On 5.0 alpha, when an non-fast interrupt is dispatched, the device interrupt is disabled in the hardware. Eg, for PC like machines, interrupts are disabled/re-enabled each time an interrupt fires via isa_{en,dis}able_intr() in alpha/isa/isa.c. Other platforms have their own way of doing the same thing. In retrospect, this seems to be hideously expensive... In 4.x, there is no SMP on alpha and the IPL level is raised when a device interrupt handler is run, so that the handler can never be interrupted by the device itself. Drew