From owner-freebsd-net Sun Nov 19 4:46:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id 6F25337B4E5 for ; Sun, 19 Nov 2000 04:46:24 -0800 (PST) Received: (qmail 67998 invoked from network); 19 Nov 2000 12:46:07 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 19 Nov 2000 12:46:07 -0000 Received: (qmail 31351 invoked by uid 500); 19 Nov 2000 12:46:06 -0000 Date: Sun, 19 Nov 2000 20:46:06 +0800 From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: Does bridging work with all interfaces Message-ID: <20001119204606.A31317@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to bridge(4) , it only works for ``ed'', ``de'', ``ep'', ``fe'', ``fxp'', ``lnc'', ``mx'', ``tx'', and ``xl'' interfaces. However, according to cvs logs [rev 1.11 and rev 1.9.2.1 of if_dc.c] on May 14 and May 24th Archie Cobb wrote the following message --- Move code to handle BPF and bridging for incoming Ethernet packets out of the individual drivers and into the common routine ether_input(). Also, remove the (incomplete) hack for matching ethernet headers in the ip_fw code. The good news: net result of 1016 lines removed, and this should make bridging now work with *all* Ethernet drivers. The bad news: it's nearly impossible to test every driver, especially for bridging, and I was unable to get much testing help on the mailing lists. Reviewed by: freebsd-net --- Has anybody got bridging to work on the dc(4) interface. I am looking to build a traffic shapping bridge machine with a fxp interface on one side and a 4 port D-Link DFE-570TX card on the other side (to traffic shape upto 4 machines individually for 1 Mb/s outbound) Any suggestions on how to go about this would be appreciated ? Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 11: 6:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id CFF9437B479 for ; Sun, 19 Nov 2000 11:06:07 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4A00I2DD25JP@field.videotron.net> for freebsd-net@freebsd.org; Sun, 19 Nov 2000 14:06:05 -0500 (EST) Date: Sun, 19 Nov 2000 14:06:20 -0500 (EST) From: Bosko Milekic Subject: Re: M_RDONLY: review & comment In-reply-to: <200011121319.aa19357@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Sorry for this relatively late review; I was bogged down with a lot of studying this past week. On Sun, 12 Nov 2000, David Malone wrote: > This is an application of the M_WRITABLE macro I've been testing > at home (we're also testing a cruder version in RELENG_4 in college). > What this does is allows sbcompress to compress into external > storage if it is writable. OK. This sounds good, although I would only introduce it, at this point, to -CURRENT. We can wait for this release to go through before looking at a MFC. > This can be of great help if you have lots of small packets arriving > via an interface which always uses an mbuf cluster for every packet > (the fxp driver is one example I think). We were frequently running > out of clusters before using this patch. Exactly... this is great! > The limit of copying at most MCLBYTES/4 comes from BSDi, which seems > to have had a similar patch in place for some time. If Bosko or someone > can review this I'd like to commit it. I have a couple of mainly stylistic remarks... see below. > David. > [...] > + (m)->m_len <= MCLBYTES / 4 && > + (m)->m_len <= M_TRAILINGSPACE(n) && [...] Firstly, why is it necessary to place paranthesis around the mbuf pointer, m? Secondly, even though the (MCLBYTES / 4) is reasonable, I would put a small comment above that, just in case we end up changing the mbuf or cluster size in the distant future, so that people browsing the code will immediately guess that it may need to be changed. This is entirely up to you, so if you feel that it's not needed, feel free to leave as is. Other than that, this looks good. I'm building a kernel with it right now and will stress the machine a bit and get back to you within the next 1.5 hours... if nothing seriously evil occurs, feel free to commit at your convenience. Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 15:48:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id EA7B337B479 for ; Sun, 19 Nov 2000 15:48:34 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA46174; Sun, 19 Nov 2000 15:48:31 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eAJNmPc46113; Sun, 19 Nov 2000 15:48:25 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200011192348.eAJNmPc46113@curve.dellroad.org> Subject: Re: Question regarding 'pptpclient' In-Reply-To: <20001117.142416.63134192.mshindo@mshindo.net> "from Motonori Shindo at Nov 17, 2000 02:24:16 pm" To: Motonori Shindo Date: Sun, 19 Nov 2000 15:48:25 -0800 (PST) Cc: julian@elischer.org, freebsd-net@FreeBSD.ORG, KuriyaKK@cpf.navy.mil, josb@cncdsl.com X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Motonori Shindo writes: > Sorry for my ignorance, but can mpd act as a PAC? I had an impression > that mpd can work as a PNS but not as a PAC first time I looked at > mpd. If I understand your question correctly, it can only act as a PNS. That is, it doesn't do any "relaying" of incoming or outgoing calls between a modem and the network. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 15:59:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id B349B37B479 for ; Sun, 19 Nov 2000 15:59:54 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA46203; Sun, 19 Nov 2000 15:59:53 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eAJNxnZ46156; Sun, 19 Nov 2000 15:59:49 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200011192359.eAJNxnZ46156@curve.dellroad.org> Subject: Re: VPN over PPPoE (racoon at fault?) In-Reply-To: "from Mike at Nov 14, 2000 02:18:30 pm" To: Mike Date: Sun, 19 Nov 2000 15:59:49 -0800 (PST) Cc: Mike Tancsa , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike writes: > I had the same experience here as well. Racoon doesn't seem to like PPPoE > for some reason... Could it be the same MTU problem people are seeing with PPPoE/DSL ? Don't have the specifics but they're in the archives. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 17:47:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from fat.ti.ru (fat.ti.ru [212.1.224.35]) by hub.freebsd.org (Postfix) with ESMTP id 1562637B479 for ; Sun, 19 Nov 2000 17:47:38 -0800 (PST) Received: from martin (hilldale.kurgan.ru [212.1.224.61]) by fat.ti.ru (Postfix) with ESMTP id E532FD91A for ; Mon, 20 Nov 2000 04:47:32 +0300 (MSK) Date: Mon, 20 Nov 2000 04:47:33 +0300 From: Martin McFlySr X-Mailer: The Bat! (v1.47 Halloween Edition) Business Reply-To: Martin McFlySr Organization: Back To The Future X-Priority: 3 (Normal) Message-ID: <140210992581.20001120044733@McFlySr.Kurgan.Ru> To: net@FreeBSD.ORG Subject: question about mpd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello net@FreeBSD.ORG, Are this possible/right way? LAN 172.16.1.0/24. FreeBSD server with two interfaces(172.16.1.1 & 199.199.199.1 [real ip :)]) MPD installed for VPN/PPTP. I want reach situation, when each privateIP get "right" couple - realIP. are this way correct: ipfw: ipfw add allow tcp from 172.16.1.0/24 to 172.16.1.1 1723 ipfw add allow tcp from 172.16.1.1 1723 to 172.16.1.0/24 Pptp0: new -i ng0 Pptp0 Pptp0 set ipcp ranges 172.16.1.1/32 172.16.1.1.3/32 ipfw: ipfw add allow ip from 172.16.1.1 to 172.16.1.3 via ng0 ipfw add allow ip from 172.16.1.3 to 172.16.1.1 via ng0 ipfw add deny ip from 172.16.1.1 to any via ng0 Pptp1: new -i ng1 Pptp1 Pptp1 set ipcp ranges 172.16.1.1/32 172.16.1.1.4/32 ipfw: ipfw add allow ip from 172.16.1.1 to 172.16.1.3 via ng1 ipfw add allow ip from 172.16.1.3 to 172.16.1.1 via ng1 ipfw add deny ip from 172.16.1.1 to any via ng1 mpd.secret: user1 user1password 199.199.199.3 user2 user2password 199.199.199.4 user3 user3password 199.199.199.5 .... etc-etc? thank you, -- Monday, November 20, 2000, 04:39 Best regards from future, Martin McFlySr, HillDale. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 18: 9:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id 38C3137B479 for ; Sun, 19 Nov 2000 18:09:34 -0800 (PST) Received: (qmail 12091 invoked from network); 20 Nov 2000 02:09:32 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 20 Nov 2000 02:09:32 -0000 Received: (qmail 2072 invoked by uid 500); 20 Nov 2000 02:09:29 -0000 Date: 20 Nov 2000 02:09:29 -0000 Message-ID: <20001120020929.2071.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: State of bridging and dummynet in FreeBSD 4.x Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I received email from Luigi that whilst Archie's commits have enabled bridging on all interfaces, it has broken the combination of bridging and dummynet. I have never used dummynet before so don't know what broken means but I have rolled out 3 filtering bridges (bridging + ipfw) in the last two months on 4.1-stable and they have been rock solid I saw that a netgraph bridge node type was available but according to the man page, there is no support for IPFW filtering and consequently dummynet support. Don't know if there are plans to get this support in and subsequently use netgraph to build filtering bridges and traffic shaping bridges Does anybody have any idea about this regression of dummynet from 3.x to 4.x and are there any patches available for this ? Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 18:24:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 47D8637B4CF for ; Sun, 19 Nov 2000 18:24:42 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id VAA31063; Sun, 19 Nov 2000 21:25:44 -0500 (EST) Date: Sun, 19 Nov 2000 21:25:44 -0500 (EST) From: Alex Pilosov To: Yusuf Goolamabbas Cc: freebsd-net@FreeBSD.ORG Subject: Re: State of bridging and dummynet in FreeBSD 4.x In-Reply-To: <20001120020929.2071.qmail@yusufg.portal2.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Take a look at Vitaly Belekhov's work at www.riss-telecom.ru/~vitaly/, as far as traffic shaping, its really state-of-art. It has its own filtering implementation. As far as bridging, I don't know if his work (specifically ng_eiface) is bridging-enabled. On 20 Nov 2000, Yusuf Goolamabbas wrote: > I received email from Luigi that whilst Archie's commits have enabled > bridging on all interfaces, it has broken the combination of bridging > and dummynet. I have never used dummynet before so don't know what > broken means but I have rolled out 3 filtering bridges (bridging + > ipfw) in the last two months on 4.1-stable and they have been rock > solid > > I saw that a netgraph bridge node type was available but according to > the man page, there is no support for IPFW filtering and consequently > dummynet support. Don't know if there are plans to get this support in > and subsequently use netgraph to build filtering bridges and traffic > shaping bridges > > Does anybody have any idea about this regression of dummynet from 3.x > to 4.x and are there any patches available for this ? > > Regards, Yusuf > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 20:16:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by hub.freebsd.org (Postfix) with ESMTP id 19D5737B479 for ; Sun, 19 Nov 2000 20:16:35 -0800 (PST) Received: from localhost ([24.23.19.97]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001120041521.ZPTK16459.femail3.sdc1.sfba.home.com@localhost>; Sun, 19 Nov 2000 20:15:21 -0800 X-Sender: 1bcsc@home.com From: the stock shark.com <1bcsc@home.com> To: "ebay" <1bcsc@home.com> Date: Sun, 19 Nov 2000 23:23:33 -0500 Subject: (THESTOCKSHARK.COM) Reply-To: members@thestockshark.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20001120041521.ZPTK16459.femail3.sdc1.sfba.home.com@localhost> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you are interested in undervalued stocks and investment opportunities, then you may want to register for their FREE weekly email Stock Pick alerts or just check out the site. Registration is absolutely FREE and without any obligation whatsoever. http://www.thestockshark.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 21:16:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by hub.freebsd.org (Postfix) with ESMTP id 536B437B479 for ; Sun, 19 Nov 2000 21:16:33 -0800 (PST) Received: from johnny5 ([64.229.55.136]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001120051632.EGXB25760.tomts8-srv.bellnexxia.net@johnny5> for ; Mon, 20 Nov 2000 00:16:32 -0500 Message-ID: <000701c052b0$7d2c9790$0100000a@johnny5> Reply-To: "John Telford" From: "John Telford" To: Subject: How to restrict access to www sites through the firewall ? Date: Mon, 20 Nov 2000 00:12:33 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been asked if there is a way to restrict users to only certain groups of WWW sites when they are browsing. Are there any ports out there that would do this ? Be able to build a list of inside static IP's and what www they can go to ? Ease of use would be nice so that they can do it themselves, what do I look like the censor board I got better things to do than stop Jimmy the sales man browsing the Hun on a slow day. Thanks in advance, John. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 22:16:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from hetnet.nl (net090s.hetnet.nl [194.151.104.183]) by hub.freebsd.org (Postfix) with ESMTP id DBD6937B4C5 for ; Sun, 19 Nov 2000 22:16:15 -0800 (PST) Received: from pecan ([63.202.80.182]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 20 Nov 2000 07:15:59 +0100 Message-ID: <001101c052b9$189c55a0$b650ca3f@pecan> From: "Wilbert de Graaf" To: "John Telford" Cc: References: <000701c052b0$7d2c9790$0100000a@johnny5> Subject: Re: How to restrict access to www sites through the firewall ? Date: Sun, 19 Nov 2000 22:14:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John, I would use an http proxy to do that. Checkout squid: http://www.squid-cache.org/ It allows you to set access control per client host or subnet. - Wilbert ----- Original Message ----- From: John Telford To: Sent: Sunday, November 19, 2000 9:12 PM Subject: How to restrict access to www sites through the firewall ? > I've been asked if there is a way to restrict users to only certain groups > of WWW sites when they are browsing. > Are there any ports out there that would do this ? Be able to build a list > of inside static IP's and what www they can go to ? > > Ease of use would be nice so that they can do it themselves, what do I look > like the censor board I got better things to do than stop Jimmy the > sales man browsing the Hun on a slow day. > > Thanks in advance, John. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 19 22:16:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from hetnet.nl (net014s.hetnet.nl [194.151.104.154]) by hub.freebsd.org (Postfix) with ESMTP id 85B7C37B479 for ; Sun, 19 Nov 2000 22:16:13 -0800 (PST) Received: from pecan ([63.202.80.182]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 20 Nov 2000 07:16:11 +0100 Message-ID: <000a01c052b9$16f116a0$b650ca3f@pecan> From: "Wilbert de Graaf" To: "John Telford" Cc: References: <000701c052b0$7d2c9790$0100000a@johnny5> Subject: Re: How to restrict access to www sites through the firewall ? Date: Sun, 19 Nov 2000 22:14:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John, I would use an http proxy to do that. Checkout squid: http://www.squid-cache.org/ It allows you to set access control per client host or subnet. - Wilbert ----- Original Message ----- From: John Telford To: Sent: Sunday, November 19, 2000 9:12 PM Subject: How to restrict access to www sites through the firewall ? > I've been asked if there is a way to restrict users to only certain groups > of WWW sites when they are browsing. > Are there any ports out there that would do this ? Be able to build a list > of inside static IP's and what www they can go to ? > > Ease of use would be nice so that they can do it themselves, what do I look > like the censor board I got better things to do than stop Jimmy the > sales man browsing the Hun on a slow day. > > Thanks in advance, John. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 2:20:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 13C6937B479 for ; Mon, 20 Nov 2000 02:19:47 -0800 (PST) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id OAA01673; (8.9.3/vak/2.1) Mon, 20 Nov 2000 14:29:14 +0300 (MSK) Message-ID: <3A18FBF7.A10184B1@cronyx.ru> Date: Mon, 20 Nov 2000 13:24:55 +0300 From: Kurakin Roman Organization: Cronyx X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: gcorcoran@lucent.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Sync PPP code References: <39F57E2C.8B00509C@cronyx.ru> <3A15E00C.528FA874@lucent.com> Content-Type: multipart/mixed; boundary="------------259123396C7721AB69FB60C9" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------259123396C7721AB69FB60C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I didn't sent it to freebsd-net, I sent it to gnats bug report system: kern/21771: Fix for sppp and Cronyx drivers update In any way I attached sppp part of this patch. Kurakin Roman "Gary T. Corcoran" wrote: > > Kurakin Roman wrote: > > > > Any way if you are going to use if_sppp and don't want to use NETGRAPH, > > I can send some useful patches for sppp. > > Hi, > > I was searching through my email and I ran across your message from > October that was sent to freebsd-net. > I'm using the sync PPP code from FreeBSD in my DSL driver. I was > wondering if you would mind sending your patches for sppp to me? > I've already had to make some modifications myself, but I thought > perhaps you might have fixed some other problem(s) that I have not > yet run into. > > Thank you, > Gary Corcoran > -- > ========================================================= > Gary Corcoran - Distinguished Member of Technical Staff > Lucent Microelectronics - Client Access Broadband Systems > Communications Protocol & Driver Development Group > "We make the drivers that make communications work" > Email: gcorcoran@lucent.com > --------------------------------------------------------- > "No brain, no service." > ========================================================= --------------259123396C7721AB69FB60C9 Content-Type: application/x-gzip; name="spp.pch.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="spp.pch.gz" H4sICCOG3DkAA3NwcC5wY2gA7Dtrd9rIkp/x2R9RydzJgEEY8TLYcWYYwAk3GAjgPHbuHI4s CdBYSIokYns32d++Vd2tJwI7M3fPfFmfxIZWV3e9X93SjOUSpC1INyC5IE3Ac1XJdo3Viffg nVi6f2IsF57jOOU1PdodPZIk6QBQ7oOuQU9XodqGyulZrXVWa4DcbrePisVi9oq5K9uCseoD VHHmWb19Vm1BtVKpHP3yC0hy6RSK9OuXX47g5PgI4BjXXxqW7sHSdsF7sNS1a1v21oPJZHLS NTzVBtOwbsHUv+gmeNsb1976BFAm6CMJV+jazgPiv/Yh3y0QfnXo4iIP9zD0tfJRMXOKREgl 5hEyna2/tt0zmOnuSof3yu3W1K1buwQvvyi3v6hsdtndvmJ7E8AbXflimA/g6l+UjYPs8m1Q bQuJ2dDH6WUX5GZTLnPyK5VSExmAf1qMBTnPd7fILM9wVAfo13kud3IMg0l3Ao7iKhsPjk9i 8xTEDzYP9IfPZAN8ZgmMnzbg6LqbAbM2vANANKBbvqEqvs2gi7ntwkNO+LB0F5qpGhzwEkF0 mOqm8gC9YXcA1nZzo7slpLFclivVWgCrrhWXQD1f8bceB5687wL/XgJF9Y0vOqrO3Ymmm7qv c5RJJXLI1fla93RYbi2cZlseKC5+M0wT+WtYcPMApGwLxfcVdZ0v4HKWRnM4sH7v6KrPRXGj w9bDjwiCFIJp3yF3EHv8nUcUtTuEKoDmIjKux2VUqzEZ1RpCRt/Oj+AIftCYmqJWLt72+5PO cPC+D/hTua/I9Bfpw43gVtcdxcTVwHFt31Ztk3EkBt0dzLpjED8IXY1Bc3UPIQ3L83VFA3tJ xpBe6HKayyF8PSeA47I5sATkckwaBAp3CtnZYj64GrNncTw7w+FgRDu0aPqdzoRwoxvWClSF iSIFMer3e53r+RuEkSsE4+obGyXr6p+3ukcCiakZipXgtad6MDL8sprlc/iTg56MT8nN11u4 Qu7IMnqks1rzrFbjrmmPNxNg5ASZR6uD3CKwRj3u0VDp0aVVQ59GHmn2XX6suA/iJC7TA14Q 3u6qnbFxTH2D3BY2Y6PJczTIWEgZNrYW7N4ZzQYwl8tN+VRS7Y2jGDemznfcKJayYguhl1pZ uIu1YjDxDch3x3GlpYXjpS0l/8FJKugSP5MmKZqmayW0TcW69aBj6vcw3/rbG9qGLzC20Lva qGHM3zhouOhbLAu5QJta9t2hOCDhr2bg5PvWCjmmu7TvUwPDDsz/bZCALIxOS/BPG7eCD1vL U9ecXqYzJk3bv66rKyYKcanvIbV9mNRijNS3W1e5RTWa2qgPSKhrJAgtCkLnGGbAs5c++VXA z5qBUci42ZKS3BmogqMxfOhMp53RfNCflVB+PqBKW8w7k0YZusZWwgVcBV2FSAyu+tPuGwTq /DoYDuafgPRtMB/1ZzO4HE+hA5POdD7oXg87U5hcTyfjWb8csp8T4cGKVkT1R33C7VxSJo+i Cy5muyvFwhDJww0+2BieRz4K2YjOlS2D01CvjSWFkjiZ6ENNm3TZ4w82uuehyRD5t7rjc7qJ vgCixJZDHwoasvuLQqEQ7mz31gv3QDYAhSRCp0zKzRT80rU3Z/Cej0O1XC8B+bSO40KtAvLp Gf6rynA16zG9CeH+cenq+q+z3tl+L1f6AnK50S5Xy1Xm3E4qjRP0k3JT+En7xjVQTP17B/5B 6J+woGhYqrnVdHhJa7KEorx+xfxivUqpXr1ZwkXIMSanerZ6q/s0N/3gwTPtlXiwBB5ctPxi IShYLArw4gXEvsOrC6hhYMTZ0ahgHT2rY7aFvjq1D2qCZjNkiz/oJgq4GD3fYFKBuybnWCgU XCT4m1hsg6K01QxqNjfbZcAQuYq8qFJiUS/JFcaTKHoOLi8Xk85shklFjj5j5H3LQuidYviY qaEuot9/YKaABm7pahBAE0tg9B2H8LLI9GxJM9AP4HQMGc7WJygpDsUykhCsegAskQdNFpgh zOad+WA8mmE6sVyyvKJjmtLMF4aEYUrRVMXzydG7aBepnGGyuB6wLKbGYK8tnk+i8g+YF1N2 yCSYwYTBVKoyT5YxBLmo0DCJpVxSAmA2FhB8H/wOY4x4cYDEDh9HMwHQYAAfdde+ByRzL8Rg 8lFA3DCIkY0CMzGR/7gfZthlhKgBIUOKt13b8l2cHIci/anKTbKoarVaatZ58RCk6L6x0Svn qQH5nKWuIR+YlFHJum/788WwP8JcJkondx/Wj4pHxRMeZ2KBm0WFWB56OUXKIfqp3He7IqHF 8SgZ0SjtQ6/mpqEnnV5vMHodpsMVAT0aTgY91HxNo3iUApoNXo8wA+dglKEKoHfldq12wvOY KFs5sPts1JnEcG8ld/csxWEQIScwkKPLhqWprLwMVvT6CVaEuT1GQRWLDdAxYBs3hmn4D2nQ y353FAetC1C0gjsCxUCJFESJcxz21xRswI4bRb3NBg4JmoVMCqIWpWpZtF3NXi/6o3fXg+kn 2uS0ITbhFR3o1uet4e6QRVDkI65nDLVTLQnFcYnNFzughP+zn0so4ZXAD8VoanuxvBz2FtP5 p0m6NnN1hxkG5aEZIO/708HlJw5SEyAs+8VAspftBEg1bcD2UwEY1blZEMPZm8HlvEEQ7YCH GD1uSQbe2lj60EiKaBqhnkUxo3ZxeT0cEhZCCUhxtuh+stHgILM34+kcQI5Adim2KfnOhkbr G/ahGkF7SAEWDSnqiYz4GBNfecdwMLdH6xn25/2E9hMgZZGsRaBlQnW6c1aKx8xNQNmYxjEy FDMTctT/kLYYAWnpdwJ50UNRXGeBZSz8NzU3LPIsiA33tbAmyZxHdo/LBJ0Frm8X0JlO3kx7 WLH3h51PokWSWsXZXSX0nmKV/vxNnzN/MEktwtotiIqChcgeVIIAjDNWmI9eoOgy13B21wgR 2Vmjnk2M7cQW4GsgC06m9Gtg4e+gJ3CCdik0bJevnr111YgncWL4o3hSkcFRPkk+zyBEwB+C q55nylrBks/PxIk/egQnPikTJwF/CI5w4u0o0Tv9gP7QxuTzjtcXDqYcrKrGCl9VHMNH1/5f wpKXYZkJWPvoJapsNsqtzpOLVouaXrWGTDkqJRdkroYKX2xD4802lQr5hYcJcD5oLOIwHHtO CQyL+6cSL4SwEJCjj9XC+d7lDAszy931xAClz3C8IXiyxNQKS5eDwxPgA+jEg2CVNQ/qjy3D yVwq8fUS2ES9v/RS+yDQrezfNvA5x/irBEFqR+q1bzme8WSsmLTx4zUnBa2YVsoSjiMkg7UG 5u5iPRVXUyP8wuVZSxEyhJa1brYCBdQxY6CvDFGmUryalFusnGydirMDbgVH0n9QkBTGgLUp rkHdqKBvXAJqZrkGhSYsY1wiW3eXCpo+an+qIVwOylq2IVoCGkSjWgkK2FzO1f2ta1Ge/Y0U MocVZ95zpFfEfEoI4QVvyxZYmMillRTJZKoTLVTEhYqs6w2vqXyZTIDrYpk3asnDbnxbg/wm 5DotyicdE4tzm4Wi/cEmUEXxpt/p9aeUweNDTkebGNeo1QTjcliN7VRvZ0QekbOWXqmi/nh2 IeqzApPvCgWD7PuCCq5hVZGLU0/dPri4iIpJwYFsBoUzaFmaouk32xXfJYfFf344fo25wK/X r7lm5chRzoizV3N4TkxyFOoeUFeTNzTZ/s85vacoMBJcvU5/ueC+0S/vzvDVNeQt3157jNLA 8xYEMpgeKFvTPyPUQ9xJh/XfBr2PVK39TlQS0/qL8aQ/6vcKbG4urtxc0qK8ww/T8Xy8mPb/ WeJTc8WiYIlHZr2RXm0Wzq2/1twy2iMUoRpMfBFH8fwp3JJ2uOXqf1CrgBxxEGae8+UT04Rc gatqbGrI/+cvyfFcVO5/vAfVd03+ic1kH1/9y3qeEldn+nqWN5ZOITaOJIn4WIJI10rAhJKU CVOyJ4tBeroYpKeKQdonhmIRyZJeGcuFZbNH55GJaC4mP/Q1tDPc/4zpZqPGemLNSjNhi7z2 vroezgfdzmx+lhy/HoWj5Cd6tvUTeuK1rt4y/xVYK6+KKLBDnsX5Rv20wNxIhqk+yzbVZ/ut 9U+bqzjRCg02OHcQ5tps1VlT7LTRKlV5U4ysNWizPe5kKbPUNHacQAdNdLQQc6E4YYM+dCfQ kysugeb5qFjKAkO6YT5w18z5sOF2zQRq2RjQPPaQfbe3ftxz8yPHCeaxpHQr3cKawwRN8ZWA 6rhbv+RHFiVqjlBtVWbg5OuvFpNpH5W5l+HLS3C16I1H8w+dwZypYIAl8kBKCKXIsT3bkVRS UJF8LPSe+sZ2eWvRdxXL2xi+wDey6YQ9cyuIjMDWXdd2PR5wTivsjP+0FQYcZE9eMW90XFbb hoE3PD3i6anh/+SBYt4pD9RKsLerdSFkzeNhUHpCNHo8GEXOCTdMWF88399axk5Dk8EGpngB rBf3DaivjCszrsjM9E/b9YArQThKKSFh8oOxxFAEg1F/HviCzuWCvp5xFLIbno+E5McCMhN0 zNchHWuferj5eN3JZS8oA3aSzAnkvq0lBwRGnfKQmGaKmubfT8775g5Bwui9rUPZpFDqOtZF NSSvWqO/GfSNZjHiMKEKtCWzcSztwWwfsfAzUZsJsl+lf2bURMQiDmdBb5sTfePqyu35rqgm H+OCmnwMidnT0/5byCEkzoLOeyY9THDNGlPLeiPmjd5tdfRDQb+TnE9QFfCLJJhrYCkiTj1Q x8LHHJyOLB+o0GdXWAIPzl3Q4HLxjrXi0FF+ZlGziOuc7XmGOONgbzqeQP5F4E09S+PkbDBk 6foGvd5Bh9uq1EstJLHVLLXFSdsSKuRh4qy8SFxciZgkhdPQp30uI2aLjXJPKdAF1Krn0XPV ST2topcrhrsYyzLHPTmpkZiUsUdyws4mDeZKxVPTth0V61bhYMUoq7h3hzGt4yOMR+0KqUH7 tBbcu+Jum7jff3fdv+7nX0Qo8DqNR9kNae6IpPbiBTKDDCHP0gkL80yWhuHXAnz9Cns9FQ8/ ByD3Kz0mahWcEYFn5UE0Ka5OKYIY0wOSkjRxJxnBQAgUipMDEg/bMjMluo7QFqeXIrlKiI6C 8mHmsenOmvwLPp686czQOfXnH8bTt4f5mGLD3iXEvCfz9TBjA67lY8RGikzkFpL8jM1LWkXA Gs8x73HPgK+NCjK0KFdqYVmQs/Q7Tj8EJh+gFjsoDuX5TEzn2x+GpRPisHyPAKVHARnnBGTi 6QX8Tz6GFXwN9xEfOc9Fdv1E0EBZ49O/XoBAkfV+OAkB0s8u4opTEGlXu1ktVevE3HqzVG1F 7YAAfGVjbbzQ7DtL5NKP1Epha+BArUTKXhR1UOY01K2gfFKdcte0PT3PeoQ0xjKRGBK+uRST 4yN8Pu3CnvECx9x6a5agB82CNLOJkOn1aDQYvT4XcDFbi3E3g0db53s59DQGfS9/9qOclS9W gsJ1V5d2mMF2G2MZF232LZPgjE4X9xB7CWauJnfAicfQjEneE2zIxYci7B6hiV845nm5LFcr Qed0t3HKi/TgSl6yMkt0ReVaS6bLK0W53mxHjVGWK/J+zGw+nkz6vbNILcOeLxbdqiOSvhLM +9OrRaf7lvWB2AF9CSr4T9Amcjkpsfi0/24x6494MyQ2jsuIcUloiOv5C9XeUuL2W7ipod3/ LnwziRqTjAVdljNWW1doUJ7meqob2NfJcYwKuna40tmNZh3yrBGO/5OYFc551yET6eJfQy5I bxOr8/7XWYS9b2oCeyawOr81IjcqjVJzV1zd4ZgOctMMZVLMGI9okXjHXzkTRSDMqP0xp3tz FvJH6qi3ov9RDi4dH+4dRS2JHz1gDTw/XAzXYa0ITlH1lFMkNyINTNMOT2B15TyhpHHxpqQb sEP0JFmFiPO4A36U9mKS9uKfoz3RtI1aq8ykLGWji3Dw100u3ginYcfF+meZj6NIF/FXign0 0QJuED96MRFhucWuujVqp8F54h6D3avYoWZKT5MRze/3CudxbYjHye9dIhOpyC6eiJVwh38J reQamXgRP6fd9ym3e2DNyF9xiTWqVdbgkJtyXaT3XNuoMW9C/jhPp7nHhfy6KBdYvhs5qpWh FsJmEN1ho1M126HLR7zVq+k+ex8j9ARplQqmkwZButXIIzDL0UBkNyHzP7OcB+LFGz0OfdIa C3gGSB1H6sPSDZegK87u9X38GHwjYno4l8smGLl2IlmlspFgKJkyRPJhp04Jxok+h8lDfMQ9 IYRmUwjhFEuCoBseLZgdZTO1s5gVIoqsWY4ORmEnPTBIdmDHTnjHCXUL8YuYIQZivMhCKh6d 9+jmnpidHc+y9gi9wpOJge/18I9RH8fsG6VTXHZteqULRdcKXhvaF2az5Um314VfeQK6g9Fg PugMOTa7XuV7V3hExb7LdzJunFYxOyR2tKp1+sA1GSU2H0vsur8fiEZ0waMjvkSUFn7l/8PC nwsLh/LlMFwcyKP/VjrIfbKb+Vyj2jyPbbXlwL5SZsgrmqCmkf5tP7xE+rf9HF5ujnFq2J2k a7BDyzH2tKrs/pbcJnvjSTFZzmze63WH7PpUdruUD1Mksh2fusR5GV6+JBTQE88XV53Xg24h Po0FrDQss1cvPbpxt7GCBiOw4S74GEb4q/k1SS44Px0s+asz0f0c/CJee6B3YuhVBMm2JE3f KNSUpDY9fyORw3s+5qQsDliGT68tME0rgeHDRlcsDyf/hCth5o6gOE+1qdQVvGs2SzJ14NrN 09BZcf/Eqvp0Nyyf6m+J7hVPi4KGQ5DgD0aX4xKvlmKn4hRcuB8sga+wq78R5ZSwlIOcfy8Y nTYa1hZBy8Ex7U51UBD9OpY8hZ2h8GASHjklZkN7EMACWHFdulGPCZFXCE+Ks3H4lj6OoG5U +I5p0C7OuOfx7CIVrxhv012hRzpdRe4gIHEhjcu+Xa+wfka1Qh/EaxVhVDp24gEoYRRh3XvF DIK/thLPLJf0epe/dukou8TfvmQXV+megrg+G6sN6bTj1QU06d0m5zeZXXBpilpRSFo/z6wk FU0jqT3/Tdzh+R2eC9+bCgkB+p3Zp1EXiZiEJHTorfvwJgndvFMwXXdhozghRQkkv35NI3mA BkjSkNUJyKaB3UutYGFSlVFA9PpU0B6PgVTufzTvAcsGK0ilM/b7JoTC/qC3GNoqugjyIeIN ZQbrgf55i+OSFNYvPwuIk3QfMDiKQnqvOh/ZmVp3ND9uBD1SUeJAdo0jbhZlVTqZZ11S0BnM asxfT8JNU6bOx2KFUrpOYs9FFfRzQGVWJZSshdgI56nwJSml3CvflUmGxcVLT8JLWILc86PY lYKqXJFLMr3yJGPQrwZtBJfdz7pgKiaCP9uQxmMXYvjSS8UwwwZQ6FVeJftsNGnr6vH+tsBe imMPsbmQ/1ErgH6v6jp7f/l5dPcOf56zHg617yRX/yOSuHictfd5IuUKuzfh/bXueHTJrq/F ejdEMbqW7ZJDh369+DgHXu5jABxiQESWpZAiC0cTTsh4nm4DQwZZo87bfWTR8vy2rGjXfQuo i6lbsP0B+agYLv63vGtvbttG4n+7n4LJjHuSKSd6WXbsOBk3dq+eSx2d7XTa6XQ8ikVHuiqS IjqNfZPcZ799AViAIE2nvZvpXadtFBIElgtgX9j9EVSljaRVzkRaY6vzyGaXP1zP18e7ibfH U96QkicIYr9lz9U+gJHC4xRDCuVzJuZVVEKkkVCE5luJzqdthqF83GVbg76Y1tAq1LH/G/Y1 mtcErXJP+7q71X6C9nV30N5yxbs0E4jZ8kifZ0L3F98dnx0cHp6CM3V08omufP9T/MLhTydc 3kDeMWJ/sHlFVGJZWPJhyUHWxRIL/Mk+krBy0WbCp1RyrHGtzKopNPQ8XCoF4M36Nru+mIKv MB6vctqwX7+7xb/AD8SRoV8cNlYG/Ec0XTE7dTICUxuteZvqS7Y9eAlvRm9mt2KRLz6smLeD AeXYp93tgUq2V/t6PU9+xqSb0dsVbGfQHpKUKJJlvLi+zsYXoLvHsK7z6SobU5EE8ZWUFAcd f+7iGwv9ybNnSbe/J3d6wZ3OwNzpB3d2zI0tdYPl1OdY/E/yUzH+uOCYFGaXjX79C8zlbJrz CQFX4AwwOSXtPhnYzMmoOsCps/rg7y2SYXRSNHYzC6IGpgoG5K0LbPAO/P68m/fFdwf33ry9 wRYmJaa97S2b/mMUQCOf/jO7uG4uP45J6yAzGV3pUZ5dggRtqcbtmCBMTgklIHk3zS+z2Ww0 zxDBxVageMenve3tLQSKSXs78KPXUbQ8iBt34sPIebiyasvTH21qtC1A0XVJJjDjORWcy8xV 6wrBSKdrw1gYl8BtuAAlA6v3Vo637sgvl8P+GjkTwgkvu+epJPcgrNDRCSbInx8VeZF4JLgI h6+x3RmF95Z8UpdjbACW0hnIWc5PNv54cGqhTHo0taNHFrp+pLL2xTvVsKZSyanGWjWjrRfg jjXStTVP89c5FIlZ/5Sji3EVcJXmGTBqKjtPHZ8UTktixyXRFAsjKmNT+DQwujynwbS6uxyp VrJwUOXIliqngdvESRa5Xu0IM1YurOCKyihWY/J6frYfW9CSrdTv9nqtfpL2e73t1labRRWn DH6YzfyiuQ9zhDVrcpgPEQYWyT8+5Ne4QScGMOFzHMKhEoaqAAR1XY0EpVGgauM1leAuISJR LTCiO3GXuEj+d1SMfpWiCDXhUwtot+GVIvDFDY6P8vPTq/eUXLwxnb/Hy1hmieh54N+QfpGT eCwnYZMP6/5wHyowPWXdhWVJT5MOBRjTN6PxrtZ0Xq5wWGG4hhRgbHfyc/sXDO92Ye23b3pX 0NcnvNr5BU2bPl1tk9vFxA1Xi0sscXCzLcLSkDh/b9wPcipoGImBqgJIW5YKfJ4Uaq2Y4MoX 0P1Lop+gEqrqJeUQBm7ZaXaZgaQYm4KcqxXoa1PyRoxfH9dx2Vo0lU1XCvQG8zkNhYpfOKFe AghlKnLd4UaDKl03msD4tMtBY6/AAt8oNGSo7wyszevFClb08dAkaz0XMT9h45YLNvf4Chm1 hM9i1gFVeGJLV9tZh3/HwqpikRUBocCiWW93b+pxEIePctAGXZFwJkvXY1ZT+Hou5RowyQzd cj+aekWazBm6g6ixdEzQK3iwb/BjdAqgjswGNH4zKqPtDuL6QpzHMRcImaAr8ukTNBzIn9u/ 3IOkV5agTe+PeuRJC6ShRRS0ePwygkn+Yd5mZDPsNF3sRdrprXFwajkdbDWFJ+ElXIXSE6YM Y/0J2vyLK6sEpM6+aXovcC3GNjUm9QfvtI4oo9dZrjhXg3VrUXEY8I6ZZwUqwwaANA1egfgI LwhKQro3En8nwYXRMRMTSlslbnmoCZdfdNo620PviePhrp5PLcH2VAd973knKU+zdwuwvUvL Nl1V+8SgFDgJQYMWRUSkKjfFatxdfWtqSme8B6bvsWFerYl0WZ4wQr820ZBfTrLxPLue5quk AQ2Pz065aA7XNWnLr6dLWEyr9x5jpBgnVRVYkRF+rBjix2CMmzsHOTkzY7Rvdjq97V1V4XWE 8IgwxsXxsf2dEKoSXOAdFiODCsscFfP8biKOzg/OD17+zam84K0Pzktfmh70BgRzDwfs7BU1 aDi+MitKXO/XQ6o40VXdsnhfUPU1GXqyXHM66J6BLdxoGmtIlXvNrXB5bKrPgM+rqxkYw8JO qQOjthLlnd1QjUhR+ZUlj9pyuvfeEE4eRfxU/Xa09YEQxODCCiKgxUBWOGq0U2EiWxHDQKp8 xQpiFwTMf7Bc8LI0knPQaQ62J4nOFjVEPwFPTwWkU94qTzZRfFM7qXHvP2k3H/nG/u8CeBGD XUpxS30AY9gz4g0KKGUxcx04o/HgaX6IjOuJOZGSDR4R9Z2UxjaT58CTXRHAfm04exJeRbhZ yFy37gL/6VqZw8LkfjulQ+osoAqVhmdmU7SU3IOrS+qVjne9FqBk+qBkOnzbt0aV7HZlzvex 716AA7nAwPJ8PHOoT8K1usa7LvOPC3liWUTMm+prRhlto6B8sRrlE1iIizmu/rcCg2xiSbyn cZfQefOZOHkxGMA3SNr0aleadprgItsuKcwid7pNs1/AVWvLRpB7vVGTt5vFW8yT14fDZLEy Dd40k/MXQ8YlaMwX9rQfhs+b3IhoZsdNnFnYJfDfvt0406WxMCbWUpFb15dLMGCSDfhTPcBX 8SFJg4XuUugGj00uJjNZiFYK8/XF1RUstX8dDy8OvyWwV7lO+QX06hxSpPit3FtSvGfIKB/4 5lxxg01iLZAV0PEDJHDz2fWEBT/Le17cn/YZz9GYRFZvFBwrs3beVepxqaTG9hE0tx/rKWou LVd9sOaup2BtFwfD4csjvBan5uA82h8pB/fu4hPxbu/LRfSG+MqWPa4kt8T+3ra/A9PflIA3 kB5aWYqtWudQrcUyW00X4ylmcWjdU8QvlCLvPPltOmJXvy3hJ0awz6D1LaqVPIMdMc5RCJFQ SsDlRR16lZz3nnQIUHWFu4qbstZJjujpwSZ+ksFhPo886EVxEqh9sfMT7FxOevHZQajP6gKM FZRVAfFrY6niVKLxeP99/1eY/cNTUhFOrcDv84tDWDwl+gWvat9ldfkbNOLZrVA8aygfSIVu LNOU2pec3iDaDc4Y1uqScJIHOuphF/CQCxocdi/ojb3v/eT1yTF9wcAKQYZ6rEMQPbbKrrJV Nr/MHA6iT6GPlupjKWqYVVShRfRUrx+FGOr3E4cMDZ6kHR2yQUOhMmyQz93yt9dP2lfv+IfR Unq/Lplhjh4FOrp3F9ooJ/5GHkeDei8p4JvOKc3D8CAg5dl+0t3asofgGhsg5BfDwO75b12k s4R13QrWFTvh50M0TulKnzCE84c4djlKFVyBHDL2nlVHEQUUzhki16xMPDTWS7Cr2UClK/xz CWb4xEZ8rcUWGGx0gDJ7NxWLqIVD7a+PW8mKf1iLrcpga7DYaCb6tAUfCm/IqYuZe+d5eRgI xgcrg9womoV8dibPiFeUxIAVKh3JV4xQy9ZFY8MOiigjTXP4l1pOLNjDSfcjoGS9QBnqKJhW hMdzBMD3I2MVeqU+DOVX7rtAk2l+YbBPL8QkL6ihgrpZK/a6nN0W3CszyLvbwhh8m8BFkQRJ U6E0E2jt/urWgwm9w3ibzwitl7AdfFBeiwYRb9wZEFQHA3In34xuT7Jr/mIDnp8Bs3kLhh0s bQeFGH/dqDvOoeHB4xASGKH3HuP/arlA3KD4gq0IzbFzJEqzpMdGEk/tIlP4KXOp/we8XQFn eH38uKabxw0clS1FXuydAlhIarxYNu/roer3WSxlZur5peHIPpHWcD8dvhqCG/rD6dHw5U+7 7F8mx2/ni5WJQlU+BMLrjGNpkT3lIvKyKghtmCnxN1nQ0mAsN9H/7wwSxjmItOiKgL2t6Euw kSv6EhRkrwbRLc1SbYRlH0oUtgT+GYEr2/0bWFmPzL8tQWGO3Kqlsjwu8ihNo7O0RY5ej89X yker3xbkUe22OyVNA/FJbSKLo2QcfyoryS80Lae+0LSMeK+hOSAIcxcTk7zoqQmpebdOjdeT 2kfacDJ5FfRVJQNZXssK4oUHj/wHl92fc9a4ScyO+JNsGRdIPTNBX9/yglkX2fzH+NgFa9w7 z2Rbqvmljjmv6/2KQ0XpgMPDsXmTDFkbII61iQWI/wuBJY37iEfJ/C70zmIG4U63jT3j0LFH rCOvaQCP6Toli4hadnUH7nJfXQajgf/RJCiN7/Usny9wbSMCwCNa1LQDICiIz6Bpt6ypSY9W vOPvFjhiop6Bx0JW9G6I4rYK2nZL21p6/q+dP05rC/O0kgaHPCVcea5hd/G0Qp0WqLy/5GA+ z26SwyqP8Qu+NFB2nLY0x2n0lVk7j36eEie29Gzajf3+E13ndJz2vRwPxyuFdXyHrY5TFWbe udEkfcSN1+7ePGwBD9JUsiw+TqazLGlsbvJRRjvMytksPmLv2XKrz3G/jEVjGHtULCGFsR9+ Y0mdpYDM7lIXkbiLSylXATT+Pl4jpNSvhbLoL/WLoqre8IF9Q/6qVK05fz3/dY4Jz27OJQq7 e888sa147hrbAMMRKn4T36XwnkmUxJhBY7k/SQd7yfLpJKUv7JgsSa/YOI18hqAig6v4ZhxW 9L3PyrfaMMnZ1p+yST4q+LwbXieNxzQW/NCSrji66t6LioQxiFA786q4eSmkeusHU3WkoPrd ly4lStFss61scBHjniCP9oIpMWRH3E2MfbJBtTKhT/6z1pzgYPj/nqWO+cUCMLY/Q36hDzqa 0el40/Ei9uRe8A6urvNzxVwOf3gRTOTTpHfveVTfBftj585kPFPRF6Um6IxnYiTYDT2V8bxm jqF1djH3rtMc9o2aWnMVBfYz5zg5WDIW36uSaZzA3/Kae5NSxw0LUc19HX4s7XnyUD6O9jDZ jbeUD6RBS0ashobJQ8HWeFjSO34a7TmV1Wcfqb1ZE/778uuG4sOmpm4sicE7oujSlHS9K41Y wqIhYZh2DGiAyG+0gLpg83CRd2oB2muIxKKM+HKRWEhgJSCJfwNMT30OdoEAAA== --------------259123396C7721AB69FB60C9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 3:38:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 315D537B4C5 for ; Mon, 20 Nov 2000 03:38:41 -0800 (PST) Received: (qmail 12018 invoked by uid 0); 20 Nov 2000 11:38:39 -0000 Received: from p3e9bc270.dip.t-dialin.net (HELO forge.local) (62.155.194.112) by mail.gmx.net (mail04) with SMTP; 20 Nov 2000 11:38:39 -0000 Received: from thomas by forge.local with local (Exim 3.12 #1 (Debian)) id 13xm2l-0000Dh-00 for ; Mon, 20 Nov 2000 09:11:15 +0100 Date: Mon, 20 Nov 2000 09:11:15 +0100 To: freebsd-net@freebsd.org Subject: Re: State of bridging and dummynet in FreeBSD 4.x Message-ID: <20001120091115.A821@crow.dom2ip.de> Mail-Followup-To: tmoestl@gmx.net, freebsd-net@freebsd.org References: <20001120020929.2071.qmail@yusufg.portal2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001120020929.2071.qmail@yusufg.portal2.com>; from yusufg@outblaze.com on Mon, Nov 20, 2000 at 02:09:29AM -0000 From: Thomas Moestl Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 20, 2000 at 02:09:29AM -0000, Yusuf Goolamabbas wrote: > I received email from Luigi that whilst Archie's commits have enabled > bridging on all interfaces, it has broken the combination of bridging > and dummynet. I have never used dummynet before so don't know what > broken means but I have rolled out 3 filtering bridges (bridging + > ipfw) in the last two months on 4.1-stable and they have been rock > solid > [...] > Does anybody have any idea about this regression of dummynet from 3.x > to 4.x and are there any patches available for this ? There is a patch that should fix the combination of dummynet and bridging. It still is not tested, though, and therefore it might cause problems. I can sent it over to you if you have interest in it. - Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 4:32:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.iastate.edu (mailhub.iastate.edu [129.186.1.102]) by hub.freebsd.org (Postfix) with ESMTP id E4B9D37B479 for ; Mon, 20 Nov 2000 04:32:10 -0800 (PST) Received: from iastate.edu (hx7570bc.aeem.iastate.edu [129.186.192.238]) by mailhub.iastate.edu (8.9.3/8.9.3) with ESMTP id GAA26977 for ; Mon, 20 Nov 2000 06:32:10 -0600 Message-ID: <3A1919CA.BB7878AF@iastate.edu> Date: Mon, 20 Nov 2000 06:32:10 -0600 From: Chris X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: bridging question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was hoping someone could shed some light on the workings of the bridge code. In particular, how it decides which interfaces to use, and how it can be configured. I would like to have bridging on fxp0, and tap0, but not fxp1. As I understand it, you need to do a "sysctl -w net.link.ether.bridge_refresh=1" so that the bridge code will pick up the tap interface. Unfortunately, I am not able to remove fxp1 from the bridging config. I tried something like sysctl -w net.link.ether.bridge_refresh=1 sysctl -w net.link.ether.bridge_cfg=fxp0:1,tap0:1, sysctl -w net.link.ether.bridge=1 However, this does not appear to work. Any suggestions on how to make this happen? Also, what are the defineable flags? Thanks, Chris Csanady To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 5: 6: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id C6B8737B479 for ; Mon, 20 Nov 2000 05:05:57 -0800 (PST) Received: from victoria-203.budapest.interware.hu ([195.70.63.203] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13xqdw-0002yk-00; Mon, 20 Nov 2000 14:05:56 +0100 Message-ID: <3A1921B0.A1333928@elischer.org> Date: Mon, 20 Nov 2000 05:05:52 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Chris Cc: freebsd-net@freebsd.org Subject: Re: bridging question References: <3A1919CA.BB7878AF@iastate.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris wrote: > > Hi, I was hoping someone could shed some light on the workings of the > bridge code. In particular, how it decides which interfaces to use, > and how it can be configured. > > I would like to have bridging on fxp0, and tap0, but not fxp1. As I > understand it, you need to do a "sysctl -w > net.link.ether.bridge_refresh=1" > so that the bridge code will pick up the tap interface. Unfortunately, > I > am not able to remove fxp1 from the bridging config. I tried something > like > > sysctl -w net.link.ether.bridge_refresh=1 > sysctl -w net.link.ether.bridge_cfg=fxp0:1,tap0:1, > sysctl -w net.link.ether.bridge=1 If you use the Netgraph bridging, you can directl select which interfaces are bridged by whether or not you hook them into the bridge node. > > However, this does not appear to work. Any suggestions on how to make > this > happen? Also, what are the defineable flags? > > Thanks, > Chris Csanady > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 7: 8: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 17F0837B479 for ; Mon, 20 Nov 2000 07:07:57 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id IAA29761; Mon, 20 Nov 2000 08:07:49 -0700 (MST) Date: Mon, 20 Nov 2000 08:07:49 -0700 (MST) From: Nick Rogness To: John Telford Cc: net@freebsd.org Subject: Re: How to restrict access to www sites through the firewall ? In-Reply-To: <000701c052b0$7d2c9790$0100000a@johnny5> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Nov 2000, John Telford wrote: > I've been asked if there is a way to restrict users to only certain groups > of WWW sites when they are browsing. > Are there any ports out there that would do this ? Be able to build a list > of inside static IP's and what www they can go to ? > > Ease of use would be nice so that they can do it themselves, what do I look > like the censor board I got better things to do than stop Jimmy the > sales man browsing the Hun on a slow day. If you are using Apache, it has this capability built into it see docs at: http://www.apache.org Using and `allow from' might be what you are looking for. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 7:44:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3666537B479 for ; Mon, 20 Nov 2000 07:44:12 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13xt8y-0000O8-00; Mon, 20 Nov 2000 08:46:08 -0700 Message-ID: <3A194740.41067E12@softweyr.com> Date: Mon, 20 Nov 2000 08:46:08 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Telford Cc: net@freebsd.org Subject: Re: How to restrict access to www sites through the firewall ? References: <000701c052b0$7d2c9790$0100000a@johnny5> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Telford wrote: > > I've been asked if there is a way to restrict users to only certain groups > of WWW sites when they are browsing. > Are there any ports out there that would do this ? Be able to build a list > of inside static IP's and what www they can go to ? > > Ease of use would be nice so that they can do it themselves, what do I look > like the censor board I got better things to do than stop Jimmy the > sales man browsing the Hun on a slow day. > > Thanks in advance, John. Transproxy will do this admirably, and you don't need to configure a proxy server on the clients. /usr/ports/www/transproxy -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 10:28:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.26]) by hub.freebsd.org (Postfix) with ESMTP id 54F7337B479; Mon, 20 Nov 2000 10:28:52 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id MAA05973; Mon, 20 Nov 2000 12:30:16 -0600 Message-ID: <3A196E28.3A9806A1@twopoint.com> Date: Mon, 20 Nov 2000 12:32:08 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , "freebsd-questions@FreeBSD.ORG" Subject: dual homed gateway system running ipfw and nat. need rules help. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I am running a dual homed system (2 nics) acting as a gateway/firewall for our office T1. The private net uses 192.x.x.x and the public uses a 'real' address of 209.x.x.x. The firewall is up and seems to be working well. I used rc.firewall "simple" and have customized it to our needs. All outgoing requests appear to to originating from the public interface. I want to be able to do two things that I have not been able to figure out yet. 1) We keep out pop server on the private net. I need to be able to get the incoming mail passed to the mail server that has a 192.x.x.x address. I was thinking something like: ${fwcmd} pass tcp from any 25 to 192.x.x.x Is this solid or am I opening myself up from more problems. I don't want to relay from outside as mail is only checked from inside the private side. 2) We want to be able to use the gateway/firewall as a PPTP server. After asking a few questions I decided to go with mpd. I have installed this and that seems ok. But I also need a rule to allow the incoming connection from the public net. All connections will be coming from home users running win9x who have static 'real' ip address. Also as i have never used mpd or set up a vpn any suggestions on this set up would be wonderfully helpful. Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 10:46:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 38A0637B479 for ; Mon, 20 Nov 2000 10:46:33 -0800 (PST) Received: from wkst ([10.10.1.70]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id NAA28613; Mon, 20 Nov 2000 13:46:51 -0500 Reply-To: From: "Peter Brezny" To: "'Hamilton Hoover'" Cc: Subject: RE: dual homed gateway system running ipfw and nat. need rules help. Date: Mon, 20 Nov 2000 13:46:08 -0800 Message-ID: <001001c0533b$4b164360$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3A196E28.3A9806A1@twopoint.com> Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hamilton, You sound like you are on the right track with your firewall line, and yes, it does open up that port...You might consider stateful rules to tighten things up a bit (man ipfw). For mpd, you'll need something like this in your ruleset to get it going. # Allow connections on pptp. $fwcmd add pass tcp from any 1723 to any 1024-65535 out xmit $oif $fwcmd add pass tcp from any 1024-65535 to any 1723 in recv $oif $fwcmd add pass 47 from any to any out xmit $oif $fwcmd add pass 47 from any to any in recv $oif the mpd-netgraph port is very well documented (just install the port and have a look in these directories: /usr/ports/net/mpd-netgraph/work/mpd-3.0/doc/mpd.html and /usr/ports/net/mpd-netgraph/work/mpd-3.0/README Hope this helps! Peter Brezny SysAdmin Services Inc. -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Hamilton Hoover Sent: Monday, November 20, 2000 10:32 AM To: freebsd-net@freebsd.org; freebsd-questions@FreeBSD.ORG Subject: dual homed gateway system running ipfw and nat. need rules help. Hi all, I am running a dual homed system (2 nics) acting as a gateway/firewall for our office T1. The private net uses 192.x.x.x and the public uses a 'real' address of 209.x.x.x. The firewall is up and seems to be working well. I used rc.firewall "simple" and have customized it to our needs. All outgoing requests appear to to originating from the public interface. I want to be able to do two things that I have not been able to figure out yet. 1) We keep out pop server on the private net. I need to be able to get the incoming mail passed to the mail server that has a 192.x.x.x address. I was thinking something like: ${fwcmd} pass tcp from any 25 to 192.x.x.x Is this solid or am I opening myself up from more problems. I don't want to relay from outside as mail is only checked from inside the private side. 2) We want to be able to use the gateway/firewall as a PPTP server. After asking a few questions I decided to go with mpd. I have installed this and that seems ok. But I also need a rule to allow the incoming connection from the public net. All connections will be coming from home users running win9x who have static 'real' ip address. Also as i have never used mpd or set up a vpn any suggestions on this set up would be wonderfully helpful. Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 10:56:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from alijku04.edvz.uni-linz.ac.at (alijku04.edvz.uni-linz.ac.at [140.78.182.1]) by hub.freebsd.org (Postfix) with ESMTP id E920E37B479 for ; Mon, 20 Nov 2000 10:56:32 -0800 (PST) Received: from sondermuell.oeh.uni-linz.ac.at (root@sondermuell.oeh.uni-linz.ac.at [140.78.214.105]) by alijku04.edvz.uni-linz.ac.at (8.8.8/8.8.8) with ESMTP id TAA22088 for ; Mon, 20 Nov 2000 19:56:31 +0100 Received: from atommuell.oeh.uni-linz.ac.at (root@atommuell.oeh.uni-linz.ac.at [140.78.214.101]) by sondermuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id UAA29932 for ; Mon, 20 Nov 2000 20:02:22 +0100 Received: from localhost (ferdl@localhost) by atommuell.oeh.uni-linz.ac.at (8.9.3/8.9.3) with ESMTP id TAA69774 for ; Mon, 20 Nov 2000 19:56:36 +0100 (CET) (envelope-from ferdl@atommuell.oeh.uni-linz.ac.at) Date: Mon, 20 Nov 2000 19:56:36 +0100 (CET) From: Ferdinand Goldmann To: freebsd-net@freebsd.org Subject: VLAN support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello everybody. I am searching desperately for a working VLAN patch for the fxp driver for FreeBSD 4.x-STABLE or -CURRENT, but there seems not much to be going on regarding this subject. The most relevant posting I found in the mailing list archives was this: Date: Thu, 19 Oct 2000 23:11:35 +0900 From: MIHIRA Sanpei Yoshiro To: freebsd-net@FreeBSD.ORG Subject: [Patch] VLAN MTU1500 patch for FreeBSD 4.1-RELEASE and later Message-ID: <200010191411.e9JEBZ817011@lavender.sanpei.org> Unfortunately, this patch did not apply anymore to my 4.1.1-STABLE system. Does noone on this mailing list need VLAN support for FreeBSD? I also tried to contact Pedro J. Lobo (without success), who posted a similar patch. I am interested if there is ANYBODY working on the subject, or if I should better try to apply the patch by hand? I just grabbed the kernel source code of 4.2-RC1 but there do not seem to be any changes to the fxp driver in this direction. Regards, Ferdinand Goldmann To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 10:59:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id A634C37B4C5; Mon, 20 Nov 2000 10:59:13 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id LAA75255; Mon, 20 Nov 2000 11:59:00 -0700 (MST) Date: Mon, 20 Nov 2000 11:59:00 -0700 (MST) From: Nick Rogness To: Hamilton Hoover Cc: "freebsd-net@freebsd.org" , "freebsd-questions@FreeBSD.ORG" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. In-Reply-To: <3A196E28.3A9806A1@twopoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Nov 2000, Hamilton Hoover wrote: > Hi all, Hello. > > I am running a dual homed system (2 nics) acting as a gateway/firewall > for our office T1. The private net uses 192.x.x.x and the public uses a > 'real' address of 209.x.x.x. The firewall is up and seems to be working > well. I used rc.firewall "simple" and have customized it to our needs. > All outgoing requests appear to to originating from the public > interface. I want to be able to do two things that I have not been able > to figure out yet. > > 1) We keep out pop server on the private net. I need to be able to get > the incoming mail passed to the mail server that has a 192.x.x.x > address. I was thinking something like: > Incoming from the outside or inside? > ${fwcmd} pass tcp from any 25 to 192.x.x.x > The POP server runs on port 110 not 25, that's SMTP. > Is this solid or am I opening myself up from more problems. I don't want > to relay from outside as mail is only checked from inside the private > side. > If you don't want mail from the outside world or users to send mail to the outside world, then this should work. Is the BSD machine acting as a mail server? Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 11:44:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.26]) by hub.freebsd.org (Postfix) with ESMTP id 274EC37B479; Mon, 20 Nov 2000 11:44:12 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id NAA06193; Mon, 20 Nov 2000 13:44:55 -0600 Message-ID: <3A197FA5.95299923@twopoint.com> Date: Mon, 20 Nov 2000 13:46:45 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nick Rogness Cc: "freebsd-net@freebsd.org" , "freebsd-questions@FreeBSD.ORG" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>I am running a dual homed system (2 nics) acting as a >>gateway/firewall for our office T1. The private net uses >>192.x.x.x and the public uses a 'real' address of 209.x.x.x. >>The firewall is up and seems to be working well. I used >>rc.firewall "simple" and have customized it to our needs. All >>outgoing requests appear to to originating from the public >>interface. I want to be able to do two things that I have not >>been able to figure out yet. >>1) We keep out pop server on the private net. I need to be >>able to get the incoming mail passed to the mail server that >>has a 192.x.x.x address. I was thinking something like: > Incoming from the outside or inside? Incoming from the public net. >>${fwcmd} pass tcp from any 25 to 192.x.x.x > The POP server runs on port 110 not 25, that's SMTP. ok. then I change that from 25 to 110? I run qmail on a linux box on my private net. >>Is this solid or am I opening myself up from more problems. I >>don't want to relay from outside as mail is only checked from >>inside the private side. >If you don't want mail from the outside world or users to send >mail to the outside world, then this should work. Is the BSD >machine acting as a mail server? um, no. I want users to be able to read and send mail normally from the private side to the public side and, I want mail from the outside world to pass in to the mail server that is on the private side, mail server is not running on the gateway/firewall. I allow all outgoing traffic ie; from private to public so I don't think 'outgoing' mail needs its own rule? But I have not been able to get mail from the public net to get passed to my mail server on the private net. thanks, Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 13:31:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5997337B479 for ; Mon, 20 Nov 2000 13:31:53 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id OAA74738; Mon, 20 Nov 2000 14:30:28 -0700 (MST) Date: Mon, 20 Nov 2000 14:30:28 -0700 (MST) From: Nick Rogness To: Hamilton Hoover Cc: "freebsd-net@freebsd.org" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. In-Reply-To: <3A197FA5.95299923@twopoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Nov 2000, Hamilton Hoover wrote: I'm only sending the response to -net. > >>1) We keep out pop server on the private net. I need to be >>able to > get the incoming mail passed to the mail server that >>has a 192.x.x.x > address. I was thinking something like: > > > > Incoming from the outside or inside? > > Incoming from the public net. Do you have a NAT translation setup for that machine? If not see below. > > >>${fw8cmd} pass tcp from any 25 to 192.x.x.x > > > > The POP server runs on port 110 not 25, that's SMTP. > > ok. then I change that from 25 to 110? I run qmail on a linux box on my > private net. Is your linux qmail server on the same network as your client machines? If so, then you need no special firewall rules for that box. Since your mail server is on the inside of your network it never touches your firewall. For public access to your mail server (SMTP) the above rule with port 25 will work fine. It must come AFTER the divert rule. Another question...Do you want clients from the outside to check their mail via POP (or IMAP)? > > >>Is this solid or am I opening myself up from more problems. I > >>don't want to relay from outside as mail is only checked from > >>inside the private side. > > >If you don't want mail from the outside world or users to send >mail > to the outside world, then this should work. Is the BSD >machine > acting as a mail server? > > um, no. I want users to be able to read and send mail normally from the > private side to the public side and, I want mail from the outside world > to pass in to the mail server that is on the private side, mail server > is not running on the gateway/firewall. I allow all outgoing traffic ie; > from private to public so I don't think 'outgoing' mail needs its own > rule? But I have not been able to get mail from the public net to get > passed to my mail server on the private net. If you don't have NAT setup then: You need to add a network address translation (NAT) statement to your natd config. Either a redirect_address or redirect_port will work. For example, let's say that your inside mail server is 192.168.1.2. You have a free outside IP of 209.4.4.4 that you want to assign to this mail server. Your natd statement would be: redirect_address 192.168.1.2 209.4.4.4 You can use redirect_port in the same way. Then set you MX record (public) to point to the above outside IP. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 20 15:12:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.4]) by hub.freebsd.org (Postfix) with ESMTP id E9CA337B4D7 for ; Mon, 20 Nov 2000 15:12:21 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id RAA00927; Mon, 20 Nov 2000 17:12:48 -0600 Message-ID: <3A19B06B.1D5D9041@twopoint.com> Date: Mon, 20 Nov 2000 17:14:51 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nick Rogness Cc: "freebsd-net@freebsd.org" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ok, more answers and more questions... > > On Mon, 20 Nov 2000, Hamilton Hoover wrote: > > I'm only sending the response to -net. > > > >>1) We keep out pop server on the private net. I need to be >>able to > > get the incoming mail passed to the mail server that >>has a 192.x.x.x > > address. I was thinking something like: > > > > > > > Incoming from the outside or inside? > > > > Incoming from the public net. > > Do you have a NAT translation setup for that machine? > If not see below. I have made a change to natd.conf as you list below. I am unsure if the syntax is correct. redirect_port tcp 192.x.x.x:25 209.x.x.x:25 I'm thinking that this will pass the mail from the external (public)interface of the nated system to the mailserver at 192.x.x.x on the private side. yes? > > > > > >>${fw8cmd} pass tcp from any 25 to 192.x.x.x > > > > > > > The POP server runs on port 110 not 25, that's SMTP. > > > > ok. then I change that from 25 to 110? I run qmail on a linux box on my > > private net. > > Is your linux qmail server on the same network as your client > machines? If so, then you need no special firewall rules for that > box. Since your mail server is on the inside of your network it > never touches your firewall. yes it is. > > For public access to your mail server (SMTP) the above rule with > port 25 will work fine. It must come AFTER the divert rule. thats the thing. I don't want public access to the mail server. I just want the incoming mail from the public side to get passed through the firewall to the mailserver on the private side By divert rule do you mean the addition to natd.conf, or is there a divert I need to put in to my firewall script as well as the add pass tcp 25 from any to 192.x.x.x? > > Another question...Do you want clients from the outside to check > their mail via POP (or IMAP)? No, mail should only be checked from the private side but, on the inside we use POP. > > > > > >>Is this solid or am I opening myself up from more problems. I > > >>don't want to relay from outside as mail is only checked from > > >>inside the private side. > > > > >If you don't want mail from the outside world or users to send >mail > > to the outside world, then this should work. Is the BSD >machine > > acting as a mail server? > > > > > um, no. I want users to be able to read and send mail normally from the > > private side to the public side and, I want mail from the outside world > > to pass in to the mail server that is on the private side, mail server > > is not running on the gateway/firewall. I allow all outgoing traffic ie; > > from private to public so I don't think 'outgoing' mail needs its own > > rule? But I have not been able to get mail from the public net to get > > passed to my mail server on the private net. > > If you don't have NAT setup then: > > You need to add a network address translation (NAT) statement to > your natd config. Either a redirect_address or redirect_port will > work. For example, let's say that your inside mail server is > 192.168.1.2. You have a free outside IP of 209.4.4.4 that you > want to assign to this mail server. Your natd statement would be: > > redirect_address 192.168.1.2 209.4.4.4 I looked in the natd man pages and didn't see an example of redirect_port. > > You can use redirect_port in the same way. > > Then set you MX record (public) to point to the above outside IP. The public MX record points to a name that has an alias. The alias point to the firewall. The alias is also the machine name of the mailserver on the inside. > > Nick Rogness > - Drive defensively. Buy a tank. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 2:43:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from euitt.upm.es (haddock.euitt.upm.es [138.100.52.102]) by hub.freebsd.org (Postfix) with ESMTP id 9BC9D37B4CF for ; Tue, 21 Nov 2000 02:43:44 -0800 (PST) Received: from deneb.euitt.upm.es (deneb.euitt.upm.es [138.100.52.12]) by euitt.upm.es (8.9.3/8.9.3) with ESMTP id LAA02976 for ; Tue, 21 Nov 2000 11:43:42 +0100 (MET) Date: Tue, 21 Nov 2000 11:43:41 +0100 (CET) From: "Pedro J. Lobo" To: freebsd-net@freebsd.org Subject: Revised patch for VLAN support (fxp driver) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, all. First of all, I want to apologyze for not answering some mails I have received in the past few months. Although it's been a hard time, it wouldn't have taken so long to give a short answer. I'm sorry. Now to the business. I have updated the fxp patch for FreeBSD 4.1 and 4.1.1. For those that doesn't know the story, it allows the fxp driver (Intel EtherExpress Pro/100, all versions, Pro/10 PCI and any 82557/8/9 based NIC) to receive the oversized packets that are needed for proper IEEE 802.1Q VLAN operation. The page is still at: http://www.euitt.upm.es/~pjlobo/fbsdvlan.html I will make a patch for 4.2 as soon as I can. See the page for more information. Cheers, Pedro. -- -------------------------------------------------------------------- Pedro José Lobo Perea Tel: +34 913367819 / Fax: +34 913319229 Centro de Cálculo e-mail: pjlobo@euitt.upm.es E.U.I.T. Telecomunicación Universidad Politécnica de Madrid Ctra. de Valencia, Km. 7 E-28031 Madrid - España / Spain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 5:13:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id A83B137B4D7 for ; Tue, 21 Nov 2000 05:13:05 -0800 (PST) Received: from victoria-171.budapest.interware.hu ([195.70.63.171] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13yDEL-00052n-00 for ; Tue, 21 Nov 2000 14:13:02 +0100 Message-ID: <3A1A74D4.CF5AEF4F@elischer.org> Date: Tue, 21 Nov 2000 05:12:52 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: ALTQ as standard..... Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd like to put to the networking list that we take a serious look at making the ALTQ code from Kenjiro Cho a standard part of FreeBSD. I'm looking at adding some queueing methods into Netgraph as part of some work being discussed by phk, Archie, Brian and myself, Looking into this I note that for the to be really effective we really want to have an overall queueing strategy for the OS. We have at the moment, the simplistic IFQ_ macro's, but I think that they have lived long enough and done their duty. I'd like to replace them (or at least supplement them) in a way that allows us to have more comprehensive queue support. If done correctly, (e.g the correct macro's are added,) I think we can keep the performance degradation to a minimum. MY main reason right NOW is that in some cases, Netgraph interfaces to exisiting code using the exisiting queues, and if I want to add such things as queue priorities, I can't do this unless the exisiting code also upgrades. (e.g. the netgraph ethernet hooks deliver packets into the same queue that the normal interface methods do.) Julian -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 5:41:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (vbook.express.ru [212.24.37.106]) by hub.freebsd.org (Postfix) with ESMTP id D095A37B4C5 for ; Tue, 21 Nov 2000 05:41:32 -0800 (PST) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id QAA16381; Tue, 21 Nov 2000 16:41:11 +0300 (MSK) (envelope-from vova) From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.31606.944182.812070@vbook.express.ru> Date: Tue, 21 Nov 2000 16:41:10 +0300 (MSK) To: Kazufumi-MIT-Mitani Cc: freebsd-net@FreeBSD.ORG Subject: ifdefault In-Reply-To: <200010300914.SAA07875@mit-s.otaru-uc.ac.jp> References: <200010300914.SAA07875@mit-s.otaru-uc.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kazufumi-MIT-Mitani writes: > Hi. > > Is there any successful port of Paul Vixie's ifdefault > (ftp://ftp.vix.com/pub/vixie/ifdefault/) > to FreeBSD? I think it can be emulated with ipfw: let's imagin that we have two providers A and B with two networks allocated for us: a.a.a.a/A and b.b.b.b/B and connected to interfaces aa0 ii bb0 with nexthops a.a.next.hop and b.b.next.hop for default routes # route add default -iface lo1 # ipfw add fwd a.a.next.hop ip from a.a.a.a/A to any out via lo1 # ipfw add fwd b.b.next.hop ip from b.b.b.b/B to any out via lo1 there we can use samething like defeault 0.0.0.0/0 route for other networks # ipfw add fwd some.default.next.hop ip from any to any out via lo1 -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 6:34:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 4762337B4CF for ; Tue, 21 Nov 2000 06:34:14 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id JAA00901; Tue, 21 Nov 2000 09:35:09 -0500 (EST) Date: Tue, 21 Nov 2000 09:35:09 -0500 (EST) From: Alex Pilosov To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: ALTQ as standard..... In-Reply-To: <3A1A74D4.CF5AEF4F@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian, Can you take a look at the code http://www.riss-telecom.ru/~vitaly/ Its already based on netgraph, and it can do [almost] everything that ALTQ does. The only thing it lacks compared to altq is a large selection of queuing disciplines. It is also much faster than altq. bwman also has support for lower and upper bound of bandwidth, unlike ALTQ. -alex On Tue, 21 Nov 2000, Julian Elischer wrote: > I'd like to put to the networking list that we take a serious look > at making the ALTQ code from Kenjiro Cho a standard part of FreeBSD. > > I'm looking at adding some queueing methods into Netgraph > as part of some work being discussed by > phk, Archie, Brian and myself, Looking into this I note that > for the to be really effective we really want to have an > overall queueing strategy for the OS. We have at the moment, > the simplistic IFQ_ macro's, but I think that they have lived > long enough and done their duty. > I'd like to replace them (or at least supplement them) > in a way that allows us to have more comprehensive queue > support. If done correctly, (e.g the correct macro's > are added,) I think we can keep the performance degradation > to a minimum. > > MY main reason right NOW is that in some cases, Netgraph > interfaces to exisiting code using the exisiting queues, and > if I want to add such things as queue priorities, I can't > do this unless the exisiting code also upgrades. > (e.g. the netgraph ethernet hooks deliver packets into the > same queue that the normal interface methods do.) > > Julian > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 6:44:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 38ADC37B479 for ; Tue, 21 Nov 2000 06:44:11 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eALEhV510844; Tue, 21 Nov 2000 08:43:31 -0600 (CST) (envelope-from jlemon) Date: Tue, 21 Nov 2000 08:43:31 -0600 (CST) From: Jonathan Lemon Message-Id: <200011211443.eALEhV510844@prism.flugsvamp.com> To: julian@elischer.org, net@freebsd.org Subject: Re: ALTQ as standard..... X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >I'd like to put to the networking list that we take a serious look >at making the ALTQ code from Kenjiro Cho a standard part of FreeBSD. > >I'm looking at adding some queueing methods into Netgraph >as part of some work being discussed by >phk, Archie, Brian and myself, Looking into this I note that >for the to be really effective we really want to have an >overall queueing strategy for the OS. We have at the moment, >the simplistic IFQ_ macro's, but I think that they have lived >long enough and done their duty. >I'd like to replace them (or at least supplement them) >in a way that allows us to have more comprehensive queue >support. If done correctly, (e.g the correct macro's >are added,) I think we can keep the performance degradation >to a minimum. > >MY main reason right NOW is that in some cases, Netgraph >interfaces to exisiting code using the exisiting queues, and >if I want to add such things as queue priorities, I can't >do this unless the exisiting code also upgrades. >(e.g. the netgraph ethernet hooks deliver packets into the >same queue that the normal interface methods do.) Do you have a potential replacement for the IFQ_* macros in mind? I'm updating the IF_* macros to be SMP safe, but still haven't changed the FIFO ordering. The patch is at http://www.flugsvamp.com/~jlemon/fbsd/ifq_v4.patch One change in these macros is the introduction of an IF_HANDOFF() macro that performs all the queueing, so in theory it should be easier in the future to conditionalize this to perform different types of packet queuing. However, as Kenjiro pointed out earlier, all the drivers need to be updated to perform correct dequeueing (rather than the various ad-hoc "look at head, dequeue, prepend if no space, etc". This requires significantly more code changes than updating some macro sets. As far as Netgraph goes, I note that each netgraph node seems to require two queues; fast and slow. Also, who is responsible for freeing the metadata for a packet? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 6:56:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id A0DC237B4D7 for ; Tue, 21 Nov 2000 06:56:23 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id HAA96987; Tue, 21 Nov 2000 07:55:01 -0700 (MST) Date: Tue, 21 Nov 2000 07:54:55 -0700 (MST) From: Nick Rogness To: Hamilton Hoover Cc: "freebsd-net@freebsd.org" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. In-Reply-To: <3A19B06B.1D5D9041@twopoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Nov 2000, Hamilton Hoover wrote: > > > > > >>1) We keep out pop server on the private net. I need to be >>able to > > > get the incoming mail passed to the mail server that >>has a 192.x.x.x > > > address. I was thinking something like: > > > > > > > > > > Incoming from the outside or inside? > > > > > > Incoming from the public net. > > > > Do you have a NAT translation setup for that machine? > > If not see below. > > I have made a change to natd.conf as you list below. I am unsure if the > syntax is correct. > > redirect_port tcp 192.x.x.x:25 209.x.x.x:25 > > I'm thinking that this will pass the mail from the external > (public)interface of the nated system to the mailserver at 192.x.x.x on > the private side. yes? > Yes this is correct! > thats the thing. I don't want public access to the mail server. I just > want the incoming mail from the public side to get passed through the > firewall to the mailserver on the private side Then all you need is the redirect_port statement. > > By divert rule do you mean the addition to natd.conf, or is there a > divert I need to put in to my firewall script as well as the add pass > tcp 25 from any to 192.x.x.x? > > > > > Another question...Do you want clients from the outside to check > > their mail via POP (or IMAP)? > > No, mail should only be checked from the private side but, on the inside > we use POP. [snip] > I looked in the natd man pages and didn't see an example of > redirect_port. man 8 natd. It's in there. > > > > > You can use redirect_port in the same way. > > > > Then set you MX record (public) to point to the above outside IP. > > The public MX record points to a name that has an alias. The alias point > to the firewall. The alias is also the machine name of the mailserver on > the inside. I would change the MX record to correspond to the redirect_port statement PUBLIC ip. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 9: 4:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id EEF8837B4C5; Tue, 21 Nov 2000 09:04:26 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA38946; Tue, 21 Nov 2000 10:04:25 -0700 (MST) (envelope-from ken) Date: Tue, 21 Nov 2000 10:04:25 -0700 From: "Kenneth D. Merry" To: net@FreeBSD.org Subject: new zero copy sockets and NFS snapshot Message-ID: <20001121100425.A38926@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 20th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The fix to the "localhost panic" problem has been revamped. We now use a new external mbuf type, EXT_DISPOSABLE, to indicate that the external mbuf payload may be page-flipped or otherwise discarded. Instead of attempting to page flip any pages that meet the size and alignment criteria, we now only page flip external mbufs marked as disposable. (Thanks to Drew Gallatin for suggesting this approach.) - The decision process on when to use vm_uiomove() versus vm_pgmoveco() in uiomoveco() has been revamped somewhat. We no longer panic in any case. Anything that isn't handled by vm_pgmoveco() (according to the page flip criteria described above) is passed to vm_uiomove(). - uiomoveco() has been reorganized somewhat, with some of the functionality split out into a subfunction. There are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin . - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 9:32: 3 2000 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 9FE9837B479 for ; Tue, 21 Nov 2000 09:32:00 -0800 (PST) Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9A1B6E2931 for ; Tue, 21 Nov 2000 09:30:33 -0800 (PST) Received: from localhost.localdom (p3EE3FF80.dip.t-dialin.net [62.227.255.128]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id SAA10409 for ; Tue, 21 Nov 2000 18:28:42 +0100 (MET) Received: from 192.168.0.1 (master [192.168.0.1]) by localhost.localdom (8.11.1/8.11.1) with ESMTP id eALCnr000814 for ; Tue, 21 Nov 2000 13:49:53 +0100 (CET) Date: Tue, 21 Nov 2000 11:35:24 -0800 From: Boris X-Mailer: The Bat! (v1.46d) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <838997467.20001121113524@x-itec.de> To: freebsd-net@FreeBSD.ORG Subject: IPSEC Win2k Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello freebsd-net, i have read everything possible, but i can´t find any solution for this problem. I have a misunderstanding with ipsec/ike, maybe someone point me to the right way. I try to setup a connection between my FreeBSD Server and my Win2k server box. two machines, nothing special. Win2k wants ONE password as shared secret, and my FreeBSD box wants TWO passwords (??????). On my BSD Box i have installed racoon. This is my currently script for my bsd box, i am new with ipsec/ike so i am sure i made something wrong, but i can´t find out what. I am sure i have a complete misunderstanding somewhere. #! /bin/sh # setkey -D -P -c <; Tue, 21 Nov 2000 09:50:14 -0800 (PST) Received: by mail.snickers.org (Postfix, from userid 66) id 9406A3D35; Tue, 21 Nov 2000 12:50:09 -0500 (EST) Received: by asherah.dyndns.org (Postfix, from userid 701954) id 939A334503; Tue, 21 Nov 2000 12:48:48 -0500 (EST) Date: Tue, 21 Nov 2000 12:48:48 -0500 From: Josh Tiefenbach To: Boris Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Win2k Message-ID: <20001121124847.F37765@zipperup.org> References: <838997467.20001121113524@x-itec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <838997467.20001121113524@x-itec.de>; from koester@x-itec.de on Tue, Nov 21, 2000 at 11:35:24AM -0800 Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I try to setup a connection between my FreeBSD Server > and my Win2k server box. two machines, nothing special. By sheer coincidence, I did this just the other day. > setkey -D -P -c < spdflush; > flush ; > add 192.168.0.99 192.168.0.1 ah 2000 -m transport -A hmac-sha1 "PASSWORD" ; > add 192.168.0.99 192.168.0.1 esp 3000 -m transport -E 3des-cbc "PASSWORD" ; > spdadd 192.168.0.99 192.168.0.1 any -P out ipsec esp/transport/192.168.0.99-192. > 168.0.1/require ; This is the problem. you've set up manual keying on the BSD box. I dont think that Win2k can accept that. Plus, you've only created a policy for outgoing packets, rather than incoming packets. Plus, you dont say which version of FreeBSD you are using. IIRC, only FreeBSD 4.x-STABLE supports IKE (using racoon). Here is a small writeup that I did for someone else on how to have BSD and Win2k talk to each other using IPsec. 1. Get a FreeBSD box, recompile the kernel with the IPsec options, and install the racoon port. 2. On the FreeBSD machine, do the following (presuming that the FreeBSD machine is 1.2.3.4 and the win2k machine is 5.6.7.8) setkey -FP # Note. This and the next line will delete all previous SPD setkey -F # entries. setkey -c << EOF spdadd 1.2.3.4/32 5.6.7.8/32 any -P out ipsec esp/transport/1.2.3.4-5.6.7.8/require; spdadd 5.6.7.8/32 1.2.3.4/32 any -P in ipsec esp/transport/5.6.7.8-1.2.3.4/require; 3. Configure psk.txt and racoon.conf. You shouldnt really need to make any changes to the racoon.conf file from the default, tho I have noticed that increasing the "lifetime time" parameter in the "sainfo anonymous" stanza to something like 3600 seconds, and the "lifetime byte" parameter to 50000 KB improves performance, as you're not swapping keys as often. In the psk.txt file, add the following entry: 5.6.7.8 somelongstringasasharedsecret Make sure that psk.txt is mode 600, owned by root. Start up racoon. 4. On the Win2k machine, fire up a command window, and launch 'mmc'. Go to Console->Add/Remove Snap in. Add the IP Security Policy Management snap-in. 5. Click on IP Security Policies in the tree listing, and then select Action->Create IP Security Policy from the menu. 6. Go thru the wizard. In particular, * Do not activate the default response rule. * Edit the properties. 7. In the properties, click on the Add button to add a new rule. Go thru the wizard, and ensure the following settings: * The rule does not specify a tunnel. * The rule applies to the LAN * Use a string to protect the key exchange. Stick in the same key as you used in the psk.txt file * You'll want to create a new IP filter so that only traffic to the BSD box is subjected to the security policy. Select this new filter. * Select 'Require Security' for the filter action. 8. Select the new policy in the window, and click on the toggle switch icon in the menu bar to activate the policy. 9. Open up a command window, and ping the BSD box. The ping will 'fail' with a message 'Negotiating IP Security'. Another ping should subsequently work. At this point, all IP traffic between the 2 boxes has been secured. josh -- This email has been brought to you by the letters U, U, C, and P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 10: 0:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 92BC737B4C5 for ; Tue, 21 Nov 2000 10:00:01 -0800 (PST) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id CAA37983; Wed, 22 Nov 2000 02:59:59 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id CAA78742; Wed, 22 Nov 2000 02:59:59 +0900 (JST) To: julian@elischer.org Cc: net@freebsd.org Subject: Re: ALTQ as standard..... In-Reply-To: <3A1A74D4.CF5AEF4F@elischer.org> References: <3A1A74D4.CF5AEF4F@elischer.org> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001122025959Z.kjc@csl.sony.co.jp> Date: Wed, 22 Nov 2000 02:59:59 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 53 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ALTQ can be viewed as (1) abstraction of the output queue and (2) an implementation based on (1) I'd like to focus on (1) for our discussion for the moment. The output queue is the place where packet scheduling and buffer management can be done. The current IF macros are incomplete (e.g., lack of a poll operation), and its model lacks enough abstraction to accommodate algorithms other than FIFO. I'm trying to make the output queue as a black-box with a set of well-defined operations, and modify the existing code to access the output queue only through these operations. Although we have to first convert the existing drivers to use these operations, I believe it will pay off in the long run. Once we have a clean model of the output queue, modifications to the internal structure do not affect the other part of the kernel, be it ALTQ or another implementation. (this approach is also preferable for SMP.) In ALTQ, the following 4 operations are used. - ENQUEUE enqueues a packet to the queue. ENQUEUE also takes care of packet dropping. if the arriving packet is dropped, the mbuf is freed and an error (ENOBUFS) is returned. - DEQUEUE dequeues a packet from the queue. - POLL returns the next packet without removing the packet from the queue. if DEQUEUE immediately follows POLL, the same packet is returned. (locking will be needed for SMP.) - PURGE discards all the packets in the queue. (this operation is needed for non-work conserving schedulers which cannot get emptied by a dequeue-loop.) In this model, a driver can poll-and-dequeue a packet but cannot prepend a packet back to the queue because it could be too expensive for some algorithms to cancel scheduling once the internal state is updated. Thus, if a driver currently use "prepend-if-failed", it should be converted to "poll-and-dequeue". I'll write a brief design note in a week (so that I can submit it to Freenix). I'll post it to the list when I'm done. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 10: 5:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6CF6F37B4D7 for ; Tue, 21 Nov 2000 10:05:25 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA36395; Tue, 21 Nov 2000 13:05:15 -0500 (EST) (envelope-from wollman) Date: Tue, 21 Nov 2000 13:05:15 -0500 (EST) From: Garrett Wollman Message-Id: <200011211805.NAA36395@khavrinen.lcs.mit.edu> To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Win2k In-Reply-To: <20001121124847.F37765@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Here is a small writeup that I did for someone else on how to have BSD > and Win2k talk to each other using IPsec. Can I be so forward as to suggest that this is exactly the sort of thing that really ought to go into the handbook and/or FAQ? One of the problems that we have with IPSEC is that the documentation (at least in English) is inadequate. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 11: 5:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 8C83E37B479 for ; Tue, 21 Nov 2000 11:05:13 -0800 (PST) Received: by mail.snickers.org (Postfix, from userid 66) id 053D83D27; Tue, 21 Nov 2000 14:05:11 -0500 (EST) Received: by asherah.dyndns.org (Postfix, from userid 701954) id 3BD0934503; Tue, 21 Nov 2000 14:03:06 -0500 (EST) Date: Tue, 21 Nov 2000 14:03:05 -0500 From: Josh Tiefenbach To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Win2k Message-ID: <20001121140305.G37765@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> <200011211805.NAA36395@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011211805.NAA36395@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Nov 21, 2000 at 01:05:15PM -0500 Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Here is a small writeup that I did for someone else on how to have BSD > > and Win2k talk to each other using IPsec. > > Can I be so forward as to suggest that this is exactly the sort of > thing that really ought to go into the handbook and/or FAQ? Hrmmm. I'll try to kick some time free later tonite and throw together something suitable for a PR. > One of > the problems that we have with IPSEC is that the documentation (at > least in English) is inadequate. Yeah. There is virtually nothing out there on how to get racoon working intelligibly. Just so its in the archives, I should point out that NetBSD's IPsec documentation is, while not great, scads better that whats currently in the handbook. http://www.netbsd.org/Documentation/network/ipsec/ More or less all of it is applicable to FreeBSD. josh -- This email has been brought to you by the letters U, U, C, and P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 11:20:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.4]) by hub.freebsd.org (Postfix) with ESMTP id 1B77E37B479 for ; Tue, 21 Nov 2000 11:20:03 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id NAA00933; Tue, 21 Nov 2000 13:20:12 -0600 Message-ID: <3A1ACB68.E9CA2862@twopoint.com> Date: Tue, 21 Nov 2000 13:22:16 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nick Rogness Cc: "freebsd-net@freebsd.org" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org First, thanks so much for your help so far. The information I have learned is invaluable. Should you ever be in my neck of the woods beer and pizza are on me. I am so close at this point i can taste it. There are just a few bugs left that I am having trouble with. At this point I am still not passing mail from the firewall but I can see in various logs what is stopping it. I am not sure how to circumvent this. my natd.conf reads as follows: dynamic no use_sockets yes same_ports yes redirect_port tcp 192.x.x.x:25 209.x.x.x:25 where 192.x.x.x is the address of the mail server on the private net and 209.x.x.x is the address of the public interface of the firewall. my firewall script has these rules for passing mail. I'm unsure if I even need this with the redirect rule in natd.conf but I put it here anyway. I have tried commenting it and the results were the same. ${fwcmd} add pass tcp from any 25 to 192.x.x.x 25 I have also tried ${fwcmd} add pass tcp from any 25 to 192.x.x.x 25 via ${iip} Scanning open ports on the public side of the firewall I noticed that only ssh 22 is open. I need to have port 25 open in order for this to work right? In rc.conf I have sendmail_enable "NO" changing this to sendmail_enable "yes" produces sendmail relaying denied errors. I'm pretty sure that I don't really need sendmail running just to pass itt through the firewall but I don't seem to be able to open port 25 without it. Additionally I would like the security email sent to myself and that only seems to work if sendmail is running. any more help? Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 12:17: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5EE9E37B4E5 for ; Tue, 21 Nov 2000 12:16:53 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA94814; Tue, 21 Nov 2000 13:15:32 -0700 (MST) Date: Tue, 21 Nov 2000 13:15:31 -0700 (MST) From: Nick Rogness To: Hamilton Hoover Cc: "freebsd-net@freebsd.org" Subject: Re: dual homed gateway system running ipfw and nat. need rules help. In-Reply-To: <3A1ACB68.E9CA2862@twopoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 21 Nov 2000, Hamilton Hoover wrote: > First, thanks so much for your help so far. The information I have > learned is invaluable. Should you ever be in my neck of the woods beer > and pizza are on me. Might take you up on that ;-p > > I am so close at this point i can taste it. There are just a few bugs > left that I am having trouble with. At this point I am still not passing > mail from the firewall but I can see in various logs what is stopping > it. I am not sure how to circumvent this. > What des the logs say. > my natd.conf reads as follows: > > dynamic no > use_sockets yes > same_ports yes > redirect_port tcp 192.x.x.x:25 209.x.x.x:25 > What do your firewall and natd files look like (complete)? > where 192.x.x.x is the address of the mail server on the private net and > 209.x.x.x is the address of the public interface of the firewall. > > my firewall script has these rules for passing mail. I'm unsure if I > even need this with the redirect rule in natd.conf but I put it here > anyway. I have tried commenting it and the results were the same. > > ${fwcmd} add pass tcp from any 25 to 192.x.x.x 25 > If you are going to use this rule, Make sure this rule occurs after the divert statement in the ipfw ruleset. You shouldn't have to use it though. > I have also tried > > ${fwcmd} add pass tcp from any 25 to 192.x.x.x 25 via ${iip} > > Scanning open ports on the public side of the firewall I noticed that > only ssh 22 is open. I need to have port 25 open in order for this to > work right? In rc.conf I have > No. The port is taken care of by natd. > sendmail_enable "NO" > > changing this to > > sendmail_enable "yes" > Leave sendmail off. > produces sendmail relaying denied errors. I'm pretty sure that I don't > really need sendmail running just to pass itt through the firewall but I > don't seem to be able to open port 25 without it. Additionally I would > like the security email sent to myself and that only seems to work if > sendmail is running. > Use an alias to forward it to your linux machine. I need more specific info like IP addresses and configs. You can email off this list and I'll work with ya on it. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 13: 6:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id F11DF37B4D7 for ; Tue, 21 Nov 2000 13:06:11 -0800 (PST) Received: from mogadishu-42.budapest.interware.hu ([195.70.52.106] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13yKcC-0006nN-00; Tue, 21 Nov 2000 22:06:08 +0100 Message-ID: <3A1AE3BB.299944A4@elischer.org> Date: Tue, 21 Nov 2000 13:06:03 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: ALTQ as standard..... References: <200011211443.eALEhV510844@prism.flugsvamp.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > > > Do you have a potential replacement for the IFQ_* macros > in mind? I'm updating the IF_* macros to be SMP safe, but > still haven't changed the FIFO ordering. Basically kenjiro's maro set.. > > The patch is at http://www.flugsvamp.com/~jlemon/fbsd/ifq_v4.patch I'll have a look > > One change in these macros is the introduction of an IF_HANDOFF() > macro that performs all the queueing, so in theory it should be > easier in the future to conditionalize this to perform different > types of packet queuing. I'm going to need to interface with this stuff and I want to implement such things as highwater marks and such. Netgraph interfaces with 'standard' interfaces in the ethernet driver forinstance. the queue is the handoff point. I'm trying to provide some standard queuing support in netgraph so it seems to me that something like Kenjiro's changes would be good to do at the same time or before. His patches seem pretty complete from what I saw. > > However, as Kenjiro pointed out earlier, all the drivers need > to be updated to perform correct dequeueing (rather than the various > ad-hoc "look at head, dequeue, prepend if no space, etc". This > requires significantly more code changes than updating some macro > sets. true but he's already spent a lot of time on this and has from what I see, a lot of it already under control (see 'supported interface cards') > > As far as Netgraph goes, I note that each netgraph node seems to > require two queues; fast and slow. No, no queueing is required on the average node. You may be confused by the two input methods.. they are TERRIBLY named and archie got the description confused in his doc. here's what I added to the file this very afternoon. (I changed the names and added theses comments at various places.) ----------- . /* * Structure of a node type. + * If data is sent to the "rcvdata_may_queue ()" entrypoint then the node + * may decide to defer it until later by queing it with the normal netgraph + * input queuing system. When it is dequeued it will be + * passed to the "rcvdata_dont_queue()" method to ensure it is not + * requeued again. Nodes may supply the same method for both + * entrypoints if they have no need to queue incoming data. + * Note that the input queueing system is to allow modules + * to 'release the stack' or to pass data across spl layers. + * The data will be redelivered as soon as the NETISR code runs + * which may be almost immediatly. A node may also do it's own queueing + * for other reasons (e.g. device output queuing), but most nodes will * * not do any queueing */ struct ng_type { @@ -170,8 +181,8 @@ ng_newhook_t *newhook; /* first notification of new hook */ ng_findhook_t *findhook; /* only if you have lots of hooks */ ng_connect_t *connect; /* final notification of new hook */ - ng_rcvdata_t *rcvdata; /* date comes here */ - ng_rcvdata_t *rcvdataq; /* or here if being queued */ + ng_rcvdata_t *rcvdata_may_queue; /* data usually comes here */ + ng_rcvdata_t *rcvdata_dont_queue; /* but here if was queued */ ng_disconnect_t *disconnect; /* notify on disconnect */ const struct ng_cmdlist *cmdlist; /* commands we can convert */ @@ -182,47 +193,58 @@ }; > Also, who is responsible for > freeing the metadata for a packet? the consumer. or the last node to see it when an error occurs. If I could change the definition of an mbuf, it'd be pointed to by a field in the mbuf. so whoever frees the mbuf should free it. > -- > Jonathan -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 13:24:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 56FA737B4CF for ; Tue, 21 Nov 2000 13:24:46 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eALLO4926749; Tue, 21 Nov 2000 15:24:04 -0600 (CST) (envelope-from jlemon) Date: Tue, 21 Nov 2000 15:24:04 -0600 (CST) From: Jonathan Lemon Message-Id: <200011212124.eALLO4926749@prism.flugsvamp.com> To: kjc@csl.sony.co.jp, net@freebsd.org Subject: Re: ALTQ as standard..... X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >In ALTQ, the following 4 operations are used. > - ENQUEUE > enqueues a packet to the queue. ENQUEUE also takes care of > packet dropping. if the arriving packet is dropped, the mbuf > is freed and an error (ENOBUFS) is returned. > - DEQUEUE > dequeues a packet from the queue. > - POLL > returns the next packet without removing the packet from the > queue. > if DEQUEUE immediately follows POLL, the same packet is > returned. (locking will be needed for SMP.) > - PURGE > discards all the packets in the queue. (this operation is > needed for non-work conserving schedulers which cannot get > emptied by a dequeue-loop.) This is roughly what I have now (but with slightly different names). Note that freeing the mbuf is a little problematic for netgraph, since you have to free the mbuf + metadata both. I also haven't addressed the (poll/dequeue vs dequeue/prepend) yet, I'll look at that after the first round of updates is complete. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 13:32:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from mb1i0.ns.pitt.edu (mb1i0.ns.pitt.edu [136.142.186.35]) by hub.freebsd.org (Postfix) with ESMTP id 2190E37B479 for ; Tue, 21 Nov 2000 13:32:22 -0800 (PST) Received: from box022.labs.pitt.edu ("port 1438"@[130.49.141.33]) by pitt.edu (PMDF V5.2-32 #41462) with ESMTP id <01JWT3WD9MAO00034Y@mb1i0.ns.pitt.edu> for freebsd-net@FreeBSD.org; Tue, 21 Nov 2000 16:22:26 EST Date: Tue, 21 Nov 2000 16:22:26 -0500 From: "Pedro F. Giffuni" Subject: Killing a port with FreeBSD and netcard Originator-info: login-id=pfg1; server=imap.pitt.edu To: freebsd-net@FreeBSD.org Message-id: <4161137642.974823746@box022.labs.pitt.edu> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not to sure if this should go to -mobile, ot -net or to no list...actually nobody commented in -chat, and I suspect -questions is not the proper place either so this was the last option. I bought a linksys netcard in order to use it with FreeBSD-4.1. I am comfortably running an old (non FreeBSDable) Alpha with Tru64 on that same port. I hooked everything and the card didn't give me any problem with W98. When I turned on the FreeBSD partition I got some messages from ed1, saying that manual intervention was required and that there was a duplicate IPV6 address found! Of course, I never found a clear guide on what values to put on if_config (it's the local address right?) so I understood that I would have to tweak a lot with the configuration, furthermore, I'm not using IPv6 so I ignored the messages. I tried to ping the campus server and it replied that I was doing something illegal for the router. I opened a session with Netscape, however, and it worked fine.... for two minutes. Next thing I know is that the port doesn't work for any computer in my office. The network manager fixed the port today but he gave no hint on what went wrong and I'm pretty sure that if I plug in FreeBSD again it will break again. If no one has a clear hint on what may failing in my configuration I think I'll break everything again but this time I'll log all the messages in FreeBSD. tia, Pedro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 15: 3:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by hub.freebsd.org (Postfix) with ESMTP id 5E84F37B4D7 for ; Tue, 21 Nov 2000 15:03:45 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA27788 for ; Tue, 21 Nov 2000 16:03:44 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA07966 for ; Tue, 21 Nov 2000 16:03:44 -0700 (MST)] Received: from pobox.cstl.labs.mot.com by m-il06-r1.mot.com with ESMTP for freebsd-net@FreeBSD.ORG; Tue, 21 Nov 2000 16:03:42 -0700 Received: from labs.mot.com ([173.23.93.6]) by pobox.cstl.labs.mot.com (Netscape Messaging Server 4.15) with ESMTP id G4EDE600.ROH for ; Tue, 21 Nov 2000 17:03:42 -0600 Message-Id: <3A1AFF4E.D1FBD5F5@labs.mot.com> Date: Tue, 21 Nov 2000 17:03:42 -0600 From: Joseph E Eggleston Reply-To: "Joe.Eggleston" Organization: Motorola Labs X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-1dac i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm currently trying to decide what open source OS to use for some IPv6 development. If anyone on this list has used both FreeBSD and Linux for IPv6, could you let me know what your sense is about how the IPv6 implementations compare (as far as stability, ease of setup, complete functionality...). Also, does anyone know of a Mobile IPv6 implementation for FreeBSD? Thanks, Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 15:52:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 4643A37B4D7 for ; Tue, 21 Nov 2000 15:51:41 -0800 (PST) Received: from localhost.localdom (p3E9E1511.dip.t-dialin.net [62.158.21.17]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA10079; Wed, 22 Nov 2000 00:51:22 +0100 (MET) Received: from masterpc (master [192.168.0.1]) by localhost.localdom (8.11.1/8.11.1) with ESMTP id eAM25B202433; Wed, 22 Nov 2000 03:05:11 +0100 (CET) Date: Wed, 22 Nov 2000 00:50:41 -0800 From: Boris X-Mailer: The Bat! (v1.46d) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <1563982125.20001122005041@x-itec.de> To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re[2]: IPSEC Win2k In-reply-To: <20001121124847.F37765@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Josh, Tuesday, November 21, 2000, 9:48:48 AM, you wrote: >> I try to setup a connection between my FreeBSD Server >> and my Win2k server box. two machines, nothing special. JT> By sheer coincidence, I did this just the other day. cool -) Now i have understand something more, but i have a problem, again no connection available, details coming now. JT> Plus, you dont say which version of FreeBSD you are using. IIRC, only FreeBSD JT> 4.x-STABLE supports IKE (using racoon). FreeBSD 4.1.1 and latest version of racoon JT> Here is a small writeup that I did for someone else on how to have BSD JT> and Win2k talk to each other using IPsec. JT> 2. On the FreeBSD machine, do the following (presuming that the FreeBSD JT> machine is 1.2.3.4 and the win2k machine is 5.6.7.8) JT> setkey -FP # Note. This and the next line will delete all previous SPD JT> setkey -F # entries. JT> setkey -c << EOF JT> spdadd 1.2.3.4/32 5.6.7.8/32 any -P out ipsec JT> esp/transport/1.2.3.4-5.6.7.8/require; JT> spdadd 5.6.7.8/32 1.2.3.4/32 any -P in ipsec JT> esp/transport/5.6.7.8-1.2.3.4/require; ok, i have used this: #! /bin/sh # setkey -FP # Note. This and the next line will delete all previous SPD setkey -F # entries. setkey -c << EOF spdadd 192.168.0.99/32 192.168.0.1 any -P out ipsec esp/transport/192.168.0.99-192.168.0.1/require; spdadd 192.168.0.1/32 192.168.0.99/32 any -P in ipsec esp/transport/192.168.0.1-192.168.0.99/require; .99 is the bsd box, .1 is the win2k box. JT> 3. Configure psk.txt and racoon.conf. You shouldnt really need to make any ... JT> In the psk.txt file, add the following entry: JT> 5.6.7.8 somelongstringasasharedsecret i have put something like 192.168.0.1 password... JT> Make sure that psk.txt is mode 600, owned by root. Start up racoon. JT> 4. On the Win2k machine, fire up a command window, and launch 'mmc'. Go to Console->>Add/Remove Snap in. Add the IP Security Policy Management snap-in. .... ok .... But racoon gives me a lot of error messages, i have added the messages here. I really do not know what to do now -(((((((((( Snapshot: 2000-11-22 02:53:09: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:09: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:52:57: pfkey.c:1966:pk_checkalg(): WARNING: compression algorithm can not be checked. 2000-11-22 02:53:05: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:05: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. Complete protocol: Foreground mode. 2000-11-22 02:52:57: @(#)racoon 20001111 sakane@ydc.co.jp 2000-11-22 02:52:57: @(#)This product linked software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) <3># "padding" defines some parameter of padding. You should not touch these. begin <11>padding <11>maximum_length <11>20 <11># maximum padding length. <11>randomize <11>off <11># enable randomize length. <11>strict_check <11>off <11># enable strict check. <11>exclusive_tail <11>off <11># extract last one octet. <3># if no listen directive is specified, racoon will listen to all <3># available interface addresses. begin <13>listen <13>#isakmp ::1 [7000]; <13>#isakmp 202.249.11.124 [500]; <13>#admin [7002]; # administrative's port by kmpstat. <13>#strict_address; # required all addresses must be bound. <3># Specification of default various timer. begin <15>timer <15># These value can be changed per remote node. <15>counter <15>5 <15># maximum trying count to send. <15>interval <15>20 <15>sec <15># maximum interval to resend. <15>persend <15>1 <15># the number of packets per a send. <15># timer for waiting to complete each phase. <15>phase1 <15>30 <15>sec <15>phase2 <15>15 <15>sec begin <33>remote <33>anonymous <35>#exchange_mode main,aggressive; <35>exchange_mode <35>aggressive <35>, <35>main <35>doi <35>ipsec_doi <35>situation <35>identity_only <35>#my_identifier address; <35>my_identifier <35>user_fqdn <35>"sakane@kame.net" <35>peers_identifier <35>user_fqdn <35>"sakane@kame.net" <35>#certificate_type x509 "mycert" "mypriv"; <35>nonce_size <35>16 <35>lifetime <35>time <35>1 <35>min <35># sec,min,hour <35>lifetime <35>byte <35>5 <35>MB <35># B,KB,GB <35>initial_contact <35>on <35>support_mip6 <35>on <35>proposal_check <35>obey <35># obey, strict or claim begin <37>proposal <37>encryption_algorithm <37>3des <37>hash_algorithm <37>sha1 <37>authentication_method <37>pre_shared_key <37>dh_group <37>2 lifetime = 60 lifebyte = 5120 strength=extra high encklen=0 isakmp enc= 00000000000000000000000000010000 isakmp hash= 00000000000000000000000000000010 isakmp dh= 00000000000000000000000000000010 isakmp auth method= 00000000000000000000000000000001 p:1 t:1 0 0 0 3DES-CBC(5) SHA(2) 1024-bit MODP group(2) pre-shared key(1) begin <33>remote <33>::1 <33>[8000] <35>#exchange_mode main,aggressive; <35>exchange_mode <35>aggressive <35>, <35>main <35>doi <35>ipsec_doi <35>situation <35>identity_only <35>my_identifier <35>user_fqdn <35>"sakane@kame.net" <35>peers_identifier <35>user_fqdn <35>"sakane@kame.net" <35>#certificate_type x509 "mycert" "mypriv"; <35>nonce_size <35>16 <35>lifetime <35>time <35>1 <35>min <35># sec,min,hour <35>lifetime <35>byte <35>5 <35>MB <35># B,KB,GB begin <37>proposal <37>encryption_algorithm <37>3des <37>hash_algorithm <37>sha1 <37>authentication_method <37>pre_shared_key <37>dh_group <37>2 lifetime = 60 lifebyte = 5120 strength=extra high encklen=0 isakmp enc= 00000000000000000000000000010000 isakmp hash= 00000000000000000000000000000010 isakmp dh= 00000000000000000000000000000010 isakmp auth method= 00000000000000000000000000000001 p:1 t:1 0 0 0 3DES-CBC(5) SHA(2) 1024-bit MODP group(2) pre-shared key(1) begin <29>sainfo <29>anonymous <31>pfs_group <31>1 <31>lifetime <31>time <31>30 <31>sec <31>lifetime <31>byte <31>5000 <31>KB <31>encryption_algorithm <31>3des <31>authentication_algorithm <31>hmac_sha1 <31>compression_algorithm <31>deflate 2000-11-22 02:52:57: pfkey.c:1966:pk_checkalg(): WARNING: compression algorithm can not be checked. begin <29>sainfo <29>address <29>203.178.141.209 <29>any <29>address <29>203.178.141.218 <29>any <31>pfs_group <31>1 <31>lifetime <31>time <31>30 <31>sec <31>lifetime <31>byte <31>5000 <31>KB <31>encryption_algorithm <31>des <31>authentication_algorithm <31>hmac_md5 <31>compression_algorithm <31>deflate 2000-11-22 02:52:57: pfkey.c:1966:pk_checkalg(): WARNING: compression algorithm can not be checked. 2000-11-22 02:52:57: sainfo.c:101:getsainfo(): anonymous sainfo selected. begin <29>sainfo <29>address <29>::1 <29>icmp6 <29>address <29>::1 <29>icmp6 <31>pfs_group <31>1 <31>lifetime <31>time <31>60 <31>sec <31>lifetime <31>byte <31>5000 <31>KB <31>encryption_algorithm <31>3des <31>, <31>cast128 <31>, <31>blowfish <31>, <31>des <31>authentication_algorithm <31>hmac_sha1 <31>, <31>hmac_md5 <31>compression_algorithm <31>deflate 2000-11-22 02:52:57: pfkey.c:1966:pk_checkalg(): WARNING: compression algorithm can not be checked. 2000-11-22 02:52:57: sainfo.c:101:getsainfo(): anonymous sainfo selected. parse successed. Foreground mode. 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: 192.168.0.99 (ed1) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: fe80::220:18ff:fe64:f25f%ed1 (ed1) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: fe80::1%lo0 (lo0) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: ::1 (lo0) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: 127.0.0.1 (lo0) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: 62.158.21.17 (isp0) 2000-11-22 02:52:57: grabmyaddr.c:213:grab_myaddrs(): my interface: fe80::220:18ff:fe64:f25f%isp0 (isp0) 2000-11-22 02:52:57: grabmyaddr.c:479:autoconf_myaddrsport(): configuring default isakmp port. 2000-11-22 02:52:57: grabmyaddr.c:503:autoconf_myaddrsport(): isakmp_autoconf success, 7 addrs 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): fe80::220:18ff:fe64:f25f%isp0[500] used as isakmp port (fd=9). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): 62.158.21.17[500] used as isakmp port (fd=10). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=11). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): ::1[500] used as isakmp port (fd=12). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): fe80::1%lo0[500] used as isakmp port (fd=13). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): fe80::220:18ff:fe64:f25f%ed1[500] used as isakmp port (fd=14). 2000-11-22 02:52:57: isakmp.c:1288:isakmp_open(): 192.168.0.99[500] used as isakmp port (fd=15). 2000-11-22 02:52:57: pfkey.c:192:pfkey_handler(): get pfkey X_SPDDUMP message sadb_msg{ version=2 type=18 errno=0 satype=0 len=15 reserved=1 seq=1 pid=2357 sadb_ext{ len=3 type=5 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 c0a80001 } sadb_ext{ len=3 type=6 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 c0a80063 } sadb_ext{ len=7 type=18 } sadb_x_policy{ type=2 dir=1 id=2 } { len=40 proto=50 mode=1 level=2 reqid=0 sockaddr{ len=16 family=2 port=0 c0a80001 } sockaddr{ len=16 family=2 port=0 c0a80063 } } 2000-11-22 02:52:57: pfkey.c:192:pfkey_handler(): get pfkey X_SPDDUMP message sadb_msg{ version=2 type=18 errno=0 satype=0 len=15 reserved=1 seq=0 pid=2357 sadb_ext{ len=3 type=5 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 c0a80063 } sadb_ext{ len=3 type=6 } sadb_address{ proto=255 prefixlen=32 reserved=0x0000 } sockaddr{ len=16 family=2 port=0 c0a80001 } sadb_ext{ len=7 type=18 } sadb_x_policy{ type=2 dir=2 id=1 } { len=40 proto=50 mode=1 level=2 reqid=0 sockaddr{ len=16 family=2 port=0 c0a80063 } sockaddr{ len=16 family=2 port=0 c0a80001 } } 2000-11-22 02:52:57: policy.c:189:cmpspidx(): sub:0xbfbff9c8: 192.168.0.99/32[0] 192.168.0.1/32[0] proto=255 dir=2 2000-11-22 02:52:57: policy.c:189:cmpspidx(): db :0x80a2208: 192.168.0.1/32[0] 192.168.0.99/32[0] proto=255 dir=1 2000-11-22 02:53:02: isakmp.c:207:isakmp_handler(): === 2000-11-22 02:53:02: isakmp.c:211:isakmp_handler(): 192.168.0.99[500] 216 bytes message received from 192.168.0.1[500] fe6e2baf 61660328 00000000 00000000 01100200 00000000 000000d8 0d0000a4 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 00000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000002 2000-11-22 02:53:02: isakmp.c:2152:isakmp_printpacket(): begin. 53:02.374683 192.168.0.1:500 -> 192.168.0.99:500: isakmp 1.0 msgid 00000000 cookie fe6e2baf61660328->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=4 (t: #1 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #2 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (vid: len=20 1e2b516905991c7d7c96fcbfb587e46100000002) 2000-11-22 02:53:02: remoteconf.c:131:getrmconf(): anonymous configuration selected for 192.168.0.1[500]. 2000-11-22 02:53:02: isakmp.c:856:isakmp_ph1begin_r(): new responder iph1 0x8099400: local 192.168.0.99 500 remote 192.168.0.1 500 2000-11-22 02:53:02: isakmp.c:860:isakmp_ph1begin_r(): === 2000-11-22 02:53:02: isakmp.c:863:isakmp_ph1begin_r(): begin Identity Protection mode. 2000-11-22 02:53:02: isakmp_ident.c:662:ident_r1recv(): begin. 2000-11-22 02:53:02: isakmp.c:1123:isakmp_parse(): begin. 2000-11-22 02:53:02: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=1(sa) 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=13(vid) 2000-11-22 02:53:02: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:02: isakmp.c:1131:isakmp_parse(): end. 2000-11-22 02:53:02: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:02: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:53:02: ipsec_doi.c:1021:get_proppair(): total SA len=160 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 2000-11-22 02:53:02: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=2(prop) 2000-11-22 02:53:02: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:02: ipsec_doi.c:1076:get_proppair(): proposal #1 len=152 2000-11-22 02:53:02: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:02: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:02: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:02: ipsec_doi.c:1220:get_transform(): transform #1 len=36 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:1220:get_transform(): transform #2 len=36 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:1220:get_transform(): transform #3 len=36 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:1220:get_transform(): transform #4 len=36 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 pair 1: 2000-11-22 02:53:02: proposal.c:877:print_proppair0(): 0x80aa2d0: next=0x0 tnext=0x80aa2e0 2000-11-22 02:53:02: proposal.c:877:print_proppair0(): 0x80aa2e0: next=0x0 tnext=0x80aa2f0 2000-11-22 02:53:02: proposal.c:877:print_proppair0(): 0x80aa2f0: next=0x0 tnext=0x80aa300 2000-11-22 02:53:02: proposal.c:877:print_proppair0(): 0x80aa300: next=0x0 tnext=0x0 2000-11-22 02:53:02: ipsec_doi.c:1157:get_proppair(): proposal #1: 4 transform 2000-11-22 02:53:02: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:02: ipsec_doi.c:289:get_ph1approvalx(): trns#=1, trns-id=IKE 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): Eà(]F@÷KgÀCÆO>ž¯òõN/ lorv=4 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:02: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:02: ipsec_doi.c:289:get_ph1approvalx(): trns#=2, trns-id=IKE 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:02: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:02: ipsec_doi.c:289:get_ph1approvalx(): trns#=3, trns-id=IKE 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:02: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:02: ipsec_doi.c:289:get_ph1approvalx(): trns#=4, trns-id=IKE 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:02: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:02: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:02: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:02: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:02: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. 2000-11-22 02:53:03: isakmp.c:207:isakmp_handler(): === 2000-11-22 02:53:03: isakmp.c:211:isakmp_handler(): 192.168.0.99[500] 216 bytes message received from 192.168.EàÜg@÷ž’ÀCÆO>žndšN>N´™oP"80 00000000 01100200 00000000 000000d8 0d0000a4 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 00000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000002 2000-11-22 02:53:03: isakmp.c:2152:isakmp_printpacket(): begin. 53:03.364853 192.168.0.1:500 -> 192.168.0.99:500: isakmp 1.0 msgid 00000000 cookie fe6e2baf61660328->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=4 (t: #1 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #2 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (vid: len=20 1e2b516905991c7d7c96fcbfb587e46100000002) 2000-11-22 02:53:03: remoteconf.c:131:getrmconf(): anonymous configuration selected for 192.168.0.1[500]. 2000-11-22 02:53:03: isakmp.c:856:isakmp_ph1begin_r(): new responder iph1 0x8099500: local 192.168.0.99 500 remote 192.168.0.1 500 2000-11-22 02:53:03: isakmp.c:860:isakmp_ph1begin_r(): === 2000-11-22 02:53:03: isakmp.c:863:isakmp_ph1begin_r(): begin Identity Protection mode. 2000-11-22 02:53:03: isakmp_ident.c:662:ident_r1recv(): begin. 2000-11-22 02:53:03: isakmp.c:1123:isakmp_parse(): begin. 2000-11-22 02:53:03: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=1(sa) 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=13(vid) 2000-11-22 02:53:03: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:03: isakmp.c:1131:isakmp_parse(): end. 2000-11-22 02:53:03: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:03: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:53:03: ipsec_doi.c:1021:get_proppair(): total SA len=160 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 2000-11-22 02:53:03: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=2(prop) 2000-11-22 02:53:03: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:03: ipsec_doi.c:1076:get_proppair(): proposal #1 len=152 2000-11-22 02:53:03: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:03: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:03: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:03: ipsec_doi.c:1220:get_transform(): transform #1 len=36 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:1220:get_transform(): transform #2 len=36 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:1220:get_transform(): transform #3 len=36 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:1220:get_transform(): transform #4 len=36 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 pair 1: 2000-11-22 02:53:03: proposal.c:877:print_proppair0(): 0x80aa310: next=0x0 tnext=0x80aa320 2000-11-22 02:53:03: proposal.c:877:print_proppair0(): 0x80aa320: next=0x0 tnext=0x80aa330 2000-11-22 02:53:03: proposal.c:877:print_proppair0(): 0x80aa330: next=0x0 tnext=0x80aa340 2000-11-22 02:53:03: proposal.c:877:print_proppair0(): 0x80aa340: next=0x0 tnext=0x0 2000-11-22 02:53:03: ipsec_doi.c:1157:get_proppair(): proposal #1: 4 transform 2000-11-22 02:53:03: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:03: ipsec_doi.c:289:get_ph1approvalx(): trns#=1, trns-id=IKE 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:03: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:03: ipsec_doi.c:289:get_ph1approvalx(): trns#=2, trns-id=IKE 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:03: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:03: ipsec_doi.c:289:get_ph1approvalx(): trns#=3, trns-id=IKE 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:03: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:03: ipsec_doi.c:289:get_ph1approvalx(): trns#=4, trns-id=IKE 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:03: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:03: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:03: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:03: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:03: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. 2000-11-22 02:53:05: isakmp.c:207:isakmp_handler(): === 2000-11-22 02:53:05: isakmp.c:211:isakmp_handler(): 192.168.0.99[500] 216 bytes message received from 192.168.0.1[500] fe6e2baf 61660328 00000000 00000000 01100200 00000000 000000d8 0d0000a4 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 00000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000002 2000-11-22 02:53:05: isakmp.c:2152:isakmp_printpacket(): begin. 53:05.394810 192.168.0.1:500 -> 192.168.0.99:500: isakmp 1.0 msgid 00000000 cookie fe6e2baf61660328->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=4 (t: #1 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #2 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (vid: len=20 1e2b516905991c7d7c96fcbfb587e46100000002) 2000-11-22 02:53:05: remoteconf.c:131:getrmconf(): anonymous configuration selected for 192.168.0.1[500]. 2000-11-22 02:53:05: isakmp.c:856:isakmp_ph1begin_r(): new responder iph1 0x8099600: local 192.168.0.99 500 remote 192.168.0.1 500 2000-11-22 02:53:05: isakmp.c:860:isakmp_ph1begin_r(): === 2000-11-22 02:53:05: isakmp.c:863:isakmp_ph1begin_r(): begin Identity Protection mode. 2000-11-22 02:53:05: isakmp_ident.c:662:ident_r1recv(): begin. 2000-11-22 02:53:05: isakmp.c:1123:isakmp_parse(): begin. 2000-11-22 02:53:05: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=1(sa) 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=13(vid) 2000-11-22 02:53:05: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:05: isakmp.c:1131:isakmp_parse(): end. 2000-11-22 02:53:05: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:05: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:53:05: ipsec_doi.c:1021:get_proppair(): total SA len=160 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 2000-11-22 02:53:05: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=2(prop) 2000-11-22 02:53:05: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:05: ipsec_doi.c:1076:get_proppair(): proposal #1 len=152 2000-11-22 02:53:05: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:05: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:05: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:05: ipsec_doi.c:1220:get_transform(): transform #1 len=36 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:1220:get_transform(): transform #2 len=36 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:1220:get_transform(): transform #3 len=36 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:1220:get_transform(): transform #4 len=36 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 pair 1: 2000-11-22 02:53:05: proposal.c:877:print_proppair0(): 0x80aa350: next=0x0 tnext=0x80aa360 2000-11-22 02:53:05: proposal.c:877:print_proppair0(): 0x80aa360: next=0x0 tnext=0x80aa370 2000-11-22 02:53:05: proposal.c:877:print_proppair0(): 0x80aa370: next=0x0 tnext=0x80aa380 2000-11-22 02:53:05: proposal.c:877:print_proppair0(): 0x80aa380: next=0x0 tnext=0x0 2000-11-22 02:53:05: ipsec_doi.c:1157:get_proppair(): proposal #1: 4 transform 2000-11-22 02:53:05: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:05: ipsec_doi.c:289:get_ph1approvalx(): trns#=1, trns-id=IKE 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:05: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:05: ipsec_doi.c:289:get_ph1approvalx(): trns#=2, trns-id=IKE 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:05: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:05: ipsec_doi.c:289:get_ph1approvalx(): trns#=3, trns-id=IKE 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:05: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:05: ipsec_doi.c:289:get_ph1approvalx(): trns#=4, trns-id=IKE 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:05: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:05: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:05: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:05: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:05: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. 2000-11-22 02:53:09: isakmp.c:207:isakmp_handler(): === 2000-11-22 02:53:09: isakmp.c:211:isakmp_handler(): 192.168.0.99[500] 216 bytes message received from 192.168.0.1[500] fe6e2baf 61660328 00000000 00000000 01100200 00000000 000000d8 0d0000a4 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 00000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000002 2000-11-22 02:53:09: isakmp.c:2152:isakmp_printpacket(): begin. 53:09.396907 192.168.0.1:500 -> 192.168.0.99:500: isakmp 1.0 msgid 00000000 cookie fe6e2baf61660328->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=4 (t: #1 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #2 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (vid: len=20 1e2b516905991c7d7c96fcbfb587e46100000002) 2000-11-22 02:53:09: remoteconf.c:131:getrmconf(): anonymous configuration selected for 192.168.0.1[500]. 2000-11-22 02:53:09: isakmp.c:856:isakmp_ph1begin_r(): new responder iph1 0x8099700: local 192.168.0.99 500 remote 192.168.0.1 500 2000-11-22 02:53:09: isakmp.c:860:isakmp_ph1begin_r(): === 2000-11-22 02:53:09: isakmp.c:863:isakmp_ph1begin_r(): begin Identity Protection mode. 2000-11-22 02:53:09: isakmp_ident.c:662:ident_r1recv(): begin. 2000-11-22 02:53:09: isakmp.c:1123:isakmp_parse(): begin. 2000-11-22 02:53:09: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=1(sa) 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=13(vid) 2000-11-22 02:53:09: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:09: isakmp.c:1131:isakmp_parse(): end. 2000-11-22 02:53:09: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:09: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:53:09: ipsec_doi.c:1021:get_proppair(): total SA len=160 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 2000-11-22 02:53:09: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=2(prop) 2000-11-22 02:53:09: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:09: ipsec_doi.c:1076:get_proppair(): proposal #1 len=152 2000-11-22 02:53:09: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:09: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:09: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:09: ipsec_doi.c:1220:get_transform(): transform #1 len=36 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:1220:get_transform(): transform #2 len=36 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:1220:get_transform(): transform #3 len=36 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:1220:get_transform(): transform #4 len=36 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 pair 1: 2000-11-22 02:53:09: proposal.c:877:print_proppair0(): 0x80aa390: next=0x0 tnext=0x80aa3a0 2000-11-22 02:53:09: proposal.c:877:print_proppair0(): 0x80aa3a0: next=0x0 tnext=0x80aa3b0 2000-11-22 02:53:09: proposal.c:877:print_proppair0(): 0x80aa3b0: next=0x0 tnext=0x80aa3c0 2000-11-22 02:53:09: proposal.c:877:print_proppair0(): 0x80aa3c0: next=0x0 tnext=0x0 2000-11-22 02:53:09: ipsec_doi.c:1157:get_proppair(): proposal #1: 4 transform 2000-11-22 02:53:09: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:09: ipsec_doi.c:289:get_ph1approvalx(): trns#=1, trns-id=IKE 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Encryption AlgEà(]i@÷KDÀCÆO>ž¯òõNÏËC 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:09: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:09: ipsec_doi.c:289:get_ph1approvalx(): trns#=2, trns-id=IKE 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:09: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:09: ipsec_doi.c:289:get_ph1approvalx(): trns#=3, trns-id=IKE 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:09: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:09: ipsec_doi.c:289:get_ph1approvalx(): trns#=4, trns-id=IKE 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:09: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:09: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:09: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:09: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:09: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. 2000-11-22 02:53:17: isakmp.c:207:isakmp_handler(): === 2000-11-22 02:53:17: isakmp.c:211:isakmp_handler(): 192.168.0.99[500] 216 bytes message received from 192.168.0.1[500] fe6e2baf 61660328 00000000 00000000 01100200 00000000 000000d8 0d0000a4 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 00000018 1e2b5169 05991c7d 7c96fcbf b587e461 00000002 2000-11-22 02:53:17: isakmp.c:2152:isakmp_printpacket(): begin. 53:17.389391 192.168.0.1:500 -> 192.168.0.99:500: isakmp 1.0 msgid 00000000 cookie fe6e2baf61660328->0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=4 (t: #1 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #2 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)) (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=group desc value=modp768)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (vid: len=20 1e2b516905991c7d7c96fcbfb587e46100000002) 2000-11-22 02:53:17: remoteconf.c:131:getrmconf(): anonymous configuration selected for 192.168.0.1[500]. 2000-11-22 02:53:17: isakmp.c:856:isakmp_ph1begin_r(): new responder iph1 0x8099800: local 192.168.0.99 500 remote 192.168.0.1 500 2000-11-22 02:53:17: isakmp.c:860:isakmp_ph1begin_r(): === 2000-11-22 02:53:17: isakmp.c:863:isakmp_ph1begin_r(): begin Identity Protection mode. 2000-11-22 02:53:17: isakmp_ident.c:662:ident_r1recv(): begin. 2000-11-22 02:53:17: isakmp.c:1123:isakmp_parse(): begin. 2000-11-22 02:53:17: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=1(sa) 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=13(vid) 2000-11-22 02:53:17: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:17: isakmp.c:1131:isakmp_parse(): end. 2000-11-22 02:53:17: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. 2000-11-22 02:53:17: vendorid.c:97:check_vendorid(): Vendor ID mismatch. 2000-11-22 02:53:17: ipsec_doi.c:1021:get_proppair(): total SA len=160 00000001 00000001 00000098 01010004 03000024 01010000 80010001 80020002 80040002 80030001 800b0001 000c0004 00007080 03000024 02010000 80010001 80020001 80040002 80030001 800b0001 000c0004 00007080 03000024 03010000 80010001 80020002 80040001 80030001 800b0001 000c0004 00007080 00000024 04010000 80010001 80020001 80040001 80030001 800b0001 000c0004 00007080 2000-11-22 02:53:17: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=2(prop) 2000-11-22 02:53:17: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:17: ipsec_doi.c:1076:get_proppair(): proposal #1 len=152 2000-11-22 02:53:17: isakmp.c:1035:isakmp_parsewoh(): begin. 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:17: isakmp.c:1066:isakmp_parsewoh(): seen nptype=3(trns) 2000-11-22 02:53:17: isakmp.c:1104:isakmp_parsewoh(): succeed. 2000-11-22 02:53:17: ipsec_doi.c:1220:get_transform(): transform #1 len=36 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:1220:get_transform(): transform #2 len=36 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:1220:get_transform(): transform #3 len=36 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:1220:get_transform(): transform #4 len=36 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:1781:check_attr_isakmp(): type=Life Duration, flag=0x0000, lorv=4 pair 1: 2000-11-22 02:53:17: proposal.c:877:print_proppair0(): 0x80aa3d0: next=0x0 tnext=0x80aa3e0 2000-11-22 02:53:17: proposal.c:877:print_proppair0(): 0x80aa3e0: next=0x0 tnext=0x80aa3f0 2000-11-22 02:53:17: proposal.c:877:print_proppair0(): 0x80aa3f0: next=0x0 tnext=0x80aa400 2000-11-22 02:53:17: proposal.c:877:print_proppair0(): 0x80aa400: next=0x0 tnext=0x0 2000-11-22 02:53:17: ipsec_doi.c:1157:get_proppair(): proposal #1: 4 transform 2000-11-22 02:53:17: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:17: ipsec_doi.c:289:get_ph1approvalx(): trns#=1, trns-id=IKE 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:17: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:17: ipsec_doi.c:289:get_ph1approvalx(): trns#=2, trns-id=IKE 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:17: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:17: ipsec_doi.c:289:get_ph1approvalx(): trns#=3, trns-id=IKE 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:SHA 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:17: ipsec_doi.c:283:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=4 2000-11-22 02:53:17: ipsec_doi.c:289:get_ph1approvalx(): trns#=4, trns-id=IKE 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=MD5 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds 2000-11-22 02:53:17: ipsec_doi.c:389:t2isakmpsa(): type=Life Duration, flag=0x0000, lorv=4 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): Compared: DB:Peer 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifetime = 60:28800) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (lifebyte = 5120:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): enctype = 3DES-CBC:DES-CBC 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): (encklen = 0:0) 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): hashtype = SHA:MD5 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key 2000-11-22 02:53:17: ipsec_doi.c:323:get_ph1approvalx(): dh_group = 1024-bit MODP group:768-bit MODP group 2000-11-22 02:53:17: ipsec_doi.c:344:get_ph1approvalx(): unacceptable proposal. 2000-11-22 02:53:17: isakmp_ident.c:721:ident_r1recv(): 192.168.0.1[500] failed to get valid proposal. 2000-11-22 02:53:17: isakmp.c:874:isakmp_ph1begin_r(): 192.168.0.1[500] failed to process packet. 2000-11-22 02:53:27: session.c:262:check_sigreq(): caught signal 2 2000-11-22 02:53:27: pfkey.c:192:pfkey_handler(): get pfkey FLUSH message sadb_msg{ version=2 type=9 errno=0 satype=0 len=2 reserved=0 seq=0 pid=2357 2000-11-22 02:53:28: pfkey.c:270:pfkey_dump_sadb(): call pfkey_send_dump JT> josh Please help me i have no idea what to do next -((( The passwords are all the same on both machines. -- Best regards, Boris mailto:koester@x-itec.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 18: 1:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 12DA337B4C5 for ; Tue, 21 Nov 2000 18:01:12 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA22618; Wed, 22 Nov 2000 11:01:03 +0900 (JST) To: "Joe.Eggleston" Cc: freebsd-net@FreeBSD.ORG In-reply-to: Joe_Eggleston-CJE136's message of Tue, 21 Nov 2000 17:03:42 CST. <3A1AFF4E.D1FBD5F5@labs.mot.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 From: itojun@iijlab.net Date: Wed, 22 Nov 2000 11:01:03 +0900 Message-ID: <22616.974858463@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm currently trying to decide what open source OS to use for some IPv6 >development. If anyone on this list has used both FreeBSD and Linux for >IPv6, could you let me know what your sense is about how the IPv6 >implementations compare (as far as stability, ease of setup, complete >functionality...). http://www.tahi.org/ has conformance test results, so the webpage can be some reference for functionality POV. http://www.kame.net/dev/cvsweb.cgi/kame/COVERAGE has some idea about functionality comparison between *BSD systems. >Also, does anyone know of a Mobile IPv6 implementation for FreeBSD? the latest kame kit from http://www.kame.net/ has mobile-ip6 code, though it may need some torture-tests. (it is not in freebsd as it is not tested enough yet) itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 19:25:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id DA29237B4CF for ; Tue, 21 Nov 2000 19:25:12 -0800 (PST) Received: by mail.snickers.org (Postfix, from userid 66) id B18243D37; Tue, 21 Nov 2000 22:25:11 -0500 (EST) Received: by asherah.dyndns.org (Postfix, from userid 701954) id 904D234503; Tue, 21 Nov 2000 22:25:00 -0500 (EST) Date: Tue, 21 Nov 2000 22:24:59 -0500 From: Josh Tiefenbach To: freebsd-net@freebsd.org Subject: IPsec mini HOWTO Message-ID: <20001121222459.A43748@zipperup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Due to popular demand, I've committed my experiences in getting IPsec to work, both between 2 FreeBSD boxes, and between a FreeBSD box and a Win2k box, to paper. You can find it at http://asherah.dyndns.org/~josh/ipsec-howto.txt While I plan to eventually tidy this up considerably, and find a doc guy to stick it into the handbook or FAQ, I felt that people could benefit from this writeup in the meantime. Feel free to point out any inaccuracies/problems/complaints to me. josh -- This email has been brought to you by the letters U, U, C, and P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 19:40:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 9A1CF37B479 for ; Tue, 21 Nov 2000 19:40:12 -0800 (PST) Received: by mail.snickers.org (Postfix, from userid 66) id AA71B3D35; Tue, 21 Nov 2000 22:40:11 -0500 (EST) Received: by asherah.dyndns.org (Postfix, from userid 701954) id B8C743450A; Tue, 21 Nov 2000 22:35:34 -0500 (EST) Date: Tue, 21 Nov 2000 22:35:33 -0500 From: Josh Tiefenbach To: Boris Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Win2k Message-ID: <20001121223533.B43748@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> <1563982125.20001122005041@x-itec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1563982125.20001122005041@x-itec.de>; from koester@x-itec.de on Wed, Nov 22, 2000 at 12:50:41AM -0800 Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > spdadd 192.168.0.99/32 192.168.0.1 any -P out ipsec ^^^^^^^^^^^ This should probably be 192.168.0.1/32, but I dont think that has any effect on the prblem your seeing. > But racoon gives me a lot of error messages, i have added the messages > here. I really do not know what to do now -(((((((((( > > Snapshot: > 2000-11-22 02:53:09: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. > 2000-11-22 02:53:09: vendorid.c:97:check_vendorid(): Vendor ID mismatch. Urk. I just grepped thru the logs I had, and I dont see any message like this. I'm not sure whats causing this, or if this is really your problem. However, I see a whole bunch of 'unacceptable proposal' messages in there. Are you sure that you've configured racoon to offer the same hash/encryption type as Win2k. It seems, i think, that your Win2k machine is requesting single-DES, while the FreeBSD machine only wants to do 3DES. josh -- This email has been brought to you by the letters U, U, C, and P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 19:54:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id E0E4237B663 for ; Tue, 21 Nov 2000 19:54:25 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA24232; Wed, 22 Nov 2000 12:52:39 +0900 (JST) To: Josh Tiefenbach Cc: Boris , freebsd-net@FreeBSD.ORG In-reply-to: josh's message of Tue, 21 Nov 2000 22:35:33 EST. <20001121223533.B43748@zipperup.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC Win2k From: itojun@iijlab.net Date: Wed, 22 Nov 2000 12:52:39 +0900 Message-ID: <24230.974865159@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> But racoon gives me a lot of error messages, i have added the messages >> here. I really do not know what to do now -(((((((((( >> >> Snapshot: >> 2000-11-22 02:53:09: isakmp_ident.c:700:ident_r1recv(): 192.168.0.1[500] peer transmitted Vendor ID. >> 2000-11-22 02:53:09: vendorid.c:97:check_vendorid(): Vendor ID mismatch. > >Urk. I just grepped thru the logs I had, and I dont see any message like this. >I'm not sure whats causing this, or if this is really your problem. it (vendor id mismatch) does not matter. the field exists (specwise) just to detect if we are using the same implementation on both end, and if we do, enable certain tweak or something like that. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 21 22:48:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from ami4000.hei.co.kr (unknown [202.30.128.31]) by hub.freebsd.org (Postfix) with ESMTP id 4B48937B4D7 for ; Tue, 21 Nov 2000 22:48:18 -0800 (PST) Received: from ami4000.hei.co.kr (localhost [127.0.0.1]) by ami4000.hei.co.kr (8.11.0/8.9.3) with ESMTP id eAM6lQr15160 for ; Wed, 22 Nov 2000 15:47:26 +0900 (KST) Received: from hei.co.kr ([192.168.203.45]) by ami4000.hei.co.kr (8.11.0/8.9.3) with ESMTP id eAM6jLn13690 for ; Wed, 22 Nov 2000 15:45:29 +0900 (KST) Message-ID: <3A1B6AF3.54999C2E@hei.co.kr> Date: Wed, 22 Nov 2000 15:42:59 +0900 From: Lee jong oh X-Mailer: Mozilla 4.7 [ko] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: ko MIME-Version: 1.0 To: net@FreeBSD.org Subject: How to participate in this Forum Content-Type: multipart/alternative; boundary="------------405360AE1DD91B0C879938DE" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------405360AE1DD91B0C879938DE Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit How are you? I am working at Hyundai Electronic Co. in South Korea. I am very intereted in developing chips related network. So, I want to receive mail which is related to TCP/IP protocol. For example, I will send you an mail which I found at http://lists.openresources.com/FreeBSD/freebsd-net. Looking for ETH NIC with real MII connector.. To: net@FreeBSD.ORG Subject: Looking for ETH NIC with real MII connector.. From: "Kevin J. Rowett" Date: Mon, 01 Feb 1999 14:38:50 -0800 Sender: owner-freebsd-net@FreeBSD.ORG I'm looking for a PCI based Ethernet NIC that has a real MII connector on it. Does anyone know of a card still made with such? I'm developing some unusual PHY arrangements and need an easy way to test, w/o having to build and debug the entire PCI card and MAC. I want to receive these kinds of mail. Help me. ---------------------------------------- Lee Jong Oh Associate Research Engineer MCU Design Team 2 SP BU/System IC SBU TEL : 02-3459-3329 FAX : 02-3459-4696 E-mail : leejo@hei.co.kr H.P : 011-554-6801 Homepage : http://my.netian.com/~leejongo __________________________________________ --------------405360AE1DD91B0C879938DE Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit How are you?
I am working at Hyundai Electronic Co. in South Korea.
I am very intereted in developing chips related network.
So, I want to receive mail which is related to TCP/IP protocol.
For example, I will send you an mail which I found at http://lists.openresources.com/FreeBSD/freebsd-net.
Looking for ETH NIC with real MII connector..

 To: net@FreeBSD.ORG
 Subject: Looking for ETH NIC with real MII connector..
 From: "Kevin J. Rowett" <krowett@rowett.org>
 Date: Mon, 01 Feb 1999 14:38:50 -0800
 Sender: owner-freebsd-net@FreeBSD.ORG

I'm looking for a PCI based Ethernet NIC that has a real MII connector
on it.  Does anyone know of a card still made with such?
I'm developing some unusual PHY arrangements and need an easy way to test,
w/o having to build and debug the entire PCI card and MAC.

I want to receive these kinds of mail.
Help me. 

----------------------------------------
Lee Jong Oh 
Associate Research Engineer
MCU Design Team 2 SP BU/System IC SBU
TEL : 02-3459-3329  FAX : 02-3459-4696
E-mail : leejo@hei.co.kr
H.P : 011-554-6801            
Homepage : http://my.netian.com/~leejongo
__________________________________________
  --------------405360AE1DD91B0C879938DE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 3:31: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 98B8F37B4D7 for ; Wed, 22 Nov 2000 03:30:57 -0800 (PST) Received: from localhost.localdom (p3E9E1510.dip.t-dialin.net [62.158.21.16]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id MAA07630; Wed, 22 Nov 2000 12:30:47 +0100 (MET) Received: from masterpc (master [192.168.0.1]) by localhost.localdom (8.11.1/8.11.1) with ESMTP id eAMDSD300644; Wed, 22 Nov 2000 14:28:13 +0100 (CET) Date: Wed, 22 Nov 2000 12:13:40 -0800 From: Boris X-Mailer: The Bat! (v1.46d) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <3144961691.20001122121340@x-itec.de> To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re[2]: IPSEC Win2k In-reply-To: <20001121223533.B43748@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> <1563982125.20001122005041@x-itec.de> <20001121223533.B43748@zipperup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Josh, Tuesday, November 21, 2000, 7:35:33 PM, you wrote: >> spdadd 192.168.0.99/32 192.168.0.1 any -P out ipsec JT> ^^^^^^^^^^^ JT> This should probably be 192.168.0.1/32, but I dont think that has any effect JT> on the prblem your seeing. To avoid any problems, i have corrected this. JT> However, I see a whole bunch of 'unacceptable proposal' messages in there. Are JT> you sure that you've configured racoon to offer the same hash/encryption type JT> as Win2k. It seems, i think, that your Win2k machine is requesting single-DES, JT> while the FreeBSD machine only wants to do 3DES. I really tried everything since a week or so and i have found no solution. I can´t get it up running. It is very frustrating. I will show you all my complete configuration now, i can´t find anything wrong. Here is my racoon.conf, a little bit modificated. Maybe is there something wrong, but i do not think so: ----------------- [ racoon.conf ] ------------------------- #path include "/usr/local/etc/racoon" ; #include "remote.conf" ; # search this file for pre_shared_key with various ID key. #bk path pre_shared_key "/etc/psk.txt" ; # racoon will look for certificate file in the directory, # if the certificate/certificate request payload is received. path certificate "/usr/local/etc/cert" ; # "log" specifies logging level. It is followed by either "info", "notify", # "debug" or "debug2". log debug4; # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off;# enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { #isakmp ::1 [7000]; #isakmp 202.249.11.124 [500]; #admin [7002]; # administrative's port by kmpstat. #strict_address; # required all addresses must be bound. } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 15 sec; } remote anonymous { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; #my_identifier address; #my_identifier address "192.168.0.99"; ##peers_identifier address "192.168.0.1"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; lifetime time 1 min; # sec,min,hour lifetime byte 5 MB; # B,KB,GB initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 3600 sec; lifetime byte 5000 KB; encryption_algorithm 3des,des,cast128,blowfish ; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate ; } -------------------- [kernel settings] ------------------- .... #bk options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security ... ----------------------- [ initial bash script ] --------------- #! /bin/sh # setkey -FP # Note. This and the next line will delete all previous SPD setkey -F # entries. setkey -c << EOF spdadd 192.168.0.99/32 192.168.0.1/32 any -P out ipsec esp/transport/192.168.0.99-192.168.0.1/require; spdadd 192.168.0.1/32 192.168.0.99/32 any -P in ipsec esp/transport/192.168.0.1-192.168.0.99/require; ------------------------------------------------ At this point i think we need 3des and md5. But even DES does not work. I have used a lot of combinations for the security settings on my win2k box. This is the current configuration. One rule for all traffic (i have removed the other ones because they did not want work, too and i wanted to try all combinations manually). * Require Security Security method: unchecked: data and address integrity (AH) checked: ESP with integrity: md5 and encryption: 3des Session key settings: unchecked at this moment I can´t figure out any solutions -((((( JT> josh -- Best regards, Boris mailto:koester@x-itec.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 3:40: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 2720237B4CF for ; Wed, 22 Nov 2000 03:40:04 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAMBfEx06157; Wed, 22 Nov 2000 03:41:14 -0800 (PST) (envelope-from kris) Date: Wed, 22 Nov 2000 03:41:14 -0800 From: Kris Kennaway To: Josh Tiefenbach Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: IPSEC Win2k Message-ID: <20001122034114.A6092@citusc17.usc.edu> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> <200011211805.NAA36395@khavrinen.lcs.mit.edu> <20001121140305.G37765@zipperup.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121140305.G37765@zipperup.org>; from josh@zipperup.org on Tue, Nov 21, 2000 at 02:03:05PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 21, 2000 at 02:03:05PM -0500, Josh Tiefenbach wrote: > > Can I be so forward as to suggest that this is exactly the sort of > > thing that really ought to go into the handbook and/or FAQ? >=20 > Hrmmm. I'll try to kick some time free later tonite and throw together > something suitable for a PR. Thanks! > Just so its in the archives, I should point out that NetBSD's IPsec > documentation is, while not great, scads better that whats currently in t= he > handbook. A "port" of this to FreeBSD for the handbook (i.e. making sure all of the information is accurate for FreeBSD) would also be great. Kris --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjobsNoACgkQWry0BWjoQKVTFgCg30BEGDpk8v+5CDPzvkT8FlOM faoAn1z+VwEF0UoFxqQvJFycnaB4wEZg =u4hs -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 4:17:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 30BE237B4CF for ; Wed, 22 Nov 2000 04:17:19 -0800 (PST) Received: from localhost.localdom (p3E9D3D90.dip.t-dialin.net [62.157.61.144]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id NAA20163; Wed, 22 Nov 2000 13:17:18 +0100 (MET) Received: from masterpc (master [192.168.0.1]) by localhost.localdom (8.11.1/8.11.1) with ESMTP id eAMEVK300825; Wed, 22 Nov 2000 15:31:20 +0100 (CET) Date: Wed, 22 Nov 2000 13:16:49 -0800 From: Boris X-Mailer: The Bat! (v1.46d) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <302422853.20001122131649@x-itec.de> To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re[2]: IPSEC Win2k In-reply-To: <20001121223533.B43748@zipperup.org> References: <838997467.20001121113524@x-itec.de> <20001121124847.F37765@zipperup.org> <1563982125.20001122005041@x-itec.de> <20001121223533.B43748@zipperup.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Josh, Tuesday, November 21, 2000, 7:35:33 PM, you wrote: Josh i have found the solution! Is it possible to write the ipsec-mini-howto with you together, i think i can make some additions and hints to it now!!!!! My english is not the best but maybe someone can correct my misspellings!!! I hope to hear from you soon! -- Best regards, Boris mailto:koester@x-itec.de MCSE, CNA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 9:31:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp-server.tampabay.rr.com (unknown [65.32.2.68]) by hub.freebsd.org (Postfix) with ESMTP id 159CE37B4C5 for ; Wed, 22 Nov 2000 09:31:50 -0800 (PST) Received: from Phiber.cfl.rr.com (33.146.166.rrcentralflorida.cfl.rr.com [65.33.146.166]) by smtp-server.tampabay.rr.com (8.9.3/8.9.3) with ESMTP id MAA04957 for ; Wed, 22 Nov 2000 12:31:49 -0500 (EST) Message-Id: <4.3.2.7.2.20001122123642.046d3200@mail.hack3r.com> X-Sender: Robby@pop-server.cfl.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Nov 2000 12:41:07 -0800 To: freebsd-net@freebsd.org From: Robby Subject: setting up the ftpd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently installed freeBSD on my home network. I am behind a linksys router with one windows 2k machine and one windows 98 machine. I am trying to configure and FTP server from my BSD box. I can ftp localhost, but when I try to connect to it from any other computer it says connection refused. I configured the properties on the router to set my BSD box to DMZ host as well as forwarding port 21. I don't know what else to do, and I am sure that theres a simple solution to my problem. I would appreciate any help. Thanks in advance Robby To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 13: 1:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id D9DDC37B479 for ; Wed, 22 Nov 2000 13:01:37 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4G006LF2EJQY@falla.videotron.net> for freebsd-net@freebsd.org; Wed, 22 Nov 2000 16:01:35 -0500 (EST) Date: Wed, 22 Nov 2000 16:01:52 -0500 (EST) From: Bosko Milekic Subject: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 In-reply-to: <20001122002157.A5078@crow.dom2ip.de> To: Thomas Moestl , cuk@cuk.nu, rizzo@aciri.org Cc: freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Thomas, Marko, others, Thomas, I have looked at and reviewed your patch, and have added one hunk to bridge.c, please take a look at the "almost ready for commit" version here: http://people.FreeBSD.org/~bmilekic/dumbridge.diff Basically, I don't like the fact that we have to copy the ethernet header back into the mbuf for dummynet in bdg_forward(), especially since we just removed it before calling bdg_forward(). But, this is no fault of yours and since dummynet does expect it, I agree with the present fix. I'd like to ask net@ and Luigi to also review this before I commit it, and I'd like to ask Marko Cuk (and others?) to test it and confirm once again that it indeed fixes their problems, just so I can close all the PRs along with it. Thanks, Thomas! On Wed, 22 Nov 2000, Thomas Moestl wrote: > Well, the first attempt I sent last week did apparently fix the panics, but > there was another logical error, this time in bridge.c: dummynet expects > an ehternet header at the start of the mbuf, but the bridging code did > not place it there. I wrote a second patch a week ago, and sent it to > Marko Cuk, who had asked for it. Looking into freebsd-net, I see that > Lachlan O'Dea has come to the same conclusion. > > Marko Cuk has apparently not tested the patch yet, but term@rmci.net has > filed a bug report (kern/23010) today about very much the same thing. He > has reported success with my patch, so I thought it might be time to > try to get it in, so I have attached it ;-) > > This should close the PRs kern/21534, kern/23010 and (probably only partly) > kern/19551. Marko Cuk's problem seems to be exactly the same to me: > he also uses pipe firewall rules, and the panics happened when he activated > the firewalling for bridging. He also reported partial success (no more > panics) with my first patch. > > So, to come to a conclusion: could you please review (and perhaps commit) the > patch or refer me to right person to bug about it? > > Thanks for your time, > - Thomas Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 14:15:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from fat.ti.ru (fat.ti.ru [212.1.224.35]) by hub.freebsd.org (Postfix) with ESMTP id AF9DA37B4CF for ; Wed, 22 Nov 2000 14:15:35 -0800 (PST) Received: from martin (hilldale.kurgan.ru [212.1.224.61]) by fat.ti.ru (Postfix) with ESMTP id B9D64D938 for ; Thu, 23 Nov 2000 01:15:28 +0300 (MSK) Date: Thu, 23 Nov 2000 01:15:31 +0300 From: Martin McFlySr X-Mailer: The Bat! (v1.47 Halloween Edition) Business Reply-To: Martin McFlySr Organization: Back To The Future X-Priority: 3 (Normal) Message-ID: <78120708860.20001123011531@McFlySr.Kurgan.Ru> To: net@FreeBSD.ORG Subject: how can i ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello net@FreeBSD.ORG, how can i connect freebsd (on client side) to freebsd (server) via pptp? On server installed mpd-3.2. Thank you, -- Thursday, November 23, 2000, 01:14 Best regards from future, Martin McFlySr, HillDale. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 14:17:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 6267937B4C5 for ; Wed, 22 Nov 2000 14:17:19 -0800 (PST) Received: (qmail 13190 invoked by uid 0); 22 Nov 2000 22:17:16 -0000 Received: from pc19e9625.dip.t-dialin.net (HELO forge.local) (193.158.150.37) by mail.gmx.net (mail06) with SMTP; 22 Nov 2000 22:17:16 -0000 Received: from thomas by forge.local with local (Exim 3.12 #1 (Debian)) id 13yiBh-00012L-00 for ; Wed, 22 Nov 2000 23:16:21 +0100 Date: Wed, 22 Nov 2000 23:16:21 +0100 From: Thomas Moestl To: freebsd-net@freebsd.org Subject: Re: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 Message-ID: <20001122231621.A3790@crow.dom2ip.de> Mail-Followup-To: Thomas Moestl , freebsd-net@freebsd.org References: <20001122002157.A5078@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bmilekic@technokratis.com on Wed, Nov 22, 2000 at 04:01:52PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thomas, I have looked at and reviewed your patch, and have added one > hunk to bridge.c, please take a look at the "almost ready for commit" > version here: > http://people.FreeBSD.org/~bmilekic/dumbridge.diff Oops, yes, I have missed that one. Luckily, it "shouldn't happen". > Basically, I don't like the fact that we have to copy the ethernet > header back into the mbuf for dummynet in bdg_forward(), especially since > we just removed it before calling bdg_forward(). But, this is no fault of > yours and since dummynet does expect it, I agree with the present fix. I agree to you that this prepending and removing is not nice. A way to solve this would of course be to change bdg_forward so that it does not get the ethernet header separately. This would however require that the header be prepended in ether_input. That that might slow down the most common case of bridging (forwarding a packet from another host to another interface, not using dummynet), because in this case the header is prepended to a copy in bdg_forward. Anyway, that change would be to large for a bugfix that can be merged relatively soon, I think ;-) > I'd like to ask net@ and Luigi to also review this before I commit > it, and I'd like to ask Marko Cuk (and others?) to test it and confirm > once again that it indeed fixes their problems, just so I can close all > the PRs along with it. OK. - Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 21: 3:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id C728537B4D7 for ; Wed, 22 Nov 2000 21:03:30 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAN54da21978; Wed, 22 Nov 2000 21:04:39 -0800 (PST) (envelope-from kris) Date: Wed, 22 Nov 2000 21:04:38 -0800 From: Kris Kennaway To: Martin McFlySr Cc: net@FreeBSD.ORG Subject: Re: how can i ... Message-ID: <20001122210438.A21910@citusc17.usc.edu> References: <78120708860.20001123011531@McFlySr.Kurgan.Ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <78120708860.20001123011531@McFlySr.Kurgan.Ru>; from Martin@McFlySr.Kurgan.Ru on Thu, Nov 23, 2000 at 01:15:31AM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 23, 2000 at 01:15:31AM +0300, Martin McFlySr wrote: > Hello net@FreeBSD.ORG, >=20 > how can i connect freebsd (on client side) to freebsd (server) via pptp? > On server installed mpd-3.2. Please check the mailing list archives - it is a frequently asked question. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjocpWYACgkQWry0BWjoQKVq6wCfWV5PlOT0ThlSr7CciY9pima4 mPsAoNVRg5Ejc0AVFD42nbRdpz7z/CA4 =6uic -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 21:13:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id D141637B4CF for ; Wed, 22 Nov 2000 21:13:42 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id eAN5DJh01421; Wed, 22 Nov 2000 21:13:19 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200011230513.eAN5DJh01421@iguana.aciri.org> Subject: Re: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 In-Reply-To: from Bosko Milekic at "Nov 22, 2000 4: 1:52 pm" To: bmilekic@technokratis.com (Bosko Milekic) Date: Wed, 22 Nov 2000 21:13:19 -0800 (PST) Cc: tmoestl@gmx.net, cuk@cuk.nu, rizzo@aciri.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thomas, I have looked at and reviewed your patch, and have added one > hunk to bridge.c, please take a look at the "almost ready for commit" > version here: > > http://people.FreeBSD.org/~bmilekic/dumbridge.diff sounds ok to me (modulo testing). > Basically, I don't like the fact that we have to copy the ethernet > header back into the mbuf for dummynet in bdg_forward(), especially since > we just removed it before calling bdg_forward(). But, this is no fault of this was also part of my criticism to the original changes. I posted a suggestion for keeping the ethernet header together with the mbuf when calling ether_input() (in case, define a new function ether_input2() if backward compatibility was a concern) to avoid the need for M_PREPEND, and also (probably) to save some code in the in the individual drivers where the ethernet splitting is replicated and could be centralized in ether_input2(). But this is some change that now would require a lot of work in touching the individual drivers. thanks Bosko and Thomas for your work cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- > yours and since dummynet does expect it, I agree with the present fix. > > I'd like to ask net@ and Luigi to also review this before I commit > it, and I'd like to ask Marko Cuk (and others?) to test it and confirm > once again that it indeed fixes their problems, just so I can close all > the PRs along with it. > > Thanks, Thomas! > > On Wed, 22 Nov 2000, Thomas Moestl wrote: > > > Well, the first attempt I sent last week did apparently fix the panics, but > > there was another logical error, this time in bridge.c: dummynet expects > > an ehternet header at the start of the mbuf, but the bridging code did > > not place it there. I wrote a second patch a week ago, and sent it to > > Marko Cuk, who had asked for it. Looking into freebsd-net, I see that > > Lachlan O'Dea has come to the same conclusion. > > > > Marko Cuk has apparently not tested the patch yet, but term@rmci.net has > > filed a bug report (kern/23010) today about very much the same thing. He > > has reported success with my patch, so I thought it might be time to > > try to get it in, so I have attached it ;-) > > > > This should close the PRs kern/21534, kern/23010 and (probably only partly) > > kern/19551. Marko Cuk's problem seems to be exactly the same to me: > > he also uses pipe firewall rules, and the panics happened when he activated > > the firewalling for bridging. He also reported partial success (no more > > panics) with my first patch. > > > > So, to come to a conclusion: could you please review (and perhaps commit) the > > patch or refer me to right person to bug about it? > > > > Thanks for your time, > > - Thomas > > Regards, > Bosko Milekic > bmilekic@technokratis.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 22 22:10:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from fat.ti.ru (fat.ti.ru [212.1.224.35]) by hub.freebsd.org (Postfix) with ESMTP id DF96037B479; Wed, 22 Nov 2000 22:10:22 -0800 (PST) Received: from martin (hilldale.kurgan.ru [212.1.224.61]) by fat.ti.ru (Postfix) with ESMTP id A74A6D91A; Thu, 23 Nov 2000 09:09:56 +0300 (MSK) Date: Thu, 23 Nov 2000 09:09:53 +0300 From: Martin McFlySr X-Mailer: The Bat! (v1.47 Halloween Edition) Business Reply-To: Martin McFlySr Organization: Back To The Future X-Priority: 3 (Normal) Message-ID: <85149180740.20001123090953@McFlySr.Kurgan.Ru> To: Kris Kennaway Cc: net@freebsd.org Subject: Re[2]: how can i ... In-reply-To: <20001122210438.A21910@citusc17.usc.edu> References: <78120708860.20001123011531@McFlySr.Kurgan.Ru> <20001122210438.A21910@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Kris Kennaway, Thursday, November 23, 2000, 08:04:38, you wrote: >> how can i connect freebsd (on client side) to freebsd (server) via pptp? >> On server installed mpd-3.2. KK> Please check the mailing list archives - it is a frequently asked KK> question. Thank you for quick answer. May be you can give more complete answer? I'm also can give answer "check maillist" for any question :-)) But before posting my question in list, i'm 1. checked this maillist. for my question exist two possible answer: pptp client & mpd. 2. i'm tested /usr/ports/net/pptpclient (this client dont support CHAP, as i understnd). 3. i'm tested mpd as cient, but no success. And i'm be obliged for accurate information about my furst question. Thank you, -- Thursday, November 23, 2000, 09:01 Best regards from future, Martin McFlySr, HillDale. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 6:14:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.suxx.eu.org (os-kam.cust.KKS.net [195.250.198.225]) by hub.freebsd.org (Postfix) with ESMTP id 97FFE37B4C5 for ; Thu, 23 Nov 2000 06:14:22 -0800 (PST) Received: by spider.suxx.eu.org (Postfix, from userid 1000) id 0DE71CC; Thu, 23 Nov 2000 15:16:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by spider.suxx.eu.org (Postfix) with ESMTP id 029D78E for ; Thu, 23 Nov 2000 15:16:13 +0100 (CET) Date: Thu, 23 Nov 2000 15:16:12 +0100 (CET) From: David Delibasic To: freebsd-net@freebsd.org Subject: Windows Millennium Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello I'm running samba with disabled option to use Crypted passwords. Does anyone know how to disable crypting passwords on Windows ME ? Best Regards, David > FreeBSD < -- > Power so serve < > Line noise provided by Telekom Slovenia < To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 11: 4:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id CD44837B4C5 for ; Thu, 23 Nov 2000 11:04:26 -0800 (PST) Received: from pretoria-31.budapest.interware.hu ([195.70.53.95] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13z1fQ-0004Gn-00; Thu, 23 Nov 2000 20:04:21 +0100 Message-ID: <3A1D1567.7D4A6F87@elischer.org> Date: Thu, 23 Nov 2000 05:02:32 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alex Pilosov Cc: net@FreeBSD.ORG Subject: Re: ALTQ as standard..... References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > Julian, > > Can you take a look at the code http://www.riss-telecom.ru/~vitaly/ > thanks for the pointer... I'll examine it in more depth later, (I looke at it some time ago) I was not specifically looking for ALTQ traffic controlling, but the ALTQ ability to have 'pluggable queue types' > Its already based on netgraph, and it can do [almost] everything that ALTQ > does. The only thing it lacks compared to altq is a large selection of > queuing disciplines. It is also much faster than altq. > > bwman also has support for lower and upper bound of bandwidth, unlike > ALTQ. > I will get back to you later about these modules.... > -alex > > On Tue, 21 Nov 2000, Julian Elischer wrote: > > > I'd like to put to the networking list that we take a serious look > > at making the ALTQ code from Kenjiro Cho a standard part of FreeBSD. > > > > I'm looking at adding some queueing methods into Netgraph > > as part of some work being discussed by > > phk, Archie, Brian and myself, Looking into this I note that > > for the to be really effective we really want to have an > > overall queueing strategy for the OS. We have at the moment, > > the simplistic IFQ_ macro's, but I think that they have lived > > long enough and done their duty. > > I'd like to replace them (or at least supplement them) > > in a way that allows us to have more comprehensive queue > > support. If done correctly, (e.g the correct macro's > > are added,) I think we can keep the performance degradation > > to a minimum. > > > > MY main reason right NOW is that in some cases, Netgraph > > interfaces to exisiting code using the exisiting queues, and > > if I want to add such things as queue priorities, I can't > > do this unless the exisiting code also upgrades. > > (e.g. the netgraph ethernet hooks deliver packets into the > > same queue that the normal interface methods do.) > > > > Julian > > > > > > \ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 11: 4:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 664F837B4C5 for ; Thu, 23 Nov 2000 11:04:34 -0800 (PST) Received: from pretoria-31.budapest.interware.hu ([195.70.53.95] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13z1fX-0004HH-00; Thu, 23 Nov 2000 20:04:28 +0100 Message-ID: <3A1D15B8.167B4A90@elischer.org> Date: Thu, 23 Nov 2000 05:03:52 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Kenjiro Cho Cc: net@freebsd.org Subject: Re: ALTQ as standard..... References: <3A1A74D4.CF5AEF4F@elischer.org> <20001122025959Z.kjc@csl.sony.co.jp> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenjiro Cho wrote: > > ALTQ can be viewed as > (1) abstraction of the output queue > and > (2) an implementation based on (1) What I want to see standard is the abstraction part.. if that's suppplied the rest can be a module... > > I'd like to focus on (1) for our discussion for the moment. > > The output queue is the place where packet scheduling and buffer > management can be done. > The current IF macros are incomplete (e.g., lack of a poll operation), > and its model lacks enough abstraction to accommodate algorithms other > than FIFO. > > I'm trying to make the output queue as a black-box with a set of > well-defined operations, and modify the existing code to access the > output queue only through these operations. > Although we have to first convert the existing drivers to use these > operations, I believe it will pay off in the long run. > > Once we have a clean model of the output queue, modifications to the > internal structure do not affect the other part of the kernel, be it > ALTQ or another implementation. > (this approach is also preferable for SMP.) > > In ALTQ, the following 4 operations are used. > - ENQUEUE > enqueues a packet to the queue. ENQUEUE also takes care of > packet dropping. if the arriving packet is dropped, the mbuf > is freed and an error (ENOBUFS) is returned. > - DEQUEUE > dequeues a packet from the queue. > - POLL > returns the next packet without removing the packet from the > queue. > if DEQUEUE immediately follows POLL, the same packet is > returned. (locking will be needed for SMP.) > - PURGE > discards all the packets in the queue. (this operation is > needed for non-work conserving schedulers which cannot get > emptied by a dequeue-loop.) > > In this model, a driver can poll-and-dequeue a packet but cannot > prepend a packet back to the queue because it could be too expensive > for some algorithms to cancel scheduling once the internal state is > updated. > Thus, if a driver currently use "prepend-if-failed", it should be > converted to "poll-and-dequeue". > > I'll write a brief design note in a week (so that I can submit it to > Freenix). I'll post it to the list when I'm done. > > -Kenjiro -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 11:18: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from nu.nu.cuk.nu (node.050.lc.link.si [212.30.95.50]) by hub.freebsd.org (Postfix) with ESMTP id 480CE37B4CF for ; Thu, 23 Nov 2000 11:18:05 -0800 (PST) Received: from nu.cuk.nu (cuk.localnet [192.168.6.11]) by nu.nu.cuk.nu (Postfix) with ESMTP id 13EF41AB45; Thu, 23 Nov 2000 20:22:08 +0100 (CET) Message-ID: <3A1D6D4A.1DEADF17@nu.cuk.nu> Date: Thu, 23 Nov 2000 20:17:30 +0100 From: Marko Cuk X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Delibasic , freebsd-net@freebsd.org Subject: Re: Windows Millennium References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms96BFC3DB5909B5570A437827" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms96BFC3DB5909B5570A437827 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit This one is for Win98. It won't work on Millenium ?? Cuk To enable plain-text passwords, add the registry entry EnablePlainTextPassword (as a Dword) and set the value to 1 in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\Vnetsup David Delibasic wrote: > Hello > > I'm running samba with disabled option to use Crypted passwords. Does > anyone know how to disable crypting passwords on Windows ME ? > > Best Regards, > David > > > FreeBSD < -- > Power so serve < > > Line noise provided by Telekom Slovenia < > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --------------ms96BFC3DB5909B5570A437827 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 MIILRwYJKoZIhvcNAQcCoIILODCCCzQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CUkwggJWMIIBv6ADAgECAgsBAAAAAADi6OMbGjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQG EwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMSBDQTEe MBwGA1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAxIENBMB4XDTAwMTExODE3NTAwNloXDTAwMTIx OTE3NTAwNlowNjEWMBQGA1UEAxQNY3VrQG51LmN1ay5udTEcMBoGCSqGSIb3DQEJARYNY3Vr QG51LmN1ay5udTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuIuBAERjucydC5Dh3ubP ROY/sx0YtaiO0r6/6xJHfDlp7iJ6xpdj2PCK/MflRL2iUzQNODn8ng7hsa7+h8eURs7cXZIq rzOJK6Gzn57ij0hWAfv7+JFXl6EpxiadzeK9yW8sHUCiIn/3SpRmGqXtBDDfs1wmX67fzRQH 6bfAcv0CAwEAAaNDMEEwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIE8DAfBgNVHSME GDAWgBQO3PC7Ejzd+mCnjycKm6cufnNpmjANBgkqhkiG9w0BAQUFAAOBgQIQ/OPaTYl3kAPP tJ33aHsVW91+3JiFc72B5ObZFSewd/UXTxSpVfG14SnTYhkUKuiF7ZQMF+ZlQW/jsi/uoxHx 9t5gSzum946riO+C+meKCvukspxXCswYGm45G98/5iqEX+FLU0Y3o8wwq6yLyCVMZ5LUO2Wm 68ATDWEKUM2IrDCCAzswggIjoAMCAQICCwIAAAAAANZ4ujryMA0GCSqGSIb3DQEBBAUAMG0x CzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmlt YXJ5IENsYXNzIDEgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAxIENB MB4XDTk4MDkxNjEyMDAwMFoXDTA0MDEyODEyMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNV BAoTEEdsb2JhbFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDEgQ0ExHjAcBgNVBAMTFUds b2JhbFNpZ24gQ2xhc3MgMSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAmjJY7csS PqvryFdmTEK8cIBgADYB7t/9/V7xcuHMqjPYhGIlL+AuKyJiIq+OXl1pRW0NQ6J3a5uaMfHy EAKH4YqBnPmMYrK8ZImHVZZWfCkDtezp9llOzLi9FLEHFl6l1GfQTUmr/1nPx7Kh+2EbmYcw NY8q1a30osItFfv+23kCAwEAAaNwMG4wCwYDVR0PBAQDAgAGMB0GA1UdDgQWBBQO3PC7Ejzd +mCnjycKm6cufnNpmjAfBgNVHSMEGDAWgBT84Gb2WjWZ60Ae0rgeQ7yYjh+KwzARBglghkgB hvhCAQEEBAMCAAcwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAJSGOw9tLJwJO 6BczAJXaTkYeqdcWCpt+H8YA6+z535Vy8ZbeZodRv+VR0vn0WEnwIBYj82jooZzjHuiAPJDv JscCeodgNZ8s5J9OKnJyaV+EY3FoBzFytnnj6+e2LjqQVJo7hGjsohyU3pjHjAwUrbmnBQ2/ TQiFY6827nLlNZOKv42LBI6qwOlrqhfZVhs1yGReZAT9sUI89/TDLcfn5WqALpQ6b9NYaWsD YReIp8l6/wCAooLeOj6eq4fgVk6BhbNpxYYW6Yk/uIQ3dKgwS6mbmDet1ksx6gx+z9RdvB6e RBy2CwAfZy6acD9872USMbSnpMtdWyeaAed5n10o4jCCA6wwggKUoAMCAQICCwIAAAAAANZ4 uDfPMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0Ew HhcNOTgwOTE1MTIwMDAwWhcNMDkwMTI4MTIwMDAwWjBtMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEbMBkGA1UECxMSUHJpbWFyeSBDbGFzcyAxIENBMSYwJAYD VQQDEx1HbG9iYWxTaWduIFByaW1hcnkgQ2xhc3MgMSBDQTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAL0gNUfRKNYIoxI5I0cNvXAhUg5XMZWmNFdr7H5DecMGUkjNvLWhmb3Y HzK8z9ducm0udyKQgk5Lj5oMAUKa2XBZtp0f5mPRDK0dTviFgfmu75+mUmFEeRp1ReBhVkVt Qow9csumpBK3mvXWYNBgULOOpqbstPQSzX+ozu+z4YUw/nLE5ud3s55YQdZRg4gHxrZpTzbe 0QtIP73WnyF0ZG8nBj5L/Q6mm7+kSFeMkO6JGAsCgRi+Z/5TYIgnuqNzNEtaVrTecwXtmJZd 7ErnQPxLCWLr0OMxT4XReqtZZyv7iA/rqoO9Nf1hJ+xmDkJX92nCDO/8asJuSdqPQTiuSKkC AwEAAaNjMGEwDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBT84Gb2WjWZ60Ae0rgeQ7yYjh+K wzAfBgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzAPBgNVHRMBAf8EBTADAQH/MA0G CSqGSIb3DQEBBAUAA4IBAQCbowhEzvKQnXHzMrMFarXqzymY3lU+oBZ9BnpE1q/S+hNYjPgc x6sdtBvvaWiYXAg5j+D3+0jMIee4M9sFqjQkbErl6Xtg3oOzHwq+QXX8zDBIt8EmHQQzqrZ4 7SrLulaXMm73MZUuRvIU7ifH92KJuVxa0ziKZPU3tPGzNHLV1SE9S9d4k9cxZjUeo9hHSW8c reGAf/iYJGxzrA7CGncCoyYHt8drXbyC1SpIHWPPUDKm+xwYRxUKWwxcOCSaBJioCEhffDSH Y6stjUwAd5Qbdrr1FhijFa8vlPYpAHbBFRfT6TdNdtTLSylZJKzaSqDqY95fVLH689FFy8Vk tHMhMYIBxjCCAcICAQEwbDBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu di1zYTETMBEGA1UECxMKQ2xhc3MgMSBDQTEeMBwGA1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAx IENBAgsBAAAAAADi6OMbGjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEyMzE5MTczMVowIwYJKoZIhvcNAQkEMRYEFHrfaU9B Z7f9XMQO7YamMM0qa82YMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAjg227C1KLBZtTWV1+61nHNv3nd6IdeGIHNB7LTCibcTtqTP1GOiF+HNcP4p/ uDKAhpyAIIYPd6fe5oA07CAoSwEMFt+iequgJD1d+m5z5fgGVuC5Cr/6/RQ1nqSbOCpXIMdk kxvqeKKll+stOK4ZXAPyX4Hh3SAW364IKJki6DA= --------------ms96BFC3DB5909B5570A437827-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 13:29:45 2000 Delivered-To: freebsd-net@freebsd.org Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.1.8]) by hub.freebsd.org (Postfix) with SMTP id 3FCD537B4C5 for ; Thu, 23 Nov 2000 13:29:43 -0800 (PST) Received: from jane.cs.toronto.edu ([128.100.2.31]) by yonge.cs.toronto.edu with SMTP id <34039-513>; Thu, 23 Nov 2000 16:29:40 -0500 Received: from localhost by jane.cs.toronto.edu with SMTP id <453134-28539>; Thu, 23 Nov 2000 16:29:28 -0500 To: freebsd-net@freebsd.org Subject: Re: PPPoE, nat, dsl, some web sites In-reply-to: <004b01c04f4f$4ebe9f20$0402010a@biohz.net> Date: Thu, 23 Nov 2000 16:29:16 -0500 From: Samir Girdhar Message-Id: <00Nov23.162928edt.453134-28539@jane.cs.toronto.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Nov 2000 16:59:20 -0500 "Renaud Waldura" wrote: > Sounds like the infamous PMTU problem. Read this, section 6.3 especially: > http://renaud.waldura.com/doc/freebsd-pppoe/ > I've been using the NAT capabilities built into ppp(8) and have had no problems maintaining simultaneous connections to multiple DSL providers (default route through my ISP, static routes to the university) -- it properly NATs the traffic going out each link. But with the problems around the PMTU/MSS/broken routers, I've been looking at tcpmssd as a workaround. However, the docs indicate that it needs to work with natd(8) but, from what I've been reading, it seems to me that natd can only handle one external interface. It doesn't look like running a separate instance for each external interface is the answer, either. When I get some time (ie. after LISA) I intend to try a few different things including: - trying to run two natds - diverting to tcpmssd before passing the packets to ppp for NAT - having ipfw/natd/tcpmssd take care of the traffic going to my ISP and ppp+NAT take care of the traffic on the link to the university (but then I haven't addressed the PMTU breakage on this link) Anyone have any suggestions? Have I missed something obvious? Someone must have faced this sort of thing already, no? Thanks, Samir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 14:47: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id B34D137B4C5 for ; Thu, 23 Nov 2000 14:47:06 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4I004D91YGZ9@falla.videotron.net> for freebsd-net@freebsd.org; Thu, 23 Nov 2000 17:47:04 -0500 (EST) Date: Thu, 23 Nov 2000 17:47:28 -0500 (EST) From: Bosko Milekic Subject: Re: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 In-reply-to: <200011230513.eAN5DJh01421@iguana.aciri.org> To: Luigi Rizzo Cc: tmoestl@gmx.net, cuk@cuk.nu, freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I built a kernel with bridging + dummynet + ipfw and tested the diff. It seems to be fine on my end, although I haven't gotten further feedback from Marko. I've committed the fix to -CURRENT. I will wait a couple of days and MFC. I'll close two of the three PRs now (because they directly relate to this problem) and will leave the third one (already assigned to me) to close in the couple of days, after I MFC this and another dummynet+bridging related fix that went into -CURRENT about a month ago. Once again, thanks Thomas. Thank you Luigi for the input! On Wed, 22 Nov 2000, Luigi Rizzo wrote: > > Thomas, I have looked at and reviewed your patch, and have added one > > hunk to bridge.c, please take a look at the "almost ready for commit" > > version here: > > > > http://people.FreeBSD.org/~bmilekic/dumbridge.diff > > sounds ok to me (modulo testing). > > > Basically, I don't like the fact that we have to copy the ethernet > > header back into the mbuf for dummynet in bdg_forward(), especially since > > we just removed it before calling bdg_forward(). But, this is no fault of > > this was also part of my criticism to the original changes. > I posted a suggestion for keeping the ethernet header together with > the mbuf when calling ether_input() (in case, define a new function > ether_input2() if backward compatibility was a concern) to avoid > the need for M_PREPEND, and also (probably) to save some code in > the in the individual drivers where the ethernet splitting is > replicated and could be centralized in ether_input2(). > > But this is some change that now would require a lot of work > in touching the individual drivers. > > thanks Bosko and Thomas for your work > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 14:56:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from nu.nu.cuk.nu (node.050.lc.link.si [212.30.95.50]) by hub.freebsd.org (Postfix) with ESMTP id 8D07237B479 for ; Thu, 23 Nov 2000 14:56:05 -0800 (PST) Received: from nu.cuk.nu (cuk.localnet [192.168.6.11]) by nu.nu.cuk.nu (Postfix) with ESMTP id 14FA91AB45; Fri, 24 Nov 2000 00:00:17 +0100 (CET) Message-ID: <3A1DA06A.9F46ADC9@nu.cuk.nu> Date: Thu, 23 Nov 2000 23:55:38 +0100 From: Marko Cuk X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic , freebsd-net@freebsd.org, tmoestl@gmx.net Subject: Re: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms471E791FB2801D9F340B3F49" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms471E791FB2801D9F340B3F49 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit I'll try it tommorov in my company. I'll go to bed now :). Cuk Bosko Milekic wrote: > I built a kernel with bridging + dummynet + ipfw and tested the diff. It > seems to be fine on my end, although I haven't gotten further feedback > from Marko. > > I've committed the fix to -CURRENT. I will wait a couple of days and MFC. > I'll close two of the three PRs now (because they directly relate to this > problem) and will leave the third one (already assigned to me) to close > in the couple of days, after I MFC this and another dummynet+bridging > related fix that went into -CURRENT about a month ago. > > Once again, thanks Thomas. Thank you Luigi for the input! > > On Wed, 22 Nov 2000, Luigi Rizzo wrote: > > > > Thomas, I have looked at and reviewed your patch, and have added one > > > hunk to bridge.c, please take a look at the "almost ready for commit" > > > version here: > > > > > > http://people.FreeBSD.org/~bmilekic/dumbridge.diff > > > > sounds ok to me (modulo testing). > > > > > Basically, I don't like the fact that we have to copy the ethernet > > > header back into the mbuf for dummynet in bdg_forward(), especially since > > > we just removed it before calling bdg_forward(). But, this is no fault of > > > > this was also part of my criticism to the original changes. > > I posted a suggestion for keeping the ethernet header together with > > the mbuf when calling ether_input() (in case, define a new function > > ether_input2() if backward compatibility was a concern) to avoid > > the need for M_PREPEND, and also (probably) to save some code in > > the in the individual drivers where the ethernet splitting is > > replicated and could be centralized in ether_input2(). > > > > But this is some change that now would require a lot of work > > in touching the individual drivers. > > > > thanks Bosko and Thomas for your work > > > > cheers > > luigi > > ----------------------------------+----------------------------------------- > > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > > Phone: (510) 666 2927 > > ----------------------------------+----------------------------------------- > > Regards, > Bosko Milekic > bmilekic@technokratis.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --------------ms471E791FB2801D9F340B3F49 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 MIILRwYJKoZIhvcNAQcCoIILODCCCzQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CUkwggJWMIIBv6ADAgECAgsBAAAAAADi6OMbGjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQG EwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTETMBEGA1UECxMKQ2xhc3MgMSBDQTEe MBwGA1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAxIENBMB4XDTAwMTExODE3NTAwNloXDTAwMTIx OTE3NTAwNlowNjEWMBQGA1UEAxQNY3VrQG51LmN1ay5udTEcMBoGCSqGSIb3DQEJARYNY3Vr QG51LmN1ay5udTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuIuBAERjucydC5Dh3ubP ROY/sx0YtaiO0r6/6xJHfDlp7iJ6xpdj2PCK/MflRL2iUzQNODn8ng7hsa7+h8eURs7cXZIq rzOJK6Gzn57ij0hWAfv7+JFXl6EpxiadzeK9yW8sHUCiIn/3SpRmGqXtBDDfs1wmX67fzRQH 6bfAcv0CAwEAAaNDMEEwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIE8DAfBgNVHSME GDAWgBQO3PC7Ejzd+mCnjycKm6cufnNpmjANBgkqhkiG9w0BAQUFAAOBgQIQ/OPaTYl3kAPP tJ33aHsVW91+3JiFc72B5ObZFSewd/UXTxSpVfG14SnTYhkUKuiF7ZQMF+ZlQW/jsi/uoxHx 9t5gSzum946riO+C+meKCvukspxXCswYGm45G98/5iqEX+FLU0Y3o8wwq6yLyCVMZ5LUO2Wm 68ATDWEKUM2IrDCCAzswggIjoAMCAQICCwIAAAAAANZ4ujryMA0GCSqGSIb3DQEBBAUAMG0x CzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmlt YXJ5IENsYXNzIDEgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAxIENB MB4XDTk4MDkxNjEyMDAwMFoXDTA0MDEyODEyMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNV BAoTEEdsb2JhbFNpZ24gbnYtc2ExEzARBgNVBAsTCkNsYXNzIDEgQ0ExHjAcBgNVBAMTFUds b2JhbFNpZ24gQ2xhc3MgMSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAmjJY7csS PqvryFdmTEK8cIBgADYB7t/9/V7xcuHMqjPYhGIlL+AuKyJiIq+OXl1pRW0NQ6J3a5uaMfHy EAKH4YqBnPmMYrK8ZImHVZZWfCkDtezp9llOzLi9FLEHFl6l1GfQTUmr/1nPx7Kh+2EbmYcw NY8q1a30osItFfv+23kCAwEAAaNwMG4wCwYDVR0PBAQDAgAGMB0GA1UdDgQWBBQO3PC7Ejzd +mCnjycKm6cufnNpmjAfBgNVHSMEGDAWgBT84Gb2WjWZ60Ae0rgeQ7yYjh+KwzARBglghkgB hvhCAQEEBAMCAAcwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAJSGOw9tLJwJO 6BczAJXaTkYeqdcWCpt+H8YA6+z535Vy8ZbeZodRv+VR0vn0WEnwIBYj82jooZzjHuiAPJDv JscCeodgNZ8s5J9OKnJyaV+EY3FoBzFytnnj6+e2LjqQVJo7hGjsohyU3pjHjAwUrbmnBQ2/ TQiFY6827nLlNZOKv42LBI6qwOlrqhfZVhs1yGReZAT9sUI89/TDLcfn5WqALpQ6b9NYaWsD YReIp8l6/wCAooLeOj6eq4fgVk6BhbNpxYYW6Yk/uIQ3dKgwS6mbmDet1ksx6gx+z9RdvB6e RBy2CwAfZy6acD9872USMbSnpMtdWyeaAed5n10o4jCCA6wwggKUoAMCAQICCwIAAAAAANZ4 uDfPMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0Ew HhcNOTgwOTE1MTIwMDAwWhcNMDkwMTI4MTIwMDAwWjBtMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEbMBkGA1UECxMSUHJpbWFyeSBDbGFzcyAxIENBMSYwJAYD VQQDEx1HbG9iYWxTaWduIFByaW1hcnkgQ2xhc3MgMSBDQTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAL0gNUfRKNYIoxI5I0cNvXAhUg5XMZWmNFdr7H5DecMGUkjNvLWhmb3Y HzK8z9ducm0udyKQgk5Lj5oMAUKa2XBZtp0f5mPRDK0dTviFgfmu75+mUmFEeRp1ReBhVkVt Qow9csumpBK3mvXWYNBgULOOpqbstPQSzX+ozu+z4YUw/nLE5ud3s55YQdZRg4gHxrZpTzbe 0QtIP73WnyF0ZG8nBj5L/Q6mm7+kSFeMkO6JGAsCgRi+Z/5TYIgnuqNzNEtaVrTecwXtmJZd 7ErnQPxLCWLr0OMxT4XReqtZZyv7iA/rqoO9Nf1hJ+xmDkJX92nCDO/8asJuSdqPQTiuSKkC AwEAAaNjMGEwDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBT84Gb2WjWZ60Ae0rgeQ7yYjh+K wzAfBgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzAPBgNVHRMBAf8EBTADAQH/MA0G CSqGSIb3DQEBBAUAA4IBAQCbowhEzvKQnXHzMrMFarXqzymY3lU+oBZ9BnpE1q/S+hNYjPgc x6sdtBvvaWiYXAg5j+D3+0jMIee4M9sFqjQkbErl6Xtg3oOzHwq+QXX8zDBIt8EmHQQzqrZ4 7SrLulaXMm73MZUuRvIU7ifH92KJuVxa0ziKZPU3tPGzNHLV1SE9S9d4k9cxZjUeo9hHSW8c reGAf/iYJGxzrA7CGncCoyYHt8drXbyC1SpIHWPPUDKm+xwYRxUKWwxcOCSaBJioCEhffDSH Y6stjUwAd5Qbdrr1FhijFa8vlPYpAHbBFRfT6TdNdtTLSylZJKzaSqDqY95fVLH689FFy8Vk tHMhMYIBxjCCAcICAQEwbDBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu di1zYTETMBEGA1UECxMKQ2xhc3MgMSBDQTEeMBwGA1UEAxMVR2xvYmFsU2lnbiBDbGFzcyAx IENBAgsBAAAAAADi6OMbGjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEyMzIyNTUzOFowIwYJKoZIhvcNAQkEMRYEFK/XBU47 CysdjapEtUcISf9vnYMcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3 DQEBAQUABIGAGS1MSMlHrl1wrs9QC+15dFiigiOMlNGPOgc+IrO4uAPNFiTOw2H+ZNCi53gb peJQ3q5z3Z1fUcSbnqt+m75kXNqjn0FvypCrKYr5iwawFNkhO8X9G2HmoUYQDIzgKd9RFu7P o0JWYh0Y1M2/IIYifGUTbG5zuT/2QXfFOOsuknM= --------------ms471E791FB2801D9F340B3F49-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 15:10:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 358F037B479 for ; Thu, 23 Nov 2000 15:10:56 -0800 (PST) Received: from kairo-29.budapest.interware.hu ([195.70.50.93] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13z5Vz-0000X9-00; Fri, 24 Nov 2000 00:10:52 +0100 Message-ID: <3A1DA3F2.9C02F1B7@elischer.org> Date: Thu, 23 Nov 2000 15:10:42 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Samir Girdhar Cc: freebsd-net@freebsd.org Subject: Re: PPPoE, nat, dsl, some web sites References: <00Nov23.162928edt.453134-28539@jane.cs.toronto.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Samir Girdhar wrote: > > On Wed, 15 Nov 2000 16:59:20 -0500 "Renaud Waldura" wrote: > > Sounds like the infamous PMTU problem. Read this, section 6.3 especially: > > http://renaud.waldura.com/doc/freebsd-pppoe/ > > > > I've been using the NAT capabilities built into ppp(8) and have > had no problems maintaining simultaneous connections to multiple > DSL providers (default route through my ISP, static routes to > the university) -- it properly NATs the traffic going out each > link. > > But with the problems around the PMTU/MSS/broken routers, I've > been looking at tcpmssd as a workaround. > > However, the docs indicate that it needs to work with natd(8) > but, from what I've been reading, it seems to me that natd > can only handle one external interface. It doesn't look like > running a separate instance for each external interface is the > answer, either. > > When I get some time (ie. after LISA) I intend to try a few > different things including: I believe that the tcpmssd port can work with ppp as well. > > - trying to run two natds > - diverting to tcpmssd before passing the packets to ppp > for NAT > - having ipfw/natd/tcpmssd take care of the traffic going > to my ISP and ppp+NAT take care of the traffic on the > link to the university (but then I haven't addressed > the PMTU breakage on this link) > > Anyone have any suggestions? Have I missed something obvious? > Someone must have faced this sort of thing already, no? > > Thanks, > Samir > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 15:24:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 2E88637B4CF for ; Thu, 23 Nov 2000 15:24:36 -0800 (PST) Received: (qmail 33880 invoked from network); 23 Nov 2000 23:24:34 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 23 Nov 2000 23:24:34 -0000 Message-ID: <0d9101c055a4$a1d5ba30$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: References: <00Nov23.162928edt.453134-28539@jane.cs.toronto.edu> <3A1DA3F2.9C02F1B7@elischer.org> Subject: Re: PPPoE, nat, dsl, some web sites Date: Thu, 23 Nov 2000 18:25:14 -0500 Organization: netZuno Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oh boy... does that qualify as a FAQ ??? I guess that tcpmssd should really be included in the FreeBSD distribution. It is needed for just about every xDSL user. Let's have that in the base and documented in the proper rc files (rc.conf and rc.firewall) just like natd. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 15:40:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 3A2FA37B4C5 for ; Thu, 23 Nov 2000 15:40:14 -0800 (PST) Received: by mail.snickers.org (Postfix, from userid 66) id 89E553D3E; Thu, 23 Nov 2000 18:40:09 -0500 (EST) Received: by asherah.dyndns.org (Postfix, from userid 701954) id 3998034503; Thu, 23 Nov 2000 18:35:44 -0500 (EST) Date: Thu, 23 Nov 2000 18:35:43 -0500 From: Josh Tiefenbach To: Patrick Bihan-Faou Cc: freebsd-net@freebsd.org Subject: Re: PPPoE, nat, dsl, some web sites Message-ID: <20001123183543.A59950@zipperup.org> References: <00Nov23.162928edt.453134-28539@jane.cs.toronto.edu> <3A1DA3F2.9C02F1B7@elischer.org> <0d9101c055a4$a1d5ba30$040aa8c0@local.mindstep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0d9101c055a4$a1d5ba30$040aa8c0@local.mindstep.com>; from patrick@netzuno.com on Thu, Nov 23, 2000 at 06:25:14PM -0500 Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I guess that tcpmssd should really be included in the FreeBSD distribution. > It is needed for just about every xDSL user. Let's have that in the base and > documented in the proper rc files (rc.conf and rc.firewall) just like natd. It would be nice if there was a way to use tcpmssd (or equiv functionality) for those of us who prefer to use IPFilter/ipnat rather than ipfw/natd to implement firewalls. For the record, is there a way to get ipfw and ipfilter to interact properly so I can use tcpmssd? Or divert sockets for that matter. The flip side is, does anyone know of any efforts to port divert sockets to the ipfilter framework? josh -- This email has been brought to you by the letters U, U, C, and P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 23 16: 2:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id A1FA737B4CF for ; Thu, 23 Nov 2000 16:02:35 -0800 (PST) Received: (qmail 35308 invoked from network); 24 Nov 2000 00:02:32 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 24 Nov 2000 00:02:32 -0000 Message-ID: <0dba01c055a9$ef7e9c20$040aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Josh Tiefenbach" Cc: References: <00Nov23.162928edt.453134-28539@jane.cs.toronto.edu> <3A1DA3F2.9C02F1B7@elischer.org> <0d9101c055a4$a1d5ba30$040aa8c0@local.mindstep.com> <20001123183543.A59950@zipperup.org> Subject: Re: PPPoE, nat, dsl, some web sites Date: Thu, 23 Nov 2000 19:03:11 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It would be nice if there was a way to use tcpmssd (or equiv functionality) > for those of us who prefer to use IPFilter/ipnat rather than ipfw/natd to > implement firewalls. > > For the record, is there a way to get ipfw and ipfilter to interact properly > so I can use tcpmssd? Or divert sockets for that matter. > > The flip side is, does anyone know of any efforts to port divert > sockets to the ipfilter framework? Yep this is really where the work is: if you can get ipfilter to use divert sockets this should not be too difficult. On the other hand, the work done in tcpmssd is really not difficult (I came up with the original code (in libalias) in a couple of hours) and can easily be integrated in whatever ipfilter uses for nat. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 24 4:17:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from tech.pcx.si (tech.pcx.si [212.18.46.56]) by hub.freebsd.org (Postfix) with ESMTP id 7EB0337B479; Fri, 24 Nov 2000 04:17:12 -0800 (PST) Received: from nu.cuk.nu (unknown [192.168.1.50]) by tech.pcx.si (Postfix) with ESMTP id E76B9F90DF; Fri, 24 Nov 2000 13:18:20 +0100 (CET) Message-ID: <3A1E5C6C.797B73DB@nu.cuk.nu> Date: Fri, 24 Nov 2000 13:17:48 +0100 From: Marko Cuk Organization: Pcx computers d.o.o., Tehnika X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bmilekic@technokratis.com, freebsd-net@freebsd.org, tmoestl@gmx.net, luigi@info.iet.unipi.it, stable@freebsd.org Subject: Re: PATCH REVIEW Re: bug in bridging/dummynet code - PR kern/19551 References: <3A1DA06A.9F46ADC9@nu.cuk.nu> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It works !!! Bridge code works in 4.2 with patched bridge.c and ip_dummynet.c from Bosko Milekic. su-2.04# netstat -m 176/624/40960 mbufs in use (current/peak/max): 173 mbufs allocated to data 3 mbufs allocated to packet headers 145/366/10240 mbuf clusters in use (current/peak/max) 888 Kbytes allocated to network (2% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines It remains like that after 200Mbytes transferred on 100Mbit network with 25 ipfw rules. Otherwise I have aroung 1Gbyte of traffic in and out every working day. I'll test it through weekend, as 4.0 crashed few times on saturday when there was no packet flow. Many thanks to bMilekic, Luigi ang Thomas !!!! Marko Cuk Marko Cuk wrote: > > I'll try it tommorov in my company. I'll go to bed now :). > > Cuk > > Bosko Milekic wrote: > > > I built a kernel with bridging + dummynet + ipfw and tested the diff. It > > seems to be fine on my end, although I haven't gotten further feedback > > from Marko. > > > > I've committed the fix to -CURRENT. I will wait a couple of days and MFC. > > I'll close two of the three PRs now (because they directly relate to this > > problem) and will leave the third one (already assigned to me) to close > > in the couple of days, after I MFC this and another dummynet+bridging > > related fix that went into -CURRENT about a month ago. > > > > Once again, thanks Thomas. Thank you Luigi for the input! > > > > On Wed, 22 Nov 2000, Luigi Rizzo wrote: > > > > > > Thomas, I have looked at and reviewed your patch, and have added one > > > > hunk to bridge.c, please take a look at the "almost ready for commit" > > > > version here: > > > > > > > > http://people.FreeBSD.org/~bmilekic/dumbridge.diff > > > > > > sounds ok to me (modulo testing). > > > > > > > Basically, I don't like the fact that we have to copy the ethernet > > > > header back into the mbuf for dummynet in bdg_forward(), especially since > > > > we just removed it before calling bdg_forward(). But, this is no fault of > > > > > > this was also part of my criticism to the original changes. > > > I posted a suggestion for keeping the ethernet header together with > > > the mbuf when calling ether_input() (in case, define a new function > > > ether_input2() if backward compatibility was a concern) to avoid > > > the need for M_PREPEND, and also (probably) to save some code in > > > the in the individual drivers where the ethernet splitting is > > > replicated and could be centralized in ether_input2(). > > > > > > But this is some change that now would require a lot of work > > > in touching the individual drivers. > > > > > > thanks Bosko and Thomas for your work > > > > > > cheers > > > luigi > > > ----------------------------------+----------------------------------------- > > > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > > > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > > > Phone: (510) 666 2927 > > > ----------------------------------+----------------------------------------- > > > > Regards, > > Bosko Milekic > > bmilekic@technokratis.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 25 15: 6: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.4]) by hub.freebsd.org (Postfix) with ESMTP id 4775737B479 for ; Sat, 25 Nov 2000 15:06:02 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id RAA02112 for ; Sat, 25 Nov 2000 17:06:07 -0600 Message-ID: <3A204656.92F4095C@twopoint.com> Date: Sat, 25 Nov 2000 17:08:06 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: mpd 3.2 connection issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I am trying to use mpd for a vpn connection, it is half working. The remote machine is connecting but the problem I am having is that the remote machine can not ping or browse the local network. It can however resolve names via DNS, ftp and telnet to local hosts on the network. I am very confused at this point. My main objective is to allow remote users to make a pptp connection via M$ vpn on win9x boxes and allow them to browse the network and connect to local machine with PcAnywhere. They also should be able to telnet and ftp, but as that is currently working it doesn't seem to be a problem. The local machine acts as firewall and Nated gateway it is dual homed with two nics. I have ipfw rules to allow the pptp connection and GRE traffic that from my logs seem to work nicely (thanks to jwd for that). The mpd/pptp server is running on the public interface and assigns an ip associated with the internal network (ie; 192.x.x.x). As I am new to mpd I am unsure what logs and config files to show. If anyone willing to help needs more info please tell me what to send. thanks, Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message