From owner-freebsd-net Sun Jul 8 9:50:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from bear.mshindo.net (bear.mshindo.net [202.229.42.121]) by hub.freebsd.org (Postfix) with ESMTP id 508C537B401 for ; Sun, 8 Jul 2001 09:50:46 -0700 (PDT) (envelope-from mshindo@mshindo.net) Received: from localhost (pl095.nas911.n-yokohama.nttpc.ne.jp [210.139.55.95]) by bear.mshindo.net (8.11.1/8.11.1) with ESMTP id f68Ggxx37201 for ; Mon, 9 Jul 2001 01:42:59 +0900 (JST) (envelope-from mshindo@mshindo.net) Date: Mon, 09 Jul 2001 01:51:10 +0900 (JST) Message-Id: <20010709.015110.52175108.mshindo@mshindo.net> To: freebsd-net@FreeBSD.ORG Subject: Tunnel Mode AH From: Motonori Shindo X-Mailer: Mew version 1.95b122 on Emacs 20.7 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a question regarding IPsec tunnel mode AH processing. ipsec(4) says: AH tunnel may not work as you might expect. If you configure ``require'' policy against AH tunnel for inbound, tunneled packets will be rejected. This is because AH authenticates encapsulating (outer) packet, not the encapsulated (inner) packet. I am seeing exactly what is explained in this paragraph; IKE (racoon) successfully establishes IPsec SA for both directions and packets get properly encapsulated (tunnel-mode AH) and sent to the peer but the peer looks rejecting the packet. If I change the parameter in the policy setting from 'required' to 'use', it works just fine. setkey(8) also says that: require means SA is required whenever the kernel deals with the packet. Even if the policy is specified as "required", it looks (at least, to me) that SA (destination address, Security Protocol(AH/ESP), and SPI) is properly established. I don't see anything that can prevent it from working if the policy is specified as 'require'. Will anybody here help me understand this? Regards, =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 8 17:20:48 2001 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 C5F2F37B401 for ; Sun, 8 Jul 2001 17:20:45 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9B4C34B21; Mon, 9 Jul 2001 09:20:43 +0900 (JST) To: Motonori Shindo Cc: freebsd-net@FreeBSD.ORG In-reply-to: mshindo's message of Mon, 09 Jul 2001 01:51:10 +0900. <20010709.015110.52175108.mshindo@mshindo.net> 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: Tunnel Mode AH From: itojun@iijlab.net Date: Mon, 09 Jul 2001 09:20:43 +0900 Message-ID: <3919.994638043@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Even if the policy is specified as "required", it looks (at least, to >me) that SA (destination address, Security Protocol(AH/ESP), and SPI) >is properly established. I don't see anything that can prevent it from >working if the policy is specified as 'require'. > >Will anybody here help me understand this? IKE is not the issue, SA establishment is not the issue. the issue bites you when you actually receive AH tunnel packet which matches "require" policy (inbound). they will get rejected. we (KAME) are at this moment using 1-bit mbuf flag to remember which mbuf is authenticated or not. this way, we cannot handle tunelled AH case. check out the latest manpage for a little bit better description: http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/man/man4/ipsec.4 itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 8 19:23:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.csl.sony.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id D260037B408 for ; Sun, 8 Jul 2001 19:23:42 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57] (may be forged)) by inetfw.csl.sony.co.jp (8.11.2+3.4W/3.7Ws3/inetfw/2001041615/smtpfeed 1.12) with ESMTP id f692Nd502627; Mon, 9 Jul 2001 11:23:40 +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 LAA51668; Mon, 9 Jul 2001 11:23:39 +0900 (JST) To: p9711422@mmu.edu.my Cc: freebsd-net@FreeBSD.ORG Subject: Re: ng_bridge and altq In-Reply-To: <20010705121139.68943.qmail@web13305.mail.yahoo.com> References: <20010705121139.68943.qmail@web13305.mail.yahoo.com> 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: <20010709112339R.kjc@csl.sony.co.jp> Date: Mon, 09 Jul 2001 11:23:39 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org wrote: > hi all...i just have one simple question. can altq work with ng_bridge if i > were to use both of it to bridge and shape traffic? currently i'm using > "options BRIDGE" in my kernel configuration and altq works flawlessly. i > haven't got the chance to play around with ng_bridge because it's a > production machine :( Unfortunately, ALTQ doesn't work with netgraph yet. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 3:35:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhost2.dircon.co.uk (mailhost2.dircon.co.uk [194.112.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 3F22537B407 for ; Mon, 9 Jul 2001 03:35:34 -0700 (PDT) (envelope-from mark.blackman@netscalibur.co.uk) Received: from localhost.ch.dircon.net (desk99.ch.dircon.net [195.157.3.99]) by mailhost2.dircon.co.uk (8.9.3/8.9.3) with ESMTP id LAA90463 for ; Mon, 9 Jul 2001 11:35:21 +0100 (BST) Message-Id: <200107091035.LAA90463@mailhost2.dircon.co.uk> From: "Mark Blackman" To: freebsd-net@freebsd.org Subject: default route disappears on address changes for interface. Date: Mon, 09 Jul 2001 11:35:29 +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org on FreeBSD 4.3-STABLE #1: Thu May 24 13:03:35 BST 2001 Is it now standard/expected behaviour that default routes disappear on an IP address change even within the same netmask or even to the same address if the default route is on that interface? Say I've got the following setup. ifconfig ep0 inet 10.0.0.1 netmask 255.255.255.0 route add default 10.0.0.254 then i do ifconfig ep0 inet 10.0.0.2 (or even 10.0.0.1) suddenly my default route disappears. Is this expected behaviour and has this always been the case? I'm pretty sure it wasn't. Thanks, Mark Blackman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 3:40:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 9899B37B408 for ; Mon, 9 Jul 2001 03:40:10 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f69AdnI13180; Mon, 9 Jul 2001 11:39:49 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f69AfbQ61858; Mon, 9 Jul 2001 11:41:37 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107091041.f69AfbQ61858@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Mark Blackman" Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: default route disappears on address changes for interface. In-Reply-To: Message from "Mark Blackman" of "Mon, 09 Jul 2001 11:35:29 BST." <200107091035.LAA90463@mailhost2.dircon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Jul 2001 11:41:37 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ifconfig(8) deletes and re-adds the given address. When the delete happens, the route (now) disappears. IMHO, ifconfig(8) should be smart enough to optimise out no-ops. > on FreeBSD 4.3-STABLE #1: Thu May 24 13:03:35 BST 2001 > > Is it now standard/expected behaviour that default routes > disappear on an IP address change even within the same netmask > or even to the same address if the default route is on that > interface? > > Say I've got the following setup. > > ifconfig ep0 inet 10.0.0.1 netmask 255.255.255.0 > route add default 10.0.0.254 > > then i do > > ifconfig ep0 inet 10.0.0.2 (or even 10.0.0.1) > > suddenly my default route disappears. Is this expected > behaviour and has this always been the case? I'm pretty > sure it wasn't. > > Thanks, > Mark Blackman -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 4: 1:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f45.law11.hotmail.com [64.4.17.45]) by hub.freebsd.org (Postfix) with ESMTP id 9AE3737B401 for ; Mon, 9 Jul 2001 04:01:50 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 04:01:50 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 11:01:50 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Date: Mon, 09 Jul 2001 11:01:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 11:01:50.0552 (UTC) FILETIME=[8E05DD80:01C10866] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, In case of configured tunneling in ip6_output() function at what stage the outgoing interface is found as gif_if. I think the following line number-646 finds the corresponding default gif_if interface is found. /*code taken from ip6_output*/ 644 if (ifp == NULL) { 645 if (ro->ro_rt == 0) { 646 ro->ro_rt = rtalloc1((struct sockaddr *)&ro->ro_dst, 0, 0UL); 648 } 649 if (ro->ro_rt == 0) { 650 ip6stat.ip6s_noroute++; 651 error = EHOSTUNREACH; 652 /* XXX in6_ifstat_inc(ifp, ifs6_out_discard) */ 653 goto bad; 654 } 655 ia = ifatoia6(ro->ro_rt->rt_ifa); 656 ifp = ro->ro_rt->rt_ifp; 657 ro->ro_rt->rt_use++; 658 } -- And pls explain me when the gif_output() is called thanks, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 4:38:29 2001 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 2AF3337B401 for ; Mon, 9 Jul 2001 04:38:27 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 733704B20; Mon, 9 Jul 2001 20:38:20 +0900 (JST) To: "FreeBSDlover FreeBSDlover" Cc: freebsd-net@freebsd.org In-reply-to: freebsdlover's message of Mon, 09 Jul 2001 11:01:50 GMT. 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 From: itojun@iijlab.net Date: Mon, 09 Jul 2001 20:38:20 +0900 Message-ID: <12868.994678700@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >And pls explain me when the gif_output() is called find the call made through (*ifp->if_output)() in sys/netinet6/nd6.c:nd6_output(). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 6: 9:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id B0BE037B403 for ; Mon, 9 Jul 2001 06:09:25 -0700 (PDT) (envelope-from vlad@majar.com) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id QDP08622 for freebsd-net@freebsd.org; Mon, 9 Jul 2001 16:09:21 +0300 (envelope-from vlad@majar.com) From: "Vladyslav Shvedenko" To: freebsd-net@freebsd.org Subject: Windows Login's statistics Date: Mon, 9 Jul 2001 16:08:28 +0300 Organization: Utel Message-ID: <9icaan$2g0s$1@bn.utel.com.ua> X-Trace: bn.utel.com.ua 994684055 81948 212.113.40.221 (9 Jul 2001 13:07:35 GMT) X-Complaints-To: postmaster@utel.net.ua X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello. I have to count all Windows logins from a LAN and accumulate all users' traffic which goes through FreeBSD gateway. I can use ipfw, but there's no username information (each Windows workstation has a lot of users). Please, tell me how can i solve my needs? Vlad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 7:29:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail4.home.nl (mail4.home.nl [213.51.129.228]) by hub.freebsd.org (Postfix) with ESMTP id 93AD337B401; Mon, 9 Jul 2001 07:29:21 -0700 (PDT) (envelope-from nascar24@home.nl) Received: from testuser ([213.51.193.168]) by mail4.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010709142956.VKNY407.mail4.home.nl@testuser>; Mon, 9 Jul 2001 15:29:56 +0100 Message-ID: <019001c10883$8ab4d790$0900a8c0@testuser> From: "Marcel Dijk" To: , Subject: ProFTPd Date: Mon, 9 Jul 2001 16:29:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018D_01C10894.4DFF17F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Disposition-Notification-To: "Marcel Dijk" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_018D_01C10894.4DFF17F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is it possible to do site-2-site transports with ProFTPd. What I mean = is, is it possible to transfer data from one FTP to my FTP server via a = site-2-site transport, aka FXP. If so, how? Thanks, Marcel ------=_NextPart_000_018D_01C10894.4DFF17F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Is it possible to do site-2-site = transports=20 with ProFTPd. What I mean is, is it possible to transfer data from = one FTP=20 to my FTP server via a site-2-site transport, aka FXP.
 
If so, how?
 
Thanks,
 
Marcel
------=_NextPart_000_018D_01C10894.4DFF17F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 7:29:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail1.home.nl (mail1.home.nl [213.51.129.225]) by hub.freebsd.org (Postfix) with ESMTP id DAA4E37B409 for ; Mon, 9 Jul 2001 07:29:43 -0700 (PDT) (envelope-from nascar24@home.nl) Received: from testuser ([213.51.193.168]) by mail1.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010709142942.FZEF22865.mail1.home.nl@testuser> for ; Mon, 9 Jul 2001 16:29:42 +0200 Message-ID: <019801c10883$98077c90$0900a8c0@testuser> From: "Marcel Dijk" To: Subject: samba question Date: Mon, 9 Jul 2001 16:29:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Disposition-Notification-To: "Marcel Dijk" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, If I try to access my Samba server (FreeBSD 4.2) from my Win2k machine I get this error: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The account is not authorized to log in from this station. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What could it be? Thanks, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 7:54:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from void.xpert.com (xpert.com [199.203.132.1]) by hub.freebsd.org (Postfix) with ESMTP id 90D3E37B401 for ; Mon, 9 Jul 2001 07:54:50 -0700 (PDT) (envelope-from Yonatan@xpert.com) Received: from mailserv.xpert.com ([199.203.132.135]) by void.xpert.com with esmtp (Exim 3.20 #1) id 15JbSV-0004nN-00; Mon, 09 Jul 2001 16:52:19 +0300 Received: by mailserv.xpert.com with Internet Mail Service (5.5.2650.21) id <3GHBYVKS>; Mon, 9 Jul 2001 17:54:12 +0300 Message-ID: From: Yonatan Bokovza To: 'Vladyslav Shvedenko' , freebsd-net@freebsd.org Subject: RE: Windows Login's statistics Date: Mon, 9 Jul 2001 17:54:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org capturing windows logins can be done with dsniff: ports/security/dsniff and ntop will give you great traffic statistics: ports/net/ntop You can play with ntop a bit to get cool (yet unsecure) web interface to the results. Best Regards, Yonatan Bokovza IT Security Consultant Xpert Systems > -----Original Message----- > From: Vladyslav Shvedenko [mailto:vlad@majar.com] > Sent: Monday, July 09, 2001 16:08 > To: freebsd-net@freebsd.org > Subject: Windows Login's statistics > > > Hello. > I have to count all Windows logins from a LAN and accumulate > all users' > traffic which goes through FreeBSD gateway. > > I can use ipfw, but there's no username information (each Windows > workstation has a lot of users). > > Please, tell me how can i solve my needs? > > Vlad > > > 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 Jul 9 10:22:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f191.law11.hotmail.com [64.4.17.191]) by hub.freebsd.org (Postfix) with ESMTP id 9AF4037B405 for ; Mon, 9 Jul 2001 10:22:08 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 10:22:08 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 17:22:08 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Date: Mon, 09 Jul 2001 17:22:08 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 17:22:08.0463 (UTC) FILETIME=[AE8EC5F0:01C1089B] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add –inet6 default –interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add –inet6 default –interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 10:31: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 015FD37B405 for ; Mon, 9 Jul 2001 10:30:52 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA48827; Mon, 9 Jul 2001 12:14:57 -0700 (PDT) Date: Mon, 9 Jul 2001 12:14:57 -0700 (PDT) From: Julian Elischer To: FreeBSDlover FreeBSDlover Cc: freebsd-net@freebsd.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 9 Jul 2001, FreeBSDlover FreeBSDlover wrote: > Hi, > Pls look at the following configuration. > --------- --------- > | | | | > | R |-------------------------| H | > | | | | > --------- ---------- > R =3D 192.168.3.1 H =3D 192.168.3.5 > H =3D 192.168.3.5 R =3D 192.168.3.1 >=20 > I have done the following steps > Step1:In Router side > ifconfig gif0 up > gifconfig gif0 192.168.3.1 192.168.3.5 > route add =96inet6 default =96interface gif0 Why is there a non-ascii character before the word "inet6" If that's taken from the script directly that would be rather=20 confusing to ifconfig.. >=20 > Step2:In Host side > ifconfig gif0 up > gifconfig gif0 192.168.3.5 192.168.3.1 > route add =96inet6 default =96interface gif0 >=20 > Step3: > ping6 -I gif0 ff02::1 > My Problem : IT DID NOT WORK > My Doubts: > 1.Is this the proper configuration? > 2.How to test configured tunneling mechanism in the above configuration= =20 > diagram. >=20 > with regds, > FreeBSDlover >=20 >=20 > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 10:32: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f264.law11.hotmail.com [64.4.16.139]) by hub.freebsd.org (Postfix) with ESMTP id 480A237B406 for ; Mon, 9 Jul 2001 10:31:57 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 10:31:57 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 09 Jul 2001 17:31:56 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: config tunneling Date: Mon, 09 Jul 2001 17:31:56 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jul 2001 17:31:57.0190 (UTC) FILETIME=[0D776260:01C1089D] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add –inet6 default –interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add –inet6 default –interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 15: 7: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from jezebel.demon.co.uk (jezebel.demon.co.uk [158.152.38.143]) by hub.freebsd.org (Postfix) with ESMTP id B2EBA37B405 for ; Mon, 9 Jul 2001 15:06:51 -0700 (PDT) (envelope-from rdls@jezebel.demon.co.uk) Received: (from rdls@localhost) by jezebel.demon.co.uk (8.11.1/8.11.1) id f69M5Dh01043 for net@freebsd.org; Mon, 9 Jul 2001 23:05:13 +0100 (BST) (envelope-from rdls) Date: Mon, 9 Jul 2001 23:05:13 +0100 From: Richard Smith To: net@freebsd.org Subject: sysctls keepidle and keepintvl Message-ID: <20010709230512.A918@gaia.home.rdls.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please cc me, as I'm not on this list. I am using 4.3-RELEASE, and investigating why I don't see any keepalives (using tcpdump) on my connections. The default values are as follows: net.inet.tcp.keepidle = 7200000 net.inet.tcp.keepintvl = 75000 It seems to me that the keepalive interval is being set by keepidle, thus setting keepidle = 20000, generates keepalives at 20s intervals. Looking at the comments in tcp_var.h, it should be keepintvl that sets this interval. Otherwise, why have such a large value for keepidle? Is this a bug? Or have I missed something, Many thanks, Rich. -- Richard Smith Network Systems Director Satamatics Ltd Green Lane, Tewkesbury, GL20 8HD, United Kingdom Tel: +44 1684 278610 Fax: +44 1684 278611 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 15:13:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 5C5D537B401 for ; Mon, 9 Jul 2001 15:13:32 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id AAA11018; Tue, 10 Jul 2001 00:07:55 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107092207.AAA11018@info.iet.unipi.it> Subject: Re: sysctls keepidle and keepintvl In-Reply-To: <20010709230512.A918@gaia.home.rdls.net> from Richard Smith at "Jul 9, 2001 11:05:13 pm" To: Richard Smith Date: Tue, 10 Jul 2001 00:07:55 +0200 (CEST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Please cc me, as I'm not on this list. > > I am using 4.3-RELEASE, and investigating why I don't see > any keepalives (using tcpdump) on my connections. > > The default values are as follows: > net.inet.tcp.keepidle = 7200000 > net.inet.tcp.keepintvl = 75000 > > It seems to me that the keepalive interval is being set > by keepidle, thus setting keepidle = 20000, generates > keepalives at 20s intervals. whatever is used, isn't the interval in seconds ? If so you must be very patient to see something... luigi > Looking at the comments in tcp_var.h, it should be > keepintvl that sets this interval. Otherwise, why > have such a large value for keepidle? > > Is this a bug? Or have I missed something, > > Many thanks, > Rich. > > -- > Richard Smith > Network Systems Director > Satamatics Ltd > Green Lane, Tewkesbury, GL20 8HD, United Kingdom > Tel: +44 1684 278610 > Fax: +44 1684 278611 > > 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 Jul 9 15:50:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 2AE1737B406 for ; Mon, 9 Jul 2001 15:50:47 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA50141; Mon, 9 Jul 2001 17:25:52 -0700 (PDT) Date: Mon, 9 Jul 2001 17:25:52 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: Richard Smith , net@FreeBSD.ORG Subject: Re: sysctls keepidle and keepintvl In-Reply-To: <200107092207.AAA11018@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Jul 2001, Luigi Rizzo wrote: > > Please cc me, as I'm not on this list. > > > > I am using 4.3-RELEASE, and investigating why I don't see > > any keepalives (using tcpdump) on my connections. > > > > The default values are as follows: > > net.inet.tcp.keepidle = 7200000 > > net.inet.tcp.keepintvl = 75000 > > > > It seems to me that the keepalive interval is being set > > by keepidle, thus setting keepidle = 20000, generates > > keepalives at 20s intervals. > > whatever is used, isn't the interval in seconds ? If so > you must be very patient to see something... milliseconds. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 19:40:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from coopcomp.com (coopcomp.com [161.58.219.43]) by hub.freebsd.org (Postfix) with ESMTP id 6F88037B401 for ; Mon, 9 Jul 2001 19:40:33 -0700 (PDT) (envelope-from seichert@coopcomp.com) Received: from gourdy.coopcomp.com (gourdy.coopcomp.com [64.81.249.34]) by coopcomp.com (8.11.2) id f6A2eWH10046; Mon, 9 Jul 2001 20:40:32 -0600 (MDT) Received: by gourdy.coopcomp.com (sSMTP sendmail emulation); Mon, 9 Jul 2001 19:40:26 +4100 Date: Mon, 9 Jul 2001 19:40:03 -0700 From: Stuart Eichert To: Julian Elischer Subject: Re: Am I missing something? Message-ID: <20010709194003.A54774@gourdy.coopcomp.com> References: <20010627111222.A9434@gourdy.coopcomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Jun 27, 2001 at 07:48:10PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jun 27, 2001 at 07:48:10PM -0700, Julian Elischer wrote: > > > On Wed, 27 Jun 2001, Stuart Eichert wrote: > I have been reading about Network Kernel Extensions (NKEs) for Mac OS/X. What are the differences between NKE and netgraph? It looks like NKEs will allow me to do what I want. Will they be adapted for FreeBSD? -- ------------ Stuart Eichert Cooperative Computers, Inc. seichert@coopcomp.com (650)938-0730 x 15 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 9 22: 3:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f179.law11.hotmail.com [64.4.17.179]) by hub.freebsd.org (Postfix) with ESMTP id 362AC37B401 for ; Mon, 9 Jul 2001 22:03:21 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jul 2001 22:03:21 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 05:03:20 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: Help me to configure Date: Tue, 10 Jul 2001 05:03:20 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 05:03:21.0045 (UTC) FILETIME=[A3C55050:01C108FD] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add –inet6 default –interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add –inet6 default –interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 2:34:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail17.messagelabs.com (mail17.messagelabs.com [62.231.131.67]) by hub.freebsd.org (Postfix) with SMTP id A3F5437B410 for ; Tue, 10 Jul 2001 02:09:50 -0700 (PDT) (envelope-from rdls@satamatics.com) X-VirusChecked: Checked Received: (qmail 22575 invoked from network); 10 Jul 2001 08:58:26 -0000 Received: from smtp-8.star.net.uk (212.125.75.77) by server-13.tower-17.messagelabs.com with SMTP; 10 Jul 2001 08:58:26 -0000 Received: (qmail 12690 invoked from network); 10 Jul 2001 09:09:47 -0000 Received: from unallocated.star.net.uk (HELO dns.hq.satamatics.net) (62.231.144.3) by smtp-8.star.net.uk with SMTP; 10 Jul 2001 09:09:47 -0000 Received: from matrix.satamatics.net (matrix.satamatics.net [10.24.1.1]) by dns.hq.satamatics.net (8.11.3/8.11.3) with ESMTP id f6AACSE36031; Tue, 10 Jul 2001 10:12:28 GMT (envelope-from rdls@satamatics.com) Subject: RE: sysctls keepidle and keepintvl Date: Tue, 10 Jul 2001 10:06:57 +0100 Message-ID: <703AB71471B6024CB86D219058DB64FB021F0D@matrix.satamatics.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sysctls keepidle and keepintvl X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcEJHpHhlnc9m8wLTa+kYNRwI7bVEgAAJhlA content-class: urn:content-classes:message From: "Richard Smith" To: "Ruslan Ermilov" Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Ruslan Ermilov [mailto:ru@FreeBSD.ORG] > Sent: 10 July 2001 10:02 > To: Richard Smith > Cc: net@FreeBSD.ORG > Subject: Re: sysctls keepidle and keepintvl >=20 >=20 > On Mon, Jul 09, 2001 at 11:05:13PM +0100, Richard Smith wrote: > > Please cc me, as I'm not on this list. > >=20 > > I am using 4.3-RELEASE, and investigating why I don't see > > any keepalives (using tcpdump) on my connections. > >=20 > > The default values are as follows: > > net.inet.tcp.keepidle =3D 7200000 > > net.inet.tcp.keepintvl =3D 75000 > >=20 > > It seems to me that the keepalive interval is being set > > by keepidle, thus setting keepidle =3D 20000, generates=20 > > keepalives at 20s intervals. > >=20 > > Looking at the comments in tcp_var.h, it should be=20 > > keepintvl that sets this interval. Otherwise, why > > have such a large value for keepidle? > >=20 > > Is this a bug? Or have I missed something, > >=20 > Only TCP sockets marked with SO_KEEPALIVE setsockopt(2) will > be kept alive. Alternatively, you can enable this option on > all sockets implicitly by net.inet.tcp.always_keepalive=3D1. > (Or by setting tcp_keepalive rc.conf(5) variable to "YES"). Thanks, keepalive _was_ enabled, it just has a long default=20 idle time (120 minutes) before it starts doing anything. I=20 guess they didn't have firewalls with dynamic rules in those days :-) Rich. _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 2:34:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B9F1237B405 for ; Tue, 10 Jul 2001 02:01:51 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6A91Un06470; Tue, 10 Jul 2001 12:01:30 +0300 (EEST) (envelope-from ru) Date: Tue, 10 Jul 2001 12:01:30 +0300 From: Ruslan Ermilov To: Richard Smith Cc: net@FreeBSD.ORG Subject: Re: sysctls keepidle and keepintvl Message-ID: <20010710120130.A5467@sunbay.com> Mail-Followup-To: Richard Smith , net@FreeBSD.ORG References: <20010709230512.A918@gaia.home.rdls.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010709230512.A918@gaia.home.rdls.net>; from rdls@satamatics.com on Mon, Jul 09, 2001 at 11:05:13PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 11:05:13PM +0100, Richard Smith wrote: > Please cc me, as I'm not on this list. > > I am using 4.3-RELEASE, and investigating why I don't see > any keepalives (using tcpdump) on my connections. > > The default values are as follows: > net.inet.tcp.keepidle = 7200000 > net.inet.tcp.keepintvl = 75000 > > It seems to me that the keepalive interval is being set > by keepidle, thus setting keepidle = 20000, generates > keepalives at 20s intervals. > > Looking at the comments in tcp_var.h, it should be > keepintvl that sets this interval. Otherwise, why > have such a large value for keepidle? > > Is this a bug? Or have I missed something, > Only TCP sockets marked with SO_KEEPALIVE setsockopt(2) will be kept alive. Alternatively, you can enable this option on all sockets implicitly by net.inet.tcp.always_keepalive=1. (Or by setting tcp_keepalive rc.conf(5) variable to "YES"). Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 2:34:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from plk.in.nextra.sk (fw.in.nextra.sk [195.168.29.2]) by hub.freebsd.org (Postfix) with ESMTP id 28C4837B40F; Tue, 10 Jul 2001 02:09:36 -0700 (PDT) (envelope-from plk@in.nextra.sk) Received: (from plk@localhost) by plk.in.nextra.sk (8.11.2/8.11.2) id f6A99Yo01616; Tue, 10 Jul 2001 11:09:34 +0200 Date: Tue, 10 Jul 2001 11:09:34 +0200 From: Bohuslav Plucinsky To: freebsd-net@freebsd.org Cc: freebsd-questions@freebsd.org, suutari@iki.fi, ru@freebsd.org Subject: natd and ICMP 3.4 packets Message-ID: <20010710110934.D1048@in.nextra.sk> Reply-To: plk@in.nextra.sk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: NEXTRA, Bratislava, SLOVAKIA X-NCC-RegID: sk.nextra Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there, I have strange problem with natd and ICMP 3.4 (destination unreachable/ fragmentation needed) packets. Situation: - we have FreeBSD 4.2-20001228-STABLE box with ipfw and natd configured xl0 interface have public address 195.168.x.x xl1 interface is connected to our intranet with private addr 10.10.1.1 ipfw show: 00100 0 0 allow ip from any to any via lo0 ... 09200 0 0 divert 8668 ip from any to any via xl0 09300 0 0 allow ip from any to any natd is running with arguments: natd -n xl0 - behind freebsd box is cisco router with GRE tunnel 195.168.x.x xl0 --------- xl1 10.10.1.0/24 (MTU 1500) -------| FreeBSD |------------------------------------------------------.... --------- | ipfw +NAT | | | 10.10.1.2 ---------- | CISCO 1 | ---------- || || || GRE tunnel (MTU 1476) || || || ---------- | CISCO 2 | ---------- | 10.10.20.0/24 ---- ---------------------------------| PC | ---- 10.10.20.2 Problem: If cisco router CISCO 1 sends ICMP 3.4 packet to any server on Internet, natd on FreeBSD box aliases data inside ICMP packet, but not IP headers There is tcpdump on xl1 interface: 11:56:54.376974 10.10.1.2 > 195.168.3.210: icmp: 10.10.20.2 unreachable - need to frag (mtu 1476) and on xl0 interface: 11:56:55.216974 10.10.1.2 > 195.168.3.210: icmp: 195.168.x.x unreachable - need to frag (mtu 1476) ^^^^^^^^^ ^^^^^^^^^^^ Is this bug in natd or make I some mistake in configuration? Regards, -- ====================================================================== Bohus PLUCINSKY e-mail: plk@in.nextra.sk Network Engineer N E X T R A Plynarenska 1 tel: +421 7 58 228 111 824 71 Bratislava 26 fax: +421 7 58 228 222 S L O V A K I A http://www.nextra.sk ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 4:46:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f197.law11.hotmail.com [64.4.17.197]) by hub.freebsd.org (Postfix) with ESMTP id 0DA7C37B403 for ; Tue, 10 Jul 2001 04:46:12 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jul 2001 04:46:11 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 11:46:11 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: tunneling in same link?? Date: Tue, 10 Jul 2001 11:46:11 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 11:46:11.0854 (UTC) FILETIME=[EAB212E0:01C10935] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Can i setup configured tunneling between a router and host which are in the same network?If possible pls explain me. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 6:12:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from gopostal.digi.com (gopostal.digi.com [204.221.110.15]) by hub.freebsd.org (Postfix) with ESMTP id 9B54E37B401 for ; Tue, 10 Jul 2001 06:12:43 -0700 (PDT) (envelope-from chaegle@mediaone.net) Received: from minx.dgii.com (minx.digi.com [204.221.110.36]) by gopostal.digi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3GYH29P0; Tue, 10 Jul 2001 08:12:37 -0500 Received: from hlc02 (hlc02.digi.com) by minx.dgii.com (5.x/SMI-SVR4) id AA05275; Tue, 17 Aug 1999 11:37:44 -0500 Message-Id: <002001c10942$2ca8dc40$420fbf8f@hlc02> From: "Cameron Haegle" To: Subject: Sendmail Date: Tue, 10 Jul 2001 08:13:55 -0500 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C10918.4356C670" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C10918.4356C670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Before I dig too deep into the Sendmail documentation I wanted to ensure = that the following is possible. My FreeBSD box is performing NATd and IPFW functions for a few PCs at = home, off of my cable modem. Wheneve I attempt to send an e-mail from my = system I receive a message back from indicating that the message had = permanent fatal erros, and the Domain of sender address = somename@some_nonexistent.domain does not exist. What I would like to knowis the following, can I configure sendmail to = ignore this message and send the message anyway? Or is there some other = way to overcome this issue. Any guidance is appreciated. Regards, Cameron ------=_NextPart_000_001D_01C10918.4356C670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Before I dig too deep into the Sendmail = documentation I wanted to ensure that the following is = possible.
 
My FreeBSD box is performing NATd and = IPFW=20 functions for a few PCs at home, off of my cable modem. Wheneve I = attempt to=20 send an e-mail from my system I receive a message back from indicating = that the=20 message had permanent fatal erros, and the Domain of sender address somename@some_nonexiste= nt.domain=20 does not exist.
 
What I would like to knowis the = following, can I=20 configure sendmail to ignore this message and send the message anyway? = Or is=20 there some other way to overcome this issue.
 
Any guidance is = appreciated.
 
Regards,
Cameron
------=_NextPart_000_001D_01C10918.4356C670-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 6:41:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by hub.freebsd.org (Postfix) with ESMTP id 0E36B37B408 for ; Tue, 10 Jul 2001 06:41:07 -0700 (PDT) (envelope-from trensz@clarinet.u-strasbg.fr) Received: from clarinet.u-strasbg.fr (IDENT:trensz@localhost [127.0.0.1]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id PAA08341 for ; Tue, 10 Jul 2001 15:41:06 +0200 Message-ID: <3B4B05F1.38D26006@clarinet.u-strasbg.fr> Date: Tue, 10 Jul 2001 15:41:05 +0200 From: Clement Trensz X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: opt_inet6.h file Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'd like to use some functions from the /sys/net/if.c file but a few files such as opt_inet6.h, opt_inet.H, opt_compat.h are #defined and I can't find them on my machine. Does anybody know where I can get them? Thanks, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 7:19:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from shadow.otel.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 29C8137B406 for ; Tue, 10 Jul 2001 07:19:45 -0700 (PDT) (envelope-from tbyte@tbyte.org) Received: from localhost (localhost [127.0.0.1]) by shadow.otel.net (8.11.4/8.11.1) with ESMTP id f6AEJZ111840; Tue, 10 Jul 2001 17:19:35 +0300 (EEST) (envelope-from tbyte@tbyte.org) Date: Tue, 10 Jul 2001 17:19:35 +0300 (EEST) From: Iasen Kostoff X-Sender: tbyte@shadow.otel.net To: Clement Trensz Cc: freebsd-net@FreeBSD.ORG Subject: Re: opt_inet6.h file In-Reply-To: <3B4B05F1.38D26006@clarinet.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org They are auto generated by make depend I think.Should be in your kernel build directory. On Tue, 10 Jul 2001, Clement Trensz wrote: > Hi, > > I'd like to use some functions from the /sys/net/if.c file but a few > files such as opt_inet6.h, opt_inet.H, opt_compat.h are #defined and I > can't find them on my machine. Does anybody know where I can get them? > Thanks, > > > 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 Tue Jul 10 7:48:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f165.law11.hotmail.com [64.4.17.165]) by hub.freebsd.org (Postfix) with ESMTP id E633237B406 for ; Tue, 10 Jul 2001 07:48:33 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jul 2001 07:48:32 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 14:48:32 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: Help me to configure Date: Tue, 10 Jul 2001 14:48:32 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 14:48:32.0731 (UTC) FILETIME=[63F76AB0:01C1094F] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add –inet6 default –interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add –inet6 default –interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 8: 6:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f174.law11.hotmail.com [64.4.17.174]) by hub.freebsd.org (Postfix) with ESMTP id 1450537B419 for ; Tue, 10 Jul 2001 08:06:15 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Jul 2001 08:06:14 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 10 Jul 2001 15:06:14 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: Help me to configure Date: Tue, 10 Jul 2001 15:06:14 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2001 15:06:14.0916 (UTC) FILETIME=[DD13FC40:01C10951] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add –inet6 default –interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add –inet6 default –interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 8: 7:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by hub.freebsd.org (Postfix) with ESMTP id 2B80C37B408 for ; Tue, 10 Jul 2001 08:07:27 -0700 (PDT) (envelope-from lekostaj@mcs.anl.gov) Received: from fluffhead.mcs.anl.gov (fluffhead.mcs.anl.gov [140.221.10.70]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id KAA06072 for ; Tue, 10 Jul 2001 10:07:26 -0500 Received: (from lekostaj@localhost) by fluffhead.mcs.anl.gov (8.11.0/8.11.0) id f6AF7QS25859; Tue, 10 Jul 2001 10:07:26 -0500 X-Authentication-Warning: fluffhead.mcs.anl.gov: lekostaj set sender to lekostaj@fluffhead.mcs.anl.gov using -f To: freebsd-net@FreeBSD.org Subject: TCP window size From: Joseph Lekostaj Date: 10 Jul 2001 10:07:26 -0500 Message-ID: Lines: 21 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been trying to up my TCP window size from the default 16K and it's caused nothing but problems. From the info I've found so far, these are the sysctl i've changed: kern.ipc.maxsockbuffer=2097152 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=524288 net.inet.tcp.recvspace=524288 But if I do that, on boot I get all sorts of error messages about buffer space. i.e.: Jul 9 11:53:20 ccn64 portmap[180]: cannot create tcp socket: No buffer space available Jul 9 11:53:21 ccn64 inetd[199]: shell/tcp: socket: No buffer space available Jul 9 11:53:21 ccn64 inetd[199]: login/tcp: socket: No buffer space available Jul 9 11:58:55 ccn64 RPC::PlClient[243]: Cannot connect: No buffer space available Jul 9 11:58:55 ccn64 RPC::PlClient[246]: Cannot connect: No buffer space available Is there anything I'm missing? -- Joe LeKostaj ------------------------------------------------------------------------- Just don't create a file called -rf. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 8: 9:58 2001 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 9FFEC37B401 for ; Tue, 10 Jul 2001 08:09:54 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 34F934B21; Wed, 11 Jul 2001 00:09:47 +0900 (JST) To: "FreeBSDlover FreeBSDlover" Cc: freebsd-net@freebsd.org In-reply-to: freebsdlover's message of Tue, 10 Jul 2001 14:48:32 GMT. 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: Help me to configure From: itojun@iijlab.net Date: Wed, 11 Jul 2001 00:09:47 +0900 Message-ID: <917.994777787@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Hi, >Pls look at the following configuration. >--------- --------- >| | | | >| R |-------------------------| H | >| | | | >--------- ---------- >R = 192.168.3.1 H = 192.168.3.5 >H = 192.168.3.5 R = 192.168.3.1 >Step3: >ping6 -I gif0 ff02::1 >My Problem : IT DID NOT WORK >My Doubts: >1.Is this the proper configuration? >2.How to test configured tunneling mechanism in the above configuration >diagram. could you elaborate on "it did not work"? any interesting outputs? are you sure you made no typo on "gifconfig"? what is the IPv4 configuration for these boxes? "route -inet6 default" setting is not really necessary. try to diagnose if the packets are going through the ethernet interface, by using tcpdump on real ethernet device. ("tcpdump -n -i fxp0" if you are using fxp0 as ether interface) do you happen to have an packet filter on these nodes, or between them? if so, remove them. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 8:10:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.thenap.com (mailman.thenap.com [209.190.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 6BF8F37B409 for ; Tue, 10 Jul 2001 08:09:58 -0700 (PDT) (envelope-from drew.weaver@thenap.com) Received: by mailman.thenap.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 11:26:35 -0400 Message-ID: From: "Drew J. Weaver" To: freebsd-net@freebsd.org Subject: RE: Help me to configure Date: Tue, 10 Jul 2001 11:26:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10954.B4577D60" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10954.B4577D60 Content-Type: text/plain; charset="iso-8859-1" Ok i've gotten like 4 of these in the last two days please stop. Thanks, -Drew -----Original Message----- From: FreeBSDlover FreeBSDlover [mailto:freebsdlover@hotmail.com] Sent: Tuesday, July 10, 2001 11:06 AM To: freebsd-net@freebsd.org Subject: Help me to configure Hi, Pls look at the following configuration. --------- --------- | | | | | R |-------------------------| H | | | | | --------- ---------- R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 I have done the following steps Step1:In Router side ifconfig gif0 up gifconfig gif0 192.168.3.1 192.168.3.5 route add -inet6 default -interface gif0 Step2:In Host side ifconfig gif0 up gifconfig gif0 192.168.3.5 192.168.3.1 route add -inet6 default -interface gif0 Step3: ping6 -I gif0 ff02::1 My Problem : IT DID NOT WORK My Doubts: 1.Is this the proper configuration? 2.How to test configured tunneling mechanism in the above configuration diagram. with regds, FreeBSDlover _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message ------_=_NextPart_001_01C10954.B4577D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Help me to configure

Ok i've gotten like 4 of these in the last two days = please stop.

Thanks,
-Drew


-----Original Message-----
From: FreeBSDlover FreeBSDlover [mailto:freebsdlover@hotmail.com= ]
Sent: Tuesday, July 10, 2001 11:06 AM
To: freebsd-net@freebsd.org
Subject: Help me to configure


Hi,
Pls look at the following configuration.
---------         =             =       ---------
|        = |            = ;            = ; |         |
|     R  = |-------------------------|     H   = |
|        = |            = ;            = ; |         |
---------         =             =      ----------
R =3D = 192.168.3.1          &= nbsp;         H =3D = 192.168.3.5
H =3D = 192.168.3.5          &= nbsp;         R =3D = 192.168.3.1

I have done the following steps
Step1:In Router side
ifconfig gif0 up
gifconfig gif0 192.168.3.1 192.168.3.5
route add -inet6 default -interface gif0

Step2:In Host side
ifconfig gif0 up
gifconfig gif0 192.168.3.5 192.168.3.1
route add -inet6 default -interface gif0

Step3:
ping6 -I gif0 ff02::1
My Problem : IT DID NOT WORK
My Doubts:
1.Is this the proper configuration?
2.How to test configured tunneling mechanism in the = above configuration
diagram.

with regds,
FreeBSDlover


_______________________________________________________________= __________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


To Unsubscribe: send mail to = majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body = of the message

------_=_NextPart_001_01C10954.B4577D60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 9:53: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 06D6F37B403 for ; Tue, 10 Jul 2001 09:52:58 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f6AGqsG11805; Tue, 10 Jul 2001 09:52:54 -0700 (PDT) Message-ID: <3B4B32E6.A79B71EB@isi.edu> Date: Tue, 10 Jul 2001 09:52:54 -0700 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: FreeBSDlover FreeBSDlover Cc: freebsd-net@freebsd.org Subject: Re: tunneling in same link?? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0B8084A5BE30D8A8AFE39D6C" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms0B8084A5BE30D8A8AFE39D6C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FreeBSDlover FreeBSDlover wrote: > > Can i setup configured tunneling between a router and host which are in the > same network?If possible pls explain me. Yes, for network and app-layer tunnels. Not sure for lower layers. What are you setting up? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms0B8084A5BE30D8A8AFE39D6C 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 MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDcxMDE2NTI1NFowIwYJKoZIhvcNAQkEMRYE FPSyE+CtzHYJ2ryltvm39SZ6G4QJMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAmil/JfY9U3jJqV0b68Cx0QM97WjYU1WJewPix30Oj9mUdhBqGcel I8KzpVX08WVUgbrA8VCLQ3SsuOfT1QM3FphmE5gE/2og/XgsPfvmb2GDno2Pns+7IqjcEgBd 6hCpCufs9nG1vQt2kBb9va8EpagiVv6mW4VKvxkT3AHeKsY= --------------ms0B8084A5BE30D8A8AFE39D6C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 9:57: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 4FE3537B40E for ; Tue, 10 Jul 2001 09:56:54 -0700 (PDT) (envelope-from matt-l@pacbell.net) Received: from fire (1Cust214.tnt1.pasadena.ca.da.uu.net [63.28.226.214]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA19297; Tue, 10 Jul 2001 09:56:40 -0700 (PDT) Message-ID: <003401c10960$6e225a20$6503c23f@XGforce.com> Reply-To: "matt" From: "matt" To: "Cameron Haegle" , References: <002001c10942$2ca8dc40$420fbf8f@hlc02> Subject: Re: Sendmail Date: Tue, 10 Jul 2001 09:50:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C10925.BAF96130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C10925.BAF96130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DNS problem?=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WWW.XGFORCE.COM=20 The Next Generation Load Balance and=20 Fail Safe Server Clustering Software for the Internet. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- Original Message -----=20 From: Cameron Haegle=20 To: net@FreeBSD.ORG=20 Sent: Tuesday, July 10, 2001 6:13 AM Subject: Sendmail Before I dig too deep into the Sendmail documentation I wanted to = ensure that the following is possible. =20 My FreeBSD box is performing NATd and IPFW functions for a few PCs at = home, off of my cable modem. Wheneve I attempt to send an e-mail from my = system I receive a message back from indicating that the message had = permanent fatal erros, and the Domain of sender address = somename@some_nonexistent.domain does not exist. =20 What I would like to knowis the following, can I configure sendmail to = ignore this message and send the message anyway? Or is there some other = way to overcome this issue. =20 Any guidance is appreciated. =20 Regards, Cameron ------=_NextPart_000_0029_01C10925.BAF96130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
DNS problem?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
WWW.XGFORCE.COM
The Next = Generation Load=20 Balance and
Fail Safe Server Clustering Software
for the=20 Internet.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
----- Original Message -----
From:=20 Cameron=20 Haegle
Sent: Tuesday, July 10, 2001 = 6:13=20 AM
Subject: Sendmail

Before I dig too deep into the = Sendmail=20 documentation I wanted to ensure that the following is = possible.
 
My FreeBSD box is performing NATd and = IPFW=20 functions for a few PCs at home, off of my cable modem. Wheneve I = attempt to=20 send an e-mail from my system I receive a message back from indicating = that=20 the message had permanent fatal erros, and the Domain of sender = address somename@some_nonexiste= nt.domain=20 does not exist.
 
What I would like to knowis the = following, can I=20 configure sendmail to ignore this message and send the message anyway? = Or is=20 there some other way to overcome this issue.
 
Any guidance is = appreciated.
 
Regards,
Cameron
------=_NextPart_000_0029_01C10925.BAF96130-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 10:12:24 2001 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 61E1037B403 for ; Tue, 10 Jul 2001 10:12:20 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f6AHC7503088; Tue, 10 Jul 2001 13:12:07 -0400 (EDT) (envelope-from wollman) Date: Tue, 10 Jul 2001 13:12:07 -0400 (EDT) From: Garrett Wollman Message-Id: <200107101712.f6AHC7503088@khavrinen.lcs.mit.edu> To: Richard Smith Cc: net@FreeBSD.ORG Subject: sysctls keepidle and keepintvl In-Reply-To: <20010709230512.A918@gaia.home.rdls.net> References: <20010709230512.A918@gaia.home.rdls.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Looking at the comments in tcp_var.h, it should be > keepintvl that sets this interval. Otherwise, why > have such a large value for keepidle? FreeBSD contains a kluge wherein all TCP connections have a form of keepalive enabled by default. This is supposed to be separate from the explicitly-requested SO_KEEPALIVE, but it's possible that something got broken along the way. I think the intended behavior is as follows: - If the connection is idle for more than `keepidle', then we always send a keepalive (unless this behavior is disabled). - If SO_KEEPALIVE has been enabled on the socket, then send a keepalive every `keepintvl' of idle time. The reason `keepidle' is so long is that it was a compromise between one group which wanted keepalives at very long intervals so that one could temporarily disconnect -- or even suspend -- one's system without getting all of one's connections killed, and another group which wanted short intervals to quickly flush broken connections resulting from unclean shutdown of Windows clients. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 10:34:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by hub.freebsd.org (Postfix) with ESMTP id 6962637B401 for ; Tue, 10 Jul 2001 10:34:50 -0700 (PDT) (envelope-from FastPathNow@netscape.net) Received: from FastPathNow@netscape.net by imo-d01.mx.aol.com (mail_out_v31.6.) id 7.10a.3b235c (16242); Tue, 10 Jul 2001 13:34:15 -0400 (EDT) Received: from netscape.com (aimmail05.aim.aol.com [205.188.144.197]) by air-in03.mx.aol.com (v78_r3.8) with ESMTP; Tue, 10 Jul 2001 13:34:15 -0400 Date: Tue, 10 Jul 2001 13:34:15 -0400 From: FastPathNow@netscape.net To: lekostaj@mcs.anl.gov Cc: freebsd-net@freebsd.org Mime-Version: 1.0 Message-ID: <6833EC93.7369A9B8.375A6AF3@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Try restricting sendspace and recvspace to 256K. If you're adventurous, try recompiling the kernel after bumping up the #define SB_MAX (in /usr/src/sys/sys/socketvar.h) beyond the default value of 256*1024 -AG ----- I've been trying to up my TCP window size from the default 16K and it's caused nothing but problems. From the info I've found so far, these are the sysctl i've changed: kern.ipc.maxsockbuffer=2097152 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=524288 net.inet.tcp.recvspace=524288 But if I do that, on boot I get all sorts of error messages about buffer space. i.e.: Jul 9 11:53:20 ccn64 portmap[180]: cannot create tcp socket: No buffer space available Jul 9 11:53:21 ccn64 inetd[199]: shell/tcp: socket: No buffer space available Jul 9 11:53:21 ccn64 inetd[199]: login/tcp: socket: No buffer space available Jul 9 11:58:55 ccn64 RPC::PlClient[243]: Cannot connect: No buffer space available Jul 9 11:58:55 ccn64 RPC::PlClient[246]: Cannot connect: No buffer space available Is there anything I'm missing? -- Joe LeKostaj ------------------------------------------------------------------------- Just don't create a file called -rf. To Unsubscribe: send mail to majordomo@FreeBSD.org __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 11: 9:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail17.messagelabs.com (mail17.messagelabs.com [62.231.131.67]) by hub.freebsd.org (Postfix) with SMTP id 480C537B405 for ; Tue, 10 Jul 2001 11:09:29 -0700 (PDT) (envelope-from rdls@satamatics.com) X-VirusChecked: Checked Received: (qmail 27060 invoked from network); 10 Jul 2001 17:58:21 -0000 Received: from smtp-5.star.net.uk (212.125.75.74) by server-8.tower-17.messagelabs.com with SMTP; 10 Jul 2001 17:58:21 -0000 Received: (qmail 10968 invoked from network); 10 Jul 2001 18:09:27 -0000 Received: from unallocated.star.net.uk (HELO dns.hq.satamatics.net) (62.231.144.3) by smtp-5.star.net.uk with SMTP; 10 Jul 2001 18:09:27 -0000 Received: from matrix.satamatics.net (matrix.satamatics.net [10.24.1.1]) by dns.hq.satamatics.net (8.11.3/8.11.3) with ESMTP id f6AJC9E37167 for ; Tue, 10 Jul 2001 19:12:09 GMT (envelope-from rdls@satamatics.com) Subject: RE: sysctls keepidle and keepintvl Date: Tue, 10 Jul 2001 19:06:31 +0100 Message-ID: <703AB71471B6024CB86D219058DB64FB02E143@matrix.satamatics.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sysctls keepidle and keepintvl X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcEJYxkh6RLcEV53TNuxoynD3z2JBQABrliw content-class: urn:content-classes:message From: "Richard Smith" To: "Garrett Wollman" Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Garrett Wollman [mailto:wollman@khavrinen.lcs.mit.edu] > Sent: 10 July 2001 18:12 > To: Richard Smith > Cc: net@FreeBSD.ORG > Subject: sysctls keepidle and keepintvl >=20 >=20 > < said: >=20 > > Looking at the comments in tcp_var.h, it should be=20 > > keepintvl that sets this interval. Otherwise, why > > have such a large value for keepidle? >=20 > FreeBSD contains a kluge wherein all TCP connections have a form of > keepalive enabled by default. This is supposed to be separate from > the explicitly-requested SO_KEEPALIVE, but it's possible that > something got broken along the way. I think the intended behavior is > as follows: >=20 > - If the connection is idle for more than `keepidle', then we always > send a keepalive (unless this behavior is disabled). >=20 > - If SO_KEEPALIVE has been enabled on the socket, then send a > keepalive every `keepintvl' of idle time. Answering my own question almost: The SO_KEEPALIVE and the sysctl net.inet.tcp.always_keepalive are logically ORed. The keepalive is sent after 'keepidle' and thereafter at 'keepintvl' intervals unless a response is received, in which case it goes back to using 'keepidle'. > The reason `keepidle' is so long is that it was a compromise between > one group which wanted keepalives at very long intervals so that one > could temporarily disconnect -- or even suspend -- one's system > without getting all of one's connections killed, and another group > which wanted short intervals to quickly flush broken connections > resulting from unclean shutdown of Windows clients. I understand, but 2 hours ??? :-) Anyway, I have added my own value of 240s to sysctl.conf which is sufficiently below the 300s value of net.inet.ip.fw.dyn_ack_lifetime to serve my purposes. Thanks, Rich. _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 12:22:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from fubar.net-ninja.com (cc260960-a.mdlvly1.tn.home.com [65.14.125.177]) by hub.freebsd.org (Postfix) with ESMTP id 18EAF37B401 for ; Tue, 10 Jul 2001 12:22:43 -0700 (PDT) (envelope-from sz@cdc.net) Received: by fubar.net-ninja.com (Postfix, from userid 100) id 6DB7788A63; Tue, 10 Jul 2001 15:22:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by fubar.net-ninja.com (Postfix) with ESMTP id 58C2243763 for ; Tue, 10 Jul 2001 15:22:12 -0400 (EDT) Date: Tue, 10 Jul 2001 15:22:12 -0400 (EDT) From: Eric Parker X-X-Sender: To: Subject: PCMCIA Card in FreeBSD 4.3 (second post) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having some problems with a couple of PCMCIA ethernet cards in FreeBSD 4.3. First, a quick history of what I have done. I have 2 Vaio laptop computers, a Cisco Aironet 340 series wireless card, and a LinkSys 10/100 PC Card (PCM100). I tested the LinkSys card in my laptop when I first got it and it worked flawlessly (pccard.conf already has 0x80000 in it), then I started working on the wireless card. I now have the wireless card working perfectly, but when I try to get the LinkSys card to work now, funky things start to happen. If I just boot straight up with the LinkSys card, I get the following error message: ed1: device timeout But, if I remove it, put in the wireless card, then put back in the LinkSys card, it works fine. It's seems like some odd IRQ issue that the wireless card fixes. Now for the weird part. I have tried to get the wireless card working on another laptop running the same FreeBSD install and get the same error message as with the LinkSys on mine: device timeout. This leads me to believe I am missing something during the setup somewhere. I have racked my brain trying to figure out what I am missing, but I can't seem to figure it out. Help! :) ------ Eric Parker Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 13: 6:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.guest-tek.com (mail.guesttek.com [139.142.1.74]) by hub.freebsd.org (Postfix) with ESMTP id 14A2237B408 for ; Tue, 10 Jul 2001 13:06:51 -0700 (PDT) (envelope-from peter@guest-tek.com) Received: from localhost ([139.142.135.115]) by mail.guest-tek.com (8.9.3/8.8.7) with ESMTP id OAA19966 for ; Tue, 10 Jul 2001 14:03:34 -0600 Message-Id: <200107102003.OAA19966@mail.guest-tek.com> Date: Tue, 10 Jul 2001 14:06:49 -0600 Content-Type: text/plain; format=flowed; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v388) From: Peter Warrick To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.388) Content-Transfer-Encoding: 7bit Subject: IPFW and NATD Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was referred to you by an Archie Cobbs who I guess did some of the ipfw code in FreeBSD? I have a question that I'm hoping someone over on your end might be able to help me with. I apologize if this email has reached the wrong person btw. :) I have setup a server with 2 NIC cards and have natd running on en0 (natd -interface en0). When I execute the ipfw command.... ipfw add divert natd all from any to any via en0 everything works find and all my computers behind my server are able to get out to the Internet. But when I try to just divert one IP on my private network it doesn't work. I need this functionality to be able to specify only certain machines to be nated. The command I used was... ipfw add divert natd all from 192.168.1.2 to any via en0 192.168.1.2 is the IP of the local machine behind my server and the IP of en1 which this machine is connected to is 192.168.1.1 which I have setup as my gateway on my local machine. Do you have any ideas why this doesn't work or what I have done wrong? Do I need to type in another command? Thank you for your time and any help you might be able to provide. Peter Warrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 13:29:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id AAB8A37B403 for ; Tue, 10 Jul 2001 13:29:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA55042; Tue, 10 Jul 2001 15:15:11 -0700 (PDT) Date: Tue, 10 Jul 2001 15:15:10 -0700 (PDT) From: Julian Elischer To: Peter Warrick Cc: freebsd-net@freebsd.org Subject: Re: IPFW and NATD In-Reply-To: <200107102003.OAA19966@mail.guest-tek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You need to divert bith directions. On Tue, 10 Jul 2001, Peter Warrick wrote: > I was referred to you by an Archie Cobbs who I guess did some of the > ipfw code in FreeBSD? I have a question that I'm hoping someone over on > your end might be able to help me with. I apologize if this email has > reached the wrong person btw. :) > > I have setup a server with 2 NIC cards and have natd running on en0 > (natd -interface en0). When I execute the ipfw command.... > > ipfw add divert natd all from any to any via en0 > > everything works find and all my computers behind my server are able to > get out to the Internet. But when I try to just divert one IP on my > private network it doesn't work. I need this functionality to be able to > specify only certain machines to be nated. The command I used was... > > ipfw add divert natd all from 192.168.1.2 to any via en0 Unfortunatly as you don't know what the outgoing session looks like you have to divert all incoming packets to natd to let it take it's pick. ipfw add divert natd ip from any to in recv en0 This assumes that natd is set up to allow non-matching packets proceeed on their way. > > 192.168.1.2 is the IP of the local machine behind my server and the IP > of en1 which this machine is connected to is 192.168.1.1 which I have > setup as my gateway on my local machine. > > Do you have any ideas why this doesn't work or what I have done wrong? > Do I need to type in another command? > > Thank you for your time and any help you might be able to provide. > > Peter Warrick. > > 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 Tue Jul 10 13:36:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from jezebel.demon.co.uk (jezebel.demon.co.uk [158.152.38.143]) by hub.freebsd.org (Postfix) with ESMTP id DC96D37B408 for ; Tue, 10 Jul 2001 13:36:09 -0700 (PDT) (envelope-from rdls@jezebel.demon.co.uk) Received: (from rdls@localhost) by jezebel.demon.co.uk (8.11.1/8.11.1) id f69MhIv01258; Mon, 9 Jul 2001 23:43:18 +0100 (BST) (envelope-from rdls) Date: Mon, 9 Jul 2001 23:43:18 +0100 From: Richard Smith To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: sysctls keepidle and keepintvl Message-ID: <20010709234317.A1235@gaia.home.rdls.net> References: <20010709230512.A918@gaia.home.rdls.net> <200107092207.AAA11018@info.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107092207.AAA11018@info.iet.unipi.it>; from luigi@info.iet.unipi.it on Tue, Jul 10, 2001 at 12:07:55AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 10, 2001 at 12:07:55AM +0200, Luigi Rizzo wrote: > > Please cc me, as I'm not on this list. > > > > I am using 4.3-RELEASE, and investigating why I don't see > > any keepalives (using tcpdump) on my connections. > > > > The default values are as follows: > > net.inet.tcp.keepidle = 7200000 > > net.inet.tcp.keepintvl = 75000 > > > > It seems to me that the keepalive interval is being set > > by keepidle, thus setting keepidle = 20000, generates > > keepalives at 20s intervals. > > whatever is used, isn't the interval in seconds ? If so > you must be very patient to see something... No, the tcp sysctls are in ms. Looking through the code, however, I now understand the relationship between keepidle and keepintvl. The value of keepidle has been 120 minutes (7200000) since the beginning of CVS. I was rather hoping to keep a dynamic firewall open with keepalives :-) So I need to set: keepidle < net.inet.ip.fw.dyn_ack_lifetime. Problem solved. Thanks, Rich. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 13:39:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id D8EDA37B406 for ; Tue, 10 Jul 2001 13:39:29 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f6AM6YO51454; Tue, 10 Jul 2001 17:06:35 -0500 (CDT) (envelope-from nick@rogness.net) Date: Tue, 10 Jul 2001 17:06:34 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Warrick Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW and NATD In-Reply-To: <200107102003.OAA19966@mail.guest-tek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Jul 2001, Peter Warrick wrote: > I was referred to you by an Archie Cobbs who I guess did some of the > ipfw code in FreeBSD? I have a question that I'm hoping someone over > on your end might be able to help me with. I apologize if this email > has reached the wrong person btw. :) I think this belongs on freebsd-questions...but I'll answer anyway. > > I have setup a server with 2 NIC cards and have natd running on en0 > (natd -interface en0). When I execute the ipfw command.... > > ipfw add divert natd all from any to any via en0 > > everything works find and all my computers behind my server are able > to get out to the Internet. But when I try to just divert one IP on my > private network it doesn't work. I need this functionality to be able > to specify only certain machines to be nated. The command I used > was... > > ipfw add divert natd all from 192.168.1.2 to any via en0 > > 192.168.1.2 is the IP of the local machine behind my server and the IP > of en1 which this machine is connected to is 192.168.1.1 which I have > setup as my gateway on my local machine. > > Do you have any ideas why this doesn't work or what I have done wrong? > Do I need to type in another command? You need to add another rule: ipfw add divert natd all from $PUBLIC_IP to any in via en0 The $PUBLIC_IP should be the IP of en0. This will only work if your non-diverted traffic is using a different public IPs...which I'm assuming you are. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 14:29:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 992FA37B403 for ; Tue, 10 Jul 2001 14:29:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA55250; Tue, 10 Jul 2001 16:14:18 -0700 (PDT) Date: Tue, 10 Jul 2001 16:14:17 -0700 (PDT) From: Julian Elischer To: Nick Rogness Cc: Peter Warrick , freebsd-net@FreeBSD.ORG Subject: Re: IPFW and NATD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Jul 2001, Nick Rogness wrote: > You need to add another rule: > > ipfw add divert natd all from $PUBLIC_IP to any in via en0 ^ ^ \----------/ swap these > > The $PUBLIC_IP should be the IP of en0. This will only work if > your non-diverted traffic is using a different public IPs...which > I'm assuming you are. OR you don NOT want other machines to be able to get out. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 14:39:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 6320537B409 for ; Tue, 10 Jul 2001 14:39:07 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f6AN69T51879; Tue, 10 Jul 2001 18:06:09 -0500 (CDT) (envelope-from nick@rogness.net) Date: Tue, 10 Jul 2001 18:06:09 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Julian Elischer Cc: Peter Warrick , freebsd-net@FreeBSD.ORG Subject: Re: IPFW and NATD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Jul 2001, Julian Elischer wrote: > > > On Tue, 10 Jul 2001, Nick Rogness wrote: > > You need to add another rule: > > > > ipfw add divert natd all from $PUBLIC_IP to any in via en0 > ^ ^ > \----------/ > swap these > > > > > > The $PUBLIC_IP should be the IP of en0. This will only work if > > your non-diverted traffic is using a different public IPs...which > > I'm assuming you are. > > OR you don NOT want other machines to be able to get out. Ooops...yep he's right...relized that after I read Julian's original response. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 14:42:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.guest-tek.com (mail.guesttek.com [139.142.1.74]) by hub.freebsd.org (Postfix) with ESMTP id E51F337B401 for ; Tue, 10 Jul 2001 14:42:18 -0700 (PDT) (envelope-from peter@guest-tek.com) Received: from localhost ([139.142.135.115]) by mail.guest-tek.com (8.9.3/8.8.7) with ESMTP id PAA21656; Tue, 10 Jul 2001 15:38:46 -0600 Message-Id: <200107102138.PAA21656@mail.guest-tek.com> Date: Tue, 10 Jul 2001 15:41:59 -0600 From: Peter Warrick Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: IPFW and NATD Cc: Nick Rogness , freebsd-net@FreeBSD.ORG To: Julian Elischer X-Mailer: Apple Mail (2.388) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hmm.. I'm not sure which ones you want me to swap? I think the tabs are getting messed up.. It looks like I should swap natd and from but that can't be right? Ahh there we go.. Swap the any and the 139 address.. That worked.. Thanks a lot you two! :) Pete On Tuesday, July 10, 2001, at 05:14 PM, Julian Elischer wrote: > > > On Tue, 10 Jul 2001, Nick Rogness wrote: >> You need to add another rule: >> >> ipfw add divert natd all from $PUBLIC_IP to any in via en0 > ^ ^ > \----------/ > swap these > > >> >> The $PUBLIC_IP should be the IP of en0. This will only work if >> your non-diverted traffic is using a different public IPs...which >> I'm assuming you are. > > OR you don NOT want other machines to be able to get out. > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 15:35:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from magpie.csie.nctu.edu.tw (magpie.csie.nctu.edu.tw [140.113.209.21]) by hub.freebsd.org (Postfix) with ESMTP id 2279837B405 for ; Tue, 10 Jul 2001 15:35:36 -0700 (PDT) (envelope-from freedom@magpie.csie.nctu.edu.tw) Received: (from freedom@localhost) by magpie.csie.nctu.edu.tw (8.11.3/8.11.2) id f6AMZNx25380; Wed, 11 Jul 2001 06:35:23 +0800 (CST) (envelope-from freedom) Date: Wed, 11 Jul 2001 06:35:23 +0800 From: Tan Koan-Sin To: Joseph Lekostaj Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP window size Message-ID: <20010711063523.A25039@magpie.csie.nctu.edu.tw> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lekostaj@mcs.anl.gov on Tue, Jul 10, 2001 at 10:07:26AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't think increasing kern.ipc.maxsockbuffer to such a big number is a good idea. You may want either reduce this value or increase maximum number of mbufs by setting NMBCLUSTERS in your kernel configuration file. On Tue, Jul 10, 2001 at 10:07:26AM -0500, Joseph Lekostaj wrote: > I've been trying to up my TCP window size from the default 16K and it's caused nothing but problems. From the info I've found so far, these are the sysctl i've changed: > > kern.ipc.maxsockbuffer=2097152 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendspace=524288 > net.inet.tcp.recvspace=524288 > > But if I do that, on boot I get all sorts of error messages about buffer space. i.e.: > > Jul 9 11:53:20 ccn64 portmap[180]: cannot create tcp socket: No buffer space available > Jul 9 11:53:21 ccn64 inetd[199]: shell/tcp: socket: No buffer space available > Jul 9 11:53:21 ccn64 inetd[199]: login/tcp: socket: No buffer space available > Jul 9 11:58:55 ccn64 RPC::PlClient[243]: Cannot connect: No buffer space available > Jul 9 11:58:55 ccn64 RPC::PlClient[246]: Cannot connect: No buffer space available > > Is there anything I'm missing? > > -- > Joe LeKostaj > ------------------------------------------------------------------------- > Just don't create a file called -rf. > > 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 Tue Jul 10 16:13: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.guest-tek.com (mail.guesttek.com [139.142.1.74]) by hub.freebsd.org (Postfix) with ESMTP id EF92737B401 for ; Tue, 10 Jul 2001 16:13:02 -0700 (PDT) (envelope-from peter@guest-tek.com) Received: from localhost ([139.142.135.115]) by mail.guest-tek.com (8.9.3/8.8.7) with ESMTP id RAA23397; Tue, 10 Jul 2001 17:09:14 -0600 Message-Id: <200107102309.RAA23397@mail.guest-tek.com> Date: Tue, 10 Jul 2001 17:12:28 -0600 From: Peter Warrick Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: IPFW and NATD Cc: Julian Elischer , freebsd-net@FreeBSD.ORG To: Nick Rogness X-Mailer: Apple Mail (2.388) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok one last question.. :) I am trying to redirect all the traffic on a certain port except for a couple of computers.. I have this rule setup to do this.. fwd 139.142.135.115 tcp from any to any 80 How would I then make it so that those couple of machines are not effected.. I've tried the following.. allow tcp from 192.168.0.2 to any 80 via en0 allow tcp from any 80 to 192.168.0.2 in recv en0 allow tcp from 192.168.0.2 to any 80 via en1 allow tcp from any 80 to 192.168.0.2 in recv en1 allow tcp from 1.2.3.5 to any 80 None of these have worked either alone or together.. Any ideas?? Thanks again. Peter. On Tuesday, July 10, 2001, at 05:06 PM, Nick Rogness wrote: > On Tue, 10 Jul 2001, Julian Elischer wrote: > >> >> >> On Tue, 10 Jul 2001, Nick Rogness wrote: >>> You need to add another rule: >>> >>> ipfw add divert natd all from $PUBLIC_IP to any in via en0 >> ^ ^ >> \----------/ >> swap these >> >> >>> >>> The $PUBLIC_IP should be the IP of en0. This will only work if >>> your non-diverted traffic is using a different public IPs...which >>> I'm assuming you are. >> >> OR you don NOT want other machines to be able to get out. > > Ooops...yep he's right...relized that after I read Julian's > original response. > > > Nick Rogness > - Keep on Routing in a Free World... > "FreeBSD: The Power to Serve!" > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 10 16:49:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6B4DC37B403 for ; Tue, 10 Jul 2001 16:49:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA55834; Tue, 10 Jul 2001 18:35:59 -0700 (PDT) Date: Tue, 10 Jul 2001 18:35:59 -0700 (PDT) From: Julian Elischer To: Peter Warrick Cc: Nick Rogness , freebsd-net@FreeBSD.ORG Subject: Re: IPFW and NATD In-Reply-To: <200107102309.RAA23397@mail.guest-tek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I 'm not sure I understand but.... firstly.. the 'fwd' keyword DOES NOT ALTER THE PACKET so you need to have the same rule on 139.142.135.115 so that the incoming packet is captured there, whe it gets there, as the headers still say that it's supposed to go somewhere else. On Tue, 10 Jul 2001, Peter Warrick wrote: > Ok one last question.. :) > > I am trying to redirect all the traffic on a certain port except for a > couple of computers.. I have this rule setup to do this.. > > fwd 139.142.135.115 tcp from any to any 80 > > How would I then make it so that those couple of machines are not > effected.. I've tried the following.. > > allow tcp from 192.168.0.2 to any 80 via en0 > allow tcp from any 80 to 192.168.0.2 in recv en0 > allow tcp from 192.168.0.2 to any 80 via en1 > allow tcp from any 80 to 192.168.0.2 in recv en1 > allow tcp from 1.2.3.5 to any 80 please draw a diagram.. I can't figure out what you want to do.. (I think the answer is to make the exceptions 'skipto' past the line that does the fwd.) > > None of these have worked either alone or together.. Any ideas?? > > Thanks again. > > Peter. > > On Tuesday, July 10, 2001, at 05:06 PM, Nick Rogness wrote: > > > On Tue, 10 Jul 2001, Julian Elischer wrote: > > > >> > >> > >> On Tue, 10 Jul 2001, Nick Rogness wrote: > >>> You need to add another rule: > >>> > >>> ipfw add divert natd all from $PUBLIC_IP to any in via en0 > >> ^ ^ > >> \----------/ > >> swap these > >> > >> > >>> > >>> The $PUBLIC_IP should be the IP of en0. This will only work if > >>> your non-diverted traffic is using a different public IPs...which > >>> I'm assuming you are. > >> > >> OR you don NOT want other machines to be able to get out. > > > > Ooops...yep he's right...relized that after I read Julian's > > original response. > > > > > > Nick Rogness > > - Keep on Routing in a Free World... > > "FreeBSD: The Power to Serve!" > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 2:20:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from nw176.netaddress.usa.net (nw176.netaddress.usa.net [204.68.24.76]) by hub.freebsd.org (Postfix) with SMTP id D9A5C37B401 for ; Wed, 11 Jul 2001 02:20:36 -0700 (PDT) (envelope-from mason_jar@usa.net) Received: (qmail 10698 invoked by uid 60001); 11 Jul 2001 09:20:36 -0000 Message-ID: <20010711092036.10697.qmail@nw176.netaddress.usa.net> Received: from 204.68.24.76 by nw176 for [194.237.142.99] via web-mailer(34FM.0700.18.03B) on Wed Jul 11 09:20:36 GMT 2001 Date: 11 Jul 2001 03:20:36 MDT From: To: freebsd-net@freebsd.org Subject: Running IPv6 X-Mailer: USANET web-mailer (34FM.0700.18.03B) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I have a small "testing-network" with two computers running FreeBSD 4.3 t= hat are _not connected to the Internet_ but connected to eachother. = They have two ethernet-cards each. = What I want to do is to start playing with IPv6 and to start communicate between these two computers with IPv6 but I don't know how to configure FreeBSD to do this, if possible. Can someone help me or point out some tutorial on this. Best regards, Andreas = To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 8:13: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by hub.freebsd.org (Postfix) with ESMTP id 9DF5A37B406 for ; Wed, 11 Jul 2001 08:12:51 -0700 (PDT) (envelope-from Martin.Karsten@KOM.tu-darmstadt.de) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id RAA16926; Wed, 11 Jul 2001 17:12:42 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.9.3/8.7.5) id RAA30280; Wed, 11 Jul 2001 17:12:43 +0200 Message-Id: <200107111512.RAA30280@KOM.tu-darmstadt.de> Subject: UDP packet loss on FreeBSD 4.x To: freebsd-net@freebsd.org Date: Wed, 11 Jul 2001 17:12:43 +0200 (CEST) Cc: oscar@ac.upc.es X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings, I have observed the following behaviour on FreeBSD 4.x platforms (4.0 till 4.3 seem to be affected). When receiving a sufficiently fast stream of UDP packets (the borderline seems to be around 3,500 packets/sec for e.g. the 'xl' driver on a 450MHz Pentium), an application on the receiving host does not receive all packets anymore, depending on which nic driver is used. A fraction of the lost packets is reported in net.inet.ip.intr_queue_drops, but not all. Tests have shown that the losses occur for the 'xl' or 'ti' drivers, whereas the 'fxp' and 'de' driver don't seem to be affected. On FreeBSD 3.4, no such losses happened and one could easily transmit more than 10,000 packets/sec between adjacent machines. Is this a knowm problem and is there a chance that it is fixed? Is there potentially a quick solution for it? Further, might this problem be related to an earlier report (08 Jan 2001) sent with the subject "On the performance of the xl driver" by Oscar-Ivan Lepe-Aldama? Thanks in advance, Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 9:40:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A3CF237B401 for ; Wed, 11 Jul 2001 09:40:47 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6BGeJ797937; Wed, 11 Jul 2001 19:40:19 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Jul 2001 19:40:19 +0300 From: Ruslan Ermilov To: Mark Blackman Cc: freebsd-net@FreeBSD.ORG Subject: Re: default route disappears on address changes for interface. Message-ID: <20010711194019.A97306@sunbay.com> Mail-Followup-To: Mark Blackman , freebsd-net@FreeBSD.ORG References: <200107091035.LAA90463@mailhost2.dircon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107091035.LAA90463@mailhost2.dircon.co.uk>; from mark.blackman@netscalibur.co.uk on Mon, Jul 09, 2001 at 11:35:29AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 11:35:29AM +0100, Mark Blackman wrote: > > on FreeBSD 4.3-STABLE #1: Thu May 24 13:03:35 BST 2001 > > Is it now standard/expected behaviour that default routes > disappear on an IP address change even within the same netmask > or even to the same address if the default route is on that > interface? > > Say I've got the following setup. > > ifconfig ep0 inet 10.0.0.1 netmask 255.255.255.0 > route add default 10.0.0.254 > > then i do > > ifconfig ep0 inet 10.0.0.2 (or even 10.0.0.1) > > suddenly my default route disappears. Is this expected > behaviour and has this always been the case? I'm pretty > sure it wasn't. > Yes. The previous routing code behavior was incorrect, since it did not update the address in the rtentry structure, and the old IP address (10.0.0.1) was still being used for anonymous (with ip_src of INADDR_ANY) IP datagrams. See PR kern/20785 for details, as well as the comment in the sys/netinet/in_rmx.c, before the in_ifadownkill() function. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 9:50:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.sysadmin-inc.com (ns2.sysadmin-inc.com [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id B30A737B401 for ; Wed, 11 Jul 2001 09:50:35 -0700 (PDT) (envelope-from peter@sysadmin-inc.com) Received: (qmail 13502 invoked by alias); 11 Jul 2001 16:50:33 -0000 Received: from unknown (HELO 98wkst) (10.10.1.70) by ns2.sysadmin-inc.com with SMTP; 11 Jul 2001 16:50:33 -0000 From: "Peter Brezny" To: Subject: need help with divert to avoid dual dns..is it possible? Date: Wed, 11 Jul 2001 12:49:58 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to come up with a way to avoid having to run an internal and an external dns for our network. Here's the basic layout. primary +--private LAN 1 router | internet --- ipfw with nat --+--private LAN 2 | +--private LAN 3 Each of these private LAN's have public services run on boxes with a static nat address assigned to them from the primary ipfw with nat box. So if someone wants to browse a web hosted on private LAN 1 from the public internet, no problem, the dns points them to the public ip on the primary router designated to static nat to a box on private LAN 1. However, if someone on private lan2 makes the same request, using the public DNS, the packet never arrives because it never goes through the external interface on the primary router and therefore does not get translated to the private ip on the destination box. To overcome this problem, I've created an internal dns that points requests made from within the private LAN space direct to the private ip's of the boxes hosting the public services. However, I'd like to eliminate this requirement. I attempted to work something out with the ipfw fwd action, but I don't think I really understand how fwd works and I'm guessing it's not really meant to do what I'm after. The other thought I had was to run a second instance of natd on the internal interface with the -redirect_address option and a specific list of static nat redirects in internal_natd.conf, however, I don't want public packets source ip's translated to the internal interface ip as they leave the internal interface headed for the private networks. Is there another flag, similar to -unregistered_only where I could specify that natd translate _only_ addresses coming into the internal interface bound for specific addresses listed in natd.conf for static nat? OR... is there another way to do this without using a divert socket, something just within ipfw. Thanks a lot for taking the time to read through all this. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 10:31:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 155C637B406 for ; Wed, 11 Jul 2001 10:31:26 -0700 (PDT) (envelope-from matt-l@pacbell.net) Received: from fire (1Cust243.tnt1.pasadena.ca.da.uu.net [63.28.226.243]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id KAA04986; Wed, 11 Jul 2001 10:31:22 -0700 (PDT) Message-ID: <003f01c10a2e$6ccb4a00$6503c23f@XGforce.com> Reply-To: "matt" From: "matt" To: "Peter Brezny" , References: Subject: Re: need help with divert to avoid dual dns..is it possible? Date: Wed, 11 Jul 2001 10:25:02 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, if ipfw cann't do the work, you can check out ipfilter module as well. It's a bit different in nat code. ====================================== WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. ====================================== ----- Original Message ----- From: Peter Brezny To: Sent: Wednesday, July 11, 2001 9:49 AM Subject: need help with divert to avoid dual dns..is it possible? > I'm trying to come up with a way to avoid having to run an internal and an > external dns for our network. > > Here's the basic layout. > > primary +--private LAN 1 > router | > internet --- ipfw with nat --+--private LAN 2 > | > +--private LAN 3 > > > Each of these private LAN's have public services run on boxes with a static > nat address assigned to them from the primary ipfw with nat box. > > So if someone wants to browse a web hosted on private LAN 1 from the public > internet, no problem, the dns points them to the public ip on the primary > router designated to static nat to a box on private LAN 1. > > However, if someone on private lan2 makes the same request, using the public > DNS, the packet never arrives because it never goes through the external > interface on the primary router and therefore does not get translated to the > private ip on the destination box. > > To overcome this problem, I've created an internal dns that points requests > made from within the private LAN space direct to the private ip's of the > boxes hosting the public services. > > However, I'd like to eliminate this requirement. > > I attempted to work something out with the ipfw fwd action, but I don't > think I really understand how fwd works and I'm guessing it's not really > meant to do what I'm after. > > The other thought I had was to run a second instance of natd on the internal > interface with the -redirect_address option and a specific list of static > nat redirects in internal_natd.conf, however, I don't want public packets > source ip's translated to the internal interface ip as they leave the > internal interface headed for the private networks. > > Is there another flag, similar to -unregistered_only where I could specify > that natd translate _only_ addresses coming into the internal interface > bound for specific addresses listed in natd.conf for static nat? > > OR... > > is there another way to do this without using a divert socket, something > just within ipfw. > > Thanks a lot for taking the time to read through all this. > > Peter Brezny > SysAdmin Services Inc. > > > 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 Wed Jul 11 10:36:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id DDE0D37B403 for ; Wed, 11 Jul 2001 10:36:43 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6BHYtL02811; Wed, 11 Jul 2001 20:34:55 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Jul 2001 20:34:55 +0300 From: Ruslan Ermilov To: Brian Somers Cc: Mark Blackman , freebsd-net@FreeBSD.ORG Subject: Re: default route disappears on address changes for interface. Message-ID: <20010711203455.A99297@sunbay.com> Mail-Followup-To: Brian Somers , Mark Blackman , freebsd-net@FreeBSD.ORG References: <200107091041.f69AfbQ61858@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107091041.f69AfbQ61858@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Mon, Jul 09, 2001 at 11:41:37AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 11:41:37AM +0100, Brian Somers wrote: > ifconfig(8) deletes and re-adds the given address. When the delete > happens, the route (now) disappears. > > IMHO, ifconfig(8) should be smart enough to optimise out no-ops. > I found that using SIOCSIFADDR (though deprecated) to be beneficial in this case. It simply "changes" the interface's address rather than deleting an old address and adding a new one. This preserves all routes holding on this address. Here is the hackish code that does this. Index: ifconfig.c =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.64 diff -u -p -r1.64 ifconfig.c --- ifconfig.c 2001/07/02 20:52:34 1.64 +++ ifconfig.c 2001/07/11 17:30:36 @@ -707,6 +707,12 @@ ifconfig(argc, argv, afp) Perror("Encapsulation Routing"); } #endif + if (clearaddr && newaddr && setaddr && afp->af_af == AF_INET) { + strncpy(afp->af_addreq, name, sizeof ifr.ifr_name); + if (ioctl(s, SIOCSIFADDR, afp->af_addreq) < 0) + Perror("ioctl (SIOCSIFADDR)"); + goto out; + } if (clearaddr) { if (afp->af_ridreq == NULL || afp->af_difaddr == 0) { warnx("interface %s cannot change %s addresses!", @@ -736,6 +742,7 @@ ifconfig(argc, argv, afp) if (ioctl(s, afp->af_aifaddr, afp->af_addreq) < 0) Perror("ioctl (SIOCAIFADDR)"); } +out: close(s); return(0); } Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 13:33:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 074D537B405 for ; Wed, 11 Jul 2001 13:33:26 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 2413 invoked by uid 1000); 11 Jul 2001 20:33:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jul 2001 20:33:24 -0000 Date: Wed, 11 Jul 2001 15:33:24 -0500 (CDT) From: Mike Silbersack To: Martin Karsten Cc: , Subject: Re: UDP packet loss on FreeBSD 4.x In-Reply-To: <200107111512.RAA30280@KOM.tu-darmstadt.de> Message-ID: <20010711153113.L2408-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 11 Jul 2001, Martin Karsten wrote: > Greetings, > > I have observed the following behaviour on FreeBSD 4.x platforms (4.0 till > 4.3 seem to be affected). > > When receiving a sufficiently fast stream of UDP packets (the borderline > seems to be around 3,500 packets/sec for e.g. the 'xl' driver on a 450MHz > Pentium), an application on the receiving host does not receive all packets > anymore, depending on which nic driver is used. A fraction of the lost > packets is reported in net.inet.ip.intr_queue_drops, but not all. > > Tests have shown that the losses occur for the 'xl' or 'ti' drivers, whereas > the 'fxp' and 'de' driver don't seem to be affected. Check the output of netstat -m after doing the test. I know that the xl driver puts all incoming packets into mbuf clusters, while the dc driver goes straight into mbufs if possible. That might not explain a slowdown in overall throughput, but it does mean that dc cards have a 4x larger incoming packet queue than xl cards. Back to netstat -m. If you see that your peak number of clusters is hitting the max, that's partially your answer, and upping the # of mbuf clusters could help. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 16: 3: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from coopcomp.com (coopcomp.com [161.58.219.43]) by hub.freebsd.org (Postfix) with ESMTP id 4535E37B405 for ; Wed, 11 Jul 2001 16:03:06 -0700 (PDT) (envelope-from seichert@coopcomp.com) Received: from gourdy.coopcomp.com (gourdy.coopcomp.com [64.81.249.34]) by coopcomp.com (8.11.2) id f6BN2xE41139; Wed, 11 Jul 2001 17:03:00 -0600 (MDT) Received: by gourdy.coopcomp.com (sSMTP sendmail emulation); Wed, 11 Jul 2001 16:02:54 -0700 Date: Wed, 11 Jul 2001 16:02:54 -0700 From: Stuart Eichert To: net@freebsd.org Subject: Network Kernel Extensions in FreeBSD Message-ID: <20010711160254.A74410@gourdy.coopcomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have been reading about Network Kernel Extensions for Mac OS X. http://developer.apple.com/techpubs/macosx/Kernel/General/KernelEnvironment/NetworkingFolder/Networking___Extensions.html It seems that Network Kernel Extensions (NKEs) would allow me to dynamically add entire protocol stacks to Mac OS X via kernel modules. NKEs allow me to insert these extensions at various stages of protocol processing, from ethernet processing all the way to the socket layer. After reading about Network Kernel Extensions I was wondering if there is an effort to bring this functionality to FreeBSD. I am aware of netgraph, but I feel that it would be beneficial if a developer could write a series of NKEs one time and then compile modules for both Mac OS X and FreeBSD. -- ------------ Stuart Eichert Cooperative Computers, Inc. seichert@coopcomp.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 16: 6:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (d020.dhcp212-198-27.noos.fr [212.198.27.20]) by hub.freebsd.org (Postfix) with ESMTP id A871D37B401 for ; Wed, 11 Jul 2001 16:06:06 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id BAA20993; Thu, 12 Jul 2001 01:06:43 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B4CDB68.8D06CA81@herbelot.com> Date: Thu, 12 Jul 2001 01:04:08 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Martin Karsten Cc: freebsd-net@FreeBSD.ORG, oscar@ac.upc.es Subject: Re: UDP packet loss on FreeBSD 4.x References: <200107111512.RAA30280@KOM.tu-darmstadt.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, FWIW, I've recently built a test bench where I used P-III-450 PCs running 4-port dc(4) NIC (DLINK DFE-570-TX). The tests I've done have shown it's posible with the 4.2-R stock sources (and a tailored kernel) to send AND simultaneously send more than 20k packets/sec with a Packet Loss Rate of less than 1e-5 (when the ports are configured for 100Mbps - full duplex ; the max "correct" throughput for 10Mbps-FD is more like 8 to 10Kpacket/s, still sending and receiving simultaneously) the tests have been done with smallish packets (64 bytes/packet) and 1, 2, 3, 4, and 12 ports per machine (in each case, a total of 20 Kpack/s could be processed that is around 1800packet/s for 12 simultaneous live ports) the packets sent were UDP or raw IP streams (I did not use the xl(4) driver) TfH Martin Karsten wrote: > > Greetings, > > I have observed the following behaviour on FreeBSD 4.x platforms (4.0 till > 4.3 seem to be affected). > > When receiving a sufficiently fast stream of UDP packets (the borderline > seems to be around 3,500 packets/sec for e.g. the 'xl' driver on a 450MHz > Pentium), an application on the receiving host does not receive all packets > anymore, depending on which nic driver is used. A fraction of the lost > packets is reported in net.inet.ip.intr_queue_drops, but not all. > > Tests have shown that the losses occur for the 'xl' or 'ti' drivers, whereas > the 'fxp' and 'de' driver don't seem to be affected. > > On FreeBSD 3.4, no such losses happened and one could easily transmit more > than 10,000 packets/sec between adjacent machines. > > Is this a knowm problem and is there a chance that it is fixed? Is there > potentially a quick solution for it? > > Further, might this problem be related to an earlier report (08 Jan 2001) > sent with the subject "On the performance of the xl driver" by Oscar-Ivan > Lepe-Aldama? > > Thanks in advance, > Martin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 16:28:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E5A8D37B408 for ; Wed, 11 Jul 2001 16:28:41 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA60662; Wed, 11 Jul 2001 18:04:01 -0700 (PDT) Date: Wed, 11 Jul 2001 18:04:00 -0700 (PDT) From: Julian Elischer To: Stuart Eichert Cc: net@freebsd.org Subject: Re: Network Kernel Extensions in FreeBSD In-Reply-To: <20010711160254.A74410@gourdy.coopcomp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It is possible to do all of this with netgraph The parts that are hard to do in netgraph are hard because they would require altering the exisiting code. Porting NKE would require the same changes to the exisiting code. (probably more actually) certainly I have written protocol stacks and loaded them with netgraph (and then unloaded them) On Wed, 11 Jul 2001, Stuart Eichert wrote: > I have been reading about Network Kernel Extensions for Mac OS X. > > http://developer.apple.com/techpubs/macosx/Kernel/General/KernelEnvironment/NetworkingFolder/Networking___Extensions.html > > It seems that Network Kernel Extensions (NKEs) would allow me to dynamically > add entire protocol stacks to Mac OS X via kernel modules. NKEs allow me > to insert these extensions at various stages of protocol processing, from > ethernet processing all the way to the socket layer. > > After reading about Network Kernel Extensions I was wondering if there is > an effort to bring this functionality to FreeBSD. I am aware of netgraph, > but I feel that it would be beneficial if a developer could write a series of > NKEs one time and then compile modules for both Mac OS X and FreeBSD. > > -- > ------------ > Stuart Eichert > Cooperative Computers, Inc. > seichert@coopcomp.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 Wed Jul 11 20: 3:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by hub.freebsd.org (Postfix) with ESMTP id 0A97F37B406 for ; Wed, 11 Jul 2001 20:03:14 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp045-bsace7001.telebrasilia.net.br [200.181.80.45]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id UAA81179 for ; Wed, 11 Jul 2001 20:03:09 -0700 (PDT) Message-ID: <3B4D1432.78232E88@newsguy.com> Date: Thu, 12 Jul 2001 00:06:26 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: net@freebsd.org Subject: Multicasting and routes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems there is a problem in our IP stack with regards to multicasting. The symptoms is the inability to send multicast packets on correctly configured sockets in the absence of a default (or, erroneously, multicast address being used) route. From my reading of sys/netinet/ip_output.c, and the message error I get, it seems this problem is caused by the following piece of code if (flags & IP_ROUTETOIF) { ... } else { /* * If this is the case, we probably don't want to allocate * a protocol-cloned route since we didn't get one from the * ULP. This lets TCP do its thing, while not burdening * forwarding or ICMP with the overhead of cloning a route. * Of course, we still want to do any cloning requested by * the link layer, as this is probably required in all cases * for correct operation (as it is for ARP). */ if (ro->ro_rt == 0) rtalloc_ign(ro, RTF_PRCLONING); if (ro->ro_rt == 0) { *** HERE *** ipstat.ips_noroute++; error = EHOSTUNREACH; goto bad; } ia = ifatoia(ro->ro_rt->rt_ifa); ifp = ro->ro_rt->rt_ifp; ro->ro_rt->rt_use++; if (ro->ro_rt->rt_flags & RTF_GATEWAY) dst = (struct sockaddr_in *)ro->ro_rt->rt_gateway; if (ro->ro_rt->rt_flags & RTF_HOST) isbroadcast = (ro->ro_rt->rt_flags & RTF_BROADCAST); else isbroadcast = in_broadcast(dst->sin_addr, ifp); } This is immediately followed by if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { struct in_multi *inm; m->m_flags |= M_MCAST; /* * IP destination address is multicast. Make sure "dst" * still points to the address in "ro". (It may have been * changed to point to a gateway address, above.) */ dst = (struct sockaddr_in *)&ro->ro_dst; (etc) I wonder if IN_MULTICAST test shouldn't be applied while checking for a route. Alas, I wonder if multicast packets shouldn't be marked with IP_ROUTETOIF. Unfortunately, my personal knowledge of this piece of code leaves me just wondering. Comments or suggestions? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 11 21:27:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from degler.net (crusoe.degler.net [160.79.55.71]) by hub.freebsd.org (Postfix) with ESMTP id A529737B401 for ; Wed, 11 Jul 2001 21:27:54 -0700 (PDT) (envelope-from sdegler@degler.net) Received: (from sdegler@localhost) by degler.net (8.11.3/8.11.0) id f6C4Rqo04226 for freebsd-net@freebsd.org; Thu, 12 Jul 2001 00:27:52 -0400 (EDT) Date: Thu, 12 Jul 2001 00:27:52 -0400 From: Stephen Degler To: freebsd-net@freebsd.org Subject: IPV6 panic? Message-ID: <20010712002752.A36881@crusoe.degler.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have had several of these since 6/30, after I cvsup'ed and rebuilt everything. I have been updating fairly frequently, but the problem seems to persist. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc02c3b10 stack pointer = 0x10:0xcbb4ff28 frame pointer = 0x10:0xcbb4ff3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: tty:sio+) kernel: type 12 trap, code=0 Stopped at nd6_timer+_0x38: movl 0(%ebx),%eax db> trace nd6_timer(0) at nd6_timer+0x38 softclock(0) at softclock_0x30e Any ideas? skd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 1:54:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id D94CD37B403 for ; Thu, 12 Jul 2001 01:53:52 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f6C8Kb082921; Thu, 12 Jul 2001 10:20:37 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200107120820.f6C8Kb082921@zibbi.icomtek.csir.co.za> Subject: Re: IPV6 panic? In-Reply-To: <20010712002752.A36881@crusoe.degler.net> from Stephen Degler at "Jul 12, 2001 00:27:52 am" To: sdegler@degler.net (Stephen Degler) Date: Thu, 12 Jul 2001 10:20:37 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I have had several of these since 6/30, after I cvsup'ed > and rebuilt everything. I have been updating fairly frequently, > but the problem seems to persist. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc02c3b10 > stack pointer = 0x10:0xcbb4ff28 > frame pointer = 0x10:0xcbb4ff3c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi6: tty:sio+) > kernel: type 12 trap, code=0 > Stopped at nd6_timer+_0x38: movl 0(%ebx),%eax > db> trace > nd6_timer(0) at nd6_timer+0x38 > softclock(0) at softclock_0x30e > > Any ideas? I have also seen it here, but haven't had the time to look into it. I guess it must be something that came in with the latest merge from the Kame code, but I don't have proof of that. :-) John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 2: 2:44 2001 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 AFEE737B403 for ; Thu, 12 Jul 2001 02:02:41 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A20BF4B20; Thu, 12 Jul 2001 18:02:38 +0900 (JST) To: John Hay Cc: sdegler@degler.net (Stephen Degler), freebsd-net@FreeBSD.ORG In-reply-to: jhay's message of Sat, 12 Jul 2001 10:20:37 +0200. <200107120820.f6C8Kb082921@zibbi.icomtek.csir.co.za> 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 panic? From: itojun@iijlab.net Date: Thu, 12 Jul 2001 18:02:38 +0900 Message-ID: <23877.994928558@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> I have had several of these since 6/30, after I cvsup'ed >> and rebuilt everything. I have been updating fairly frequently, >> but the problem seems to persist. when does it happen? like, - removal of pcmcia card - some specific command/activity - seeing certain packet - not related to command/activity, looks like some sort of timer issue - whatever itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 2:42:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 623B037B401; Thu, 12 Jul 2001 02:42:13 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6C9fq783788; Thu, 12 Jul 2001 12:41:52 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Jul 2001 12:41:52 +0300 From: Ruslan Ermilov To: Bohuslav Plucinsky Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, suutari@iki.fi Subject: Re: natd and ICMP 3.4 packets Message-ID: <20010712124152.A80584@sunbay.com> Mail-Followup-To: Bohuslav Plucinsky , freebsd-net@freebsd.org, freebsd-questions@freebsd.org, suutari@iki.fi References: <20010710110934.D1048@in.nextra.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010710110934.D1048@in.nextra.sk>; from plk@in.nextra.sk on Tue, Jul 10, 2001 at 11:09:34AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 10, 2001 at 11:09:34AM +0200, Bohuslav Plucinsky wrote: > Hi there, > > I have strange problem with natd and ICMP 3.4 (destination unreachable/ > fragmentation needed) packets. > > Situation: > > - we have FreeBSD 4.2-20001228-STABLE box with ipfw and natd configured > xl0 interface have public address 195.168.x.x > xl1 interface is connected to our intranet with private addr 10.10.1.1 > ipfw show: > 00100 0 0 allow ip from any to any via lo0 > ... > 09200 0 0 divert 8668 ip from any to any via xl0 > 09300 0 0 allow ip from any to any > > natd is running with arguments: natd -n xl0 > > - behind freebsd box is cisco router with GRE tunnel > > > 195.168.x.x > xl0 --------- xl1 10.10.1.0/24 (MTU 1500) > -------| FreeBSD |------------------------------------------------------.... > --------- | > ipfw +NAT | > | > | 10.10.1.2 > ---------- > | CISCO 1 | > ---------- > || > || > || GRE tunnel (MTU 1476) > || > || > || > ---------- > | CISCO 2 | > ---------- > | 10.10.20.0/24 ---- > ---------------------------------| PC | > ---- > 10.10.20.2 > > Problem: > > If cisco router CISCO 1 sends ICMP 3.4 packet to any server on Internet, > natd on FreeBSD box aliases data inside ICMP packet, but not IP headers > There is tcpdump on xl1 interface: > > 11:56:54.376974 10.10.1.2 > 195.168.3.210: icmp: 10.10.20.2 unreachable - need to frag (mtu 1476) > > and on xl0 interface: > > 11:56:55.216974 10.10.1.2 > 195.168.3.210: icmp: 195.168.x.x unreachable - need to frag (mtu 1476) > ^^^^^^^^^ ^^^^^^^^^^^ > Is this bug in natd or make I some mistake in configuration? > This is intentional. : RCS file: /home/ncvs/src/lib/libalias/alias.c,v : Working file: alias.c : head: 1.29 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 41; selected revisions: 1 : description: : ---------------------------- : revision 1.23 : date: 2000/09/01 09:32:44; author: ru; state: Exp; lines: +23 -13 : Changed the way we handle outgoing ICMP error messages -- do : not alias `ip_src' unless it comes from the host an original : datagram that triggered this error message was destined for. : : PR: 20712 : Reviewed by: brian, Charles Mott : ============================================================================= I.e., the original IP datagram that caused this ICMP error message was not destined for CISCO 1. (The original datagram's header should be visible with tcpdump -vv). Please see PR 20712 for details. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 3:10:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f77.law11.hotmail.com [64.4.17.77]) by hub.freebsd.org (Postfix) with ESMTP id 797AD37B403 for ; Thu, 12 Jul 2001 03:10:08 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Jul 2001 03:10:08 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 12 Jul 2001 10:10:07 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: Tunneling works! Date: Thu, 12 Jul 2001 10:10:07 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2001 10:10:08.0187 (UTC) FILETIME=[D41BC8B0:01C10ABA] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am very thankful to ur suggestions.....I cheked the code and 2 places i commented #ifdef INET6 Change in /netinet/in_proto.c inetsw[] initialization struct ipprotosw inetsw[] = { .... ..... /*# ifdef INET6*/ { SOCK_RAW, &inetdomain, IPPROTO_IPV6, PR_ATOMIC|PR_ADDR, encap4_input, 0, 0, rip_ctloutput, 0, 0, 0, 0, 0, &nousrreqs }, /*#endif*/ .... ....} Change in /net/if_gif.c /*# ifdef INET6*/ case AF_INET6: ifq = &ip6intrq; isr = NETISR_IPV6; break; /*#endif*/ After commenting the #ifdef INET6 ,the tunnel is working....Though this was not a proper way....for time being i did it.because code was not able to execute since somehow INET6 was not defined(pls explian this) And one more question pls answer me.... Actually my machine(Router) has 2 following physical interfaces wb0 : fe80::280:48ff:fed6:8d38 and 192.168.2.1 ed1 : fe80::200:e8ff:fe21:412b and 192.168.3.1 Actually tunnel is being set up between 192.168.3.1 and another machine with 192.168.3.9. When I ping6 -I gif0 ff02::1 the response was from other end of the tunnel and another response from (wb0 : fe80::280:48ff:fed6:8d38 )interface of my machine.Actually I think it should come from ed1. NOTE:Both wb0 and ed1 are connected to the hub. Pls explain me..... --------- --------- --------- | | | | | | | A |----------| R |----------------- | H | | | | | tunnel | | --------- ---------- --------- A=192.1682.2 R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 Now I want to communicate from H to A and A to H thro the tunnel.What i have to do for that? I want to ping6 to the other interface(wb0) of router which is NOT the tunnel end point.? with thanks and regds, FreeBSD Lover. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 3:10:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f265.law11.hotmail.com [64.4.16.140]) by hub.freebsd.org (Postfix) with ESMTP id 063E037B617 for ; Thu, 12 Jul 2001 03:10:42 -0700 (PDT) (envelope-from freebsdlover@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Jul 2001 03:10:42 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 12 Jul 2001 10:10:42 GMT X-Originating-IP: [203.200.20.3] From: "FreeBSDlover FreeBSDlover" To: freebsd-net@freebsd.org Subject: Tunneling! Date: Thu, 12 Jul 2001 10:10:42 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2001 10:10:42.0876 (UTC) FILETIME=[E8C8E7C0:01C10ABA] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am very thankful to ur suggestions.....I cheked the code and 2 places i commented #ifdef INET6 Change in /netinet/in_proto.c inetsw[] initialization struct ipprotosw inetsw[] = { .... ..... /*# ifdef INET6*/ { SOCK_RAW, &inetdomain, IPPROTO_IPV6, PR_ATOMIC|PR_ADDR, encap4_input, 0, 0, rip_ctloutput, 0, 0, 0, 0, 0, &nousrreqs }, /*#endif*/ .... ....} Change in /net/if_gif.c /*# ifdef INET6*/ case AF_INET6: ifq = &ip6intrq; isr = NETISR_IPV6; break; /*#endif*/ After commenting the #ifdef INET6 ,the tunnel is working....Though this was not a proper way....for time being i did it.because code was not able to execute since somehow INET6 was not defined(pls explian this) And one more question pls answer me.... Actually my machine(Router) has 2 following physical interfaces wb0 : fe80::280:48ff:fed6:8d38 and 192.168.2.1 ed1 : fe80::200:e8ff:fe21:412b and 192.168.3.1 Actually tunnel is being set up between 192.168.3.1 and another machine with 192.168.3.9. When I ping6 -I gif0 ff02::1 the response was from other end of the tunnel and another response from (wb0 : fe80::280:48ff:fed6:8d38 )interface of my machine.Actually I think it should come from ed1. NOTE:Both wb0 and ed1 are connected to the hub. Pls explain me..... --------- --------- --------- | | | | | | | A |----------| R |----------------- | H | | | | | tunnel | | --------- ---------- --------- A=192.1682.2 R = 192.168.3.1 H = 192.168.3.5 H = 192.168.3.5 R = 192.168.3.1 Now I want to communicate from H to A and A to H thro the tunnel.What i have to do for that? I want to ping6 to the other interface(wb0) of router which is NOT the tunnel end point.? with thanks and regds, FreeBSD Lover. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 3:15:48 2001 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 4AABC37B403 for ; Thu, 12 Jul 2001 03:15:39 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D3FAB4B20; Thu, 12 Jul 2001 19:15:37 +0900 (JST) To: "FreeBSDlover FreeBSDlover" Cc: freebsd-net@freebsd.org In-reply-to: freebsdlover's message of Thu, 12 Jul 2001 10:10:07 GMT. 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: Tunneling works! From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <24767.994932927.0@itojun.org> Date: Thu, 12 Jul 2001 19:15:37 +0900 Message-ID: <24771.994932937@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24767.994932927.1@itojun.org> >I am very thankful to ur suggestions.....I cheked the code and 2 places i >commented #ifdef INET6 here's my resposes to private copy. you don't need to send me another copy... itojun ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <24767.994932927.2@itojun.org> To: "FreeBSDlover FreeBSDlover" In-reply-to: freebsdlover's message of Thu, 12 Jul 2001 10:02:57 GMT. 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: Help me to configure From: itojun@iijlab.net Date: Thu, 12 Jul 2001 19:14:25 +0900 Message-ID: <24740.994932865@itojun.org> Sender: itojun@itojun.org >Hi, >I am very thankful to ur suggestions.....I cheked the code and 2 places i >commented #ifdef INET6 first of all, please use public forums as much as possible. it is pity when i can help only one guy, while i can potentially help multiple people by using mailing lists. next, identify which platform you are using. what is the kernel configuration file you are using (do you have INET6 in there?). >Change in /netinet/in_proto.c >inetsw[] initialization >struct ipprotosw inetsw[] = { (snip) >it.because code was not able to execute since somehow INET6 was not >defined(pls explian this) normally you won't need to comment anything out in the source code. also, when i don't have any clue about your operating system environment (version of freebsd) i cannot really comment. >And one more question pls answer me.... >Actually my machine(Router) has 2 following physical interfaces >wb0 : fe80::280:48ff:fed6:8d38 and 192.168.2.1 >ed1 : fe80::200:e8ff:fe21:412b and 192.168.3.1 > >Actually tunnel is being set up between 192.168.3.1 and another machine with >192.168.3.9. >When I ping6 -I gif0 ff02::1 the response was from other end of the tunnel >and another response from (wb0 : >fe80::280:48ff:fed6:8d38 )interface of my machine.Actually I think it should >come from ed1. >NOTE:Both wb0 and ed1 are connected to the hub. >Pls explain me..... in the diagram there's no 192.168.3.9. who is 192.168.3.9??? i can't guess your network. anyway, interface idenfiers are local to each node, therefore, when you see responses from 192.168.2.1 and watch it on 192.168.3.1, it will be presented as "fe80::280:48ff:fed6:8d38%wb0" ("the packet came in from my wb0 interface"). >--------- --------- --------- >| | | | | | >| A |------------ | R |----------| H | | > | | | tunnel | | >--------- ---------- --------- >A=192.168.2.2 R = 192.168.3.1 H = 192.168.3.5 > H = 192.168.3.5 R = 192.168.3.1 >Now I want to communicate from H to A and A to H thro the tunnel.What i have >to do for that? >I want to ping6 to the other interface(wb0) of router which is NOT the >tunnel end point.? with link-local addresses, you can't. configure global IPv6 addresses onto every interfaces (now I guess you should buy a book on IPv6). itojun ------- =_aaaaaaaaaa0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 3:29: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 1BC2037B401 for ; Thu, 12 Jul 2001 03:28:50 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f6CAJqI85911; Thu, 12 Jul 2001 12:19:52 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200107121019.f6CAJqI85911@zibbi.icomtek.csir.co.za> Subject: Re: IPV6 panic? In-Reply-To: <23877.994928558@itojun.org> from "itojun@iijlab.net" at "Jul 12, 2001 06:02:38 pm" To: itojun@iijlab.net Date: Thu, 12 Jul 2001 12:19:52 +0200 (SAT) Cc: jhay@icomtek.csir.co.za (John Hay), sdegler@degler.net (Stephen Degler), freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >> I have had several of these since 6/30, after I cvsup'ed > >> and rebuilt everything. I have been updating fairly frequently, > >> but the problem seems to persist. > > when does it happen? like, > - removal of pcmcia card > - some specific command/activity > - seeing certain packet > - not related to command/activity, looks like some sort of timer issue > - whatever Up to now it has been at night when I'm not there. :-) I have enabled saving of the kernel crashdump, so hopefully I'll catch it next time. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 7:24: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.NoDak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 8BACB37B401 for ; Thu, 12 Jul 2001 07:24:06 -0700 (PDT) (envelope-from tinguely@web.cs.ndsu.NoDak.edu) Received: (from tinguely@localhost) by web.cs.ndsu.NoDak.edu (8.11.1/8.11.1) id f6CEO1040030; Thu, 12 Jul 2001 09:24:01 -0500 (CDT) (envelope-from tinguely) Date: Thu, 12 Jul 2001 09:24:01 -0500 (CDT) From: mark tinguely Message-Id: <200107121424.f6CEO1040030@web.cs.ndsu.NoDak.edu> To: dcs@newsguy.com, net@FreeBSD.ORG Subject: Re: Multicasting and routes In-Reply-To: <3B4D1432.78232E88@newsguy.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > It seems there is a problem in our IP stack with regards to > multicasting. The symptoms is the inability to send multicast packets on > correctly configured sockets in the absence of a default (or, > erroneously, multicast address being used) route. I don't know if I am reading your question correctly, but have you tried adding a multicast route? In /etc/rc.conf: static_routes="multicast loopback" route_multicast="224.0.0.0 -netmask 0xf0000000 -interface ${hostname}" this allows only one interface to send the multicast packets, and requires a multicast router to place the packets on the other interfaces. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 8:49:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by hub.freebsd.org (Postfix) with ESMTP id 052D037B401 for ; Thu, 12 Jul 2001 08:49:51 -0700 (PDT) (envelope-from bmah@employees.org) Received: from intruder.bmah.org ([24.176.204.87]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010712154950.PKRQ9548.femail4.sdc1.sfba.home.com@intruder.bmah.org>; Thu, 12 Jul 2001 08:49:50 -0700 Received: (from bmah@localhost) by intruder.bmah.org (8.11.4/8.11.3) id f6CFmZF15294; Thu, 12 Jul 2001 08:48:35 -0700 (PDT) (envelope-from bmah) Message-Id: <200107121548.f6CFmZF15294@intruder.bmah.org> X-Mailer: exmh version 2.5 07/09/2001 with nmh-1.0.4 To: John Hay Cc: itojun@iijlab.net, sdegler@degler.net (Stephen Degler), freebsd-net@FreeBSD.ORG Subject: Re: IPV6 panic? In-Reply-To: <200107121019.f6CAJqI85911@zibbi.icomtek.csir.co.za> References: <200107121019.f6CAJqI85911@zibbi.icomtek.csir.co.za> Comments: In-reply-to John Hay message dated "Sat, 12 Jul 2001 12:19:52 +0200." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1747276780P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 12 Jul 2001 08:48:35 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --==_Exmh_1747276780P Content-Type: text/plain; charset=us-ascii If memory serves me right, John Hay wrote: > > >> I have had several of these since 6/30, after I cvsup'ed > > >> and rebuilt everything. I have been updating fairly frequently, > > >> but the problem seems to persist. > > > > when does it happen? like, > > - removal of pcmcia card > > - some specific command/activity > > - seeing certain packet > > - not related to command/activity, looks like some sort of timer issue > > - whatever > > Up to now it has been at night when I'm not there. :-) I have enabled > saving of the kernel crashdump, so hopefully I'll catch it next time. I've seen something like this as well (4-STABLE from 7 July). For me, this happens in the middle of the day, when I'm at work (this is one of my home systems). I have a crashdump, but no debugging symbols. :-( Having just realized this, I'm turning them on for my kernel builds. My last crashdump has a tombstone that looks like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3f fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fc074 stack pointer = 0x10:0xce06ff60 frame pointer = 0x10:0xce06ff78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 373 (setiathome) interrupt mask = trap number = 12 panic: page fault syncing disks... 13 2 done Uptime: 1d0h9m41s dumping to dev #da/0x30001, offset 786456 dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 8 5 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc017a892 in dumpsys () (kgdb) where #0 0xc017a892 in dumpsys () #1 0xc017a6b3 in boot () #2 0xc017aa30 in poweroff_wait () #3 0xc0308991 in trap_fatal () #4 0xc0308669 in trap_pfault () #5 0xc0308223 in trap () #6 0xc01fc074 in nd6_timer () #7 0xc01802c9 in softclock () #8 0xc02fc1af in doreti_swi () #9 0x3263 in ?? () #10 0xef9b in ?? () #11 0x138fe in ?? () #12 0x13a25 in ?? () #13 0x2abb in ?? () #14 0x107e in ?? () Will give more info if/when I get it. Bruce. --==_Exmh_1747276780P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7TcbS2MoxcVugUsMRAievAKD98TqVMmhxpUVb/M8dwGaMHUCleQCgxbV/ i9DI84LeT2vBTUpzLVXr244= =+TK/ -----END PGP SIGNATURE----- --==_Exmh_1747276780P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 10:14:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id C9FBA37B406; Thu, 12 Jul 2001 10:14:10 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA07890; Fri, 13 Jul 2001 02:15:50 +0900 (JST) Date: Fri, 13 Jul 2001 02:14:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bmah@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPV6 panic? In-Reply-To: <200107121548.f6CFmZF15294@intruder.bmah.org> References: <200107121019.f6CAJqI85911@zibbi.icomtek.csir.co.za> <200107121548.f6CFmZF15294@intruder.bmah.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Thu, 12 Jul 2001 08:48:35 -0700, >>>>> "Bruce A. Mah" said: > #0 0xc017a892 in dumpsys () > (kgdb) where > #0 0xc017a892 in dumpsys () > #1 0xc017a6b3 in boot () > #2 0xc017aa30 in poweroff_wait () > #3 0xc0308991 in trap_fatal () > #4 0xc0308669 in trap_pfault () > #5 0xc0308223 in trap () > #6 0xc01fc074 in nd6_timer () > #7 0xc01802c9 in softclock () > #8 0xc02fc1af in doreti_swi () > #9 0x3263 in ?? () > #10 0xef9b in ?? () > #11 0x138fe in ?? () > #12 0x13a25 in ?? () > #13 0x2abb in ?? () > #14 0x107e in ?? () > Will give more info if/when I get it. If possible, please let us know - the kernel configuration file - the result of % ifconfig -a % ndp -p % ndp -r before the crash (I know it is difficult, though.) as well as the stack trace with debugging symbols. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 18:58:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from granch.com (granch.com [212.109.197.246]) by hub.freebsd.org (Postfix) with ESMTP id C398137B401 for ; Thu, 12 Jul 2001 18:58:54 -0700 (PDT) (envelope-from timofeev@granch.ru) Received: from granch.com (IDENT:timofeev@granch.com [212.109.197.246]) by granch.com (8.11.2/8.11.2) with ESMTP id f6D1wpW04680 for ; Fri, 13 Jul 2001 08:58:52 +0700 (NOVST) (envelope-from timofeev@granch.ru) Date: Fri, 13 Jul 2001 08:58:51 +0700 (NOVST) From: "Denis I. Timofeev" X-Sender: timofeev@granch.com To: net@freebsd.org Subject: A question about submitting new drivers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Our company, Granch, Ltd (http://www.granch.com), is manufacturer of data communication equipment. For a few years we offer a FreeBSD driver for leased line modems SBNI12, rather widely used in Russia. Is it able to include this driver to FreeBSD distribution ? The driver isn't hard to integrate: we should create sys/dev/sbni subdirectory, copy three .c and two .h files there, and patch some existing files (sys/conf/files, sys/conf/files.i386, sys/net/if_mib.h, sys/i386/i386/userconfig.c). Additionally, there is a small configuration utility which may be stored in src/sbin/i386/sbniconfig subdirectory, like cxconfig. wbr, Denis Timofeev system programmer of Granch, Ltd. p.s. Sorry for my English. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 19:20:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 042B237B401 for ; Thu, 12 Jul 2001 19:20:29 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id A51765D010; Thu, 12 Jul 2001 21:20:28 -0500 (CDT) Date: Thu, 12 Jul 2001 21:20:28 -0500 From: Alfred Perlstein To: "Denis I. Timofeev" Cc: net@freebsd.org Subject: Re: A question about submitting new drivers Message-ID: <20010712212028.E6664@sneakerz.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from timofeev@granch.ru on Fri, Jul 13, 2001 at 08:58:51AM +0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Denis I. Timofeev [010712 20:58] wrote: > > Our company, Granch, Ltd (http://www.granch.com), is manufacturer > of data communication equipment. For a few years we offer a FreeBSD driver > for leased line modems SBNI12, rather widely used in Russia. Is it able > to include this driver to FreeBSD distribution ? > The driver isn't hard to integrate: we should create sys/dev/sbni > subdirectory, copy three .c and two .h files there, and patch some > existing files (sys/conf/files, sys/conf/files.i386, sys/net/if_mib.h, > sys/i386/i386/userconfig.c). Additionally, there is a small configuration > utility which may be stored in src/sbin/i386/sbniconfig subdirectory, > like cxconfig. This sounds cool, can you send me a url to the tarball containing these files? Why are they i386 specific though? > wbr, Denis Timofeev > system programmer of Granch, Ltd. > > p.s. Sorry for my English. English is fine and I'm guessing your Russian is a hell of a lot better than mine. :) Thanks for the work. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 19:48: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from granch.com (granch.com [212.109.197.246]) by hub.freebsd.org (Postfix) with ESMTP id B1F7037B401 for ; Thu, 12 Jul 2001 19:47:52 -0700 (PDT) (envelope-from timofeev@granch.ru) Received: from granch.com (IDENT:timofeev@granch.com [212.109.197.246]) by granch.com (8.11.2/8.11.2) with ESMTP id f6D2lQW05333; Fri, 13 Jul 2001 09:47:26 +0700 (NOVST) (envelope-from timofeev@granch.ru) Date: Fri, 13 Jul 2001 09:47:25 +0700 (NOVST) From: "Denis I. Timofeev" X-Sender: timofeev@granch.com To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: A question about submitting new drivers In-Reply-To: <20010712212028.E6664@sneakerz.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 12 Jul 2001, Alfred Perlstein wrote: > * Denis I. Timofeev [010712 20:58] wrote: > > > > Our company, Granch, Ltd (http://www.granch.com), is manufacturer > > of data communication equipment. For a few years we offer a FreeBSD driver > > for leased line modems SBNI12, rather widely used in Russia. Is it able > > to include this driver to FreeBSD distribution ? > > The driver isn't hard to integrate: we should create sys/dev/sbni > > subdirectory, copy three .c and two .h files there, and patch some > > existing files (sys/conf/files, sys/conf/files.i386, sys/net/if_mib.h, > > sys/i386/i386/userconfig.c). Additionally, there is a small configuration > > utility which may be stored in src/sbin/i386/sbniconfig subdirectory, > > like cxconfig. > > This sounds cool, can you send me a url to the tarball containing these > files? Latest stable release: ftp://ftp.granch.com/pub/drivers/sbni12/FREEBSD/FreeBSD.4x/fbsd41-3.tgz > > Why are they i386 specific though? We weren't able to test our hardware on other platforms (as Alpha); the driver contains an asm fragment, but it enclosed in #ifdef/#else brackets. > > > wbr, Denis Timofeev > > system programmer of Granch, Ltd. > > > > p.s. Sorry for my English. > > English is fine and I'm guessing your Russian is a hell of a lot > better than mine. :) Thanks! > > Thanks for the work. > > -- > -Alfred Perlstein [alfred@freebsd.org] > Ok, who wrote this damn function called '??'? > And why do my programs keep crashing in it? > wbr, Denis Timofeev system programmer of Granch, Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 12 20:30:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (cust-P5-R10-109.POOL.ESR.SJO.wwc.com [206.112.121.109]) by hub.freebsd.org (Postfix) with ESMTP id 187E737B432 for ; Thu, 12 Jul 2001 20:30:18 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6D3i9003496; Thu, 12 Jul 2001 20:44:15 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107130344.f6D3i9003496@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Denis I. Timofeev" Cc: net@freebsd.org Subject: Re: (forw) Re: A question about submitting new drivers In-reply-to: Your message of "Thu, 12 Jul 2001 22:14:58 CDT." <20010712221458.H6664@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Jul 2001 20:44:03 -0700 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It doesn't actually make a lot of sense to bundle a driver like this with FreeBSD; none of the developers are going to be able to test against it, and your customers are typically going to be running against the -stable branch anyway. Personally, I would recommend a driver like this be built and distributed as a KLD; it's fairly easy to package so that you can unpack and build under /sys/modules (just put everything in the module directory). You can also ship pre-build KLDs, making runtime loading of the driver very straightforward. Just put the kld in /modules, and ensure that it's named appropriately (if_snbi.ko). ifconfig will load it automatically on the first attempt to configure the interface. I note that you've made some modifications to the kernel MIB. You'd probably want to keep a private copy of these mods for your driver's internal use. The ifconfig changes were meant to make it easier for folks like yourselves to provide network interface drivers without having to integrate them tightly with the kernel tree; let me know if we're still falling short... Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 3: 2: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from plk.in.nextra.sk (fw.in.nextra.sk [195.168.29.2]) by hub.freebsd.org (Postfix) with ESMTP id 6614337B407; Fri, 13 Jul 2001 03:01:49 -0700 (PDT) (envelope-from plk@in.nextra.sk) Received: (from plk@localhost) by plk.in.nextra.sk (8.11.2/8.11.2) id f6DA2Cs05783; Fri, 13 Jul 2001 12:02:12 +0200 Date: Fri, 13 Jul 2001 12:02:12 +0200 From: Bohuslav Plucinsky To: ru@FreeBSD.org Cc: freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org, suutari@iki.fi Subject: Re: natd and ICMP 3.4 packets Message-ID: <20010713120211.B4366@in.nextra.sk> Reply-To: plk@in.nextra.sk References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010712124152.A80584@sunbay.com>; from ru@freebsd.org on Thu, Jul 12, 2001 at 12:41:52PM +0300 Organization: NEXTRA, Bratislava, SLOVAKIA X-NCC-RegID: sk.nextra Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Ruslan, thanks for your response, but I must dispute. If 'ip_src' is not aliased, the ICMP packet never reaches the destination because the private addresses are mostly filtered. Are you sure it was the aim? Regards, Bohus On Thu, Jul 12, 2001 at 12:41:52PM +0300, Ruslan Ermilov wrote: > On Tue, Jul 10, 2001 at 11:09:34AM +0200, Bohuslav Plucinsky wrote: > > Hi there, > > > > I have strange problem with natd and ICMP 3.4 (destination unreachable/ > > fragmentation needed) packets. > > > > Situation: > > > > - we have FreeBSD 4.2-20001228-STABLE box with ipfw and natd configured > > xl0 interface have public address 195.168.x.x > > xl1 interface is connected to our intranet with private addr 10.10.1.1 > > ipfw show: > > 00100 0 0 allow ip from any to any via lo0 > > ... > > 09200 0 0 divert 8668 ip from any to any via xl0 > > 09300 0 0 allow ip from any to any > > > > natd is running with arguments: natd -n xl0 > > > > - behind freebsd box is cisco router with GRE tunnel > > > > > > 195.168.x.x > > xl0 --------- xl1 10.10.1.0/24 (MTU 1500) > > -------| FreeBSD |------------------------------------------------------.... > > --------- | > > ipfw +NAT | > > | > > | 10.10.1.2 > > ---------- > > | CISCO 1 | > > ---------- > > || > > || > > || GRE tunnel (MTU 1476) > > || > > || > > || > > ---------- > > | CISCO 2 | > > ---------- > > | 10.10.20.0/24 ---- > > ---------------------------------| PC | > > ---- > > 10.10.20.2 > > > > Problem: > > > > If cisco router CISCO 1 sends ICMP 3.4 packet to any server on Internet, > > natd on FreeBSD box aliases data inside ICMP packet, but not IP headers > > There is tcpdump on xl1 interface: > > > > 11:56:54.376974 10.10.1.2 > 195.168.3.210: icmp: 10.10.20.2 unreachable - need to frag (mtu 1476) > > > > and on xl0 interface: > > > > 11:56:55.216974 10.10.1.2 > 195.168.3.210: icmp: 195.168.x.x unreachable - need to frag (mtu 1476) > > ^^^^^^^^^ ^^^^^^^^^^^ > > Is this bug in natd or make I some mistake in configuration? > > > This is intentional. > > : RCS file: /home/ncvs/src/lib/libalias/alias.c,v > : Working file: alias.c > : head: 1.29 > : branch: > : locks: strict > : access list: > : keyword substitution: kv > : total revisions: 41; selected revisions: 1 > : description: > : ---------------------------- > : revision 1.23 > : date: 2000/09/01 09:32:44; author: ru; state: Exp; lines: +23 -13 > : Changed the way we handle outgoing ICMP error messages -- do > : not alias `ip_src' unless it comes from the host an original > : datagram that triggered this error message was destined for. > : > : PR: 20712 > : Reviewed by: brian, Charles Mott > : ============================================================================= > > I.e., the original IP datagram that caused this ICMP error message > was not destined for CISCO 1. (The original datagram's header should > be visible with tcpdump -vv). > > Please see PR 20712 for details. > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > -- ====================================================================== Bohus PLUCINSKY e-mail: plk@in.nextra.sk Network Engineer N E X T R A Plynarenska 1 tel: +421 7 58 228 111 824 71 Bratislava 26 fax: +421 7 58 228 222 S L O V A K I A http://www.nextra.sk ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 3:35:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by hub.freebsd.org (Postfix) with ESMTP id 6A50337B401; Fri, 13 Jul 2001 03:35:38 -0700 (PDT) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.intranet.syncrontech.com [192.168.5.14]) by osku.suutari.iki.fi (8.11.3/8.9.3) with SMTP id f6DAYwq36333; Fri, 13 Jul 2001 13:34:58 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <017d01c10b87$b573a4f0$0e05a8c0@coffee> From: "Ari Suutari" To: , Cc: , References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> <20010713120211.B4366@in.nextra.sk> Subject: Re: natd and ICMP 3.4 packets Date: Fri, 13 Jul 2001 13:36:42 +0300 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Doesn't sound good that IP header with private IP address gets sent to internet. - after all, the 195.168.3.210 host on internet knows nothing about 10.10.1.2... Ari S. ----- Original Message ----- From: "Bohuslav Plucinsky" To: Cc: ; ; Sent: Friday, July 13, 2001 1:02 PM Subject: Re: natd and ICMP 3.4 packets > Hi Ruslan, > > thanks for your response, but I must dispute. > If 'ip_src' is not aliased, the ICMP packet never reaches the destination > because the private addresses are mostly filtered. Are you sure it was the aim? > > Regards, > > Bohus > > > > > On Thu, Jul 12, 2001 at 12:41:52PM +0300, Ruslan Ermilov wrote: > > On Tue, Jul 10, 2001 at 11:09:34AM +0200, Bohuslav Plucinsky wrote: > > > Hi there, > > > > > > I have strange problem with natd and ICMP 3.4 (destination unreachable/ > > > fragmentation needed) packets. > > > > > > Situation: > > > > > > - we have FreeBSD 4.2-20001228-STABLE box with ipfw and natd configured > > > xl0 interface have public address 195.168.x.x > > > xl1 interface is connected to our intranet with private addr 10.10.1.1 > > > ipfw show: > > > 00100 0 0 allow ip from any to any via lo0 > > > ... > > > 09200 0 0 divert 8668 ip from any to any via xl0 > > > 09300 0 0 allow ip from any to any > > > > > > natd is running with arguments: natd -n xl0 > > > > > > - behind freebsd box is cisco router with GRE tunnel > > > > > > > > > 195.168.x.x > > > xl0 --------- xl1 10.10.1.0/24 (MTU 1500) > > > -------| FreeBSD |------------------------------------------------------.... > > > --------- | > > > ipfw +NAT | > > > | > > > | 10.10.1.2 > > > ---------- > > > | CISCO 1 | > > > ---------- > > > || > > > || > > > || GRE tunnel (MTU 1476) > > > || > > > || > > > || > > > ---------- > > > | CISCO 2 | > > > ---------- > > > | 10.10.20.0/24 ---- > > > ---------------------------------| PC | > > ---- > > > 10.10.20.2 > > > > > > Problem: > > > > > > If cisco router CISCO 1 sends ICMP 3.4 packet to any server on Internet, > > > natd on FreeBSD box aliases data inside ICMP packet, but not IP headers > > > There is tcpdump on xl1 interface: > > > > > > 11:56:54.376974 10.10.1.2 > 195.168.3.210: icmp: 10.10.20.2 unreachable - need to frag (mtu 1476) > > > > > > and on xl0 interface: > > > > > > 11:56:55.216974 10.10.1.2 > 195.168.3.210: icmp: 195.168.x.x unreachable - need to frag (mtu 1476) > > > ^^^^^^^^^ ^^^^^^^^^^^ > > > Is this bug in natd or make I some mistake in configuration? > > > > > This is intentional. > > > > : RCS file: /home/ncvs/src/lib/libalias/alias.c,v > > : Working file: alias.c > > : head: 1.29 > > : branch: > > : locks: strict > > : access list: > > : keyword substitution: kv > > : total revisions: 41; selected revisions: 1 > > : description: > > : ---------------------------- > > : revision 1.23 > > : date: 2000/09/01 09:32:44; author: ru; state: Exp; lines: +23 -13 > > : Changed the way we handle outgoing ICMP error messages -- do > > : not alias `ip_src' unless it comes from the host an original > > : datagram that triggered this error message was destined for. > > : > > : PR: 20712 > > : Reviewed by: brian, Charles Mott > > : ============================================================================ = > > > > I.e., the original IP datagram that caused this ICMP error message > > was not destined for CISCO 1. (The original datagram's header should > > be visible with tcpdump -vv). > > > > Please see PR 20712 for details. > > > > > > Cheers, > > -- > > Ruslan Ermilov Oracle Developer/DBA, > > ru@sunbay.com Sunbay Software AG, > > ru@FreeBSD.org FreeBSD committer, > > +380.652.512.251 Simferopol, Ukraine > > > > http://www.FreeBSD.org The Power To Serve > > http://www.oracle.com Enabling The Information Age > > > > -- > > ====================================================================== > Bohus PLUCINSKY e-mail: plk@in.nextra.sk > Network Engineer > > N E X T R A > Plynarenska 1 tel: +421 7 58 228 111 > 824 71 Bratislava 26 fax: +421 7 58 228 222 > S L O V A K I A http://www.nextra.sk > ======================================================================= > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 3:47:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.hexanet.fr (ns1.hexanet.fr [194.98.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 4479937B401; Fri, 13 Jul 2001 03:47:21 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by ns1.hexanet.fr (8.9.3/8.9.3) with ESMTP id MAA61394; Fri, 13 Jul 2001 12:47:20 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.2/8.11.2) with SMTP id f6DAlKf01557; Fri, 13 Jul 2001 12:47:20 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 13 Jul 2001 12:47:20 +0200 From: Christophe Prévotaux To: Mike Smith Cc: net@FreeBSD.ORG Subject: Re: (forw) Re: A question about submitting new drivers Message-Id: <20010713124720.3bcd19fb.c.prevotaux@hexanet.fr> In-Reply-To: <200107130344.f6D3i9003496@mass.dis.org> References: <20010712221458.H6664@sneakerz.org> <200107130344.f6D3i9003496@mass.dis.org> X-Mailer: Sylpheed version 0.4.66 (GTK+ 1.2.7; i386--freebsd4.2) Organization: HEXANET Sarl Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Actually I think that any driver that can be included in FreeBSD is welcome I don't see why you guys are always so cautious about this, it just make FreeBSD lag behind in terms hardware support. these drivers can stay in LINT for those who want to use them and you could have russian people test these and support it On Thu, 12 Jul 2001 20:44:03 -0700 Mike Smith wrote: > > It doesn't actually make a lot of sense to bundle a driver like this with > FreeBSD; none of the developers are going to be able to test against it, > and your customers are typically going to be running against the -stable > branch anyway. > > Personally, I would recommend a driver like this be built and distributed > as a KLD; it's fairly easy to package so that you can unpack and build > under /sys/modules (just put everything in the module directory). > > You can also ship pre-build KLDs, making runtime loading of the driver > very straightforward. Just put the kld in /modules, and ensure that it's > named appropriately (if_snbi.ko). ifconfig will load it automatically on > the first attempt to configure the interface. > > I note that you've made some modifications to the kernel MIB. You'd > probably want to keep a private copy of these mods for your driver's > internal use. > > The ifconfig changes were meant to make it easier for folks like > yourselves to provide network interface drivers without having to > integrate them tightly with the kernel tree; let me know if we're still > falling short... > > Regards, > Mike > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- =================================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 BP415 Fax: +33 (0)3 26 79 30 06 51689 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 4: 0:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3BFD537B407; Fri, 13 Jul 2001 04:00:01 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6DAwtQ66269; Fri, 13 Jul 2001 13:58:55 +0300 (EEST) (envelope-from ru) Date: Fri, 13 Jul 2001 13:58:55 +0300 From: Ruslan Ermilov To: Ari Suutari Cc: plk@in.nextra.sk, freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: natd and ICMP 3.4 packets Message-ID: <20010713135855.A65898@sunbay.com> Mail-Followup-To: Ari Suutari , plk@in.nextra.sk, freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> <20010713120211.B4366@in.nextra.sk> <017d01c10b87$b573a4f0$0e05a8c0@coffee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017d01c10b87$b573a4f0$0e05a8c0@coffee>; from ari@suutari.iki.fi on Fri, Jul 13, 2001 at 01:36:42PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 13, 2001 at 01:36:42PM +0300, Ari Suutari wrote: > Hi, > > Doesn't sound good that IP header with private IP address > gets sent to internet. - after all, the 195.168.3.210 host on internet knows > nothing about 10.10.1.2... > We have discussed this before with Brian and Charles, and have come up to an agreement that FIREWALL should block these packets, not NAT. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 4:31:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from plk.in.nextra.sk (fw.in.nextra.sk [195.168.29.2]) by hub.freebsd.org (Postfix) with ESMTP id B624B37B403; Fri, 13 Jul 2001 04:31:27 -0700 (PDT) (envelope-from plk@in.nextra.sk) Received: (from plk@localhost) by plk.in.nextra.sk (8.11.2/8.11.2) id f6DBVpp09210; Fri, 13 Jul 2001 13:31:51 +0200 Date: Fri, 13 Jul 2001 13:31:51 +0200 From: Bohuslav Plucinsky To: ru@FreeBSD.org Cc: ari@suutari.iki.fi, freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: natd and ICMP 3.4 packets Message-ID: <20010713133151.D4366@in.nextra.sk> Reply-To: plk@in.nextra.sk References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> <20010713120211.B4366@in.nextra.sk> <017d01c10b87$b573a4f0$0e05a8c0@coffee> <20010713135855.A65898@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010713135855.A65898@sunbay.com>; from ru@FreeBSD.org on Fri, Jul 13, 2001 at 01:58:55PM +0300 Organization: NEXTRA, Bratislava, SLOVAKIA X-NCC-RegID: sk.nextra Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 13, 2001 at 01:58:55PM +0300, Ruslan Ermilov wrote: > On Fri, Jul 13, 2001 at 01:36:42PM +0300, Ari Suutari wrote: > > Hi, > > > > Doesn't sound good that IP header with private IP address > > gets sent to internet. - after all, the 195.168.3.210 host on internet knows > > nothing about 10.10.1.2... > > > We have discussed this before with Brian and Charles, and have come > up to an agreement that FIREWALL should block these packets, not NAT. The firewall blocks these packets, but the effect is, that the host 195.168.3.210 never gets the information about different MTU on path. regards, -- ====================================================================== Bohus PLUCINSKY e-mail: plk@in.nextra.sk Network Engineer N E X T R A Plynarenska 1 tel: +421 7 58 228 111 824 71 Bratislava 26 fax: +421 7 58 228 222 S L O V A K I A http://www.nextra.sk ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 6:17: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by hub.freebsd.org (Postfix) with ESMTP id 3B17F37B401; Fri, 13 Jul 2001 06:17:01 -0700 (PDT) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.intranet.syncrontech.com [192.168.5.14]) by osku.suutari.iki.fi (8.11.3/8.9.3) with SMTP id f6DDGMq36576; Fri, 13 Jul 2001 16:16:23 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <01f101c10b9e$41482530$0e05a8c0@coffee> From: "Ari Suutari" To: "Ruslan Ermilov" Cc: , , References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> <20010713120211.B4366@in.nextra.sk> <017d01c10b87$b573a4f0$0e05a8c0@coffee> <20010713135855.A65898@sunbay.com> Subject: Re: natd and ICMP 3.4 packets Date: Fri, 13 Jul 2001 16:18:05 +0300 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > > Doesn't sound good that IP header with private IP address > > gets sent to internet. - after all, the 195.168.3.210 host on internet knows > > nothing about 10.10.1.2... > > > We have discussed this before with Brian and Charles, and have come > up to an agreement that FIREWALL should block these packets, not NAT. > There must be something I don't understand now ? How is the host on the internet now going to know that smaller MTU is required when it sends packets to host inside nat'ed network ? Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 6:48:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7FF6F37B405; Fri, 13 Jul 2001 06:48:26 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f6DDm4D87248; Fri, 13 Jul 2001 16:48:04 +0300 (EEST) (envelope-from ru) Date: Fri, 13 Jul 2001 16:48:03 +0300 From: Ruslan Ermilov To: Ari Suutari Cc: plk@in.nextra.sk, freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: natd and ICMP 3.4 packets Message-ID: <20010713164803.A87098@sunbay.com> Mail-Followup-To: Ari Suutari , plk@in.nextra.sk, freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG References: <20010710110934.D1048@in.nextra.sk> <20010712124152.A80584@sunbay.com> <20010713120211.B4366@in.nextra.sk> <017d01c10b87$b573a4f0$0e05a8c0@coffee> <20010713135855.A65898@sunbay.com> <01f101c10b9e$41482530$0e05a8c0@coffee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01f101c10b9e$41482530$0e05a8c0@coffee>; from ari@suutari.iki.fi on Fri, Jul 13, 2001 at 04:18:05PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 13, 2001 at 04:18:05PM +0300, Ari Suutari wrote: > > > > > > Doesn't sound good that IP header with private IP address > > > gets sent to internet. - after all, the 195.168.3.210 host on internet > knows > > > nothing about 10.10.1.2... > > > > > We have discussed this before with Brian and Charles, and have come > > up to an agreement that FIREWALL should block these packets, not NAT. > > > > There must be something I don't understand now ? How is the host > on the internet now going to know that smaller MTU is required when > it sends packets to host inside nat'ed network ? > Give me a few days guys, OK? I will come up with a solution. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 7: 7:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by hub.freebsd.org (Postfix) with ESMTP id B51DB37B403 for ; Fri, 13 Jul 2001 07:07:10 -0700 (PDT) (envelope-from Martin.Karsten@KOM.tu-darmstadt.de) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id QAA12572; Fri, 13 Jul 2001 16:06:58 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.9.3/8.7.5) id QAA03047; Fri, 13 Jul 2001 16:06:59 +0200 Message-Id: <200107131406.QAA03047@KOM.tu-darmstadt.de> Subject: Re: UDP packet loss on FreeBSD 4.x In-Reply-To: <20010711153113.L2408-100000@achilles.silby.com> from Mike Silbersack at "Jul 11, 2001 03:33:24 pm" To: Mike Silbersack Date: Fri, 13 Jul 2001 16:06:59 +0200 (CEST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for this hint, but it doesn't seem to help. Here's the output of netstat -m after a test with packet losses: 386/608/8192 mbufs in use (current/peak/max): 385 mbufs allocated to data 1 mbufs allocated to packet headers 384/494/2048 mbuf clusters in use (current/peak/max) 1140 Kbytes allocated to network (18% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines IMO the problem must have been introduced due to a change between versions 3.4 and 4.x. I'm not experienced with driver programming, the only obvious difference (at least with respect to the xl driver) is that it uses the mii driver now. Thanks anyway, Martin > > Greetings, > > > > I have observed the following behaviour on FreeBSD 4.x platforms (4.0 till > > 4.3 seem to be affected). > > > > When receiving a sufficiently fast stream of UDP packets (the borderline > > seems to be around 3,500 packets/sec for e.g. the 'xl' driver on a 450MHz > > Pentium), an application on the receiving host does not receive all packets > > anymore, depending on which nic driver is used. A fraction of the lost > > packets is reported in net.inet.ip.intr_queue_drops, but not all. > > > > Tests have shown that the losses occur for the 'xl' or 'ti' drivers, whereas > > the 'fxp' and 'de' driver don't seem to be affected. > > Check the output of netstat -m after doing the test. I know that the xl > driver puts all incoming packets into mbuf clusters, while the dc driver > goes straight into mbufs if possible. That might not explain a slowdown > in overall throughput, but it does mean that dc cards have a 4x larger > incoming packet queue than xl cards. > > Back to netstat -m. If you see that your peak number of clusters is > hitting the max, that's partially your answer, and upping the # of mbuf > clusters could help. > > Mike "Silby" Silbersack > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 7:53:33 2001 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 83B6137B407 for ; Fri, 13 Jul 2001 07:52:53 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id TAA01498; (8.9.3/vak/2.1) Fri, 13 Jul 2001 19:00:57 +0400 (MSD) Message-ID: <3B4F1C18.3030105@cronyx.ru> Date: Fri, 13 Jul 2001 20:04:40 +0400 From: Kurakin Roman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Update for sync PPP driver Content-Type: multipart/mixed; boundary="------------010302040108080607050007" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------010302040108080607050007 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hi, I made patch for the net/if_spppsubr.c and net/if_sppp.h relative 4.current kernel sources. It consists of ppp patch and adds FrameRelay to the sppp driver. Who is responsible for network drivers update? Best regards, Kurakin Roman --------------010302040108080607050007 Content-Type: application/octet-stream; name="if_sppp_c.pch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if_sppp_c.pch" LS0tIGlmX3NwcHBzdWJyX2MuYwlXZWQgSnVsICA0IDE4OjU5OjIyIDIwMDEKKysrIGlmX3Nw cHBzdWJyLmMJRnJpIEp1bCAxMyAxODo0MjoxNiAyMDAxCkBAIC0xLDMwICsxLDM2IEBACiAv KgotICogU3luY2hyb25vdXMgUFBQL0Npc2NvIGxpbmsgbGV2ZWwgc3Vicm91dGluZXMuCisg KiBTeW5jaHJvbm91cyBQUFAvQ2lzY28vRnJhbWUgUmVsYXkgbGluayBsZXZlbCBzdWJyb3V0 aW5lcy4KICAqIEtlZXBhbGl2ZSBwcm90b2NvbCBpbXBsZW1lbnRlZCBpbiBib3RoIENpc2Nv IGFuZCBQUFAgbW9kZXMuCisgKiBBTlNJIFQxLjYxNy1jb21wYWlibGUgbGluayBtYW5hZ2Vt ZW50IHNpZ25hbGluZworICogaW1wbGVtZW50ZWQgZm9yIEZyYW1lIFJlbGF5IG1vZGUuCisg KiBDaXNjby10eXBlIEZyYW1lIFJlbGF5IGZyYW1pbmcgYWRkZWQsIHRoYW5rcyBBbGV4IFR1 dHViYWxpbi4KKyAqIE9ubHkgb25lIERMQ0kgcGVyIGNoYW5uZWwgZm9yIG5vdy4KICAqCi0g KiBDb3B5cmlnaHQgKEMpIDE5OTQtMTk5NiBDcm9ueXggRW5naW5lZXJpbmcgTHRkLgorICog Q29weXJpZ2h0IChDKSAxOTk0LTIwMDAgQ3Jvbnl4IEVuZ2luZWVyaW5nIEx0ZC4KICAqIEF1 dGhvcjogU2VyZ2UgVmFrdWxlbmtvLCA8dmFrQGNyb255eC5ydT4KICAqCiAgKiBIZWF2aWx5 IHJldmFtcGVkIHRvIGNvbmZvcm0gdG8gUkZDIDE2NjEuCiAgKiBDb3B5cmlnaHQgKEMpIDE5 OTcsIEpvZXJnIFd1bnNjaC4KICAqCisgKiBTbGlnaHRseSByZXZhbXBlZCB0byBjb25mb3Jt IHRvIHJlYWwgbGlmZS4KKyAqIENvcHlyaWdodCAoQykgMTk5OS0yMDAwIENyb255eCBFbmdp bmVlcmluZyBMdGQuCisgKiBBdXRob3I6IEt1cmFraW4gUm9tYW4sIDxyaWtAY3Jvbnl4LnJ1 PgorICoKICAqIFRoaXMgc29mdHdhcmUgaXMgZGlzdHJpYnV0ZWQgd2l0aCBOTyBXQVJSQU5U SUVTLCBub3QgZXZlbiB0aGUgaW1wbGllZAogICogd2FycmFudGllcyBmb3IgTUVSQ0hBTlRB QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgogICoKICAqIEF1 dGhvcnMgZ3JhbnQgYW55IG90aGVyIHBlcnNvbnMgb3Igb3JnYW5pc2F0aW9ucyBwZXJtaXNz aW9uIHRvIHVzZQogICogb3IgbW9kaWZ5IHRoaXMgc29mdHdhcmUgYXMgbG9uZyBhcyB0aGlz IG1lc3NhZ2UgaXMga2VwdCB3aXRoIHRoZSBzb2Z0d2FyZSwKICAqIGFsbCBkZXJpdmF0aXZl IHdvcmtzIG9yIG1vZGlmaWVkIHZlcnNpb25zLgotICoKLSAqIEZyb206IFZlcnNpb24gMi40 LCBUaHUgQXByIDMwIDE3OjE3OjIxIE1TRCAxOTk3Ci0gKgotICogJEZyZWVCU0Q6IHNyYy9z eXMvbmV0L2lmX3NwcHBzdWJyLmMsdiAxLjU5LjIuNiAyMDAxLzA3LzAzIDExOjAxOjQxIHVt ZSBFeHAgJAogICovCiAKICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KIAogI2lmIGRlZmluZWQo X19GcmVlQlNEX18pICYmIF9fRnJlZUJTRF9fID49IDMKICNpbmNsdWRlICJvcHRfaW5ldC5o IgotI2luY2x1ZGUgIm9wdF9pbmV0Ni5oIgorI2lmIF9fRnJlZUJTRF9fID49IDQyMDAwMAor IyAgaW5jbHVkZSAib3B0X2luZXQ2LmgiCisjZW5kaWYKICNpbmNsdWRlICJvcHRfaXB4Lmgi CiAjZW5kaWYKIApAQCAtNDMsNyArNDksMTEgQEAKICNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+ CiAjaW5jbHVkZSA8c3lzL3N5c2xvZy5oPgogI2lmIGRlZmluZWQoX19GcmVlQlNEX18pICYm IF9fRnJlZUJTRF9fID49IDMKKyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA0MTAwMDAKICNp bmNsdWRlIDxzeXMvcmFuZG9tLmg+CisjZWxzZQorI2luY2x1ZGUgPG1hY2hpbmUvcmFuZG9t Lmg+CisjZW5kaWYKICNlbmRpZgogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRl IDxzeXMvbWJ1Zi5oPgpAQCAtMjIyLDcgKzIzMiw2NCBAQAogCXVfc2hvcnQgdGltZTA7CiAJ dV9zaG9ydCB0aW1lMTsKIH07Ci0jZGVmaW5lIENJU0NPX1BBQ0tFVF9MRU4gMTgKKyNkZWZp bmUgQ0lTQ09fUEFDS0VUX0xFTiAxNAorCisvKgorICogRnJhbWUgUmVsYXkuCisgKi8KKyNk ZWZpbmUgRlJfSVAgICAgICAgICAgIDB4Q0MgICAgLyogSVAgcHJvdG9jb2wgaWRlbnRpZmll ciAqLworI2RlZmluZSBGUl9QQURESU5HICAgICAgMHgwMCAgICAvKiBOTFBJRCBwYWRkaW5n ICovCisjZGVmaW5lIEZSX1NJR05BTElORyAgICAweDA4ICAgIC8qIFEuOTMzL1QxLjYxNyBz aWduYWxpbmcgaWRlbnRpZmllciAqLworI2RlZmluZSBGUl9TTkFQICAgICAgICAgMHg4MCAg ICAvKiBOTFBJRCBzbmFwICovCisKKy8qCisgKiBIZWFkZXIgZmxhZ3MuCisgKi8KKyNkZWZp bmUgRlJfREUgICAgICAgICAgIDB4MDIgICAgLyogZGlzY2FyZCBlbGlnaWJpbGl0eSAqLwor I2RlZmluZSBGUl9GRUNOICAgICAgICAgMHgwNCAgICAvKiBmb3J3YXJkIG5vdGlmaWNhdGlv biAqLworI2RlZmluZSBGUl9CRUNOICAgICAgICAgMHgwOCAgICAvKiBiYWNrd2FyZCBub3Rp ZmljYXRpb24gKi8KKworLyoKKyAqIFNpZ25hbGluZyBtZXNzYWdlIHR5cGVzLgorICovCisj ZGVmaW5lIEZSX01TR19FTlFVSVJZICAweDc1ICAgIC8qIHN0YXR1cyBlbnF1aXJ5ICovCisj ZGVmaW5lIEZSX01TR19TVEFUVVMgICAweDdkICAgIC8qIHN0YXR1cyAqLworCisjZGVmaW5l IEZSX0VOUVVJUllfU0laRQkxNAorCisvKgorICogTWVzc2FnZSBmaWVsZCB0eXBlcy4KKyAq LworI2RlZmluZSBGUl9GTERfUlRZUEUgICAgMHgwMSAgICAvKiByZXBvcnQgdHlwZSAqLwor I2RlZmluZSBGUl9GTERfVkVSSUZZICAgMHgwMyAgICAvKiBsaW5rIHZlcmlmaWNhdGlvbiAq LworI2RlZmluZSBGUl9GTERfUFZDICAgICAgMHgwNyAgICAvKiBQVkMgc3RhdHVzICovCisj ZGVmaW5lIEZSX0ZMRF9MU0hJRlQ1ICAweDk1ICAgIC8qIGxvY2tpbmcgc2hpZnQgNSAqLwor CisvKgorICogUmVwb3J0IHR5cGVzLgorICovCisjZGVmaW5lIEZSX1JUWVBFX0ZVTEwgICAw ICAgICAgIC8qIGZ1bGwgc3RhdHVzICovCisjZGVmaW5lIEZSX1JUWVBFX1NIT1JUICAxICAg ICAgIC8qIGxpbmsgdmVyaWZpY2F0aW9uIG9ubHkgKi8KKyNkZWZpbmUgRlJfUlRZUEVfU0lO R0xFIDIgICAgICAgLyogc2luZ2xlIFBWQyBzdGF0dXMgKi8KKworLyogUFZDIHN0YXR1cyBm aWVsZC4gKi8KKyNkZWZpbmUgRlJfRExDSV9ERUxFVEUgIDB4MDQgICAgLyogUFZDIGlzIGRl bGV0ZWQgKi8KKyNkZWZpbmUgRlJfRExDSV9BQ1RJVkUgIDB4MDIgICAgLyogUFZDIGlzIG9w ZXJhdGlvbmFsICovCisjZGVmaW5lIEZSX0RMQ0lfTkVXICAgICAweDA4ICAgIC8qIFBWQyBp cyBuZXcgKi8KKworc3RydWN0IGFycF9yZXEgeworCXVuc2lnbmVkIHNob3J0ICBodHlwZTsg ICAgICAgICAgLyogaGFyZHdhcmUgdHlwZSA9IEFSUEhSRF9GUkVMQVkgKi8KKwl1bnNpZ25l ZCBzaG9ydCAgcHR5cGU7ICAgICAgICAgIC8qIHByb3RvY29sIHR5cGUgPSBFVEhFUlRZUEVf SVAgKi8KKwl1bnNpZ25lZCBjaGFyICAgaGFsZW47ICAgICAgICAgIC8qIGhhcmR3YXJlIGFk ZHJlc3MgbGVuZ3RoID0gMiAqLworCXVuc2lnbmVkIGNoYXIgICBwYWxlbjsgICAgICAgICAg LyogcHJvdG9jb2wgYWRkcmVzcyBsZW5ndGggPSA0ICovCisJdW5zaWduZWQgc2hvcnQgIG9w OyAgICAgICAgICAgICAvKiBBUlAvUkFSUC9JbkFSUCByZXF1ZXN0L3JlcGx5ICovCisJdW5z aWduZWQgc2hvcnQgIGhzb3VyY2U7ICAgICAgICAvKiBoYXJkd2FyZSBzb3VyY2UgYWRkcmVz cyAqLworCXVuc2lnbmVkIHNob3J0ICBwc291cmNlMTsgICAgICAgLyogcHJvdG9jb2wgc291 cmNlICovCisJdW5zaWduZWQgc2hvcnQgIHBzb3VyY2UyOworCXVuc2lnbmVkIHNob3J0ICBo dGFyZ2V0OyAgICAgICAgLyogaGFyZHdhcmUgdGFyZ2V0IGFkZHJlc3MgKi8KKwl1bnNpZ25l ZCBzaG9ydCAgcHRhcmdldDE7ICAgICAgIC8qIHByb3RvY29sIHRhcmdldCAqLworCXVuc2ln bmVkIHNob3J0ICBwdGFyZ2V0MjsKK307CiAKIC8qCiAgKiBXZSBmb2xsb3cgdGhlIHNwZWxs aW5nIGFuZCBjYXBpdGFsaXphdGlvbiBvZiBSRkMgMTY2MSBoZXJlLCB0byBtYWtlCkBAIC0y OTQsNiArMzYxLDEyIEBACiBzdGF0aWMgdm9pZCBzcHBwX2Npc2NvX3NlbmQoc3RydWN0IHNw cHAgKnNwLCBpbnQgdHlwZSwgbG9uZyBwYXIxLCBsb25nIHBhcjIpOwogc3RhdGljIHZvaWQg c3BwcF9jaXNjb19pbnB1dChzdHJ1Y3Qgc3BwcCAqc3AsIHN0cnVjdCBtYnVmICptKTsKIAor c3RhdGljIHZvaWQgc3BwcF9mcl9pbnB1dCAoc3RydWN0IHNwcHAgKnNwLCBzdHJ1Y3QgbWJ1 ZiAqbSk7CitzdGF0aWMgc3RydWN0IG1idWYgKnNwcHBfZnJfaGVhZGVyIChzdHJ1Y3Qgc3Bw cCAqc3AsIHN0cnVjdCBtYnVmICptLCBpbnQgZmFtKTsKK3N0YXRpYyB2b2lkIHNwcHBfZnJf a2VlcGFsaXZlIChzdHJ1Y3Qgc3BwcCAqc3ApOworc3RhdGljIHZvaWQgc3BwcF9mcl9hcnAg KHN0cnVjdCBzcHBwICpzcCwgc3RydWN0IGFycF9yZXEgKnJlcSwgdV9zaG9ydCBhZGRyKTsK K3N0YXRpYyB2b2lkIHNwcHBfZnJfc2lnbmFsIChzdHJ1Y3Qgc3BwcCAqc3AsIHVuc2lnbmVk IGNoYXIgKmgsIGludCBsZW4pOworCiBzdGF0aWMgdm9pZCBzcHBwX2NwX2lucHV0KGNvbnN0 IHN0cnVjdCBjcCAqY3AsIHN0cnVjdCBzcHBwICpzcCwKIAkJCSAgc3RydWN0IG1idWYgKm0p Owogc3RhdGljIHZvaWQgc3BwcF9jcF9zZW5kKHN0cnVjdCBzcHBwICpzcCwgdV9zaG9ydCBw cm90bywgdV9jaGFyIHR5cGUsCkBAIC01MjAsNiArNTkzLDExIEBACiAJCXJldHVybjsKIAl9 CiAKKwlpZiAoc3AtPnBwX21vZGUgPT0gUFBfRlIpIHsKKwkJc3BwcF9mcl9pbnB1dCAoc3As IG0pOworCQlyZXR1cm47CisJfQorCiAJLyogR2V0IFBQUCBoZWFkZXIuICovCiAJaCA9IG10 b2QgKG0sIHN0cnVjdCBwcHBfaGVhZGVyKik7CiAJbV9hZGogKG0sIFBQUF9IRUFERVJfTEVO KTsKQEAgLTUzOSwxNiArNjE3LDE2IEBACiAJCX0KIAkJc3dpdGNoIChudG9ocyAoaC0+cHJv dG9jb2wpKSB7CiAJCWRlZmF1bHQ6CisJCQlpZiAoc3AtPnN0YXRlW0lEWF9MQ1BdID09IFNU QVRFX09QRU5FRCkKKwkJCQlzcHBwX2NwX3NlbmQgKHNwLCBQUFBfTENQLCBQUk9UT19SRUos CisJCQkJCSsrc3AtPnBwX3NlcVtJRFhfTENQXSwKKwkJCQkJbS0+bV9wa3RoZHIubGVuICsg MiwgJmgtPnByb3RvY29sKTsKIAkJCWlmIChkZWJ1ZykKIAkJCQlsb2coTE9HX0RFQlVHLAot CQkJCSAgICBTUFBfRk1UICJyZWplY3RpbmcgcHJvdG9jb2wgIgorCQkJCSAgICBTUFBfRk1U ICJpbnZhbGlkIGlucHV0IHByb3RvY29sICIKIAkJCQkgICAgIjxhZGRyPTB4JXggY3RybD0w eCV4IHByb3RvPTB4JXg+XG4iLAogCQkJCSAgICBTUFBfQVJHUyhpZnApLAogCQkJCSAgICBo LT5hZGRyZXNzLCBoLT5jb250cm9sLCBudG9ocyhoLT5wcm90b2NvbCkpOwotCQkJaWYgKHNw LT5zdGF0ZVtJRFhfTENQXSA9PSBTVEFURV9PUEVORUQpCi0JCQkJc3BwcF9jcF9zZW5kIChz cCwgUFBQX0xDUCwgUFJPVE9fUkVKLAotCQkJCQkrK3NwLT5wcF9zZXFbSURYX0xDUF0sIG0t Pm1fcGt0aGRyLmxlbiArIDIsCi0JCQkJCSZoLT5wcm90b2NvbCk7CiAJCQkrK2lmcC0+aWZf bm9wcm90bzsKIAkJCWdvdG8gZHJvcDsKIAkJY2FzZSBQUFBfTENQOgpAQCAtNzY3LDE4ICs4 NDUsMjUgQEAKIAl9CiAjZW5kaWYKIAorCWlmIChzcC0+cHBfbW9kZSA9PSBQUF9GUikgewor CQkvKiBBZGQgZnJhbWUgcmVsYXkgaGVhZGVyLiAqLworCQltID0gc3BwcF9mcl9oZWFkZXIg KHNwLCBtLCBkc3QtPnNhX2ZhbWlseSk7CisJCWlmICghIG0pCisJCQlnb3RvIG5vYnVmczsK KwkJZ290byBvdXQ7CiAjaWZkZWYgSU5FVDYKIAlpZiAoZHN0LT5zYV9mYW1pbHkgPT0gQUZf SU5FVDYpIHsKIAkJLyogWFhYIGRvIHNvbWV0aGluZyB0cmlja3kgaGVyZT8gKi8KIAl9CiAj ZW5kaWYKKwl9CiAKIAkvKgogCSAqIFByZXBlbmQgZ2VuZXJhbCBkYXRhIHBhY2tldCBQUFAg aGVhZGVyLiBGb3Igbm93LCBJUCBvbmx5LgogCSAqLwogCU1fUFJFUEVORCAobSwgUFBQX0hF QURFUl9MRU4sIE1fRE9OVFdBSVQpOwogCWlmICghIG0pIHsKLQkJaWYgKGRlYnVnKQorbm9i dWZzOgkJaWYgKGRlYnVnKQogCQkJbG9nKExPR19ERUJVRywgU1BQX0ZNVCAibm8gbWVtb3J5 IGZvciB0cmFuc21pdCBoZWFkZXJcbiIsCiAJCQkJU1BQX0FSR1MoaWZwKSk7CiAJCSsraWZw LT5pZl9vZXJyb3JzOwpAQCAtODYzLDcgKzk0OCw3IEBACiAJICogUXVldWUgbWVzc2FnZSBv biBpbnRlcmZhY2UsIGFuZCBzdGFydCBvdXRwdXQgaWYgaW50ZXJmYWNlCiAJICogbm90IHll dCBhY3RpdmUuCiAJICovCi0JaWYgKElGX1FGVUxMIChpZnEpKSB7CitvdXQ6CWlmIChJRl9R RlVMTCAoaWZxKSkgewogCQlJRl9EUk9QICgmaWZwLT5pZl9zbmQpOwogCQltX2ZyZWVtICht KTsKIAkJKytpZnAtPmlmX29lcnJvcnM7CkBAIC05MDQsOSArOTg5LDkgQEAKICNpZiAwCiAJ c3AtPnBwX2ZsYWdzID0gUFBfS0VFUEFMSVZFOwogI2VuZGlmCi0gCXNwLT5wcF9pZi5pZl9z bmQuaWZxX21heGxlbiA9IDMyOwotIAlzcC0+cHBfZmFzdHEuaWZxX21heGxlbiA9IDMyOwot IAlzcC0+cHBfY3BxLmlmcV9tYXhsZW4gPSAyMDsKKyAJc3AtPnBwX2lmLmlmX3NuZC5pZnFf bWF4bGVuID0gNTA7CisgCXNwLT5wcF9mYXN0cS5pZnFfbWF4bGVuID0gNTA7CisgCXNwLT5w cF9jcHEuaWZxX21heGxlbiA9IDUwOwogCXNwLT5wcF9sb29wY250ID0gMDsKIAlzcC0+cHBf YWxpdmVjbnQgPSAwOwogCWJ6ZXJvKCZzcC0+cHBfc2VxWzBdLCBzaXplb2Yoc3AtPnBwX3Nl cSkpOwpAQCAtOTkyLDcgKzEwNzcsOCBAQAogCSAqLwogCUlGX0RFUVVFVUUoJnNwLT5wcF9j cHEsIG0pOwogCWlmIChtID09IE5VTEwgJiYKLQkgICAgKHNwcHBfbmNwX2NoZWNrKHNwKSB8 fCBzcC0+cHBfbW9kZSA9PSBJRkZfQ0lTQ08pKSB7CisJICAgIChzcHBwX25jcF9jaGVjayhz cCkgfHwgc3AtPnBwX21vZGUgPT0gSUZGX0NJU0NPIHx8CisJICAgICBzcC0+cHBfbW9kZSA9 PSBQUF9GUikpIHsKIAkJSUZfREVRVUVVRSgmc3AtPnBwX2Zhc3RxLCBtKTsKIAkJaWYgKG0g PT0gTlVMTCkKIAkJCUlGX0RFUVVFVUUgKCZzcC0+cHBfaWYuaWZfc25kLCBtKTsKQEAgLTEw MTUsNyArMTEwMSw5IEBACiAKIAltID0gc3AtPnBwX2NwcS5pZnFfaGVhZDsKIAlpZiAobSA9 PSBOVUxMICYmCi0JICAgIChzcC0+cHBfcGhhc2UgPT0gUEhBU0VfTkVUV09SSyB8fCBzcC0+ cHBfbW9kZSA9PSBJRkZfQ0lTQ08pKQorCSAgICAoc3AtPnBwX3BoYXNlID09IFBIQVNFX05F VFdPUksgfHwKKwkgICAgIHNwLT5wcF9tb2RlID09IElGRl9DSVNDTyB8fAorCSAgICAgc3At PnBwX21vZGUgPT0gUFBfRlIpKQogCQlpZiAoKG0gPSBzcC0+cHBfZmFzdHEuaWZxX2hlYWQp ID09IE5VTEwpCiAJCQltID0gc3AtPnBwX2lmLmlmX3NuZC5pZnFfaGVhZDsKIAlzcGx4IChz KTsKQEAgLTEwNTQsOSArMTE0MiwxMyBAQAogCQkJbmV3bW9kZSA9IGlmcC0+aWZfZmxhZ3Mg JiBJRkZfQVVUTzsKIAkJaWYgKCFuZXdtb2RlKQogCQkJbmV3bW9kZSA9IGlmcC0+aWZfZmxh Z3MgJiBJRkZfQ0lTQ087CisKIAkJaWZwLT5pZl9mbGFncyAmPSB+KElGRl9QQVNTSVZFIHwg SUZGX0FVVE8gfCBJRkZfQ0lTQ08pOwogCQlpZnAtPmlmX2ZsYWdzIHw9IG5ld21vZGU7CiAK KwkJaWYgKCFuZXdtb2RlKQorCQkJbmV3bW9kZSA9IHNwLT5wcF9mbGFncyAmIFBQX0ZSOwor CiAJCWlmIChuZXdtb2RlICE9IHNwLT5wcF9tb2RlKSB7CiAJCQlnb2luZ19kb3duID0gMTsK IAkJCWlmICghZ29pbmdfdXApCkBAIC0xMDY0LDI2ICsxMTU2LDMwIEBACiAJCX0KIAogCQlp ZiAoZ29pbmdfZG93bikgewotCQkJaWYgKHNwLT5wcF9tb2RlICE9IElGRl9DSVNDTykKKwkJ CWlmIChzcC0+cHBfbW9kZSAhPSBJRkZfQ0lTQ08gJiYKKwkJCSAgICBzcC0+cHBfbW9kZSAh PSBQUF9GUikKIAkJCQlsY3AuQ2xvc2Uoc3ApOwotCQkJZWxzZSBpZiAoc3AtPnBwX3RsZikK LQkJCQkoc3AtPnBwX3RsZikoc3ApOworLyoJCQllbHNlIGlmIChzcC0+cHBfdGxmKQorCQkJ CShzcC0+cHBfdGxmKShzcCk7Ki8KKwkJCQogCQkJc3BwcF9mbHVzaChpZnApOwogCQkJaWZw LT5pZl9mbGFncyAmPSB+SUZGX1JVTk5JTkc7CiAJCQlzcC0+cHBfbW9kZSA9IG5ld21vZGU7 CiAJCX0KIAogCQlpZiAoZ29pbmdfdXApIHsKLQkJCWlmIChzcC0+cHBfbW9kZSAhPSBJRkZf Q0lTQ08pCisJCQlpZiAoc3AtPnBwX21vZGUgIT0gSUZGX0NJU0NPICYmCisJCQkgICAgc3At PnBwX21vZGUgIT0gUFBfRlIpCiAJCQkJbGNwLkNsb3NlKHNwKTsKIAkJCXNwLT5wcF9tb2Rl ID0gbmV3bW9kZTsKIAkJCWlmIChzcC0+cHBfbW9kZSA9PSAwKSB7CiAJCQkJaWZwLT5pZl9m bGFncyB8PSBJRkZfUlVOTklORzsKIAkJCQlsY3AuT3BlbihzcCk7CiAJCQl9Ci0JCQlpZiAo c3AtPnBwX21vZGUgPT0gSUZGX0NJU0NPKSB7Ci0JCQkJaWYgKHNwLT5wcF90bHMpCi0JCQkJ CShzcC0+cHBfdGxzKShzcCk7CisJCQlpZiAoKHNwLT5wcF9tb2RlID09IElGRl9DSVNDTykg fHwKKwkJCSAgICAoc3AtPnBwX21vZGUgPT0gUFBfRlIpKSB7CisvKgkJCQlpZiAoc3AtPnBw X3RscykKKwkJCQkJKHNwLT5wcF90bHMpKHNwKTsqLwogCQkJCWlmcC0+aWZfZmxhZ3MgfD0g SUZGX1JVTk5JTkc7CiAJCQl9CiAJCX0KQEAgLTExMzMsNiArMTIyOSw3IEBACiAJcmV0dXJu IHJ2OwogfQogCisKIC8qCiAgKiBDaXNjbyBmcmFtaW5nIGltcGxlbWVudGF0aW9uLgogICov CkBAIC0xMzkwLDE2ICsxNDg3LDYgQEAKIAkJCS8qIGZhbGwgdGhyb3VnaC4uLiAqLwogCQlj YXNlIFNUQVRFX0FDS19TRU5UOgogCQljYXNlIFNUQVRFX1JFUV9TRU5UOgotCQkJLyoKLQkJ CSAqIHNwcHBfY3BfY2hhbmdlX3N0YXRlKCkgaGF2ZSB0aGUgc2lkZSBlZmZlY3Qgb2YKLQkJ CSAqIHJlc3RhcnRpbmcgdGhlIHRpbWVvdXRzLiBXZSB3YW50IHRvIGF2b2lkIHRoYXQKLQkJ CSAqIGlmIHRoZSBzdGF0ZSBkb24ndCBjaGFuZ2UsIG90aGVyd2lzZSB3ZSB3b24ndAotCQkJ ICogZXZlciB0aW1lb3V0IGFuZCByZXNlbmQgYSBjb25maWd1cmF0aW9uIHJlcXVlc3QKLQkJ CSAqIHRoYXQgZ290IGxvc3QuCi0JCQkgKi8KLQkJCWlmIChzcC0+c3RhdGVbY3AtPnByb3Rv aWR4XSA9PSAocnYgPyBTVEFURV9BQ0tfU0VOVDoKLQkJCSAgICBTVEFURV9SRVFfU0VOVCkp Ci0JCQkJYnJlYWs7CiAJCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIHJ2PwogCQkJ CQkgICAgIFNUQVRFX0FDS19TRU5UOiBTVEFURV9SRVFfU0VOVCk7CiAJCQlicmVhazsKQEAg LTE0OTIsMTcgKzE1NzksMTEgQEAKIAkJY2FzZSBTVEFURV9TVE9QUEVEOgogCQkJc3BwcF9j cF9zZW5kKHNwLCBjcC0+cHJvdG8sIFRFUk1fQUNLLCBoLT5pZGVudCwgMCwgMCk7CiAJCQli cmVhazsKLQkJY2FzZSBTVEFURV9SRVFfU0VOVDoKIAkJY2FzZSBTVEFURV9BQ0tfU0VOVDoK LQkJCXNwLT5yc3RfY291bnRlcltjcC0+cHJvdG9pZHhdID0gc3AtPmxjcC5tYXhfY29uZmln dXJlOwotCQkJLyoKLQkJCSAqIFNsb3cgdGhpbmdzIGRvd24gYSBiaXQgaWYgd2UgdGhpbmsg d2UgbWlnaHQgYmUKLQkJCSAqIGluIGxvb3BiYWNrLiBEZXBlbmQgb24gdGhlIHRpbWVvdXQg dG8gc2VuZCB0aGUKLQkJCSAqIG5leHQgY29uZmlndXJhdGlvbiByZXF1ZXN0LgotCQkJICov Ci0JCQlpZiAoc3AtPnBwX2xvb3BjbnQpCi0JCQkJYnJlYWs7CiAJCQkoY3AtPnNjcikoc3Ap OworLyoJCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZSAoY3AsIHNwLCBTVEFURV9SRVFfU0VOVCk7 Ki8KKwkJY2FzZSBTVEFURV9SRVFfU0VOVDoKKwkJCXNwLT5yc3RfY291bnRlcltjcC0+cHJv dG9pZHhdID0gc3AtPmxjcC5tYXhfY29uZmlndXJlOwogCQkJYnJlYWs7CiAJCWNhc2UgU1RB VEVfT1BFTkVEOgogCQkJKGNwLT50bGQpKHNwKTsKQEAgLTE1MzQsNyArMTYxNSw2IEBACiAJ CWNhc2UgU1RBVEVfQ0xPU0lORzoKIAkJY2FzZSBTVEFURV9TVE9QUElORzoKIAkJY2FzZSBT VEFURV9SRVFfU0VOVDoKLQkJICBzdGE6CiAJCQkvKiBTZW5kIFRlcm1pbmF0ZS1BY2sgcGFj a2V0LiAqLwogCQkJaWYgKGRlYnVnKQogCQkJCWxvZyhMT0dfREVCVUcsIFNQUF9GTVQgIiVz IHNlbmQgdGVybWluYXRlLWFja1xuIiwKQEAgLTE1NDUsNyArMTYyNSwxMSBAQAogCQkJKGNw LT50bGQpKHNwKTsKIAkJCXNwLT5yc3RfY291bnRlcltjcC0+cHJvdG9pZHhdID0gMDsKIAkJ CXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfU1RPUFBJTkcpOwotCQkJZ290 byBzdGE7CisJCQkvKiBTZW5kIFRlcm1pbmF0ZS1BY2sgcGFja2V0LiAqLworCQkJaWYgKGRl YnVnKQorCQkJCWxvZyhMT0dfREVCVUcsIFNQUF9GTVQgIiVzIHNlbmQgdGVybWluYXRlLWFj a1xuIiwKKwkJCQkgICAgU1BQX0FSR1MoaWZwKSwgY3AtPm5hbWUpOworCQkJc3BwcF9jcF9z ZW5kKHNwLCBjcC0+cHJvdG8sIFRFUk1fQUNLLCBoLT5pZGVudCwgMCwgMCk7CiAJCQlicmVh azsKIAkJZGVmYXVsdDoKIAkJCXByaW50ZihTUFBfRk1UICIlcyBpbGxlZ2FsICVzIGluIHN0 YXRlICVzXG4iLApAQCAtMTU2MywxMiArMTY0NywxMiBAQAogCQljYXNlIFNUQVRFX0FDS19T RU5UOgogCQkJYnJlYWs7CiAJCWNhc2UgU1RBVEVfQ0xPU0lORzoKLQkJCXNwcHBfY3BfY2hh bmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfQ0xPU0VEKTsKIAkJCShjcC0+dGxmKShzcCk7CisJ CQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX0NMT1NFRCk7CiAJCQlicmVh azsKIAkJY2FzZSBTVEFURV9TVE9QUElORzoKLQkJCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNw LCBzcCwgU1RBVEVfU1RPUFBFRCk7CiAJCQkoY3AtPnRsZikoc3ApOworCQkJc3BwcF9jcF9j aGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9TVE9QUEVEKTsKIAkJCWJyZWFrOwogCQljYXNl IFNUQVRFX0FDS19SQ1ZEOgogCQkJc3BwcF9jcF9jaGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFU RV9SRVFfU0VOVCk7CkBAIC0xNjQwLDE0ICsxNzI0LDkgQEAKIAkJICAgIG50b2hsICgqKGxv bmcqKShoKzEpKSA9PSBzcC0+bGNwLm1hZ2ljKSB7CiAJCQkvKiBMaW5lIGxvb3BiYWNrIG1v ZGUgZGV0ZWN0ZWQuICovCiAJCQlwcmludGYoU1BQX0ZNVCAibG9vcGJhY2tcbiIsIFNQUF9B UkdTKGlmcCkpOwotCQkJc3AtPnBwX2xvb3BjbnQgPSBNQVhBTElWRUNOVCAqIDU7Ci0JCQlp Zl9kb3duIChpZnApOwotCQkJc3BwcF9xZmx1c2ggKCZzcC0+cHBfY3BxKTsKLQogCQkJLyog U2h1dCBkb3duIHRoZSBQUFAgbGluay4gKi8KLQkJCS8qIFhYWCAqLwotCQkJbGNwLkRvd24o c3ApOwotCQkJbGNwLlVwKHNwKTsKKwkJCWxjcC5DbG9zZShzcCk7CisJCQlsY3AuT3Blbihz cCk7CiAJCQlicmVhazsKIAkJfQogCQkqKGxvbmcqKShoKzEpID0gaHRvbmwgKHNwLT5sY3Au bWFnaWMpOwpAQCAtMTc4MCwyOCArMTg1OSwyMSBAQAogCQlzcHBwX2NwX2NoYW5nZV9zdGF0 ZShjcCwgc3AsIFNUQVRFX1JFUV9TRU5UKTsKIAkJYnJlYWs7CiAJY2FzZSBTVEFURV9TVE9Q UEVEOgotCQkvKgotCQkgKiBUcnkgZXNjYXBpbmcgc3RvcHBlZCBzdGF0ZS4gIFRoaXMgc2Vl bXMgdG8gYml0ZQotCQkgKiBwZW9wbGUgb2NjYXNpb25hbGx5LCBpbiBwYXJ0aWN1bGFyIGZv ciBJUENQLAotCQkgKiBwcmVzdW1hYmx5IGZvbGxvd2luZyBwcmV2aW91cyBJUENQIG5lZ290 aWF0aW9uCi0JCSAqIGFib3J0cy4gIFNvbWVob3csIHdlIG11c3QgaGF2ZSBtaXNzZWQgYSBE b3duIGV2ZW50Ci0JCSAqIHdoaWNoIHdvdWxkIGhhdmUgY2F1c2VkIGEgdHJhbnNpdGlvbiBp bnRvIHN0YXJ0aW5nCi0JCSAqIHN0YXRlLCBzbyBhcyBhIGJhbmRhaWQgd2UgZm9yY2UgdGhl IERvd24gZXZlbnQgbm93LgotCQkgKiBUaGlzIGVmZmVjdGl2ZWx5IGltcGxlbWVudHMgKHNv bWV0aGluZyBsaWtlIHRoZSkKLQkJICogYHJlc3RhcnQnIG9wdGlvbiBtZW50aW9uZWQgaW4g dGhlIHN0YXRlIHRyYW5zaXRpb24KLQkJICogdGFibGUgb2YgUkZDIDE2NjEuCi0JCSAqLwot CQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX1NUQVJUSU5HKTsKLQkJKGNw LT50bHMpKHNwKTsKLQkJYnJlYWs7CiAJY2FzZSBTVEFURV9TVE9QUElORzoKKwljYXNlIFNU QVRFX09QRU5FRDoKKwkvKiBBcyBzYWlkIGluIEltcGxlbWVudGF0aW9uIE9wdGlvbiAqLwor CQljcC0+RG93bihzcCk7CisJCWNwLT5VcChzcCk7CisJCWJyZWFrOwogCWNhc2UgU1RBVEVf UkVRX1NFTlQ6CiAJY2FzZSBTVEFURV9BQ0tfUkNWRDoKIAljYXNlIFNUQVRFX0FDS19TRU5U OgotCWNhc2UgU1RBVEVfT1BFTkVEOgogCQlicmVhazsKIAljYXNlIFNUQVRFX0NMT1NJTkc6 CisJLyogQXMgc2FpZCBpbiBJbXBsZW1lbnRhdGlvbiBPcHRpb24gKi8KIAkJc3BwcF9jcF9j aGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9TVE9QUElORyk7CisJCWNwLT5Eb3duKHNwKTsK KwkJY3AtPlVwKHNwKTsKIAkJYnJlYWs7CiAJfQogfQpAQCAtMTgyMyw4ICsxODk1LDggQEAK IAljYXNlIFNUQVRFX0NMT1NJTkc6CiAJCWJyZWFrOwogCWNhc2UgU1RBVEVfU1RBUlRJTkc6 Ci0JCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfSU5JVElBTCk7CiAJCShj cC0+dGxmKShzcCk7CisJCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfSU5J VElBTCk7CiAJCWJyZWFrOwogCWNhc2UgU1RBVEVfU1RPUFBFRDoKIAkJc3BwcF9jcF9jaGFu Z2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9DTE9TRUQpOwpAQCAtMTg2MywxOCArMTkzNSwxOCBA QAogCQkvKiBUTy0gZXZlbnQgKi8KIAkJc3dpdGNoIChzcC0+c3RhdGVbY3AtPnByb3RvaWR4 XSkgewogCQljYXNlIFNUQVRFX0NMT1NJTkc6Ci0JCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShj cCwgc3AsIFNUQVRFX0NMT1NFRCk7CiAJCQkoY3AtPnRsZikoc3ApOworCQkJc3BwcF9jcF9j aGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9DTE9TRUQpOwogCQkJYnJlYWs7CiAJCWNhc2Ug U1RBVEVfU1RPUFBJTkc6Ci0JCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRF X1NUT1BQRUQpOwogCQkJKGNwLT50bGYpKHNwKTsKKwkJCXNwcHBfY3BfY2hhbmdlX3N0YXRl KGNwLCBzcCwgU1RBVEVfU1RPUFBFRCk7CiAJCQlicmVhazsKIAkJY2FzZSBTVEFURV9SRVFf U0VOVDoKIAkJY2FzZSBTVEFURV9BQ0tfUkNWRDoKIAkJY2FzZSBTVEFURV9BQ0tfU0VOVDoK LQkJCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfU1RPUFBFRCk7CiAJCQko Y3AtPnRsZikoc3ApOworCQkJc3BwcF9jcF9jaGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9T VE9QUEVEKTsKIAkJCWJyZWFrOwogCQl9CiAJZWxzZQpAQCAtMjAwOCw5ICsyMDgwLDggQEAK IAkgKi8KIAlpZiAoKGlmcC0+aWZfZmxhZ3MgJiAoSUZGX0FVVE8gfCBJRkZfUEFTU0lWRSkp ID09IDApIHsKIAkJbG9nKExPR19JTkZPLAotCQkgICAgU1BQX0ZNVCAiRG93biBldmVudCwg dGFraW5nIGludGVyZmFjZSBkb3duLlxuIiwKKwkJICAgIFNQUF9GTVQgIkRvd24gZXZlbnQs IGNvbnRpbnVpbmcuXG4iLAogCQkgICAgU1BQX0FSR1MoaWZwKSk7Ci0JCWlmX2Rvd24oaWZw KTsKIAl9IGVsc2UgewogCQlpZiAoZGVidWcpCiAJCQlsb2coTE9HX0RFQlVHLApAQCAtMjA4 NSw3ICsyMTU2LDcgQEAKIAkJCWlmIChsZW4gPj0gNiAmJiBwWzFdID09IDYpCiAJCQkJY29u dGludWU7CiAJCQlpZiAoZGVidWcpCi0JCQkJbG9nKC0xLCAiW2ludmFsaWRdICIpOworCQkJ CWFkZGxvZygiW2ludmFsaWRdICIpOwogCQkJYnJlYWs7CiAJCWNhc2UgTENQX09QVF9BU1lO Q19NQVA6CiAJCQkvKiBBc3luYyBjb250cm9sIGNoYXJhY3RlciBtYXAuICovCkBAIC0yMTY0 LDEyICsyMjM1LDExIEBACiAJCQlubWFnaWMgPSAodV9sb25nKXBbMl0gPDwgMjQgfAogCQkJ CSh1X2xvbmcpcFszXSA8PCAxNiB8IHBbNF0gPDwgOCB8IHBbNV07CiAJCQlpZiAobm1hZ2lj ICE9IHNwLT5sY3AubWFnaWMpIHsKLQkJCQlzcC0+cHBfbG9vcGNudCA9IDA7CiAJCQkJaWYg KGRlYnVnKQogCQkJCQlhZGRsb2coIjB4JWx4ICIsIG5tYWdpYyk7CiAJCQkJY29udGludWU7 CiAJCQl9Ci0JCQlpZiAoZGVidWcgJiYgc3AtPnBwX2xvb3BjbnQgPCBNQVhBTElWRUNOVCo1 KQorCQkJaWYgKGRlYnVnKQogCQkJCWFkZGxvZygiW2dsaXRjaF0gIik7CiAJCQkrK3NwLT5w cF9sb29wY250OwogCQkJLyoKQEAgLTIyMzQsMzEgKzIzMDQsMjMgQEAKIAkJcmxlbiArPSBw WzFdOwogCX0KIAlpZiAocmxlbikgewotCQkvKgotCQkgKiBMb2NhbCBhbmQgcmVtb3RlIG1h Z2ljcyBlcXVhbCAtLSBsb29wYmFjaz8KLQkJICovCi0JCWlmIChzcC0+cHBfbG9vcGNudCA+ PSBNQVhBTElWRUNOVCo1KSB7Ci0JCQlpZiAoc3AtPnBwX2xvb3BjbnQgPT0gTUFYQUxJVkVD TlQqNSkKLQkJCQlwcmludGYgKFNQUF9GTVQgImxvb3BiYWNrXG4iLAotCQkJCQlTUFBfQVJH UyhpZnApKTsKLQkJCWlmIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSB7Ci0JCQkJaWZfZG93 bihpZnApOwotCQkJCXNwcHBfcWZsdXNoKCZzcC0+cHBfY3BxKTsKLQkJCQkvKiBYWFggPyAq LwotCQkJCWxjcC5Eb3duKHNwKTsKLQkJCQlsY3AuVXAoc3ApOwotCQkJfQotCQl9IGVsc2Ug aWYgKCsrc3AtPmZhaWxfY291bnRlcltJRFhfTENQXSA+PSBzcC0+bGNwLm1heF9mYWlsdXJl KSB7Ci0JCQlpZiAoZGVidWcpCi0JCQkJYWRkbG9nKCIgbWF4X2ZhaWx1cmUgKCVkKSBleGNl ZWRlZCwgIgotCQkJCSAgICAgICAic2VuZCBjb25mLXJlalxuIiwKLQkJCQkgICAgICAgc3At PmxjcC5tYXhfZmFpbHVyZSk7Ci0JCQlzcHBwX2NwX3NlbmQoc3AsIFBQUF9MQ1AsIENPTkZf UkVKLCBoLT5pZGVudCwgcmxlbiwgYnVmKTsKLQkJfSBlbHNlIHsKKwkJaWYgKCsrc3AtPmZh aWxfY291bnRlcltJRFhfTENQXSA8IHNwLT5sY3AubWF4X2ZhaWx1cmUpIHsKIAkJCWlmIChk ZWJ1ZykKLQkJCQlhZGRsb2coIiBzZW5kIGNvbmYtbmFrXG4iKTsKKwkJCQlhZGRsb2coInNl bmQgY29uZi1uYWtcbiIpOwogCQkJc3BwcF9jcF9zZW5kIChzcCwgUFBQX0xDUCwgQ09ORl9O QUssIGgtPmlkZW50LCBybGVuLCBidWYpOworCQkJcmV0dXJuIDA7CiAJCX0KKwkJaWYgKGRl YnVnKQorCQkJYWRkbG9nKCJtYXhfZmFpbHVyZSAoJWQpIGV4Y2VlZGVkLCBjbG9zaW5nXG4i LAorCQkJICAgICAgIHNwLT5sY3AubWF4X2ZhaWx1cmUpOworCQlpZiAoc3AtPnBwX2xvb3Bj bnQgPj0gTUFYQUxJVkVDTlQpCisJCQlwcmludGYgKCIlcyVkOiBsb29wYmFja1xuIiwKKwkJ CQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCk7CisJCWxjcC5DbG9zZShzcCk7CisJCXNw LT5mYWlsX2NvdW50ZXJbSURYX0xDUF0gPSAwOworCQlzcC0+cHBfbG9vcGNudCA9IDA7CisJ CWxjcC5PcGVuKHNwKTsKKwkJcmV0dXJuIDA7CiAJfSBlbHNlIHsKIAkJaWYgKGRlYnVnKQog CQkJYWRkbG9nKCIgc2VuZCBjb25mLWFja1xuIik7CkBAIC0yNjU4LDYgKzI3MjAsMTcgQEAK IAogCXNwLT5pcGNwLmZsYWdzICY9IH4oSVBDUF9ISVNBRERSX1NFRU58SVBDUF9NWUFERFJf U0VFTnxJUENQX01ZQUREUl9EWU4pOwogCisJLyogVG8gcHJldmVudCBJUENQIGxvY2sgdXAg aW4gc3RvcHBlZCBzdGF0ZS4gKi8KKwlpZiAoc3AtPnN0YXRlW0lEWF9JUENQXSA9PSBTVEFU RV9TVE9QUEVEKQorCQlzcC0+c3RhdGVbSURYX0lQQ1BdID0gU1RBVEVfQ0xPU0VEOworCisJ LyoKKwkgKiBJZiBubyBvdGhlciBvcGVuZCBOQ1AgYXQgdGhpcyBtb21lbmV0LCB3ZSBzaG91 bGQgaW5kaWNhdGUKKwkgKiB0byBMQ1Agb3VyIHByZXNlbnMuCisJICovCisJaWYgKCFzcHBw X25jcF9jaGVjayAoc3ApKQorCQlzcC0+c3RhdGVbSURYX0lQQ1BdID0gU1RBVEVfSU5JVElB TDsKKwogCXNwcHBfZ2V0X2lwX2FkZHJzKHNwLCAmbXlhZGRyLCAmaGlzYWRkciwgMCk7CiAJ LyoKIAkgKiBJZiB3ZSBkb24ndCBoYXZlIGhpcyBhZGRyZXNzLCB0aGlzIHByb2JhYmx5IG1l YW5zIG91cgpAQCAtMjgwOSwxMSArMjg4MiwxMSBAQAogCQkJCQlhZGRsb2coIiVzIFtub3Qg YWdyZWVkXSAiLAogCQkJCQkJc3BwcF9kb3R0ZWRfcXVhZChkZXNpcmVkYWRkcikpOwogCi0J CQl9CiAJCQlwWzJdID0gaGlzYWRkciA+PiAyNDsKIAkJCXBbM10gPSBoaXNhZGRyID4+IDE2 OwogCQkJcFs0XSA9IGhpc2FkZHIgPj4gODsKIAkJCXBbNV0gPSBoaXNhZGRyOworCQkJfQog CQkJYnJlYWs7CiAJCX0KIAkJLyogQWRkIHRoZSBvcHRpb24gdG8gbmFrJ2VkIGxpc3QuICov CkBAIC0yOTg5LDYgKzMwNjIsOCBAQAogCS8qIHdlIG5vIGxvbmdlciBuZWVkIExDUCAqLwog CXNwLT5sY3AucHJvdG9zICY9IH4oMSA8PCBJRFhfSVBDUCk7CiAJc3BwcF9sY3BfY2hlY2tf YW5kX2Nsb3NlKHNwKTsKKwlpZiAoIXNwcHBfbmNwX2NoZWNrKHNwKSkKKwkJbGNwLk9wZW4g KHNwKTsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTMzOTYsNiArMzQ3MSw3IEBACiAJZnJlZSAo YnVmLCBNX1RFTVApOwogCXJldHVybjsKIH0KKwogc3RhdGljIHZvaWQKIHNwcHBfaXB2NmNw X3RsdShzdHJ1Y3Qgc3BwcCAqc3ApCiB7CkBAIC0zOTk5LDggKzQwNzUsNyBAQAogCQkgICAg ICAgc3AtPm15YXV0aC5uYW1lLAogCQkgICAgICAgMCk7CiB9Ci0KLS8qCisMLyoKICAqLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0qCiAgKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgogICogICAgICAg ICAgICAgICAgICAgICAgICBUaGUgUEFQIGltcGxlbWVudGF0aW9uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICoKQEAgLTQ0MzIsNiArNDUwNywxMSBAQAogCQkgICAgISAoaWZwLT5p Zl9mbGFncyAmIElGRl9SVU5OSU5HKSkKIAkJCWNvbnRpbnVlOwogCisJCWlmIChzcC0+cHBf bW9kZSA9PSBQUF9GUikgeworCQkJc3BwcF9mcl9rZWVwYWxpdmUgKHNwKTsKKwkJCWNvbnRp bnVlOworCQl9CisKIAkJLyogTm8ga2VlcGFsaXZlIGluIFBQUCBtb2RlIGlmIExDUCBub3Qg b3BlbmVkIHlldC4gKi8KIAkJaWYgKHNwLT5wcF9tb2RlICE9IElGRl9DSVNDTyAmJgogCQkg ICAgc3AtPnBwX3BoYXNlIDwgUEhBU0VfQVVUSEVOVElDQVRFKQpAQCAtNDQ0MCwxNCArNDUy MCwxMyBAQAogCQlpZiAoc3AtPnBwX2FsaXZlY250ID09IE1BWEFMSVZFQ05UKSB7CiAJCQkv KiBObyBrZWVwYWxpdmUgcGFja2V0cyBnb3QuICBTdG9wIHRoZSBpbnRlcmZhY2UuICovCiAJ CQlwcmludGYgKFNQUF9GTVQgImRvd25cbiIsIFNQUF9BUkdTKGlmcCkpOworCQkJaWYgKHNw LT5wcF9tb2RlID09IElGRl9DSVNDTykgewogCQkJaWZfZG93biAoaWZwKTsKIAkJCXNwcHBf cWZsdXNoICgmc3AtPnBwX2NwcSk7Ci0JCQlpZiAoc3AtPnBwX21vZGUgIT0gSUZGX0NJU0NP KSB7Ci0JCQkJLyogWFhYICovCisJCQl9IGVsc2UgewogCQkJCS8qIFNodXQgZG93biB0aGUg UFBQIGxpbmsuICovCi0JCQkJbGNwLkRvd24oc3ApOwotCQkJCS8qIEluaXRpYXRlIG5lZ290 aWF0aW9uLiBYWFggKi8KLQkJCQlsY3AuVXAoc3ApOworCQkJCWxjcC5DbG9zZShzcCk7CisJ CQkJbGNwLk9wZW4oc3ApOwogCQkJfQogCQl9CiAJCWlmIChzcC0+cHBfYWxpdmVjbnQgPD0g TUFYQUxJVkVDTlQpCkBAIC00ODY1LDcgKzQ5NDQsNiBAQAogCXNwcHBfbGNwX2NoZWNrX2Fu ZF9jbG9zZShzcCk7CiB9CiAKLQogc3RhdGljIGNvbnN0IGNoYXIgKgogc3BwcF9jcF90eXBl X25hbWUodV9jaGFyIHR5cGUpCiB7CkBAIC01MDUxLDQgKzUxMjksNTA5IEBACiBzcHBwX251 bGwoc3RydWN0IHNwcHAgKnVudXNlZCkKIHsKIAkvKiBkbyBqdXN0IG5vdGhpbmcgKi8KK30K KworLyoKKyAqIEZyYW1lIFJlbGF5IGxpbmsgbGV2ZWwgc3Vicm91dGluZXMuCisgKiBBTlNJ IFQxLjYxNy1jb21wYXRpYmxlIGxpbmsgbWFuYWdlbWVudCBzaWduYWxpbmcgaW1wbGVtZW50 ZWQuCisgKiBPbmx5IG9uZSBETENJIHBlciBjaGFubmVsIGZvciBub3cuCisgKiBDb3B5cmln aHQgKEMpIDE5OTQtMTk5OSBDcm9ueXggRW5naW5lZXJpbmcgTHRkLgorICogQXV0aG9yOiBT ZXJnZSBWYWt1bGVua28sIDx2YWtAY3Jvbnl4LnJ1PgorICovCitzdGF0aWMgdm9pZCBzcHBw X2ZyX2lucHV0IChzdHJ1Y3Qgc3BwcCAqc3AsIHN0cnVjdCBtYnVmICptKQoreworCVNURERD TDsKKwl1X2NoYXIgKmggPSBtdG9kIChtLCB1X2NoYXIqKTsKKwlzdHJ1Y3QgaWZxdWV1ZSAq aW5xOworCWludCBkbGNpLCBobGVuLCBwcm90bywgczsKKworCS8qIEdldCB0aGUgRExDSSBu dW1iZXIuICovCisJaWYgKG0tPm1fcGt0aGRyLmxlbiA8IDEwKSB7CitiYWQ6ICAgICAgICAg ICAgbV9mcmVlbSAobSk7CisJCXJldHVybjsKKwl9CisJZGxjaSA9IChoWzBdIDw8IDIgJiAw eDNmMCkgfCAoaFsxXSA+PiA0ICYgMHgwZik7CisKKwkvKiBQcm9jZXNzIHNpZ25hbGluZyBw YWNrZXRzLiAqLworCWlucSA9IDA7CisJaWYgKGRsY2kgPT0gMCkgeworCQlzcHBwX2ZyX3Np Z25hbCAoc3AsIGgsIG0tPm1fcGt0aGRyLmxlbik7CisJCW1fZnJlZW0gKG0pOworCQlyZXR1 cm47CisJfQorCisJaWYgKGRsY2kgIT0gc3AtPmZyX2RsY2kpIHsKKwkJaWYgKGRlYnVnKQor CQkJcHJpbnRmICgiJXMlZDogUmVjZWl2ZWQgcGFja2V0IGZyb20gaW52YWxpZCBETENJICVk XG4iLAorCQkJCWlmcC0+aWZfbmFtZSwgaWZwLT5pZl91bml0LCBkbGNpKTsKKwkJZ290byBi YWQ7CisJfQorCisJLyogUHJvY2VzcyB0aGUgcGFja2V0LiAqLworCWlmIChudG9ocyAoKihz aG9ydCopIChoKzIpKSA9PSBFVEhFUlRZUEVfSVApIHsKKyAgICAgICAgICAgICAgICAvKiBQ cmVoaXN0b3JpYyBJUCBmcmFtaW5nPyAqLworCQloWzJdID0gUFBQX1VJOworCQloWzNdID0g RlJfSVA7CisJfQorCWlmIChoWzJdICE9IFBQUF9VSSkgeworCQlpZiAoZGVidWcpCisJCQlw cmludGYgKCIlcyVkOiBJbnZhbGlkIGZyYW1lIHJlbGF5IGhlYWRlciBmbGFnIDB4JTAyeFxu IiwKKwkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCwgaFsyXSk7CisJCWdvdG8gYmFk OworCX0KKwlzd2l0Y2ggKGhbM10pIHsKKwlkZWZhdWx0OgorCQlpZiAoZGVidWcpCisJCQlw cmludGYgKCIlcyVkOiBVbnN1cHBvcnRlZCBOTFBJRCAweCUwMnhcbiIsCisJCQkJaWZwLT5p Zl9uYW1lLCBpZnAtPmlmX3VuaXQsIGhbM10pOworCQlnb3RvIGJhZDsKKworCWNhc2UgRlJf UEFERElORzoKKwkJaWYgKGhbNF0gIT0gRlJfU05BUCkgeworCQkJaWYgKGRlYnVnKQorCQkJ CXByaW50ZiAoIiVzJWQ6IEJhZCBOTFBJRCAweCUwMnhcbiIsCisJCQkJCWlmcC0+aWZfbmFt ZSwgaWZwLT5pZl91bml0LCBoWzRdKTsKKwkJCWdvdG8gYmFkOworCQl9CisJCWlmIChoWzVd IHx8IGhbNl0gfHwgaFs3XSkgeworCQkJaWYgKGRlYnVnKQorCQkJCXByaW50ZiAoIiVzJWQ6 IEJhZCBPSUQgMHglMDJ4LTB4JTAyeC0weCUwMnhcbiIsCisJCQkJCWlmcC0+aWZfbmFtZSwg aWZwLT5pZl91bml0LAorCQkJCQloWzVdLCBoWzZdLCBoWzddKTsKKwkJCWdvdG8gYmFkOwor CQl9CisJCXByb3RvID0gbnRvaHMgKCooc2hvcnQqKSAoaCs4KSk7CisJCWlmIChwcm90byA9 PSBFVEhFUlRZUEVfQVJQKSB7CisJCQkvKiBQcm9jZXNzIHRoZSBBUlAgcmVxdWVzdC4gKi8K KwkJCWlmIChtLT5tX3BrdGhkci5sZW4gIT0gMTAgKyBzaXplb2YgKHN0cnVjdCBhcnBfcmVx KSkgeworCQkJCWlmIChkZWJ1ZykKKwkJCQkJcHJpbnRmICgiJXMlZDogQmFkIEFSUCByZXF1 ZXN0IHNpemUgPSAlZCBieXRlc1xuIiwKKwkJCQkJCWlmcC0+aWZfbmFtZSwgaWZwLT5pZl91 bml0LAorCQkJCQkJbS0+bV9wa3RoZHIubGVuKTsKKwkJCQlnb3RvIGJhZDsKKwkJCX0KKwkJ CXNwcHBfZnJfYXJwIChzcCwgKHN0cnVjdCBhcnBfcmVxKikgKGggKyAxMCksCisJCQkJaFsw XSA8PCA4IHwgaFsxXSk7CisJCQltX2ZyZWVtIChtKTsKKwkJCXJldHVybjsKKwkJfQorCQlo bGVuID0gMTA7CisJCWJyZWFrOworCisJY2FzZSBGUl9JUDoKKwkJcHJvdG8gPSBFVEhFUlRZ UEVfSVA7CisJCWhsZW4gPSA0OworCQlicmVhazsKKwl9CisKKwkvKiBSZW1vdmUgZnJhbWUg cmVsYXkgaGVhZGVyLiAqLworCW1fYWRqIChtLCBobGVuKTsKKworCXN3aXRjaCAocHJvdG8p IHsKKwlkZWZhdWx0OgorCQkrK2lmcC0+aWZfbm9wcm90bzsKK2Ryb3A6CQkrK2lmcC0+aWZf aWVycm9yczsKKwkJKytpZnAtPmlmX2lxZHJvcHM7CisJCW1fZnJlZW0gKG0pOworCQlyZXR1 cm47CisjaWZkZWYgSU5FVAorCWNhc2UgRVRIRVJUWVBFX0lQOgorCQlzY2hlZG5ldGlzciAo TkVUSVNSX0lQKTsKKwkJaW5xID0gJmlwaW50cnE7CisJCWJyZWFrOworI2VuZGlmCisjaWZk ZWYgSVBYCisJY2FzZSBFVEhFUlRZUEVfSVBYOgorCQlzY2hlZG5ldGlzciAoTkVUSVNSX0lQ WCk7CisJCWlucSA9ICZpcHhpbnRycTsKKwkJYnJlYWs7CisjZW5kaWYKKyNpZmRlZiBOUwor CWNhc2UgMHg4MTM3OiAvKiBOb3ZlbGwgRXRoZXJuZXRfSUkgRXRoZXJuZXQgVFlQRSBJSSAq LworCQlzY2hlZG5ldGlzciAoTkVUSVNSX05TKTsKKwkJaW5xID0gJm5zaW50cnE7CisJCWJy ZWFrOworI2VuZGlmCisjaWZkZWYgTkVUQVRBTEsKKyAgICAgICAgY2FzZSBFVEhFUlRZUEVf QVQ6CisJCXNjaGVkbmV0aXNyIChORVRJU1JfQVRBTEspOworCQlpbnEgPSAmYXRpbnRycTE7 CisgICAgICAgICAgICAgICAgYnJlYWs7CisjZW5kaWYKKwl9CisKKwlpZiAoISAoaWZwLT5p Zl9mbGFncyAmIElGRl9VUCkpCisJCWdvdG8gZHJvcDsKKworCS8qIENoZWNrIHF1ZXVlLiAq LworCXMgPSBzcGxpbXAoKTsKKwlpZiAoSUZfUUZVTEwgKGlucSkpIHsKKwkJLyogUXVldWUg b3ZlcmZsb3cuICovCisJCUlGX0RST1AoaW5xKTsKKwkJc3BseChzKTsKKwkJaWYgKGRlYnVn KQorCQkJbG9nKExPR19ERUJVRywgU1BQX0ZNVCAicHJvdG9jb2wgcXVldWUgb3ZlcmZsb3dc biIsCisJCQkJU1BQX0FSR1MoaWZwKSk7CisJCWdvdG8gZHJvcDsKKwl9CisJSUZfRU5RVUVV RShpbnEsIG0pOworCXNwbHgocyk7Cit9CisKKy8qCisgKiBBZGQgdGhlIGZyYW1lIHJlbGF5 IGhlYWRlciB0byB0aGUgcGFja2V0LgorICogRm9yIElQIHRoZSBoZWFkZXIgbGVuZ3RoIGlz IDQgYnl0ZXMsCisgKiBmb3IgYWxsIG90aGVyIHByb3RvY29scyAtIDEwIGJ5dGVzIChSRkMg MTQ5MCkuCisgKi8KK3N0YXRpYyBzdHJ1Y3QgbWJ1ZiAqc3BwcF9mcl9oZWFkZXIgKHN0cnVj dCBzcHBwICpzcCwgc3RydWN0IG1idWYgKm0sCisJaW50IGZhbWlseSkKK3sKKwlTVEREQ0w7 CisJdV9jaGFyICpoOworCWludCB0eXBlLCBobGVuOworCisJLyogUHJlcGVuZCB0aGUgc3Bh Y2UgZm9yIEZyYW1lIFJlbGF5IGhlYWRlci4gKi8KKwlobGVuID0gKGZhbWlseSA9PSBBRl9J TkVUKSA/IDQgOiAxMDsKKwlNX1BSRVBFTkQgKG0sIGhsZW4sIE1fRE9OVFdBSVQpOworCWlm ICghIG0pCisJCXJldHVybiAwOworCWggPSBtdG9kIChtLCB1X2NoYXIqKTsKKworCS8qIEZp bGwgdGhlIGhlYWRlci4gKi8KKwloWzBdID0gc3AtPmZyX2RsY2kgPj4gMiAmIDB4ZmM7CisJ aFsxXSA9IHNwLT5mcl9kbGNpIDw8IDQgfCAxOworCWhbMl0gPSBQUFBfVUk7CisKKwlzd2l0 Y2ggKGZhbWlseSkgeworCWRlZmF1bHQ6CisJCWlmIChkZWJ1ZykKKwkJCXByaW50ZiAoIiVz JWQ6IENhbm5vdCBoYW5kbGUgYWRkcmVzcyBmYW1pbHkgJWRcbiIsCisJCQkJaWZwLT5pZl9u YW1lLCBpZnAtPmlmX3VuaXQsIGZhbWlseSk7CisJCW1fZnJlZW0gKG0pOworCQlyZXR1cm4g MDsKKyNpZmRlZiBJTkVUCisJY2FzZSBBRl9JTkVUOgorI2lmIDAgLyogQ3Jhc2hlcyBvbiBm cmFnbWVudGVkIHBhY2tldHMgKi8KKwkJLyoKKwkJICogU2V0IHRoZSBkaXNjYXJkIGVsaWdp YmlsaXR5IGJpdCwgaWY6CisJCSAqIDEpIG5vIGZyYWdtZW50YXRpb24KKwkJICogMikgbGVu Z3RoID4gNDAwIGJ5dGVzCisJCSAqIDNhKSB0aGUgcHJvdG9jb2wgaXMgVURQIG9yCisJCSAq IDNiKSBUQ1AgZGF0YSAobm8gY29udHJvbCBiaXRzKQorCQkgKi8KKwkJeworCQlzdHJ1Y3Qg aXAgKmlwID0gKHN0cnVjdCBpcCopIChoICsgaGxlbik7CisJCXN0cnVjdCB0Y3BoZHIgKnRj cCA9IChzdHJ1Y3QgdGNwaGRyKikgKChsb25nKilpcCArIGlwLT5pcF9obCk7CisKKwkJaWYg KCEgKGlwLT5pcF9vZmYgJiB+SVBfREYpICYmIGlwLT5pcF9sZW4gPiA0MDAgJiYKKwkJICAg IChpcC0+aXBfcCA9PSBJUFBST1RPX1VEUCB8fAorCQkgICAgaXAtPmlwX3AgPT0gSVBQUk9U T19UQ1AgJiYgISB0Y3AtPnRoX2ZsYWdzKSkKKwkJCWhbMV0gfD0gRlJfREU7CisJCX0KKyNl bmRpZgorCQloWzNdID0gRlJfSVA7CisJCXJldHVybiBtOworI2VuZGlmCisjaWZkZWYgSVBY CisJY2FzZSBBRl9JUFg6CisJCXR5cGUgPSBFVEhFUlRZUEVfSVBYOworCQlicmVhazsKKyNl bmRpZgorI2lmZGVmIE5TCisJY2FzZSBBRl9OUzoKKwkJdHlwZSA9IDB4ODEzNzsKKwkJYnJl YWs7CisjZW5kaWYKKyNpZmRlZiBORVRBVEFMSworCWNhc2UgQUZfQVBQTEVUQUxLOgorCQl0 eXBlID0gRVRIRVJUWVBFX0FUOworCQlicmVhazsKKyNlbmRpZgorCX0KKwloWzNdID0gRlJf UEFERElORzsKKwloWzRdID0gRlJfU05BUDsKKwloWzVdID0gMDsKKwloWzZdID0gMDsKKwlo WzddID0gMDsKKwkqKHNob3J0KikgKGgrOCkgPSBodG9ucyh0eXBlKTsKKwlyZXR1cm4gbTsK K30KKworLyoKKyAqIFNlbmQgcGVyaW9kaWNhbCBmcmFtZSByZWxheSBsaW5rIHZlcmlmaWNh dGlvbiBtZXNzYWdlcyB2aWEgRExDSSAwLgorICogQ2FsbGVkIGV2ZXJ5IDEwIHNlY29uZHMg KGRlZmF1bHQgdmFsdWUgb2YgVDM5MSB0aW1lciBpcyAxMCBzZWMpLgorICogRXZlcnkgNi10 aCBtZXNzYWdlIGlzIGEgZnVsbCBzdGF0dXMgcmVxdWVzdAorICogKGRlZmF1bHQgdmFsdWUg b2YgTjM5MSBjb3VudGVyIGlzIDYpLgorICovCitzdGF0aWMgdm9pZCBzcHBwX2ZyX2tlZXBh bGl2ZSAoc3RydWN0IHNwcHAgKnNwKQoreworCVNURERDTDsKKwl1bnNpZ25lZCBjaGFyICpo LCAqcDsKKwlzdHJ1Y3QgbWJ1ZiAqbTsKKworCU1HRVRIRFIgKG0sIE1fRE9OVFdBSVQsIE1U X0RBVEEpOworCWlmICghIG0pCisJCXJldHVybjsKKwltLT5tX3BrdGhkci5yY3ZpZiA9IDA7 CisKKwloID0gbXRvZCAobSwgdV9jaGFyKik7CisJcCA9IGg7CisJKnArKyA9IDA7ICAgICAg ICAgICAgICAgICAgICAgICAvKiBETENJID0gMCAqLworCSpwKysgPSAxOworCSpwKysgPSBQ UFBfVUk7CisJKnArKyA9IEZSX1NJR05BTElORzsgICAgICAgICAgICAvKiBOTFBJRCA9IFVO SSBjYWxsIGNvbnRyb2wgKi8KKworCSpwKysgPSAwOyAgICAgICAgICAgICAgICAgICAgICAg LyogY2FsbCByZWZlcmVuY2UgbGVuZ3RoID0gMCAqLworCSpwKysgPSBGUl9NU0dfRU5RVUlS WTsgICAgICAgICAgLyogbWVzc2FnZSB0eXBlID0gc3RhdHVzIGVucXVpcnkgKi8KKworCSpw KysgPSBGUl9GTERfTFNISUZUNTsgICAgICAgICAgLyogbG9ja2luZyBzaGlmdCA1ICovCisK KwkqcCsrID0gRlJfRkxEX1JUWVBFOyAgICAgICAgICAgIC8qIHJlcG9ydCB0eXBlIGZpZWxk ICovCisJKnArKyA9IDE7ICAgICAgICAgICAgICAgICAgICAgICAvKiByZXBvcnQgdHlwZSBs ZW5ndGggPSAxICovCisJaWYgKHNwLT5wcF9zZXFbSURYX0xDUF0gJSA2KQorCQkqcCsrID0g RlJfUlRZUEVfU0hPUlQ7ICAvKiBsaW5rIHZlcmlmaWNhdGlvbiBvbmx5ICovCisJZWxzZQor CQkqcCsrID0gRlJfUlRZUEVfRlVMTDsgICAvKiBmdWxsIHN0YXR1cyBuZWVkZWQgKi8KKwor CWlmIChzcC0+cHBfc2VxW0lEWF9MQ1BdID49IDI1NSkKKwkJc3AtPnBwX3NlcVtJRFhfTENQ XSA9IDA7CisJKnArKyA9IEZSX0ZMRF9WRVJJRlk7ICAgICAgICAgICAvKiBsaW5rIHZlcmlm aWNhdGlvbiB0eXBlIGZpZWxkICovCisJKnArKyA9IDI7ICAgICAgICAgICAgICAgICAgICAg ICAvKiBsaW5rIHZlcmlmaWNhdGlvbiBmaWVsZCBsZW5ndGggPSAyICovCisJKnArKyA9ICsr c3AtPnBwX3NlcVtJRFhfTENQXTsgICAvKiBvdXIgc2VxdWVuY2UgbnVtYmVyICovCisJKnAr KyA9IHNwLT5wcF9yc2VxW0lEWF9MQ1BdOyAgICAvKiBsYXN0IHJlY2VpdmVkIHNlcXVlbmNl IG51bWJlciAqLworCisJbS0+bV9wa3RoZHIubGVuID0gbS0+bV9sZW4gPSBwIC0gaDsKKwlp ZiAoZGVidWcpCisJCXByaW50ZiAoIiVzJWQ6IHNlbmQgbG1pIHBhY2tldCwgc2VxPSVkLCBy c2VxPSVkXG4iLAorCQkJaWZwLT5pZl9uYW1lLCBpZnAtPmlmX3VuaXQsCisJCQkodV9jaGFy KSBzcC0+cHBfc2VxW0lEWF9MQ1BdLAorCQkJKHVfY2hhcikgc3AtPnBwX3JzZXFbSURYX0xD UF0pOworCisJaWYgKElGX1FGVUxMICgmc3AtPnBwX2Zhc3RxKSkgeworCQlJRl9EUk9QICgm aWZwLT5pZl9zbmQpOworCQltX2ZyZWVtIChtKTsKKwl9IGVsc2UKKwkJSUZfRU5RVUVVRSAo JnNwLT5wcF9mYXN0cSwgbSk7CisJaWYgKCEgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfT0FDVElW RSkpCisJCSgqaWZwLT5pZl9zdGFydCkgKGlmcCk7CisJaWZwLT5pZl9vYnl0ZXMgKz0gbS0+ bV9wa3RoZHIubGVuICsgMzsKK30KKworLyoKKyAqIFByb2Nlc3MgdGhlIGZyYW1lIHJlbGF5 IEludmVyc2UgQVJQIHJlcXVlc3QuCisgKi8KK3N0YXRpYyB2b2lkIHNwcHBfZnJfYXJwIChz dHJ1Y3Qgc3BwcCAqc3AsIHN0cnVjdCBhcnBfcmVxICpyZXEsCisJdV9zaG9ydCBoaXNfaGFy ZHdhcmVfYWRkcmVzcykKK3sKKwlTVEREQ0w7CisJc3RydWN0IG1idWYgKm07CisJc3RydWN0 IGFycF9yZXEgKnJlcGx5OworCXVfY2hhciAqaDsKKwl1X3Nob3J0IG15X2hhcmR3YXJlX2Fk ZHJlc3M7CisJdV9sb25nIGhpc19pcF9hZGRyZXNzLCBteV9pcF9hZGRyZXNzOworCisJaWYg KChudG9ocyAocmVxLT5odHlwZSkgIT0gQVJQSFJEX0ZSRUxBWSB8fAorCSAgICBudG9ocyAo cmVxLT5odHlwZSkgIT0gMTYpIHx8IC8qIGZvciBCYXlOZXR3b3JrcyByb3V0ZXJzICovCisJ ICAgIG50b2hzIChyZXEtPnB0eXBlKSAhPSBFVEhFUlRZUEVfSVApIHsKKwkJaWYgKGRlYnVn KQorCQkJcHJpbnRmICgiJXMlZDogSW52YWxpZCBBUlAgaGFyZHdhcmUvcHJvdG9jb2wgdHlw ZSA9IDB4JXgvMHgleFxuIiwKKwkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCwKKwkJ CQludG9ocyAocmVxLT5odHlwZSksIG50b2hzIChyZXEtPnB0eXBlKSk7CisJCXJldHVybjsK Kwl9CisJaWYgKHJlcS0+aGFsZW4gIT0gMiB8fCByZXEtPnBhbGVuICE9IDQpIHsKKwkJaWYg KGRlYnVnKQorCQkJcHJpbnRmICgiJXMlZDogSW52YWxpZCBBUlAgaGFyZHdhcmUvcHJvdG9j b2wgYWRkcmVzcyBsZW5ndGggPSAlZC8lZFxuIiwKKwkJCQlpZnAtPmlmX25hbWUsIGlmcC0+ aWZfdW5pdCwKKwkJCQlyZXEtPmhhbGVuLCByZXEtPnBhbGVuKTsKKwkJcmV0dXJuOworCX0K Kwlzd2l0Y2ggKG50b2hzIChyZXEtPm9wKSkgeworCWRlZmF1bHQ6CisJCWlmIChkZWJ1ZykK KwkJCXByaW50ZiAoIiVzJWQ6IEludmFsaWQgQVJQIG9wID0gMHgleFxuIiwKKwkJCQlpZnAt PmlmX25hbWUsIGlmcC0+aWZfdW5pdCwgbnRvaHMgKHJlcS0+b3ApKTsKKwkJcmV0dXJuOwor CisJY2FzZSBBUlBPUF9JTlZSRVBMWToKKwkJLyogSWdub3JlLiAqLworCQlyZXR1cm47CisK KwljYXNlIEFSUE9QX0lOVlJFUVVFU1Q6CisJCW15X2hhcmR3YXJlX2FkZHJlc3MgPSBudG9o cyAocmVxLT5odGFyZ2V0KTsKKwkJaGlzX2lwX2FkZHJlc3MgPSBudG9ocyAocmVxLT5wc291 cmNlMSkgPDwgMTYgfAorCQkJbnRvaHMgKHJlcS0+cHNvdXJjZTIpOworCQlteV9pcF9hZGRy ZXNzID0gbnRvaHMgKHJlcS0+cHRhcmdldDEpIDw8IDE2IHwKKwkJCW50b2hzIChyZXEtPnB0 YXJnZXQyKTsKKwkJYnJlYWs7CisJfQorCWlmIChkZWJ1ZykKKwkJcHJpbnRmICgiJXMlZDog Z290IEFSUCByZXF1ZXN0LCBzb3VyY2U9MHglMDR4LyVkLiVkLiVkLiVkLCB0YXJnZXQ9MHgl MDR4LyVkLiVkLiVkLiVkXG4iLAorCQkJaWZwLT5pZl9uYW1lLCBpZnAtPmlmX3VuaXQsIG50 b2hzIChyZXEtPmhzb3VyY2UpLAorCQkJKHVuc2lnbmVkIGNoYXIpIChoaXNfaXBfYWRkcmVz cyA+PiAyNCksCisJCQkodW5zaWduZWQgY2hhcikgKGhpc19pcF9hZGRyZXNzID4+IDE2KSwK KwkJCSh1bnNpZ25lZCBjaGFyKSAoaGlzX2lwX2FkZHJlc3MgPj4gOCksCisJCQkodW5zaWdu ZWQgY2hhcikgaGlzX2lwX2FkZHJlc3MsCisJCQlteV9oYXJkd2FyZV9hZGRyZXNzLAorCQkJ KHVuc2lnbmVkIGNoYXIpIChteV9pcF9hZGRyZXNzID4+IDI0KSwKKwkJCSh1bnNpZ25lZCBj aGFyKSAobXlfaXBfYWRkcmVzcyA+PiAxNiksCisJCQkodW5zaWduZWQgY2hhcikgKG15X2lw X2FkZHJlc3MgPj4gOCksCisJCQkodW5zaWduZWQgY2hhcikgbXlfaXBfYWRkcmVzcyk7CisK KwlzcHBwX2dldF9pcF9hZGRycyAoc3AsICZteV9pcF9hZGRyZXNzLCAwLCAwKTsKKwlpZiAo ISBteV9pcF9hZGRyZXNzKQorCQlyZXR1cm47ICAgICAgICAgLyogbm90aGluZyB0byByZXBs eSAqLworCisJaWYgKGRlYnVnKQorCQlwcmludGYgKCIlcyVkOiBzZW5kIEFSUCByZXBseSwg c291cmNlPTB4JTA0eC8lZC4lZC4lZC4lZCwgdGFyZ2V0PTB4JTA0eC8lZC4lZC4lZC4lZFxu IiwKKwkJCWlmcC0+aWZfbmFtZSwgaWZwLT5pZl91bml0LCBteV9oYXJkd2FyZV9hZGRyZXNz LAorCQkJKHVuc2lnbmVkIGNoYXIpIChteV9pcF9hZGRyZXNzID4+IDI0KSwKKwkJCSh1bnNp Z25lZCBjaGFyKSAobXlfaXBfYWRkcmVzcyA+PiAxNiksCisJCQkodW5zaWduZWQgY2hhcikg KG15X2lwX2FkZHJlc3MgPj4gOCksCisJCQkodW5zaWduZWQgY2hhcikgbXlfaXBfYWRkcmVz cywKKwkJCWhpc19oYXJkd2FyZV9hZGRyZXNzLAorCQkJKHVuc2lnbmVkIGNoYXIpIChoaXNf aXBfYWRkcmVzcyA+PiAyNCksCisJCQkodW5zaWduZWQgY2hhcikgKGhpc19pcF9hZGRyZXNz ID4+IDE2KSwKKwkJCSh1bnNpZ25lZCBjaGFyKSAoaGlzX2lwX2FkZHJlc3MgPj4gOCksCisJ CQkodW5zaWduZWQgY2hhcikgaGlzX2lwX2FkZHJlc3MpOworCisJLyogU2VuZCB0aGUgSW52 ZXJzZSBBUlAgcmVwbHkuICovCisJTUdFVEhEUiAobSwgTV9ET05UV0FJVCwgTVRfREFUQSk7 CisJaWYgKCEgbSkKKwkJcmV0dXJuOworCW0tPm1fcGt0aGRyLmxlbiA9IG0tPm1fbGVuID0g MTAgKyBzaXplb2YgKCpyZXBseSk7CisJbS0+bV9wa3RoZHIucmN2aWYgPSAwOworCisJaCA9 IG10b2QgKG0sIHVfY2hhciopOworCXJlcGx5ID0gKHN0cnVjdCBhcnBfcmVxKikgKGggKyAx MCk7CisKKwloWzBdID0gaGlzX2hhcmR3YXJlX2FkZHJlc3MgPj4gODsKKwloWzFdID0gaGlz X2hhcmR3YXJlX2FkZHJlc3M7CisJaFsyXSA9IFBQUF9VSTsKKwloWzNdID0gRlJfUEFERElO RzsKKwloWzRdID0gRlJfU05BUDsKKwloWzVdID0gMDsKKwloWzZdID0gMDsKKwloWzddID0g MDsKKwkqKHNob3J0KikgKGgrOCkgPSBodG9ucyAoRVRIRVJUWVBFX0FSUCk7CisKKwlyZXBs eS0+aHR5cGUgICAgPSBodG9ucyAoQVJQSFJEX0ZSRUxBWSk7CisJcmVwbHktPnB0eXBlICAg ID0gaHRvbnMgKEVUSEVSVFlQRV9JUCk7CisJcmVwbHktPmhhbGVuICAgID0gMjsKKwlyZXBs eS0+cGFsZW4gICAgPSA0OworCXJlcGx5LT5vcCAgICAgICA9IGh0b25zIChBUlBPUF9JTlZS RVBMWSk7CisJcmVwbHktPmhzb3VyY2UgID0gaHRvbnMgKG15X2hhcmR3YXJlX2FkZHJlc3Mp OworCXJlcGx5LT5wc291cmNlMSA9IGh0b25sIChteV9pcF9hZGRyZXNzKTsKKwlyZXBseS0+ cHNvdXJjZTIgPSBodG9ubCAobXlfaXBfYWRkcmVzcykgPj4gMTY7CisJcmVwbHktPmh0YXJn ZXQgID0gaHRvbnMgKGhpc19oYXJkd2FyZV9hZGRyZXNzKTsKKwlyZXBseS0+cHRhcmdldDEg PSBodG9ubCAoaGlzX2lwX2FkZHJlc3MpOworCXJlcGx5LT5wdGFyZ2V0MiA9IGh0b25sICho aXNfaXBfYWRkcmVzcykgPj4gMTY7CisKKwlpZiAoSUZfUUZVTEwgKCZzcC0+cHBfZmFzdHEp KSB7CisJCUlGX0RST1AgKCZpZnAtPmlmX3NuZCk7CisJCW1fZnJlZW0gKG0pOworCX0gZWxz ZQorCQlJRl9FTlFVRVVFICgmc3AtPnBwX2Zhc3RxLCBtKTsKKwlpZiAoISAoaWZwLT5pZl9m bGFncyAmIElGRl9PQUNUSVZFKSkKKwkJKCppZnAtPmlmX3N0YXJ0KSAoaWZwKTsKKwlpZnAt PmlmX29ieXRlcyArPSBtLT5tX3BrdGhkci5sZW4gKyAzOworfQorCisvKgorICogUHJvY2Vz cyB0aGUgaW5wdXQgc2lnbmFsaW5nIHBhY2tldCAoRExDSSAwKS4KKyAqIFRoZSBpbXBsZW1l bnRlZCBwcm90b2NvbCBpcyBBTlNJIFQxLjYxNyBBbm5leCBELgorICovCitzdGF0aWMgdm9p ZCBzcHBwX2ZyX3NpZ25hbCAoc3RydWN0IHNwcHAgKnNwLCB1bnNpZ25lZCBjaGFyICpoLCBp bnQgbGVuKQoreworCVNURERDTDsKKwl1X2NoYXIgKnA7CisJaW50IGRsY2k7CisKKwlpZiAo aFsyXSAhPSBQUFBfVUkgfHwgaFszXSAhPSBGUl9TSUdOQUxJTkcgfHwgaFs0XSAhPSAwKSB7 CisJCWlmIChkZWJ1ZykKKwkJCXByaW50ZiAoIiVzJWQ6IEludmFsaWQgc2lnbmFsaW5nIGhl YWRlclxuIiwKKwkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCk7CitiYWQ6ICAgICAg ICAgICAgaWYgKGRlYnVnKSB7CisJCQlwcmludGYgKCIlMDJ4IiwgKmgrKyk7CisJCQl3aGls ZSAoLS1sZW4gPiAwKQorCQkJCXByaW50ZiAoIi0lMDJ4IiwgKmgrKyk7CisJCQlwcmludGYg KCJcbiIpOworCQl9CisJCXJldHVybjsKKwl9CisJaWYgKGhbNV0gPT0gRlJfTVNHX0VOUVVJ UlkpIHsKKwkJaWYgKGxlbiA9PSBGUl9FTlFVSVJZX1NJWkUgJiYKKwkJICAgIGhbMTJdID09 ICh1X2NoYXIpIHNwLT5wcF9zZXFbSURYX0xDUF0pIHsKKwkJCXNwLT5wcF9zZXFbSURYX0xD UF0gPSByYW5kb20oKTsKKwkJCXByaW50ZiAoIiVzJWQ6IGxvb3BiYWNrIGRldGVjdGVkXG4i LAorCQkJCWlmcC0+aWZfbmFtZSwgaWZwLT5pZl91bml0KTsKKwkJfQorCQlyZXR1cm47CisJ fQorCWlmIChoWzVdICE9IEZSX01TR19TVEFUVVMpIHsKKwkJaWYgKGRlYnVnKQorCQkJcHJp bnRmICgiJXMlZDogVW5rbm93biBzaWduYWxpbmcgbWVzc2FnZTogMHglMDJ4XG4iLAorCQkJ CWlmcC0+aWZfbmFtZSwgaWZwLT5pZl91bml0LCBoWzVdKTsKKwkJZ290byBiYWQ7CisJfQor CisJLyogUGFyc2UgbWVzc2FnZSBmaWVsZHMuICovCisJZm9yIChwPWgrNjsgcDxoK2xlbjsg KSB7CisJCXN3aXRjaCAoKnApIHsKKwkJZGVmYXVsdDoKKwkJCWlmIChkZWJ1ZykKKwkJCQlw cmludGYgKCIlcyVkOiBVbmtub3duIHNpZ25hbGluZyBmaWVsZCAweCV4XG4iLAorCQkJCQlp ZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCwgKnApOworCQkJYnJlYWs7CisJCWNhc2UgRlJf RkxEX0xTSElGVDU6CisJCWNhc2UgRlJfRkxEX1JUWVBFOgorCQkJLyogSWdub3JlLiAqLwor CQkJYnJlYWs7CisJCWNhc2UgRlJfRkxEX1ZFUklGWToKKwkJCWlmIChwWzFdICE9IDIpIHsK KwkJCQlpZiAoZGVidWcpCisJCQkJCXByaW50ZiAoIiVzJWQ6IEludmFsaWQgc2lnbmFsaW5n IHZlcmlmeSBmaWVsZCBsZW5ndGggJWRcbiIsCisJCQkJCQlpZnAtPmlmX25hbWUsIGlmcC0+ aWZfdW5pdCwgcFsxXSk7CisJCQkJYnJlYWs7CisJCQl9CisJCQlzcC0+cHBfcnNlcVtJRFhf TENQXSA9IHBbMl07CisJCQlpZiAoZGVidWcpIHsKKwkJCQlwcmludGYgKCIlcyVkOiBnb3Qg bG1pIHJlcGx5IHJzZXE9JWQsIHNlcT0lZCIsCisJCQkJCWlmcC0+aWZfbmFtZSwgaWZwLT5p Zl91bml0LCBwWzJdLCBwWzNdKTsKKwkJCQlpZiAocFszXSAhPSAodV9jaGFyKSBzcC0+cHBf c2VxW0lEWF9MQ1BdKQorCQkJCQlwcmludGYgKCIgKHJlYWxseSAlZCkiLAorCQkJCQkJKHVf Y2hhcikgc3AtPnBwX3NlcVtJRFhfTENQXSk7CisJCQkJcHJpbnRmICgiXG4iKTsKKwkJCX0K KwkJCWJyZWFrOworCQljYXNlIEZSX0ZMRF9QVkM6CisJCQlpZiAocFsxXSA8IDMpIHsKKwkJ CQlpZiAoZGVidWcpCisJCQkJCXByaW50ZiAoIiVzJWQ6IEludmFsaWQgUFZDIHN0YXR1cyBs ZW5ndGggJWRcbiIsCisJCQkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCwgcFsxXSk7 CisJCQkJYnJlYWs7CisJCQl9CisJCQlkbGNpID0gKHBbMl0gPDwgNCAmIDB4M2YwKSB8IChw WzNdID4+IDMgJiAweDBmKTsKKwkJCWlmICghIHNwLT5mcl9kbGNpKQorCQkJCXNwLT5mcl9k bGNpID0gZGxjaTsKKwkJCWlmIChzcC0+ZnJfc3RhdHVzICE9IHBbNF0pCisJCQkJcHJpbnRm ICgiJXMlZDogRExDSSAlZCAlcyVzXG4iLAorCQkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZf dW5pdCwgZGxjaSwKKwkJCQkJcFs0XSAmIEZSX0RMQ0lfREVMRVRFID8gImRlbGV0ZWQiIDoK KwkJCQkJcFs0XSAmIEZSX0RMQ0lfQUNUSVZFID8gImFjdGl2ZSIgOiAicGFzc2l2ZSIsCisJ CQkJCXBbNF0gJiBGUl9ETENJX05FVyA/ICIsIG5ldyIgOiAiIik7CisJCQlzcC0+ZnJfc3Rh dHVzID0gcFs0XTsKKwkJCWJyZWFrOworCQl9CisJCWlmICgqcCAmIDB4ODApCisJCQkrK3A7 CisJCWVsc2UgaWYgKHAgPCBoK2xlbisxICYmIHBbMV0pCisJCQlwICs9IDIgKyBwWzFdOwor CQllbHNlIHsKKwkJCWlmIChkZWJ1ZykKKwkJCQlwcmludGYgKCIlcyVkOiBJbnZhbGlkIHNp Z25hbGluZyBmaWVsZCAweCV4XG4iLAorCQkJCQlpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5p dCwgKnApOworCQkJZ290byBiYWQ7CisJCX0KKwl9CiB9Cg== --------------010302040108080607050007 Content-Type: text/plain; name="if_sppp_h.pch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_sppp_h.pch" --- if_sppp_c.h Wed Jul 4 18:59:21 2001 +++ if_sppp.h Fri Jul 13 17:43:37 2001 @@ -1,8 +1,9 @@ /* * Defines for synchronous PPP/Cisco link level subroutines. * - * Copyright (C) 1994 Cronyx Ltd. - * Author: Serge Vakulenko, + * Copyright (C) 1994-2001 Cronyx Ltd. + * Authors: Serge Vakulenko, + * Roman Kurakin, * * Heavily revamped to conform to RFC 1661. * Copyright (C) 1997, Joerg Wunsch. @@ -16,7 +17,6 @@ * * From: Version 2.0, Fri Oct 6 20:39:21 MSK 1995 * - * $FreeBSD: src/sys/net/if_sppp.h,v 1.16.2.1 2001/07/03 11:01:41 ume Exp $ */ #ifndef _NET_IF_SPPP_H_ @@ -106,6 +106,8 @@ struct sipcp ipv6cp; /* IPv6CP params */ struct sauth myauth; /* auth params, i'm peer */ struct sauth hisauth; /* auth params, i'm authenticator */ + u_short fr_dlci; /* Frame Relay DLCI number, 16..1023 */ + u_char fr_status; /* PVC status, active/new/delete */ /* * These functions are filled in by sppp_attach(), and are * expected to be used by the lower layer (hardware) drivers @@ -139,6 +141,7 @@ }; #define PP_KEEPALIVE 0x01 /* use keepalive protocol */ +#define PP_FR 0x04 /* use Frame Relay protocol instead of PPP */ /* 0x04 was PP_TIMO */ #define PP_CALLIN 0x08 /* we are being called */ #define PP_NEEDAUTH 0x10 /* remote requested authentication */ @@ -167,7 +170,8 @@ struct sppp defs; }; -#ifdef _KERNEL +#if (__FreeBSD_version >= 400000 && defined _KERNEL) \ + || (__FreeBSD_version < 400000 && defined KERNEL) void sppp_attach (struct ifnet *ifp); void sppp_detach (struct ifnet *ifp); void sppp_input (struct ifnet *ifp, struct mbuf *m); --------------010302040108080607050007-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 10: 3:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by hub.freebsd.org (Postfix) with ESMTP id 5F23237B406 for ; Fri, 13 Jul 2001 10:03:46 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp045-bsace7001.telebrasilia.net.br [200.181.80.45]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id KAA49035; Fri, 13 Jul 2001 10:03:36 -0700 (PDT) Message-ID: <3B4F2A53.1A4353EE@newsguy.com> Date: Fri, 13 Jul 2001 14:05:23 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: mark tinguely Cc: net@FreeBSD.ORG Subject: Re: Multicasting and routes References: <200107121424.f6CEO1040030@web.cs.ndsu.NoDak.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org mark tinguely wrote: > > > It seems there is a problem in our IP stack with regards to > > multicasting. The symptoms is the inability to send multicast packets on > > correctly configured sockets in the absence of a default (or, > > erroneously, multicast address being used) route. > > I don't know if I am reading your question correctly, but have you > tried adding a multicast route? In /etc/rc.conf: > > static_routes="multicast loopback" > route_multicast="224.0.0.0 -netmask 0xf0000000 -interface ${hostname}" > > this allows only one interface to send the multicast packets, and requires > a multicast router to place the packets on the other interfaces. A multicast application specifies what interface it wants to send the multicast packet through. The "one interface" limit mentioned on rfc1112 refers to the behavior when no interface is specified: a default is choosen and used. The route above is essentially incorrect. Fortunately, our IP stack behaves correctly when a default route (or a route to the multicast address) exists: it ignores it. Unfortunately, it only does so after checking if it knows a route to that address and returning host unreachable otherwise. I have a patch at http://people.freebsd.org/~dcs/ip_output.patch which I intend to commit unless someone objects. What it does is skip the route checking code if a interface was specified for the multicast packet. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 14:13:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id BE65737B403 for ; Fri, 13 Jul 2001 14:13:46 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 24977 invoked by uid 1000); 13 Jul 2001 21:13:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jul 2001 21:13:45 -0000 Date: Fri, 13 Jul 2001 16:13:45 -0500 (CDT) From: Mike Silbersack To: Martin Karsten Cc: Subject: Re: UDP packet loss on FreeBSD 4.x In-Reply-To: <200107131406.QAA03047@KOM.tu-darmstadt.de> Message-ID: <20010713161149.K24914-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 13 Jul 2001, Martin Karsten wrote: > 384/494/2048 mbuf clusters in use (current/peak/max) > > IMO the problem must have been introduced due to a change between versions > 3.4 and 4.x. I'm not experienced with driver programming, the only obvious > difference (at least with respect to the xl driver) is that it uses the mii > driver now. > > Thanks anyway, > Martin Hm, that's too bad. I'd help... but I don't have any driver experience either. :| Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 17:13:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 0FA9237B405 for ; Fri, 13 Jul 2001 17:13:47 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6E0Dgh21452 for net@freebsd.org; Fri, 13 Jul 2001 17:13:42 -0700 Date: Fri, 13 Jul 2001 17:13:42 -0700 From: Brooks Davis To: net@freebsd.org Subject: sysctl net.link.vlan.link.proto Message-ID: <20010713171342.A18472@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm working on modernizing the vlan device (making it loadable, unloadable, and clonable) and I've run into this sysctl. It allows you to set the ethernet protocol used for vlan packets. This doesn't strike me as very useful and it will cause problems with modularizing this code because its value must be know by the ethernet code. NetBSD clearly agrees with me because they never imported that part of the code. If someone is actually using this feature with a relativly stock system I'll figure out how to support it, but I rather doubt that's the case. Thanks, Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7T42/XY6L6fI4GtQRAjrJAJsFbtuCbcmSXVWWzvovwsnDq5kbNwCgs6uA k/kbJOFSHWTeGnu2AA88o3o= =l4Jk -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 18:54:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from condor.jinmei.org (wls03.pi.cuc.ac.jp [202.244.37.17]) by hub.freebsd.org (Postfix) with ESMTP id BDE4E37B406 for ; Fri, 13 Jul 2001 18:54:10 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (localhost [127.0.0.1]) by condor.jinmei.org (8.10.1/8.10.1) with ESMTP id f6C4YJ905638; Thu, 12 Jul 2001 13:34:22 +0900 (JST) Date: Thu, 12 Jul 2001 13:34:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stephen Degler Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPV6 panic? In-Reply-To: <20010712002752.A36881@crusoe.degler.net> References: <20010712002752.A36881@crusoe.degler.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Thu, 12 Jul 2001 00:27:52 -0400, >>>>> Stephen Degler said: > I have had several of these since 6/30, after I cvsup'ed > and rebuilt everything. I have been updating fairly frequently, > but the problem seems to persist. > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc02c3b10 > stack pointer = 0x10:0xcbb4ff28 > frame pointer = 0x10:0xcbb4ff3c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi6: tty:sio+) > kernel: type 12 trap, code=0 > Stopped at nd6_timer+_0x38: movl 0(%ebx),%eax db> trace > nd6_timer(0) at nd6_timer+0x38 > softclock(0) at softclock_0x30e If possible, please make the kernel core-dump, and get a back trace using gdb (and send it to the list). Also, if you find a procedure that can reproduce the panic, please let us know about it. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 13 23:43:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id F075D37B403; Fri, 13 Jul 2001 23:43:01 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f6E6gna56822; Sat, 14 Jul 2001 15:42:50 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <20010703003309K.matusita@jp.FreeBSD.org> References: <20010703003309K.matusita@jp.FreeBSD.org> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 529 From: Makoto MATSUSHITA To: brian@FreeBSD.org, net@FreeBSD.org Subject: [patch] supports 'protoX' notation for all IP protocol numbers Date: Sat, 14 Jul 2001 15:42:29 +0900 Message-Id: <20010714154229P.matusita@jp.FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've sent following patch; matusita> This patch does teach ppp(8) about 'ipv6' protocol (protocol matusita> number 41) to filter. This patch also fixes matusita> not-initializing 'f_dstop' variable for other protocols. but some other guys says that "why not you make ppp to specify protocol number directly, just like 'set filter out 0 permit 41' or whatever?" It's good suggestion to me, so I've update my patch to support this. *** This patch allows to users to specify any IP protocol number in their filter ruleset. For example, if you want to pass incoming L2TP (protocol number 115) packet, set filter in 0 permit proto115 where 'proto115' means 'protocol number 115'. Since ppp(8) doesn't know L2TP or any ppp(8) unsupported protocol, you can only specify src/dst addresses to a filter rule of these unknown protocols (specifying 'port' or whatever will not work). I hope this patch works as expected (I've tested with my ADSL line and it seems working) and doesn't hurt any existing features, but if you have a time, please review this patch. -- - Makoto `MAR' MATSUSHITA Index: command.c =================================================================== RCS file: /home/cvs/FreeBSD/usr.sbin/ppp/command.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- command.c 2001/07/10 10:17:07 1.1.1.1 +++ command.c 2001/07/14 06:25:24 1.3 @@ -2169,7 +2169,7 @@ "escape characters", "set escape hex-digit ..."}, {"filter", NULL, filter_Set, LOCAL_AUTH, "packet filters", "set filter alive|dial|in|out rule-no permit|deny " - "[src_addr[/width]] [dst_addr[/width]] [tcp|udp|icmp|ospf|igmp " + "[src_addr[/width]] [dst_addr[/width]] [tcp|udp|icmp|ospf|igmp|ipv6|protoN " "[src [lt|eq|gt port]] [dst [lt|eq|gt port]] [estab] [syn] [finrst]]"}, {"hangup", NULL, SetVariable, LOCAL_AUTH | LOCAL_CX, "hangup script", "set hangup chat-script", (const void *) VAR_HANGUP}, Index: filter.c =================================================================== RCS file: /home/cvs/FreeBSD/usr.sbin/ppp/filter.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- filter.c 2001/07/10 10:17:06 1.1.1.1 +++ filter.c 2001/07/14 06:25:25 1.3 @@ -159,13 +159,13 @@ int port; switch (proto) { - case P_IPIP: + case IPPROTO_IPIP: protocol_name = "ipip"; break; - case P_UDP: + case IPPROTO_UDP: protocol_name = "udp"; break; - case P_TCP: + case IPPROTO_TCP: protocol_name = "tcp"; break; default: @@ -197,7 +197,7 @@ switch (argc) { case 0: /* permit/deny all ICMP types */ - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; break; case 3: @@ -209,6 +209,7 @@ } tgt->f_srcop = OP_EQ; tgt->f_srcport = type; + tgt->f_dstop = OP_NONE; } break; @@ -255,7 +256,7 @@ argv += 3; } - if (proto == P_TCP) { + if (proto == IPPROTO_TCP) { for (; argc > 0; argc--, argv++) if (!strcmp(*argv, "estab")) tgt->f_estab = 1; @@ -286,13 +287,45 @@ log_Printf(LogWARN, "ParseIgmp: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } -#ifdef P_GRE static int +ParseIPv6(int argc, char const * const *argv, struct filterent *tgt) +{ + /* + * Filter currently is a catch-all. Requests are either permitted or + * dropped. + */ + if (argc != 0) { + log_Printf(LogWARN, "ParseIPv6: Too many parameters\n"); + return 0; + } else + tgt->f_srcop = tgt->f_dstop = OP_NONE; + + return 1; +} + +static int +ParseGenericProtocol(int argc, char const * const *argv, struct filterent *tgt) +{ + /* + * Filter currently is a catch-all. Requests are either permitted or + * dropped. + */ + if (argc != 0) { + log_Printf(LogWARN, "ParseGenericProtocol: Too many parameters\n"); + return 0; + } else + tgt->f_srcop = tgt->f_dstop = OP_NONE; + + return 1; +} + +#ifdef IPPROTO_GRE +static int ParseGRE(int argc, char const * const *argv, struct filterent *tgt) { /* @@ -303,13 +336,13 @@ log_Printf(LogWARN, "ParseGRE: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } #endif -#ifdef P_OSPF +#ifdef IPPROTO_OSPF static int ParseOspf(int argc, char const * const *argv, struct filterent *tgt) { @@ -321,7 +354,7 @@ log_Printf(LogWARN, "ParseOspf: Too many parameters\n"); return 0; } else - tgt->f_srcop = OP_NONE; + tgt->f_srcop = tgt->f_dstop = OP_NONE; return 1; } @@ -401,7 +434,7 @@ } argv++; - proto = P_NONE; + proto = 0; memset(&filterdata, '\0', sizeof filterdata); val = strtol(*argv, &wp, 0); @@ -435,7 +468,7 @@ } proto = filter_Nam2Proto(argc, argv); - if (proto == P_NONE) { + if (proto == 0) { if (!argc) log_Printf(LogWARN, "Parse: address/mask is expected.\n"); else if (ParseAddr(ipcp, *argv, &filterdata.f_src.ipaddr, @@ -446,7 +479,7 @@ proto = filter_Nam2Proto(argc, argv); if (!argc) log_Printf(LogWARN, "Parse: address/mask is expected.\n"); - else if (proto == P_NONE) { + else if (proto == 0) { if (ParseAddr(ipcp, *argv, &filterdata.f_dst.ipaddr, &filterdata.f_dst.mask, &filterdata.f_dst.width)) { filterdata.f_dsttype = addrtype(*argv); @@ -456,7 +489,7 @@ filterdata.f_dsttype = T_ADDR; if (argc) { proto = filter_Nam2Proto(argc, argv); - if (proto == P_NONE) { + if (proto == 0) { log_Printf(LogWARN, "Parse: %s: Invalid protocol\n", *argv); return 0; } else { @@ -486,31 +519,37 @@ filterdata.f_proto = proto; switch (proto) { - case P_TCP: - val = ParseUdpOrTcp(argc, argv, P_TCP, &filterdata); + case IPPROTO_TCP: + val = ParseUdpOrTcp(argc, argv, IPPROTO_TCP, &filterdata); + break; + case IPPROTO_UDP: + val = ParseUdpOrTcp(argc, argv, IPPROTO_UDP, &filterdata); break; - case P_UDP: - val = ParseUdpOrTcp(argc, argv, P_UDP, &filterdata); + case IPPROTO_IPIP: + val = ParseUdpOrTcp(argc, argv, IPPROTO_IPIP, &filterdata); break; - case P_IPIP: - val = ParseUdpOrTcp(argc, argv, P_IPIP, &filterdata); + case IPPROTO_IPV6: + val = ParseIPv6(argc, argv, &filterdata); break; - case P_ICMP: + case IPPROTO_ICMP: val = ParseIcmp(argc, argv, &filterdata); break; - case P_IGMP: + case IPPROTO_IGMP: val = ParseIgmp(argc, argv, &filterdata); break; -#ifdef P_OSPF - case P_OSPF: +#ifdef IPPROTO_OSPF + case IPPROTO_OSPF: val = ParseOspf(argc, argv, &filterdata); break; #endif -#ifdef P_GRE - case P_GRE: +#ifdef IPPROTO_GRE + case IPPROTO_GRE: val = ParseGRE(argc, argv, &filterdata); break; #endif + default: + val = ParseGenericProtocol(argc, argv, &filterdata); + break; } log_Printf(LogDEBUG, "Parse: Src: %s\n", inet_ntoa(filterdata.f_src.ipaddr)); @@ -652,31 +691,61 @@ return 0; } -static const char * const protoname[] = { - "none", "tcp", "udp", "icmp", "ospf", "igmp", "gre", "ipip" +struct protoname_table { + char *name; /* protocol name */ + int proto; /* protocol number */ +}; +static const struct protoname_table protoname[] = { + {"icmp", IPPROTO_ICMP}, + {"igmp", IPPROTO_IGMP}, + {"ipip", IPPROTO_IPIP}, + {"tcp", IPPROTO_TCP}, + {"udp", IPPROTO_UDP}, + {"ipv6", IPPROTO_IPV6}, + {"gre", IPPROTO_GRE}, + {"esp", IPPROTO_ESP}, + {"ah", IPPROTO_AH}, + {"ospf", IPPROTO_OSPFIGP}, + {NULL, 0}, /* end marker */ }; const char * filter_Proto2Nam(int proto) { - if (proto >= sizeof protoname / sizeof protoname[0]) - return "unknown"; - return protoname[proto]; + int idx = 0; + static char buf[BUFSIZ+1]; + + while (protoname[idx].name != NULL) { + if (protoname[idx].proto == proto) { + return protoname[idx].name; + } + idx++; + } + snprintf(buf, BUFSIZ, "proto%d", proto); + return buf; } static int filter_Nam2Proto(int argc, char const *const *argv) { + int idx = 0; int proto; if (argc == 0) - proto = 0; - else - for (proto = sizeof protoname / sizeof protoname[0] - 1; proto; proto--) - if (!strcasecmp(*argv, protoname[proto])) - break; + return 0; - return proto; + while (protoname[idx].name != NULL) { + if (!strcasecmp(*argv, protoname[idx].name)) { + return protoname[idx].proto; + } + idx++; + } + if (strncmp(*argv, "proto", 5) == 0) { + proto = atoi(*argv + 5); + if (proto > 0 && proto < IPPROTO_MAX) + return proto; + } + return 0; } static const char * const opname[] = {"none", "eq", "gt", "lt"}; Index: filter.h =================================================================== RCS file: /home/cvs/FreeBSD/usr.sbin/ppp/filter.h,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- filter.h 2001/07/10 10:17:05 1.1.1.1 +++ filter.h 2001/07/14 06:25:25 1.3 @@ -28,22 +28,6 @@ * $FreeBSD: src/usr.sbin/ppp/filter.h,v 1.27 2001/06/13 21:52:16 brian Exp $ */ -/* Known protocols - f_proto */ -#define P_NONE 0 -#define P_TCP 1 -#define P_UDP 2 -#define P_ICMP 3 -#ifdef IPPROTO_OSPFIGP -#define P_OSPF 4 -#endif -#define P_IGMP 5 -#ifdef IPPROTO_GRE -#define P_GRE 6 -#endif -#define P_ESP 7 -#define P_AH 8 -#define P_IPIP 9 - /* Operations - f_srcop, f_dstop */ #define OP_NONE 0 #define OP_EQ 1 @@ -73,7 +57,7 @@ */ struct filterent { unsigned f_action : 8; /* Filtering action: goto or A_... */ - unsigned f_proto : 8; /* Protocol: P_... */ + unsigned f_proto : 8; /* Protocol: IPPROTO_... */ unsigned f_srcop : 2; /* Source port operation: OP_... */ unsigned f_dstop : 2; /* Destination port operation: OP_... */ unsigned f_srctype : 3; /* T_ value of src */ Index: ip.c =================================================================== RCS file: /home/cvs/FreeBSD/usr.sbin/ppp/ip.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- ip.c 2001/07/10 10:17:04 1.1.1.1 +++ ip.c 2001/07/14 06:25:25 1.3 @@ -166,7 +166,7 @@ FilterCheck(const struct ip *pip, const struct filter *filter, unsigned *psecs) { int gotinfo; /* true if IP payload decoded */ - int cproto; /* P_* protocol type if (gotinfo) */ + int cproto; /* IPPROTO_* protocol type if (gotinfo) */ int estab, syn, finrst; /* TCP state flags if (gotinfo) */ u_short sport, dport; /* src, dest port from packet if (gotinfo) */ int n; /* filter rule to process */ @@ -220,7 +220,7 @@ fp->f_src.mask.s_addr) && !((pip->ip_dst.s_addr ^ fp->f_dst.ipaddr.s_addr) & fp->f_dst.mask.s_addr)) { - if (fp->f_proto != P_NONE) { + if (fp->f_proto != 0) { if (!gotinfo) { const char *ptop = (const char *) pip + (pip->ip_hl << 2); const struct tcphdr *th; @@ -229,9 +229,9 @@ int datalen; /* IP datagram length */ datalen = ntohs(pip->ip_len) - (pip->ip_hl << 2); + cproto = pip->ip_p; switch (pip->ip_p) { case IPPROTO_ICMP: - cproto = P_ICMP; if (datalen < 8) { /* ICMP must be at least 8 octets */ log_Printf(LogFILTER, " error: ICMP must be at least 8 octets\n"); return 1; @@ -244,7 +244,6 @@ snprintf(dbuff, sizeof dbuff, "sport = %d", sport); break; case IPPROTO_IGMP: - cproto = P_IGMP; if (datalen < 8) { /* IGMP uses 8-octet messages */ log_Printf(LogFILTER, " error: IGMP must be at least 8 octets\n"); return 1; @@ -254,7 +253,6 @@ break; #ifdef IPPROTO_GRE case IPPROTO_GRE: - cproto = P_GRE; if (datalen < 2) { /* GRE uses 2-octet+ messages */ log_Printf(LogFILTER, " error: GRE must be at least 2 octets\n"); return 1; @@ -265,7 +263,6 @@ #endif #ifdef IPPROTO_OSPFIGP case IPPROTO_OSPFIGP: - cproto = P_OSPF; if (datalen < 8) { /* IGMP uses 8-octet messages */ log_Printf(LogFILTER, " error: IGMP must be at least 8 octets\n"); return 1; @@ -275,22 +272,26 @@ break; #endif case IPPROTO_ESP: - cproto = P_ESP; estab = syn = finrst = -1; sport = ntohs(0); break; case IPPROTO_AH: - cproto = P_AH; estab = syn = finrst = -1; sport = ntohs(0); break; case IPPROTO_IPIP: - cproto = P_IPIP; sport = dport = 0; estab = syn = finrst = -1; break; + case IPPROTO_IPV6: + if (datalen < 20) { /* RFC2893 Section 3.5: 5 * 32bit words */ + log_Printf(LogFILTER, " error: IPV6 header incorrect\n"); + return 1; + } + sport = dport = 0; + estab = syn = finrst = -1; + break; case IPPROTO_UDP: - cproto = P_UDP; if (datalen < 8) { /* UDP header is 8 octets */ log_Printf(LogFILTER, " error: UDP/IPIP" " must be at least 8 octets\n"); @@ -306,7 +307,6 @@ sport, dport); break; case IPPROTO_TCP: - cproto = P_TCP; th = (const struct tcphdr *) ptop; /* TCP headers are variable length. The following code * ensures that the TCP header length isn't de-referenced if @@ -331,8 +331,10 @@ } break; default: - log_Printf(LogFILTER, " error: unknown protocol\n"); - return 1; /* We'll block unknown type of packet */ + /* unknown protocol, no port checking and flags */ + sport = dport = 0; + estab = syn = finrst = -1; + break; } if (log_IsKept(LogDEBUG)) { @@ -640,6 +642,20 @@ len = ntohs(pip->ip_len) - (pip->ip_hl << 2); snprintf(logbuf + loglen, sizeof logbuf - loglen, "OSPF: %s ---> ", inet_ntoa(pip->ip_src)); + loglen += strlen(logbuf + loglen); + snprintf(logbuf + loglen, sizeof logbuf - loglen, + "%s (%d/%d)", inet_ntoa(pip->ip_dst), len, nb); + loglen += strlen(logbuf + loglen); + } + break; +#endif + +#ifdef IPPROTO_IPV6 + case IPPROTO_IPV6: + if (logit && loglen < sizeof logbuf) { + len = ntohs(pip->ip_len) - (pip->ip_hl << 2); + snprintf(logbuf + loglen, sizeof logbuf - loglen, + "IPv6: %s ---> ", inet_ntoa(pip->ip_src)); loglen += strlen(logbuf + loglen); snprintf(logbuf + loglen, sizeof logbuf - loglen, "%s (%d/%d)", inet_ntoa(pip->ip_dst), len, nb); Index: ppp.8 =================================================================== RCS file: /home/cvs/FreeBSD/usr.sbin/ppp/ppp.8,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- ppp.8 2001/07/10 10:17:02 1.1.1.1 +++ ppp.8 2001/07/14 06:25:25 1.3 @@ -1746,10 +1746,13 @@ .Sq icmp , .Sq igmp , .Sq ipip , +.Sq ipv6 , .Sq ospf , -.Sq udp +.Sq udp , +.Sq tcp or -.Sq tcp . +.Sq protoN +where N is a protocol number. .It .Ar Cmp is one of To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 3:45:11 2001 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 45DBE37B405; Sat, 14 Jul 2001 03:45:02 -0700 (PDT) (envelope-from Martin@McFlySr.Kurgan.Ru) Received: from 127.0.0.1 (fat.ti.ru [212.1.224.35]) by fat.ti.ru (Postfix) with ESMTP id 8A2C1D927; Sat, 14 Jul 2001 14:44:49 +0400 (MSD) Date: Sat, 14 Jul 2001 14:44:50 +0400 From: Martin McFlySr X-Mailer: The Bat! (v1.51) Business Reply-To: Martin McFlySr Organization: Back To The Future X-Priority: 3 (Normal) Message-ID: <1836672504.20010714144450@McFlySr.Kurgan.Ru> To: freebsd-stable@FreeBSD.ORG Cc: net@FreeBSD.ORG Subject: mpd, (GRE/NETGRAPH), kernel panic, abort trap in FreeBSD 3.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello net@FreeBSD.ORG, #uname -a FreeBSD 4.3-STABLE #3: Fri Jul 13 09:37:43 MSD 2001 In MyKernel i include all "options NETGRAPH*". After run mpd (for pptp session to other fbsd/mpd) and establish session >---- Jul 13 10:22:29 mpd: [vpn] CCP: state change Req-Sent --> Ack-Sent Jul 13 10:22:29 mpd: [vpn] IPCP: rec'd Configure Ack #2 link 0 (Ack-Sent) Jul 13 10:22:29 mpd: IPADDR 212.1.227.125 Jul 13 10:22:29 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jul 13 10:22:29 mpd: [vpn] IPCP: state change Ack-Sent --> Opened Jul 13 10:22:29 mpd: [vpn] IPCP: LayerUp Jul 13 10:22:29 mpd: 200.200.200.200 -> 192.168.1.1 Jul 13 10:22:29 mpd: [vpn] IFACE: Up event Jul 13 10:22:29 mpd: [vpn] exec: /sbin/ifconfig ng0 200.200.200.200 192.168 .1.1 netmask 0xffffffff -link0 Jul 13 10:22:29 mpd: [vpn] exec: /sbin/route add 0.0.0.0 192.168.1.1 Jul 13 10:22:29 mpd: [vpn] IFACE: Up event Jul 13 10:22:29 mpd: MPPC Jul 13 10:22:29 mpd: 0x00000040: MPPE, 128 bit Jul 13 10:22:29 mpd: [vpn] CCP: state change Ack-Sent --> Opened u 23:34 12-Jul-2001) >---- and after 1...2 minutes FreeBSD got a abort trrap 12, address 0x70. Hardware is Ok - last " make world " proceeded 6 hours, and mistakes have not arisen. Precisely same problem is described in the letter: >--- Subject: mpd-3.2 makes FreeBSD 4.2R panic Message-ID: Date: Fri, 13 Apr 2001 12:03:48 +0200 (MET DST) >--- but no answer was given :( What can i fix this ? Thank you, -- Saturday, 14 July 2001, 14:03 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 Sat Jul 14 4:49:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 968B837B401 for ; Sat, 14 Jul 2001 04:49:09 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f6EBn7V78543 for ; Sat, 14 Jul 2001 13:49:07 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f6EBntk23077 for freebsd-net@freebsd.org; Sat, 14 Jul 2001 13:49:55 +0200 (CEST) Date: Sat, 14 Jul 2001 13:49:55 +0200 From: Bernd Walter To: freebsd-net@freebsd.org Subject: how to get AF_LOCAL from getaddrinfo() Message-ID: <20010714134954.A23031@cicely20.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm doing the following: [...] int res; struct addrinfo *info; struct addrinfo hints; bzero(&hints, sizeof(hints)); hints.ai_flags = AI_PASSIVE; hints.ai_socktype = SOCK_STREAM; hints.ai_family = AF_UNSPEC; res = getaddrinfo(ip, portname, &hints, &info); if (res != 0) { fprintf(stderr, "getaddrinfo failed: %s\n", gai_strerror(res)); exit(1); } [...] ip = "/var/run/something"; portname = "/local"; results in: getaddrinfo failed: servname not supported for ai_socktype ip = "/var/run/something"; portname = NULL; results in: getaddrinfo failed: No address associated with hostname ip = "/var/run/something"; portname = NULL; hints.ai_family = AF_LOCAL results in: getaddrinfo failed: ai_family not supported -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 8:43: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7B337B401 for ; Sat, 14 Jul 2001 08:42:57 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:q+554qaysMu1+ErBuIKt2ujlPmTrelpMprA0pJRkSIOWn7VULOfmJUVFLIXiQfcO@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.4/8.11.4/peace) with ESMTP/inet6 id f6EFgLa75222; Sun, 15 Jul 2001 00:42:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 15 Jul 2001 00:42:17 +0900 (JST) Message-Id: <20010715.004217.07562357.ume@mahoroba.org> To: ticso@mail.cicely.de Cc: freebsd-net@freebsd.org Subject: Re: how to get AF_LOCAL from getaddrinfo() From: Hajimu UMEMOTO In-Reply-To: <20010714134954.A23031@cicely20.cicely.de> References: <20010714134954.A23031@cicely20.cicely.de> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 14 Jul 2001 13:49:55 +0200 >>>>> Bernd Walter said: ticso> ip = "/var/run/something"; portname = "/local"; ticso> results in: ticso> getaddrinfo failed: servname not supported for ai_socktype ticso> ip = "/var/run/something"; portname = NULL; ticso> results in: ticso> getaddrinfo failed: No address associated with hostname ticso> ip = "/var/run/something"; portname = NULL; hints.ai_family = AF_LOCAL ticso> results in: ticso> getaddrinfo failed: ai_family not supported Our getaddrinfo(3) doesn't support AF_UNIX. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 9:42: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id B0E5337B616; Sat, 14 Jul 2001 09:41:56 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6EGfVY19286; Sat, 14 Jul 2001 17:41:31 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6EGhem72494; Sat, 14 Jul 2001 17:43:40 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107141643.f6EGhem72494@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Makoto MATSUSHITA Cc: brian@FreeBSD.ORG, net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: [patch] supports 'protoX' notation for all IP protocol numbers In-Reply-To: Message from Makoto MATSUSHITA of "Sat, 14 Jul 2001 15:42:29 +0900." <20010714154229P.matusita@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 14 Jul 2001 17:43:40 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'll look at merging this into my development sources. I've been working on abstracting NCP addresses so that IP6 functionality can be developed on ppp more easily. I'll hopefully have something worth committing in the next few days. Thanks. > I've sent following patch; > > matusita> This patch does teach ppp(8) about 'ipv6' protocol (protocol > matusita> number 41) to filter. This patch also fixes > matusita> not-initializing 'f_dstop' variable for other protocols. > > but some other guys says that "why not you make ppp to specify > protocol number directly, just like 'set filter out 0 permit 41' or whatever?" > It's good suggestion to me, so I've update my patch to support this. > > *** > > This patch allows to users to specify any IP protocol number in their > filter ruleset. For example, if you want to pass incoming L2TP > (protocol number 115) packet, > > set filter in 0 permit proto115 > > where 'proto115' means 'protocol number 115'. Since ppp(8) doesn't > know L2TP or any ppp(8) unsupported protocol, you can only specify > src/dst addresses to a filter rule of these unknown protocols > (specifying 'port' or whatever will not work). > > I hope this patch works as expected (I've tested with my ADSL line and > it seems working) and doesn't hurt any existing features, but if you > have a time, please review this patch. > > -- - > Makoto `MAR' MATSUSHITA [patch deleted] -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 9:43:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id D9A3B37B401 for ; Sat, 14 Jul 2001 09:43:45 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f6EGheV79705; Sat, 14 Jul 2001 18:43:40 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f6EGiSv23615; Sat, 14 Jul 2001 18:44:28 +0200 (CEST) Date: Sat, 14 Jul 2001 18:44:27 +0200 From: Bernd Walter To: Hajimu UMEMOTO Cc: ticso@mail.cicely.de, freebsd-net@FreeBSD.ORG Subject: Re: how to get AF_LOCAL from getaddrinfo() Message-ID: <20010714184427.C23031@cicely20.cicely.de> References: <20010714134954.A23031@cicely20.cicely.de> <20010715.004217.07562357.ume@mahoroba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010715.004217.07562357.ume@mahoroba.org>; from ume@mahoroba.org on Sun, Jul 15, 2001 at 12:42:17AM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 15, 2001 at 12:42:17AM +0900, Hajimu UMEMOTO wrote: > >>>>> On Sat, 14 Jul 2001 13:49:55 +0200 > >>>>> Bernd Walter said: > > ticso> ip = "/var/run/something"; portname = "/local"; > ticso> results in: > ticso> getaddrinfo failed: servname not supported for ai_socktype > > ticso> ip = "/var/run/something"; portname = NULL; > ticso> results in: > ticso> getaddrinfo failed: No address associated with hostname > > ticso> ip = "/var/run/something"; portname = NULL; hints.ai_family = AF_LOCAL > ticso> results in: > ticso> getaddrinfo failed: ai_family not supported > > Our getaddrinfo(3) doesn't support AF_UNIX. Arg - I looked into src/contrib/bin/lib/irs/getaddrinfo.c The one in libc is different... Any idea if it will be supported in a future version? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 9:49:19 2001 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 0AA8837B40C for ; Sat, 14 Jul 2001 09:49:17 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f6EGnEb01827; Sat, 14 Jul 2001 12:49:14 -0400 (EDT) (envelope-from wollman) Date: Sat, 14 Jul 2001 12:49:14 -0400 (EDT) From: Garrett Wollman Message-Id: <200107141649.f6EGnEb01827@khavrinen.lcs.mit.edu> To: Brooks Davis Cc: net@FreeBSD.org Subject: sysctl net.link.vlan.link.proto In-Reply-To: <20010713171342.A18472@Odin.AC.HMC.Edu> References: <20010713171342.A18472@Odin.AC.HMC.Edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > I'm working on modernizing the vlan device (making it loadable, > unloadable, and clonable) and I've run into this sysctl. It allows you > to set the ethernet protocol used for vlan packets. This doesn't strike > me as very useful [...] It has never proven useful to me, but all the VLAN-capable switches I have seen allow the Ethertype to be configured, so I figured that there must have been some need or requirement for it somewhere. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 10:25:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D4BDE37B403; Sat, 14 Jul 2001 10:25:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA74840; Sat, 14 Jul 2001 12:13:29 -0700 (PDT) Message-ID: <3B507E22.10AF8D81@elischer.org> Date: Sat, 14 Jul 2001 10:15:14 -0700 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: Martin McFlySr Cc: freebsd-stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: mpd, (GRE/NETGRAPH), kernel panic, abort trap in FreeBSD 3.4 References: <1836672504.20010714144450@McFlySr.Kurgan.Ru> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Martin McFlySr wrote: > > Hello net@FreeBSD.ORG, > > #uname -a > FreeBSD 4.3-STABLE #3: Fri Jul 13 09:37:43 MSD 2001 > > In MyKernel i include all "options NETGRAPH*". > > After run mpd (for pptp session to other fbsd/mpd) and establish session > > >---- > Jul 13 10:22:29 mpd: [vpn] CCP: state change Req-Sent --> Ack-Sent > Jul 13 10:22:29 mpd: [vpn] IPCP: rec'd Configure Ack #2 link 0 (Ack-Sent) > Jul 13 10:22:29 mpd: IPADDR 212.1.227.125 > Jul 13 10:22:29 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid > Jul 13 10:22:29 mpd: [vpn] IPCP: state change Ack-Sent --> Opened > Jul 13 10:22:29 mpd: [vpn] IPCP: LayerUp > Jul 13 10:22:29 mpd: 200.200.200.200 -> 192.168.1.1 > Jul 13 10:22:29 mpd: [vpn] IFACE: Up event > Jul 13 10:22:29 mpd: [vpn] exec: /sbin/ifconfig ng0 200.200.200.200 192.168 > .1.1 netmask 0xffffffff -link0 > Jul 13 10:22:29 mpd: [vpn] exec: /sbin/route add 0.0.0.0 192.168.1.1 > Jul 13 10:22:29 mpd: [vpn] IFACE: Up event > Jul 13 10:22:29 mpd: MPPC > Jul 13 10:22:29 mpd: 0x00000040: MPPE, 128 bit > Jul 13 10:22:29 mpd: [vpn] CCP: state change Ack-Sent --> Opened > u 23:34 12-Jul-2001) > >---- > > and after 1...2 minutes FreeBSD got a abort trrap 12, address 0x70. > > Hardware is Ok - last " make world " proceeded 6 hours, and mistakes have > not arisen. > > Precisely same problem is described in the letter: > > >--- > Subject: mpd-3.2 makes FreeBSD 4.2R panic > Message-ID: > Date: Fri, 13 Apr 2001 12:03:48 +0200 (MET DST) > >--- > > but no answer was given :( > > What can i fix this ? If it is reporoducable for you, then you need to make a debug kernel (config -g MYKERNEL) then enable core-dumps (dumpon /dev/ad0s1b) then make sure that when it happens a core-dump is made and then saved at next boot After that you can cd /sys/compile/MYKERNEL gdb -k kernel.debug /somewhere/crashdump to get a full traceback. (info stack) and send that to us.. :-) > > Thank you, > > -- > Saturday, 14 July 2001, > 14:03 > > Best regards from future, > Martin McFlySr, HillDale. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 12:51:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 09A4D37B403 for ; Sat, 14 Jul 2001 12:51:20 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6EJpFm18594; Sat, 14 Jul 2001 12:51:15 -0700 Date: Sat, 14 Jul 2001 12:51:15 -0700 From: Brooks Davis To: Garrett Wollman Cc: net@FreeBSD.org Subject: Re: sysctl net.link.vlan.link.proto Message-ID: <20010714125115.A17574@Odin.AC.HMC.Edu> References: <20010713171342.A18472@Odin.AC.HMC.Edu> <200107141649.f6EGnEb01827@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107141649.f6EGnEb01827@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sat, Jul 14, 2001 at 12:49:14PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 14, 2001 at 12:49:14PM -0400, Garrett Wollman wrote: > < said: >=20 > > I'm working on modernizing the vlan device (making it loadable, > > unloadable, and clonable) and I've run into this sysctl. It allows you > > to set the ethernet protocol used for vlan packets. This doesn't strike > > me as very useful [...] >=20 > It has never proven useful to me, but all the VLAN-capable switches I > have seen allow the Ethertype to be configured, so I figured that > there must have been some need or requirement for it somewhere. I'll ask my Cisco rep if they know of anyone using this feature. If people _really_ need it, they can always edit sys/net/ethernet.h so I'll probably remove it for now. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 654D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7UKKzXY6L6fI4GtQRAh6JAJ4qaAz2vp/DFOHQ3/9HxH6h57+H1QCghAk9 O3TEsQlKTOhHGOsJFEhOQa0= =3BZZ -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 13:22:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from sirius.pc.cis.udel.edu (sirius.pc.cis.udel.edu [128.175.202.57]) by hub.freebsd.org (Postfix) with ESMTP id 0E53D37B403; Sat, 14 Jul 2001 13:22:17 -0700 (PDT) (envelope-from jain@sirius.pc.cis.udel.edu) Received: from localhost (localhost [127.0.0.1]) by sirius.pc.cis.udel.edu (8.11.3/8.11.3) with ESMTP id f6EKI2C00406; Sat, 14 Jul 2001 16:18:02 -0400 (EDT) (envelope-from jain@sirius.pc.cis.udel.edu) Date: Sat, 14 Jul 2001 16:18:02 -0400 (EDT) From: Manish Jain To: Cc: Subject: window scaling doesnt seem to work Message-ID: <20010714161716.H399-100000@sirius.pc.cis.udel.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Window scaling option in TCP header is not set everytime I try to set a window greater 250 Kbytes. If I am attempting to set a windwo in the range 64 K - 200 K ( I tired this range ), thn the window scaling works fine. I think that there is some kind of hard coding in the tcp code in netinet branch. Has anybody had the same problem or know of a quick fix so that I dont have to spend much time scanning the kernel code ? Please cc a reply to my email id too. -- manish jain university of delaware,newark (302) 454 1792 You know... that a blank wall is an apalling thing to look at. The wall of a museum -- a canvas -- a piece of film -- or a guy sitting in front of a typewriter. Then, you start out to do something -- that vague thing called creation. The beginning strikes awe within you. -Edward Steichen, "Wisdom" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 14:43: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id D392237B401; Sat, 14 Jul 2001 14:41:47 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6ELflx27984; Sat, 14 Jul 2001 14:41:47 -0700 Date: Sat, 14 Jul 2001 14:41:47 -0700 From: Brooks Davis To: net@freebsd.org, audit@freebsd.org Subject: review request: if_faith modernization Message-ID: <20010714144147.A27610@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please review the following patch. It makes the faith interface loadable, unloadable, and clonable. It also converts it from a count device to an option device. A copy is also available at: http://people.freebsd.org/~brooks/patches/faith.diff Thanks, Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 Index: sys/conf/files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.551 diff -u -r1.551 files --- sys/conf/files 2001/07/14 08:25:18 1.551 +++ sys/conf/files 2001/07/14 21:21:45 @@ -892,7 +892,7 @@ net/if_disc.c optional disc net/if_ef.c optional ef net/if_ethersubr.c optional ether -net/if_faith.c count faith +net/if_faith.c optional faith net/if_fddisubr.c optional fddi net/if_gif.c optional gif net/if_iso88025subr.c optional token @@ -1018,6 +1018,7 @@ netgraph/ng_echo.c optional netgraph_echo netgraph/ng_ether.c optional netgraph_ether netgraph/ng_frame_relay.c optional netgraph_frame_relay +netgraph/ng_gif.c optional netgraph_gif netgraph/ng_hole.c optional netgraph_hole netgraph/ng_iface.c optional netgraph_iface netgraph/ng_ksocket.c optional netgraph_ksocket Index: sys/modules/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.190 diff -u -r1.190 Makefile --- sys/modules/Makefile 2001/07/08 04:17:26 1.190 +++ sys/modules/Makefile 2001/07/13 23:10:49 @@ -6,21 +6,122 @@ _random=3D random .endif =20 -SUBDIR=3D 3dfx accf_data accf_http agp aha amr an aue \ - cam ccd cd9660 coda cue dc de digi ed fdescfs fdc fs fxp \ - if_disc if_ef if_gif if_ppp if_sl if_stf if_tap if_tun \ - ip6fw ipfilter ipfw ispfw joy kue lge \ - libmchain linux lnc md mii mlx msdosfs ncp netgraph nfs nge nmdm ntfs \ - nullfs nwfs pcn portalfs procfs ${_random} \ - rl rp sf sis sk sn snp sound sppp ste sym syscons sysvipc ti tl twe \ - tx udbp ugen uhid ukbd ulpt umapfs umass umodem ums unionfs urio usb \ +SUBDIR=3D 3dfx \ + accf_data \ + accf_http \ + agp \ + aha \ + amr \ + an \ + aue \ + cam \ + ccd \ + cd9660 \ + coda \ + cue \ + dc \ + de \ + digi \ + ed \ + fdescfs \ + fdc \ + fs \ + fxp \ + if_disc \ + if_ef \ + if_gif \ + if_ppp \ + if_sl \ + if_stf \ + if_tap \ + if_tun \ + ip6fw \ + ipfilter \ + ipfw \ + ispfw \ + joy \ + kue \ + lge \ + linux \ + lnc \ + md \ + mii \ + mlx \ + msdosfs \ + ncp \ + netgraph \ + nfs \ + nge \ + nmdm \ + ntfs \ + nullfs \ + nwfs \ + pcn \ + portalfs \ + procfs \ + ${_random} \ + rl \ + rp \ + sf \ + sis \ + sk \ + sn \ + snp \ + sound \ + sppp \ + ste \ + sym \ + syscons \ + sysvipc \ + ti \ + tl \ + twe \ + tx \ + udbp \ + ugen \ + uhid \ + ukbd \ + ulpt \ + umapfs \ + umass \ + umodem \ + ums \ + unionfs \ + urio \ + usb \ uscanner \ - vinum vpo vr vx wb wx xl + vinum \ + vpo \ + vr \ + vx \ + wb \ + wx \ + xl =20 # XXX some of these can move to the general case when de-i386'ed .if ${MACHINE_ARCH} =3D=3D "i386" -SUBDIR+=3Daac aic ar asr atspeaker bktr coff el fpu gnufpu ibcs2 mly \ - oltr pecoff ray s3 smbfs splash sr streams vesa wi +SUBDIR+=3Daac \ + aic \ + ar \ + asr \ + atspeaker \ + bktr \ + coff \ + el \ + fpu \ + gnufpu \ + ibcs2 \ + mly \ + oltr \ + pecoff \ + ray \ + s3 \ + smbfs \ + splash \ + sr \ + streams \ + vesa \ + wi .endif =20 .if ${MACHINE} =3D=3D "pc98" Index: sys/net/if_faith.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.6 diff -u -r1.6 if_faith.c --- sys/net/if_faith.c 2001/07/05 14:42:54 1.6 +++ sys/net/if_faith.c 2001/07/14 01:21:02 @@ -46,9 +46,6 @@ #include "opt_inet.h" #include "opt_inet6.h" =20 -#include "faith.h" -#if NFAITH > 0 - #include #include #include @@ -58,13 +55,16 @@ #include #include #include +#include +#include +#include /* XXX: Shouldn't really be required! */ +#include =20 #include #include #include #include #include -#include =20 #ifdef INET #include @@ -82,56 +82,159 @@ #include #endif =20 -#include "bpf.h" -#define NBPFILTER NBPF - #include =20 +#define FAITHNAME "faith" +#define FAITH_MAXUNIT 0x7fff /* ifp->if_unit is only 15 bits */ + +struct faith_softc { + struct ifnet sc_if; /* must be first */ + struct resource *r_unit; + LIST_ENTRY(faith_softc) sc_list; +}; + static int faithioctl __P((struct ifnet *, u_long, caddr_t)); int faithoutput __P((struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *)); static void faithrtrequest __P((int, struct rtentry *, struct sockaddr *)); +static int faithprefix __P((struct in6_addr *)); + +static int faithmodevent __P((module_t, int, void *)); + +static MALLOC_DEFINE(M_FAITH, FAITHNAME, "Firewall Assisted Tunnel Interfa= ce"); +static struct rman faithunits[1]; +LIST_HEAD(, faith_softc) faith_softc_list; =20 -void faithattach __P((void *)); -PSEUDO_SET(faithattach, if_faith); +int faith_clone_create __P((struct if_clone *, int *)); +void faith_clone_destroy __P((struct ifnet *)); =20 -static struct ifnet faithif[NFAITH]; +struct if_clone faith_cloner =3D + IF_CLONE_INITIALIZER(FAITHNAME, faith_clone_create, faith_clone_destro= y); =20 #define FAITHMTU 1500 =20 -/* ARGSUSED */ -void -faithattach(faith) - void *faith; +static int +faithmodevent(mod, type, data) + module_t mod; + int type; + void *data; { - struct ifnet *ifp; - int i; + int err; + + switch (type) { + case MOD_LOAD: + faithunits->rm_type =3D RMAN_ARRAY; + faithunits->rm_descr =3D "configurable if_faith units"; + err =3D rman_init(faithunits); + if (err !=3D 0) + return (err); + err =3D rman_manage_region(faithunits, 0, FAITH_MAXUNIT); + if (err !=3D 0) { + printf("%s: faithunits: rman_manage_region: " + "Failed %d\n", FAITHNAME, err); + rman_fini(faithunits); + return (err); + } + LIST_INIT(&faith_softc_list); + if_clone_attach(&faith_cloner); =20 - for (i =3D 0; i < NFAITH; i++) { - ifp =3D &faithif[i]; - bzero(ifp, sizeof(faithif[i])); - ifp->if_name =3D "faith"; - ifp->if_unit =3D i; - ifp->if_mtu =3D FAITHMTU; - /* LOOPBACK commented out to announce IPv6 routes to faith */ - ifp->if_flags =3D /* IFF_LOOPBACK | */ IFF_MULTICAST; - ifp->if_ioctl =3D faithioctl; - ifp->if_output =3D faithoutput; - ifp->if_type =3D IFT_FAITH; - ifp->if_snd.ifq_maxlen =3D ifqmaxlen; - ifp->if_hdrlen =3D 0; - ifp->if_addrlen =3D 0; - if_attach(ifp); -#if NBPFILTER > 0 -#ifdef HAVE_OLD_BPF - bpfattach(ifp, DLT_NULL, sizeof(u_int)); -#else - bpfattach(&ifp->if_bpf, ifp, DLT_NULL, sizeof(u_int)); +#ifdef INET6 + faithprefix_p =3D faithprefix; #endif + + break; + case MOD_UNLOAD: +#ifdef INET6 + faithprefix_p =3D NULL; #endif + + if_clone_detach(&faith_cloner); + + while (!LIST_EMPTY(&faith_softc_list)) + faith_clone_destroy( + &LIST_FIRST(&faith_softc_list)->sc_if); + + err =3D rman_fini(faithunits); + if (err !=3D 0) + return (err); + + break; + } + return 0; +} + +static moduledata_t faith_mod =3D { + "if_faith", + faithmodevent, + 0 +}; + +DECLARE_MODULE(if_faith, faith_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); +MODULE_VERSION(if_faith, 1); + +int +faith_clone_create(ifc, unit) + struct if_clone *ifc; + int *unit; +{ + struct resource *r; + struct faith_softc *sc; + + if (*unit > FAITH_MAXUNIT) + return (ENXIO); + + if (*unit < 0) { + r =3D rman_reserve_resource(faithunits, 0, FAITH_MAXUNIT, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (ENOSPC); + *unit =3D rman_get_start(r); + } else { + r =3D rman_reserve_resource(faithunits, *unit, *unit, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + if (r =3D=3D NULL) + return (ENOSPC); } + + sc =3D malloc(sizeof(struct faith_softc), M_FAITH, M_WAITOK); + bzero(sc, sizeof(struct faith_softc)); + + sc->sc_if.if_softc =3D sc; + sc->sc_if.if_name =3D FAITHNAME; + sc->sc_if.if_unit =3D *unit; + sc->r_unit =3D r; + + sc->sc_if.if_mtu =3D FAITHMTU; + /* Change to BROADCAST experimentaly to announce its prefix. */ + sc->sc_if.if_flags =3D /* IFF_LOOPBACK */ IFF_BROADCAST | IFF_MULTICAST; + sc->sc_if.if_ioctl =3D faithioctl; + sc->sc_if.if_output =3D faithoutput; + sc->sc_if.if_type =3D IFT_FAITH; + sc->sc_if.if_hdrlen =3D 0; + sc->sc_if.if_addrlen =3D 0; + if_attach(&sc->sc_if); + bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); + LIST_INSERT_HEAD(&faith_softc_list, sc, sc_list); + return (0); } =20 +void +faith_clone_destroy(ifp) + struct ifnet *ifp; +{ + int err; + struct faith_softc *sc =3D (void *) ifp; + + LIST_REMOVE(sc, sc_list); + bpfdetach(ifp); + if_detach(ifp); + + err =3D rman_release_resource(sc->r_unit); + KASSERT(err =3D=3D 0, ("Unexpected error freeing resource")); + + free(sc, M_FAITH); +} + int faithoutput(ifp, m, dst, rt) struct ifnet *ifp; @@ -144,7 +247,7 @@ =20 if ((m->m_flags & M_PKTHDR) =3D=3D 0) panic("faithoutput no HDR"); -#if NBPFILTER > 0 + /* BPF write needs to be handled specially */ if (dst->sa_family =3D=3D AF_UNSPEC) { dst->sa_family =3D *(mtod(m, int *)); @@ -168,13 +271,8 @@ m0.m_len =3D 4; m0.m_data =3D (char *)⁡ =20 -#ifdef HAVE_OLD_BPF bpf_mtap(ifp, &m0); -#else - bpf_mtap(ifp->if_bpf, &m0); -#endif } -#endif =20 if (rt && rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE)) { m_freem(m); @@ -297,7 +395,7 @@ * XXX could be slow * XXX could be layer violation to call sys/net from sys/netinet6 */ -int +static int faithprefix(in6) struct in6_addr *in6; { @@ -323,4 +421,3 @@ return ret; } #endif -#endif /* NFAITH > 0 */ Index: sys/netinet/in_pcb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.85 diff -u -r1.85 in_pcb.c --- sys/netinet/in_pcb.c 2001/06/29 12:07:29 1.85 +++ sys/netinet/in_pcb.c 2001/07/13 22:28:51 @@ -67,8 +67,6 @@ #include #endif /* INET6 */ =20 -#include "faith.h" - #ifdef IPSEC #include #include @@ -870,11 +868,9 @@ #endif if (inp->inp_faddr.s_addr =3D=3D INADDR_ANY && inp->inp_lport =3D=3D lport) { -#if defined(NFAITH) && NFAITH > 0 if (ifp && ifp->if_type =3D=3D IFT_FAITH && (inp->inp_flags & INP_FAITH) =3D=3D 0) continue; -#endif if (inp->inp_laddr.s_addr =3D=3D laddr.s_addr) return (inp); else if (inp->inp_laddr.s_addr =3D=3D INADDR_ANY) { Index: sys/netinet/ip_icmp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.58 diff -u -r1.58 ip_icmp.c --- sys/netinet/ip_icmp.c 2001/06/23 17:17:58 1.58 +++ sys/netinet/ip_icmp.c 2001/07/13 21:10:23 @@ -46,6 +46,7 @@ #include =20 #include +#include #include =20 #define _IP_VHL @@ -62,11 +63,6 @@ #include #endif =20 -#include "faith.h" -#if defined(NFAITH) && NFAITH > 0 -#include -#endif - #include =20 /* @@ -275,7 +271,6 @@ m->m_len +=3D hlen; m->m_data -=3D hlen; =20 -#if defined(NFAITH) && 0 < NFAITH if (m->m_pkthdr.rcvif && m->m_pkthdr.rcvif->if_type =3D=3D IFT_FAITH) { /* * Deliver very specific ICMP type only. @@ -288,7 +283,6 @@ goto freeit; } } -#endif =20 #ifdef ICMPPRINTFS if (icmpprintfs) Index: sys/netinet/ip_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- sys/netinet/ip_input.c 2001/06/23 17:17:58 1.174 +++ sys/netinet/ip_input.c 2001/07/13 21:12:18 @@ -60,6 +60,7 @@ =20 #include #include +#include #include #include #include @@ -86,11 +87,6 @@ #include #endif =20 -#include "faith.h" -#if defined(NFAITH) && NFAITH > 0 -#include -#endif - #ifdef DUMMYNET #include #endif @@ -636,7 +632,6 @@ if (ip->ip_dst.s_addr =3D=3D INADDR_ANY) goto ours; =20 -#if defined(NFAITH) && 0 < NFAITH /* * FAITH(Firewall Aided Internet Translator) */ @@ -648,7 +643,7 @@ m_freem(m); return; } -#endif + /* * Not for us; forward if possible and desirable. */ Index: sys/netinet/ip_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.127 diff -u -r1.127 ip_output.c --- sys/netinet/ip_output.c 2001/06/11 18:38:11 1.127 +++ sys/netinet/ip_output.c 2001/07/13 21:13:53 @@ -63,8 +63,6 @@ #include #include =20 -#include "faith.h" - #include =20 static MALLOC_DEFINE(M_IPMOPTS, "ip_moptions", "internet multicast options= "); @@ -1158,9 +1156,7 @@ case IP_RECVRETOPTS: case IP_RECVDSTADDR: case IP_RECVIF: -#if defined(NFAITH) && NFAITH > 0 case IP_FAITH: -#endif error =3D sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); if (error) @@ -1196,11 +1192,9 @@ OPTSET(INP_RECVIF); break; =20 -#if defined(NFAITH) && NFAITH > 0 case IP_FAITH: OPTSET(INP_FAITH); break; -#endif } break; #undef OPTSET @@ -1292,9 +1286,7 @@ case IP_RECVDSTADDR: case IP_RECVIF: case IP_PORTRANGE: -#if defined(NFAITH) && NFAITH > 0 case IP_FAITH: -#endif switch (sopt->sopt_name) { =20 case IP_TOS: @@ -1332,11 +1324,9 @@ optval =3D 0; break; =20 -#if defined(NFAITH) && NFAITH > 0 case IP_FAITH: optval =3D OPTBIT(INP_FAITH); break; -#endif } error =3D sooptcopyout(sopt, &optval, sizeof optval); break; Index: sys/netinet6/in6.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/in6.c,v retrieving revision 1.13 diff -u -r1.13 in6.c --- sys/netinet6/in6.c 2001/07/02 21:02:08 1.13 +++ sys/netinet6/in6.c 2001/07/13 22:58:31 @@ -138,6 +138,8 @@ =20 struct in6_multihead in6_multihead; /* XXX BSS initialization */ =20 +int (*faithprefix_p)(struct in6_addr *); + /* * Subroutine for in6_ifaddloop() and in6_ifremloop(). * This routine does actual work. Index: sys/netinet6/in6.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/in6.h,v retrieving revision 1.14 diff -u -r1.14 in6.h --- sys/netinet6/in6.h 2001/06/24 20:43:01 1.14 +++ sys/netinet6/in6.h 2001/07/13 22:58:22 @@ -600,6 +600,8 @@ #define satosin6(sa) ((struct sockaddr_in6 *)(sa)) #define sin6tosa(sin6) ((struct sockaddr *)(sin6)) #define ifatoia6(ifa) ((struct in6_ifaddr *)(ifa)) + +extern int (*faithprefix_p)(struct in6_addr *); #endif /* _KERNEL */ =20 __BEGIN_DECLS Index: sys/netinet6/icmp6.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/icmp6.c,v retrieving revision 1.13 diff -u -r1.13 icmp6.c --- sys/netinet6/icmp6.c 2001/07/03 11:54:07 1.13 +++ sys/netinet6/icmp6.c 2001/07/13 23:00:30 @@ -103,11 +103,6 @@ #include #endif =20 -#include "faith.h" -#if defined(NFAITH) && 0 < NFAITH -#include -#endif - #include =20 #ifdef HAVE_NRL_INPCB @@ -439,8 +434,7 @@ goto freeit; } =20 -#if defined(NFAITH) && 0 < NFAITH - if (faithprefix(&ip6->ip6_dst)) { + if (faithprefix_p !=3D NULL && (*faithprefix_p)(&ip6->ip6_dst)) { /* * Deliver very specific ICMP6 type only. * This is important to deilver TOOBIG. Otherwise PMTUD @@ -455,7 +449,6 @@ goto freeit; } } -#endif =20 icmp6stat.icp6s_inhist[icmp6->icmp6_type]++; icmp6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_msg); Index: sys/netinet6/in6_pcb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.c,v retrieving revision 1.15 diff -u -r1.15 in6_pcb.c --- sys/netinet6/in6_pcb.c 2001/06/11 12:39:05 1.15 +++ sys/netinet6/in6_pcb.c 2001/07/13 23:01:21 @@ -100,11 +100,6 @@ #include #include =20 -#include "faith.h" -#if defined(NFAITH) && NFAITH > 0 -#include -#endif - #ifdef IPSEC #include #ifdef INET6 @@ -1001,11 +996,10 @@ u_short fport =3D fport_arg, lport =3D lport_arg; int faith; =20 -#if defined(NFAITH) && NFAITH > 0 - faith =3D faithprefix(laddr); -#else - faith =3D 0; -#endif + if (faithprefix_p !=3D NULL) + faith =3D (*faithprefix_p)(laddr); + else + faith =3D 0; =20 /* * First look for an exact match. Index: sys/netinet6/ip6_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/ip6_input.c,v retrieving revision 1.28 diff -u -r1.28 ip6_input.c --- sys/netinet6/ip6_input.c 2001/07/02 21:02:09 1.28 +++ sys/netinet6/ip6_input.c 2001/07/13 21:19:34 @@ -120,8 +120,6 @@ =20 #include =20 -#include "faith.h" - #include =20 extern struct domain inet6domain; @@ -632,7 +630,6 @@ /* * FAITH(Firewall Aided Internet Translator) */ -#if defined(NFAITH) && 0 < NFAITH if (ip6_keepfaith) { if (ip6_forward_rt.ro_rt && ip6_forward_rt.ro_rt->rt_ifp && ip6_forward_rt.ro_rt->rt_ifp->if_type =3D=3D IFT_FAITH) { @@ -642,7 +639,6 @@ goto hbhcheck; } } -#endif =20 /* * Now there is no reason to process the packet if it's not our own Index: sys/netinet6/raw_ip6.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/raw_ip6.c,v retrieving revision 1.11 diff -u -r1.11 raw_ip6.c --- sys/netinet6/raw_ip6.c 2001/06/11 12:39:06 1.11 +++ sys/netinet6/raw_ip6.c 2001/07/13 23:01:32 @@ -104,11 +104,6 @@ =20 #include =20 -#include "faith.h" -#if defined(NFAITH) && 0 < NFAITH -#include -#endif - #define satosin6(sa) ((struct sockaddr_in6 *)(sa)) #define ifatoia6(ifa) ((struct in6_ifaddr *)(ifa)) =20 @@ -142,13 +137,11 @@ =20 rip6stat.rip6s_ipackets++; =20 -#if defined(NFAITH) && 0 < NFAITH - if (faithprefix(&ip6->ip6_dst)) { + if (faithprefix_p !=3D NULL && (*faithprefix_p)(&ip6->ip6_dst)) { /* XXX send icmp6 host/port unreach? */ m_freem(m); return IPPROTO_DONE; } -#endif =20 init_sin6(&rip6src, m); /* general init */ =20 Index: sys/netinet6/udp6_output.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/udp6_output.c,v retrieving revision 1.3 diff -u -r1.3 udp6_output.c --- sys/netinet6/udp6_output.c 2001/06/11 12:39:06 1.3 +++ sys/netinet6/udp6_output.c 2001/07/13 22:30:30 @@ -106,8 +106,6 @@ #endif #endif /*IPSEC*/ =20 -#include "faith.h" - #include =20 /* Index: sys/netinet6/udp6_usrreq.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.15 diff -u -r1.15 udp6_usrreq.c --- sys/netinet6/udp6_usrreq.c 2001/06/11 12:39:06 1.15 +++ sys/netinet6/udp6_usrreq.c 2001/07/13 23:01:40 @@ -106,11 +106,6 @@ #include #endif /*IPSEC*/ =20 -#include "faith.h" -#if defined(NFAITH) && NFAITH > 0 -#include -#endif - /* * UDP protocol inplementation. * Per RFC 768, August, 1980. @@ -161,13 +156,11 @@ =20 ip6 =3D mtod(m, struct ip6_hdr *); =20 -#if defined(NFAITH) && 0 < NFAITH - if (faithprefix(&ip6->ip6_dst)) { + if (faithprefix_p !=3D NULL && (*faithprefix_p)(&ip6->ip6_dst)) { /* XXX send icmp6 host/port unreach? */ m_freem(m); return IPPROTO_DONE; } -#endif =20 udpstat.udps_ipackets++; =20 Index: share/man/man4/faith.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/share/man/man4/faith.4,v retrieving revision 1.10 diff -u -r1.10 faith.4 --- share/man/man4/faith.4 2001/06/11 12:38:48 1.10 +++ share/man/man4/faith.4 2001/07/14 02:14:28 @@ -36,7 +36,7 @@ .Nm faith .Nd IPv6-to-IPv4 TCP relay capturing interface .Sh SYNOPSIS -.Cd "device faith" Op Ar count +.Cd "device faith" .Sh DESCRIPTION The .Nm --- sys/modules/if_faith/Makefile.orig Fri Jul 13 19:55:29 2001 +++ sys/modules/if_faith/Makefile Fri Jul 13 16:06:52 2001 @@ -0,0 +1,15 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../net + +KMOD=3D if_faith +SRCS=3D if_faith.c opt_inet.h opt_inet6.h +NOMAN=3D + +opt_inet.h: + echo "#define INET 1" > ${.TARGET} + +opt_inet6.h: + echo "#define INET6 1" > ${.TARGET} + +.include --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ULyaXY6L6fI4GtQRAhDLAKCuFUiaM2iTma0zV7W2CPg97JiEqQCcCgdm qOqdITYEPraWYbIs3eqgSPQ= =Ci8Q -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 16:11:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id EE19537B403; Sat, 14 Jul 2001 16:11:18 -0700 (PDT) (envelope-from alex@fump.kawo2.rwth-aachen.de) Received: from fump.kawo2.rwth-aachen.de (root@fump.kawo2.rwth-aachen.de [134.130.181.148]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id BAA05623; Sun, 15 Jul 2001 01:11:17 +0200 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.11.3/8.11.3) id f6ENBiu97487; Sun, 15 Jul 2001 01:11:44 +0200 (CEST) (envelope-from alex) Date: Sun, 15 Jul 2001 01:11:44 +0200 From: Alexander Langer To: Brooks Davis Cc: net@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: review request: if_faith modernization Message-ID: <20010715011143.A97334@fump.kawo2.rwth-aachen.de> References: <20010714144147.A27610@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010714144147.A27610@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Sat, Jul 14, 2001 at 02:41:47PM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Brooks Davis (brooks@one-eyed-alien.net): People. This is a good example why style fixes shouldn't happen with content fixes. I can't figure out what changed in this file: > RCS file: /home/ncvs/src/sys/modules/Makefile,v > retrieving revision 1.190 > diff -u -r1.190 Makefile > --- sys/modules/Makefile 2001/07/08 04:17:26 1.190 > +++ sys/modules/Makefile 2001/07/13 23:10:49 > diff -u -r1.6 if_faith.c > --- sys/net/if_faith.c 2001/07/05 14:42:54 1.6 > +++ sys/net/if_faith.c 2001/07/14 01:21:02 I'm just curious: Why don't you need to include sys/module.h? You don't include any other file that itself includes it, but module.h defines DECLARE_MODULE and friends, which you are using. I'm a little bit confused :-) > +#include /* XXX: Shouldn't really be required! */ Why do you include it then? :-) Haven't looked at the other stuff. Thanks Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 18: 5:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by hub.freebsd.org (Postfix) with ESMTP id E403637B408 for ; Sat, 14 Jul 2001 18:05:24 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp045-bsace7001.telebrasilia.net.br [200.181.80.45]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id SAA90038 for ; Sat, 14 Jul 2001 18:05:22 -0700 (PDT) Message-ID: <3B50ECDF.618ED83C@newsguy.com> Date: Sat, 14 Jul 2001 22:07:43 -0300 From: "Daniel C. Sobral" Reply-To: dcs@freebsd.org X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: 802.1q and multicasting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I discovered a curious problem while trying to set up some firewalls. I do not receive multicast packets through 802.1q (vlan tagging) unless I'm doing a tcpdump on the interface. My first thought was that this was promiscuous mode-related, but I tried calling ifpromisc() from if_up() on sys/net/if.c and that didn't help. I tried to find out what else was different when this was done through bpf, but aside a bpf flag I couldn't find anything. Anyone has any clues or insights? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 14 21:29:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2E1DF37B401; Sat, 14 Jul 2001 21:29:04 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6F4St226647; Sat, 14 Jul 2001 21:28:55 -0700 Date: Sat, 14 Jul 2001 21:28:55 -0700 From: Brooks Davis To: Alexander Langer Cc: net@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: review request: if_faith modernization Message-ID: <20010714212855.B26269@Odin.AC.HMC.Edu> References: <20010714144147.A27610@Odin.AC.HMC.Edu> <20010715011143.A97334@fump.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010715011143.A97334@fump.kawo2.rwth-aachen.de>; from alex@big.endian.de on Sun, Jul 15, 2001 at 01:11:44AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 15, 2001 at 01:11:44AM +0200, Alexander Langer wrote: > Thus spake Brooks Davis (brooks@one-eyed-alien.net): >=20 > People. This is a good example why style fixes shouldn't happen > with content fixes. I can't figure out what changed in this file: >=20 > > RCS file: /home/ncvs/src/sys/modules/Makefile,v > > retrieving revision 1.190 > > diff -u -r1.190 Makefile > > --- sys/modules/Makefile 2001/07/08 04:17:26 1.190 > > +++ sys/modules/Makefile 2001/07/13 23:10:49 dd pointed this out too. I just forgot that I had patched that. I'll commit it seperatly. (The actual change is adding if_faith.) > > diff -u -r1.6 if_faith.c > > --- sys/net/if_faith.c 2001/07/05 14:42:54 1.6 > > +++ sys/net/if_faith.c 2001/07/14 01:21:02 >=20 > I'm just curious: Why don't you need to include sys/module.h? > You don't include any other file that itself includes it, but > module.h defines DECLARE_MODULE and friends, which you are using. > I'm a little bit confused :-) I'm not sure. Things worked, so I didn't add more includes. > > +#include /* XXX: Shouldn't really be required! */ >=20 > Why do you include it then? :-) Because sys/rman.h bogusly contains refrences to bus_space_tag_t and bus_space_handle_t. The comment is actually brain's since that code is pretty much copyed from the cloning code for tun(4). Thanks, Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7URwFXY6L6fI4GtQRAr5QAJ9leEH0XDe3IVcUu/OXZtPHXLT3OwCfTEWo bfSvZKIoOWTgF+g2DQDi/i4= =epJb -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message