From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 01:35:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F2F116A4CE; Mon, 7 Jun 2004 01:35:56 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 882A243D55; Sun, 6 Jun 2004 18:35:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004060701355501400i4q3me>; Mon, 7 Jun 2004 01:35:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA15412; Sun, 6 Jun 2004 18:35:53 -0700 (PDT) Date: Sun, 6 Jun 2004 18:35:51 -0700 (PDT) From: Julian Elischer To: FreeBSD current users Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 01:35:56 -0000 If you don't know or care about netgraph metadata (e.g. packet priority) then this shouldn't worry you. We are changing the netgraph metadata facility (in which arbitrary metadata can be sent with a packet through processing) to use the mbuf TAG facility that has been imported by sam. Netgraph tags will use different cookies to the standard set of tags imported with the code, so they will live in a separate namespace, however they will be handled during GC and manipulation by the standard tag handling code (Thanks to Sam for giving us the cookie facility). In the checked in code there are only a couple of users of metadata, but there may be 3rd parties out there that use it. If so the authors should contact me as soon as possible to co-ordinate the changeover. For example the BW_MAN bandwith manager uses metadata to tag packets selected by its ipfw netgraph node. Currently the biggest user of metadata is the frame relay LMI node that tags LMI packets with a higher priority in order to meet timing constraints given by the standards. In addition the ng_ksocket node adds info into metadata and I suspect there are people using that. julian From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:17:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 263C016A4CE; Mon, 7 Jun 2004 07:17:14 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 057EB43D48; Mon, 7 Jun 2004 07:17:14 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i577H2vw018057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 11:17:02 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i577H2jC018056; Mon, 7 Jun 2004 11:17:02 +0400 (MSD) Date: Mon, 7 Jun 2004 11:17:01 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20040607071701.GC17986@cell.sick.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:17:15 -0000 On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: J> In addition the ng_ksocket node adds info into metadata and I suspect J> there are people using that. Since ng_ksocket tags packets for itself only, we can safely change it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:36:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD99A16A4CE; Mon, 7 Jun 2004 07:36:01 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BD4B43D46; Mon, 7 Jun 2004 07:36:01 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040607073558012001h8a8e>; Mon, 7 Jun 2004 07:35:59 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA19362; Mon, 7 Jun 2004 00:35:58 -0700 (PDT) Date: Mon, 7 Jun 2004 00:35:56 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607071701.GC17986@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:36:01 -0000 On Mon, 7 Jun 2004, Gleb Smirnoff wrote: > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> In addition the ng_ksocket node adds info into metadata and I suspect > J> there are people using that. > > Since ng_ksocket tags packets for itself only, we can safely change it. Since I did not add that code I am not very familiar with it or who uses it. (or why) if this is true than yes we can do this.. > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:38:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 818C116A4CE; Mon, 7 Jun 2004 07:38:54 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C51E943D2F; Mon, 7 Jun 2004 07:38:53 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i577iVQr096502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 10:44:32 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i577cCDI000515; Mon, 7 Jun 2004 10:38:12 +0300 (EEST) (envelope-from ru) Date: Mon, 7 Jun 2004 10:38:12 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040607073812.GA339@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20040607071701.GC17986@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:38:54 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:17:01AM +0400, Gleb Smirnoff wrote: > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> In addition the ng_ksocket node adds info into metadata and I suspect > J> there are people using that. >=20 > Since ng_ksocket tags packets for itself only, we can safely change it. >=20 I use this feature in one proprietary module (need to send/recevive UDP datagrams to/from different destinations). Cheers,=20 --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxBtkqRfpzJluFF4RAmvDAJ4mmauyH2vfh4VpQj2Mk+dZEnrYVgCdFAZx B1AoVPc7JEPMs1XaloOdp3I= =BaUJ -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:40:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5833316A4CE; Mon, 7 Jun 2004 07:40:43 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98AE143D39; Mon, 7 Jun 2004 07:40:42 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i577ebvw018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 11:40:38 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i577ebrw018302; Mon, 7 Jun 2004 11:40:37 +0400 (MSD) Date: Mon, 7 Jun 2004 11:40:37 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20040607074037.GB18232@cell.sick.ru> References: <20040607071701.GC17986@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:40:43 -0000 On Mon, Jun 07, 2004 at 12:35:56AM -0700, Julian Elischer wrote: J> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: J> > J> In addition the ng_ksocket node adds info into metadata and I suspect J> > J> there are people using that. J> > J> > Since ng_ksocket tags packets for itself only, we can safely change it. J> J> Since I did not add that code I am not very familiar with it or who uses J> it. (or why) J> J> if this is true than yes we can do this.. It is used only on UDP connection, to send replies back to where the original packets came from. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:44:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DADD716A4CE; Mon, 7 Jun 2004 07:44:15 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 204C243D4C; Mon, 7 Jun 2004 07:44:15 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i577iAvw018346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 11:44:10 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i577iAx5018345; Mon, 7 Jun 2004 11:44:10 +0400 (MSD) Date: Mon, 7 Jun 2004 11:44:10 +0400 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20040607074410.GC18232@cell.sick.ru> References: <20040607071701.GC17986@cell.sick.ru> <20040607073812.GA339@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040607073812.GA339@ip.net.ua> User-Agent: Mutt/1.5.6i cc: Julian Elischer cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:44:16 -0000 On Mon, Jun 07, 2004 at 10:38:12AM +0300, Ruslan Ermilov wrote: R> On Mon, Jun 07, 2004 at 11:17:01AM +0400, Gleb Smirnoff wrote: R> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: R> > J> In addition the ng_ksocket node adds info into metadata and I suspect R> > J> there are people using that. R> > R> > Since ng_ksocket tags packets for itself only, we can safely change it. R> > R> I use this feature in one proprietary module (need to send/recevive R> UDP datagrams to/from different destinations). Does your module reads/writes meta? Or just forwards the meta? If it just forwards meta, does it allocate new mbuf? If it does, then you should copy tag from old mbuf to a new one. If it does not allocate new mbuf, than our ng_ksocket change won't break your module. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 07:53:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EC2A16A4CE for ; Mon, 7 Jun 2004 07:53:17 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A53E043D1F for ; Mon, 7 Jun 2004 07:53:16 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i577xHCG098896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 10:59:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i577qwuM000680; Mon, 7 Jun 2004 10:52:58 +0300 (EEST) (envelope-from ru) Date: Mon, 7 Jun 2004 10:52:58 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040607075258.GA642@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> <20040607073812.GA339@ip.net.ua> <20040607074410.GC18232@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20040607074410.GC18232@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Julian Elischer cc: net@FreeBSD.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:53:17 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:44:10AM +0400, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 10:38:12AM +0300, Ruslan Ermilov wrote: > R> On Mon, Jun 07, 2004 at 11:17:01AM +0400, Gleb Smirnoff wrote: > R> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > R> > J> In addition the ng_ksocket node adds info into metadata and I sus= pect > R> > J> there are people using that. > R> >=20 > R> > Since ng_ksocket tags packets for itself only, we can safely change = it. > R> >=20 > R> I use this feature in one proprietary module (need to send/recevive > R> UDP datagrams to/from different destinations). >=20 > Does your module reads/writes meta? >=20 It does, in its "rcvdata" method: NG_FREE_META(meta); len =3D sizeof(*meta) + sizeof(*mhead) + sizeof(*sin); MALLOC(meta, meta_p, len, M_NETGRAPH, M_NOWAIT | M_ZERO); if (meta =3D=3D NULL) { NG_FREE_M(m); return (ENOMEM); } ... Yes, the change will break it. No, I'm not opposed to a change. I was just commenting on the "for itself" bit, it's not true. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxB7aqRfpzJluFF4RAm8fAJ9L/Iyt+NzOiwDQ7JJDBr1LtajPJwCcDxt9 +nFN+L2atAGZV2RgYiFG96U= =1Ivc -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 10:00:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67A4216A4EB for ; Mon, 7 Jun 2004 10:00:12 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B238143D45 for ; Mon, 7 Jun 2004 10:00:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 2A4BC1FFDD6 for ; Mon, 7 Jun 2004 12:00:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 38B261FFDD4; Mon, 7 Jun 2004 12:00:07 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 19C2C154E5; Mon, 7 Jun 2004 09:59:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0F13815329 for ; Mon, 7 Jun 2004 09:59:56 +0000 (UTC) Date: Mon, 7 Jun 2004 09:59:55 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-net@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: STM-1/STM-4 cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:00:12 -0000 Hi, does anyone know of any STM-1/STM-4 cards supported under FreeBSD that can do RFC 2615 PPP over SDH ? Thanks in advance. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 11:02:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6042316A568 for ; Mon, 7 Jun 2004 11:02:04 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD4343D5C for ; Mon, 7 Jun 2004 11:02:04 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i57B23gx043485 for ; Mon, 7 Jun 2004 11:02:03 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i57B22qP043479 for freebsd-net@freebsd.org; Mon, 7 Jun 2004 11:02:02 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Jun 2004 11:02:02 GMT Message-Id: <200406071102.i57B22qP043479@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:02:04 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 14:11:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2885216A4CE for ; Mon, 7 Jun 2004 14:11:39 +0000 (GMT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A13643D41 for ; Mon, 7 Jun 2004 14:11:38 +0000 (GMT) (envelope-from root@pukruppa.de) Received: (qmail 32454 invoked by uid 513); 7 Jun 2004 14:14:32 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.666893 secs); 07 Jun 2004 14:14:32 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 7 Jun 2004 14:14:31 -0000 Date: Mon, 7 Jun 2004 16:11:47 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Julian Elischer In-Reply-To: Message-ID: <20040607160206.G854@pukruppa.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 14:11:39 -0000 Hi! Sorry for topposting, but I don't know if this has got something to do with your changes: I am trying to rebuild my -CURRENT system now for some days and keep receiving panic messages from ng_ppoe like this panic NG_MKMESSAGE() with how=M_DONTWAIT(1) at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c ... netgraph/pppoe is used by ppp to connect to my ISP . My last working kernel was built on May 31 . Thanks, if you know how to repair this. Uli. On Sun, 6 Jun 2004, Julian Elischer wrote: > > If you don't know or care about netgraph metadata (e.g. packet priority) > then this shouldn't worry you. > > We are changing the netgraph metadata facility (in which arbitrary > metadata can be sent with a packet through processing) to use > the mbuf TAG facility that has been imported by sam. > > Netgraph tags will use different cookies to the standard set of > tags imported with the code, so they will live in a separate namespace, > however they will be handled during GC and manipulation by the standard > tag handling code (Thanks to Sam for giving us the cookie facility). > > In the checked in code there are only a couple of users of metadata, but > there may be 3rd parties out there that use it. If so the authors should > contact me as soon as possible to co-ordinate the changeover. > > For example the BW_MAN bandwith manager uses metadata to tag > packets selected by its ipfw netgraph node. > > Currently the biggest user of metadata is the frame relay LMI > node that tags LMI packets with a higher priority in order to meet > timing constraints given by the standards. > > In addition the ng_ksocket node adds info into metadata and I suspect > there are people using that. > > > julian > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 17:21:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6284516A4CE; Mon, 7 Jun 2004 17:21:49 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB9743D5A; Mon, 7 Jun 2004 17:21:48 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i57HLYvw022790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 21:21:34 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i57HLXTA022789; Mon, 7 Jun 2004 21:21:33 +0400 (MSD) Date: Mon, 7 Jun 2004 21:21:32 +0400 From: Gleb Smirnoff To: Peter Ulrich Kruppa , Bosko Milekic Message-ID: <20040607172132.GA22717@cell.sick.ru> References: <20040607160206.G854@pukruppa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040607160206.G854@pukruppa.net> User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:21:49 -0000 On Mon, Jun 07, 2004 at 04:11:47PM +0200, Peter Ulrich Kruppa wrote: P> Sorry for topposting, but I don't know if this has got something P> to do with your changes: P> I am trying to rebuild my -CURRENT system now for some days and P> keep receiving panic messages from ng_ppoe P> like this P> P> panic NG_MKMESSAGE() with how=M_DONTWAIT(1) P> at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c P> ... P> P> netgraph/pppoe is used by ppp to connect to my ISP . P> My last working kernel was built on May 31 . P> P> Thanks, if you know how to repair this. Seems like you problem is caused (indirectly) by mbuma import. See http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html Perhaps Bosko has more comments. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 20:58:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C585616A4CE; Mon, 7 Jun 2004 20:58:28 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i57KwS0V021444; Mon, 7 Jun 2004 16:58:28 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i57KwRe3021443; Mon, 7 Jun 2004 16:58:27 -0400 (EDT) (envelope-from green) Date: Mon, 7 Jun 2004 16:58:27 -0400 From: Brian Feldman To: Gleb Smirnoff Message-ID: <20040607205827.GD20308@green.homeunix.org> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607172132.GA22717@cell.sick.ru> User-Agent: Mutt/1.5.6i cc: Julian Elischer cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:58:29 -0000 On Mon, Jun 07, 2004 at 09:21:32PM +0400, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:11:47PM +0200, Peter Ulrich Kruppa wrote: > P> Sorry for topposting, but I don't know if this has got something > P> to do with your changes: > P> I am trying to rebuild my -CURRENT system now for some days and > P> keep receiving panic messages from ng_ppoe > P> like this > P> > P> panic NG_MKMESSAGE() with how=M_DONTWAIT(1) > P> at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c > P> ... > P> > P> netgraph/pppoe is used by ppp to connect to my ISP . > P> My last working kernel was built on May 31 . > P> > P> Thanks, if you know how to repair this. > > Seems like you problem is caused (indirectly) by mbuma import. See > > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > > Perhaps Bosko has more comments. Please try removing both KASSERT() calls from NG_MKMESSAGE() in src/sys/sys/ng_message.h, and then rebuild (and unload and reload) all netgraph modules. The KASSERT() lines appear to be entirely bogus now. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 21:47:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0364116A4D1; Mon, 7 Jun 2004 21:47:02 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CF743D1D; Mon, 7 Jun 2004 21:47:01 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i57LkRvw024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 01:46:28 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i57LkRYo024406; Tue, 8 Jun 2004 01:46:27 +0400 (MSD) Date: Tue, 8 Jun 2004 01:46:27 +0400 From: Gleb Smirnoff To: Brian Feldman , Julian Elischer Message-ID: <20040607214627.GA24142@cell.sick.ru> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> <20040607205827.GD20308@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20040607205827.GD20308@green.homeunix.org> User-Agent: Mutt/1.5.6i cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:47:02 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: B> > Seems like you problem is caused (indirectly) by mbuma import. See B> > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html B> > B> > Perhaps Bosko has more comments. B> B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) B> all netgraph modules. The KASSERT() lines appear to be entirely B> bogus now. Agreed. After mbuma import the first KASSERT() definitely must be removed. Julian, take a look at this. It must be fixed ASAP. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_message.h.diff" Index: ng_message.h =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_message.h,v retrieving revision 1.22 diff -u -r1.22 ng_message.h --- ng_message.h 26 Jan 2004 14:05:31 -0000 1.22 +++ ng_message.h 7 Jun 2004 21:45:06 -0000 @@ -371,8 +371,6 @@ */ #define NG_MKMESSAGE(msg, cookie, cmdid, len, how) \ do { \ - KASSERT(!(how & M_DONTWAIT), \ - ("NG_MKMESSAGE() with how=M_DONTWAIT (%d)\n", how)); \ KASSERT(!(how & M_TRYWAIT), \ ("NG_MKMESSAGE() with how=M_TRYWAIT (%d)\n", how)); \ MALLOC((msg), struct ng_mesg *, sizeof(struct ng_mesg) \ --ZPt4rx8FFjLCG7dd-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 21:57:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3A616A4CE; Mon, 7 Jun 2004 21:57:33 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9900B43D31; Mon, 7 Jun 2004 21:57:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004060721572901500mn9r8e>; Mon, 7 Jun 2004 21:57:31 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA30085; Mon, 7 Jun 2004 14:57:30 -0700 (PDT) Date: Mon, 7 Jun 2004 14:57:29 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607214627.GA24142@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brian Feldman cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:57:33 -0000 On Tue, 8 Jun 2004, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: > B> > Seems like you problem is caused (indirectly) by mbuma import. See > B> > > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > B> > > B> > Perhaps Bosko has more comments. > B> > B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in > B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > B> all netgraph modules. The KASSERT() lines appear to be entirely > B> bogus now. > > Agreed. After mbuma import the first KASSERT() definitely must be removed. > Julian, take a look at this. It must be fixed ASAP. Messages never were done by mbuf so it's a bit puzzling what mbuma has to do with it.. however, removing the KASSERT seems appropriate. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 22:12:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA0616A4CE; Mon, 7 Jun 2004 22:12:24 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5735643D2D; Mon, 7 Jun 2004 22:12:24 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040607221215016000kcjce>; Mon, 7 Jun 2004 22:12:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA30273; Mon, 7 Jun 2004 15:12:16 -0700 (PDT) Date: Mon, 7 Jun 2004 15:12:15 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607214627.GA24142@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brian Feldman cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 22:12:24 -0000 On Tue, 8 Jun 2004, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: > B> > Seems like you problem is caused (indirectly) by mbuma import. See > B> > > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > B> > > B> > Perhaps Bosko has more comments. > B> > B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in > B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > B> all netgraph modules. The KASSERT() lines appear to be entirely > B> bogus now. > > Agreed. After mbuma import the first KASSERT() definitely must be removed. > Julian, take a look at this. It must be fixed ASAP. committed.. removed both KASSERTS > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 03:48:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE87316A4D0 for ; Tue, 8 Jun 2004 03:48:01 +0000 (GMT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id BC6D943D4C for ; Tue, 8 Jun 2004 03:48:00 +0000 (GMT) (envelope-from root@pukruppa.de) Received: (qmail 4363 invoked by uid 513); 8 Jun 2004 03:51:05 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.395539 secs); 08 Jun 2004 03:51:05 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 8 Jun 2004 03:51:04 -0000 Date: Tue, 8 Jun 2004 05:48:53 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Brian Feldman In-Reply-To: <20040607205827.GD20308@green.homeunix.org> Message-ID: <20040608054738.B1838@pukruppa.net> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> <20040607205827.GD20308@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Julian Elischer cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:48:01 -0000 On Mon, 7 Jun 2004, Brian Feldman wrote: > On Mon, Jun 07, 2004 at 09:21:32PM +0400, Gleb Smirnoff wrote: > > Please try removing both KASSERT() calls from NG_MKMESSAGE() in > src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > all netgraph modules. The KASSERT() lines appear to be entirely > bogus now. Yes, they are. Thanks to everyone. Uli. +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 03:57:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC7B516A4CE; Tue, 8 Jun 2004 03:57:27 +0000 (GMT) Received: from bspu.ab.ru (bspu.ab.ru [212.94.100.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C229743D1F; Tue, 8 Jun 2004 03:57:22 +0000 (GMT) (envelope-from swp@uni-altai.ru) Received: from bspu.secna.ru (root@bspu.secna.ru [212.192.2.193]) by bspu.ab.ru (8.12.10/8.12.10) with ESMTP id i584U2lP082494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2004 11:30:04 +0700 (NOVST) (envelope-from swp@uni-altai.ru) Received: from swp.bspu.secna.ru (swp.bspu.secna.ru [212.192.2.73]) by bspu.secna.ru (8.12.11/8.12.11) with ESMTP id i583vF6q009761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2004 10:57:15 +0700 (NOVST) (envelope-from swp@swp.bspu.secna.ru) Received: from swp.bspu.secna.ru (localhost [127.0.0.1]) by swp.bspu.secna.ru (8.12.10/8.12.10) with ESMTP id i583vE4V001037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 10:57:14 +0700 (OMSST) (envelope-from swp@swp.bspu.secna.ru) Received: (from root@localhost) by swp.bspu.secna.ru (8.12.10/8.12.10/Submit) id i583vE2J001036; Tue, 8 Jun 2004 10:57:14 +0700 (OMSST) (envelope-from swp) Date: Tue, 8 Jun 2004 10:57:14 +0700 From: Charlie Root To: archie@freebsd.org, bp@freebsd.org Message-ID: <20040608035714.GA867@swp.bspu.secna.ru> Mail-Followup-To: archie@freebsd.org, bp@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: ng_ether(4) panic with ef(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: swp@swp.pp.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:57:27 -0000 helo. if if_ef.ko was loaded before ng_ether.ko or if i have "device ef" in kernel and ng_ether.ko loaded as module then IPXrouted panic my kernel for 15-30 seconds after boot. ~# kldstat Id Refs Address Size Name 1 37 0xc0400000 34c150 kernel 2 1 0xc074d000 5e40 vesa.ko 3 1 0xc0753000 2d0c if_ef.ko 4 2 0xc0756000 1ac7c miibus.ko 5 1 0xc0771000 b2b4 if_fxp.ko 6 2 0xc077d000 1e58c snd_pcm.ko 7 1 0xc079c000 67d8 snd_es137x.ko 8 1 0xc07a3000 b8b4 random.ko 9 1 0xc07af000 51b48 acpi.ko 10 1 0xc0801000 7d40 fdc.ko 11 1 0xc0809000 3bcc speaker.ko 12 1 0xc1d81000 c7000 vinum.ko 13 2 0xc1eea000 5000 procfs.ko 14 2 0xc1eef000 6000 pseudofs.ko 15 1 0xc1efb000 6000 linprocfs.ko 16 4 0xc1f01000 19000 linux.ko 17 1 0xc1f27000 4000 sysvmsg.ko 18 1 0xc1f2f000 5000 sysvsem.ko 19 1 0xc1f34000 4000 sysvshm.ko 20 1 0xc1f52000 17000 ipl.ko 21 1 0xc1faa000 2f000 nfsclient.ko 22 1 0xc2013000 1b000 nfsserver.ko 23 1 0xc2054000 22000 usb.ko 24 1 0xc20b3000 2000 snake_saver.ko 25 1 0xc20f2000 9000 vmmon_up.ko 26 1 0xc20fb000 2000 vmnet.ko 27 1 0xc20fd000 4000 if_tap.ko 28 5 0xc2101000 12000 netgraph.ko 29 1 0xc2118000 4000 ng_socket.ko 30 2 0xc211d000 4000 ng_ether.ko 31 1 0xc2121000 3000 ng_tee.ko 32 1 0xc2125000 5000 ng_bridge.ko 33 1 0xc221c000 2000 rtc.ko ~# ifconfig fxp0: flags=9943 mtu 1500 inet 212.192.2.73 netmask 0xffffffe0 broadcast 212.192.2.95 ether 00:03:47:05:6f:5b media: Ethernet autoselect (100baseTX ) status: active fxp0f0: flags=8843 mtu 1500 ipx 10000H.347056f5b ether 00:03:47:05:6f:5b fxp0f1: flags=8843 mtu 1500 ipx 10001H.347056f5b ether 00:03:47:05:6f:5b fxp0f2: flags=8843 mtu 1500 ipx 10002H.347056f5b ether 00:03:47:05:6f:5b fxp0f3: flags=8843 mtu 1500 ipx 10003H.347056f5b ether 00:03:47:05:6f:5b lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet 10.250.0.2 netmask 0xffffffff ipx 20040605H.1H vmnet0: flags=8943 mtu 1500 ether 00:bd:a7:20:00:00 vmnet1: flags=8943 mtu 1500 ether 00:bd:b1:20:00:01 vmnet2: flags=8943 mtu 1500 ether 00:bd:bb:20:00:02 vmnet3: flags=8943 mtu 1500 ether 00:bd:c6:20:00:03 /usr/src/sys/i386/compile/aj_kernel# gdb -k kernel GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... (kgdb) file kernel.debug Reading symbols from kernel.debug...done. (kgdb) target remote /dev/uart0 Remote debugging using /dev/uart0 0xc211e5bd in ?? () warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint (kgdb) bt #0 0xc211e5bd in ?? () #1 0xc05301fe in ether_output (ifp=0x0, m=0xc16ef000, dst=0xce651b20, rt0=0x0) at ../../../net/if_ethersubr.c:303 #2 0xc0576add in ipx_outputfl (m0=0xc16ef000, ro=0x0, flags=48) at ../../../netipx/ipx_outputfl.c:134 #3 0xc0577a71 in ipx_output (ipxp=0xc200ba00, m0=0xc16ef0be) at ../../../netipx/ipx_usrreq.c:310 #4 0xc0577ec2 in ipx_send (so=0xc16e1200, flags=0, m=0xc16ef000, nam=0xc21240a0, control=0x0, td=0xc16e1200) at ../../../netipx/ipx_usrreq.c:559 #5 0xc04ff08d in sosend (so=0xc1f755a0, addr=0xc21240a0, uio=0xce651c4c, top=0xc16ef000, control=0x0, flags=4, td=0xc1d5d3c0) at ../../../kern/uipc_socket.c:715 #6 0xc05038cc in kern_sendit (td=0xc1d5d3c0, s=4, mp=0xce651cc4, flags=-1049751040, control=0xc16e1200) at ../../../kern/uipc_syscalls.c:723 #7 0xc050371e in sendit (td=0xc16e1200, s=-1049751040, mp=0xce651cc4, flags=-1049751040) at ../../../kern/uipc_syscalls.c:663 #8 0xc0503a5b in sendto (td=0xc16e1200, uap=0xc1d5d3c0) at ../../../kern/uipc_syscalls.c:784 #9 0xc060e2a0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 34, tf_esi = 34, tf_ebp = -1077940968, tf_isp = -832234124, tf_ebx = -1077941008, tf_edx = 4, tf_ecx = 1, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671938895, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941044, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 ---Type to continue, or q to quit--- #10 0xc05fefed in Xint0x80_syscall () at {standard input}:136 #11 0x0804a9ae in ?? () #12 0x0804a60e in ?? () #13 0x0804befb in ?? () #14 0x0804a019 in ?? () #15 0x08048d22 in ?? () (kgdb) bt full #0 0xc211e5bd in ?? () No symbol table info available. #1 0xc05301fe in ether_output (ifp=0x0, m=0xc16ef000, dst=0xce651b20, rt0=0x0) at ../../../net/if_ethersubr.c:303 type = 18432 error = 0 hdrcmplt = 0 esrc = "?\002\0\0аJ" edst = "яяяяяя" rt = (struct rtentry *) 0x0 eh = (struct ether_header *) 0x0 loop_copy = 0 hlen = 22 ac = (struct arpcom *) 0xc16e1200 #2 0xc0576add in ipx_outputfl (m0=0xc16ef000, ro=0x0, flags=48) at ../../../netipx/ipx_outputfl.c:134 ipx = (struct ipx *) 0xce651b20 ifp = (struct ifnet *) 0xc16e1200 error = 13 dst = (struct sockaddr_ipx *) 0x0 ipxroute = {ro_rt = 0x0, ro_dst = {sa_len = 16 '\020', sa_family = 23 '\027', sa_data = "\0\001\0\003яяяяяя\0\0\0"}} #3 0xc0577a71 in ipx_output (ipxp=0xc200ba00, m0=0xc16ef0be) at ../../../netipx/ipx_usrreq.c:310 ipx = (struct ipx *) 0xc16ef0be so = (struct socket *) 0xc1d5d3c0 len = 64 ro = (struct route *) 0xc16e1200 m = (struct mbuf *) 0xc16ef000 mprev = (struct mbuf *) 0xc1d5d3c0 #4 0xc0577ec2 in ipx_send (so=0xc16e1200, flags=0, m=0xc16ef000, nam=0xc21240a0, control=0x0, td=0xc16e1200) at ../../../netipx/ipx_usrreq.c:559 error = 0 ipxp = (struct ipxpcb *) 0xc200ba00 laddr = {x_net = {c_net = "\0\0\0", s_net = {0, 0}}, x_host = { c_host = "\0\0\0\0\0", s_host = {0, 0, 0}}, x_port = 21252} #5 0xc04ff08d in sosend (so=0xc1f755a0, addr=0xc21240a0, uio=0xce651c4c, top=0xc16ef000, control=0x0, flags=4, td=0xc1d5d3c0) at ../../../kern/uipc_socket.c:715 mp = (struct mbuf **) 0xc16ef000 m = (struct mbuf *) 0xc200ba00 space = 0 len = -1049694208 resid = 0 clen = -1040139776 error = 0 dontroute = 1 mlen = 208 atomic = 1 cow_send = 0 #6 0xc05038cc in kern_sendit (td=0xc1d5d3c0, s=4, mp=0xce651cc4, flags=-1049751040, control=0xc16e1200) at ../../../kern/uipc_syscalls.c:723 auio = {uio_iov = 0xce651cbc, uio_iovcnt = 1, uio_offset = 34, uio_resid = 0, uio_segflg = UIO_USERSPACE, uio_rw = UIO_WRITE, uio_td = 0xc1d5d3c0} iov = (struct iovec *) 0xc1d5d3c0 so = (struct socket *) 0xc1f755a0 i = -1042951232 len = 34 error = 22 ktriov = (struct iovec *) 0x0 ktruio = {uio_iov = 0x0, uio_iovcnt = -832234408, uio_offset = -4582091130731257156, uio_resid = 0, uio_segflg = 3227917479, uio_rw = 265, uio_td = 0xc21240a0} #7 0xc050371e in sendit (td=0xc16e1200, s=-1049751040, mp=0xce651cc4, flags=-1049751040) at ../../../kern/uipc_syscalls.c:663 control = (struct mbuf *) 0x0 to = (struct sockaddr *) 0xc21240a0 error = 0 #8 0xc0503a5b in sendto (td=0xc16e1200, uap=0xc1d5d3c0) at ../../../kern/uipc_syscalls.c:784 msg = {msg_name = 0xc21240a0, msg_namelen = 16, msg_iov = 0xce651cbc, msg_iovlen = 1, msg_control = 0x0, msg_controllen = 3254741312, msg_flags = 0} aiov = {iov_base = 0x804f8e0, iov_len = 0} error = -1049751040 #9 0xc060e2a0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 34, tf_esi = 34, tf_ebp = -1077940968, tf_isp = -832234124, tf_ebx = -1077941008, tf_edx = 4, tf_ecx = 1, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671938895, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941044, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 params = 0xbfbfecd0 "\004" callp = (struct sysent *) 0xc068a868 td = (struct thread *) 0xc1d5d3c0 p = (struct proc *) 0xce651cc4 orig_tf_eflags = 518 sticks = 0 error = 0 narg = 6 args = {4, 134543550, 34, 4, -1077941008, 16, 0, 1} code = 133 #10 0xc05fefed in Xint0x80_syscall () at {standard input}:136 No locals. #11 0x0804a9ae in ?? () No symbol table info available. ---Type to continue, or q to quit--- #12 0x0804a60e in ?? () No symbol table info available. #13 0x0804befb in ?? () No symbol table info available. #14 0x0804a019 in ?? () No symbol table info available. #15 0x08048d22 in ?? () No symbol table info available. (kgdb) up #1 0xc05301fe in ether_output (ifp=0x0, m=0xc16ef000, dst=0xce651b20, rt0=0x0) at ../../../net/if_ethersubr.c:303 303 if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) { (kgdb) list 298 } 299 } 300 301 /* Handle ng_ether(4) processing, if any */ 302 if (ng_ether_output_p != NULL) { 303 if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) { 304 bad: if (m != NULL) 305 m_freem(m); 306 return (error); 307 } (kgdb) p ifp $1 = (struct ifnet *) 0x0 (kgdb) up #2 0xc0576add in ipx_outputfl (m0=0xc16ef000, ro=0x0, flags=48) at ../../../netipx/ipx_outputfl.c:134 134 error = (*ifp->if_output)(ifp, m0, (kgdb) p ifp $2 = (struct ifnet *) 0xc16e1200 (kgdb) list 129 if (htons(ipx->ipx_len) <= ifp->if_mtu) { 130 ipxstat.ipxs_localout++; 131 if (ipx_copy_output) { 132 ipx_watch_output(m0, ifp); 133 } 134 error = (*ifp->if_output)(ifp, m0, 135 (struct sockaddr *)dst, ro->ro_rt); 136 goto done; 137 } else { 138 ipxstat.ipxs_mtutoosmall++; (kgdb) quit this hack prevent panic index: sys/netgraph/ng_ether.c =================================================================== RCS file: /usr/cvs/freebsd/ncvs/src/sys/netgraph/ng_ether.c,v retrieving revision 1.27 diff -u -r1.27 ng_ether.c --- sys/netgraph/ng_ether.c 31 Oct 2003 18:32:11 -0000 1.27 +++ sys/netgraph/ng_ether.c 6 Jun 2004 14:00:25 -0000 @@ -269,9 +269,36 @@ static int ng_ether_output(struct ifnet *ifp, struct mbuf **mp) { - const node_p node = IFP2NG(ifp); - const priv_p priv = NG_NODE_PRIVATE(node); + const node_p node; + const priv_p priv; int error = 0; + + if (!ifp) { + printf("%s(): ifp = 0\n", __func__); + return (EINVAL); + } + if (!(node = IFP2NG(ifp))) { + printf( "%s(): IFP2NG(ifp:%p) = 0 \\\n" + "\t{ if_xname = \"%s\", if_dname = \"%s\", " + "if_index = %d }\n", + __func__, + ifp, + ifp->if_xname, + ifp->if_dname, + ifp->if_index); + return (EINVAL); + } + if (!(priv = NG_NODE_PRIVATE(node))) { + printf( "%s(): NG_NODE_PRIVATE(IFP2NG(ifp:%p):%p) = 0 \\\n" + "\t{ if_xname = \"%s\", if_dname = \"%s\", " + "if_index = %d }\n", + __func__, + ifp, node, + ifp->if_xname, + ifp->if_dname, + ifp->if_index); + return (EINVAL); + } /* If "upper" hook not connected, let packet continue */ if (priv->upper == NULL) messages on console... ng_ether_output(): IFP2NG(ifp:0xc16e1200) = 0 \ { if_xname = "fxp0f3", if_dname = "ef", if_index = 5 } ng_ether_output(): IFP2NG(ifp:0xc16e1400) = 0 \ { if_xname = "fxp0f2", if_dname = "ef", if_index = 4 } ng_ether_output(): IFP2NG(ifp:0xc16e1600) = 0 \ { if_xname = "fxp0f1", if_dname = "ef", if_index = 3 } ng_ether_output(): IFP2NG(ifp:0xc16e1800) = 0 \ { if_xname = "fxp0f0", if_dname = "ef", if_index = 2 } dmesg & netgraph start script here... http://bspu.secna.ru/~swp/freebsd/panic/panic.1 /swp From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 04:18:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFC7316A4CE for ; Tue, 8 Jun 2004 04:18:41 +0000 (GMT) Received: from bspu.ab.ru (bspu.ab.ru [212.94.100.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E47043D5E for ; Tue, 8 Jun 2004 04:18:36 +0000 (GMT) (envelope-from swp@uni-altai.ru) Received: from bspu.secna.ru (root@bspu.secna.ru [212.192.2.193]) by bspu.ab.ru (8.12.10/8.12.10) with ESMTP id i584pJlP082798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Jun 2004 11:51:21 +0700 (NOVST) (envelope-from swp@uni-altai.ru) Received: from swp.bspu.secna.ru (swp.bspu.secna.ru [212.192.2.73]) by bspu.secna.ru (8.12.11/8.12.11) with ESMTP id i584IBqe015352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Jun 2004 11:18:31 +0700 (NOVST) (envelope-from swp@swp.bspu.secna.ru) Received: from swp.bspu.secna.ru (localhost [127.0.0.1]) by swp.bspu.secna.ru (8.12.10/8.12.10) with ESMTP id i584IB4V001106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jun 2004 11:18:11 +0700 (OMSST) (envelope-from swp@swp.bspu.secna.ru) Received: (from root@localhost) by swp.bspu.secna.ru (8.12.10/8.12.10/Submit) id i584IAHS001105 for freebsd-net@freebsd.org; Tue, 8 Jun 2004 11:18:10 +0700 (OMSST) (envelope-from swp) Date: Tue, 8 Jun 2004 11:18:10 +0700 From: Charlie Root To: freebsd-net@freebsd.org Message-ID: <20040608041810.GA1077@swp.bspu.secna.ru> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i Subject: kernel panic by mars_nwe (nwserv -k) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: swp@swp.pp.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:18:41 -0000 helo. kernel panic for shutdown of mars_nwe... bash-2.05b# gdb -k kernel /var/crash/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... panic: mutex rtentry not owned at ../../../net/route.c:225 panic messages: --- panic: mutex rtentry not owned at ../../../net/route.c:225 Stack backtrace: panic: from debugger Uptime: 57m26s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- warning: cannot find file for module vesa.ko warning: cannot find file for module if_ef.ko warning: cannot find file for module miibus.ko warning: cannot find file for module if_fxp.ko warning: cannot find file for module snd_pcm.ko warning: cannot find file for module snd_es137x.ko warning: cannot find file for module random.ko warning: cannot find file for module acpi.ko warning: cannot find file for module fdc.ko warning: cannot find file for module speaker.ko warning: cannot find file for module vinum.ko warning: cannot find file for module procfs.ko warning: cannot find file for module pseudofs.ko warning: cannot find file for module linprocfs.ko warning: cannot find file for module linux.ko warning: cannot find file for module sysvmsg.ko warning: cannot find file for module sysvsem.ko warning: cannot find file for module sysvshm.ko warning: cannot find file for module ipl.ko warning: cannot find file for module nfsclient.ko warning: cannot find file for module nfsserver.ko warning: cannot find file for module usb.ko warning: cannot find file for module snake_saver.ko warning: cannot find file for module vmmon_up.ko warning: cannot find file for module vmnet.ko warning: cannot find file for module if_tap.ko warning: cannot find file for module netgraph.ko warning: cannot find file for module ng_socket.ko warning: cannot find file for module ng_ether.ko warning: cannot find file for module ng_tee.ko warning: cannot find file for module ng_bridge.ko warning: cannot find file for module rtc.ko Error while mapping shared library sections: vesa.ko: No such file or directory. Error while mapping shared library sections: if_ef.ko: Unknown error: 0. Error while mapping shared library sections: miibus.ko: Unknown error: 0. Error while mapping shared library sections: if_fxp.ko: Unknown error: 0. Error while mapping shared library sections: snd_pcm.ko: Unknown error: 0. Error while mapping shared library sections: snd_es137x.ko: Unknown error: 0. Error while mapping shared library sections: random.ko: Unknown error: 0. Error while mapping shared library sections: acpi.ko: Unknown error: 0. Error while mapping shared library sections: fdc.ko: Unknown error: 0. Error while mapping shared library sections: speaker.ko: Unknown error: 0. Error while mapping shared library sections: vinum.ko: Unknown error: 0. Error while mapping shared library sections: procfs.ko: Unknown error: 0. Error while mapping shared library sections: pseudofs.ko: Unknown error: 0. Error while mapping shared library sections: linprocfs.ko: Unknown error: 0. Error while mapping shared library sections: linux.ko: Unknown error: 0. Error while mapping shared library sections: sysvmsg.ko: Unknown error: 0. Error while mapping shared library sections: sysvsem.ko: Unknown error: 0. Error while mapping shared library sections: sysvshm.ko: Unknown error: 0. Error while mapping shared library sections: ipl.ko: Unknown error: 0. Error while mapping shared library sections: nfsclient.ko: Unknown error: 0. Error while mapping shared library sections: nfsserver.ko: Unknown error: 0. Error while mapping shared library sections: usb.ko: Unknown error: 0. Error while mapping shared library sections: snake_saver.ko: Unknown error: 0. Error while mapping shared library sections: vmmon_up.ko: Unknown error: 0. Error while mapping shared library sections: vmnet.ko: Unknown error: 0. Error while mapping shared library sections: if_tap.ko: Unknown error: 0. Error while mapping shared library sections: netgraph.ko: Unknown error: 0. Error while mapping shared library sections: ng_socket.ko: Unknown error: 0. Error while mapping shared library sections: ng_ether.ko: Unknown error: 0. Error while mapping shared library sections: ng_tee.ko: Unknown error: 0. Error while mapping shared library sections: ng_bridge.ko: Unknown error: 0. Error while mapping shared library sections: rtc.ko: Unknown error: 0. Error while reading shared library symbols: vesa.ko: No such file or directory. Error while reading shared library symbols: if_ef.ko: No such file or directory. Error while reading shared library symbols: miibus.ko: No such file or directory. Error while reading shared library symbols: if_fxp.ko: No such file or directory. Error while reading shared library symbols: snd_pcm.ko: No such file or directory. Error while reading shared library symbols: snd_es137x.ko: No such file or directory. Error while reading shared library symbols: random.ko: No such file or directory. Error while reading shared library symbols: acpi.ko: No such file or directory. Error while reading shared library symbols: fdc.ko: No such file or directory. Error while reading shared library symbols: speaker.ko: No such file or directory. Error while reading shared library symbols: vinum.ko: No such file or directory. Error while reading shared library symbols: procfs.ko: No such file or directory. Error while reading shared library symbols: pseudofs.ko: No such file or directory. Error while reading shared library symbols: linprocfs.ko: No such file or directory. Error while reading shared library symbols: linux.ko: No such file or directory. Error while reading shared library symbols: sysvmsg.ko: No such file or directory. Error while reading shared library symbols: sysvsem.ko: No such file or directory. Error while reading shared library symbols: sysvshm.ko: No such file or directory. Error while reading shared library symbols: ipl.ko: No such file or directory. Error while reading shared library symbols: nfsclient.ko: No such file or directory. Error while reading shared library symbols: nfsserver.ko: No such file or directory. Error while reading shared library symbols: usb.ko: No such file or directory. Error while reading shared library symbols: snake_saver.ko: No such file or directory. Error while reading shared library symbols: vmmon_up.ko: No such file or directory. Error while reading shared library symbols: vmnet.ko: No such file or directory. Error while reading shared library symbols: if_tap.ko: No such file or directory. Error while reading shared library symbols: netgraph.ko: No such file or directory. Error while reading shared library symbols: ng_socket.ko: No such file or directory. Error while reading shared library symbols: ng_ether.ko: No such file or directory. Error while reading shared library symbols: ng_tee.ko: No such file or directory. Error while reading shared library symbols: ng_bridge.ko: No such file or directory. Error while reading shared library symbols: rtc.ko: No such file or directory. #0 0xc04c567b in doadump () (kgdb) file kernel.debug Reading symbols from kernel.debug...done. (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc04c5ce5 in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc04c6090 in panic (fmt=0xc0657095 "from debugger") at ../../../kern/kern_shutdown.c:550 #3 0xc043a732 in db_panic (addr=-1067460476, have_addr=0, count=-1, modif=0xce67896c "") at ../../../ddb/db_command.c:450 #4 0xc043a692 in db_command (last_cmdp=0xc06aa180, cmd_table=0xce678940, aux_cmd_tablep=0xc0657095, aux_cmd_tablep_end=0x0) at ../../../ddb/db_command.c:346 #5 0xc043a7d5 in db_command_loop () at ../../../ddb/db_command.c:472 #6 0xc043d7e5 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73 #7 0xc05fd5cc in kdb_trap (type=3, code=0, regs=0xce678abc) at ../../../i386/i386/db_interface.c:171 #8 0xc060d92a in trap (frame= {tf_fs = -832110568, tf_es = -1067515888, tf_ds = 16, tf_edi = 1, tf_esi = -1067046359, tf_ebp = -832075000, tf_isp = -832075032, tf_ebx = 0, tf_edx = 0, tf_ecx = -1066644000, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067460476, tf_cs = 8, tf_eflags = 646, tf_esp = -1066959182, tf_ss = -1067043737}) at ../../../i386/i386/trap.c:580 #9 0xc05fef98 in calltrap () at {standard input}:94 #10 0xc04c6015 in panic (fmt=0xc0662a29 "mutex %s not owned at %s:%d") at ../../../kern/kern_shutdown.c:534 #11 0xc04bc1b5 in _mtx_assert (m=0xc0662a29, what=0, file=0xc066a143 "../../../net/route.c", line=1) ---Type to continue, or q to quit--- at ../../../kern/kern_mutex.c:654 #12 0xc0534fb3 in rtfree (rt=0xc0662a29) at ../../../net/route.c:225 #13 0xc05774a1 in ipx_pcbdetach (ipxp=0xc2554080) at ../../../netipx/ipx_pcb.c:274 #14 0xc0577dbd in ipx_detach (so=0x0) at ../../../netipx/ipx_usrreq.c:492 #15 0xc04fe9f2 in soclose (so=0xc2138d20) at ../../../kern/uipc_socket.c:379 #16 0xc04f3a7b in soo_close (fp=0x0, td=0xc1d5e500) at ../../../kern/sys_socket.c:244 #17 0xc04a8a59 in fdrop_locked (fp=0xc2149d8c, td=0x0) at ../../../sys/file.h:292 #18 0xc04a7a5e in fdrop (fp=0xc2149d8c, td=0x0) at ../../../kern/kern_descrip.c:1829 #19 0xc04a7a0c in closef (fp=0xc2149d8c, td=0xc1d5e500) at ../../../kern/kern_descrip.c:1815 #20 0xc04a5b38 in close (td=0xc1d5e500, uap=0x0) at ../../../kern/kern_descrip.c:862 #21 0xc060e2a0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = 0, tf_ebp = -1077941576, tf_isp = -832074380, tf_ebx = 2, tf_edx = -1077943056, tf_ecx = 672561504, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 672052015, tf_cs = 31, tf_eflags = 642, tf_esp = -1077941588, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 #22 0xc05fefed in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- (kgdb) where full #0 doadump () at ../../../kern/kern_shutdown.c:240 No locals. #1 0xc04c5ce5 in boot (howto=260) at ../../../kern/kern_shutdown.c:372 No locals. #2 0xc04c6090 in panic (fmt=0xc0657095 "from debugger") at ../../../kern/kern_shutdown.c:550 td = (struct thread *) 0xc1d5e500 bootopt = 260 newpanic = 0 ap = 0xce678940 "ш\211gО\222¦CА\204Ш_А" buf = "mutex rtentry not owned at ../../../net/route.c:225", '\0' #3 0xc043a732 in db_panic (addr=-1067460476, have_addr=0, count=-1, modif=0xce67896c "") at ../../../ddb/db_command.c:450 No locals. #4 0xc043a692 in db_command (last_cmdp=0xc06aa180, cmd_table=0xce678940, aux_cmd_tablep=0xc0657095, aux_cmd_tablep_end=0x0) at ../../../ddb/db_command.c:346 cmd = (struct command *) 0xc0622e40 t = 0 modif = "\0ЄjА\0\0\0\0\210\211gО\r\0\0\0аklА\r\0\0\0\001\0\0\0Ё\211gОЦ3_А`QlА\aK\0 dllАаVkАаЄjАx\0\0\0аЄjА\0\0\0\0М\211gОБЕCА(¤eАpГCА\0\0\0\0\020\0\0\0\0\0\0\0аЄjАЦјCАаЄjА ўjАx\0\0\0\003\0\0" addr = -1067460476 ---Type to continue, or q to quit--- count = -1 have_addr = 0 result = 0 #5 0xc043a7d5 in db_command_loop () at ../../../ddb/db_command.c:472 No locals. #6 0xc043d7e5 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73 bkpt = 0 #7 0xc05fd5cc in kdb_trap (type=3, code=0, regs=0xce678abc) at ../../../i386/i386/db_interface.c:171 ef = 70 ddb_mode = 1 #8 0xc060d92a in trap (frame= {tf_fs = -832110568, tf_es = -1067515888, tf_ds = 16, tf_edi = 1, tf_esi = -1067046359, tf_ebp = -832075000, tf_isp = -832075032, tf_ebx = 0, tf_edx = 0, tf_ecx = -1066644000, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067460476, tf_cs = 8, tf_eflags = 646, tf_esp = -1066959182, tf_ss = -1067043737}) at ../../../i386/i386/trap.c:580 td = (struct thread *) 0xc1d5e500 p = (struct proc *) 0xc2086a98 sticks = 0 i = 0 ucode = 0 type = 3 code = 0 ---Type to continue, or q to quit--- eva = 0 #9 0xc05fef98 in calltrap () at {standard input}:94 No locals. #10 0xc04c6015 in panic (fmt=0xc0662a29 "mutex %s not owned at %s:%d") at ../../../kern/kern_shutdown.c:534 td = (struct thread *) 0xc1d5e500 bootopt = 256 newpanic = 1 ap = 0x0 buf = "mutex rtentry not owned at ../../../net/route.c:225", '\0' #11 0xc04bc1b5 in _mtx_assert (m=0xc0662a29, what=0, file=0xc066a143 "../../../net/route.c", line=1) at ../../../kern/kern_mutex.c:654 No locals. #12 0xc0534fb3 in rtfree (rt=0xc0662a29) at ../../../net/route.c:225 rnh = (struct radix_node_head *) 0x1 #13 0xc05774a1 in ipx_pcbdetach (ipxp=0xc2554080) at ../../../netipx/ipx_pcb.c:274 so = (struct socket *) 0x0 #14 0xc0577dbd in ipx_detach (so=0x0) at ../../../netipx/ipx_usrreq.c:492 ipxp = (struct ipxpcb *) 0x0 #15 0xc04fe9f2 in soclose (so=0xc2138d20) at ../../../kern/uipc_socket.c:379 error2 = 0 ---Type to continue, or q to quit--- error = 0 #16 0xc04f3a7b in soo_close (fp=0x0, td=0xc1d5e500) at ../../../kern/sys_socket.c:244 error = 0 so = (struct socket *) 0x0 #17 0xc04a8a59 in fdrop_locked (fp=0xc2149d8c, td=0x0) at ../../../sys/file.h:292 lf = {l_start = 7523290432, l_len = 1051199940862, l_pid = -1056791004, l_type = -18016, l_whence = -16125} vp = (struct vnode *) 0x0 error = -1042946816 #18 0xc04a7a5e in fdrop (fp=0xc2149d8c, td=0x0) at ../../../kern/kern_descrip.c:1829 No locals. #19 0xc04a7a0c in closef (fp=0xc2149d8c, td=0xc1d5e500) at ../../../kern/kern_descrip.c:1815 vp = (struct vnode *) 0x0 lf = {l_start = -4582963836952247460, l_len = -4590368889683604296, l_pid = -1034551244, l_type = 1, l_whence = 0} fdtol = (struct filedesc_to_leader *) 0xc2149d8c fdp = (struct filedesc *) 0x155 #20 0xc04a5b38 in close (td=0xc1d5e500, uap=0x0) at ../../../kern/kern_descrip.c:862 fdp = (struct filedesc *) 0xc2560000 ---Type to continue, or q to quit--- fp = (struct file *) 0xc2149d8c fd = 6 error = 6 holdleaders = 0 #21 0xc060e2a0 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = 0, tf_ebp = -1077941576, tf_isp = -832074380, tf_ebx = 2, tf_edx = -1077943056, tf_ecx = 672561504, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 672052015, tf_cs = 31, tf_eflags = 642, tf_esp = -1077941588, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 params = 0xbfbfeab0---Can't read userspace from dump, or kernel process--- (kgdb) up No stack. (kgdb) help List of classes of commands: aliases -- Aliases of other commands breakpoints -- Making program stop at certain points data -- Examining data files -- Specifying and examining files internals -- Maintenance commands obscure -- Obscure features running -- Running the program stack -- Examining the stack status -- Status inquiries support -- Support facilities tracepoints -- Tracing of program execution without stopping the program user-defined -- User-defined commands Type "help" followed by a class name for a list of commands in that class. Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (kgdb) help stack Examining the stack. The stack is made up of stack frames. Gdb assigns numbers to stack frames counting from zero for the innermost (currently executing) frame. At any time gdb identifies one frame as the "selected" frame. Variable lookups are done with respect to the selected frame. When the program being debugged stops, gdb selects the innermost frame. The commands below can be used to select other frames by number or address. List of commands: backtrace -- Print backtrace of all stack frames bt -- Print backtrace of all stack frames down -- Select and print stack frame called by this one frame -- Select and print a stack frame return -- Make selected stack frame return to its caller select-frame -- Select a stack frame without printing anything up -- Select and print stack frame that called this one Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (kgdb) return No selected frame. (kgdb) help select-frame Select a stack frame without printing anything. An argument specifies the frame to select. It can be a stack frame number or the address of the frame. (kgdb) select-frame 10 (kgdb) up #11 0xc04bc1b5 in _mtx_assert (m=0xc0662a29, what=0, file=0xc066a143 "../../../net/route.c", line=1) at ../../../kern/kern_mutex.c:654 654 panic("mutex %s not owned at %s:%d", (kgdb) p m $1 = (struct mtx *) 0xc0662a29 (kgdb) p *m $2 = {mtx_object = {lo_class = 0x6574756d, lo_name = 0x73252078---Can't read userspace from dump, or kernel process--- (kgdb) list 649 switch (what) { 650 case MA_OWNED: 651 case MA_OWNED | MA_RECURSED: 652 case MA_OWNED | MA_NOTRECURSED: 653 if (!mtx_owned(m)) 654 panic("mutex %s not owned at %s:%d", 655 m->mtx_object.lo_name, file, line); 656 if (mtx_recursed(m)) { 657 if ((what & MA_NOTRECURSED) != 0) 658 panic("mutex %s recursed at %s:%d", (kgdb) up #12 0xc0534fb3 in rtfree (rt=0xc0662a29) at ../../../net/route.c:225 225 RT_LOCK_ASSERT(rt); (kgdb) p *rt $3 = {rt_nodes = {{rn_mklist = 0x6574756d, rn_parent = 0x73252078, rn_bit = 28192, rn_bmask = 111 'o', rn_flags = 116 't', rn_u = { rn_leaf = {rn_Key = 0x6e776f20---Can't read userspace from dump, or kernel process--- (kgdb) list 220 struct radix_node_head *rnh = rt_tables[rt_key(rt)->sa_family]; 221 222 if (rt == 0 || rnh == 0) 223 panic("rtfree"); 224 225 RT_LOCK_ASSERT(rt); 226 227 /* 228 * decrement the reference count by one and if it reaches 0, 229 * and there is a close function defined, call the close function (kgdb) up #13 0xc05774a1 in ipx_pcbdetach (ipxp=0xc2554080) at ../../../netipx/ipx_pcb.c:274 274 rtfree(ipxp->ipxp_route.ro_rt); (kgdb) p *ipxp_route No symbol "ipxp_route" in current context. (kgdb) p *ipxp $4 = {ipxp_next = 0xc2004680, ipxp_prev = 0xc1f52400, ipxp_head = 0x0, ipxp_socket = 0xc2138d20, ipxp_faddr = {x_net = {c_net = "\0\0\0", s_net = { 0, 0}}, x_host = {c_host = "\0\0\0\0\0", s_host = {0, 0, 0}}, x_port = 0}, ipxp_laddr = {x_net = {c_net = " \004\006\005", s_net = { 1056, 1286}}, x_host = {c_host = "\0\0\0\0\0\001", s_host = {0, 0, 256}}, x_port = 832}, ipxp_pcb = 0x0, ipxp_route = { ro_rt = 0xc1d60900, ro_dst = {sa_len = 16 '\020', sa_family = 23 '\027', sa_data = " \004\006\005\0\0\0\0\0\001\0\0\0"}}, ipxp_lastdst = { x_net = {c_net = " \004\006\005", s_net = {1056, 1286}}, x_host = { c_host = "\0\0\0\0\0\001", s_host = {0, 0, 256}}, x_port = 1088}, ipxp_notify_param = 0, ipxp_flags = 2, ipxp_dpt = 17 '\021', ipxp_rpt = 17 '\021'} (kgdb) p *ipxp->ipxp_route.ro_rt $5 = {rt_nodes = {{rn_mklist = 0x0, rn_parent = 0xc20f5218, rn_bit = -49, rn_bmask = 0 '\0', rn_flags = 5 '\005', rn_u = {rn_leaf = { rn_Key = 0xc1c7a980 "\020\027 \004\006\005", rn_Mask = 0xc1d2acb0 "\006яяяяя", rn_Dupedkey = 0x0}, rn_node = { rn_Off = -1043879552, rn_L = 0xc1d2acb0, rn_R = 0x0}}}, { rn_mklist = 0x0, rn_parent = 0xc1cea04c, rn_bit = 18, rn_bmask = 32 ' ', rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = 0x2---Can't read userspace from dump, or kernel process--- (kgdb) list 269 struct socket *so = ipxp->ipxp_socket; 270 271 so->so_pcb = 0; 272 sotryfree(so); 273 if (ipxp->ipxp_route.ro_rt != NULL) 274 rtfree(ipxp->ipxp_route.ro_rt); 275 remque(ipxp); 276 FREE(ipxp, M_PCB); 277 } 278 (kgdb) up #14 0xc0577dbd in ipx_detach (so=0x0) at ../../../netipx/ipx_usrreq.c:492 492 ipx_pcbdetach(ipxp); (kgdb) list 487 struct ipxpcb *ipxp = sotoipxpcb(so); 488 489 if (ipxp == NULL) 490 return (ENOTCONN); 491 s = splnet(); 492 ipx_pcbdetach(ipxp); 493 splx(s); 494 return (0); 495 } 496 (kgdb) quit help me please... /swp From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 06:52:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 097E916A4CE; Tue, 8 Jun 2004 06:52:49 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49AD143D53; Tue, 8 Jun 2004 06:52:48 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i586wBwW030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 09:58:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i586qZHZ056855; Tue, 8 Jun 2004 09:52:35 +0300 (EEST) (envelope-from ru) Date: Tue, 8 Jun 2004 09:52:35 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040608065235.GA56799@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20040607074037.GB18232@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:52:49 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:40:37AM +0400, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 12:35:56AM -0700, Julian Elischer wrote: > J> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> > J> In addition the ng_ksocket node adds info into metadata and I sus= pect > J> > J> there are people using that. > J> >=20 > J> > Since ng_ksocket tags packets for itself only, we can safely change = it. > J>=20 > J> Since I did not add that code I am not very familiar with it or who us= es > J> it. (or why) > J>=20 > J> if this is true than yes we can do this.. >=20 > It is used only on UDP connection, to send replies back to where the orig= inal > packets came from. >=20 I wouldn't hardcode it this way. Rather, it just mimics the sendto()/recvfrom() semantics, to represent the "to"/"from" arguments, respectively. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWIzqRfpzJluFF4RAjOkAJ9JZGZNx59wAY8ZIqDgK2sQ7nq6/QCeLuI3 KVd2hlhxR9QUsnSrzv9K+BQ= =Ytac -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 06:58:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A62B816A4CE; Tue, 8 Jun 2004 06:58:51 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF35343D49; Tue, 8 Jun 2004 06:58:50 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i586wWvw026932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 10:58:32 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i586wVCs026931; Tue, 8 Jun 2004 10:58:31 +0400 (MSD) Date: Tue, 8 Jun 2004 10:58:31 +0400 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20040608065831.GC26822@cell.sick.ru> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> <20040608065235.GA56799@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040608065235.GA56799@ip.net.ua> User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:58:51 -0000 On Tue, Jun 08, 2004 at 09:52:35AM +0300, Ruslan Ermilov wrote: R> > J> > J> In addition the ng_ksocket node adds info into metadata and I suspect R> > J> > J> there are people using that. R> > J> > R> > J> > Since ng_ksocket tags packets for itself only, we can safely change it. R> > J> R> > J> Since I did not add that code I am not very familiar with it or who uses R> > J> it. (or why) R> > J> R> > J> if this is true than yes we can do this.. R> > R> > It is used only on UDP connection, to send replies back to where the original R> > packets came from. R> > R> I wouldn't hardcode it this way. Rather, it just mimics the R> sendto()/recvfrom() semantics, to represent the "to"/"from" R> arguments, respectively. Pardon, haven't understand what do you suggest. You mean, that it'll be better if node originating packets will insert this tag? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 07:02:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E8116A4CE; Tue, 8 Jun 2004 07:02:55 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB7243D49; Tue, 8 Jun 2004 07:02:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i5878Clc032285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 10:08:13 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i5872afE057074; Tue, 8 Jun 2004 10:02:36 +0300 (EEST) (envelope-from ru) Date: Tue, 8 Jun 2004 10:02:36 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040608070236.GA57053@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> <20040608065235.GA56799@ip.net.ua> <20040608065831.GC26822@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20040608065831.GC26822@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:02:56 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 08, 2004 at 10:58:31AM +0400, Gleb Smirnoff wrote: > On Tue, Jun 08, 2004 at 09:52:35AM +0300, Ruslan Ermilov wrote: > R> > J> > J> In addition the ng_ksocket node adds info into metadata and = I suspect > R> > J> > J> there are people using that. > R> > J> >=20 > R> > J> > Since ng_ksocket tags packets for itself only, we can safely ch= ange it. > R> > J>=20 > R> > J> Since I did not add that code I am not very familiar with it or w= ho uses > R> > J> it. (or why) > R> > J>=20 > R> > J> if this is true than yes we can do this.. > R> >=20 > R> > It is used only on UDP connection, to send replies back to where the= original > R> > packets came from. > R> >=20 > R> I wouldn't hardcode it this way. Rather, it just mimics the > R> sendto()/recvfrom() semantics, to represent the "to"/"from" > R> arguments, respectively. >=20 > Pardon, haven't understand what do you suggest. You mean, that it'll be b= etter > if node originating packets will insert this tag? >=20 It's not just used "to send replies back". In our proprietary module, we expect the connected node to be of a type "inet/dgram/udp ksocket", and insert tags appropriately to send datagrams to a correct router. We also read tags to verify that the datagrams are coming from the correct router. And it just mimics the sendto()/recvfrom() behavior. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWSMqRfpzJluFF4RAkekAJ97yi0KbkzFeTJmD7l5mmvUXq7CNgCglEMW +096yFXJsnZxagmcpOv32qo= =85Md -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 22:19:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4469616A4DD for ; Tue, 8 Jun 2004 22:19:52 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F67443D1D for ; Tue, 8 Jun 2004 22:19:51 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i58MH385072702 for net@FreeBSD.org.checked; (8.12.8/vak/2.1) Wed, 9 Jun 2004 02:17:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i58MEZeu072619 for ; (8.12.8/vak/2.1) Wed, 9 Jun 2004 02:14:37 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C638D8.3000009@cronyx.ru> Date: Wed, 09 Jun 2004 02:08:24 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: HEADSUP! FRF12 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 22:19:52 -0000 Hi, http://www.cronyx.ru/~rik/frf12_beta.tgz This is beta version of ng_frf12 module - FRF12 Frame Relay Fragmentation. Currently only End-to-End fragmentation supported. A bit later I'll post version with Interface fragmentation. Driver works as a filter between ng_frame_relay module and ng_rfc1490 module. It has two hooks "upstream" and "downstream." You could set fragment size via "ngctl msg fragsize" (default 200), fr header size (q922 address) could be set via "ngctl msg hdrsize" (default 2) Since it was tested only with itself please send me information about your results. Best regards, rik From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 22:52:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468D816A4CE for ; Tue, 8 Jun 2004 22:52:33 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207AB43D31 for ; Tue, 8 Jun 2004 22:52:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004060822523001400i2lgse>; Tue, 8 Jun 2004 22:52:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA45965; Tue, 8 Jun 2004 15:52:32 -0700 (PDT) Date: Tue, 8 Jun 2004 15:52:31 -0700 (PDT) From: Julian Elischer To: Roman Kurakin In-Reply-To: <40C638D8.3000009@cronyx.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: HEADSUP! FRF12 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 22:52:33 -0000 On Wed, 9 Jun 2004, Roman Kurakin wrote: > Hi, > > http://www.cronyx.ru/~rik/frf12_beta.tgz > > This is beta version of ng_frf12 module - FRF12 Frame Relay Fragmentation. > > Currently only End-to-End fragmentation supported. A bit later I'll post > version with Interface fragmentation. > > Driver works as a filter between ng_frame_relay module and ng_rfc1490 > module. > It has two hooks "upstream" and "downstream." > > You could set fragment size via "ngctl msg fragsize" (default 200), > fr header size (q922 address) could be set via "ngctl msg > hdrsize" (default 2) rather cool. > > Since it was tested only with itself please send me information about > your results. > Unfortunatly I don't have anything to test it against either.. > Best regards, > rik > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 23:20:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 100D816A4CE for ; Tue, 8 Jun 2004 23:20:08 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9CB43D53 for ; Tue, 8 Jun 2004 23:20:07 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i58NH3AT002098 for net@FreeBSD.org.checked; (8.12.8/vak/2.1) Wed, 9 Jun 2004 03:17:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i58NGoS5002085 for ; (8.12.8/vak/2.1) Wed, 9 Jun 2004 03:16:51 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C6477C.1000101@cronyx.ru> Date: Wed, 09 Jun 2004 03:10:52 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: net@FreeBSD.org References: <200406082116.i58LGg2M086150@repoman.freebsd.org> In-Reply-To: <200406082116.i58LGg2M086150@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: src/sys/net bpf.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 23:20:08 -0000 This commit reminded me one of my old ideas. Why not to make some function that allow to change DLT on the fly? Sync adapters can work with various types of protocols and protocol can be changed on the fly. Now we have to use DLT_NULL in such case and this strips functionality. rik David Malone: >dwmalone 2004-06-08 21:16:42 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_4) > sys/net bpf.h > Log: > MFC: Make the comment for DLT_NULL slightly more accurate. > > Revision Changes Path > 1.21.2.5 +1 -1 src/sys/net/bpf.h > > > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 03:22:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66F3E16A502 for ; Wed, 9 Jun 2004 03:22:08 +0000 (GMT) Received: from mail.seed.net.tw (matrix.seed.net.tw [192.72.81.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 762F143D53 for ; Wed, 9 Jun 2004 03:22:02 +0000 (GMT) (envelope-from al_chane@issc.com.tw) Received: from h25-210-66-57.seed.net.tw ([210.66.57.25] helo=issc.com.tw) by mail.seed.net.tw with esmtp (Seednet MTA build 20020826 Matrix) id 1BXtf5-0002he-00 for freebsd-net@freebsd.org; Wed, 09 Jun 2004 11:21:59 +0800 Message-ID: <40C68254.7040501@issc.com.tw> Date: Wed, 09 Jun 2004 11:21:56 +0800 From: AL Chane User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-TW; rv:1.2.1) Gecko/20030225 X-Accept-Language: zh-tw, en-us, zh MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Two interfaces on the same network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 03:22:08 -0000 Hi, there: I have two interfaces on my linux PC in the same network: >ifconfig eth0 172.20.1.30 netmask 255.255.255.0 >ifconfig eth1 172.20.1.31 netmask 255.255.255.0 Another Windows PC with IP 172.20.1.32 netmask 255.255.255.0 I found that in the same network, Linux PC only use one interface eth0 for outbound/inbound traffics no matter what. Even if I use Windows PC (172.20.1.32) to ping Linux PC's eth1 (172.20.1.31), Linux still use eth0 to reply. That is, if I unplug eth0's wire, eth1 won't work too. Does anyone have the same issue on how to make two interfaces work in the same network? I search 2003 archive, some said it can be done by set second interface (eth1) netmask to 255.255.255.255, but i tried and it doesn't work for me. Helps from you are highly appreciated! Thanks AL From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 06:02:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F7716A4CE for ; Wed, 9 Jun 2004 06:02:18 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B86E43D53 for ; Wed, 9 Jun 2004 06:02:15 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i595xE94021392 for freebsd-net@freebsd.org.checked; (8.12.8/vak/2.1) Wed, 9 Jun 2004 09:59:14 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i595vZWY021293; (8.12.8/vak/2.1) Wed, 9 Jun 2004 09:57:36 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C6A56A.5040105@cronyx.ru> Date: Wed, 09 Jun 2004 09:51:38 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: AL Chane References: <40C68254.7040501@issc.com.tw> In-Reply-To: <40C68254.7040501@issc.com.tw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Two interfaces on the same network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 06:02:18 -0000 AL Chane: >Hi, there: > > I have two interfaces on my linux PC in the same network: > > > >>ifconfig eth0 172.20.1.30 netmask 255.255.255.0 >>ifconfig eth1 172.20.1.31 netmask 255.255.255.0 >> >> > > Another Windows PC with IP 172.20.1.32 netmask 255.255.255.0 > > I found that in the same network, Linux PC only use one interface >eth0 for outbound/inbound traffics no matter what. Even if I use Windows >PC (172.20.1.32) to ping Linux PC's eth1 (172.20.1.31), Linux still use >eth0 to reply. That is, if I unplug eth0's wire, eth1 won't work too. > > Does anyone have the same issue on how to make two interfaces >work in the same network? I search 2003 archive, some said it can be >done by set second interface (eth1) netmask to 255.255.255.255, but >i tried and it doesn't work for me. > > Helps from you are highly appreciated! > Are they on the same wire? If so, why do you need such configuretion? rik > >Thanks > >AL > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 06:42:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA0BC16A4CE for ; Wed, 9 Jun 2004 06:42:25 +0000 (GMT) Received: from mail.seed.net.tw (matrix.seed.net.tw [192.72.81.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6238D43D1D for ; Wed, 9 Jun 2004 06:42:20 +0000 (GMT) (envelope-from al_chane@issc.com.tw) Received: from h25-210-66-57.seed.net.tw ([210.66.57.25] helo=issc.com.tw) by mail.seed.net.tw with esmtp (Seednet MTA build 20020826 Matrix) id 1BXwmt-000Ibs-00; Wed, 09 Jun 2004 14:42:15 +0800 Message-ID: <40C6B144.5040203@issc.com.tw> Date: Wed, 09 Jun 2004 14:42:12 +0800 From: AL Chane User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-TW; rv:1.2.1) Gecko/20030225 X-Accept-Language: zh-tw, en-us, zh MIME-Version: 1.0 To: Roman Kurakin References: <40C68254.7040501@issc.com.tw> <40C6A56A.5040105@cronyx.ru> In-Reply-To: <40C6A56A.5040105@cronyx.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Two interfaces on the same network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 06:42:26 -0000 > AL Chane: > >> Hi, there: >> >> I have two interfaces on my linux PC in the same network: >> >> >> >>> ifconfig eth0 172.20.1.30 netmask 255.255.255.0 >>> ifconfig eth1 172.20.1.31 netmask 255.255.255.0 >>> >> >> >> Another Windows PC with IP 172.20.1.32 netmask 255.255.255.0 >> >> I found that in the same network, Linux PC only use one interface >> eth0 for outbound/inbound traffics no matter what. Even if I use Windows >> PC (172.20.1.32) to ping Linux PC's eth1 (172.20.1.31), Linux still use >> eth0 to reply. That is, if I unplug eth0's wire, eth1 won't work too. >> >> Does anyone have the same issue on how to make two interfaces >> work in the same network? I search 2003 archive, some said it can be >> done by set second interface (eth1) netmask to 255.255.255.255, but >> i tried and it doesn't work for me. >> >> Helps from you are highly appreciated! >> > Are they on the same wire? If so, why do you need such configuretion? > > rik no, eth0 is wired ethernet. eth1 is wireless. My application is an IP Camera with two interfaces (eth0 is wired ethernet, eth1 is wireless) running on uClinux. IP Camera provides an Http server so clinet browers can access it by either ethernet or wireless. Two interfaces work fine with different networks, but have probem to work in the same network as I described in the previous message. The situation I might have is like this: Users need first to use ethernet (eth0) to access http server to setup wireless(eth1) like SSID, WEP. Once wireless is setup, two interface eth0/eth1 with two IPS exist in the same network. If user unplug the ethernet wire, wireless won't work unless I make ethernet down or change ethernet IP to different network. This step might not be friendly for ordinary users. In addition, in the same LAN, clients access thru wireless might want switch back to wired access due to heavy wireless traffic/wireless performance (sometimes choppy) Thanks :) AL Chane From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 10:11:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04DB316A4CE for ; Wed, 9 Jun 2004 10:11:14 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F8EA43D2F for ; Wed, 9 Jun 2004 10:11:13 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i59A85sW035729 for freebsd-net@freebsd.org.checked; (8.12.8/vak/2.1) Wed, 9 Jun 2004 14:08:05 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i59A5uji035624; (8.12.8/vak/2.1) Wed, 9 Jun 2004 14:05:56 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C6E0B8.2090502@cronyx.ru> Date: Wed, 09 Jun 2004 14:04:40 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: AL Chane References: <40C68254.7040501@issc.com.tw> <40C6A56A.5040105@cronyx.ru> <40C6B144.5040203@issc.com.tw> In-Reply-To: <40C6B144.5040203@issc.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Two interfaces on the same network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 10:11:14 -0000 AL Chane wrote: >> AL Chane: >> >>> Hi, there: >>> >>> I have two interfaces on my linux PC in the same network: >>> >>>> ifconfig eth0 172.20.1.30 netmask 255.255.255.0 >>>> ifconfig eth1 172.20.1.31 netmask 255.255.255.0 >>>> >>> Another Windows PC with IP 172.20.1.32 netmask 255.255.255.0 >>> >>> I found that in the same network, Linux PC only use one interface >>> eth0 for outbound/inbound traffics no matter what. Even if I use >>> Windows >>> PC (172.20.1.32) to ping Linux PC's eth1 (172.20.1.31), Linux still use >>> eth0 to reply. That is, if I unplug eth0's wire, eth1 won't work too. >>> >>> Does anyone have the same issue on how to make two interfaces >>> work in the same network? I search 2003 archive, some said it can be >>> done by set second interface (eth1) netmask to 255.255.255.255, but >>> i tried and it doesn't work for me. >>> >>> Helps from you are highly appreciated! >>> >> Are they on the same wire? If so, why do you need such configuretion? >> >> rik > > > no, eth0 is wired ethernet. eth1 is wireless. > > My application is an IP Camera with two interfaces (eth0 is wired > ethernet, eth1 is wireless) running on uClinux. IP Camera provides > an Http server so clinet browers can access it by either ethernet or > wireless. I don't know how in linux, probably the same, but I didn't setup it on linux. In FreeBSD you could do this via bridging. If you turn on bridging you just need to assign IP to one of the interfaces. Also do not forget to turn on forwarding. All side effects could be fixed by firewall rules. By the way it would be better if you choose other list, cause this one is for freebsd not for linux. I am not sure if this violates policy of this list but for sure you would be less lucky here. rik > > Two interfaces work fine with different networks, but have probem > to work in the same network as I described in the previous message. > > The situation I might have is like this: > > Users need first to use ethernet (eth0) to access http server > to setup wireless(eth1) like SSID, WEP. Once wireless is setup, > two interface eth0/eth1 with two IPS exist in the same network. > If user unplug the ethernet wire, wireless won't work unless > I make ethernet down or change ethernet IP to different network. > This step might not be friendly for ordinary users. > In addition, in the same LAN, clients access thru wireless might > want switch back to wired access due to heavy wireless > traffic/wireless performance (sometimes choppy) > > Thanks :) > > AL Chane > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 10:20:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E2416A4CE for ; Wed, 9 Jun 2004 10:20:50 +0000 (GMT) Received: from smtp.clifftop.net (machassociates-6.dsl.easynet.co.uk [217.204.162.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A228743D54 for ; Wed, 9 Jun 2004 10:20:46 +0000 (GMT) (envelope-from danny@clifftop.net) Received: from andromeda.clifftop.net (localhost.clifftop.net [127.0.0.1]) by smtp.clifftop.net (8.12.11/8.12.11) with ESMTP id i59AKiOA009286 for ; Wed, 9 Jun 2004 11:20:44 +0100 (BST) Received: (from www@localhost) by andromeda.clifftop.net (8.12.11/8.12.10/Submit) id i59AKiDh009285 for freebsd-net@freebsd.org; Wed, 9 Jun 2004 11:20:44 +0100 (BST) X-Authentication-Warning: andromeda.clifftop.net: www set sender to danny@clifftop.net using -f Received: from cassiopeia.clifftop.net (cassiopeia.clifftop.net [192.168.1.10]) by webmail.randomlittlehost.com (IMP) with HTTP for ; Wed, 9 Jun 2004 11:20:44 +0100 Message-ID: <1086776444.40c6e47c77be1@webmail.randomlittlehost.com> Date: Wed, 9 Jun 2004 11:20:44 +0100 From: Danny Horne To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 / FreeBSD-4.9 X-Originating-IP: 192.168.1.10 Subject: ipf / ipnat question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 10:20:50 -0000 Hi all, Can anyone direct me to a good tutorial on ipf / ipnat? Specifically I need to open a contiguous range of ports with ipf & then forward them (rdr?) to an internal IP address with ipnat. Thanks for all replies ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 17:24:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FC7516A4CE for ; Wed, 9 Jun 2004 17:24:57 +0000 (GMT) Received: from lists.sch.bme.hu (kaa.sch.bme.hu [152.66.208.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id C385E43D1D for ; Wed, 9 Jun 2004 17:24:56 +0000 (GMT) (envelope-from tamas@bazmag.hu) Received: by lists.sch.bme.hu (Postfix, from userid 102) id 0024F85853E; Wed, 9 Jun 2004 19:24:39 +0200 (CEST) Received: from [127.0.0.1] (ural14.sch.bme.hu [152.66.211.76]) by lists.sch.bme.hu (Postfix) with ESMTP id E71988582E6 for ; Wed, 9 Jun 2004 19:24:39 +0200 (CEST) Message-ID: <40C747D8.1030200@bazmag.hu> Date: Wed, 09 Jun 2004 19:24:40 +0200 From: Tamas MEZEI User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: two nics, same network, different topics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 17:24:57 -0000 Hi, I'm having a quite same problem as Al Chane had (two interfaces on the same network) but with a completely different situation. So, the box looks like this: a gigabit 3com card (bge0) attached to a switch's span (mirror) port, and a fxp0 card for maintaining the traffic metering pc, accessing to Apache etc. Both ifaces have an ip address from the same network (x.x.x.3 is fxp0 and x.x.x.156 is the metering card), and have different hostnames. (Actually, this is/was an OpenBSD problem, but I'm trying to move the box to FreeBSD due to performance and software support.) Is it possible to route all the packets coming out of the box through the fxp0 card (I mean, saying "ok, we have a default route, but you, silly packet, you're always gonna use fxp0 to go out from the computer, and don't try to use bge0")? If it can be accessed via bridging, and if bridging doesn't affect the metering possibilities, please tell me. We're using Netramet and Nemac to get data from the flows. If the mirror iface has an ip address, Nemac cannot "poll" (or whatever it's called it does) data from Netramet and the bge0 card and saying something like no response from x.x.x.3 (it's the fxp0 card). (It's kinda strange, and kinda offtopic, but networking related.) If I say, ifconfig bge0 delete, it works again. The metering card has an IP address because tcpdump would complain (no IPv4 address) and maybe it affects it's capabilities. (I'm not so sure.) BTW, if anyone using Netramet, Nemac or other free traffic metering software, and would give me a hand, some advices whatever, please tell me, I have some questions, but, I think, it's completely offtopic here. Thanks, Tamas From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 19:45:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id C165316A4D0; Wed, 9 Jun 2004 19:45:38 +0000 (GMT) In-Reply-To: <40C747D8.1030200@bazmag.hu> from Tamas MEZEI at "Jun 9, 2004 07:24:40 pm" To: tamas@bazmag.hu (Tamas MEZEI) Date: Wed, 9 Jun 2004 19:45:38 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040609194538.C165316A4D0@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-net@freebsd.org Subject: Re: two nics, same network, different topics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 19:45:38 -0000 [...] > We're using Netramet and Nemac to get data from the flows. If the mirror > iface has an ip address, Nemac cannot "poll" (or whatever it's called it > does) data from Netramet and the bge0 card and saying something like no > response from x.x.x.3 (it's the fxp0 card). (It's kinda strange, and > kinda offtopic, but networking related.) If I say, ifconfig bge0 delete, > it works again. > > The metering card has an IP address because tcpdump would complain (no > IPv4 address) and maybe it affects it's capabilities. (I'm not so sure.) Uh... no. Whether or not the interface has an IP address does not "affect its capabilities." If all you want to do is snoop traffic via tcpdump (or something like it), you don't need an IP address on the interface. Period. Snooping traffic is done via BPF, which grabs all frames they even get anywhere near the IP layer. If you're not actually using the bge0 interface to exchange any traffic, just do ifconifg bge0 up and don't bother putting an IP address on it. You'll still be able to put the interface into promiscuous mode and monitor packets to your heart's content. Don't let the big bad tcpdump warning message scare you. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 20:23:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27CD716A52E for ; Wed, 9 Jun 2004 20:23:35 +0000 (GMT) Received: from fever.boogie.com (cpe-66-87-52-132.co.sprintbbd.net [66.87.52.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97E9443D1F for ; Wed, 9 Jun 2004 20:23:34 +0000 (GMT) (envelope-from durian@boogie.com) Received: from man.boogie.com (man.boogie.com [192.168.1.3]) by fever.boogie.com (8.12.11/8.12.11) with ESMTP id i59KNVKD000994 for ; Wed, 9 Jun 2004 14:23:31 -0600 (MDT) (envelope-from durian@boogie.com) From: Mike Durian To: freebsd-net@freebsd.org Date: Wed, 9 Jun 2004 14:23:31 -0600 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406091423.31355.durian@boogie.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fever.boogie.com Subject: Racoon breakage with recent kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 20:23:35 -0000 Sometime between Feb 9 and June 9 something changed in the kernel that causes racoon to fail. I'm afraid I don't have a verbatim error message handy, but my notes (from running racoon with debugging enabled, in the foreground) say the error was in pk_sendupdate and the errno was, ENOBUFS. I believe this message is reporting the same problem I'm seeing: http://groups.google.com/groups?q=racoon+%22No+buffer+space+available%22&hl=en&lr=&ie=UTF-8&selm=20040606025301.GB41345%40mehnert.org&rnum=1 Does anybody know what is going on? Thanks, mike From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 21:27:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 858A916A4D2 for ; Wed, 9 Jun 2004 21:27:25 +0000 (GMT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E12A43D1F for ; Wed, 9 Jun 2004 21:27:25 +0000 (GMT) (envelope-from guy@alum.mit.edu) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i59LRL5X020716 for ; Wed, 9 Jun 2004 14:27:22 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com ; Wed, 9 Jun 2004 14:27:21 -0700 Received: from [17.202.40.208] (gharris.apple.com [17.202.40.208]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i59LRJH7023846; Wed, 9 Jun 2004 14:27:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Guy Harris Date: Wed, 9 Jun 2004 14:27:19 -0700 To: Roman Kurakin X-Mailer: Apple Mail (2.618) cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/net bpf.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 21:27:25 -0000 > This commit reminded me one of my old ideas. Why not to make some > function that allow to change DLT on the fly? Such as NetBSD's "bpf_change_type()"? /* * Change the data link type of a interface. */ void bpf_change_type(ifp, dlt, hdrlen) struct ifnet *ifp; u_int dlt, hdrlen; { struct bpf_if *bp; for (bp = bpf_iflist; bp != NULL; bp = bp->bif_next) { if (bp->bif_driverp == (struct bpf_if **)&ifp->if_bpf) break; } if (bp == NULL) panic("bpf_change_type"); bp->bif_dlt = dlt; /* * Compute the length of the bpf header. This is not necessarily * equal to SIZEOF_BPF_HDR because we want to insert spacing such * that the network layer header begins on a longword boundary (for * performance reasons and to alleviate alignment restrictions). */ bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; } From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 22:16:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAB2616A4CE for ; Wed, 9 Jun 2004 22:16:00 +0000 (GMT) Received: from beagle2.mehnert.org (beagle2.mehnert.org [212.42.235.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C5C843D2F for ; Wed, 9 Jun 2004 22:16:00 +0000 (GMT) (envelope-from hannes@mehnert.org) Received: from localhost (unknown [62.206.114.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Hannes Mehnert", Issuer "mehnert root CA" (verified OK)) by beagle2.mehnert.org (Postfix) with ESMTP id 2B73095821; Thu, 10 Jun 2004 00:15:58 +0200 (CEST) Date: Thu, 10 Jun 2004 00:15:49 +0200 From: Hannes Mehnert To: Mike Durian Message-ID: <20040609221549.GA5359@mehnert.org> References: <200406091423.31355.durian@boogie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406091423.31355.durian@boogie.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: Racoon breakage with recent kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 22:16:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Wed, Jun 09, 2004 at 02:23:31PM -0600, Mike Durian wrote: > Sometime between Feb 9 and June 9 something changed in the kernel > that causes racoon to fail. It happened between May 30 and June 4. > I'm afraid I don't have a verbatim > error message handy, but my notes (from running racoon with debugging > enabled, in the foreground) say the error was in pk_sendupdate > and the errno was, ENOBUFS. > > I believe this message is reporting the same problem I'm seeing: > > http://groups.google.com/groups?q=racoon+%22No+buffer+space+available%22&hl=en&lr=&ie=UTF-8&selm=20040606025301.GB41345%40mehnert.org&rnum=1 Yes, it is the same problem. I have put my kernel config and racoon.log on https://berlin.ccc.de/~hannes/KERNEL https://berlin.ccc.de/~hannes/racoon.log Regards, Hannes Mehnert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAx4wQRcuNlziBjRwRApIjAJ0drAwqUOHQcH3ADa2XQhlO7bnhHACgxD24 XeaIEKbPzy4FBkxZ2LC4u5Y= =vT9l -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 23:41:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49C2416A4D1 for ; Wed, 9 Jun 2004 23:41:47 +0000 (GMT) Received: from frodo.otenet.gr (frodo.otenet.gr [195.170.0.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C5843D54 for ; Wed, 9 Jun 2004 23:41:45 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a229.otenet.gr [212.205.215.229]) by frodo.otenet.gr (8.12.10/8.12.10) with ESMTP id i59NfaEv013484; Thu, 10 Jun 2004 02:41:38 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.11/8.12.11) with ESMTP id i59NfYtD021211; Thu, 10 Jun 2004 02:41:34 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.11/8.12.11/Submit) id i59NdrB7021133; Thu, 10 Jun 2004 02:39:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 10 Jun 2004 02:39:53 +0300 From: Giorgos Keramidas To: Danny Horne Message-ID: <20040609233953.GA20236@gothmog.gr> References: <1086776444.40c6e47c77be1@webmail.randomlittlehost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086776444.40c6e47c77be1@webmail.randomlittlehost.com> cc: freebsd-net@freebsd.org Subject: Re: ipf / ipnat question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 23:41:47 -0000 On 2004-06-09 11:20, Danny Horne wrote: > Can anyone direct me to a good tutorial on ipf / ipnat? Specifically > I need to open a contiguous range of ports with ipf & then forward > them (rdr?) to an internal IP address with ipnat. The first is easy to set up if you look at the ipf(5) manpage. I haven't used ipnat much, so I cannot answer about the second. From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 00:36:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A5FD16A4CE; Thu, 10 Jun 2004 00:36:13 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B36A43D41; Thu, 10 Jun 2004 00:36:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i5A0a3qE014733; Wed, 9 Jun 2004 20:36:04 -0400 Received: from obsecurity.org (xor [10.0.0.2]) by obsecurity.dyndns.org (Postfix) with ESMTP id 00AB751770; Wed, 9 Jun 2004 17:36:03 -0700 (PDT) Message-ID: <40C7ACF2.5020306@obsecurity.org> Date: Wed, 09 Jun 2004 17:36:02 -0700 From: Kris Kennaway User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040609 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD current users cc: net@FreeBSD.ORG Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 00:36:13 -0000 Julian Elischer wrote: > If you don't know or care about netgraph metadata (e.g. packet priority) > then this shouldn't worry you. > > We are changing the netgraph metadata facility (in which arbitrary > metadata can be sent with a packet through processing) to use > the mbuf TAG facility that has been imported by sam. > > Netgraph tags will use different cookies to the standard set of > tags imported with the code, so they will live in a separate namespace, > however they will be handled during GC and manipulation by the standard > tag handling code (Thanks to Sam for giving us the cookie facility). > > In the checked in code there are only a couple of users of metadata, but > there may be 3rd parties out there that use it. If so the authors should > contact me as soon as possible to co-ordinate the changeover. Don't forget to bump __FreeBSD_version when you make this change. Kris From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 12:02:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E0A16A4D0 for ; Thu, 10 Jun 2004 12:02:32 +0000 (GMT) Received: from mail.rialcom.ru (ns1.rialcom.ru [213.85.29.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9176943D49 for ; Thu, 10 Jun 2004 12:02:31 +0000 (GMT) (envelope-from dia@podolsk.net) Received: from 127.0.0.1 (one.rialcom.ru [213.85.13.238]) by mail.rialcom.ru (Postfix) with ESMTP id A54799BE3F for ; Thu, 10 Jun 2004 16:06:33 +0100 (BST) X-AntiVirus: Checked by Dr.Web [version: 4.31a, engine: 4.31b, virus records: 49097, updated: 24.04.2004] Date: Thu, 10 Jun 2004 16:02:12 +0300 From: "Ilya B." X-Mailer: The Bat! (v1.62r) UNREG / CD5BF9353B3B7091 Organization: RialCom X-Priority: 3 (Normal) Message-ID: <496840076.20040610160212@podolsk.net> To: freebsd-net@freebsd.org In-Reply-To: <979796772.20040610160043@podolsk.net> References: <40C68254.7040501@issc.com.tw> <40C6A56A.5040105@cronyx.ru> <40C6B144.5040203@issc.com.tw> <40C6E0B8.2090502@cronyx.ru> <979796772.20040610160043@podolsk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[2]: Two interfaces on the same network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Ilya B." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 12:02:32 -0000 Здравствуйте, . ---------- Пересылаемое письмо ---------- От: Ilya B. К: Roman Kurakin А также к: Время создания: Thu, 10 Jun 2004 16:00:43 +0300 Тема: Two interfaces on the same network Прикрепленные файлы: <нет> Здравствуйте, Roman. Вы писали 9 июня 2004 г., 13:04:40: RK> AL Chane wrote: >>> AL Chane: >>> >>>> Hi, there: >>>> >>>> I have two interfaces on my linux PC in the same network: >>>> >>>>> ifconfig eth0 172.20.1.30 netmask 255.255.255.0 >>>>> ifconfig eth1 172.20.1.31 netmask 255.255.255.0 >>>>> >>>> Another Windows PC with IP 172.20.1.32 netmask 255.255.255.0 >>>> >>>> I found that in the same network, Linux PC only use one interface >>>> eth0 for outbound/inbound traffics no matter what. Even if I use >>>> Windows >>>> PC (172.20.1.32) to ping Linux PC's eth1 (172.20.1.31), Linux still use >>>> eth0 to reply. That is, if I unplug eth0's wire, eth1 won't work too. >>>> >>>> Does anyone have the same issue on how to make two interfaces >>>> work in the same network? I search 2003 archive, some said it can be >>>> done by set second interface (eth1) netmask to 255.255.255.255, but >>>> i tried and it doesn't work for me. >>>> >>>> Helps from you are highly appreciated! >>>> >>> Are they on the same wire? If so, why do you need such configuretion? >>> >>> rik >> >> >> no, eth0 is wired ethernet. eth1 is wireless. >> >> My application is an IP Camera with two interfaces (eth0 is wired >> ethernet, eth1 is wireless) running on uClinux. IP Camera provides >> an Http server so clinet browers can access it by either ethernet or >> wireless. RK> I don't know how in linux, probably the same, but I didn't setup it on RK> linux. RK> In FreeBSD you could do this via bridging. If you turn on bridging you just RK> need to assign IP to one of the interfaces. Also do not forget to turn RK> on forwarding. RK> All side effects could be fixed by firewall rules. RK> By the way it would be better if you choose other list, cause this one RK> is for freebsd RK> not for linux. I am not sure if this violates policy of this list but RK> for sure you would be RK> less lucky here. RK> rik >> >> Two interfaces work fine with different networks, but have probem >> to work in the same network as I described in the previous message. >> >> The situation I might have is like this: >> >> Users need first to use ethernet (eth0) to access http server >> to setup wireless(eth1) like SSID, WEP. Once wireless is setup, >> two interface eth0/eth1 with two IPS exist in the same network. >> If user unplug the ethernet wire, wireless won't work unless >> I make ethernet down or change ethernet IP to different network. >> This step might not be friendly for ordinary users. >> In addition, in the same LAN, clients access thru wireless might >> want switch back to wired access due to heavy wireless >> traffic/wireless performance (sometimes choppy) >> >> Thanks :) >> >> AL Chane >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> RK> _______________________________________________ RK> freebsd-net@freebsd.org mailing list RK> http://lists.freebsd.org/mailman/listinfo/freebsd-net RK> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" In FreeBSD works next sheme: su-2.05b# ifconfig fxp0: flags=8843 mtu 1500 inet 213.85.29.138 netmask 0xfffffff0 broadcast 213.85.29.143 inet6 fe80::202:a5ff:fe41:ccd6%fxp0 prefixlen 64 scopeid 0x1 inet 213.85.29.130 netmask 0xffffffff broadcast 213.85.29.130 ether 00:02:a5:41:cc:d6 media: Ethernet autoselect (100baseTX ) status: active But aliased IP adress couldn't be a gateway. -- С уважением, Ilya mailto:dia@podolsk.net ---------- Конец пересылаемого письма ---------- -- С уважением, Ilya mailto:dia@podolsk.net From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 14:29:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95F2716A4CE for ; Thu, 10 Jun 2004 14:29:34 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6365243D45 for ; Thu, 10 Jun 2004 14:29:33 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i5AEQ3w2045257 for net@FreeBSD.org.checked; (8.12.8/vak/2.1) Thu, 10 Jun 2004 18:26:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i5AENoIE045173; (8.12.8/vak/2.1) Thu, 10 Jun 2004 18:23:50 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C86EAD.8080508@cronyx.ru> Date: Thu, 10 Jun 2004 18:22:37 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Harris References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/net bpf.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 14:29:34 -0000 Yea, I think the same. rik Guy Harris wrote: >> This commit reminded me one of my old ideas. Why not to make some >> function that allow to change DLT on the fly? > > > Such as NetBSD's "bpf_change_type()"? > > /* > * Change the data link type of a interface. > */ > void > bpf_change_type(ifp, dlt, hdrlen) > struct ifnet *ifp; > u_int dlt, hdrlen; > { > struct bpf_if *bp; > > for (bp = bpf_iflist; bp != NULL; bp = bp->bif_next) { > if (bp->bif_driverp == (struct bpf_if **)&ifp->if_bpf) > break; > } > if (bp == NULL) > panic("bpf_change_type"); > > bp->bif_dlt = dlt; > > /* > * Compute the length of the bpf header. This is not necessarily > * equal to SIZEOF_BPF_HDR because we want to insert spacing such > * that the network layer header begins on a longword boundary > (for > * performance reasons and to alleviate alignment restrictions). > */ > bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; > } > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 19:23:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F70D16A4CE for ; Thu, 10 Jun 2004 19:23:36 +0000 (GMT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E7F43D2F for ; Thu, 10 Jun 2004 19:23:35 +0000 (GMT) (envelope-from Holger.Eitzenberger@t-online.de) Received: from fwd02.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BYV9A-0004BY-06; Thu, 10 Jun 2004 21:23:32 +0200 Received: from jonathan.eitzenberger.name (SsX3CmZereLJa8J-LDu91cpvUCRr6CAEqhQy2wILCPA3jjWiukYNo2@[62.224.21.55]) by fwd02.sul.t-online.com with esmtp id 1BYV8z-2AN8kK0; Thu, 10 Jun 2004 21:23:21 +0200 Received: from holger by jonathan.eitzenberger.name with local (Exim 3.35 #1 (Debian)) id 1BYVCg-0000RU-00 for ; Thu, 10 Jun 2004 21:27:10 +0200 Date: Thu, 10 Jun 2004 21:27:10 +0200 To: FreeBSD Net Message-ID: <20040610212709.A1672@eitzenberger.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: Holger.Eitzenberger@t-online.de (Holger Eitzenberger) X-Seen: false X-ID: SsX3CmZereLJa8J-LDu91cpvUCRr6CAEqhQy2wILCPA3jjWiukYNo2 Subject: choosing another random number generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 19:23:36 -0000 Hi all, using FBSD 4.9 I want to choose another RNG, because I have to following line in the logs when starting IPSec: WARNING: pseudo-random number generator used for IPsec processing Against popular believe[1] the Handbook or the random(4) manpage does not mention how to switch to another RNG. I have set the variable $rand_irqs accordingly. Thx in advance. /Holger [1] http://www.atm.tut.fi/list-archive/freebsd-stable/msg05253.html -- ++ GnuPG Key -> http://www.t-online.de/~holger.eitzenberger ++ From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 19:39:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4889E16A4CE for ; Thu, 10 Jun 2004 19:39:51 +0000 (GMT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFDB643D4C for ; Thu, 10 Jun 2004 19:39:50 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.84.3]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040610193949.VBIA6671.out003.verizon.net@[192.168.1.3]>; Thu, 10 Jun 2004 14:39:49 -0500 Message-ID: <40C8B906.7000904@mac.com> Date: Thu, 10 Jun 2004 15:39:50 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Holger Eitzenberger References: <20040610212709.A1672@eitzenberger.name> In-Reply-To: <20040610212709.A1672@eitzenberger.name> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.161.84.3] at Thu, 10 Jun 2004 14:39:49 -0500 cc: FreeBSD Net Subject: Re: choosing another random number generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 19:39:51 -0000 Holger Eitzenberger wrote: > using FBSD 4.9 I want to choose another RNG, because I have to > following line in the logs when starting IPSec: > > WARNING: pseudo-random number generator used for IPsec processing > > Against popular believe[1] the Handbook or the random(4) manpage > does not mention how to switch to another RNG. > > I have set the variable $rand_irqs accordingly. Consider getting something like: http://www.soekris.com/vpn1401.htm ...which will provide you with a hardware-based RNG. You'll need to enable some options in the kernel to use it (search for HIFN in LINT)... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 21:38:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10E3D16A4CE for ; Fri, 11 Jun 2004 21:38:14 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F0643D31 for ; Fri, 11 Jun 2004 21:38:13 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i5BLbKYA074585 for ; Fri, 11 Jun 2004 23:37:20 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: net@freebsd.org From: Poul-Henning Kamp Date: Fri, 11 Jun 2004 23:37:20 +0200 Message-ID: <74584.1086989840@critter.freebsd.dk> Subject: multi-link natd(8) testers needed. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 21:38:14 -0000 I have a patch here which attempts to teach natd(8) how to cope with multiple lines. I need a few good testers to help me iron out all the bugs. You need to have: A serious clue to configuring ipfw + natd. The necessary hardware to test a situation like having two ADSL lines from different providers. Run a moderately fresh -current or be prepared to backport the patches (this shouldn't be hard since it is only libalias and natd which is changed). Apply by private email. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Sat Jun 12 05:36:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 247C116A4CE for ; Sat, 12 Jun 2004 05:36:23 +0000 (GMT) Received: from diaspar.rdsnet.ro (diaspar.rdsnet.ro [213.157.165.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F5CB43D31 for ; Sat, 12 Jun 2004 05:36:22 +0000 (GMT) (envelope-from dudu@diaspar.rdsnet.ro) Received: (qmail 58720 invoked by uid 89); 12 Jun 2004 05:35:55 -0000 Received: from unknown (HELO diaspar.rdsnet.ro) (213.157.165.224) by 0 with AES256-SHA encrypted SMTP; 12 Jun 2004 05:35:55 -0000 Date: Sat, 12 Jun 2004 08:35:55 +0300 (EEST) From: Vlad GALU To: freebsd-net@freebsd.org Message-ID: <20040612082817.A10245@qvnfcne.eqfarg.eb> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: tun(4) issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dudu@diaspar.rdsnet.ro List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 05:36:23 -0000 Hello. I've been trying to set up a VPN server which should serve a large number of clients. Let's say something between 500 and 1000. I'd like to use the tun interface to do it. Now, what I observed when I tried to create 1000 tun devices, was that their minor numbers started to cycle every once in a while. So I guess there are replicas of my initial tun devices. Am I wrong ? Anyway, I only see these repeating minor numbers when browsing /dev/ from midnight commander. 'ls' shows a whole different kind of minor numbers, written in hex. Casting those to integers results in way larger numbers than usual, for example 196610. Before I start testing, am I doing something wrong here ? Should I stop now and find another implementation ? Thanks in advance for any feedback. ---- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sat Jun 12 20:17:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A19416A4CE for ; Sat, 12 Jun 2004 20:17:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBE943D2D for ; Sat, 12 Jun 2004 20:17:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5CKGHS0095803; Sat, 12 Jun 2004 16:16:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5CKGHCj095800; Sat, 12 Jun 2004 16:16:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Jun 2004 16:16:17 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Vlad GALU In-Reply-To: <20040612082817.A10245@qvnfcne.eqfarg.eb> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: tun(4) issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 20:17:41 -0000 On Sat, 12 Jun 2004, Vlad GALU wrote: > Hello. I've been trying to set up a VPN server which should > serve a large number of clients. Let's say something between 500 and > 1000. I'd like to use the tun interface to do it. Now, what I observed > when I tried to create 1000 tun devices, was that their minor numbers > started to cycle every once in a while. So I guess there are replicas of > my initial tun devices. Am I wrong ? Anyway, I only see these repeating > minor numbers when browsing /dev/ from midnight commander. 'ls' shows a > whole different kind of minor numbers, written in hex. Casting those to > integers results in way larger numbers than usual, for example 196610. > > Before I start testing, am I doing something wrong here ? Should > I stop now and find another implementation ? > > Thanks in advance for any feedback. Are you sure that minor numbers are duplicated? You shouldn't see that, and if you do, it's a bug. However, the observation regarding numbers and a non-contiguous shift to hex should be correct. This is because, historically, the device number was 16-bit: 8 bits for major number, 8 bits for minor number. When the device number was extended to 32-bit, the bits allocated to the minor number became non-contiguous. Here are the conversion routines to turn the device number into the parts: #define minor(x) ((int)((x)&0xffff00ff)) /* minor number */ #define major(x) ((int)(((u_int)(x) >> 8)&0xff)) /* major number */ I.e., minor numbers go from 0 to 255 (0x00 - 0xff), then skip all values with non-zero third and fourth digits in hex. I.e.: ... crw------- 1 uucp dialer 233, 254 May 25 13:26 /dev/tun254 crw------- 1 uucp dialer 233, 255 May 25 13:26 /dev/tun255 crw------- 1 uucp dialer 233, 0x00010000 May 25 13:26 /dev/tun256 crw------- 1 uucp dialer 233, 0x00010001 May 25 13:26 /dev/tun257 ... So assuming you're not actually seeing duplicate minor numbers or collisions, it should be operating correctly. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Sat Jun 12 20:36:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B0F116A4CE for ; Sat, 12 Jun 2004 20:36:10 +0000 (GMT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D633B43D46 for ; Sat, 12 Jun 2004 20:36:09 +0000 (GMT) (envelope-from Holger.Eitzenberger@t-online.de) Received: from fwd06.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1BZFCa-0003En-03; Sat, 12 Jun 2004 22:34:08 +0200 Received: from jonathan.eitzenberger.name (Ttsy0cZBweiZOr2px2twa14wff5llZSVV0KSM66we4BNPHwaX4S0QB@[193.159.49.214]) by fwd06.sul.t-online.com with esmtp id 1BZFCK-0iFlzs0; Sat, 12 Jun 2004 22:33:52 +0200 Received: from holger by jonathan.eitzenberger.name with local (Exim 3.35 #1 (Debian)) id 1BZFG6-0000EL-00; Sat, 12 Jun 2004 22:37:46 +0200 Date: Sat, 12 Jun 2004 22:37:44 +0200 To: Chuck Swiger Message-ID: <20040612223744.A871@eitzenberger.name> References: <20040610212709.A1672@eitzenberger.name> <40C8B906.7000904@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40C8B906.7000904@mac.com>; from cswiger@mac.com on Thu, Jun 10, 2004 at 03:39:50PM -0400 From: Holger.Eitzenberger@t-online.de (Holger Eitzenberger) X-Seen: false X-ID: Ttsy0cZBweiZOr2px2twa14wff5llZSVV0KSM66we4BNPHwaX4S0QB cc: FreeBSD Net Subject: Re: choosing another random number generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 20:36:10 -0000 On Thu, Jun 10, 2004 at 03:39:50PM -0400, Chuck Swiger wrote: > > WARNING: pseudo-random number generator used for IPsec processing > > Consider getting something like: > > http://www.soekris.com/vpn1401.htm > > ...which will provide you with a hardware-based RNG. You'll need to enable > some options in the kernel to use it (search for HIFN in LINT)... I use the box a home VPN gateway with max 3 users at the same time, so througput is not an issue. However, according to the manpage I can switch to the /dev/urandom RNG, while configuring the "entropy pool" with the $rand_irqs in /etc/rc.conf. Can someone please tell me how to switch to /dev/urandom? Thx. /Holger -- ++ GnuPG Key -> http://www.t-online.de/~holger.eitzenberger ++