From owner-freebsd-net Sun Dec 8 14:28:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D85037B401 for ; Sun, 8 Dec 2002 14:28:39 -0800 (PST) Received: from office.LF.net (office.LF.net [212.9.190.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A3D443E4A for ; Sun, 8 Dec 2002 14:28:38 -0800 (PST) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net ([212.118.165.100]) by office.LF.net with esmtp (Exim 4.04) id 18L9uS-0000de-00 for freebsd-net@FreeBSD.ORG; Sun, 08 Dec 2002 23:28:24 +0100 Received: from krion by voodoo.oberon.net with local (Exim 4.10) id 18L9v9-0001eR-00 for freebsd-net@FreeBSD.ORG; вс, 08 дек 2002 23:29:07 +0100 Date: Sun, 8 Dec 2002 23:29:07 +0100 From: Kirill Ponomarew To: freebsd-net@FreeBSD.ORG Subject: znyx NIC's Message-ID: <20021208222907.GA6286@krion> Mail-Followup-To: Kirill Ponomarew , freebsd-net@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Fingerprint: : 58E7 B953 57A2 D9DD 4960 2A2D 402D 46E9 AEB4 26E5 User-Agent: Mutt/1.5.1i 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! we have just bought many 4 ports ZNYX NIC's - http://www.znyx.com/products/hardware/zx340q.htm. The NIC works good with dc driver, but only if the card is in 100baseTX mode, with 10baseT/UTP the NIC doesn't work at all. ifconfig says "no carrier" and on console many "watchdog timeout" messages. Znyx writes own drivers for FreeBSD, and with that drivers the NIC works well under both (100base/10base) modes. The driver's list is: http://www.znyx.com/support/drivers/ZX346Q_drivers.htm What have to be done to make this card working under 10baseT/UTP with dc driver? -- Kirill A short cut is the longest distance between two points. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 8 14:51:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63A9A37B401 for ; Sun, 8 Dec 2002 14:51:27 -0800 (PST) Received: from out6.mx.nwbl.wi.voyager.net (out6.mx.nwbl.wi.voyager.net [169.207.3.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDAE243E4A for ; Sun, 8 Dec 2002 14:51:26 -0800 (PST) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d118.as20.nwbl0.wi.voyager.net [169.207.138.118]) by out6.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 18D48DABE3; Sun, 8 Dec 2002 16:51:20 -0600 (CST) Date: Sun, 8 Dec 2002 16:58:58 -0600 (CST) From: Mike Silbersack To: Kirill Ponomarew Cc: freebsd-net@FreeBSD.ORG Subject: Re: znyx NIC's In-Reply-To: <20021208222907.GA6286@krion> Message-ID: <20021208165310.Y61645-100000@patrocles.silby.com> References: <20021208222907.GA6286@krion> 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 Sun, 8 Dec 2002, Kirill Ponomarew wrote: > Hi! > > we have just bought many 4 ports ZNYX NIC's - > http://www.znyx.com/products/hardware/zx340q.htm. > > The NIC works good with dc driver, but only if the card is > in 100baseTX mode, with 10baseT/UTP the NIC doesn't work at all. > > What have to be done to make this card working under 10baseT/UTP with > dc driver? > > -- > Kirill That's a good question. I checked out their downloadable driver, and it does not appear to provide source code for anything relevant. Perhaps you could drop them an e-mail asking for public release of the changes necessary to get 10baseT working. As that would in no way give away their "rainlink" technology, they might be willing. If that fails, you could locate someone running a recent release of linux and see if 10baseT works on those cards properly. If so, we can probably extract the necessary changes from the linux driver. If both of those fail, you could search for relevant documentation and we could work based off of that. 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 Sun Dec 8 19:42:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C12C37B401 for ; Sun, 8 Dec 2002 19:42:34 -0800 (PST) Received: from thevoid.delnoch.net (thevoid.delnoch.net [66.93.83.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE9A543E4A for ; Sun, 8 Dec 2002 19:42:33 -0800 (PST) (envelope-from jeffi@rcn.com) Received: by thevoid.delnoch.net (Postfix, from userid 1000) id 1E926F9F0; Sun, 8 Dec 2002 22:42:26 -0500 (EST) Date: Sun, 8 Dec 2002 22:42:26 -0500 From: Jeff To: freebsd-net@freebsd.org Subject: kerberos problems Message-ID: <20021209034225.GB11264@rcn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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, Recently I have setup KerberosV (the kdc is on a NetBSD system). I have client boxes on NetBSD, OpenBSD, and FreeBSD. On all of the boxes, I can successfully kinit (k5init on FreeBSD) a ticket, and change my password. Then I enable telnet on all of the above, I can connect to any of the three (Net/Open/FreeBSD) boxes, from either the Net, or OpenBSD boxes, however when I try to telnet out from the FreeBSD box (I have tried this on both a 4.7-RELEASE and -CURRENT box) (separate machines entirely FWIW) I get... [ Trying mutual KERBEROS5 (host/host.foo.net@FOO.NET)... ] Bus error (core dumped) ... I have not yet tried to debug the core file, that is my next step, but in the mean time, if anyone knows what/where the problem may be, I would appreciate any suggestions. Thank You Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 8 20:32:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F48A37B401 for ; Sun, 8 Dec 2002 20:32:50 -0800 (PST) Received: from thevoid.delnoch.net (thevoid.delnoch.net [66.93.83.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05F1C43EC2 for ; Sun, 8 Dec 2002 20:32:45 -0800 (PST) (envelope-from jeffi@rcn.com) Received: by thevoid.delnoch.net (Postfix, from userid 1000) id 4B8FAF9F0; Sun, 8 Dec 2002 23:32:38 -0500 (EST) Date: Sun, 8 Dec 2002 23:32:38 -0500 From: Jeff To: freebsd-net@freebsd.org Subject: Re: kerberos problems Message-ID: <20021209043238.GC11264@rcn.com> References: <20021209034225.GB11264@rcn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021209034225.GB11264@rcn.com> User-Agent: Mutt/1.4i 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 managed to track down another thread that I must have missed during earlier purusing of the archives, that states the same problem that was "fixed" by installing krb5 from ports, which I am attempting currently. Does anyone know of a fix/where the problem lies for the krb5 that ships with FBSD? Thanks > Recently I have setup KerberosV (the kdc is on a NetBSD system). > I have client boxes on NetBSD, OpenBSD, and FreeBSD. On all of the > boxes, I can successfully kinit (k5init on FreeBSD) a ticket, and > change my password. Then I enable telnet on all of the above, > I can connect to any of the three (Net/Open/FreeBSD) boxes, from either > the Net, or OpenBSD boxes, however when I try to telnet out from the > FreeBSD box (I have tried this on both a 4.7-RELEASE and -CURRENT box) > (separate machines entirely FWIW) > I get... > > [ Trying mutual KERBEROS5 (host/host.foo.net@FOO.NET)... ] > Bus error (core dumped) > > ... > I have not yet tried to debug the core file, that is my next step, > but in the mean time, if anyone knows what/where the problem may be, > I would appreciate any suggestions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 8 21:18:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C342037B401; Sun, 8 Dec 2002 21:18:29 -0800 (PST) Received: from hotmail.com (f55.law15.hotmail.com [64.4.23.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85F8A43E4A; Sun, 8 Dec 2002 21:18:29 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 8 Dec 2002 21:18:28 -0800 Received: from 81.31.160.37 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 09 Dec 2002 05:18:28 GMT X-Originating-IP: [81.31.160.37] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Spoofing Another Host Packet From User Land Date: Mon, 09 Dec 2002 05:18:28 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Dec 2002 05:18:28.0997 (UTC) FILETIME=[68848B50:01C29F42] 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 Dear All I want to know if i can use SOCK_RAW to create and send another Host ( with another IP) Packet from my box. Sayin' in another way , i want to know if the kernel fill the ip:ip_src field of the packet throw out by SOCK_RAW ? if i can not do this by raw socket how can i do that ? THANX S,H,Y _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 8 23:28:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE0037B401 for ; Sun, 8 Dec 2002 23:28:46 -0800 (PST) Received: from straylight.ringlet.net (office.sbnd.net [217.75.140.130]) by mx1.FreeBSD.org (Postfix) with SMTP id 740EF43EA9 for ; Sun, 8 Dec 2002 23:28:42 -0800 (PST) (envelope-from roam@ringlet.net) Received: (qmail 2752 invoked by uid 1000); 9 Dec 2002 07:28:15 -0000 Date: Mon, 9 Dec 2002 09:28:14 +0200 From: Peter Pentchev To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Spoofing Another Host Packet From User Land Message-ID: <20021209072814.GA372@straylight.oblivion.bg> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i 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 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 09, 2002 at 05:18:28AM +0000, soheil soheil wrote: > Dear All > I want to know if i can use SOCK_RAW to create and send another Host ( wi= th=20 > another IP) Packet from my box. Sayin' in another way , i want to know if= =20 > the kernel fill the ip:ip_src field of the packet throw out by SOCK_RAW ? > if i can not do this by raw socket how can i do that ? > THANX I'd suggest you take a look at the net/libnet port, and either use it, or check how it does things. I believe you have to at least set the IP_HDRINCL socket option on the raw socket. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the = original Sanskrit. --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE99EYO7Ri2jRYZRVMRAsOxAKCh7ubTWbrWijbz48tRKx8s7KFtIwCeKQLb 4L4uP9iFfNEplBqsm3/msLE= =zhXF -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 5: 8:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8787F37B401 for ; Mon, 9 Dec 2002 05:08:55 -0800 (PST) Received: from hotmail.com (f143.law15.hotmail.com [64.4.23.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA1443E4A for ; Mon, 9 Dec 2002 05:08:55 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Dec 2002 05:04:15 -0800 Received: from 81.31.160.37 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 09 Dec 2002 13:04:15 GMT X-Originating-IP: [81.31.160.37] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: I-TCP Lib on BSD Date: Mon, 09 Dec 2002 13:04:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Dec 2002 13:04:15.0588 (UTC) FILETIME=[79FBEA40:01C29F83] 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 Dear All in this paper: Implementation and Performance Evaluation of Indirect TCP - Bakre, Badrinath (1997) It says the i-tcp lib. is availabe on BSD4.3 where can i find this i want the one for 4.4BSD THANX _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 5:37: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E14037B401 for ; Mon, 9 Dec 2002 05:37:08 -0800 (PST) Received: from dgap-gw.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA5CA43F55 for ; Mon, 9 Dec 2002 05:37:04 -0800 (PST) (envelope-from andrew@nas.dgap.mipt.ru) Received: from nas.dgap.mipt.ru (nas.dgap.mipt.ru [194.85.81.203]) by dgap-gw.mipt.ru (8.11.6/8.11.6) with ESMTP id gB9DWZT04107 for ; Mon, 9 Dec 2002 16:32:35 +0300 Received: (from andrew@localhost) by nas.dgap.mipt.ru (8.12.6/8.12.6/Submit) id gB9DbA2m003389 for freebsd-net@freebsd.org; Mon, 9 Dec 2002 16:37:10 +0300 (MSK) Date: Mon, 9 Dec 2002 16:37:10 +0300 From: "Andrew L. Neporada" To: freebsd-net@freebsd.org Subject: persistent routes Message-ID: <20021209133710.GA2639@nas.dgap.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 Is there any possibility to have multiple routing tables in FreeBSD? Something like "ip route" utilities in Linux. Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 6:44: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAACD37B401 for ; Mon, 9 Dec 2002 06:44:01 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0CB143EC5 for ; Mon, 9 Dec 2002 06:44:00 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gB9EhsBF070622; Mon, 9 Dec 2002 09:43:54 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 9 Dec 2002 09:43:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Spoofing Another Host Packet From User Land 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 Mon, 9 Dec 2002, soheil soheil wrote: > I want to know if i can use SOCK_RAW to create and send another Host ( > with another IP) Packet from my box. Sayin' in another way , i want to > know if the kernel fill the ip:ip_src field of the packet throw out by > SOCK_RAW ? if i can not do this by raw socket how can i do that ? The ip(4) man page has a description of IP raw sockets in detail; the socket option you're interested in is IP_HDRINCL. You may want to dig up one of the network programming books by Stevens to find out more about low level network programming. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 8:13:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FBB37B401 for ; Mon, 9 Dec 2002 08:13:29 -0800 (PST) Received: from seed.net.tw (sn15.seed.net.tw [139.175.54.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 489CB43EB2 for ; Mon, 9 Dec 2002 08:13:23 -0800 (PST) (envelope-from leafy@leafy.idv.tw) Received: from [61.59.151.48] (port=49166 helo=leafy.idv.tw) by seed.net.tw with esmtp (Seednet 4.10:3) id 18LQWz-0008AQ-00 for freebsd-net@freebsd.org; Tue, 10 Dec 2002 00:13:17 +0800 Received: from leafy.idv.tw (localhost [127.0.0.1]) by leafy.idv.tw (8.12.6/8.12.6) with ESMTP id gB9GDGoU000636 for ; Tue, 10 Dec 2002 00:13:16 +0800 (CST) (envelope-from leafy@leafy.idv.tw) Received: (from leafy@localhost) by leafy.idv.tw (8.12.6/8.12.6/Submit) id gB9GDGaf000635 for freebsd-net@freebsd.org; Tue, 10 Dec 2002 00:13:16 +0800 (CST) Date: Tue, 10 Dec 2002 00:13:16 +0800 From: leafy To: freebsd-net@freebsd.org Subject: [leafy@leafy.idv.tw: Confused by mpd and ipnat] Message-ID: <20021209161316.GA625@leafy.idv.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.5.1i 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 ----- Forwarded message from leafy ----- Date: Tue, 10 Dec 2002 00:06:21 +0800 From: leafy To: freebsd-current@FreeBSD.ORG Subject: Confused by mpd and ipnat I run -current and decided to try kernel PPPoE. I installed mpd from ports which ran fine. After installing ipnat, I setup the following rule in ipnat.rules: map ng0 192.168.0.0/24 -> 0/32 When I reboot, this line (along with ipnat stuff) got executed before mpd fiinishes PPPoE negotiation, and ipnat -l shows no traffice could be passed from the local network. (no mapping exists) Only after I do "ipnat -C && ipnat -f /etc/ipnat.rules" can I get traffice through. Is there anyway I can ensure that "ipnat -f /etc/ipnat.rules" get executed only after mpd has obtained proper ip settings? Thank you, JY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 9:24:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC81C37B401; Mon, 9 Dec 2002 09:24:31 -0800 (PST) Received: from hotmail.com (f91.law15.hotmail.com [64.4.23.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8145243EC5; Mon, 9 Dec 2002 09:24:31 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Dec 2002 09:18:58 -0800 Received: from 62.217.78.252 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 09 Dec 2002 17:18:58 GMT X-Originating-IP: [62.217.78.252] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: IPFW Date: Mon, 09 Dec 2002 17:18:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Dec 2002 17:18:58.0575 (UTC) FILETIME=[0F5AA9F0:01C29FA7] 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 Dear ALL i run this commands on my 4.4FreeBSD-Release #/sbin/ipfw -f flush #/sbin/ipfw divert 5050 ip from any to any it runs the first command and say no socket found and then when i run the second line it write the words for help and nothing is applied what can i do ? I have a divert socket on port 5050 i want to divert all of the packet to it thanx _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 10:14:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABBEE37B401 for ; Mon, 9 Dec 2002 10:14:49 -0800 (PST) Received: from exch01.megadat.com (exchange.megadat.com [195.22.224.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id E081943EA9 for ; Mon, 9 Dec 2002 10:14:47 -0800 (PST) (envelope-from VGirnet@MEGADAT.COM) Subject: gre patch compiling problem MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2002 20:14:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gre patch compiling problem Thread-Index: AcKfruqOXCP6ihfxSDSaW9jYKUYneQ== From: "Girnet Vladimir" To: 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 updated my system today to 4.7-STABLE. Now, I want to enable WCCP support on my server, but I cannot compile = the kernel with the 'options GRE' All seems to be fine, as described in SQUID FAQ for FreeBSD, and the = email from 27 Oct 2002 to FreeBSD. How I can enable WCCP support on 4.7-STABLE? Thanks. Looking forward to your reply, Vladimir Girnet "MEGADAT.COM" S.R.L. MOLDOVA, Chisinau www.mdl.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 11:54:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F01237B401 for ; Mon, 9 Dec 2002 11:54:18 -0800 (PST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C1643EC5 for ; Mon, 9 Dec 2002 11:54:16 -0800 (PST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gB9Js8F54968; Mon, 9 Dec 2002 20:54:08 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from localhost (pD9E4AEE2.dip.t-dialin.net [217.228.174.226]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gB9JsQHW045192; Mon, 9 Dec 2002 19:54:26 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Date: Mon, 9 Dec 2002 20:51:28 +0100 Subject: Re: IPFW Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: freebsd-net@FreeBSD.ORG To: "soheil soheil" From: Martin Stiemerling In-Reply-To: Message-Id: <9BA04004-0BAF-11D7-B97F-0003936FD19E@ccrle.nec.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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 Am Montag den, 9. Dezember 2002, um 18:18, schrieb soheil soheil: > Dear ALL > i run this commands on my 4.4FreeBSD-Release Do you have this line in your kernel configuration file and compiled into the kernel: options IPFIREWALL see also LINT in /usr/src/sys/i386/conf (if it is an i386) Martin > #/sbin/ipfw -f flush > #/sbin/ipfw divert 5050 ip from any to any > it runs the first command and say no socket found > and then when i run the second line it write the words for help and > nothing is applied > what can i do ? > I have a divert socket on port 5050 i want to divert all of the packet > to it > thanx > > > > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > 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 Dec 9 12:45:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C111037B401 for ; Mon, 9 Dec 2002 12:45:21 -0800 (PST) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F1243EB2 for ; Mon, 9 Dec 2002 12:45:21 -0800 (PST) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (bigv.netvulture.com [192.168.2.2]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id gB9KjAMh012106 for ; Mon, 9 Dec 2002 12:45:10 -0800 (PST) Message-ID: <3DF500F5.8000301@consult-scs.com> Date: Mon, 09 Dec 2002 12:45:41 -0800 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: IPFW References: <9BA04004-0BAF-11D7-B97F-0003936FD19E@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed 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 You will also need options IPDIVERT in your kernel config Martin Stiemerling wrote: > > Am Montag den, 9. Dezember 2002, um 18:18, schrieb soheil soheil: > >> Dear ALL >> i run this commands on my 4.4FreeBSD-Release > > > Do you have this line in your kernel configuration file and compiled > into the kernel: > options IPFIREWALL > > see also LINT in /usr/src/sys/i386/conf (if it is an i386) > > Martin > >> #/sbin/ipfw -f flush >> #/sbin/ipfw divert 5050 ip from any to any >> it runs the first command and say no socket found >> and then when i run the second line it write the words for help and >> nothing is applied >> what can i do ? >> I have a divert socket on port 5050 i want to divert all of the >> packet to it >> thanx >> >> >> >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> >> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 12:48:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44B8C37B401 for ; Mon, 9 Dec 2002 12:48:08 -0800 (PST) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB9543E4A for ; Mon, 9 Dec 2002 12:48:07 -0800 (PST) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (bigv.netvulture.com [192.168.2.2]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id gB9Km8Mh012126 for ; Mon, 9 Dec 2002 12:48:08 -0800 (PST) Message-ID: <3DF501A7.6030103@consult-scs.com> Date: Mon, 09 Dec 2002 12:48:39 -0800 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: IPFW References: <9BA04004-0BAF-11D7-B97F-0003936FD19E@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Also - In your second line for ipfw you have the syntax wrong to divert all ip traffic to divert port 5050 ipfw add 1000 divert 5050 ip from any to any where 1000 is the rule # - you may omit the # if you want it to get a rule # automatically - not recomended when other rules are in use! lower rule #'s get processed before higher's Martin Stiemerling wrote: > > Am Montag den, 9. Dezember 2002, um 18:18, schrieb soheil soheil: > >> Dear ALL >> i run this commands on my 4.4FreeBSD-Release > > > Do you have this line in your kernel configuration file and compiled > into the kernel: > options IPFIREWALL > > see also LINT in /usr/src/sys/i386/conf (if it is an i386) > > Martin > >> #/sbin/ipfw -f flush >> #/sbin/ipfw divert 5050 ip from any to any >> it runs the first command and say no socket found >> and then when i run the second line it write the words for help and >> nothing is applied >> what can i do ? >> I have a divert socket on port 5050 i want to divert all of the >> packet to it >> thanx >> >> >> >> >> >> _________________________________________________________________ >> MSN 8 with e-mail virus protection service: 2 months FREE* >> http://join.msn.com/?page=features/virus >> >> >> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 13:17:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D0E37B401 for ; Mon, 9 Dec 2002 13:17:16 -0800 (PST) Received: from mx1.purplecat.net (mx1.purplecat.net [208.133.44.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EEE943EE5 for ; Mon, 9 Dec 2002 13:17:12 -0800 (PST) (envelope-from peter@skyrunner.net) Received: (qmail 65086 invoked from network); 9 Dec 2002 21:17:28 -0000 Received: from unknown (HELO micron) (208.150.25.130) by mx1.skyrunner.net with SMTP; 9 Dec 2002 21:17:28 -0000 From: "Peter Brezny" To: Subject: passive mode ftp server, need stateful ipfw rule. Date: Mon, 9 Dec 2002 16:16:40 -0500 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Is it possible to create an ipfw ruleset for an ftp server in passive mode that figures out which random port the ftp server is going to open to only allow the client that initiated the connection to connect to that port? Since the client initiates it's data connection from a random port to the new random data port on the passive mode server, i've so far not been able to come up with decent firewall rules to protect this type of system. TIA, Peter Brezny Skyrunner.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 13:42:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48E2437B401 for ; Mon, 9 Dec 2002 13:42:43 -0800 (PST) Received: from mx1.purplecat.net (mx1.purplecat.net [208.133.44.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id A602B43EC2 for ; Mon, 9 Dec 2002 13:42:42 -0800 (PST) (envelope-from peter@skyrunner.net) Received: (qmail 72274 invoked from network); 9 Dec 2002 21:42:59 -0000 Received: from unknown (HELO micron) (208.150.25.130) by mx1.skyrunner.net with SMTP; 9 Dec 2002 21:42:59 -0000 From: "Peter Brezny" To: "Orville R. Weyrich_Jr" Cc: Subject: RE: passive mode ftp server, need stateful ipfw rule. Date: Mon, 9 Dec 2002 16:42:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20021209145439.L45560-100000@localhost> 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 Yes but then you run into: DYNAMIC RULES In order to protect a site from flood attacks involving fake TCP packets, it is safer to use dynamic rules: ipfw add check-state ipfw add deny tcp from any to any established And also, if you've got an: add allow all from any to any established arn't you sort of setting yourself up. Couldn't someone establish a valid connection to a valid port, then, have a field day? TIA Peter Brezny Skyrunner.net -----Original Message----- From: Orville R. Weyrich_Jr [mailto:orville@ameriroots.com] Sent: Monday, December 09, 2002 4:55 PM To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: passive mode ftp server, need stateful ipfw rule. Isn't that what ESTABLISHED is used for? On Mon, 9 Dec 2002, Peter Brezny wrote: > Is it possible to create an ipfw ruleset for an ftp server in passive mode > that figures out which random port the ftp server is going to open to only > allow the client that initiated the connection to connect to that port? > > > Since the client initiates it's data connection from a random port to the > new random data port on the passive mode server, i've so far not been able > to come up with decent firewall rules to protect this type of system. > > TIA, > > > Peter Brezny > Skyrunner.net > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ---------------------------------------------------------------------------- --- Orville R. Weyrich, Jr PhD. KD7HJV mailto:orville@weyrich.com ---------------------------------------------------------------------------- --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 15:12:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00F7537B404 for ; Mon, 9 Dec 2002 15:12:24 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE9B43EA9 for ; Mon, 9 Dec 2002 15:12:23 -0800 (PST) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB9NCNI21444 for ; Mon, 9 Dec 2002 15:12:23 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 9 Dec 2002 15:11:59 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gB9NCMs09651 for ; Mon, 9 Dec 2002 15:12:22 -0800 (PST) Date: Mon, 9 Dec 2002 15:12:22 -0800 Subject: Re: broadcast over loopback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <20021206185424.P19254-100000@lethargic.dyndns.org> Message-Id: X-Mailer: Apple Mail (2.548) 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 Friday, December 6, 2002, at 04:15 PM, Jason Hunt wrote: >> Other platforms out there will handle broadcast on the loopback >> interface. Is it desirable to make changes to the FreeBSD stack to get >> this behavior? > > Any examples? I cannot think of a practical case where this would be > required. I would think that an application will know if it sent a > broadcast or not, so it shouldn't have to receive that broadcast > itself. > Anyone disagree? If someone is using broadcast for a service discovery protocol instead of multicast, they would want services, whether running locally or remotely, to receive that broadcast. If loopback is the only interface, it might still be desirable to find services running on the local machine. -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 16:57:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 413BA37B401 for ; Mon, 9 Dec 2002 16:57:11 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8502F43EA9 for ; Mon, 9 Dec 2002 16:57:09 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gBA0uuMG062136; Mon, 9 Dec 2002 19:56:56 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gBA0uuTn062135; Mon, 9 Dec 2002 19:56:56 -0500 (EST) (envelope-from barney) Date: Mon, 9 Dec 2002 19:56:56 -0500 From: Barney Wolff To: Peter Brezny Cc: "Orville R. Weyrich_Jr" , freebsd-net@FreeBSD.ORG Subject: Re: passive mode ftp server, need stateful ipfw rule. Message-ID: <20021210005656.GA62054@tp.databus.com> References: <20021209145439.L45560-100000@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) 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 Guys, you're both missing the point. Any flavor of ftp makes the data connection separate from the control connection, so something must permit the SYN of the data connection to pass. natd is able to do this for clients using active-mode ftp, but I don't think it can do it for a server with a passive-mode client. One pragmatic solution is to adjust the range of random tcp ports chosen to a fairly narrow one, and then allow the setup from any to that port range. The real answer is to get rid of ftp, and use something better. For replacing anonymous ftp, http works just as well. scp, sftp or https with passwords will do fine for restricting users and ensuring file integrity. On Mon, Dec 09, 2002 at 04:42:11PM -0500, Peter Brezny wrote: > Yes but then you run into: > DYNAMIC RULES > In order to protect a site from flood attacks involving fake TCP > packets, > it is safer to use dynamic rules: > > ipfw add check-state > ipfw add deny tcp from any to any established > > And also, if you've got an: > add allow all from any to any established > > arn't you sort of setting yourself up. Couldn't someone establish a valid > connection to a valid port, then, have a field day? > > TIA > > Peter Brezny > Skyrunner.net > > > -----Original Message----- > From: Orville R. Weyrich_Jr [mailto:orville@ameriroots.com] > Sent: Monday, December 09, 2002 4:55 PM > To: Peter Brezny > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: passive mode ftp server, need stateful ipfw rule. > > > Isn't that what ESTABLISHED is used for? > > On Mon, 9 Dec 2002, Peter Brezny wrote: > > > Is it possible to create an ipfw ruleset for an ftp server in passive mode > > that figures out which random port the ftp server is going to open to only > > allow the client that initiated the connection to connect to that port? > > > > > > Since the client initiates it's data connection from a random port to the > > new random data port on the passive mode server, i've so far not been able > > to come up with decent firewall rules to protect this type of system. > > > > TIA, > > > > > > Peter Brezny > > Skyrunner.net > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > ---------------------------------------------------------------------------- > --- > Orville R. Weyrich, Jr PhD. KD7HJV > mailto:orville@weyrich.com > ---------------------------------------------------------------------------- > --- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 9 17: 5:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C8D637B401 for ; Mon, 9 Dec 2002 17:05:12 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F2743E4A for ; Mon, 9 Dec 2002 17:05:10 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2002121001050900300cq542e>; Tue, 10 Dec 2002 01:05:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA75183; Mon, 9 Dec 2002 17:01:29 -0800 (PST) Date: Mon, 9 Dec 2002 17:01:27 -0800 (PST) From: Julian Elischer To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: IPFW 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 Mon, 9 Dec 2002, soheil soheil wrote: > Dear ALL > i run this commands on my 4.4FreeBSD-Release > #/sbin/ipfw -f flush > #/sbin/ipfw divert 5050 ip from any to any /sbin/ipfw add divert 5050 ip from any to any ^^^ > it runs the first command and say no socket found > and then when i run the second line it write the words for help and nothing > is applied > what can i do ? > I have a divert socket on port 5050 i want to divert all of the packet to it > thanx > > > > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > 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 Dec 9 23:34: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F201537B40A for ; Mon, 9 Dec 2002 23:33:58 -0800 (PST) Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E17F543E4A for ; Mon, 9 Dec 2002 23:33:57 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto6.wanadoo.fr (6.7.010) id 3DEF2002002F066C; Tue, 10 Dec 2002 08:33:12 +0100 Received: from mercure.vincentjardin.net (80.13.229.130) by mel-rta7.wanadoo.fr (6.7.010) id 3DEDFF89002EBA26; Tue, 10 Dec 2002 08:33:12 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Barney Wolff , Peter Brezny Subject: Re: passive mode ftp server, need stateful ipfw rule. Date: Tue, 10 Dec 2002 08:31:45 +0000 User-Agent: KMail/1.4.3 Cc: "Orville R. Weyrich_Jr" , freebsd-net@FreeBSD.ORG References: <20021209145439.L45560-100000@localhost> <20021210005656.GA62054@tp.databus.com> In-Reply-To: <20021210005656.GA62054@tp.databus.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200212100831.45848.vjardin@wanadoo.fr> 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 > > One pragmatic solution is to adjust the range of random tcp ports > chosen to a fairly narrow one, and then allow the setup from any to > that port range. > > The real answer is to get rid of ftp, and use something better. For > replacing anonymous ftp, http works just as well. scp, sftp or https > with passwords will do fine for restricting users and ensuring file > integrity. Another solution is a daemon that could track the control planes of some=20 specific applicatoins on a divert socket such as ftp, h323, ... then that= add=20 a dynamic rule about the new TCP/UDP sessions. It is like natd however=20 without the NAT features. The performace would remain good because this daemon would work only on t= he=20 control plane. The data plane would remain within the kernel and if they= =20 match the "dynamic" firewall rules, they are just forwarded or dropped by= the=20 kernel. It would be session tracking firewall ;-) Vincent > > On Mon, Dec 09, 2002 at 04:42:11PM -0500, Peter Brezny wrote: > > Yes but then you run into: > > DYNAMIC RULES > > In order to protect a site from flood attacks involving fake TCP > > packets, > > it is safer to use dynamic rules: > > > > ipfw add check-state > > ipfw add deny tcp from any to any established > > > > And also, if you've got an: > > add allow all from any to any established > > > > arn't you sort of setting yourself up. Couldn't someone establish a > > valid connection to a valid port, then, have a field day? > > > > TIA > > > > Peter Brezny > > Skyrunner.net > > > > > > -----Original Message----- > > From: Orville R. Weyrich_Jr [mailto:orville@ameriroots.com] > > Sent: Monday, December 09, 2002 4:55 PM > > To: Peter Brezny > > Cc: freebsd-net@FreeBSD.ORG > > Subject: Re: passive mode ftp server, need stateful ipfw rule. > > > > > > Isn't that what ESTABLISHED is used for? > > > > On Mon, 9 Dec 2002, Peter Brezny wrote: > > > Is it possible to create an ipfw ruleset for an ftp server in passi= ve > > > mode that figures out which random port the ftp server is going to = open > > > to only allow the client that initiated the connection to connect t= o > > > that port? > > > > > > > > > Since the client initiates it's data connection from a random port = to > > > the new random data port on the passive mode server, i've so far no= t > > > been able to come up with decent firewall rules to protect this typ= e of > > > system. > > > > > > TIA, > > > > > > > > > Peter Brezny > > > Skyrunner.net > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > ---------------------------------------------------------------------= ---- > >--- --- > > Orville R. Weyrich, Jr PhD. KD7HJV > > mailto:orville@weyrich.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 Tue Dec 10 3:22:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9109737B401; Tue, 10 Dec 2002 03:22:57 -0800 (PST) Received: from sdf.lonestar.org (sdf.lonestar.org [207.202.214.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0894443E4A; Tue, 10 Dec 2002 03:22:57 -0800 (PST) (envelope-from omestre@sdf.lonestar.org) Received: by sdf.lonestar.org (8.11.6+3.4W/8.11.6) id gBABMpJ04041; Tue, 10 Dec 2002 11:22:51 GMT Date: Tue, 10 Dec 2002 11:22:51 +0000 (UTC) From: omestre To: freebsd-hackers@freebsd.org, Subject: bootp_subr.c hacked! 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 Hi Somedays ago i wrote to this list about my patch to bootp_subr.c Some users said to me about error in the link... sorry, here is the working link: http://oslo.procergs.com.br/tor/leal/FreeBSD/bootp_subr.c sorry by the english. omestre@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 10 10:40:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0835A37B401 for ; Tue, 10 Dec 2002 10:40:45 -0800 (PST) Received: from mx1.purplecat.net (mx1.purplecat.net [208.133.44.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2619143E4A for ; Tue, 10 Dec 2002 10:40:44 -0800 (PST) (envelope-from peter@skyrunner.net) Received: (qmail 87726 invoked from network); 10 Dec 2002 18:40:56 -0000 Received: from unknown (HELO micron) (208.150.25.130) by mx1.skyrunner.net with SMTP; 10 Dec 2002 18:40:56 -0000 From: "Peter Brezny" To: "Vincent Jardin" , "Barney Wolff" Cc: "Orville R. Weyrich_Jr" , Subject: RE: passive mode ftp server, need stateful ipfw rule. Date: Tue, 10 Dec 2002 13:40:43 -0500 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200212100831.45848.vjardin@wanadoo.fr> 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 like the pragmatic solution idea, How do you adjust the range of random tcp ports chosen if you are using the stoc ftpd that comes with freebsd. Of course I'd like to be able to move to sftp or scp or https, but as an isp with web hosting, the support overhead for all the designers to learn how to do it would be a bit overwhelming. What about the -punch_fw option in natd? Has anyone used that before? from man natd: -punch_fw basenumber:count This option directs natd to ``punch holes'' in an ipfirewall(4) based firewall for FTP/IRC DCC connections. This is done dynamically by installing temporary firewall rules which allow a particular connection (and only that con- nection) to go through the firewall. The rules are removed once the corresponding connection terminates. Thanks again. Peter Brezny Skyrunner.net -----Original Message----- From: Vincent Jardin [mailto:vjardin@wanadoo.fr] Sent: Tuesday, December 10, 2002 3:32 AM To: Barney Wolff; Peter Brezny Cc: Orville R. Weyrich_Jr; freebsd-net@FreeBSD.ORG Subject: Re: passive mode ftp server, need stateful ipfw rule. > > One pragmatic solution is to adjust the range of random tcp ports > chosen to a fairly narrow one, and then allow the setup from any to > that port range. > > The real answer is to get rid of ftp, and use something better. For > replacing anonymous ftp, http works just as well. scp, sftp or https > with passwords will do fine for restricting users and ensuring file > integrity. Another solution is a daemon that could track the control planes of some specific applicatoins on a divert socket such as ftp, h323, ... then that add a dynamic rule about the new TCP/UDP sessions. It is like natd however without the NAT features. The performace would remain good because this daemon would work only on the control plane. The data plane would remain within the kernel and if they match the "dynamic" firewall rules, they are just forwarded or dropped by the kernel. It would be session tracking firewall ;-) Vincent > > On Mon, Dec 09, 2002 at 04:42:11PM -0500, Peter Brezny wrote: > > Yes but then you run into: > > DYNAMIC RULES > > In order to protect a site from flood attacks involving fake TCP > > packets, > > it is safer to use dynamic rules: > > > > ipfw add check-state > > ipfw add deny tcp from any to any established > > > > And also, if you've got an: > > add allow all from any to any established > > > > arn't you sort of setting yourself up. Couldn't someone establish a > > valid connection to a valid port, then, have a field day? > > > > TIA > > > > Peter Brezny > > Skyrunner.net > > > > > > -----Original Message----- > > From: Orville R. Weyrich_Jr [mailto:orville@ameriroots.com] > > Sent: Monday, December 09, 2002 4:55 PM > > To: Peter Brezny > > Cc: freebsd-net@FreeBSD.ORG > > Subject: Re: passive mode ftp server, need stateful ipfw rule. > > > > > > Isn't that what ESTABLISHED is used for? > > > > On Mon, 9 Dec 2002, Peter Brezny wrote: > > > Is it possible to create an ipfw ruleset for an ftp server in passive > > > mode that figures out which random port the ftp server is going to open > > > to only allow the client that initiated the connection to connect to > > > that port? > > > > > > > > > Since the client initiates it's data connection from a random port to > > > the new random data port on the passive mode server, i've so far not > > > been able to come up with decent firewall rules to protect this type of > > > system. > > > > > > TIA, > > > > > > > > > Peter Brezny > > > Skyrunner.net > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > ------------------------------------------------------------------------- > >--- --- > > Orville R. Weyrich, Jr PhD. KD7HJV > > mailto:orville@weyrich.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 Tue Dec 10 11:29:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E8737B401 for ; Tue, 10 Dec 2002 11:29:49 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5436843EB2 for ; Tue, 10 Dec 2002 11:29:47 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gBAJTcMG068765; Tue, 10 Dec 2002 14:29:38 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gBAJTcut068764; Tue, 10 Dec 2002 14:29:38 -0500 (EST) (envelope-from barney) Date: Tue, 10 Dec 2002 14:29:38 -0500 From: Barney Wolff To: Peter Brezny Cc: Vincent Jardin , Barney Wolff , "Orville R. Weyrich_Jr" , freebsd-net@FreeBSD.ORG Subject: Re: passive mode ftp server, need stateful ipfw rule. Message-ID: <20021210192938.GA68635@tp.databus.com> References: <200212100831.45848.vjardin@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) 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, Dec 10, 2002 at 01:40:43PM -0500, Peter Brezny wrote: > How do you adjust the range of random tcp ports chosen if you are using the > stoc ftpd that comes with freebsd. sysctl net.inet.ip.portrange.hifirst and .hilast, set by default to 49152 and 65535. The ftpd manpage is slightly misleading here, as it states the defaults without noting that they can be modified. UTSL shows that ftpd binds to port 0 for PASV, thus leaving the choice up to the kernel. > Of course I'd like to be able to move to sftp or scp or https, but as an isp > with web hosting, the support overhead for all the designers to learn how to > do it would be a bit overwhelming. > > What about the -punch_fw option in natd? Has anyone used that before? I believe that only works on the client side, but I'd be happy to be shown to be in error. One could hack up the natd source to do the job, as all the pieces necessary are in there. But beware - a server must cope with tricks such as asking for a nonexistent file that looks like the response to a PASV command, and so on. Firewall vendors sometimes actually do earn their money. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 10 18:30:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0734437B401 for ; Tue, 10 Dec 2002 18:30:30 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44BA443EC2 for ; Tue, 10 Dec 2002 18:30:29 -0800 (PST) (envelope-from cswiger@mac.com) Received: from prime ([12.88.91.118]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021211023027.FCBG9286.mtiwmhc11.worldnet.att.net@prime>; Wed, 11 Dec 2002 02:30:27 +0000 Message-ID: <00cc01c2a0bd$43e465a0$0301a8c0@prime> From: "Charles Swiger" To: "Joshua Graessley" , References: Subject: Re: broadcast over loopback Date: Tue, 10 Dec 2002 21:30:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Joshua Graessley wrote: [ ... ] > If someone is using broadcast for a service discovery protocol instead > of multicast, they would want services, whether running locally or > remotely, to receive that broadcast. Sure, since the thing doing service discovery may not be the same as the thing (or things) advertising services. > If loopback is the only interface, it might still be desirable to find > services running on the local machine. Besides, giving the loopback special case behavior when it's not needed doesn't strike me as a good idea. Presumably one would want to remove the second test: /* * Multicasts with a time-to-live of zero may be looped- * back, above, but must not be transmitted on a network. * Also, multicasts addressed to the loopback interface * are not sent -- the above call to ip_mloopback() will * loop back a copy if this host actually belongs to the * destination group on the loopback interface. */ if (ip->ip_ttl == 0 || ifp->if_flags & IFF_LOOPBACK) { m_freem(m); goto done; } ...around line 380 of /usr/src/sys/netinet/ip_output.c, and rebuild the kernel to test your suggested change out. -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 7:21:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EFFF37B401 for ; Wed, 11 Dec 2002 07:21:21 -0800 (PST) Received: from myra.cc.metu.edu.tr (myra.cc.metu.edu.tr [144.122.199.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D3D343EDC for ; Wed, 11 Dec 2002 07:21:18 -0800 (PST) (envelope-from eryol@metu.edu.tr) Received: from metu.edu.tr (myra-atm [144.122.156.93]) by myra.cc.metu.edu.tr (8.11.6/8.11.6) with ESMTP id gBBFLJO27181; Wed, 11 Dec 2002 17:21:19 +0200 (EET) Message-Id: <200212111521.gBBFLJO27181@myra.cc.metu.edu.tr> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 User-Agent: IMHO/0.98.3 (Webmail for Roxen) Subject: freebsd 4.7-stable kernel gre tunnel support for squid's wccp cisco interaction X-Originating-IP: [144.122.202.32] From: Gokhan Eryol To: freebsd-net@freebsd.org Date: Wed, 11 Dec 2002 17:21:18 +0200 MIME-Version: 1.0 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 upgraded /usr/src from 4.7-RELEASE to 4.7-STABLE by cvs and trying to compile it for transparent web-caching with squid (wccp support). I tried the steps described in http://www.squid-cache.org/Doc/FAQ/FAQ-17.html as i did before. I knew from older experiences that the gre.patch given here was wrong in last part (cause of removed "__P(...)" stuffs in the file ip_var.h) so you had to do the changes manually. However, by the date 20-Nov-2002, new patch released at http://www.squid-cache.org/WCCP-support/FreeBSD-4.x/4.7-gre.patch . Unfortunately, even this patch's last part designed for 4.7 - ip_var.h format, again fails for 4.7-STABLE, so you have to do the last part manually again (line 185 at /usr/src/sys/netinet/ip_var.h changed from "void ipip_input(struct mbuf *, int, int);" to "extern void (*ipip_input)(struct mbuf *, int, int);" ). Real problems starts here. Firstly, when you do the gre patches for wccp support, and try the compile the kernel with "option GRE", following error appears: In file included from /usr/src/sys/net/if_gre.c:77: /usr/src/sys/netinet/ip_var.h:184: conflicting types for `gre_input' /usr/src/sys/netinet/ip_gre.h:41: previous declaration of `gre_input' /usr/src/sys/netinet/ip_var.h:184: warning: redundant redeclaration of `gre_input' in same scope /usr/src/sys/netinet/ip_gre.h:41: warning: previous declaration of `gre_input' /usr/src/sys/net/if_gre.c:120: warning: initialization from incompatible pointer type /usr/src/sys/net/if_gre.c:120: warning: initialization from incompatible pointer type /usr/src/sys/net/if_gre.c:127: warning: initialization from incompatible pointer type /usr/src/sys/net/if_gre.c:127: warning: initialization from incompatible pointer type *** Error code 1 Stop in /usr/obj/usr/src/sys/BIGMETUCACHE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I realized the file /usr/src/sys/netinet/ip_gre.h with the line "void gre_input(struct mbuf *, ...);" but the patch defined it as "void gre_input(struct mbuf *, int, int);" ip ip_var.h file. The file is changed at 1.Dec.2002 . I tried some other things but didn't work. How can i enable wccp support on FreeBSD-4.7-STABLE updated today? I would appreciate any suggestions. Thanks, Gokhan ERYOL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 9:48:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C604F37B401 for ; Wed, 11 Dec 2002 09:48:12 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4395143E4A for ; Wed, 11 Dec 2002 09:48:11 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.12.6/8.12.6/hmo29jun02) with ESMTP id gBBHm0cg051593 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Dec 2002 18:48:03 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gBBHlxYY051592; Wed, 11 Dec 2002 18:47:59 +0100 (CET) (envelope-from hmo) Message-Id: <200212111747.gBBHlxYY051592@sep.oldach.net> Subject: Re: freebsd 4.7-stable kernel gre tunnel support for squid's wccp cisco interaction In-Reply-To: <200212111521.gBBFLJO27181@myra.cc.metu.edu.tr> from Gokhan Eryol at "Dec 11, 2002 5:21:18 pm" To: eryol@metu.edu.tr (Gokhan Eryol) Date: Wed, 11 Dec 2002 18:47:59 +0100 (CET) Cc: freebsd-net@FreeBSD.ORG From: Helge Oldach 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 Gokhan Eryol: > I upgraded /usr/src from 4.7-RELEASE to 4.7-STABLE by cvs and trying > to compile it for transparent web-caching with squid (wccp support). I > tried the steps described in > http://www.squid-cache.org/Doc/FAQ/FAQ-17.html as i did before. I believe this should be mostly obsolete. GRE has been incorporated into STABLE on 1st December, so you shouldn't need to patch anything any more. Probably you will just have to configure a gre interface and make squid talk to that. > /usr/src/sys/netinet/ip_var.h:184: conflicting types for `gre_input' > /usr/src/sys/netinet/ip_gre.h:41: previous declaration of `gre_input' > /usr/src/sys/netinet/ip_var.h:184: warning: redundant redeclaration of > `gre_input' in same scope > /usr/src/sys/netinet/ip_gre.h:41: warning: previous declaration of > `gre_input' Yep, this sounds like the patch has already garbled your ip_var.h and ip_gre.h files and has thrown in superfluous declarations. Regards, Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 10:35:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A3737B401; Wed, 11 Dec 2002 10:35:08 -0800 (PST) Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id D60C743ED1; Wed, 11 Dec 2002 10:35:07 -0800 (PST) (envelope-from le@cs.unc.edu) Received: from le-cs.cs.unc.edu (IDENT:le@le-cs.cs.unc.edu [152.2.131.150]) by wren.cs.unc.edu (8.12.5/8.12.5) with ESMTP id gBBIZ1hj011916; Wed, 11 Dec 2002 13:35:02 -0500 (EST) Date: Wed, 11 Dec 2002 13:35:01 -0500 (EST) From: Long Le To: , Subject: Broadcom NetXtreme 5703 NIC Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="43554435-1369830500-1039631701=:886" 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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --43554435-1369830500-1039631701=:886 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, We installed FreeBSD 4.7 on an IBM eServer machine with an on-board copper Broadcom BCM5703X and put two more fiber Broadcom BCM5703X NICs into the machine. We used cvs to get the latest update on the stable branch yesterday. However, only the copper NIC and one fiber NIC come up. The log message says "bge2: MII without any PHY!" for the second fiber NIC. Does anyone have any suggestion for us? The dmesg is in attachment of this mail. Please kindly copy your reply to my email address because I'm not on the list. Thanks, -- long --43554435-1369830500-1039631701=:886 Content-Type: TEXT/plain; name="dmesg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg.txt" RGVjICA5IDEzOjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBDb3B5cmlnaHQg KGMpIDE5OTItMjAwMiBUaGUgRnJlZUJTRCBQcm9qZWN0Lg0KRGVjICA5IDEz OjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5Nzks IDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5 OTMsIDE5OTQNCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNzb3IgL2tlcm5lbDog VGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4g QWxsIHJpZ2h0cyByZXNlcnZlZC4NCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNz b3IgL2tlcm5lbDogRnJlZUJTRCA0LjctU1RBQkxFICMxOiBNb24gRGVjICA5 IDEyOjEzOjQzIEVTVCAyMDAyDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29y IC9rZXJuZWw6IHJvb3RAZ29sZGJlcmcuY3MudW5jLmVkdTovdXNyL3NyYy9z eXMvY29tcGlsZS9ESVJUDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29yIC9r ZXJuZWw6IFRpbWVjb3VudGVyICJpODI1NCIgIGZyZXF1ZW5jeSAxMTkzMTgy IEh6DQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29yIC9rZXJuZWw6IENQVTog UGVudGl1bSA0ICgxNzk2LjA4LU1IeiA2ODYtY2xhc3MgQ1BVKQ0KRGVjICA5 IDEzOjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBPcmlnaW4gPSAiR2VudWlu ZUludGVsIiAgSWQgPSAweGYyNCAgU3RlcHBpbmcgPSA0DQpEZWMgIDkgMTM6 MzE6NTIgcHJvZmVzc29yIC9rZXJuZWw6IEZlYXR1cmVzPTB4M2ZlYmZiZmY8 RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxN VFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxN TVgsRlhTUixTU0UsU1NFMixTUyw8YjI4PixBQ0M+DQpEZWMgIDkgMTM6MzE6 NTIgcHJvZmVzc29yIC9rZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDEzNDIxNDQ1 MTIgKDEzMTA2ODhLIGJ5dGVzKQ0KRGVjICA5IDEzOjMxOjUyIHByb2Zlc3Nv ciAva2VybmVsOiBhdmFpbCBtZW1vcnkgPSAxMjk5ODI4NzM2ICgxMjY5MzY0 SyBieXRlcykNCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNzb3IgL2tlcm5lbDog UHJlbG9hZGVkIGVsZiBrZXJuZWwgImtlcm5lbCIgYXQgMHhjMDUxZjAwMC4N CkRlYyAgOSAxMzozMTo1MiBwcm9mZXNzb3IgL2tlcm5lbDogUGVudGl1bSBQ cm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQNCkRlYyAgOSAxMzozMTo1MiBwcm9m ZXNzb3IgL2tlcm5lbDogbWQwOiBNYWxsb2MgZGlzaw0KRGVjICA5IDEzOjMx OjUyIHByb2Zlc3NvciAva2VybmVsOiBucHgwOiA8bWF0aCBwcm9jZXNzb3I+ IG9uIG1vdGhlcmJvYXJkDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29yIC9r ZXJuZWw6IG5weDA6IElOVCAxNiBpbnRlcmZhY2UNCkRlYyAgOSAxMzozMTo1 MiBwcm9mZXNzb3IgL2tlcm5lbDogcGNpYjA6IDxIb3N0IHRvIFBDSSBicmlk Z2U+IG9uIG1vdGhlcmJvYXJkDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29y IC9rZXJuZWw6IHBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMA0KRGVjICA5IDEz OjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBwY2kwOiA8QVRJIE1hY2g2NC1H UiBncmFwaGljcyBhY2NlbGVyYXRvcj4gYXQgOS4wIGlycSAxMA0KRGVjICA5 IDEzOjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBhdGFwY2kwOiA8U2VydmVy V29ya3MgQ1NCNSBBVEExMDAgY29udHJvbGxlcj4gcG9ydCAweDcwMC0weDcw ZiwweDM3NC0weDM3NywweDE3MC0weDE3NywweDNmNC0weDNmNywweDFmMC0w eDFmNyBhdCBkZXZpY2UgMTUuMSBvbiBwY2kwDQpEZWMgIDkgMTM6MzE6NTIg cHJvZmVzc29yIC9rZXJuZWw6IGF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBh dGFwY2kwDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29yIC9rZXJuZWw6IGF0 YTE6IGF0IDB4MTcwIGlycSAxNSBvbiBhdGFwY2kwDQpEZWMgIDkgMTM6MzE6 NTIgcHJvZmVzc29yIC9rZXJuZWw6IG9oY2kwOiA8T0hDSSAoZ2VuZXJpYykg VVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlYmZlMDAwLTB4ZmViZmVmZmYgaXJx IDExIGF0IGRldmljZSAxNS4yIG9uIHBjaTANCkRlYyAgOSAxMzozMTo1MiBw cm9mZXNzb3IgL2tlcm5lbDogdXNiMDogT0hDSSB2ZXJzaW9uIDEuMCwgbGVn YWN5IHN1cHBvcnQNCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNzb3IgL2tlcm5l bDogdXNiMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBv aGNpMA0KRGVjICA5IDEzOjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiB1c2Iw OiBVU0IgcmV2aXNpb24gMS4wDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29y IC9rZXJuZWw6IHVodWIwOiAoMHgxMTY2KSBPSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQ0KRGVjICA5IDEzOjMxOjUy IHByb2Zlc3NvciAva2VybmVsOiB1aHViMDogNCBwb3J0cyB3aXRoIDQgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNz b3IgL2tlcm5lbDogaXNhYjA6IDxQQ0kgdG8gSVNBIGJyaWRnZSAodmVuZG9y PTExNjYgZGV2aWNlPTAyMjUpPiBhdCBkZXZpY2UgMTUuMyBvbiBwY2kwDQpE ZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29yIC9rZXJuZWw6IGlzYTA6IDxJU0Eg YnVzPiBvbiBpc2FiMA0KRGVjICA5IDEzOjMxOjUyIHByb2Zlc3NvciAva2Vy bmVsOiBwY2liMTogPEhvc3QgdG8gUENJIGJyaWRnZT4gb24gbW90aGVyYm9h cmQNCkRlYyAgOSAxMzozMTo1MiBwcm9mZXNzb3IgL2tlcm5lbDogcGNpMTog PFBDSSBidXM+IG9uIHBjaWIxDQpEZWMgIDkgMTM6MzE6NTIgcHJvZmVzc29y IC9rZXJuZWw6IHBjaWIyOiA8SG9zdCB0byBQQ0kgYnJpZGdlPiBvbiBtb3Ro ZXJib2FyZA0KRGVjICA5IDEzOjMxOjUyIHByb2Zlc3NvciAva2VybmVsOiBw Y2kyOiA8UENJIGJ1cz4gb24gcGNpYjINCkRlYyAgOSAxMzozMTo1MiBwcm9m ZXNzb3IgL2tlcm5lbDogYmdlMDogPEJyb2FkY29tIEJDTTU3MDNYIEdpZ2Fi aXQgRXRoZXJuZXQ+IG1lbSAweGZiZmYwMDAwLTB4ZmJmZmZmZmYgaXJxIDEw IGF0IGRldmljZSA4LjAgb24gcGNpMg0KRGVjICA5IDEzOjMxOjUyIHByb2Zl c3NvciAva2VybmVsOiBiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowMjo1 NTowNzo1MTo0Zg0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVs OiBtaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMA0KRGVjICA5IDEzOjMxOjUz IHByb2Zlc3NvciAva2VybmVsOiB1a3BoeTA6IDxHZW5lcmljIElFRUUgODAy LjN1IG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMA0KRGVjICA5IDEzOjMx OjUzIHByb2Zlc3NvciAva2VybmVsOiB1a3BoeTA6ICAxMGJhc2VULCAxMGJh c2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQpEZWMg IDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBjaWIzOiA8SG9zdCB0 byBQQ0kgYnJpZGdlPiBvbiBtb3RoZXJib2FyZA0KRGVjICA5IDEzOjMxOjUz IHByb2Zlc3NvciAva2VybmVsOiBwY2kzOiA8UENJIGJ1cz4gb24gcGNpYjMN CkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogcGNpYjQ6IDxT ZXJ2ZXJXb3JrcyBob3N0IHRvIFBDSSBicmlkZ2UodW5rbm93biBjaGlwc2V0 KT4gb24gbW90aGVyYm9hcmQNCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3Ig L2tlcm5lbDogcGNpNDogPFBDSSBidXM+IG9uIHBjaWI0DQpEZWMgIDkgMTM6 MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBjaWI1OiA8U2VydmVyV29ya3Mg aG9zdCB0byBQQ0kgYnJpZGdlKHVua25vd24gY2hpcHNldCk+IG9uIG1vdGhl cmJvYXJkDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBj aTU6IDxQQ0kgYnVzPiBvbiBwY2liNQ0KRGVjICA5IDEzOjMxOjUzIHByb2Zl c3NvciAva2VybmVsOiBtcHQwOiA8TFNJTG9naWMgMTAzMCBVbHRyYTQgQWRh cHRlcj4gcG9ydCAweDIzMDAtMHgyM2ZmIG1lbSAweGY5ZmUwMDAwLTB4Zjlm ZWZmZmYsMHhmOWZmMDAwMC0weGY5ZmZmZmZmIGlycSA5IGF0IGRldmljZSA3 LjAgb24gcGNpNQ0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVs OiBtcHQxOiA8TFNJTG9naWMgMTAzMCBVbHRyYTQgQWRhcHRlcj4gcG9ydCAw eDI0MDAtMHgyNGZmIG1lbSAweGY5ZmMwMDAwLTB4ZjlmY2ZmZmYsMHhmOWZk MDAwMC0weGY5ZmRmZmZmIGlycSA5IGF0IGRldmljZSA3LjEgb24gcGNpNQ0K RGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBwY2liNzogPFNl cnZlcldvcmtzIGhvc3QgdG8gUENJIGJyaWRnZSh1bmtub3duIGNoaXBzZXQp PiBvbiBtb3RoZXJib2FyZA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAv a2VybmVsOiBwY2k3OiA8UENJIGJ1cz4gb24gcGNpYjcNCkRlYyAgOSAxMzoz MTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogYmdlMTogPEJyb2FkY29tIEJDTTU3 MDNYIEdpZ2FiaXQgRXRoZXJuZXQ+IG1lbSAweGY3ZmYwMDAwLTB4ZjdmZmZm ZmYgaXJxIDExIGF0IGRldmljZSA1LjAgb24gcGNpNw0KRGVjICA5IDEzOjMx OjUzIHByb2Zlc3NvciAva2VybmVsOiBiZ2UxOiBFdGhlcm5ldCBhZGRyZXNz OiAwMDoxMDoxODowMDo0ODo2Zg0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3Nv ciAva2VybmVsOiBtaWlidXMxOiA8TUlJIGJ1cz4gb24gYmdlMQ0KRGVjICA5 IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiB1a3BoeTE6IDxHZW5lcmlj IElFRUUgODAyLjN1IG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMQ0KRGVj ICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiB1a3BoeTE6ICBubyBt ZWRpYSBwcmVzZW50DQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJu ZWw6IHBjaWI5OiA8U2VydmVyV29ya3MgaG9zdCB0byBQQ0kgYnJpZGdlKHVu a25vd24gY2hpcHNldCk+IG9uIG1vdGhlcmJvYXJkDQpEZWMgIDkgMTM6MzE6 NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBjaTk6IDxQQ0kgYnVzPiBvbiBwY2li OQ0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBiZ2UyOiA8 QnJvYWRjb20gQkNNNTcwM1ggR2lnYWJpdCBFdGhlcm5ldD4gbWVtIDB4ZjUz ZjAwMDAtMHhmNTNmZmZmZiBpcnEgMyBhdCBkZXZpY2UgNi4wIG9uIHBjaTkN CkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogYmdlMjogRXRo ZXJuZXQgYWRkcmVzczogMDA6MTA6MTg6MDA6NDg6OWENCkRlYyAgOSAxMzoz MTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogYmdlMjogTUlJIHdpdGhvdXQgYW55 IFBIWSENCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGV2 aWNlX3Byb2JlX2FuZF9hdHRhY2g6IGJnZTIgYXR0YWNoIHJldHVybmVkIDYN CkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogb3JtMDogPE9w dGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjODAwMC0w eGNiZmZmLDB4Y2MwMDAtMHhjZDdmZiwweGNkODAwLTB4Y2VmZmYsMHhjZjAw MC0weGQwN2ZmIG9uIGlzYTANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3Ig L2tlcm5lbDogZmRjMDogPE5FQyA3MjA2NUIgb3IgY2xvbmU+IGF0IHBvcnQg MHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMA0KRGVjICA5 IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBmZGMwOiBGSUZPIGVuYWJs ZWQsIDggYnl0ZXMgdGhyZXNob2xkDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVz c29yIC9rZXJuZWw6IGZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRj MCBkcml2ZSAwDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6 IGF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBv cnQgMHg2MCwweDY0IG9uIGlzYTANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNz b3IgL2tlcm5lbDogYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGZsYWdzIDB4MSBp cnEgMSBvbiBhdGtiZGMwDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9r ZXJuZWw6IGtiZDAgYXQgYXRrYmQwDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVz c29yIC9rZXJuZWw6IHBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRr YmRjMA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBwc20w OiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwDQpEZWMg IDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHZnYTA6IDxHZW5lcmlj IElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0w eGJmZmZmIG9uIGlzYTANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tl cm5lbDogc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9u IGlzYTANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogc2Mw OiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0KRGVj ICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBzaW8wIGF0IHBvcnQg MHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2EwDQpEZWMgIDkg MTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHNpbzA6IHR5cGUgMTY1NTBB DQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHNpbzE6IGNv bmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAw DQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBwYzA6IDxQ YXJhbGxlbCBwb3J0PiBhdCBwb3J0IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGlz YTANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogcHBjMDog R2VuZXJpYyBjaGlwc2V0IChOSUJCTEUtb25seSkgaW4gQ09NUEFUSUJMRSBt b2RlDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IHBsaXAw OiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwDQpEZWMgIDkg MTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IGxwdDA6IDxQcmludGVyPiBv biBwcGJ1czANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDog bHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0DQpEZWMgIDkgMTM6MzE6NTMg cHJvZmVzc29yIC9rZXJuZWw6IHBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBw YnVzMA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBJUCBw YWNrZXQgZmlsdGVyaW5nIGluaXRpYWxpemVkLCBkaXZlcnQgZGlzYWJsZWQs IHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBlbmFibGVkLCBkZWZhdWx0IHRvIGFj Y2VwdCwgbG9nZ2luZyBkaXNhYmxlZA0KRGVjICA5IDEzOjMxOjUzIHByb2Zl c3NvciAva2VybmVsOiBEVU1NWU5FVCBpbml0aWFsaXplZCAoMDExMDMxKQ0K RGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBhY2QwOiBDRFJP TSA8SEwtRFQtU1QgQ0QtUk9NIEdDUi04NDgwQj4gYXQgYXRhMC1tYXN0ZXIg UElPNA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBXYWl0 aW5nIDE1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUNCkRl YyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogcGFzczUgYXQgbXB0 MCBidXMgMCB0YXJnZXQgOCBsdW4gMA0KRGVjICA5IDEzOjMxOjUzIHByb2Zl c3NvciAva2VybmVsOiBwYXNzNTogPElCTSAzMlAwMDQyYSBTMzIwICAxIDE+ IEZpeGVkIFByb2Nlc3NvciBTQ1NJLTIgZGV2aWNlIA0KRGVjICA5IDEzOjMx OjUzIHByb2Zlc3NvciAva2VybmVsOiBwYXNzNTogMy4zMDBNQi9zIHRyYW5z ZmVycw0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBkYTAg YXQgbXB0MCBidXMgMCB0YXJnZXQgMSBsdW4gMA0KRGVjICA5IDEzOjMxOjUz IHByb2Zlc3NvciAva2VybmVsOiBkYTA6IDxJQk0tRVNYUyBTVDMzNjc1MkxD ICAgICEjIEI4NDE+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmlj ZSANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGEwOiAx NjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDgwLjAwME1Ieiwgb2Zmc2V0IDYzLCAx NmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpEZWMgIDkgMTM6MzE6 NTMgcHJvZmVzc29yIC9rZXJuZWw6IGRhMDogMzQ3MTVNQiAoNzEwOTY2NDAg NTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA0NDI1QykNCkRlYyAgOSAx MzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGEyIGF0IG1wdDAgYnVzIDAg dGFyZ2V0IDMgbHVuIDANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tl cm5lbDogZGEyOiA8SUJNLUVTWFMgU1QzMzY3NTJMQyAgICAhIyBCODQxPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgDQpEZWMgIDkgMTM6 MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IGRhMjogMTYwLjAwME1CL3MgdHJh bnNmZXJzICg4MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQg UXVldWVpbmcgRW5hYmxlZA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAv a2VybmVsOiBkYTI6IDM0NzE1TUIgKDcxMDk2NjQwIDUxMiBieXRlIHNlY3Rv cnM6IDI1NUggNjNTL1QgNDQyNUMpDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVz c29yIC9rZXJuZWw6IGRhMSBhdCBtcHQwIGJ1cyAwIHRhcmdldCAyIGx1biAw DQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IGRhMTogPElC TS1FU1hTIFNUMzM2NzUyTEMgICAgISMgQjg0MT4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTMgZGV2aWNlIA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3Nv ciAva2VybmVsOiBkYTE6IDE2MC4wMDBNQi9zIHRyYW5zZmVycyAoODAuMDAw TUh6LCBvZmZzZXQgNjMsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJs ZWQNCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGExOiAz NDcxNU1CICg3MTA5NjY0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9U IDQ0MjVDKQ0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBk YTQgYXQgbXB0MCBidXMgMCB0YXJnZXQgNSBsdW4gMA0KRGVjICA5IDEzOjMx OjUzIHByb2Zlc3NvciAva2VybmVsOiBkYTQ6IDxJQk0tRVNYUyBTVDMzNjc1 MkxDICAgICEjIEI4NDE+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRl dmljZSANCkRlYyAgOSAxMzozMTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGE0 OiAzLjMwME1CL3MgdHJhbnNmZXJzLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxl ZA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBkYTQ6IDM0 NzE1TUIgKDcxMDk2NjQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg NDQyNUMpDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29yIC9rZXJuZWw6IGRh MyBhdCBtcHQwIGJ1cyAwIHRhcmdldCA0IGx1biAwDQpEZWMgIDkgMTM6MzE6 NTMgcHJvZmVzc29yIC9rZXJuZWw6IGRhMzogPElCTS1FU1hTIFNUMzM2NzUy TEMgICAgISMgQjg0MT4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2 aWNlIA0KRGVjICA5IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBkYTM6 IDE2MC4wMDBNQi9zIHRyYW5zZmVycyAoODAuMDAwTUh6LCBvZmZzZXQgNjMs IDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQNCkRlYyAgOSAxMzoz MTo1MyBwcm9mZXNzb3IgL2tlcm5lbDogZGEzOiAzNDcxNU1CICg3MTA5NjY0 MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDQ0MjVDKQ0KRGVjICA5 IDEzOjMxOjUzIHByb2Zlc3NvciAva2VybmVsOiBNb3VudGluZyByb290IGZy b20gdWZzOi9kZXYvZGEwczFhDQpEZWMgIDkgMTM6MzE6NTMgcHJvZmVzc29y IGxwZFsxMDRdOiBscGQgc3RhcnR1cDogbG9nZ2luZz0wDQo= --43554435-1369830500-1039631701=:886-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 12:28:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E96C237B401; Wed, 11 Dec 2002 12:28:26 -0800 (PST) Received: from pasiphae.parad.net (pcp991894pcs.nchrls01.sc.comcast.net [68.59.35.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9953843EC2; Wed, 11 Dec 2002 12:28:25 -0800 (PST) (envelope-from jdisher@parad.net) Received: from localhost (jdisher@localhost) by pasiphae.parad.net (8.10.2/8.10.2) with ESMTP id gBBKRHB10267; Wed, 11 Dec 2002 15:27:21 -0500 Date: Wed, 11 Dec 2002 15:27:16 -0500 (EST) From: Jonathan Disher X-X-Sender: jdisher@pasiphae To: Long Le Cc: freebsd-hardware@FreeBSD.ORG, Subject: Re: Broadcom NetXtreme 5703 NIC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="43554435-1369830500-1039631701=:886" Content-ID: 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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --43554435-1369830500-1039631701=:886 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Wed, 11 Dec 2002, Long Le wrote: > Hi all, > > We installed FreeBSD 4.7 on an IBM eServer machine with an on-board > copper Broadcom BCM5703X and put two more fiber Broadcom BCM5703X NICs > into the machine. We used cvs to get the latest update on the stable > branch yesterday. However, only the copper NIC and one fiber NIC > come up. The log message says "bge2: MII without any PHY!" for the > second fiber NIC. Does anyone have any suggestion for us? I'm in somewhat the same boat. We just purchased and installed two ASUS A7V8X motherboards with onboard Broadcom BCM5702 Gigabit ethernet controllers, and we're having some problems getting them to work. I cvsup'd to the latest -STABLE last night, and the controller is found, but it's using ukphy instead of brgphy. Has anyone gotten this controller to work successfully in 4.7? Or is this something that I should expect to see in 5.0 or 4.8? If this has already been discussed, please accept my apologies, I just subscribed to the list this morning and I didn't see anything related in a Google search... dmesg attached. -j --43554435-1369830500-1039631701=:886 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ns2-dmesg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ns2-dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDIgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCA0LjctU1RBQkxFICM1OiBXZWQgRGVj IDExIDEyOjM5OjMwIEVTVCAyMDAyDQogICAgamRpc2hlckBucy0yLmF3b2Qu Y29tOi91c3Ivc3JjL3N5cy9jb21waWxlL25zLTINClRpbWVjb3VudGVyICJp ODI1NCIgIGZyZXF1ZW5jeSAxMTkzMTgyIEh6DQpUaW1lY291bnRlciAiVFND IiAgZnJlcXVlbmN5IDE2NjY3MzYwMzUgSHoNCkNQVTogQU1EIEF0aGxvbihU TSkgWFAgMjAwMCsgKDE2NjYuNzQtTUh6IDY4Ni1jbGFzcyBDUFUpDQogIE9y aWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4NjYyICBTdGVwcGluZyA9 IDINCiAgRmVhdHVyZXM9MHgzODNmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxN U1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LE1NWCxGWFNSLFNTRT4NCiAgQU1EIEZlYXR1cmVzPTB4YzA0MDAw MDA8QU1JRSxEU1AsM0ROb3chPg0KcmVhbCBtZW1vcnkgID0gNTM2ODU0NTI4 ICg1MjQyNzJLIGJ5dGVzKQ0KYXZhaWwgbWVtb3J5ID0gNTE5Mjk5MDcyICg1 MDcxMjhLIGJ5dGVzKQ0KUHJlbG9hZGVkIGVsZiBrZXJuZWwgImtlcm5lbCIg YXQgMHhjMDJhZDAwMC4NClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFi bGVkDQpVc2luZyAkUElSIHRhYmxlLCAxMiBlbnRyaWVzIGF0IDB4YzAwZjFj ZDANCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQNCm5w eDA6IElOVCAxNiBpbnRlcmZhY2UNCnBjaWIwOiA8SG9zdCB0byBQQ0kgYnJp ZGdlPiBvbiBtb3RoZXJib2FyZA0KcGNpMDogPFBDSSBidXM+IG9uIHBjaWIw DQpwY2liMTogPFBDSSB0byBQQ0kgYnJpZGdlICh2ZW5kb3I9MTEwNiBkZXZp Y2U9YjE2OCk+IGF0IGRldmljZSAxLjAgb24gcGNpMA0KcGNpMTogPFBDSSBi dXM+IG9uIHBjaWIxDQpwY2kxOiA8U2lTIG1vZGVsIDAzMDAgVkdBLWNvbXBh dGlibGUgZGlzcGxheSBkZXZpY2U+IGF0IDAuMCBpcnEgMTENCnBjaTA6IDx1 bmtub3duIGNhcmQ+ICh2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMDQ0KSBhdCA3 LjAgaXJxIDEwDQpwY2kwOiA8dW5rbm93biBjYXJkPiAodmVuZG9yPTB4MTA1 YSwgZGV2PTB4MzM3NikgYXQgOC4wIGlycSAxMA0KYmdlMDogPEJyb2FkY29t IEJDTTU3MDJYIEdpZ2FiaXQgRXRoZXJuZXQ+IG1lbSAweGVkMDAwMDAwLTB4 ZWQwMGZmZmYgaXJxIDEyIGF0IGRldmljZSA5LjAgb24gcGNpMA0KYmdlMDog RXRoZXJuZXQgYWRkcmVzczogMDA6ZTA6MTg6ZDM6NzE6MzUNCm1paWJ1czA6 IDxNSUkgYnVzPiBvbiBiZ2UwDQp1a3BoeTA6IDxHZW5lcmljIElFRUUgODAy LjN1IG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMA0KdWtwaHkwOiAgMTBi YXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwg YXV0bw0KeGwwOiA8M0NvbSAzYzkwNUItVFggRmFzdCBFdGhlcmxpbmsgWEw+ IHBvcnQgMHhhNDAwLTB4YTQ3ZiBtZW0gMHhlYzgwMDAwMC0weGVjODAwMDdm IGlycSAxMSBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwDQp4bDA6IEV0aGVybmV0 IGFkZHJlc3M6IDAwOjUwOjA0OmIyOjZlOjE1DQptaWlidXMxOiA8TUlJIGJ1 cz4gb24geGwwDQp4bHBoeTA6IDwzQ29tIGludGVybmFsIG1lZGlhIGludGVy ZmFjZT4gb24gbWlpYnVzMQ0KeGxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1G RFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bw0KeGwxOiA8M0Nv bSAzYzkwNS1UWCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAweGEwMDAtMHhh MDNmIGlycSAxMCBhdCBkZXZpY2UgMTQuMCBvbiBwY2kwDQp4bDE6IEV0aGVy bmV0IGFkZHJlc3M6IDAwOjYwOjk3Ojc3OmQ5OjcxDQptaWlidXMyOiA8TUlJ IGJ1cz4gb24geGwxDQpuc3BoeTA6IDxEUDgzODQwIDEwLzEwMCBtZWRpYSBp bnRlcmZhY2U+IG9uIG1paWJ1czINCm5zcGh5MDogIDEwYmFzZVQsIDEwYmFz ZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NCmlzYWIw OiA8UENJIHRvIElTQSBicmlkZ2UgKHZlbmRvcj0xMTA2IGRldmljZT0zMTc3 KT4gYXQgZGV2aWNlIDE3LjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9u IGlzYWIwDQphdGFwY2kwOiA8VklBIDgyMzUgQVRBMTMzIGNvbnRyb2xsZXI+ IHBvcnQgMHg4ODAwLTB4ODgwZiBhdCBkZXZpY2UgMTcuMSBvbiBwY2kwDQph dGEwOiBhdCAweDFmMCBpcnEgMTQgb24gYXRhcGNpMA0KYXRhMTogYXQgMHgx NzAgaXJxIDE1IG9uIGF0YXBjaTANCm9ybTA6IDxPcHRpb24gUk9NPiBhdCBp b21lbSAweGMwMDAwLTB4Y2ZmZmYgb24gaXNhMA0KZmRjMDogPE5FQyA3MjA2 NUIgb3IgY2xvbmU+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYg ZHJxIDIgb24gaXNhMA0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRo cmVzaG9sZA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQy KT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMA0KdmdhMDogPEdlbmVyaWMg SVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4 YmZmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdz IDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDw4IHZpcnR1YWwgY29uc29sZXMs IGZsYWdzPTB4MzAwPg0KYWQwOiAxOTU0MU1CIDxNYXh0b3IgNTIwNDlVND4g WzM5NzAzLzE2LzYzXSBhdCBhdGEwLW1hc3RlciBVRE1BNjYNCmFkMjogNzgx NjdNQiA8TWF4dG9yIDk4MTk2SDg+IFsxNTg4MTYvMTYvNjNdIGF0IGF0YTEt bWFzdGVyIFVETUExMDANCmFkMzogNzgxNjdNQiA8TWF4dG9yIDk4MTk2SDg+ IFsxNTg4MTYvMTYvNjNdIGF0IGF0YTEtc2xhdmUgVURNQTEwMA0KTW91bnRp bmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQ0KDQo= --43554435-1369830500-1039631701=:886-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 20: 1:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFE7937B401 for ; Wed, 11 Dec 2002 20:01:57 -0800 (PST) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5319E43ED1 for ; Wed, 11 Dec 2002 20:01:57 -0800 (PST) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (bigv.netvulture.com [192.168.2.2]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id gBC41kMh026492 for ; Wed, 11 Dec 2002 20:01:46 -0800 (PST) Message-ID: <3DF80A4D.6020305@consult-scs.com> Date: Wed, 11 Dec 2002 20:02:21 -0800 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: DNS Translation Content-Type: text/plain; charset=us-ascii; format=flowed 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 Has anyone come across a daemon that will translate dns query responses from inside ip's to outside ip's, when the query is though the firewall? The CISCO PIX I have at work does this with the alias command - but - I'm not at work where I'd like to do that. Thanks - Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 20:14: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D00A837B401 for ; Wed, 11 Dec 2002 20:14:05 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A93143EB2 for ; Wed, 11 Dec 2002 20:14:05 -0800 (PST) (envelope-from cswiger@mac.com) Received: from prime ([12.88.93.216]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021212041358.TASL9286.mtiwmhc11.worldnet.att.net@prime>; Thu, 12 Dec 2002 04:13:58 +0000 Message-ID: <00c501c2a194$e5385060$0301a8c0@prime> From: "Charles Swiger" To: Cc: "Jonathan Feally" References: <3DF80A4D.6020305@consult-scs.com> Subject: Re: DNS Translation Date: Wed, 11 Dec 2002 23:13:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Jonathan Feally wrote: > Has anyone come across a daemon that will translate dns query > responses from inside ip's to outside ip's, when the query is though > the firewall? The CISCO PIX I have at work does this with the alias > command - but - I'm not at work where I'd like to do that. See the BIND-9 administrator's guide at http://www.nominum.com/content/documents/bind9arm.pdf Specificly: "4.3. Split DNS Setting up different views, or visibility, of DNS space to internal and external resolvers is usually referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way. One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy"attackers" can find the information they need using other means.Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside back in to the internal network." -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 11 23:24:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7057837B401 for ; Wed, 11 Dec 2002 23:24:45 -0800 (PST) Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7118B43EB2 for ; Wed, 11 Dec 2002 23:24:44 -0800 (PST) (envelope-from listsub@401.cx) Received: from 401.cx (malin.twenty4help.se [195.67.108.195]) by mailf.telia.com (8.12.5/8.12.5) with ESMTP id gBC7OgKs009695; Thu, 12 Dec 2002 08:24:42 +0100 (CET) X-Original-Recipient: freebsd-net@FreeBSD.ORG Message-ID: <3DF83968.5060000@401.cx> Date: Thu, 12 Dec 2002 08:23:20 +0100 From: "Roger 'Rocky' Vetterberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: soheil soheil Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW References: Content-Type: text/plain; charset=us-ascii; format=flowed 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 soheil soheil wrote: > Dear ALL > i run this commands on my 4.4FreeBSD-Release > #/sbin/ipfw -f flush > #/sbin/ipfw divert 5050 ip from any to any > it runs the first command and say no socket found > and then when i run the second line it write the words for help and > nothing is applied > what can i do ? > I have a divert socket on port 5050 i want to divert all of the packet > to it > thanx > First of all, I think this belongs to -question. Are you sure you have ipfw in your kernel? The "no socket" error is usually due to not having it in the kernel or not loading the module. The second error is a syntax error. Try #/sbin/ipfw add divert 5050 ip from any to any -- R To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 12 11:19:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FAA737B401; Thu, 12 Dec 2002 11:19:12 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E91943ED1; Thu, 12 Dec 2002 11:19:11 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id gBCJJ982025508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Dec 2002 14:19:10 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gBCJJ4V07773; Thu, 12 Dec 2002 14:19:04 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15864.57640.801997.698563@grasshopper.cs.duke.edu> Date: Thu, 12 Dec 2002 14:19:04 -0500 (EST) To: Jonathan Disher Cc: Long Le , freebsd-hardware@FreeBSD.ORG, Reply-To: freebsd-net@FreeBSD.ORG Subject: Re: Broadcom NetXtreme 5703 NIC In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Jonathan Disher writes: > On Wed, 11 Dec 2002, Long Le wrote: > > > Hi all, > > > > We installed FreeBSD 4.7 on an IBM eServer machine with an on-board > > copper Broadcom BCM5703X and put two more fiber Broadcom BCM5703X NICs > > into the machine. We used cvs to get the latest update on the stable > > branch yesterday. However, only the copper NIC and one fiber NIC > > come up. The log message says "bge2: MII without any PHY!" for the > > second fiber NIC. Does anyone have any suggestion for us? > > I'm in somewhat the same boat. We just purchased and installed two ASUS > A7V8X motherboards with onboard Broadcom BCM5702 Gigabit ethernet > controllers, and we're having some problems getting them to work. I > cvsup'd to the latest -STABLE last night, and the controller is found, but > it's using ukphy instead of brgphy. Has anyone gotten this controller to New phy support which is required for the BCM5703 was merged from current yesterday. You may which to try a more recent stable and verify that you have rev 1.4.2.10 of sys/dev/mii/miidevs.h Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 12 17:16: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BBA237B401; Thu, 12 Dec 2002 17:16:02 -0800 (PST) Received: from pasiphae.parad.net (pcp991894pcs.nchrls01.sc.comcast.net [68.59.35.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46EDF43EDE; Thu, 12 Dec 2002 17:16:01 -0800 (PST) (envelope-from jdisher@parad.net) Received: from localhost (jdisher@localhost) by pasiphae.parad.net (8.10.2/8.10.2) with ESMTP id gBD1G0D17966; Thu, 12 Dec 2002 20:16:00 -0500 Date: Thu, 12 Dec 2002 20:16:00 -0500 (EST) From: Jonathan Disher X-X-Sender: jdisher@pasiphae To: freebsd-net@FreeBSD.ORG Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Broadcom NetXtreme 5703 NIC In-Reply-To: <15864.57640.801997.698563@grasshopper.cs.duke.edu> 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 in somewhat the same boat. We just purchased and installed two ASUS > > A7V8X motherboards with onboard Broadcom BCM5702 Gigabit ethernet > > controllers, and we're having some problems getting them to work. I > > cvsup'd to the latest -STABLE last night, and the controller is found, but > > it's using ukphy instead of brgphy. Has anyone gotten this controller to > > New phy support which is required for the BCM5703 was merged from > current yesterday. You may which to try a more recent stable and > verify that you have rev 1.4.2.10 of sys/dev/mii/miidevs.h Yeah, I'd imagine it was merged in by Paul Saab, who sent me a patch that made things work. I was waiting for him to post that it was in. Thanks. -j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 12 18:40:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 998A237B401 for ; Thu, 12 Dec 2002 18:40:49 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id D190543E4A for ; Thu, 12 Dec 2002 18:40:48 -0800 (PST) (envelope-from thomas.r.henderson@boeing.com) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id UAA12020 for ; Thu, 12 Dec 2002 20:40:43 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id UAA27660 for ; Thu, 12 Dec 2002 20:40:42 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id gBD2ef602108 for ; Thu, 12 Dec 2002 18:40:41 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Dec 2002 18:40:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: transport protocol hook for kqueue Date: Thu, 12 Dec 2002 18:40:35 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C923D65@XCH-NW-27.nw.nos.boeing.com> Thread-Topic: transport protocol hook for kqueue Thread-Index: AcKiUQOvIVGWvcnVTbuUfIgM0T/wcg== From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 13 Dec 2002 02:40:36.0018 (UTC) FILETIME=[03D5A920:01C2A251] 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 trying to integrate Dave Bailey's bsdproxy with an experimental transport protocol (substitutes for TCP and preserves same API semantics). However, I can't seem to trigger a read event with the new protocol-- the client side socket buffer fills up with data but bsdproxy never gets a read event. I have been able to use simpler proxies (ones that basically pipe between descriptors) successfully. Is there anything special that needs to be done at the transport layer to trigger a kevent read? My protocol calls sorwakeup() at the appropriate times-- I had thought that would be enough and that kqueue would be indifferent to the underlying transport protocol implementation. Nothing seems apparent in the TCP code, however. Tom=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 2:25:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D7DC37B401 for ; Fri, 13 Dec 2002 02:25:50 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id F008A43EC5 for ; Fri, 13 Dec 2002 02:25:48 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gBDAPguO071591 for ; Fri, 13 Dec 2002 12:25:45 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DF9B5A6.4070603@he.iki.fi> Date: Fri, 13 Dec 2002 12:25:42 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: libpcap Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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 Suggestions what would it take to make libpcap included in the FreeBSD distribution stop tweaking BPF buffer size by default? tcpdump.org people have been nonresponsive about changing it there, so I would suggest it should be patched in FreeBSD to allow applications to control buffer size. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 5:14:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02CE937B401 for ; Fri, 13 Dec 2002 05:14:19 -0800 (PST) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B1043EB2 for ; Fri, 13 Dec 2002 05:14:18 -0800 (PST) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.globali.net [127.0.0.1]) by overlord.e-gerbil.net (8.12.6/8.12.6) with ESMTP id gBDDE4GQ069399; Fri, 13 Dec 2002 08:14:04 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.6/8.12.6/Submit) id gBDDDu5m069398; Fri, 13 Dec 2002 08:13:56 -0500 (EST) Date: Fri, 13 Dec 2002 08:13:56 -0500 From: Richard A Steenbergen To: Petri Helenius Cc: freebsd-net@FreeBSD.ORG Subject: Re: libpcap Message-ID: <20021213131356.GF56949@overlord.e-gerbil.net> References: <3DF9B5A6.4070603@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DF9B5A6.4070603@he.iki.fi> User-Agent: Mutt/1.5.1i 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, Dec 13, 2002 at 12:25:42PM +0200, Petri Helenius wrote: > > Suggestions what would it take to make libpcap included in the FreeBSD > distribution > stop tweaking BPF buffer size by default? > > tcpdump.org people have been nonresponsive about changing it there, so I > would suggest > it should be patched in FreeBSD to allow applications to control buffer > size. Sure, fix the code starting at src/contrib/libpcap/pcap-bpf.c:236, which even says (complete with outdated assumption that 32768 is big): /* * Try finding a good size for the buffer; 32768 may be too * big, so keep cutting it in half until we find a size * that works, or run out of sizes to try. * * XXX - there should be a user-accessible hook to set the * initial buffer size. */ The problem is, you can't add it as a parameter to any of the existing functions without royally breaking existing code. You could add another function for setting it, but that would still produce freebsd specific code. You could just remove that code completely, and let the sysctl specified default take over, but where one libpcap application might have use for a 1MB buffer another might be wasting it completely. But changing stuff like this in FreeBSD pretty much defeats the purpose of having a portable lib. I'd suggest either clubbing them over the head with the need to fix it, modifying your local copy to suit your needs, or better yet (since you obviously don't mind a fbsd specific hack) just use bpf yourself (and you get bpf write functionality too :P). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 5:46:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAB9437B401 for ; Fri, 13 Dec 2002 05:46:54 -0800 (PST) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AAF43EC2 for ; Fri, 13 Dec 2002 05:46:54 -0800 (PST) (envelope-from ghelmer@palisadesys.com) Received: from localhost (ghelmer@localhost) by magellan.palisadesys.com (8.11.6/8.11.6) with ESMTP id gBDDke703615; Fri, 13 Dec 2002 07:46:40 -0600 Date: Fri, 13 Dec 2002 07:46:40 -0600 (CST) From: Guy Helmer To: Petri Helenius Cc: Subject: Re: libpcap In-Reply-To: <3DF9B5A6.4070603@he.iki.fi> 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 Fri, 13 Dec 2002, Petri Helenius wrote: > Suggestions what would it take to make libpcap included in the FreeBSD > distribution stop tweaking BPF buffer size by default? I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the BPF buffer size to something more reasonable without having to directly modify libpcap. Guy -- Guy Helmer, Ph.D. http://www.palisadesys.com/~ghelmer Sr. Software Engineer, Palisade Systems ghelmer@palisadesys.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 5:57:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0472737B401 for ; Fri, 13 Dec 2002 05:57:10 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC2AD43EB2 for ; Fri, 13 Dec 2002 05:57:08 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gBDDtvuO072361; Fri, 13 Dec 2002 15:56:02 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DF9E6ED.6030205@he.iki.fi> Date: Fri, 13 Dec 2002 15:55:57 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Richard A Steenbergen Cc: freebsd-net@FreeBSD.ORG Subject: Re: libpcap References: <3DF9B5A6.4070603@he.iki.fi> <20021213131356.GF56949@overlord.e-gerbil.net> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Richard A Steenbergen wrote: >On Fri, Dec 13, 2002 at 12:25:42PM +0200, Petri Helenius wrote: > > >>Suggestions what would it take to make libpcap included in the FreeBSD >>distribution >>stop tweaking BPF buffer size by default? >> >>tcpdump.org people have been nonresponsive about changing it there, so I >>would suggest >>it should be patched in FreeBSD to allow applications to control buffer >>size. >> >> > >Sure, fix the code starting at src/contrib/libpcap/pcap-bpf.c:236, which >even says (complete with outdated assumption that 32768 is big): > > That's what we have done, the problem is that every time the source tree is brought up to RELENG_4_7 or RELENG_4 the change needs to be reapplied, so that's why the appeal to fix it at the source. > /* > * Try finding a good size for the buffer; 32768 may be too > * big, so keep cutting it in half until we find a size > * that works, or run out of sizes to try. > * > * XXX - there should be a user-accessible hook to set the > * initial buffer size. > */ > >The problem is, you can't add it as a parameter to any of the existing >functions without royally breaking existing code. You could add another >function for setting it, but that would still produce freebsd specific >code. You could just remove that code completely, and let the sysctl >specified default take over, but where one libpcap application might have >use for a 1MB buffer another might be wasting it completely. > > I think the libpcap code should not touch a parameter: - which has a system settable default - which is accessible to an application Specifically since it cannot be set either before or after the pcap stuff initialized. >But changing stuff like this in FreeBSD pretty much defeats the purpose of >having a portable lib. I'd suggest either clubbing them over the head with >the need to fix it, modifying your local copy to suit your needs, or >better yet (since you obviously don't mind a fbsd specific hack) just use >bpf yourself (and you get bpf write functionality too :P). > > If I do move somewhere, moving away from bpf (and libpcap) would only improve performance. It's more work but eventually a must. Pete > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 5:58:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F79A37B401 for ; Fri, 13 Dec 2002 05:58:41 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F4043EC2 for ; Fri, 13 Dec 2002 05:58:40 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gBDDwcuO072369; Fri, 13 Dec 2002 15:58:39 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DF9E78E.50001@he.iki.fi> Date: Fri, 13 Dec 2002 15:58:38 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Guy Helmer Cc: freebsd-net@FreeBSD.ORG Subject: Re: libpcap References: Content-Type: text/plain; charset=us-ascii; format=flowed 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 Guy Helmer wrote: >I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the >BPF buffer size to something more reasonable without having to directly >modify libpcap. > > > >Hope you're not disappointed to find out that modifying that parameter has > no effect when using applications which use libpcap since libpcap always sets the buffer size to 32768. (which is exactly the problem I'm complaining about) Pete > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 8: 6: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CB3B37B401 for ; Fri, 13 Dec 2002 08:06:02 -0800 (PST) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id A25E643ED1 for ; Fri, 13 Dec 2002 08:06:01 -0800 (PST) (envelope-from ghelmer@palisadesys.com) Received: from mira (mira.palisadesys.com [192.188.162.116]) (authenticated (0 bits)) by magellan.palisadesys.com (8.11.6/8.11.6) with ESMTP id gBDG5wI05290 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 13 Dec 2002 10:05:58 -0600 From: "Guy Helmer" To: "Petri Helenius" Cc: Subject: RE: libpcap Date: Fri, 13 Dec 2002 10:05:58 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3DF9E78E.50001@he.iki.fi> 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 Petri Helenius wrote: > Guy Helmer wrote: > >I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the > >BPF buffer size to something more reasonable without having to directly > >modify libpcap. > > > Hope you're not disappointed to find out that modifying that parameter has > no effect when using applications which use libpcap since libpcap always > sets the buffer size to 32768. (which is exactly the problem I'm complaining about) You are right - I misremembered how the BIOCSBLEN ioctl worked. My appliances do have a private copy of libpcap with a larger buffer size because of this problem. IMHO, it would be better for the libpcap code to query the default BPF buffer size (BIOCGLEN) and use it if it is larger than the libpcap default size (32768). Then libpcap would obey the buffer size set by the sysctl. Guy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 9:53: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54BCB37B401 for ; Fri, 13 Dec 2002 09:53:02 -0800 (PST) Received: from web21408.mail.yahoo.com (web21408.mail.yahoo.com [216.136.232.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 2503C43E4A for ; Fri, 13 Dec 2002 09:53:02 -0800 (PST) (envelope-from zopewiz@yahoo.com) Message-ID: <20021213175301.48423.qmail@web21408.mail.yahoo.com> Received: from [63.170.174.190] by web21408.mail.yahoo.com via HTTP; Fri, 13 Dec 2002 09:53:01 PST Date: Fri, 13 Dec 2002 09:53:01 -0800 (PST) From: Carlos Carnero Subject: Static routes at startup To: FreeBSD Network 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, I wonder if I can put stuff in rc.conf to add static routes when my machine boots. Is that possible? I mean, currently I'm adding those routes in rc.local, but I'd really like to see them in rc.conf. Best regards, Carlos. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 9:54:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3167937B401 for ; Fri, 13 Dec 2002 09:54:19 -0800 (PST) Received: from web21414.mail.yahoo.com (web21414.mail.yahoo.com [216.136.232.185]) by mx1.FreeBSD.org (Postfix) with SMTP id 0534A43EA9 for ; Fri, 13 Dec 2002 09:54:19 -0800 (PST) (envelope-from zopewiz@yahoo.com) Message-ID: <20021213175418.21275.qmail@web21414.mail.yahoo.com> Received: from [63.170.174.190] by web21414.mail.yahoo.com via HTTP; Fri, 13 Dec 2002 09:54:18 PST Date: Fri, 13 Dec 2002 09:54:18 -0800 (PST) From: Carlos Carnero Subject: Re: Static routes at startup To: FreeBSD Network 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 Oh, please disregard. man rc.conf is my friend. Thanks, Carlos. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 10:27:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63C2B37B401 for ; Fri, 13 Dec 2002 10:27:28 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F182543EC2 for ; Fri, 13 Dec 2002 10:27:27 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 29FF57B472; Fri, 13 Dec 2002 13:27:27 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E7AFE7B46E; Fri, 13 Dec 2002 13:27:25 -0500 (EST) Message-ID: <3DFA268D.A073F0F3@internet2.edu> Date: Fri, 13 Dec 2002 11:27:25 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 udp socket bind: EADDRNOTAVAIL? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 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 a long running IPv6 daemon that uses both tcp and udp. It accepts requests on a tcp socket, and then performs an action on a udp socket using the same local address that the tcp request came in on. (I am calling bind on the udp socket to allocate a port number to return to the client over the tcp connection.) My problem is that I get intermittent bind failures for the udp socket. I'm trying to understand what is going on here. The udp bind is for the same address as the local address of the tcp socket. (Although the tcp socket was originally bound using the wildcard.) I have tracked this down to the following lines in the kernel code: in6_pcb.c:129 if (!in6_ifaddr) /* XXX broken! */ return (EADDRNOTAVAIL); It looks like the kernel's list of v6 interfaces is empty for some reason. Is that correct, or is there some other reason this list would be empty? Questions: 1. The comment says broken. Anyone know why the comment says that? (The IPv4 version of bind says the same thing...) 2. This system is auto configuring this address... Is it possible that I'm just having this problem because the system is reconfiguring the address at this time? (I must admit that I have not looked at the auto configuration stuff.) Thanks, jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 19:29:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7480837B401 for ; Fri, 13 Dec 2002 19:29:56 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB5B943EC2 for ; Fri, 13 Dec 2002 19:29:50 -0800 (PST) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-63.dsl.snfc21.pacbell.net [63.201.91.63]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gBE3TnMv367508 for ; Fri, 13 Dec 2002 22:29:49 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id gBE3TmYl033717 for ; Fri, 13 Dec 2002 19:29:48 -0800 (PST) (envelope-from kbyanc@posi.net) Date: Fri, 13 Dec 2002 19:29:48 -0800 (PST) From: Kelly Yancey To: net@FreeBSD.org Subject: Raw sockets and splnet() Message-ID: <20021213191946.Y33706-100000@gateway.posi.net> 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 Is there any particular reason that the raw socket implementation in net/raw_usrreq.c does not require splnet() protection? It seems as though adding splnet()/splx() calls to the various raw_* routines would greatly reduce the size of net/rtsock.c, in which many of the routines simply wrap their raw_ counterparts with splnet()/splx(). Currently, it appears that routing sockets are the only consumer of the raw socket interface at the moment, but if another consumer were to exist then they would have to do the same splnet()/splx() hackery I imagine. Wouldn't it make sense to just put the logic into net/raw_usrreq.c and be done with it? Any insight would be appreciated. Thanks, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} Visit the BSD driver database: http://www.posi.net/freebsd/drivers/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 19:59:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB5237B401 for ; Fri, 13 Dec 2002 19:59:25 -0800 (PST) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDA8643E4A for ; Fri, 13 Dec 2002 19:59:24 -0800 (PST) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-63.dsl.snfc21.pacbell.net [63.201.91.63]) by pimout2-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gBE3xNDL100028 for ; Fri, 13 Dec 2002 22:59:23 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id gBE3xMYl033749 for ; Fri, 13 Dec 2002 19:59:22 -0800 (PST) (envelope-from kbyanc@posi.net) Date: Fri, 13 Dec 2002 19:59:22 -0800 (PST) From: Kelly Yancey To: net@FreeBSD.org Subject: Re: Raw sockets and splnet() In-Reply-To: <20021213191946.Y33706-100000@gateway.posi.net> Message-ID: <20021213194809.N33726-100000@gateway.posi.net> 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 Dec 2002, Kelly Yancey wrote: > > Is there any particular reason that the raw socket implementation in > net/raw_usrreq.c does not require splnet() protection? It seems as though > adding splnet()/splx() calls to the various raw_* routines would greatly > reduce the size of net/rtsock.c, in which many of the routines simply wrap > their raw_ counterparts with splnet()/splx(). > Currently, it appears that routing sockets are the only consumer of the raw > socket interface at the moment, but if another consumer were to exist then > they would have to do the same splnet()/splx() hackery I imagine. Wouldn't it > make sense to just put the logic into net/raw_usrreq.c and be done with it? > > Any insight would be appreciated. Thanks, > > Kelly > Actually, as a follow-up to my own question, I don't see how the splnet()/splx() calls in rtsock.c are necessary at all as all of the pru_* hooks are called at splnet(). Being that rtsock's pru_* hooks are called at splnet(), is there any reason not to just extern the various raw_* pru hooks and reference them directly from route_usrreqs? Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 20:22: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27C6137B401 for ; Fri, 13 Dec 2002 20:22:03 -0800 (PST) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79F5343EA9 for ; Fri, 13 Dec 2002 20:21:57 -0800 (PST) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-63.dsl.snfc21.pacbell.net [63.201.91.63]) by pimout2-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gBE4LoDL034568 for ; Fri, 13 Dec 2002 23:21:50 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id gBE4LmYl033783 for ; Fri, 13 Dec 2002 20:21:49 -0800 (PST) (envelope-from kbyanc@posi.net) Date: Fri, 13 Dec 2002 20:21:48 -0800 (PST) From: Kelly Yancey To: net@FreeBSD.org Subject: Re: Raw sockets and splnet() In-Reply-To: <20021213194809.N33726-100000@gateway.posi.net> Message-ID: <20021213201926.A33726-200000@gateway.posi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-553016530-1039839708=:33726" 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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-553016530-1039839708=:33726 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 13 Dec 2002, Kelly Yancey wrote: > Actually, as a follow-up to my own question, I don't see how the > splnet()/splx() calls in rtsock.c are necessary at all as all of the pru_* > hooks are called at splnet(). Being that rtsock's pru_* hooks are called at > splnet(), is there any reason not to just extern the various raw_* pru hooks > and reference them directly from route_usrreqs? > > Kelly For a better idea of what I am talking about, a diff against 4.7 is attached. I've confirmed that it compiles and will leave a machine running with this patch up over the weekend. Any comments would be appreciated, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ --0-553016530-1039839708=:33726 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rtsock.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20021213202148.A33726@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="rtsock.diff" SW5kZXg6IHJhd19jYi5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0L3Jhd19jYi5o LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQ0KZGlmZiAtdSAtcCAt cjEuMS4xLjEgcmF3X2NiLmgNCi0tLSByYXdfY2IuaAkyMiBNYXIgMjAwMiAw NDoxMTowMCAtMDAwMAkxLjEuMS4xDQorKysgcmF3X2NiLmgJMTQgRGVjIDIw MDIgMDQ6MTc6NTUgLTAwMDANCkBAIC03MSw2ICs3MSwxOSBAQCB2b2lkCSBy YXdfaW5wdXQgX19QKChzdHJ1Y3QgbWJ1ZiAqLA0KIAkgICAgc3RydWN0IHNv Y2twcm90byAqLCBzdHJ1Y3Qgc29ja2FkZHIgKiwgc3RydWN0IHNvY2thZGRy ICopKTsNCiANCiBleHRlcm4Jc3RydWN0IHByX3VzcnJlcXMgcmF3X3VzcnJl cXM7DQorDQoraW50CSByYXdfdWFib3J0IF9fUCgoc3RydWN0IHNvY2tldCAq KSk7DQoraW50CSByYXdfdWF0dGFjaCBfX1AoKHN0cnVjdCBzb2NrZXQgKiwg aW50LCBzdHJ1Y3QgcHJvYyAqKSk7DQoraW50CSByYXdfdWJpbmQgX19QKChz dHJ1Y3Qgc29ja2V0ICosIHN0cnVjdCBzb2NrYWRkciAqLCBzdHJ1Y3QgcHJv YyAqKSk7DQoraW50CSByYXdfdWNvbm5lY3QgX19QKChzdHJ1Y3Qgc29ja2V0 ICosIHN0cnVjdCBzb2NrYWRkciAqLCBzdHJ1Y3QgcHJvYyAqKSk7DQoraW50 CSByYXdfdWRldGFjaCBfX1AoKHN0cnVjdCBzb2NrZXQgKikpOw0KK2ludAkg cmF3X3VkaXNjb25uZWN0IF9fUCgoc3RydWN0IHNvY2tldCAqKSk7DQoraW50 CSByYXdfdXBlZXJhZGRyIF9fUCgoc3RydWN0IHNvY2tldCAqLCBzdHJ1Y3Qg c29ja2FkZHIgKiopKTsNCitpbnQJIHJhd191c2VuZCBfX1AoKHN0cnVjdCBz b2NrZXQgKiwgaW50LCBzdHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3Qgc29ja2FkZHIg KiwNCisJCQlzdHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3QgcHJvYyAqKSk7DQoraW50 CSByYXdfdXNodXRkb3duIF9fUCgoc3RydWN0IHNvY2tldCAqKSk7DQoraW50 CSByYXdfdXNvY2thZGRyIF9fUCgoc3RydWN0IHNvY2tldCAqLCBzdHJ1Y3Qg c29ja2FkZHIgKiopKTsNCisNCiAjZW5kaWYNCiANCiAjZW5kaWYNCkluZGV4 OiByYXdfdXNycmVxLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm aWxlOiAvaG9tZS9jdnMvYWNzL2Jhc2Uvc3JjL3N5cy9uZXQvcmF3X3VzcnJl cS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQ0KZGlmZiAtdSAt cCAtcjEuMS4xLjEgcmF3X3VzcnJlcS5jDQotLS0gcmF3X3VzcnJlcS5jCTIy IE1hciAyMDAyIDA0OjExOjAwIC0wMDAwCTEuMS4xLjENCisrKyByYXdfdXNy cmVxLmMJMTQgRGVjIDIwMDIgMDQ6MTc6NTUgLTAwMDANCkBAIC0xMzUsNyAr MTM1LDcgQEAgcmF3X2N0bGlucHV0KGNtZCwgYXJnLCBkdW1teSkNCiAJLyog SU5DT01QTEVURSAqLw0KIH0NCiANCi1zdGF0aWMgaW50DQoraW50DQogcmF3 X3VhYm9ydChzdHJ1Y3Qgc29ja2V0ICpzbykNCiB7DQogCXN0cnVjdCByYXdj YiAqcnAgPSBzb3RvcmF3Y2Ioc28pOw0KQEAgLTE1MCw3ICsxNTAsNyBAQCBy YXdfdWFib3J0KHN0cnVjdCBzb2NrZXQgKnNvKQ0KIA0KIC8qIHBydV9hY2Nl cHQgaXMgRU9QTk9UU1VQUCAqLw0KIA0KLXN0YXRpYyBpbnQNCitpbnQNCiBy YXdfdWF0dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50IHByb3RvLCBzdHJ1 Y3QgcHJvYyAqcCkNCiB7DQogCXN0cnVjdCByYXdjYiAqcnAgPSBzb3RvcmF3 Y2Ioc28pOw0KQEAgLTE2MywxMyArMTYzLDEzIEBAIHJhd191YXR0YWNoKHN0 cnVjdCBzb2NrZXQgKnNvLCBpbnQgcHJvdG8NCiAJcmV0dXJuIHJhd19hdHRh Y2goc28sIHByb3RvKTsNCiB9DQogDQotc3RhdGljIGludA0KK2ludA0KIHJh d191YmluZChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpu YW0sIHN0cnVjdCBwcm9jICpwKQ0KIHsNCiAJcmV0dXJuIEVJTlZBTDsNCiB9 DQogDQotc3RhdGljIGludA0KK2ludA0KIHJhd191Y29ubmVjdChzdHJ1Y3Qg c29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuYW0sIHN0cnVjdCBwcm9j ICpwKQ0KIHsNCiAJcmV0dXJuIEVJTlZBTDsNCkBAIC0xNzgsNyArMTc4LDcg QEAgcmF3X3Vjb25uZWN0KHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgcw0K IC8qIHBydV9jb25uZWN0MiBpcyBFT1BOT1RTVVBQICovDQogLyogcHJ1X2Nv bnRyb2wgaXMgRU9QTk9UU1VQUCAqLw0KIA0KLXN0YXRpYyBpbnQNCitpbnQN CiByYXdfdWRldGFjaChzdHJ1Y3Qgc29ja2V0ICpzbykNCiB7DQogCXN0cnVj dCByYXdjYiAqcnAgPSBzb3RvcmF3Y2Ioc28pOw0KQEAgLTE5MCw3ICsxOTAs NyBAQCByYXdfdWRldGFjaChzdHJ1Y3Qgc29ja2V0ICpzbykNCiAJcmV0dXJu IDA7DQogfQ0KIA0KLXN0YXRpYyBpbnQNCitpbnQNCiByYXdfdWRpc2Nvbm5l Y3Qoc3RydWN0IHNvY2tldCAqc28pDQogew0KIAlzdHJ1Y3QgcmF3Y2IgKnJw ID0gc290b3Jhd2NiKHNvKTsNCkBAIC0yMDcsNyArMjA3LDcgQEAgcmF3X3Vk aXNjb25uZWN0KHN0cnVjdCBzb2NrZXQgKnNvKQ0KIA0KIC8qIHBydV9saXN0 ZW4gaXMgRU9QTk9UU1VQUCAqLw0KIA0KLXN0YXRpYyBpbnQNCitpbnQNCiBy YXdfdXBlZXJhZGRyKHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2Fk ZHIgKipuYW0pDQogew0KIAlzdHJ1Y3QgcmF3Y2IgKnJwID0gc290b3Jhd2Ni KHNvKTsNCkBAIC0yMjQsNyArMjI0LDcgQEAgcmF3X3VwZWVyYWRkcihzdHJ1 Y3Qgc29ja2V0ICpzbywgc3RydWN0IA0KIC8qIHBydV9yY3ZkIGlzIEVPUE5P VFNVUFAgKi8NCiAvKiBwcnVfcmN2b29iIGlzIEVPUE5PVFNVUFAgKi8NCiAN Ci1zdGF0aWMgaW50DQoraW50DQogcmF3X3VzZW5kKHN0cnVjdCBzb2NrZXQg KnNvLCBpbnQgZmxhZ3MsIHN0cnVjdCBtYnVmICptLA0KIAkgIHN0cnVjdCBz b2NrYWRkciAqbmFtLCBzdHJ1Y3QgbWJ1ZiAqY29udHJvbCwgc3RydWN0IHBy b2MgKnApDQogew0KQEAgLTI2Nyw3ICsyNjcsNyBAQCByZWxlYXNlOg0KIA0K IC8qIHBydV9zZW5zZSBpcyBudWxsICovDQogDQotc3RhdGljIGludA0KK2lu dA0KIHJhd191c2h1dGRvd24oc3RydWN0IHNvY2tldCAqc28pDQogew0KIAlz dHJ1Y3QgcmF3Y2IgKnJwID0gc290b3Jhd2NiKHNvKTsNCkBAIC0yNzgsNyAr Mjc4LDcgQEAgcmF3X3VzaHV0ZG93bihzdHJ1Y3Qgc29ja2V0ICpzbykNCiAJ cmV0dXJuIDA7DQogfQ0KIA0KLXN0YXRpYyBpbnQNCitpbnQNCiByYXdfdXNv Y2thZGRyKHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKipu YW0pDQogew0KIAlzdHJ1Y3QgcmF3Y2IgKnJwID0gc290b3Jhd2NiKHNvKTsN CkluZGV4OiBydHNvY2suYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC9ob21lL2N2cy9hY3MvYmFzZS9zcmMvc3lzL25ldC9ydHNvY2su Yyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMS4xLjINCmRpZmYgLXUgLXAg LXIxLjEuMS4yIHJ0c29jay5jDQotLS0gcnRzb2NrLmMJMjMgQXVnIDIwMDIg MDQ6MTA6MjcgLTAwMDAJMS4xLjEuMg0KKysrIHJ0c29jay5jCTE0IERlYyAy MDAyIDA0OjE3OjU1IC0wMDAwDQpAQCAtODgsMTUgKzg4LDYgQEAgc3RhdGlj IHZvaWQJIHJ0X3NldG1ldHJpY3MgX19QKCh1X2xvbmcsIA0KICAqIEl0IHJl YWxseSBkb2Vzbid0IG1ha2UgYW55IHNlbnNlIGF0IGFsbCBmb3IgdGhpcyBj b2RlIHRvIHNoYXJlIG11Y2gNCiAgKiB3aXRoIHJhd191c3JyZXEuYywgc2lu Y2UgaXRzIGZ1bmN0aW9uYWxpdHkgaXMgc28gcmVzdHJpY3RlZC4gIFhYWA0K ICAqLw0KLXN0YXRpYyBpbnQNCi1ydHNfYWJvcnQoc3RydWN0IHNvY2tldCAq c28pDQotew0KLQlpbnQgcywgZXJyb3I7DQotCXMgPSBzcGxuZXQoKTsNCi0J ZXJyb3IgPSByYXdfdXNycmVxcy5wcnVfYWJvcnQoc28pOw0KLQlzcGx4KHMp Ow0KLQlyZXR1cm4gZXJyb3I7DQotfQ0KIA0KIC8qIHBydV9hY2NlcHQgaXMg RU9QTk9UU1VQUCAqLw0KIA0KQEAgLTE1MCwyNiArMTQxLDYgQEAgcnRzX2F0 dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50IHByb3RvLA0KIAlyZXR1cm4g MDsNCiB9DQogDQotc3RhdGljIGludA0KLXJ0c19iaW5kKHN0cnVjdCBzb2Nr ZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm5hbSwgc3RydWN0IHByb2MgKnAp DQotew0KLQlpbnQgcywgZXJyb3I7DQotCXMgPSBzcGxuZXQoKTsNCi0JZXJy b3IgPSByYXdfdXNycmVxcy5wcnVfYmluZChzbywgbmFtLCBwKTsgLyogeHh4 IGp1c3QgRUlOVkFMICovDQotCXNwbHgocyk7DQotCXJldHVybiBlcnJvcjsN Ci19DQotDQotc3RhdGljIGludA0KLXJ0c19jb25uZWN0KHN0cnVjdCBzb2Nr ZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm5hbSwgc3RydWN0IHByb2MgKnAp DQotew0KLQlpbnQgcywgZXJyb3I7DQotCXMgPSBzcGxuZXQoKTsNCi0JZXJy b3IgPSByYXdfdXNycmVxcy5wcnVfY29ubmVjdChzbywgbmFtLCBwKTsgLyog WFhYIGp1c3QgRUlOVkFMICovDQotCXNwbHgocyk7DQotCXJldHVybiBlcnJv cjsNCi19DQotDQogLyogcHJ1X2Nvbm5lY3QyIGlzIEVPUE5PVFNVUFAgKi8N CiAvKiBwcnVfY29udHJvbCBpcyBFT1BOT1RTVVBQICovDQogDQpAQCAtMjAy LDY5ICsxNzMsMTYgQEAgcnRzX2RldGFjaChzdHJ1Y3Qgc29ja2V0ICpzbykN CiAJcmV0dXJuIGVycm9yOw0KIH0NCiANCi1zdGF0aWMgaW50DQotcnRzX2Rp c2Nvbm5lY3Qoc3RydWN0IHNvY2tldCAqc28pDQotew0KLQlpbnQgcywgZXJy b3I7DQotCXMgPSBzcGxuZXQoKTsNCi0JZXJyb3IgPSByYXdfdXNycmVxcy5w cnVfZGlzY29ubmVjdChzbyk7DQotCXNwbHgocyk7DQotCXJldHVybiBlcnJv cjsNCi19DQotDQogLyogcHJ1X2xpc3RlbiBpcyBFT1BOT1RTVVBQICovDQot DQotc3RhdGljIGludA0KLXJ0c19wZWVyYWRkcihzdHJ1Y3Qgc29ja2V0ICpz bywgc3RydWN0IHNvY2thZGRyICoqbmFtKQ0KLXsNCi0JaW50IHMsIGVycm9y Ow0KLQlzID0gc3BsbmV0KCk7DQotCWVycm9yID0gcmF3X3VzcnJlcXMucHJ1 X3BlZXJhZGRyKHNvLCBuYW0pOw0KLQlzcGx4KHMpOw0KLQlyZXR1cm4gZXJy b3I7DQotfQ0KLQ0KIC8qIHBydV9yY3ZkIGlzIEVPUE5PVFNVUFAgKi8NCiAv KiBwcnVfcmN2b29iIGlzIEVPUE5PVFNVUFAgKi8NCi0NCi1zdGF0aWMgaW50 DQotcnRzX3NlbmQoc3RydWN0IHNvY2tldCAqc28sIGludCBmbGFncywgc3Ry dWN0IG1idWYgKm0sIHN0cnVjdCBzb2NrYWRkciAqbmFtLA0KLQkgc3RydWN0 IG1idWYgKmNvbnRyb2wsIHN0cnVjdCBwcm9jICpwKQ0KLXsNCi0JaW50IHMs IGVycm9yOw0KLQlzID0gc3BsbmV0KCk7DQotCWVycm9yID0gcmF3X3VzcnJl cXMucHJ1X3NlbmQoc28sIGZsYWdzLCBtLCBuYW0sIGNvbnRyb2wsIHApOw0K LQlzcGx4KHMpOw0KLQlyZXR1cm4gZXJyb3I7DQotfQ0KLQ0KIC8qIHBydV9z ZW5zZSBpcyBudWxsICovDQogDQotc3RhdGljIGludA0KLXJ0c19zaHV0ZG93 bihzdHJ1Y3Qgc29ja2V0ICpzbykNCi17DQotCWludCBzLCBlcnJvcjsNCi0J cyA9IHNwbG5ldCgpOw0KLQllcnJvciA9IHJhd191c3JyZXFzLnBydV9zaHV0 ZG93bihzbyk7DQotCXNwbHgocyk7DQotCXJldHVybiBlcnJvcjsNCi19DQot DQotc3RhdGljIGludA0KLXJ0c19zb2NrYWRkcihzdHJ1Y3Qgc29ja2V0ICpz bywgc3RydWN0IHNvY2thZGRyICoqbmFtKQ0KLXsNCi0JaW50IHMsIGVycm9y Ow0KLQlzID0gc3BsbmV0KCk7DQotCWVycm9yID0gcmF3X3VzcnJlcXMucHJ1 X3NvY2thZGRyKHNvLCBuYW0pOw0KLQlzcGx4KHMpOw0KLQlyZXR1cm4gZXJy b3I7DQotfQ0KLQ0KIHN0YXRpYyBzdHJ1Y3QgcHJfdXNycmVxcyByb3V0ZV91 c3JyZXFzID0gew0KLQlydHNfYWJvcnQsIHBydV9hY2NlcHRfbm90c3VwcCwg cnRzX2F0dGFjaCwgcnRzX2JpbmQsIHJ0c19jb25uZWN0LA0KLQlwcnVfY29u bmVjdDJfbm90c3VwcCwgcHJ1X2NvbnRyb2xfbm90c3VwcCwgcnRzX2RldGFj aCwgcnRzX2Rpc2Nvbm5lY3QsDQotCXBydV9saXN0ZW5fbm90c3VwcCwgcnRz X3BlZXJhZGRyLCBwcnVfcmN2ZF9ub3RzdXBwLCBwcnVfcmN2b29iX25vdHN1 cHAsDQotCXJ0c19zZW5kLCBwcnVfc2Vuc2VfbnVsbCwgcnRzX3NodXRkb3du LCBydHNfc29ja2FkZHIsDQorCXJhd191YWJvcnQsIHBydV9hY2NlcHRfbm90 c3VwcCwgcnRzX2F0dGFjaCwgcmF3X3ViaW5kLCByYXdfdWNvbm5lY3QsDQor CXBydV9jb25uZWN0Ml9ub3RzdXBwLCBwcnVfY29udHJvbF9ub3RzdXBwLCBy dHNfZGV0YWNoLCByYXdfdWRpc2Nvbm5lY3QsDQorCXBydV9saXN0ZW5fbm90 c3VwcCwgcmF3X3VwZWVyYWRkciwgcHJ1X3JjdmRfbm90c3VwcCwgcHJ1X3Jj dm9vYl9ub3RzdXBwLA0KKwlyYXdfdXNlbmQsIHBydV9zZW5zZV9udWxsLCBy YXdfdXNodXRkb3duLCByYXdfdXNvY2thZGRyLA0KIAlzb3NlbmQsIHNvcmVj ZWl2ZSwgc29wb2xsDQogfTsNCiANCg== --0-553016530-1039839708=:33726-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 13 21:57:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D90C937B401 for ; Fri, 13 Dec 2002 21:57:49 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A5B043ED1 for ; Fri, 13 Dec 2002 21:57:48 -0800 (PST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:3d7e:5c59:f943:4f38]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gBE5vbR65566; Sat, 14 Dec 2002 14:57:37 +0900 (JST) Date: Sat, 14 Dec 2002 14:57:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Jeff W. Boote" Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 udp socket bind: EADDRNOTAVAIL? In-Reply-To: <3DFA268D.A073F0F3@internet2.edu> References: <3DFA268D.A073F0F3@internet2.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 35 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 Dec 2002 11:27:25 -0700, >>>>> "Jeff W. Boote" said: > Questions: > 1. The comment says broken. Anyone know why the comment says that? (The > IPv4 version of bind says the same thing...) I don't know...perhaps this comment was copied from the IPv4 code. > 2. This system is auto configuring this address... Is it possible that > I'm just having this problem because the system is reconfiguring the > address at this time? (I must admit that I have not looked at the auto > configuration stuff.) I don't think so. Even if the system is reconfiguring global addresses, it should have other stable addresses, such as link-local and loopback ones. So the address list starting at in6_ifaddr should rarely be empty. I suspect the EADDRNOTAVAIL error comes from a different part of the kernel (or the kernel has a serious bug). If you give us more information, we may be able to diagnose the problem. The information can include: - the result of ifconfig -a inet6 - the result of netstat -anl -f inet6 - the IPv6 address (and port) being bound in the error case - the (related part of the) source code of the daemon In any case, you should provide the FreeBSD version of your system. 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 Sat Dec 14 16:17:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D74737B401 for ; Sat, 14 Dec 2002 16:17:07 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3911643EB2 for ; Sat, 14 Dec 2002 16:17:06 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 741757B470; Sat, 14 Dec 2002 19:17:00 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id CF7AD7B46E; Sat, 14 Dec 2002 19:16:57 -0500 (EST) Message-ID: <3DFBC9F9.9BEAA413@internet2.edu> Date: Sat, 14 Dec 2002 17:16:57 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: JINMEI@internet2.edu, Tatuya@internet2.edu, /@internet2.edu, "$B?\"@L@C#:Hnet2.edu?fetch>UID>|INBOX>9535"@internet2.edu Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 udp socket bind: EADDRNOTAVAIL? References: <3DFA268D.A073F0F3@internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 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 JINMEI Tatuya / $B?@L@C#:H(B wrote: > > 2. This system is auto configuring this address... Is it possible that > > I'm just having this problem because the system is reconfiguring the > > address at this time? (I must admit that I have not looked at the auto > > configuration stuff.) > > I don't think so. Even if the system is reconfiguring global > addresses, it should have other stable addresses, such as link-local > and loopback ones. So the address list starting at in6_ifaddr should > rarely be empty. > > I suspect the EADDRNOTAVAIL error comes from a different part of the > kernel (or the kernel has a serious bug). I *may* have found my problem. (Since this has been intermittent I will need to let my fix run for a while longer before I'm convinced.) In my code, I am creating the struct sockaddr directly. (not using getaddrinfo or anything like that.) This is because the "control" connection was requesting a specific numeric address for the udp "test". I believe my problem may have been that I had the sa_len value set to 0. (It was zero because I memset the entire structure before starting, and I was attempting to write portable code - and that member is not portable. In any case, I have determined that getnameinfo on FreeBSD doesn't work unless it is set. So it wouldn't surprise me if bind failed in this case as well.) I have modified my code to set the sa_len field. Incidentally - I'm setting the flowinfo and scope_id fields to 0 as well. I believe that is the correct thing to do. At least it looked like that was correct the last time I checked, but I admit I have not looked at the latest version of 2553bis to see if this has changed. > If you give us more > information, we may be able to diagnose the problem. The information > can include: Oops. Sorry - I definitely should have done that in the first message. This gets kind of long, but I don't know of any way to make it shorter: I'm running a 4.6 kernel on that system. > - the result of ifconfig -a inet6 owamp@nms2-ipls:~[510]$ ifconfig -a inet6 sk0: flags=8843 mtu 1500 inet6 fe80::200:5aff:fe9a:6a3c%sk0 prefixlen 64 scopeid 0x1 inet6 2001:468:12:3:200:5aff:fe9a:6a3c prefixlen 64 autoconf fxp0: flags=8843 mtu 1500 inet6 fe80::203:47ff:fef1:5071%fxp0 prefixlen 64 scopeid 0x2 inet6 2001:468:12:2:203:47ff:fef1:5071 prefixlen 64 autoconf fxp1: flags=8802 mtu 1500 ifconfig: fxp1 has no inet6 interface address! lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 ppp0: flags=8010 mtu 1500 ifconfig: ppp0 has no inet6 interface address! sl0: flags=c010 mtu 552 ifconfig: sl0 has no inet6 interface address! faith0: flags=8002 mtu 1500 ifconfig: faith0 has no inet6 interface address! > - the result of netstat -anl -f inet6 (Of course, I'm not currently having the problem... Hmm - perhaps I should set something up to run netstat automatically if/when this happens again.) owamp@nms2-ipls:~[512]$ netstat -anl -f inet6 Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.4822 2001:468:f:2:203:47ff:fef1:4daf.1782 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.4822 2001:468:15:2:203:47ff:fef1:505d.2790 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.4822 2001:468:f:2:203:47ff:fef1:4daf.1780 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.4822 2001:468:15:2:203:47ff:fef1:505d.2788 ESTABLISHED tcp46 0 0 *.4822 *.* LISTEN tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.2971 2001:468:f:2:203:47ff:fef1:4daf.4822 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.2970 2001:468:f:2:203:47ff:fef1:4daf.4822 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.2920 2001:468:15:2:203:47ff:fef1:505d.4822 ESTABLISHED tcp6 0 0 2001:468:12:2:203:47ff:fef1:5071.2917 2001:468:15:2:203:47ff:fef1:505d.4822 ESTABLISHED tcp46 0 0 *.22 *.* LISTEN udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.1366 2001:468:f:2:203:47ff:fef1:4daf.1297 udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.3754 *.* udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.3752 *.* udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.3750 *.* udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.3747 *.* udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.3162 2001:468:15:2:203:47ff:fef1:505d.2156 udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.2888 2001:468:f:2:203:47ff:fef1:4daf.1283 udp6 0 0 2001:468:12:2:203:47ff:fef1:5071.4675 2001:468:15:2:203:47ff:fef1:505d.2137 udp6 0 0 *.514 *.* > - the IPv6 address (and port) being bound in the error case (udp) Addr: 2001:468:12:2:203:47ff:fef1:5071 Port: 0 (I'm trying to allocate a port.) > - the (related part of the) source code of the daemon Ok... to make it just related will take some annotating: # This is the part of the daemon where I initialize the # sockaddr structures. # sender and receiver are pointers to sockaddr_storage variables # that have been initialized with 0 values. # (This function reads a request off the network and is decoding # the message. I'm only including the part that decodes the # address.) # The last part with the HAVE_STRUCT_SOCKADDR_SA_LEN I just added, # and have not seen errors since. # switch(*ipvn){ struct sockaddr_in *saddr4; #ifdef AF_INET6 struct sockaddr_in6 *saddr6; case 6: if(*socklen < sizeof(struct sockaddr_in6)){ OWPError(ctx,OWPErrFATAL,OWPErrINVALID, "_OWPDecodeV3TestRequest:socklen not big enough (%d < %d)", *socklen,sizeof(struct sockaddr_in6)); *socklen = 0; return OWPErrFATAL; } *socklen = sizeof(struct sockaddr_in6); /* sender address and port */ saddr6 = (struct sockaddr_in6*)sender; saddr6->sin6_family = AF_INET6; memcpy(saddr6->sin6_addr.s6_addr,&buf[4],16); if(*server_conf_sender) saddr6->sin6_port = 0; else saddr6->sin6_port = *(u_int16_t*)&buf[36]; /* receiver address and port */ saddr6 = (struct sockaddr_in6*)receiver; saddr6->sin6_family = AF_INET6; memcpy(saddr6->sin6_addr.s6_addr,&buf[20],16); if(*server_conf_receiver) saddr6->sin6_port = 0; else saddr6->sin6_port = *(u_int16_t*)&buf[38]; break; #endif case 4: if(*socklen < sizeof(struct sockaddr_in)){ *socklen = 0; OWPError(ctx,OWPErrFATAL,OWPErrINVALID, "_OWPDecodeV3TestRequest:socklen not big enough (%d < %d)", *socklen,sizeof(struct sockaddr_in)); return OWPErrFATAL; } *socklen = sizeof(struct sockaddr_in); /* sender address and port */ saddr4 = (struct sockaddr_in*)sender; saddr4->sin_family = AF_INET; saddr4->sin_addr.s_addr = *(u_int32_t*)&buf[4]; if(*server_conf_sender) saddr4->sin_port = 0; else saddr4->sin_port = *(u_int16_t*)&buf[36]; /* receiver address and port */ saddr4 = (struct sockaddr_in*)receiver; saddr4->sin_family = AF_INET; saddr4->sin_addr.s_addr = *(u_int32_t*)&buf[20]; if(*server_conf_receiver) saddr4->sin_port = 0; else saddr4->sin_port = *(u_int16_t*)&buf[38]; break; default: OWPError(ctx,OWPErrFATAL,OWPErrINVALID, "_OWPDecodeV3TestRequest:Unsupported IP version (%d)", *ipvn); return OWPErrFATAL; } #ifdef HAVE_STRUCT_SOCKADDR_SA_LEN sender->sa_len = receiver->sa_len = *socklen; #endif # # Ok - a bunch of things happen between the allocation # and the creation of the udp socket. (Policy checks and # the like.) localaddr is a wrapper structure that encodes # all the addr information that is needed to create the # socket in a non-addr specific way. (almost an addrinfo # structure.) # Now this is the part where I actually use that sockaddr. # localaddr->saddr is either sender or receiver from the # initialization function depending upon the context of # the actual request. (In the error case it is the sender, # but that is only because that is the case I've been # testing - there is no difference in the two cases until # after the socket is bound.) /* * Create the socket. */ ep->sockfd = socket(localaddr->saddr->sa_family,localaddr->so_type, localaddr->so_protocol); if(ep->sockfd<0){ OWPError(ctx,OWPErrFATAL,OWPErrUNKNOWN,"socket(): %M"); goto error; } /* * bind it to the local address getting an ephemeral port number. */ if(bind(ep->sockfd,localaddr->saddr,localaddr->saddrlen) != 0){ OWPError(ctx,OWPErrFATAL,OWPErrUNKNOWN, "bind([%s]:%s): %M",localaddr->node,localaddr->port); goto error; } # # And this is an example of the error messages I have been seeing: Nov 26 16:30:10 nms2-ipls owampd[87121]: FILE=endpoint.c, LINE=437, bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address Nov 26 16:30:12 nms2-ipls owampd[87134]: FILE=endpoint.c, LINE=437, bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address Nov 26 16:30:13 nms2-ipls owampd[87121]: FILE=endpoint.c, LINE=437, bind([2001:468:12:2:203:47ff:fef1:5071]:0): Can't assign requested address Now, when this happens, it happens for about 10 seconds - and then things start working again. So, how likely is it that not initializing sa_len was causing this? (My ipv4 tests never had problems, and I would think they would behave the same in this particular regard.) (If anyone has actually read down this far, I truely thank you.) Thanks, jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 14 18:45:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0AD237B401 for ; Sat, 14 Dec 2002 18:45:36 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C27843ED4 for ; Sat, 14 Dec 2002 18:45:36 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Dec 2002 21:45:35 -0500 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: struct inpcb, INET6 Date: Sat, 14 Dec 2002 21:45:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Is there a reason that struct inpcb doesn't have an #ifdef INET6 around struct { /* IP options */ struct mbuf *inp6_options; /* IP6 options for outgoing packets */ struct ip6_pktopts *inp6_outputopts; /* IP multicast options */ struct ip6_moptions *inp6_moptions; /* ICMPv6 code type filter */ struct icmp6_filter *inp6_icmp6filt; /* IPV6_CHECKSUM setsockopt */ int inp6_cksum; u_short inp6_ifindex; short inp6_hops; u_int8_t inp6_hlim; } inp_depend6; ? Its 25 bytes per connection. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message