From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 06:05:22 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A827F16A4D0
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 06:05:22 +0000 (GMT)
Received: from ns.tagnet.ru (ns.tagnet.ru [80.64.16.1])
by mx1.FreeBSD.org (Postfix) with ESMTP id DE2D343D46
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 06:05:21 +0000 (GMT)
(envelope-from boris@tagnet.ru)
Received: from p-242.secure.tagnet.ru ([80.64.16.242])
by ns.tagnet.ru with esmtp (Exim 4.43 #0)
id 1CsasB-0004gF-9S
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 11:05:20 +0500
Message-ID: <41F33E9F.9090301@tagnet.ru>
Date: Sun, 23 Jan 2005 11:05:19 +0500
From: Boris Kovalenko <boris@tagnet.ru>
Organization: JSC "TAGNet"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040616
X-Accept-Language: ru, 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: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 06:05:22 -0000
Hello!
>I'm not sure why you need trust and override. It seems like you only
>need the ability to set or remove values as well as acting on already
>attached tags (which we're going to need to carry around as m_tags so >we
>can filter on and modify them in conjunction with layer 3 information).
For example I have vlan of devices, which can set 802.1p themself
(Cisco IP Phones for example) based on their knowledge of situation. I
should just pass-trough their 802.1p because I don't know the situation.
In this case I should trust. Another example - I have devices that can
not set 802.1p (or more simply - it always 0), so I should set (or in
other words - override received value :) 802.1p myself.
> 3. Mark 802.1p at vlan drivers like 2
> ifconfig vlan0
> vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0
> Here we are trusting received from low level information and set 6 if it
> is omitted
> ifconfig vlan0
> vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0
> Here we silently set 6.
>If you're not going to do separate interfaces per priority (or
>perhaps set of priorities[0]) I'm not sure what the point of having the
>interface do anything is. Filtering is the job of the firewall so I'm
>not convinced we should be doing it in the vlan device. There's also
Hmm... If You remember, the idea of filtering is not mine :) I wrote it
may be realized, but see no sense in that. The only thing I suggested is
to set 802.1p values. Again, there are working realizations of 802.1p in
a world. Cisco for example. I can not access/modify 802.1p in firewall
(PIX/ACL/VACL). The only place where I may set 802.1p is the Catalyst
port. And on trunking port I may trust received values or reset them.
So, may be we should not to invent a bicycle?
>the complication that we need to handle the vlan=0 case which shouldn't
>be treated as a vlan at all and should be decapsulated in the actual
>device without a trip through the vlan code.
What the vlan=0 is? On a wire we may receive tagged or untagged frames.
Untagged should go usual way, tagged via vlan driver (IMHO).
>My suspicion is that we need to rethink the current separation of
>ether and vlan code. Making vlans less optional and doing more of the
>handling in ether_input and ether_output might be a good thing.
I'm not a guru of FreeBSD net infrastructure, so I can not raise an
objection on this words.
>[0] What I've read says that many switches group sets of priority
>values together reducing the set of valid values.
And what this changes? Some switches totally ignore 802.1p. We're
talking about IEEE standard and should fully support it. Also, may You
point me where You have read this?
----
Regards,
Boris
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 08:37:13 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6DEF516A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 08:37:13 +0000 (GMT)
Received: from abyss.iscas.cn (abyss.iscas.cn [159.226.5.55])
by mx1.FreeBSD.org (Postfix) with SMTP id A9B3743D4C
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 08:37:11 +0000 (GMT)
(envelope-from wangbin02@abyss.iscas.cn)
Received: (qmail 3550 invoked by uid 501); 23 Jan 2005 08:10:26 -0000
Message-ID: <20050123081026.3549.qmail@abyss.iscas.cn>
From: "Wang Bin" <wangbin02@iscas.cn>
To: freebsd-net@freebsd.org
Date: Sun, 23 Jan 2005 16:10:26 +0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="gb2312"
Content-Transfer-Encoding: 7bit
Subject:
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 08:37:13 -0000
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 11:22:34 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8419516A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 11:22:34 +0000 (GMT)
Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44])
by mx1.FreeBSD.org (Postfix) with ESMTP id D4B4643D46
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 11:22:33 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-1.free.fr (Postfix) with ESMTP id BBABC17353B;
Sun, 23 Jan 2005 12:22:30 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id E358A407C; Sun, 23 Jan 2005 12:22:19 +0100 (CET)
Date: Sun, 23 Jan 2005 12:22:19 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Brooks Davis <brooks@one-eyed-alien.net>
Message-ID: <20050123112219.GJ36660@obiwan.tataz.chchile.org>
References: <41F1E99A.5070001@ntmk.ru>
<20050122152546.GG36660@obiwan.tataz.chchile.org>
<20050122203347.GB4466@odin.ac.hmc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050122203347.GB4466@odin.ac.hmc.edu>
User-Agent: Mutt/1.5.6i
cc: freebsd-net@freebsd.org
cc: Boris Kovalenko <boris@ntmk.ru>
cc: Jeremie Le Hen <jeremie@le-hen.org>
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 11:22:34 -0000
> > Having the possibility to test and set the 802.1p or TOS values
> > separately would avoid making a "trust"/"override" subtlety and will
> > obviously make it more flexible.
>
> I agree on this point. The one thing to be careful of is that 802.1p
> priorities and TOS values work rather differently in that TOS values fit
> in to an existing field of the packet and 802.1p values require
> modifications to the header and adding data between the header and the
> real body, possiably with a resuling reduction in MTU (though what
> you're doing trying to use 802.1p priority with crappy nic I don't know
> :-).
I do not understand your point here. TOS is indeed an existing field
of the IPv4 header but AFAIK, this is the same for the 802.1p header [1].
There are already 3 bits reserved for priority (802.1p) near the 802.1q
field which are both inside what they call "Tag Control Information".
Regards,
[1] http://www.networkdictionnary.com/protocols/8021p.php
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 19:24:13 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 1598A16A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 19:24:13 +0000 (GMT)
Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75])
by mx1.FreeBSD.org (Postfix) with ESMTP id B7C3043D3F
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 19:24:12 +0000 (GMT)
(envelope-from brdavis@odin.ac.hmc.edu)
Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1])
by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0NJOjJE030520;
Sun, 23 Jan 2005 11:24:45 -0800
Received: (from brdavis@localhost)
by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0NJOiLh030519;
Sun, 23 Jan 2005 11:24:44 -0800
Date: Sun, 23 Jan 2005 11:24:44 -0800
From: Brooks Davis <brooks@one-eyed-alien.net>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050123192444.GA29225@odin.ac.hmc.edu>
References: <41F1E99A.5070001@ntmk.ru>
<20050122152546.GG36660@obiwan.tataz.chchile.org>
<20050122203347.GB4466@odin.ac.hmc.edu>
<20050123112219.GJ36660@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE"
Content-Disposition: inline
In-Reply-To: <20050123112219.GJ36660@obiwan.tataz.chchile.org>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu
cc: freebsd-net@freebsd.org
cc: Boris Kovalenko <boris@ntmk.ru>
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 19:24:13 -0000
--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 23, 2005 at 12:22:19PM +0100, Jeremie Le Hen wrote:
> > > Having the possibility to test and set the 802.1p or TOS values
> > > separately would avoid making a "trust"/"override" subtlety and will
> > > obviously make it more flexible.
> >=20
> > I agree on this point. The one thing to be careful of is that 802.1p
> > priorities and TOS values work rather differently in that TOS values fit
> > in to an existing field of the packet and 802.1p values require
> > modifications to the header and adding data between the header and the
> > real body, possiably with a resuling reduction in MTU (though what
> > you're doing trying to use 802.1p priority with crappy nic I don't know
> > :-).
>=20
> I do not understand your point here. TOS is indeed an existing field
> of the IPv4 header but AFAIK, this is the same for the 802.1p header [1].
> There are already 3 bits reserved for priority (802.1p) near the 802.1q
> field which are both inside what they call "Tag Control Information".
At the point you are examining layer 3 state, you either have already
stripped off the ethernet header or have not created it yet so you can't
just modify it. At least according to what I've read, you may or may
not want to tag all traffic so if you strip the tags, you not want to
use a vlan tag on the packet. You do have the actual storage the TOS
values will use since you have the IP header. I'm basicly saying that
they aren't necessicairly as similar as you might think. It might make
sense to modify the TOS bits directly in the firewall, but it is simply
not possiable to modify the 802.1p bits at that point because there's no
where to put them.
-- Brooks
--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFB8/n7XY6L6fI4GtQRAkfkAJ0eJwF02IKcm+Rg+dIoObSTjAeREACfQ/jl
ySG7PtfBoVo4wjEjD6ZdWkM=
=kvSM
-----END PGP SIGNATURE-----
--0OAP2g/MAC+5xKAE--
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 19:36:40 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7832816A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 19:36:40 +0000 (GMT)
Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75])
by mx1.FreeBSD.org (Postfix) with ESMTP id 490D043D31
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 19:36:39 +0000 (GMT)
(envelope-from brdavis@odin.ac.hmc.edu)
Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1])
by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0NJbBCq031525;
Sun, 23 Jan 2005 11:37:11 -0800
Received: (from brdavis@localhost)
by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0NJbBLg031524;
Sun, 23 Jan 2005 11:37:11 -0800
Date: Sun, 23 Jan 2005 11:37:11 -0800
From: Brooks Davis <brooks@one-eyed-alien.net>
To: Boris Kovalenko <boris@tagnet.ru>
Message-ID: <20050123193711.GB29225@odin.ac.hmc.edu>
References: <41F33E9F.9090301@tagnet.ru>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8"
Content-Disposition: inline
In-Reply-To: <41F33E9F.9090301@tagnet.ru>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu
cc: freebsd-net@freebsd.org
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 19:36:40 -0000
--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 23, 2005 at 11:05:19AM +0500, Boris Kovalenko wrote:
> Hello!
>=20
>=20
> >I'm not sure why you need trust and override. It seems like you only
> >need the ability to set or remove values as well as acting on already
> >attached tags (which we're going to need to carry around as m_tags so >we
> >can filter on and modify them in conjunction with layer 3 information).
>=20
> For example I have vlan of devices, which can set 802.1p themself=20
> (Cisco IP Phones for example) based on their knowledge of situation. I=20
> should just pass-trough their 802.1p because I don't know the situation.=
=20
> In this case I should trust. Another example - I have devices that can=20
> not set 802.1p (or more simply - it always 0), so I should set (or in=20
> other words - override received value :) 802.1p myself.
I still don't see how this usefull differs from taking action or not
taking action.
> > 3. Mark 802.1p at vlan drivers like 2
> > ifconfig vlan0
> > vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0
> > Here we are trusting received from low level information and set 6 if it
> > is omitted
> > ifconfig vlan0
> > vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0
> > Here we silently set 6.
>=20
> >If you're not going to do separate interfaces per priority (or
> >perhaps set of priorities[0]) I'm not sure what the point of having the
> >interface do anything is. Filtering is the job of the firewall so I'm
> >not convinced we should be doing it in the vlan device. There's also
>=20
> Hmm... If You remember, the idea of filtering is not mine :) I wrote=20
> it may be realized, but see no sense in that. The only thing I suggested=
is=20
> to set 802.1p values. Again, there are working realizations of 802.1p in=
=20
> a world. Cisco for example. I can not access/modify 802.1p in firewall=20
> (PIX/ACL/VACL). The only place where I may set 802.1p is the Catalyst=20
> port. And on trunking port I may trust received values or reset them.=20
> So, may be we should not to invent a bicycle?
What Cisco does is of rather limited relevence IMO. The default case of
a FreeBSD system is not a bridge or router but a host. We need to
determine what makes sense for both the bridge/router case and the host
case. Cisco's are for all practical purposes, not hosts.
> >the complication that we need to handle the vlan=3D0 case which shouldn't
> >be treated as a vlan at all and should be decapsulated in the actual
> >device without a trip through the vlan code.
>=20
> What the vlan=3D0 is? On a wire we may receive tagged or untagged=20
> frames. Untagged should go usual way, tagged via vlan driver (IMHO).
I've found at least one refrence when googling for 802.1p which says
that vlan 0 is reserved and means that the tag is only a priority. In
that case there is no vlan and I don't think vlan devices should be
involved. If they are, you must set the priority on every frame or
priority and non-priority frames will be delivered to different
intefaces which may or may not be what you want.
I'm not 100% sure that's correct, but the IEEE has made it practialy
impossiable to find 802.1p. I haven't found it yet.
> >My suspicion is that we need to rethink the current separation of
> >ether and vlan code. Making vlans less optional and doing more of the
> >handling in ether_input and ether_output might be a good thing.
>=20
> I'm not a guru of FreeBSD net infrastructure, so I can not raise an=20
> objection on this words.
>=20
> >[0] What I've read says that many switches group sets of priority=20
> >values together reducing the set of valid values.
>=20
> And what this changes? Some switches totally ignore 802.1p. We're=20
> talking about IEEE standard and should fully support it. Also, may You=20
> point me where You have read this?
The issue is that you may need the ability to treat some values as
though they are the same because some network environments will do this.
While I think a lower level solution will be the most useful in the
end, I don't object to an interface based solution. I think you should
proceed with that with the idea that you add a third, optional keyword
to vlan initalization to specify priority. That way you can create
seperate interfaces for each priority for any vlan tag. Something like:
ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3
-- Brooks
--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFB8/zmXY6L6fI4GtQRAvS4AJ4/z22QZLzjTXstgotJCGf6/pgiHQCgn2AP
t8yv28D5zAsRvfqT4/Hu6Ls=
=pjiu
-----END PGP SIGNATURE-----
--JP+T4n/bALQSJXh8--
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 22:27:02 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 56E2E16A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:27:02 +0000 (GMT)
Received: from borgtech.ca (borgtech.ca [216.187.106.216])
by mx1.FreeBSD.org (Postfix) with ESMTP id 15E3943D46
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:27:02 +0000 (GMT)
(envelope-from asegu@borgtech.ca)
Received: from asegulaptop (unknown [161.53.212.129])
by borgtech.ca (Postfix) with ESMTP id A997254A5
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:31:30 +0000 (GMT)
From: "Andrew Seguin" <asegu@borgtech.ca>
To: <freebsd-net@freebsd.org>
Date: Sun, 23 Jan 2005 23:25:47 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcUBmnxv1/7yLmEbSNKwVODRtEHJJQ==
Message-Id: <20050123223130.A997254A5@borgtech.ca>
Subject: Weird situation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 22:27:02 -0000
Here I am again, experimenting with FreeBSD on the network.
My last questions here helped me get a firewall to help our network.
Now, I have a test setup in a virtual environment=85 but I have a =
problem.
(why else would I be writing here then?). At the moment I have no clue =
what
to even look up on Google or the archives (so all I=92ve been able to do =
at
the moment is experiment).
The problem: traffic is flowing through one way, not back, through a =
test
environment.
The setup:
Main connection:
Router -> [vlan0][fxp1] firewall (production) [fxp0][vlan1] -> managed
switch, cuts off the vlan tag.
>From the switch -> secondary switch -> {FreeBSD test firewall -> FreeBSD
test server}
The two servers between '{' and '}' are running inside virtual PC on a
windows 2000 server (the best I could make up for a "lab"). They were =
build
by having the test firewall de0 linked with the physical nic, and de1 to =
a
"Microsoft loopback adapter", de0 of the test server as well.
Problem:
Pings from the test server at the end of the chain to the router don't =
come
back all the way.
Tests to date:
I've been using tcpdump -i {interface} "host {test_ip}" at each stage.
At the main firewall, tcpdump shows both request and reply, no problem.
On the win2k server, ethereal shows both request and reply, no problem.
On the test firewall, I see only the outgoing ICMP ping request.
At all points, the TTL seems fine (still 255 when captured by the win2k
server).
So I wondered, is virtual PC not sending the packet along?
But the freebsd firewall server can ping the router no problem.
What about the communication between the two freebsd servers?
Ping works with no problem at all.
The test firewall is as open as I can make, it is built with the same =
kernel
configuration as the production firewall, it is enabled in rc.conf with =
type
OPEN.
I'm not sure I know what to do about this problem at the moment, And
therefore ask if anybody knows what I could do about this?
Writing allll this down, I had a crazy idea that depresses me... what if
Virtual PC is not respecting the PROMISC mode of the virtual network =
card
and then the test server is not seeing traffic not specifically meant =
for
it... :( Can anybody confirm or give any suggestions?
--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
=20
From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 22:38:24 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8FB8516A4CE
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:38:24 +0000 (GMT)
Received: from borgtech.ca (borgtech.ca [216.187.106.216])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1347B43D1D
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:38:24 +0000 (GMT)
(envelope-from asegu@borgtech.ca)
Received: from asegulaptop (unknown [161.53.212.129])
by borgtech.ca (Postfix) with ESMTP id 15DEA54AA
for <freebsd-net@freebsd.org>; Sun, 23 Jan 2005 22:42:52 +0000 (GMT)
From: "Andrew Seguin" <asegu@borgtech.ca>
To: <freebsd-net@freebsd.org>
Date: Sun, 23 Jan 2005 23:37:09 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcUBmnxv1/7yLmEbSNKwVODRtEHJJQAANx/A
In-Reply-To: <20050123223130.A997254A5@borgtech.ca>
Message-Id: <20050123224252.15DEA54AA@borgtech.ca>
Subject: RE: Weird situation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2005 22:38:24 -0000
I apologize for hitting the send button too quickly.
Once all noted down, it clicked in my mind that virtual pc mustn't be
respecting the PROMISCUOUS mode of the virtual network card. Once I had =
a
question in mind, a google search answered that yes, that is a =
limitation of
virtual PC. So, *sigh* there goes a day of installation and preparation.
So the only remaining solution I can imagine, is... does anybody have an
idea how I could have the virtual firewall test server register itself =
for
the IP address of the second test server and still function as a gateway
properly (it does have the two nics bridged)? Maybe using ipfw to =
forward
the traffic by MAC address? I'm going to sleep on it, anybody with =
advice
would receive my full gratitude!
Andrew
-----Original Message-----
From: owner-freebsd-net@freebsd.org =
[mailto:owner-freebsd-net@freebsd.org]
On Behalf Of Andrew Seguin
Sent: Sunday, January 23, 2005 11:26 PM
To: freebsd-net@freebsd.org
Subject: Weird situation
Here I am again, experimenting with FreeBSD on the network.
My last questions here helped me get a firewall to help our network.
Now, I have a test setup in a virtual environment=85 but I have a =
problem.
(why else would I be writing here then?). At the moment I have no clue =
what
to even look up on Google or the archives (so all I=92ve been able to do =
at
the moment is experiment).
The problem: traffic is flowing through one way, not back, through a =
test
environment.
The setup:
Main connection:
Router -> [vlan0][fxp1] firewall (production) [fxp0][vlan1] -> managed
switch, cuts off the vlan tag.
>From the switch -> secondary switch -> {FreeBSD test firewall -> =
FreeBSD
test server}
The two servers between '{' and '}' are running inside virtual PC on a
windows 2000 server (the best I could make up for a "lab"). They were =
build
by having the test firewall de0 linked with the physical nic, and de1 to =
a
"Microsoft loopback adapter", de0 of the test server as well.
Problem:
Pings from the test server at the end of the chain to the router don't =
come
back all the way.
Tests to date:
I've been using tcpdump -i {interface} "host {test_ip}" at each stage.
At the main firewall, tcpdump shows both request and reply, no problem.
On the win2k server, ethereal shows both request and reply, no problem.
On the test firewall, I see only the outgoing ICMP ping request.
At all points, the TTL seems fine (still 255 when captured by the win2k
server).
So I wondered, is virtual PC not sending the packet along?
But the freebsd firewall server can ping the router no problem.
What about the communication between the two freebsd servers?
Ping works with no problem at all.
The test firewall is as open as I can make, it is built with the same =
kernel
configuration as the production firewall, it is enabled in rc.conf with =
type
OPEN.
I'm not sure I know what to do about this problem at the moment, And
therefore ask if anybody knows what I could do about this?
Writing allll this down, I had a crazy idea that depresses me... what if
Virtual PC is not respecting the PROMISC mode of the virtual network =
card
and then the test server is not seeing traffic not specifically meant =
for
it... :( Can anybody confirm or give any suggestions?
--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
=20
_______________________________________________
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"
--=20
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
=20
--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
=20
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 03:32:18 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 9251D16A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 03:32:18 +0000 (GMT)
Received: from mail.ntmk.ru (mail.ntmk.ru [217.114.241.6])
by mx1.FreeBSD.org (Postfix) with ESMTP id E5F0B43D46
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 03:32:16 +0000 (GMT)
(envelope-from boris@ntmk.ru)
Received: from boris.nikom.ru ([10.1.16.195])
by mail.ntmk.ru with esmtp (Exim 4.34)
id 1CsuxY-0006xz-Gh; Mon, 24 Jan 2005 08:32:12 +0500
Message-ID: <41F46C3C.20205@ntmk.ru>
Date: Mon, 24 Jan 2005 08:32:12 +0500
From: Boris Kovalenko <boris@ntmk.ru>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041228)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brooks Davis <brooks@one-eyed-alien.net>, freebsd-net@freebsd.org
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu>
In-Reply-To: <20050123193711.GB29225@odin.ac.hmc.edu>
Content-Type: multipart/mixed;
boundary="------------010401000303000403050708"
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 03:32:18 -0000
This is a multi-part message in MIME format.
--------------010401000303000403050708
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Brooks Davis wrote:
Hello!
>
>
> I still don't see how this usefull differs from taking action or not
> taking action.
Just more simple to understand (trusted or not trusted vlan (IMHO)), but
taking action via IPFW of course will be more flexible.
>
> What Cisco does is of rather limited relevence IMO. The default case of
> a FreeBSD system is not a bridge or router but a host. We need to
> determine what makes sense for both the bridge/router case and the host
> case. Cisco's are for all practical purposes, not hosts.
Thinking my idea satisfies router/bridge an host as well. We may set
value or may pass-trough it.
> I've found at least one refrence when googling for 802.1p which says
> that vlan 0 is reserved and means that the tag is only a priority. In
> that case there is no vlan and I don't think vlan devices should be
> involved. If they are, you must set the priority on every frame or
> priority and non-priority frames will be delivered to different
> intefaces which may or may not be what you want.
>
> I'm not 100% sure that's correct, but the IEEE has made it practialy
> impossiable to find 802.1p. I haven't found it yet.
Augh... it that case. Yes, VLID==0 is reserved for "priority" packets,
but it should not be used in usual way. And this packet will have full
802.1Q header indeed.
>>
>> And what this changes? Some switches totally ignore 802.1p. We're
>>talking about IEEE standard and should fully support it. Also, may You
>>point me where You have read this?
>
>
> The issue is that you may need the ability to treat some values as
> though they are the same because some network environments will do this.
Don't think that. What to do with each value is our own decision and
only when we want to implement priority queues, in all other cases we
may just ignore it (this way FreeBSD currently does).
>
> While I think a lower level solution will be the most useful in the
> end, I don't object to an interface based solution. I think you should
> proceed with that with the idea that you add a third, optional keyword
> to vlan initalization to specify priority. That way you can create
> seperate interfaces for each priority for any vlan tag. Something like:
>
> ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3
But this is already done with my patch!!! :))) Have You seen it? I've
added also ability to set apropriate CFI. Attached patch again to this
message. Please review it again :)
>
> -- Brooks
>
--
With respect,
Boris
--------------010401000303000403050708
Content-Type: text/plain;
name="patch-8021p.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch-8021p.diff"
--- sbin/ifconfig/ifconfig.h.orig Wed Jan 19 10:44:20 2005
+++ sbin/ifconfig/ifconfig.h Fri Jan 21 09:11:22 2005
@@ -49,6 +49,8 @@
extern void setvlantag(const char *, int, int, const struct afswtch *rafp);
extern void setvlandev(const char *, int, int, const struct afswtch *rafp);
+extern void setvlanpri(const char *, int, int, const struct afswtch *rafp);
+extern void setvlancfi(const char *, int, int, const struct afswtch *rafp);
extern void unsetvlandev(const char *, int, int, const struct afswtch *rafp);
extern void vlan_status(int s, struct rt_addrinfo *);
--- sbin/ifconfig/ifconfig.c.orig Wed Jan 19 10:56:44 2005
+++ sbin/ifconfig/ifconfig.c Fri Jan 21 09:11:54 2005
@@ -247,6 +247,8 @@
#endif
#ifdef USE_VLANS
{ "vlan", NEXTARG, setvlantag },
+ { "vlanpri", NEXTARG, setvlanpri },
+ { "vlancfi", NEXTARG, setvlancfi },
{ "vlandev", NEXTARG, setvlandev },
{ "-vlandev", NEXTARG, unsetvlandev },
#endif
--- sbin/ifconfig/ifvlan.c.orig Thu Apr 18 23:14:09 2002
+++ sbin/ifconfig/ifvlan.c Fri Jan 21 12:19:38 2005
@@ -59,6 +59,8 @@
"$FreeBSD: src/sbin/ifconfig/ifvlan.c,v 1.5 2002/04/18 17:14:09 imp Exp $";
#endif
static int __tag = 0;
+static int __pri = 0;
+static int __cfi = 0;
static int __have_tag = 0;
void
@@ -72,9 +74,10 @@
if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
return;
- printf("\tvlan: %d parent interface: %s\n",
- vreq.vlr_tag, vreq.vlr_parent[0] == '\0' ?
- "<none>" : vreq.vlr_parent);
+ printf("\tvlan: %d 802.1p: %d CFI: %d parent interface: %s \n",
+ EVL_VLANOFTAG(vreq.vlr_tag), EVL_PRIOFTAG(vreq.vlr_tag),
+ EVL_CFIOFTAG(vreq.vlr_tag),
+ vreq.vlr_parent[0] == '\0' ? "<none>" : vreq.vlr_parent );
return;
}
@@ -88,13 +91,66 @@
__tag = tag = atoi(val);
__have_tag = 1;
+ if(tag < 1 || tag > 4094)
+ errx(1, "VLAN ID shoud be in range 1..4094");
+
+ bzero((char *)&vreq, sizeof(struct vlanreq));
+ ifr.ifr_data = (caddr_t)&vreq;
+
+ if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGETVLAN");
+
+ vreq.vlr_tag = EVL_MAKETAG(tag, __pri, __cfi);
+
+ if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSETVLAN");
+
+ return;
+}
+
+void
+setvlanpri(const char *val, int d, int s, const struct afswtch *afp)
+{
+ u_int16_t pri;
+ struct vlanreq vreq;
+
+ __pri = pri = atoi(val);
+
+ if(pri > 7)
+ errx(1, "VLAN 802.1p shoud be in range 0..7");
+
+ bzero((char *)&vreq, sizeof(struct vlanreq));
+ ifr.ifr_data = (caddr_t)&vreq;
+
+ if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGETVLAN");
+
+ vreq.vlr_tag = EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), pri, __cfi);
+
+ if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSETVLAN");
+
+ return;
+}
+
+void
+setvlancfi(const char *val, int d, int s, const struct afswtch *afp)
+{
+ u_int16_t cfi;
+ struct vlanreq vreq;
+
+ __cfi = cfi = atoi(val);
+
+ if(cfi > 1)
+ errx(1, "VLAN CFI shoud be 0 or 1");
+
bzero((char *)&vreq, sizeof(struct vlanreq));
ifr.ifr_data = (caddr_t)&vreq;
if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCGETVLAN");
- vreq.vlr_tag = tag;
+ vreq.vlr_tag = EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), __pri, cfi);
if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCSETVLAN");
@@ -117,7 +173,7 @@
err(1, "SIOCGETVLAN");
strncpy(vreq.vlr_parent, val, sizeof(vreq.vlr_parent));
- vreq.vlr_tag = __tag;
+ vreq.vlr_tag = EVL_MAKETAG(__tag, __pri, __cfi);
if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCSETVLAN");
--- sbin/ifconfig/ifconfig.8.orig Thu Sep 30 20:25:39 2004
+++ sbin/ifconfig/ifconfig.8 Fri Jan 21 09:39:24 2005
@@ -386,15 +386,35 @@
pseudo interface, set the VLAN tag value
to
.Ar vlan_tag .
-This value is a 16-bit number which is used to create an 802.1Q
+This value is a 12-bit number which is used to create an 802.1Q
VLAN header for packets sent from the
.Xr vlan 4
interface.
Note that
-.Cm vlan
+.Cm vlan, vlanpri, vlancfi
and
.Cm vlandev
-must both be set at the same time.
+must be set at the same time.
+.It Cm vlanpri Ar vlan_pri
+If the interface is a
+.Xr vlan 4
+pseudo interface, set the 802.1p priority value
+to
+.Ar vlan_pri .
+This value is a 3-bit number which is used to tag outgoing
+VLAN packtes with apropriate priority. If
+.Cm vlanpri
+is omitted it default to 0.
+.It Cm vlancfi Ar vlan_cfi
+If the interface is a
+.Xr vlan 4
+pseudo interface, set the CFI value
+to
+.Ar vlan_cfi .
+This value is a 1-bit number which is used to tag outgoing
+VLAN packtes with apropriate CFI value. If
+.Cm vlancfi
+is omitted it default to 0.
.It Cm vlandev Ar iface
If the interface is a
.Xr vlan 4
--- sys/net/if_vlan_var.h.orig Mon Jan 19 00:29:04 2004
+++ sys/net/if_vlan_var.h Fri Jan 21 09:46:46 2005
@@ -43,6 +43,8 @@
#define EVL_VLID_MASK 0x0FFF
#define EVL_VLANOFTAG(tag) ((tag) & EVL_VLID_MASK)
#define EVL_PRIOFTAG(tag) (((tag) >> 13) & 7)
+#define EVL_CFIOFTAG(tag) (((tag) >> 12) & 1)
+#define EVL_MAKETAG(vlid,pri,cfi) ((((((pri) & 7) << 1) | ((cfi) & 1)) << 12) | ((vlid) & EVL_VLID_MASK))
/* sysctl(3) tags, for compatibility purposes */
#define VLANCTL_PROTO 1
@@ -52,8 +54,8 @@
* Configuration structure for SIOCSETVLAN and SIOCGETVLAN ioctls.
*/
struct vlanreq {
- char vlr_parent[IFNAMSIZ];
- u_short vlr_tag;
+ char vlr_parent[IFNAMSIZ];
+ u_int16_t vlr_tag;
};
#define SIOCSETVLAN SIOCSIFGENERIC
#define SIOCGETVLAN SIOCGIFGENERIC
--- sys/net/if_vlan.c.orig Wed Jan 19 10:40:32 2005
+++ sys/net/if_vlan.c Fri Jan 21 09:05:45 2005
@@ -930,15 +930,6 @@
error = ENOENT;
break;
}
- /*
- * Don't let the caller set up a VLAN tag with
- * anything except VLID bits.
- */
-
- if (vlr.vlr_tag & ~EVL_VLID_MASK) {
- error = EINVAL;
- break;
- }
VLAN_LOCK();
error = vlan_config(ifv, p);
--------------010401000303000403050708--
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 10:07:22 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 E8E6B16A4CE; Mon, 24 Jan 2005 10:07:21 +0000 (GMT)
Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 233C743D46; Mon, 24 Jan 2005 10:07:21 +0000 (GMT)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68])
by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j0OA7I0e019596
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
Mon, 24 Jan 2005 13:07:19 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
by cell.sick.ru (8.12.11/8.12.8) with ESMTP id j0OA7IC5047896
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 24 Jan 2005 13:07:18 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
by cell.sick.ru (8.12.11/8.12.11/Submit) id j0OA7IcK047895;
Mon, 24 Jan 2005 13:07:18 +0300 (MSK)
(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
glebius@freebsd.org using -f
Date: Mon, 24 Jan 2005 13:07:17 +0300
From: Gleb Smirnoff <glebius@freebsd.org>
To: julian@freebsd.org, brooks@freebsd.org, andre@freebsd.org
Message-ID: <20050124100717.GA47663@cell.sick.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: ClamAV version devel-20050119, clamav-milter version 0.80ff
on relay.bestcom.ru
X-Virus-Status: Clean
cc: net@freebsd.org
Subject: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 10:07:22 -0000
Dear collegues,
pls review an updated patch bringing in ng_ipfw node. Differencies against
previous patch:
- packets coming from netgraph are queued, and later serviced by netisr
- "ngtee" keyword introduced. A copy of packet is made, and it is sent
into netgraph. No tagging is done. Original packet is either accepted or
continues check against rules, depending on net.inet.ip.fw.one_pass.
Target users are the ones, who are going to do ip accounting/netflow via
ng_ipfw.
- a bit more comments in code
URL: http://people.freebsd.org/~glebius/totest/ng_ipfw.patch
A sample setup:
+ ls
There are 6 total nodes:
Name: <unnamed> Type: hole ID: 00000009 Num hooks: 1
Name: netflow Type: netflow ID: 00000008 Num hooks: 2
Name: ngctl768 Type: socket ID: 00000007 Num hooks: 0
Name: <unnamed> Type: hole ID: 00000006 Num hooks: 1
Name: <unnamed> Type: echo ID: 00000004 Num hooks: 1
Name: ipfw Type: ipfw ID: 00000001 Num hooks: 3
+ show ipfw:
Name: ipfw Type: ipfw ID: 00000001 Num hooks: 3
Local hook Peer name Peer type Peer ID Peer hook
---------- --------- --------- ------- ---------
555 netflow netflow 00000008 iface0
666 <unnamed> hole 00000006 qqq
100 <unnamed> echo 00000004 qqq
+
root@jujik:~:|>ipfw show
00100 0 0 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
00400 14927 61918948 netgraph 100 ip from any to any
00500 14927 61918948 ngtee 666 ip from any to any
00600 7477 1067060 ngtee 555 ip from any to any in
65000 14927 61918948 allow ip from any to any
65535 0 0 deny ip from any to any
root@jujik:~:|>sysctl net.inet.ip.fw.one_pass
net.inet.ip.fw.one_pass: 0
On Mon, Jan 17, 2005 at 11:06:10PM +0300, Gleb Smirnoff wrote:
> Dear collegues,
>
> here is quite a simple node for direct interaction between ipfw(4)
> and netgraph(4). It is going to be more effective and error-prone
> than a complicated construction around divert socket and ng_ksocket[1].
>
> The semantics of node operation are quite simple. There is one node
> per system, which accepts any hooks with numeric names. Packets
> can be sent to netgraph(4) using ipfw 'netgraph' action, followed
> by a numeric cookie. Matched packets are sent out from corresponding
> hook of ng_ipfw node. These packets are tagged with information which
> helps them later to reenter ipfw processing. Tagged packets received on
> any node hook reenter IP stack. If net.inet.ip.fw.one_pass sysctl is non
> zero they are accepted, otherwise they continue with next rule. Non-tagged
> packets (not originating from ng_ipfw node) are discarded.
>
> Here is sample configuration. ng_echo(4) echoes packets back from netgraph
> to ipfw thru a tee node, which allows to sniff traffic.
>
> ngctl
> + ls
> There are 4 total nodes:
> Name: ngctl6138 Type: socket ID: 0000000c Num hooks: 0
> Name: ipfw Type: ipfw ID: 00000009 Num hooks: 1
> Name: <unnamed> Type: echo ID: 00000006 Num hooks: 1
> Name: tee Type: tee ID: 00000005 Num hooks: 2
> + show ipfw:
> Name: ipfw Type: ipfw ID: 00000009 Num hooks: 1
> Local hook Peer name Peer type Peer ID Peer hook
> ---------- --------- --------- ------- ---------
> 666 tee tee 00000005 left
> + show tee:
> Name: tee Type: tee ID: 00000005 Num hooks: 2
> Local hook Peer name Peer type Peer ID Peer hook
> ---------- --------- --------- ------- ---------
> left ipfw ipfw 00000009 666
> right <unnamed> echo 00000006 echi
>
> root@jujik:/usr/src:|>ipfw show
> 00100 292 40304 allow ip from any to any via lo0
> 00200 0 0 deny ip from any to 127.0.0.0/8
> 00300 0 0 deny ip from 127.0.0.0/8 to any
> 00350 290730 661428793 netgraph 666 ip from any to any
> 65000 627921 1896034399 allow ip from any to any
> 65535 0 0 deny ip from any to any
>
> The patch [2] is applicable only to HEAD, sorry. The target users are
> the ones, who are now running ip_accounting/netflow using diverted
> ng_ksocket, and just netgraph geeks.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 11:02:11 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 DB7AF16A506
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 11:02:11 +0000 (GMT)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
by mx1.FreeBSD.org (Postfix) with ESMTP id ACB4F43D48
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 11:02:11 +0000 (GMT)
(envelope-from owner-bugmaster@freebsd.org)
Received: from freefall.freebsd.org (peter@localhost [127.0.0.1])
by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0OB2Auf018950
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 11:02:10 GMT
(envelope-from owner-bugmaster@freebsd.org)
Received: (from peter@localhost)
by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0OB2AUI018944
for freebsd-net@freebsd.org; Mon, 24 Jan 2005 11:02:10 GMT
(envelope-from owner-bugmaster@freebsd.org)
Date: Mon, 24 Jan 2005 11:02:10 GMT
Message-Id: <200501241102.j0OB2AUI018944@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: peter set sender to
owner-bugmaster@freebsd.org using -f
From: FreeBSD bugmaster <bugmaster@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 11:02:12 -0000
Current FreeBSD problem reports
Critical problems
Serious problems
S Submitted Tracker Resp. Description
-------------------------------------------------------------------------------
o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap
1 problem total.
Non-critical problems
S Submitted Tracker Resp. Description
-------------------------------------------------------------------------------
o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit
1 problem total.
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 13:40:43 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7F6DA16A4CE; Mon, 24 Jan 2005 13:40:43 +0000 (GMT)
Received: from mccinet.ru (relay.cell.ru [212.119.96.41])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 3C83D43D45; Mon, 24 Jan 2005 13:40:42 +0000 (GMT)
(envelope-from dolgop@mccinet.ru)
Received: from [212.1.235.150] (HELO server.dep624)
by mccinet.ru (CommuniGate Pro SMTP 4.2.8)
with ESMTP-TLS id 15617820; Mon, 24 Jan 2005 16:40:40 +0300
From: Evgeny Dolgopiat <dolgop@mccinet.ru>
To: "Pawel Jakub Dawidek" <pjd@FreeBSD.org>
Date: Mon, 24 Jan 2005 16:41:36 +0300
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200501241641.36863.dolgop@mccinet.ru>
cc: freebsd-net@FreeBSD.ORG
Subject: Re: New failure detection algorithm for ng_one2many(4).
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: evg_dolgop@mail.ru
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 13:40:43 -0000
> Hello.
>
> Patch below adds new failure detection algorithm for ng_one2many(4).
> For now, the only such algorithm doesn't detect failures, one have
> to show active links manually.
>
> http://garage.freebsd.pl/patches/netgraph_one2many.patch
>
> The way how to use this module (ng_one2many) is described in manual
> page, to made use of new algorithm one should execute:
>
> ngctl msg fxp0:upper setconfig "{ xmitAlg=3D1 failAlg=3D2
>interval=3D5 }"
>
> Value '5' after interval means: check interfaces every 5 seconds.
>If interface will be down it will not be used.
>
>Note that 'one' interface have to be always avaliable.
>
>Any comments, etc. are of course welcome
Hello. Did you see my patch?
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=92946+0+archive/2005/freebsd-net/20050116.freebsd-net
Heartbeat signal has some advantages as compared to ioctl function. All subnet
containing failed element (card or hub) marked as failed. Therefore packets
sended from other hosts to host, holding failed element, wouldn't lost. Other
advantage: now heartbeat algorithm working independently of the layer on
which one2many operates (not only for ethernet).
Some time ago (october 2003) I sent first version of this patch in mailing
list and got some replies from people, using STABLE (4.X). But this patch
could be used only for 5.X, not stable at that time. Now 5.3 is stable and
this patch can be used for it.
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 16:02:52 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 D2B3816A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 16:02:52 +0000 (GMT)
Received: from us.svf.stuba.sk (us.svf.stuba.sk [147.175.16.9])
by mx1.FreeBSD.org (Postfix) with ESMTP id 308DF43D49
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 16:02:52 +0000 (GMT)
(envelope-from md@us.svf.stuba.sk)
Received: from us.svf.stuba.sk (localhost [127.0.0.1])
by us.svf.stuba.sk (8.13.1/8.13.1) with ESMTP id j0OG2lVb093626
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 17:02:48 +0100 (CET)
(envelope-from md@us.svf.stuba.sk)
Received: (from md@localhost)
by us.svf.stuba.sk (8.13.1/8.13.1/Submit) id j0OG2gs1093621
for freebsd-net@freebsd.org; Mon, 24 Jan 2005 17:02:42 +0100 (CET)
(envelope-from md)
Date: Mon, 24 Jan 2005 17:02:42 +0100
From: Marian Durkovic <md@bts.sk>
To: freebsd-net@freebsd.org
Message-ID: <20050124160242.GA91593@us.svf.stuba.sk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: ClamAV 0.80/648/Sun Jan 2 09:18:38 2005
clamav-milter version 0.80j
on us.svf.stuba.sk
X-Virus-Status: Clean
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on us.svf.stuba.sk
Subject: Making ICMP the default traceroute protocol?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 16:02:52 -0000
Hi all,
seems that in today's networking environment the original traceroute
concept utilising high UDP ports no longer works - since those ports
are now typically blocked by firewalls.
However, when traceroute is performed using ICMP protocol, the results
are much better.
Therefore, I'd like to propose to patch
src/contrib/traceroute/traceroute.c
so the ICMP protocol is the first one in
struct outproto protos[] = {
and thus the default protocol used by traceroute.
With kind regards,
M.
--------------------------------------------------------------------------
---- ----
---- Marian Durkovic network manager ----
---- ----
---- Slovak Technical University Tel: +421 2 524 51 301 ----
---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ----
---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ----
---- ----
--------------------------------------------------------------------------
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 17:06:53 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 52F9516A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 17:06:53 +0000 (GMT)
Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75])
by mx1.FreeBSD.org (Postfix) with ESMTP id DFC9043D1D
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 17:06:52 +0000 (GMT)
(envelope-from brdavis@odin.ac.hmc.edu)
Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1])
by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0OH7ZkF028952;
Mon, 24 Jan 2005 09:07:35 -0800
Received: (from brdavis@localhost)
by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0OH7ZYl028950;
Mon, 24 Jan 2005 09:07:35 -0800
Date: Mon, 24 Jan 2005 09:07:35 -0800
From: Brooks Davis <brooks@one-eyed-alien.net>
To: Boris Kovalenko <boris@ntmk.ru>
Message-ID: <20050124170735.GA26830@odin.ac.hmc.edu>
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu> <41F46C3C.20205@ntmk.ru>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline
In-Reply-To: <41F46C3C.20205@ntmk.ru>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu
cc: freebsd-net@freebsd.org
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 17:06:53 -0000
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 24, 2005 at 08:32:12AM +0500, Boris Kovalenko wrote:
> Brooks Davis wrote:
> Hello!
>=20
> >
> >
> >I still don't see how this usefull differs from taking action or not
> >taking action.
> Just more simple to understand (trusted or not trusted vlan (IMHO)), but=
=20
> taking action via IPFW of course will be more flexible.
I disagree it's more simple.
> >While I think a lower level solution will be the most useful in the
> >end, I don't object to an interface based solution. I think you should
> >proceed with that with the idea that you add a third, optional keyword
> >to vlan initalization to specify priority. That way you can create
> >seperate interfaces for each priority for any vlan tag. Something like:
> >
> >ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3
> But this is already done with my patch!!! :))) Have You seen it? I've=20
> added also ability to set apropriate CFI. Attached patch again to this=20
> message. Please review it again :)
I missread your patch before. Sorry about that. Overall, this seems
like a step forward. I would like this interface to be labled as
subject to change in the ifconfig manpage so that a solution that does
not treat different priorities as seperate interfaces is not precluded
by this specific implementation. I'm sure we can keep an interface that
handles priorities as seperate interfaces, but I'm not sure we'll want
to do it via the vlan device (attractivly simple though that is.)
This patch appears to be against 4 or 5. In 6 we've largly rewritten
ifconfig so the patch won't apply. It looks like a simple matter to fix
this issue. We'll need to commit to 6 before 4 or 5.
I've embeded some comments in the text below.
-- Brooks
> --- sbin/ifconfig/ifconfig.h.orig Wed Jan 19 10:44:20 2005
> +++ sbin/ifconfig/ifconfig.h Fri Jan 21 09:11:22 2005
> @@ -49,6 +49,8 @@
> =20
> extern void setvlantag(const char *, int, int, const struct afswtch *raf=
p);
> extern void setvlandev(const char *, int, int, const struct afswtch *raf=
p);
> +extern void setvlanpri(const char *, int, int, const struct afswtch *raf=
p);
> +extern void setvlancfi(const char *, int, int, const struct afswtch *raf=
p);
> extern void unsetvlandev(const char *, int, int, const struct afswtch *r=
afp);
> extern void vlan_status(int s, struct rt_addrinfo *);
> =20
> --- sbin/ifconfig/ifconfig.c.orig Wed Jan 19 10:56:44 2005
> +++ sbin/ifconfig/ifconfig.c Fri Jan 21 09:11:54 2005
> @@ -247,6 +247,8 @@
> #endif
> #ifdef USE_VLANS
> { "vlan", NEXTARG, setvlantag },
> + { "vlanpri", NEXTARG, setvlanpri },
> + { "vlancfi", NEXTARG, setvlancfi },
> { "vlandev", NEXTARG, setvlandev },
> { "-vlandev", NEXTARG, unsetvlandev },
> #endif
> --- sbin/ifconfig/ifvlan.c.orig Thu Apr 18 23:14:09 2002
> +++ sbin/ifconfig/ifvlan.c Fri Jan 21 12:19:38 2005
> @@ -59,6 +59,8 @@
> "$FreeBSD: src/sbin/ifconfig/ifvlan.c,v 1.5 2002/04/18 17:14:09 imp Ex=
p $";
> #endif
> static int __tag =3D 0;
> +static int __pri =3D 0;
> +static int __cfi =3D 0;
> static int __have_tag =3D 0;
> =20
> void
> @@ -72,9 +74,10 @@
> if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) =3D=3D -1)
> return;
> =20
> - printf("\tvlan: %d parent interface: %s\n",
> - vreq.vlr_tag, vreq.vlr_parent[0] =3D=3D '\0' ?
> - "<none>" : vreq.vlr_parent);
> + printf("\tvlan: %d 802.1p: %d CFI: %d parent interface: %s \n",
> + EVL_VLANOFTAG(vreq.vlr_tag), EVL_PRIOFTAG(vreq.vlr_tag),
> + EVL_CFIOFTAG(vreq.vlr_tag),
> + vreq.vlr_parent[0] =3D=3D '\0' ? "<none>" : vreq.vlr_parent );
> =20
> return;
> }
> @@ -88,13 +91,66 @@
> __tag =3D tag =3D atoi(val);
> __have_tag =3D 1;
> =20
> + if(tag < 1 || tag > 4094)
> + errx(1, "VLAN ID shoud be in range 1..4094");
errx should be fully indented.
> +
> + bzero((char *)&vreq, sizeof(struct vlanreq));
> + ifr.ifr_data =3D (caddr_t)&vreq;
> +
> + if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) =3D=3D -1)
> + err(1, "SIOCGETVLAN");
> +
> + vreq.vlr_tag =3D EVL_MAKETAG(tag, __pri, __cfi);
> +
> + if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) =3D=3D -1)
> + err(1, "SIOCSETVLAN");
> +
> + return;
> +}
> +
> +void
> +setvlanpri(const char *val, int d, int s, const struct afswtch *afp)
> +{
> + u_int16_t pri;
> + struct vlanreq vreq;
> +
> + __pri =3D pri =3D atoi(val);
I know other nearby code does this, but atoi should not be used. It has
not useful error checking. strtoul should be used instead.
> +
> + if(pri > 7)
> + errx(1, "VLAN 802.1p shoud be in range 0..7");
errx should be fully indented.
> +
> + bzero((char *)&vreq, sizeof(struct vlanreq));
> + ifr.ifr_data =3D (caddr_t)&vreq;
> +
> + if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) =3D=3D -1)
> + err(1, "SIOCGETVLAN");
> +
> + vreq.vlr_tag =3D EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), pri, __cfi);
> +
> + if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) =3D=3D -1)
> + err(1, "SIOCSETVLAN");
> +
> + return;
> +}
> +
> +void
> +setvlancfi(const char *val, int d, int s, const struct afswtch *afp)
> +{
> + u_int16_t cfi;
> + struct vlanreq vreq;
> +
> + __cfi =3D cfi =3D atoi(val);
strtoul
> +
> + if(cfi > 1)
> + errx(1, "VLAN CFI shoud be 0 or 1");
indent.
> +
> bzero((char *)&vreq, sizeof(struct vlanreq));
> ifr.ifr_data =3D (caddr_t)&vreq;
> =20
> if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) =3D=3D -1)
> err(1, "SIOCGETVLAN");
> =20
> - vreq.vlr_tag =3D tag;
> + vreq.vlr_tag =3D EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), __pri, cfi);
> =20
> if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) =3D=3D -1)
> err(1, "SIOCSETVLAN");
> @@ -117,7 +173,7 @@
> err(1, "SIOCGETVLAN");
> =20
> strncpy(vreq.vlr_parent, val, sizeof(vreq.vlr_parent));
> - vreq.vlr_tag =3D __tag;
> + vreq.vlr_tag =3D EVL_MAKETAG(__tag, __pri, __cfi);
> =20
> if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) =3D=3D -1)
> err(1, "SIOCSETVLAN");
> --- sbin/ifconfig/ifconfig.8.orig Thu Sep 30 20:25:39 2004
> +++ sbin/ifconfig/ifconfig.8 Fri Jan 21 09:39:24 2005
> @@ -386,15 +386,35 @@
> pseudo interface, set the VLAN tag value
> to
> .Ar vlan_tag .
> -This value is a 16-bit number which is used to create an 802.1Q
> +This value is a 12-bit number which is used to create an 802.1Q
> VLAN header for packets sent from the
> .Xr vlan 4
> interface.
> Note that
> -.Cm vlan
> +.Cm vlan, vlanpri, vlancfi
> and
> .Cm vlandev
> -must both be set at the same time.
> +must be set at the same time.
> +.It Cm vlanpri Ar vlan_pri
> +If the interface is a
> +.Xr vlan 4
> +pseudo interface, set the 802.1p priority value
> +to
> +.Ar vlan_pri .
> +This value is a 3-bit number which is used to tag outgoing
> +VLAN packtes with apropriate priority. If
> +.Cm vlanpri
> +is omitted it default to 0.
> +.It Cm vlancfi Ar vlan_cfi
> +If the interface is a
> +.Xr vlan 4
> +pseudo interface, set the CFI value
> +to
> +.Ar vlan_cfi .
> +This value is a 1-bit number which is used to tag outgoing
> +VLAN packtes with apropriate CFI value. If
> +.Cm vlancfi
> +is omitted it default to 0.
> .It Cm vlandev Ar iface
> If the interface is a
> .Xr vlan 4
> --- sys/net/if_vlan_var.h.orig Mon Jan 19 00:29:04 2004
> +++ sys/net/if_vlan_var.h Fri Jan 21 09:46:46 2005
> @@ -43,6 +43,8 @@
> #define EVL_VLID_MASK 0x0FFF
> #define EVL_VLANOFTAG(tag) ((tag) & EVL_VLID_MASK)
> #define EVL_PRIOFTAG(tag) (((tag) >> 13) & 7)
> +#define EVL_CFIOFTAG(tag) (((tag) >> 12) & 1)
> +#define EVL_MAKETAG(vlid,pri,cfi) ((((((pri) & 7) << 1) | ((cfi) & 1)) <=
< 12) | ((vlid) & EVL_VLID_MASK))
> =20
> /* sysctl(3) tags, for compatibility purposes */
> #define VLANCTL_PROTO 1
> @@ -52,8 +54,8 @@
> * Configuration structure for SIOCSETVLAN and SIOCGETVLAN ioctls.
> */
> struct vlanreq {
> - char vlr_parent[IFNAMSIZ];
> - u_short vlr_tag;
> + char vlr_parent[IFNAMSIZ];
> + u_int16_t vlr_tag;
This appears to be a no-op. Is it needed?
> };
> #define SIOCSETVLAN SIOCSIFGENERIC
> #define SIOCGETVLAN SIOCGIFGENERIC
> --- sys/net/if_vlan.c.orig Wed Jan 19 10:40:32 2005
> +++ sys/net/if_vlan.c Fri Jan 21 09:05:45 2005
> @@ -930,15 +930,6 @@
> error =3D ENOENT;
> break;
> }
> - /*
> - * Don't let the caller set up a VLAN tag with
> - * anything except VLID bits.
> - */
> -
> - if (vlr.vlr_tag & ~EVL_VLID_MASK) {
> - error =3D EINVAL;
> - break;
> - }
> =20
> VLAN_LOCK();
> error =3D vlan_config(ifv, p);
--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFB9StWXY6L6fI4GtQRAjSRAJwJuhA1WoTNQCoLqpoKNw46G1Y9CgCg5VP6
sQQb1Bxqd9yHFZqUXgqS7E0=
=srEQ
-----END PGP SIGNATURE-----
--J2SCkAp4GZ/dPZZf--
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 18:02:07 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8587916A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 18:02:07 +0000 (GMT)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213])
by mx1.FreeBSD.org (Postfix) with ESMTP id 19CE943D46
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 18:02:07 +0000 (GMT)
(envelope-from gaylord@dirtcheapemail.com)
Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu
[10.1.1.12])
by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j0OI26Pd010298
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 13:02:06 -0500
Received: from [127.0.0.1] (locust.cns.vt.edu [198.82.169.14])
by vivi.cc.vt.edu (MOS 3.5.6-GR)
with ESMTP id CLW47928;
Mon, 24 Jan 2005 13:02:00 -0500 (EST)
Message-ID: <41F537E1.40500@dirtcheapemail.com>
Date: Mon, 24 Jan 2005 13:01:05 -0500
From: Clark Gaylord <gaylord@dirtcheapemail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041217
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: [Fwd: Re: Making ICMP the default traceroute protocol?]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 18:02:07 -0000
Marian Durkovic wrote:
> seems that in today's networking environment the original traceroute
>concept utilising high UDP ports no longer works - since those ports
>are now typically blocked by firewalls.
>
> However, when traceroute is performed using ICMP protocol, the results
>are much better.
>
> Therefore, I'd like to propose to patch
>
>src/contrib/traceroute/traceroute.c
>
> so the ICMP protocol is the first one in
I disagree. Firstly, IWFs tend to also block ICMP. Secondly, routers
sometimes queue ICMP differently than UDP (not just in their own
processing, which they almost always do, but also in their forwarding),
giving even more distortion to these data than they naturally possess
otherwise. In particular, if filtering happens, this becomes obvious;
if differential queueing happens, it is difficult to notice that is
likely what is happening as it doesn't break the trace, it just distorts
the data. Finally, knowing that there is some IWF between me and the
destination is usually a good indication of where a performance problem
resides. ;-)
This is most likely to make a difference at the end hop itself, though
of course filtering can happen anywhere along the path.
If you are finding that your destinations tend to need ICMP, I'd
recommend aliasing traceroute to "traceroute -I".
--ckg
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 18:04:07 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 0D30816A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 18:04:07 +0000 (GMT)
Received: from us.svf.stuba.sk (us.svf.stuba.sk [147.175.16.9])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4B4C443D55
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 18:04:06 +0000 (GMT)
(envelope-from md@us.svf.stuba.sk)
Received: from us.svf.stuba.sk (localhost [127.0.0.1])
by us.svf.stuba.sk (8.13.1/8.13.1) with ESMTP id j0OI41wc097081
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 19:04:02 +0100 (CET)
(envelope-from md@us.svf.stuba.sk)
Received: (from md@localhost)
by us.svf.stuba.sk (8.13.1/8.13.1/Submit) id j0OI3uWl097080
for freebsd-net@freebsd.org; Mon, 24 Jan 2005 19:03:56 +0100 (CET)
(envelope-from md)
Resent-Message-Id: <200501241803.j0OI3uWl097080@us.svf.stuba.sk>
Received: from us.svf.stuba.sk (localhost [127.0.0.1])
by us.svf.stuba.sk (8.13.1/8.13.1) with ESMTP id j0OHsYC2096852;
Mon, 24 Jan 2005 18:54:34 +0100 (CET)
(envelope-from md@us.svf.stuba.sk)
Received: (from md@localhost)
by us.svf.stuba.sk (8.13.1/8.13.1/Submit) id j0OHsT5n096851;
Mon, 24 Jan 2005 18:54:29 +0100 (CET)
(envelope-from md)
Date: Mon, 24 Jan 2005 18:54:29 +0100
From: Marian Durkovic <md@bts.sk>
To: Clark Gaylord <gaylord@dirtcheapemail.com>
Message-ID: <20050124175429.GA96355@us.svf.stuba.sk>
References: <20050124160242.GA91593@us.svf.stuba.sk>
<41F52B41.4090706@dirtcheapemail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41F52B41.4090706@dirtcheapemail.com>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: ClamAV 0.80/648/Sun Jan 2 09:18:38 2005
clamav-milter version 0.80j
on us.svf.stuba.sk
X-Virus-Scanned: ClamAV 0.80/648/Sun Jan 2 09:18:38 2005
clamav-milter version 0.80j
on us.svf.stuba.sk
X-Virus-Status: Clean
X-Virus-Status: Clean
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on us.svf.stuba.sk
Resent-From: md@bts.sk
Resent-Date: Mon, 24 Jan 2005 19:03:56 +0100
Resent-To: freebsd-net@freebsd.org
Subject: Re: Making ICMP the default traceroute protocol?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 18:04:07 -0000
> I disagree. Firstly, IWFs tend to also block ICMP. Secondly, routers
> sometimes queue ICMP differently than UDP (not just in their own
> processing, which they almost always do, but also in their forwarding),
> giving even more distortion to these data than they naturally possess
> otherwise.
Well, that's true, however, the backward packets of traceroute probes
are ICMP "ttl exceeded" anyway...
The main motivation I'm proposing this is significantly less support for
UDP traceroutes that ICMP traceroutes. Several important www sites have
dropped UDP traceroute support (try e.g. www.cisco.com, www.google.com,
www.dtag.de or many many others). Also on intranet level, WinXP boxes
with SP2 installed have no support for UDP traceroutes either.
> If you are finding that your destinations tend to need ICMP, I'd
> recommend aliasing traceroute to "traceroute -I".
Of course I have "traceroute -P icmp" in my alias list for some time,
which fixes the problem for me, however I just think it's better to
have it as default and use UDP/TCP just for experienced users which
exactly know what they're doing...
With kind regards,
M.
--------------------------------------------------------------------------
---- ----
---- Marian Durkovic network manager ----
---- ----
---- Slovak Technical University Tel: +421 2 524 51 301 ----
---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ----
---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ----
---- ----
--------------------------------------------------------------------------
From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 23:21:20 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A796216A4CE
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 23:21:20 +0000 (GMT)
Received: from web30406.mail.mud.yahoo.com (web30406.mail.mud.yahoo.com
[68.142.200.109])
by mx1.FreeBSD.org (Postfix) with SMTP id 2A2EE43D1D
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 23:21:20 +0000 (GMT)
(envelope-from mihaissa@yahoo.com)
Received: (qmail 66194 invoked by uid 60001); 24 Jan 2005 23:21:19 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
b=dU/nZm/61rfmKQ62rwycwvdI2BkP74J9H5OlTGwZper0CyiQZ3fZiA97PzYv2QRPx0NqyrMyLrDNGSCAaEWG1t7FJrztsZIGNoGHk4S9WXYr0Lu7Q5vkMFq4X7193t7+KgX5XORSDql48FCWUlFS1Q0tpV+dQXjWkLd+9Ft/C7U=
;
Message-ID: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
Received: from [193.231.73.33] by web30406.mail.mud.yahoo.com via HTTP;
Mon, 24 Jan 2005 15:21:19 PST
Date: Mon, 24 Jan 2005 15:21:19 -0800 (PST)
From: Mihai Nitulescu <mihaissa@yahoo.com>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
Subject: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2005 23:21:20 -0000
Hi
Can anyone help me out with an issue that i have?
I run 2 FreeBSD 5.3 machines.
First nat.example.com has 2 NIC`s
rl0 (193.231.43.33)
rl1(192.168.0.254)
The machine runs NAT for my LAN (192.168.0.0/24)
In the LAN i have the other machine application.example.com
I have some Public IP`s from my ISP :
193.231.43.25-30
255.255.255.248
I want to assign to application.example.com 193.231.43.27 and to route this ip trough nat.example.com
Any ideea how can i do that ?
Please help.
Regards,
Mihai
---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 00:58:16 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6CF5216A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 00:58:16 +0000 (GMT)
Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176])
by mx1.FreeBSD.org (Postfix) with ESMTP id E8BC443D2F
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 00:58:15 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix4-2.free.fr (Postfix) with ESMTP id 4492A2B8406
for <freebsd-net@freebsd.org>; Mon, 24 Jan 2005 22:20:22 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id 8F2C4407C; Mon, 24 Jan 2005 22:20:11 +0100 (CET)
Date: Mon, 24 Jan 2005 22:20:11 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: freebsd-net@freebsd.org
Message-ID: <20050124212011.GC59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Subject: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 00:58:16 -0000
Hi,
I set up a VPN between a RELENG_4 and a another box. Everything works
well except I can't use tcpdump(8) on the gif(4). IIRC it's a
well-known problem - I already saw this topic here but can't find these
posts again - but I cannot understand why it doesn't work since
if_gif.c in RELENG_4 has bpfattach(), bpf_mtap2(), ...
Is it supposed to work or not ? If not, does it work on RELENG_5 ?
My very -CURRENT laptop succeeds in opening bpf(4) on a gif(4) interface.
Regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 01:15:08 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 E512416A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 01:15:08 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4408543D39
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 01:15:08 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id 501176520E; Tue, 25 Jan 2005 01:15:06 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 08163-01; Tue, 25 Jan 2005 01:15:05 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id 477CB651F7; Tue, 25 Jan 2005 01:15:05 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id 8E19A6383; Tue, 25 Jan 2005 01:16:15 +0000 (GMT)
Date: Tue, 25 Jan 2005 01:16:15 +0000
From: Bruce M Simpson <bms@spc.org>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050125011615.GB47638@dhcp120.icir.org>
Mail-Followup-To: Jeremie Le Hen <jeremie@le-hen.org>,
freebsd-net@freebsd.org
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050124212011.GC59685@obiwan.tataz.chchile.org>
cc: freebsd-net@freebsd.org
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 01:15:09 -0000
On Mon, Jan 24, 2005 at 10:20:11PM +0100, Jeremie Le Hen wrote:
> Is it supposed to work or not ? If not, does it work on RELENG_5 ?
> My very -CURRENT laptop succeeds in opening bpf(4) on a gif(4) interface.
In a previous existence, I was able to tcpdump on a gif(4) interface;
the tunnel was being used so that I could IPSEC-encapsulate multicast
traffic which was necessary to get past some ISP filters (IPIP was
being dropped at the border).
This was in 5.2.1-RELEASE on a sparc64.
Hope this helps,
BMS
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 01:16:52 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 0A92516A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 01:16:52 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id B446843D39
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 01:16:51 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id F327C6520E; Tue, 25 Jan 2005 01:16:50 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 08163-01-3; Tue, 25 Jan 2005 01:16:50 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id 735ED651F7; Tue, 25 Jan 2005 01:16:50 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id DC2166383; Tue, 25 Jan 2005 01:18:00 +0000 (GMT)
Date: Tue, 25 Jan 2005 01:18:00 +0000
From: Bruce M Simpson <bms@spc.org>
To: Mihai Nitulescu <mihaissa@yahoo.com>
Message-ID: <20050125011800.GC47638@dhcp120.icir.org>
Mail-Followup-To: Mihai Nitulescu <mihaissa@yahoo.com>,
freebsd-net@freebsd.org
References: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
cc: freebsd-net@freebsd.org
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 01:16:52 -0000
On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
> I want to assign to application.example.com 193.231.43.27 and to route this ip trough nat.example.com
If you have control over the NAT device, you could set up a point-to-point
tunnel from the NAT device to the machine in the NAT domain; this would
preserve the public IP address but would require additional routing setup
(assuming that the public subnet is routed by the ISP to the NAT device).
Hope this helps,
BMS
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 02:59:46 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 DDAFA16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 02:59:46 +0000 (GMT)
Received: from mx1.purplecat.net (mx1.purplecat.net [64.132.45.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5380F43D4C
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 02:59:46 +0000 (GMT)
(envelope-from peter@purplecat.net)
Received: (qmail 86655 invoked by uid 89); 25 Jan 2005 02:59:45 -0000
Received: by simscan 1.0.8 ppid: 86641, pid: 86643, t: 1.8116s
scanners: attach: 1.0.8 clamav: 0.80/m:28/d:645 spam: 3.0.1
Received: from unknown (HELO k62500) (24.179.22.192)
by mx1.purplecat.net with SMTP; 25 Jan 2005 02:59:43 -0000
From: "Peter Brezny" <peter@purplecat.net>
To: <freebsd-net@freebsd.org>
Date: Mon, 24 Jan 2005 21:59:49 -0500
Message-ID: <BEEKJNELKLKFAANOLIOEEENEFPAA.peter@purplecat.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on rack.purplecat.net
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Subject: mpd pptp packet loss xp client
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 02:59:47 -0000
The packet loss issue with pptp connections from xp clients to mpd servers
appears to be a windows firewall issue.
Disabling windows firewall solved my problem.
It doesn't look like the standard xp firewall knows how to handle gre or ppp
protocols.
I attempted adding tcp port 1723 to the list of allowed ports without
success.
Peter Brezny
purplecat.net
828-250-9446
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 04:16:06 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 460C116A4CF
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 04:16:06 +0000 (GMT)
Received: from mail.ntmk.ru (mail.ntmk.ru [217.114.241.6])
by mx1.FreeBSD.org (Postfix) with ESMTP id 21DEF43D39
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 04:16:05 +0000 (GMT)
(envelope-from boris@ntmk.ru)
Received: from boris.nikom.ru ([10.1.16.195])
by mail.ntmk.ru with esmtp (Exim 4.34)
id 1CtI7W-0001UE-NA; Tue, 25 Jan 2005 09:16:02 +0500
Message-ID: <41F5C802.8010307@ntmk.ru>
Date: Tue, 25 Jan 2005 09:16:02 +0500
From: Boris Kovalenko <boris@ntmk.ru>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041228)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brooks Davis <brooks@one-eyed-alien.net>, freebsd-net@freebsd.org
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu> <41F46C3C.20205@ntmk.ru>
<20050124170735.GA26830@odin.ac.hmc.edu>
In-Reply-To: <20050124170735.GA26830@odin.ac.hmc.edu>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 04:16:06 -0000
Hello!
> by this specific implementation. I'm sure we can keep an interface that
> handles priorities as seperate interfaces, but I'm not sure we'll want
> to do it via the vlan device (attractivly simple though that is.)
>
> This patch appears to be against 4 or 5. In 6 we've largly rewritten
> ifconfig so the patch won't apply. It looks like a simple matter to fix
> this issue. We'll need to commit to 6 before 4 or 5.
>
> I've embeded some comments in the text below.
Ok, so what I should do now? Rewrite patch for 6?
>>+ if(tag < 1 || tag > 4094)
>>+ errx(1, "VLAN ID shoud be in range 1..4094");
>
>
> errx should be fully indented.
What this means? What difference between my errx and this one (from 6)?
errx(1, "must specify both vlan tag and device");
> I know other nearby code does this, but atoi should not be used. It has
> not useful error checking. strtoul should be used instead.
No problem.
>> */
>> struct vlanreq {
>>- char vlr_parent[IFNAMSIZ];
>>- u_short vlr_tag;
>>+ char vlr_parent[IFNAMSIZ];
>>+ u_int16_t vlr_tag;
>
>
> This appears to be a no-op. Is it needed?
Hmm... just to clarify that vlr_tag is 16bit value. If this is
unnecessary I may use u_short.
--
With respect,
Boris
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 06:28:26 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8076316A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 06:28:26 +0000 (GMT)
Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75])
by mx1.FreeBSD.org (Postfix) with ESMTP id 45BA943D48
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 06:28:26 +0000 (GMT)
(envelope-from brdavis@odin.ac.hmc.edu)
Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1])
by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0P6TF5i014407;
Mon, 24 Jan 2005 22:29:15 -0800
Received: (from brdavis@localhost)
by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0P6TEie014406;
Mon, 24 Jan 2005 22:29:14 -0800
Date: Mon, 24 Jan 2005 22:29:14 -0800
From: Brooks Davis <brooks@one-eyed-alien.net>
To: Boris Kovalenko <boris@ntmk.ru>
Message-ID: <20050125062914.GA12771@odin.ac.hmc.edu>
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu> <41F46C3C.20205@ntmk.ru>
<20050124170735.GA26830@odin.ac.hmc.edu> <41F5C802.8010307@ntmk.ru>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
In-Reply-To: <41F5C802.8010307@ntmk.ru>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new
X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu
cc: freebsd-net@freebsd.org
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 06:28:26 -0000
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 25, 2005 at 09:16:02AM +0500, Boris Kovalenko wrote:
> Hello!
>=20
> >by this specific implementation. I'm sure we can keep an interface that
> >handles priorities as seperate interfaces, but I'm not sure we'll want
> >to do it via the vlan device (attractivly simple though that is.)
> >
> >This patch appears to be against 4 or 5. In 6 we've largly rewritten
> >ifconfig so the patch won't apply. It looks like a simple matter to fix
> >this issue. We'll need to commit to 6 before 4 or 5.
> >
> >I've embeded some comments in the text below.
> Ok, so what I should do now? Rewrite patch for 6?
Let's get the version for 5 looking good first since we should be able
to MFC. We can do the ifconfig part for 6 once that's clean.
> >>+ if(tag < 1 || tag > 4094)
> >>+ errx(1, "VLAN ID shoud be in range 1..4094");
> >
> >
> >errx should be fully indented.
> What this means? What difference between my errx and this one (from 6)?
> errx(1, "must specify both vlan tag and device");
err is indented with a tab and four spaces. It should be indented with
two tabs like this:
if(tag < 1 || tag > 4094)
errx(1, "VLAN ID shoud be in range 1..4094");
> >I know other nearby code does this, but atoi should not be used. It has
> >not useful error checking. strtoul should be used instead.
> No problem.
> >> */
> >>struct vlanreq {
> >>- char vlr_parent[IFNAMSIZ];
> >>- u_short vlr_tag;
> >>+ char vlr_parent[IFNAMSIZ];
> >>+ u_int16_t vlr_tag;
> >
> >
> >This appears to be a no-op. Is it needed?
> Hmm... just to clarify that vlr_tag is 16bit value. If this is=20
> unnecessary I may use u_short.
Assuming the code compiles cleanly, let's leave it a u_short in 5. We
can change it to a u_int16_t in 6 since I agree that's more precise.
Changes to types, even ones that obviously don't do anything tend to
make re@ concerned about possible ABI breakage so I'd rather not worry
them. I tend to do that enough with my other projects. :)
-- Brooks
--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFB9ec6XY6L6fI4GtQRAifEAJ9NdixDxCTfDOLqFKChbgHG+SxBUgCfcuCs
D/gASd/vyIJj1Nj5u26pLNk=
=pNkk
-----END PGP SIGNATURE-----
--+QahgC5+KEYLbs62--
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 07:13:42 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2B5C416A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 07:13:42 +0000 (GMT)
Received: from piglet.slowthinkers.net (fia114-101.dsl.hccnet.nl
[62.251.101.114])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6EDA943D1D
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 07:13:40 +0000 (GMT)
(envelope-from marcel@slowthinkers.net)
Received: from piglet.slowthinkers.net (localhost [127.0.0.1])
j0P7DaS0037016
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 07:13:36 GMT
(envelope-from marcel@piglet.slowthinkers.net)
Message-Id: <200501250713.j0P7DaS0037016@piglet.slowthinkers.net>
To: freebsd-net@freebsd.org
In-Reply-To: Message from Mihai Nitulescu <mihaissa@yahoo.com>
<20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
Date: Tue, 25 Jan 2005 07:13:36 +0000
From: Anne Marcel Roorda <marcel@slowthinkers.net>
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 07:13:42 -0000
> I want to assign to application.example.com 193.231.43.27 and to route this i
p trough nat.example.com
>
> Any ideea how can i do that ?
> Please help.
Mihai,
From the man page of natd:
-unregistered_only | -u
Only alter outgoing packets with an unregistered source
address. According to RFC 1918, unregistered source
addresses are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.
That should allow you to use both private space, and assigned
addressess.
You can either add this option to your natd configuration file, or
add it as a command line option.
Regards,
- marcel
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:08:47 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F181316A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 08:08:46 +0000 (GMT)
Received: from mail.ntmk.ru (mail.ntmk.ru [217.114.241.6])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5C42D43D41
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 08:08:45 +0000 (GMT)
(envelope-from boris@ntmk.ru)
Received: from boris.nikom.ru ([10.1.16.195])
by mail.ntmk.ru with esmtp (Exim 4.34)
id 1CtLkh-0008AG-82; Tue, 25 Jan 2005 13:08:43 +0500
Message-ID: <41F5FE8B.40809@ntmk.ru>
Date: Tue, 25 Jan 2005 13:08:43 +0500
From: Boris Kovalenko <boris@ntmk.ru>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041228)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brooks Davis <brooks@one-eyed-alien.net>, freebsd-net@freebsd.org
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu> <41F46C3C.20205@ntmk.ru>
<20050124170735.GA26830@odin.ac.hmc.edu> <41F5C802.8010307@ntmk.ru>
<20050125062914.GA12771@odin.ac.hmc.edu>
In-Reply-To: <20050125062914.GA12771@odin.ac.hmc.edu>
Content-Type: multipart/mixed;
boundary="------------020001000007000200010100"
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:08:47 -0000
This is a multi-part message in MIME format.
--------------020001000007000200010100
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Hello!
Is this patch looks ok for You now? Or should I do something more?
--
With respect,
Boris
--------------020001000007000200010100
Content-Type: text/plain;
name="patch-8021p.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch-8021p.diff"
--- sbin/ifconfig/ifconfig.h.orig Wed Jan 19 10:44:20 2005
+++ sbin/ifconfig/ifconfig.h Fri Jan 21 09:11:22 2005
@@ -49,6 +49,8 @@
extern void setvlantag(const char *, int, int, const struct afswtch *rafp);
extern void setvlandev(const char *, int, int, const struct afswtch *rafp);
+extern void setvlanpri(const char *, int, int, const struct afswtch *rafp);
+extern void setvlancfi(const char *, int, int, const struct afswtch *rafp);
extern void unsetvlandev(const char *, int, int, const struct afswtch *rafp);
extern void vlan_status(int s, struct rt_addrinfo *);
--- sbin/ifconfig/ifconfig.c.orig Wed Jan 19 10:56:44 2005
+++ sbin/ifconfig/ifconfig.c Fri Jan 21 09:11:54 2005
@@ -247,6 +247,8 @@
#endif
#ifdef USE_VLANS
{ "vlan", NEXTARG, setvlantag },
+ { "vlanpri", NEXTARG, setvlanpri },
+ { "vlancfi", NEXTARG, setvlancfi },
{ "vlandev", NEXTARG, setvlandev },
{ "-vlandev", NEXTARG, unsetvlandev },
#endif
--- sbin/ifconfig/ifvlan.c.orig Thu Apr 18 23:14:09 2002
+++ sbin/ifconfig/ifvlan.c Tue Jan 25 13:05:11 2005
@@ -59,6 +59,8 @@
"$FreeBSD: src/sbin/ifconfig/ifvlan.c,v 1.5 2002/04/18 17:14:09 imp Exp $";
#endif
static int __tag = 0;
+static int __pri = 0;
+static int __cfi = 0;
static int __have_tag = 0;
void
@@ -72,9 +74,10 @@
if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
return;
- printf("\tvlan: %d parent interface: %s\n",
- vreq.vlr_tag, vreq.vlr_parent[0] == '\0' ?
- "<none>" : vreq.vlr_parent);
+ printf("\tvlan: %d 802.1p: %d CFI: %d parent interface: %s \n",
+ EVL_VLANOFTAG(vreq.vlr_tag), EVL_PRIOFTAG(vreq.vlr_tag),
+ EVL_CFIOFTAG(vreq.vlr_tag),
+ vreq.vlr_parent[0] == '\0' ? "<none>" : vreq.vlr_parent );
return;
}
@@ -84,17 +87,79 @@
{
u_int16_t tag;
struct vlanreq vreq;
+ char *endptr;
- __tag = tag = atoi(val);
+ __tag = tag = (u_int16_t)strtoul(val, &endptr, 0);
+ if(*endptr != '\0')
+ errx(1, "VLID ID must be a number");
__have_tag = 1;
+ if(tag < 1 || tag > 4094)
+ errx(1, "VLAN ID should be in range 1..4094");
+
+ bzero((char *)&vreq, sizeof(struct vlanreq));
+ ifr.ifr_data = (caddr_t)&vreq;
+
+ if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGETVLAN");
+
+ vreq.vlr_tag = EVL_MAKETAG(tag, __pri, __cfi);
+
+ if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSETVLAN");
+
+ return;
+}
+
+void
+setvlanpri(const char *val, int d, int s, const struct afswtch *afp)
+{
+ u_int16_t pri;
+ struct vlanreq vreq;
+ char *endptr;
+
+ __pri = pri = (u_int16_t)strtoul(val, &endptr, 0);
+ if(*endptr != '\0')
+ errx(1, "VLAN 802.1p must be a number");
+
+ if(pri > 7)
+ errx(1, "VLAN 802.1p shoud be in range 0..7");
+
+ bzero((char *)&vreq, sizeof(struct vlanreq));
+ ifr.ifr_data = (caddr_t)&vreq;
+
+ if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGETVLAN");
+
+ vreq.vlr_tag = EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), pri, __cfi);
+
+ if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSETVLAN");
+
+ return;
+}
+
+void
+setvlancfi(const char *val, int d, int s, const struct afswtch *afp)
+{
+ u_int16_t cfi;
+ struct vlanreq vreq;
+ char *endptr;
+
+ __cfi = cfi = (u_int16_t)strtoul(val, &endptr, 0);
+ if(*endptr != '\0')
+ errx(1, "VLAN CFI must be a number");
+
+ if(cfi > 1)
+ errx(1, "VLAN CFI shoud be 0 or 1");
+
bzero((char *)&vreq, sizeof(struct vlanreq));
ifr.ifr_data = (caddr_t)&vreq;
if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCGETVLAN");
- vreq.vlr_tag = tag;
+ vreq.vlr_tag = EVL_MAKETAG(EVL_VLANOFTAG(vreq.vlr_tag), __pri, cfi);
if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCSETVLAN");
@@ -117,7 +182,7 @@
err(1, "SIOCGETVLAN");
strncpy(vreq.vlr_parent, val, sizeof(vreq.vlr_parent));
- vreq.vlr_tag = __tag;
+ vreq.vlr_tag = EVL_MAKETAG(__tag, __pri, __cfi);
if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
err(1, "SIOCSETVLAN");
--- sbin/ifconfig/ifconfig.8.orig Thu Sep 30 20:25:39 2004
+++ sbin/ifconfig/ifconfig.8 Fri Jan 21 09:39:24 2005
@@ -386,15 +386,35 @@
pseudo interface, set the VLAN tag value
to
.Ar vlan_tag .
-This value is a 16-bit number which is used to create an 802.1Q
+This value is a 12-bit number which is used to create an 802.1Q
VLAN header for packets sent from the
.Xr vlan 4
interface.
Note that
-.Cm vlan
+.Cm vlan, vlanpri, vlancfi
and
.Cm vlandev
-must both be set at the same time.
+must be set at the same time.
+.It Cm vlanpri Ar vlan_pri
+If the interface is a
+.Xr vlan 4
+pseudo interface, set the 802.1p priority value
+to
+.Ar vlan_pri .
+This value is a 3-bit number which is used to tag outgoing
+VLAN packtes with apropriate priority. If
+.Cm vlanpri
+is omitted it default to 0.
+.It Cm vlancfi Ar vlan_cfi
+If the interface is a
+.Xr vlan 4
+pseudo interface, set the CFI value
+to
+.Ar vlan_cfi .
+This value is a 1-bit number which is used to tag outgoing
+VLAN packtes with apropriate CFI value. If
+.Cm vlancfi
+is omitted it default to 0.
.It Cm vlandev Ar iface
If the interface is a
.Xr vlan 4
--- sys/net/if_vlan_var.h.orig Mon Jan 19 00:29:04 2004
+++ sys/net/if_vlan_var.h Tue Jan 25 11:54:33 2005
@@ -43,6 +43,8 @@
#define EVL_VLID_MASK 0x0FFF
#define EVL_VLANOFTAG(tag) ((tag) & EVL_VLID_MASK)
#define EVL_PRIOFTAG(tag) (((tag) >> 13) & 7)
+#define EVL_CFIOFTAG(tag) (((tag) >> 12) & 1)
+#define EVL_MAKETAG(vlid,pri,cfi) ((((((pri) & 7) << 1) | ((cfi) & 1)) << 12) | ((vlid) & EVL_VLID_MASK))
/* sysctl(3) tags, for compatibility purposes */
#define VLANCTL_PROTO 1
--- sys/net/if_vlan.c.orig Wed Jan 19 10:40:32 2005
+++ sys/net/if_vlan.c Fri Jan 21 09:05:45 2005
@@ -930,15 +930,6 @@
error = ENOENT;
break;
}
- /*
- * Don't let the caller set up a VLAN tag with
- * anything except VLID bits.
- */
-
- if (vlr.vlr_tag & ~EVL_VLID_MASK) {
- error = EINVAL;
- break;
- }
VLAN_LOCK();
error = vlan_config(ifv, p);
--------------020001000007000200010100--
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:09:53 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 1D52916A4CE
for <net@freebsd.org>; Tue, 25 Jan 2005 08:09:53 +0000 (GMT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id C58B943D58
for <net@freebsd.org>; Tue, 25 Jan 2005 08:09:51 +0000 (GMT)
(envelope-from andre@freebsd.org)
Received: (qmail 82536 invoked from network); 25 Jan 2005 07:51:09 -0000
Received: from unknown (HELO freebsd.org) ([62.48.0.54])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <glebius@freebsd.org>; 25 Jan 2005 07:51:09 -0000
Message-ID: <41F5FED1.B6EFD246@freebsd.org>
Date: Tue, 25 Jan 2005 09:09:53 +0100
From: Andre Oppermann <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@freebsd.org>
References: <20050124100717.GA47663@cell.sick.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: brooks@freebsd.org
cc: net@freebsd.org
Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:09:53 -0000
Gleb Smirnoff wrote:
>
> Dear collegues,
>
> pls review an updated patch bringing in ng_ipfw node. Differencies against
> previous patch:
>
> - packets coming from netgraph are queued, and later serviced by netisr
> - "ngtee" keyword introduced. A copy of packet is made, and it is sent
> into netgraph. No tagging is done. Original packet is either accepted or
> continues check against rules, depending on net.inet.ip.fw.one_pass.
> Target users are the ones, who are going to do ip accounting/netflow via
> ng_ipfw.
> - a bit more comments in code
>
> URL: http://people.freebsd.org/~glebius/totest/ng_ipfw.patch
Style-wise there is only the space after "(void )..." in ip_fw_pfil.c
for the ng_tee case which is too much.
I don't like the arbitrary back-passing of errors from ng_ipfw. I'm
fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
else. Getting back any other error is very confusing and non-intuitive
when looking at the error of an application having packets sunk there.
Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
doing it? Dummynet should do the same to get it consistent again.
Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
to unwind the stack?
PS: I'm out of town until tomorrow afternoon. I'll have only limited
email access until then.
--
Andre
> A sample setup:
>
> + ls
> There are 6 total nodes:
> Name: <unnamed> Type: hole ID: 00000009 Num hooks: 1
> Name: netflow Type: netflow ID: 00000008 Num hooks: 2
> Name: ngctl768 Type: socket ID: 00000007 Num hooks: 0
> Name: <unnamed> Type: hole ID: 00000006 Num hooks: 1
> Name: <unnamed> Type: echo ID: 00000004 Num hooks: 1
> Name: ipfw Type: ipfw ID: 00000001 Num hooks: 3
> + show ipfw:
> Name: ipfw Type: ipfw ID: 00000001 Num hooks: 3
> Local hook Peer name Peer type Peer ID Peer hook
> ---------- --------- --------- ------- ---------
> 555 netflow netflow 00000008 iface0
> 666 <unnamed> hole 00000006 qqq
> 100 <unnamed> echo 00000004 qqq
> +
>
> root@jujik:~:|>ipfw show
> 00100 0 0 allow ip from any to any via lo0
> 00200 0 0 deny ip from any to 127.0.0.0/8
> 00300 0 0 deny ip from 127.0.0.0/8 to any
> 00400 14927 61918948 netgraph 100 ip from any to any
> 00500 14927 61918948 ngtee 666 ip from any to any
> 00600 7477 1067060 ngtee 555 ip from any to any in
> 65000 14927 61918948 allow ip from any to any
> 65535 0 0 deny ip from any to any
>
> root@jujik:~:|>sysctl net.inet.ip.fw.one_pass
> net.inet.ip.fw.one_pass: 0
>
> On Mon, Jan 17, 2005 at 11:06:10PM +0300, Gleb Smirnoff wrote:
> > Dear collegues,
> >
> > here is quite a simple node for direct interaction between ipfw(4)
> > and netgraph(4). It is going to be more effective and error-prone
> > than a complicated construction around divert socket and ng_ksocket[1].
> >
> > The semantics of node operation are quite simple. There is one node
> > per system, which accepts any hooks with numeric names. Packets
> > can be sent to netgraph(4) using ipfw 'netgraph' action, followed
> > by a numeric cookie. Matched packets are sent out from corresponding
> > hook of ng_ipfw node. These packets are tagged with information which
> > helps them later to reenter ipfw processing. Tagged packets received on
> > any node hook reenter IP stack. If net.inet.ip.fw.one_pass sysctl is non
> > zero they are accepted, otherwise they continue with next rule. Non-tagged
> > packets (not originating from ng_ipfw node) are discarded.
> >
> > Here is sample configuration. ng_echo(4) echoes packets back from netgraph
> > to ipfw thru a tee node, which allows to sniff traffic.
> >
> > ngctl
> > + ls
> > There are 4 total nodes:
> > Name: ngctl6138 Type: socket ID: 0000000c Num hooks: 0
> > Name: ipfw Type: ipfw ID: 00000009 Num hooks: 1
> > Name: <unnamed> Type: echo ID: 00000006 Num hooks: 1
> > Name: tee Type: tee ID: 00000005 Num hooks: 2
> > + show ipfw:
> > Name: ipfw Type: ipfw ID: 00000009 Num hooks: 1
> > Local hook Peer name Peer type Peer ID Peer hook
> > ---------- --------- --------- ------- ---------
> > 666 tee tee 00000005 left
> > + show tee:
> > Name: tee Type: tee ID: 00000005 Num hooks: 2
> > Local hook Peer name Peer type Peer ID Peer hook
> > ---------- --------- --------- ------- ---------
> > left ipfw ipfw 00000009 666
> > right <unnamed> echo 00000006 echi
> >
> > root@jujik:/usr/src:|>ipfw show
> > 00100 292 40304 allow ip from any to any via lo0
> > 00200 0 0 deny ip from any to 127.0.0.0/8
> > 00300 0 0 deny ip from 127.0.0.0/8 to any
> > 00350 290730 661428793 netgraph 666 ip from any to any
> > 65000 627921 1896034399 allow ip from any to any
> > 65535 0 0 deny ip from any to any
> >
> > The patch [2] is applicable only to HEAD, sorry. The target users are
> > the ones, who are now running ip_accounting/netflow using diverted
> > ng_ksocket, and just netgraph geeks.
>
> --
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:21:13 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 C632116A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 08:21:13 +0000 (GMT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id 01BD943D54
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 08:21:13 +0000 (GMT)
(envelope-from andre@freebsd.org)
Received: (qmail 82613 invoked from network); 25 Jan 2005 08:02:30 -0000
Received: from unknown (HELO freebsd.org) ([62.48.0.54])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <brooks@one-eyed-alien.net>; 25 Jan 2005 08:02:30 -0000
Message-ID: <41F6017A.9484C656@freebsd.org>
Date: Tue, 25 Jan 2005 09:21:14 +0100
From: Andre Oppermann <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brooks Davis <brooks@one-eyed-alien.net>
References: <41F33E9F.9090301@tagnet.ru>
<20050123193711.GB29225@odin.ac.hmc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: freebsd-net@freebsd.org
cc: Boris Kovalenko <boris@tagnet.ru>
Subject: Re: [PATCH] 802.1p priority (fixed)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:21:13 -0000
Brooks Davis wrote:
>
> On Sun, Jan 23, 2005 at 11:05:19AM +0500, Boris Kovalenko wrote:
> > And what this changes? Some switches totally ignore 802.1p. We're
> > talking about IEEE standard and should fully support it. Also, may You
> > point me where You have read this?
Chiming in somewhere into this thread...
> The issue is that you may need the ability to treat some values as
> though they are the same because some network environments will do this.
>
> While I think a lower level solution will be the most useful in the
> end, I don't object to an interface based solution. I think you should
> proceed with that with the idea that you add a third, optional keyword
> to vlan initalization to specify priority. That way you can create
> seperate interfaces for each priority for any vlan tag. Something like:
>
> ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3
For a clean handling of 802.1p tagging we should handle it like this:
1. Extend to ifconfig and vlan to be able to specify a DEFAULT vlan
priority.
2. Have vlan insert the 802.1p priority from a generic layer 2 specifics
aganostic priority m_tag into the vlan header overiding any configured
default value on the vlan interface.
3. Extend any|all of the packet filters and|or ALTQ to set the generic
layer 2 priority tag directly via the m_tag. Propagation of any pritority
information contained in the layer 3 (IP TOS) is done through the
packet filters subject to their filtering abilities to prevent abuse.
4. Provide a way for applications (via setsockopt) to specify their priority
wishes.
The entire tagging thing should be generic that other kinds of networks
can use it as well (frame relay for example). I think 4 bits is fine.
If less than 16 priorities are supported it should shift to the right
and use the remainder.
Starting with just the default vlan priority configuration via ifconfig
is fine with provided that the overriding via m_tags is documented that
we don't have POLA problems later on when we implement the full thing.
--
Andre
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:21:40 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 00DAD16A4CE; Tue, 25 Jan 2005 08:21:40 +0000 (GMT)
Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 231EC43D54; Tue, 25 Jan 2005 08:21:39 +0000 (GMT)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68])
by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j0P8Lbgg052735
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
Tue, 25 Jan 2005 11:21:38 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
by cell.sick.ru (8.12.11/8.12.8) with ESMTP id j0P8LaxV057567
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 25 Jan 2005 11:21:37 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
by cell.sick.ru (8.12.11/8.12.11/Submit) id j0P8La0b057566;
Tue, 25 Jan 2005 11:21:36 +0300 (MSK)
(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
glebius@freebsd.org using -f
Date: Tue, 25 Jan 2005 11:21:36 +0300
From: Gleb Smirnoff <glebius@freebsd.org>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20050125082136.GC57248@cell.sick.ru>
References: <20050124100717.GA47663@cell.sick.ru>
<41F5FED1.B6EFD246@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <41F5FED1.B6EFD246@freebsd.org>
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff
on relay.bestcom.ru
X-Virus-Status: Clean
cc: brooks@freebsd.org
cc: net@freebsd.org
Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:21:40 -0000
On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
A> Style-wise there is only the space after "(void )..." in ip_fw_pfil.c
A> for the ng_tee case which is too much.
Ok.
A> I don't like the arbitrary back-passing of errors from ng_ipfw. I'm
A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
A> else. Getting back any other error is very confusing and non-intuitive
A> when looking at the error of an application having packets sunk there.
So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
Julian, Brooks?
A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
A> doing it? Dummynet should do the same to get it consistent again.
Not sure that this is good. These tags are foreign to ipfw, they belong
to other facilities.
A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
A> to unwind the stack?
No. The stack will be unwinded when packet travels thru netgraph and returned
back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
is configured in ng_ipfw_connect().
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:29:49 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 78D5816A4CF
for <net@freebsd.org>; Tue, 25 Jan 2005 08:29:49 +0000 (GMT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id 52DDE43D31
for <net@freebsd.org>; Tue, 25 Jan 2005 08:29:48 +0000 (GMT)
(envelope-from andre@freebsd.org)
Received: (qmail 82704 invoked from network); 25 Jan 2005 08:11:06 -0000
Received: from unknown (HELO freebsd.org) ([62.48.0.54])
(envelope-sender <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <glebius@freebsd.org>; 25 Jan 2005 08:11:06 -0000
Message-ID: <41F6037E.3C7F6364@freebsd.org>
Date: Tue, 25 Jan 2005 09:29:50 +0100
From: Andre Oppermann <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@freebsd.org>
References: <20050124100717.GA47663@cell.sick.ru>
<41F5FED1.B6EFD246@freebsd.org> <20050125082136.GC57248@cell.sick.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: brooks@freebsd.org
cc: net@freebsd.org
Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:29:49 -0000
Gleb Smirnoff wrote:
>
> On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
> A> I don't like the arbitrary back-passing of errors from ng_ipfw. I'm
> A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
> A> else. Getting back any other error is very confusing and non-intuitive
> A> when looking at the error of an application having packets sunk there.
>
> So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
> Julian, Brooks?
No, I want only get EACCES, ENOMEM or ESRCH back and nothing else.
I didn't I want only "return (0)".
> A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
> A> doing it? Dummynet should do the same to get it consistent again.
>
> Not sure that this is good. These tags are foreign to ipfw, they belong
> to other facilities.
I guess ng_ipfw is pretty much specific to ipfw, no?
> A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
> A> to unwind the stack?
>
> No. The stack will be unwinded when packet travels thru netgraph and returned
> back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
> is configured in ng_ipfw_connect().
What if the packet doesn't make its way back to ng_ipfw? I can imagine a
lot of configurations where this may happen (intential). The problem comes
back again and is much less obvious if the stack breaks.
I'm out now until tomorrow afternoon.
--
Andre
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 08:37:37 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8EF2E16A4CE; Tue, 25 Jan 2005 08:37:37 +0000 (GMT)
Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5])
by mx1.FreeBSD.org (Postfix) with ESMTP
id B479B43D39; Tue, 25 Jan 2005 08:37:36 +0000 (GMT)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68])
by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j0P8bYF3053041
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
Tue, 25 Jan 2005 11:37:35 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
by cell.sick.ru (8.12.11/8.12.8) with ESMTP id j0P8bXfl057822
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 25 Jan 2005 11:37:34 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
by cell.sick.ru (8.12.11/8.12.11/Submit) id j0P8bXCc057821;
Tue, 25 Jan 2005 11:37:33 +0300 (MSK)
(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
glebius@freebsd.org using -f
Date: Tue, 25 Jan 2005 11:37:33 +0300
From: Gleb Smirnoff <glebius@freebsd.org>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20050125083733.GA57770@cell.sick.ru>
References: <20050124100717.GA47663@cell.sick.ru>
<41F5FED1.B6EFD246@freebsd.org> <20050125082136.GC57248@cell.sick.ru>
<41F6037E.3C7F6364@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <41F6037E.3C7F6364@freebsd.org>
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff
on relay.bestcom.ru
X-Virus-Status: Clean
cc: brooks@freebsd.org
cc: net@freebsd.org
Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 08:37:37 -0000
On Tue, Jan 25, 2005 at 09:29:50AM +0100, Andre Oppermann wrote:
A> > On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
A> > A> I don't like the arbitrary back-passing of errors from ng_ipfw. I'm
A> > A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
A> > A> else. Getting back any other error is very confusing and non-intuitive
A> > A> when looking at the error of an application having packets sunk there.
A> >
A> > So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
A> > Julian, Brooks?
A>
A> No, I want only get EACCES, ENOMEM or ESRCH back and nothing else.
A> I didn't I want only "return (0)".
ENOMEM and ESRCH can be returned by ng_ipfw_input() itself. EACCES can be returned
by ipfw_check_{in,out}. All other errors can be returned indirectly by other
nodes, via NG_SEND_DATA_ONLY() macro. These errors are out of our control.
Do you want this construction at end of ng_ipfw_input()?
NG_SEND_DATA_ONLY(error, hook, m);
if (error == EACCES ||
error == ENOMEM ||
error == ESRCH)
return (error);
else
return (0);
A> > A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
A> > A> doing it? Dummynet should do the same to get it consistent again.
A> >
A> > Not sure that this is good. These tags are foreign to ipfw, they belong
A> > to other facilities.
A>
A> I guess ng_ipfw is pretty much specific to ipfw, no?
Yes. I thought it is better to allocate tag only after a sending hook was found.
I will accept after I hear more opinions.
A> > A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
A> > A> to unwind the stack?
A> >
A> > No. The stack will be unwinded when packet travels thru netgraph and returned
A> > back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
A> > is configured in ng_ipfw_connect().
A>
A> What if the packet doesn't make its way back to ng_ipfw? I can imagine a
A> lot of configurations where this may happen (intential). The problem comes
A> back again and is much less obvious if the stack breaks.
If the packet does not come back to ng_ipfw, then we do not have any recursion
and stack problems.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 14:33:41 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 1B0A316A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 14:33:41 +0000 (GMT)
Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169])
by mx1.FreeBSD.org (Postfix) with ESMTP id 926DB43D45
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 14:33:40 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-2.free.fr (Postfix) with ESMTP id C9162C273;
Tue, 25 Jan 2005 15:33:39 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id 78012408E; Tue, 25 Jan 2005 15:33:27 +0100 (CET)
Date: Tue, 25 Jan 2005 15:33:27 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Bruce M Simpson <bms@spc.org>
Message-ID: <20050125143327.GD59685@obiwan.tataz.chchile.org>
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125011615.GB47638@dhcp120.icir.org>
User-Agent: Mutt/1.5.6i
cc: freebsd-net@freebsd.org
cc: Jeremie Le Hen <jeremie@le-hen.org>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 14:33:41 -0000
> In a previous existence, I was able to tcpdump on a gif(4) interface;
> the tunnel was being used so that I could IPSEC-encapsulate multicast
> traffic which was necessary to get past some ISP filters (IPIP was
> being dropped at the border).
>
> This was in 5.2.1-RELEASE on a sparc64.
>
> Hope this helps,
Well this is a start. But I would really like to make it work on
RELENG_4. In fact, if bpf.h was not included in if_gif.c, I would not
mind. But although I'm not (yet ;p) a kernel hacker, I read quickly
bpf(9) manpage and I really think the code should work. I dread that
this is due to some back magic I can't even imagine. That's why I
made a call here for testimonies or explanations.
Thanks.
Regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 14:40:40 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 19D3516A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 14:40:40 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id C1A3F43D1D
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 14:40:39 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id EF6096530A; Tue, 25 Jan 2005 14:40:38 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 17833-01-29; Tue, 25 Jan 2005 14:40:38 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id BC28665213; Tue, 25 Jan 2005 14:40:37 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id 6BC976383; Tue, 25 Jan 2005 14:41:53 +0000 (GMT)
Date: Tue, 25 Jan 2005 14:41:53 +0000
From: Bruce M Simpson <bms@spc.org>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050125144153.GJ47638@dhcp120.icir.org>
Mail-Followup-To: Jeremie Le Hen <jeremie@le-hen.org>,
freebsd-net@freebsd.org
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
<20050125143327.GD59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125143327.GD59685@obiwan.tataz.chchile.org>
cc: freebsd-net@freebsd.org
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 14:40:40 -0000
On Tue, Jan 25, 2005 at 03:33:27PM +0100, Jeremie Le Hen wrote:
> Well this is a start. But I would really like to make it work on
> RELENG_4. In fact, if bpf.h was not included in if_gif.c, I would not
> mind. But although I'm not (yet ;p) a kernel hacker, I read quickly
> bpf(9) manpage and I really think the code should work. I dread that
> this is due to some back magic I can't even imagine. That's why I
> made a call here for testimonies or explanations.
Try tcpdump -L -i gif0 on the affected system and post what you get. You
might need to install the port if the base system tcpdump doesn't
have the -L option.
If you get a list of encapsulations back, try using them with the -y
option,,e.g.:
tcpdump -y null -i gif0
BMS
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 15:03:08 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 CC7D716A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:03:08 +0000 (GMT)
Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8097E43D1D
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:03:08 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix4-2.free.fr (Postfix) with ESMTP id B49AC2BBE08
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:03:07 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id EB360408E; Tue, 25 Jan 2005 16:02:55 +0100 (CET)
Date: Tue, 25 Jan 2005 16:02:55 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: freebsd-net@freebsd.org
Message-ID: <20050125150255.GE59685@obiwan.tataz.chchile.org>
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
<20050125143327.GD59685@obiwan.tataz.chchile.org>
<20050125144153.GJ47638@dhcp120.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125144153.GJ47638@dhcp120.icir.org>
User-Agent: Mutt/1.5.6i
cc: Jeremie Le Hen <jeremie@le-hen.org>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 15:03:08 -0000
> Try tcpdump -L -i gif0 on the affected system and post what you get. You
> might need to install the port if the base system tcpdump doesn't
> have the -L option.
>
> If you get a list of encapsulations back, try using them with the -y
> option,,e.g.:
> tcpdump -y null -i gif0
I need indeed tcpdump port. But unfortunately, it did not work.
Here is the typescript:
%%%
yoda:root# ping 192.168.4.13 >/dev/null 2>&1 &
[1] 53373
yoda:root# /usr/local/sbin/tcpdump -L -i gif0
Data link types (use option -y to set):
NULL (BSD loopback)
yoda:root# /usr/local/sbin/tcpdump -y null -i gif0
tcpdump: data link type null
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
yoda:root# /usr/local/sbin/tcpdump -ni ep0 esp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ep0, link-type EN10MB (Ethernet), capture size 96 bytes
15:59:24.708405 IP xx.xx.xx.xx > yy.yy.yy.yy: ESP(spi=0x0c988eaf,seq=0x1f3)
15:59:24.746374 IP yy.yy.yy.yy > xx.xx.xx.xx: ESP(spi=0x0cb31758,seq=0x1f0)
15:59:25.728390 IP xx.xx.xx.xx > yy.yy.yy.yy: ESP(spi=0x0c988eaf,seq=0x1f4)
15:59:25.766083 IP yy.yy.yy.yy > xx.xx.xx.xx: ESP(spi=0x0cb31758,seq=0x1f1)
^C
4 packets captured
83 packets received by filter
0 packets dropped by kernel
%%%
Does any one have other ideas ? It seems the code was partly written
by sam@, brooks@ and shin@.
Best regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 15:21:01 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2671516A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:21:01 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9364F43D54
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:20:58 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id 6ADBF6520C; Tue, 25 Jan 2005 15:20:55 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 18387-02-2; Tue, 25 Jan 2005 15:20:54 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id 7CC136520E; Tue, 25 Jan 2005 15:20:54 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id 05FCA6383; Tue, 25 Jan 2005 15:22:09 +0000 (GMT)
Date: Tue, 25 Jan 2005 15:22:09 +0000
From: Bruce M Simpson <bms@spc.org>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050125152209.GK47638@dhcp120.icir.org>
Mail-Followup-To: Jeremie Le Hen <jeremie@le-hen.org>,
freebsd-net@freebsd.org
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
<20050125143327.GD59685@obiwan.tataz.chchile.org>
<20050125144153.GJ47638@dhcp120.icir.org>
<20050125150255.GE59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125150255.GE59685@obiwan.tataz.chchile.org>
cc: freebsd-net@freebsd.org
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 15:21:01 -0000
On Tue, Jan 25, 2005 at 04:02:55PM +0100, Jeremie Le Hen wrote:
> Does any one have other ideas ? It seems the code was partly written
> by sam@, brooks@ and shin@.
Interesting. It seems gif isn't passing anything back at all. Can you verify
that the routes for the addresses you're pinging traverse gif0? I'd
probably also try csjp@'s bpfstat tool to get a closer look at what's
going on in bpf.
Also try assigning a local address to an instance of gif on the affected
system and pinging a destination through it using the -r and -S options
whilst running tcpdump to be sure.
Can you post the revision(s) of the source files? e.g.:
src/sys/net/if_gif.c
src/sys/netinet/in_gif.c
src/sys/netinet6/in6_gif.c
...and uname -a?
Hope this helps,
BMS
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 15:36:01 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 E86AB16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:36:01 +0000 (GMT)
Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2E81843D49
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 15:36:01 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-2.free.fr (Postfix) with ESMTP id 86044C37C;
Tue, 25 Jan 2005 16:35:59 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id 2FFC6407C; Tue, 25 Jan 2005 16:35:47 +0100 (CET)
Date: Tue, 25 Jan 2005 16:35:47 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>
Message-ID: <20050125153547.GF59685@obiwan.tataz.chchile.org>
References: <D86BF562467D944EB435513F725B236A07C11F@exchange.stardevelopers4msi.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <D86BF562467D944EB435513F725B236A07C11F@exchange.stardevelopers4msi.com>
User-Agent: Mutt/1.5.6i
cc: freebsd-net@freebsd.org
cc: Jeremie Le Hen <jeremie@le-hen.org>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 15:36:02 -0000
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> Please tell me more about your problem: is it that tcpdump cannot
> attach to device, or it shows no packets when you are sure there is
> traffic on the gif(4) interface, or something else? If there is some
> error report - send it here. Please check that you have free bpf
> device :-) . What version of 4.x are you running? On my 4.9 system
> if_gif.c has references to bpf_mtap in both _input and _output
> routines. That should work.
Yes sorry, I should have given these informations earlier :
4.10-STABLE FreeBSD 4.10-STABLE #44: Wed Jul 7 03:35:21 CEST 2004
bpf(4) is compiled in the kernel but gif(4) is loaded as a module (can
this be the point ?).
There is absolutely no error. I attached the strace log.
See also my next reply to Bruce, I'll give my file revisions.
Many thanks.
Best regards,
--
Jeremie Le Hen
jeremie@le-hen.org
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="strace.tcpdump"
execve("/usr/local/sbin/tcpdump", ["/usr/local/sbin/tcpdump", "-y", "null", "-i", "gif0"], [/* 27 vars */]) = 0 <0.000935>
mmap(0, 2048, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x280d7000 <0.000061>
munmap(0x280d7000, 2048) = 0 <0.000061>
__sysctl([hw.pagesize], 2, "\0\20\0\0", [4], NULL, 0) = 0 <0.000079>
mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x280d7000 <0.000052>
geteuid(0xbfbff76c) = 0 <0.000041>
getuid() = 0 (euid 0) <0.000040>
getegid(0xbfbff76c) = 0 <0.000040>
getgid() = 0 (egid 0) <0.000039>
open("/etc/libmap.conf", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000081>
open("/var/run/ld-elf.so.hints", O_RDONLY) = 3 <0.000091>
read(3, "Ehnt\1\0\0\0\200\0\0\0Q\0\0\0\0\0\0\0P\0\0\0\0\0\0\0\0"..., 128) = 128 <0.000070>
lseek(3, 128, SEEK_SET) = 128 <0.000040>
read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 81) = 81 <0.000062>
close(3) = 0 <0.000069>
access("/usr/lib/libc.so.4", F_OK) = 0 <0.000082>
open("/usr/lib/libc.so.4", O_RDONLY) = 3 <0.000080>
fstat(3, {st_mode=S_IFREG|0444, st_size=589976, ...}) = 0 <0.000048>
read(3, "\177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\264(\1"..., 4096) = 4096 <0.000106>
mmap(0, 638976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_NOCORE, 3, 0) = 0x280df000 <0.000064>
mprotect(0x28162000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 <0.000052>
mprotect(0x28162000, 4096, PROT_READ|PROT_EXEC) = 0 <0.000048>
mmap(0x28163000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x83000) = 0x28163000 <0.000079>
mmap(0x28168000, 77824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x28168000 <0.000059>
close(3) = 0 <0.000048>
mmap(0, 864, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2817b000 <0.000050>
munmap(0x2817b000, 864) = 0 <0.000067>
mmap(0, 13360, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2817b000 <0.000053>
munmap(0x2817b000, 13360) = 0 <0.000071>
sigaction(SIGILL, {0x280c69c8, [], 0}, {SIG_DFL}) = 0 <0.000053>
sigprocmask(SIG_BLOCK, NULL, []) = 0 <0.000041>
sigaction(SIGILL, {SIG_DFL}, NULL) = 0 <0.000043>
sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0 <0.000042>
sigprocmask(SIG_SETMASK, [], NULL) = 0 <0.000042>
gettimeofday({1106667099, 812736}, NULL) = 0 <0.000042>
issetugid(0x28166cac) = 0 <0.000040>
open("/usr/share/zoneinfo/GMT", O_RDONLY) = 3 <0.000109>
fstat(3, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 <0.000046>
read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0"..., 7944) = 56 <0.000066>
close(3) = 0 <0.000066>
issetugid(0x28166cac) = 0 <0.000040>
open("/usr/share/zoneinfo/CET", O_RDONLY) = 3 <0.000089>
fstat(3, {st_mode=S_IFREG|0644, st_size=755, ...}) = 0 <0.000044>
read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 7944) = 755 <0.000072>
close(3) = 0 <0.000065>
readlink("/etc/malloc.conf", 0xbfbff410, 63) = -1 ENOENT (No such file or directory) <0.000065>
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x2817b000 <0.000062>
break(0x819e000) = 0 <0.000049>
break(0x819f000) = 0 <0.000047>
open("/dev/bpf0", O_RDONLY) = -1 EBUSY (Device busy) <0.000092>
open("/dev/bpf1", O_RDONLY) = 3 <0.000105>
ioctl(3, BIOCVERSION, 0xbfbff4c8) = 0 <0.000049>
ioctl(3, BIOCGBLEN, 0xbfbff4c4) = 0 <0.000044>
ioctl(3, BIOCSBLEN, 0xbfbff4c4) = 0 <0.000047>
ioctl(3, BIOCSETIF, 0xbfbff580) = 0 <0.000161>
ioctl(3, BIOCGDLT, 0xbfbff4c4) = 0 <0.000044>
ioctl(3, BIOCSRTIMEOUT, 0xbfbff4bc) = 0 <0.000049>
ioctl(3, BIOCPROMISC, 0) = 0 <0.000263>
ioctl(3, BIOCGBLEN, 0xbfbff4c4) = 0 <0.000045>
break(0x81a7000) = 0 <0.000047>
__sysctl([kern.ostype], 2, "FreeBSD\0", [8], NULL, 0) = 0 <0.000077>
__sysctl([kern.hostname], 2, "yoda.tataz.chchile.org\0", [23], NULL, 0) = 0 <0.000077>
__sysctl([kern.osrelease], 2, "4.10-STABLE\0", [12], NULL, 0) = 0 <0.000074>
__sysctl([kern.version], 2, 0xbfbff540, 0xbfbff474, NULL, 0) = -1 ENOMEM (Cannot allocate memory) <0.000076>
__sysctl([hw.machine], 2, "i386\0", [5], NULL, 0) = 0 <0.000077>
write(2, "tcpdump: data link type null\n", 29) = 29 <0.001243>
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 <0.000084>
ioctl(4, SIOCGIFADDR, 0xbfbff590) = 0 <0.000066>
ioctl(4, SIOCGIFNETMASK, 0xbfbff590) = 0 <0.000053>
close(4) = 0 <0.000075>
getuid() = 0 (euid 0) <0.000041>
setuid(0) = 0 <0.000042>
sigprocmask(SIG_BLOCK, NULL, []) = 0 <0.000041>
break(0x81a8000) = 0 <0.000048>
break(0x81a9000) = 0 <0.000047>
break(0x81aa000) = 0 <0.000047>
open("/etc/ethers", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000078>
open("/etc/services", O_RDONLY) = 4 <0.000083>
fstat(4, {st_mode=S_IFREG|0644, st_size=73544, ...}) = 0 <0.000046>
read(4, "#\n# Network services, Internet s"..., 8192) = 8192 <0.000141>
break(0x81ab000) = 0 <0.000047>
read(4, "ISO-TSAP Class 0\ngppitnp\t\t103/tc"..., 8192) = 8192 <0.000129>
break(0x81ac000) = 0 <0.000046>
break(0x81ad000) = 0 <0.000047>
read(4, " #AppleTalk Zone Information\nat"..., 8192) = 8192 <0.000130>
break(0x81ae000) = 0 <0.000047>
break(0x81af000) = 0 <0.000047>
read(4, "nteractive Mail Support Protocol"..., 8192) = 8192 <0.000129>
break(0x81b0000) = 0 <0.000047>
break(0x81b1000) = 0 <0.000047>
read(4, "p\t #Apertus Technologies Load "..., 8192) = 8192 <0.000125>
break(0x81b2000) = 0 <0.000048>
break(0x81b3000) = 0 <0.000048>
read(4, "/tcp\napplix\t\t999/udp\t #App"..., 8192) = 8192 <0.000134>
break(0x81b4000) = 0 <0.000047>
break(0x81b5000) = 0 <0.000049>
read(4, "anager\nsas-1\t\t1426/tcp #Satell"..., 8192) = 8192 <0.000129>
break(0x81b6000) = 0 <0.000047>
read(4, "udp\nmiroconnect\t1532/tcp\nmirocon"..., 8192) = 8192 <0.000131>
break(0x81b7000) = 0 <0.000047>
read(4, " web - development\nwww-dev\t\t2784"..., 8192) = 8008 <0.000732>
break(0x81b8000) = 0 <0.000052>
break(0x81b9000) = 0 <0.000046>
read(4, "", 8192) = 0 <0.000051>
close(4) = 0 <0.000046>
sigaction(SIGPIPE, {0x807d384, [], 0}, {SIG_DFL}) = 0 <0.000050>
sigaction(SIGTERM, {0x807d384, [], 0}, {SIG_DFL}) = 0 <0.000044>
sigaction(SIGINT, {0x807d384, [], 0}, {SIG_DFL}) = 0 <0.000046>
sigaction(SIGHUP, {0x807d384, [], 0}, {SIG_DFL}) = 0 <0.000046>
ioctl(3, BIOCSETF, 0xbfbff5fc) = 0 <0.000058>
sigaction(SIGINFO, {0x807d82c, [], 0}, {SIG_DFL}) = 0 <0.000045>
write(2, "tcpdump: verbose output suppress"..., 75) = 75 <0.001092>
write(2, "listening on gif0, link-type NUL"..., 72) = 72 <0.000698>
read(3, "", 32768) = 0 <0.987321>
read(3, "", 32768) = 0 <0.999422>
read(3, <unfinished ...>
--- SIGINT (Interrupt) ---
--- SIGINT (Interrupt) ---
--- SIGINT (Interrupt) ---
<... read resumed> 0x819f000, 32768) = -1 EINTR (Interrupted system call) <0.917070>
sigreturn(0xbfbff3c0) = -1 EINTR (Interrupted system call) <0.000048>
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(5, 16), ...}) = 0 <0.000052>
ioctl(1, TIOCGETA, {B38400 opost isig icanon echo ...}) = 0 <0.000050>
write(1, "\n", 1) = 1 <0.000887>
ioctl(3, BIOCGSTATS, 0xbfbff558) = 0 <0.000050>
write(2, "0 packets captured", 18) = 18 <0.000636>
write(2, "\n", 1) = 1 <0.000634>
write(2, "0 packets received by filter", 28) = 28 <0.000583>
write(2, "\n", 1) = 1 <0.000653>
write(2, "0 packets dropped by kernel\n", 28) = 28 <0.000659>
close(3) = 0 <0.000402>
exit(0) = ?
--a8Wt8u1KmwUX3Y2C--
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 16:08:51 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 93C2E16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:08:51 +0000 (GMT)
Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0C02443D3F
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:08:51 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-2.free.fr (Postfix) with ESMTP id 0E22AC288
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:08:50 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id 32932407C; Tue, 25 Jan 2005 17:08:37 +0100 (CET)
Date: Tue, 25 Jan 2005 17:08:37 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Jeremie Le Hen <jeremie@le-hen.org>, freebsd-net@freebsd.org
Message-ID: <20050125160837.GG59685@obiwan.tataz.chchile.org>
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
<20050125143327.GD59685@obiwan.tataz.chchile.org>
<20050125144153.GJ47638@dhcp120.icir.org>
<20050125150255.GE59685@obiwan.tataz.chchile.org>
<20050125152209.GK47638@dhcp120.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125152209.GK47638@dhcp120.icir.org>
User-Agent: Mutt/1.5.6i
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 16:08:51 -0000
> Interesting. It seems gif isn't passing anything back at all. Can you verify
> that the routes for the addresses you're pinging traverse gif0? I'd
> probably also try csjp@'s bpfstat tool to get a closer look at what's
> going on in bpf.
Yes they are (network on the other side of the tunnel is 192.168.4.0/24) :
%%%
yoda:tools# netstat -rnf inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default <hidden gw> UGSc 24 17513460 ep0
<hidden net>/24 link#4 UC 1 0 ep0
<hidden ip> 127.0.0.1 UGHS 0 70 lo0
<hidden gw> 00:07:cb:0e:2e:70 UHLW 25 0 ep0 1188
127.0.0.1 127.0.0.1 UH 3 816372 lo0
192.168.0 link#2 UC 1 0 sis1
192.168.0.4 00:a0:cc:da:9f:62 UHLW 2 2188 sis1 625
192.168.1 link#1 UC 6 0 sis0
192.168.1.1 00:09:5b:1a:48:94 UHLW 1 31599 lo0
192.168.1.2 00:09:5b:1a:4f:4d UHLW 0 752 sis0 1199
192.168.1.25 00:04:23:89:e5:84 UHLW 0 562 sis0 353
192.168.1.53 00:04:23:89:e5:84 UHLW 2 167625 sis0 1156
192.168.1.222 00:04:23:89:e5:84 UHLW 2 7601091 sis0 262
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 15 sis0
192.168.4 192.168.4.13 UGSc 0 691911 gif0
192.168.4.13 192.168.1.1 UH 3 6949 gif0
%%%
I got bpfstat on csjp@'s FreeBSD webpage, but it is designed to work
with devfs. Running RELENG_4, it just does not compile :-(.
> Also try assigning a local address to an instance of gif on the affected
> system and pinging a destination through it using the -r and -S options
> whilst running tcpdump to be sure.
Here is it, with the interface configuration :
%%%
yoda:sys# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet <hidden ip> --> <hidden peer ip>
inet6 fe80::209:5bff:fe1a:4894%gif0 prefixlen 64 scopeid 0xa
inet 192.168.1.1 --> 192.168.4.13 netmask 0xffffff00
yoda:sys# ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
[1] 63095
yoda:sys# /usr/local/sbin/tcpdump -c 2 -ni ep0 'esp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ep0, link-type EN10MB (Ethernet), capture size 96 bytes
17:06:09.008978 IP 82.233.239.98 > 82.66.245.132: ESP(spi=0x0f5d2cbd,seq=0x3a9)
17:06:09.046998 IP 82.66.245.132 > 82.233.239.98: ESP(spi=0x00439e94,seq=0x3a9)
2 packets captured
106 packets received by filter
0 packets dropped by kernel
yoda:sys# /usr/local/sbin/tcpdump -y null -c 2 -ni gif0 'esp'
tcpdump: data link type null
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
%%%
> Can you post the revision(s) of the source files? e.g.:
> src/sys/net/if_gif.c
> src/sys/netinet/in_gif.c
> src/sys/netinet6/in6_gif.c
> ...and uname -a?
I already looked on CVSweb, but I saw no relevant commit log.
%%%
yoda:sys# ident net/if_gif.c netinet/in_gif.c netinet6/in6_gif.c
net/if_gif.c:
$FreeBSD: src/sys/net/if_gif.c,v 1.4.2.15 2002/11/08 16:57:13 ume Exp $
$KAME: if_gif.c,v 1.87 2001/10/19 08:50:27 itojun Exp $
netinet/in_gif.c:
$FreeBSD: src/sys/netinet/in_gif.c,v 1.5.2.11 2003/01/23 21:06:45 sam Exp $
$KAME: in_gif.c,v 1.54 2001/05/14 14:02:16 itojun Exp $
netinet6/in6_gif.c:
$FreeBSD: src/sys/netinet6/in6_gif.c,v 1.2.2.7 2003/01/23 21:06:47 sam Exp $
$KAME: in6_gif.c,v 1.49 2001/05/14 14:02:17 itojun Exp $
yoda:sys# uname -a
FreeBSD yoda.tataz.chchile.org 4.10-STABLE FreeBSD 4.10-STABLE #44: Wed Jul 7 03:35:21 CEST 2004 root@yoda.tataz.chchile.org:/usr/src/sys/compile/YODA i386
%%%
> Hope this helps,
I hope too ;-).
Many thanks,
Regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 16:26:31 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 17EA516A569
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:26:31 +0000 (GMT)
Received: from mail.libertysurf.net (mx-out.tiscali.fr [213.36.80.91])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7178943D53
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:26:30 +0000 (GMT)
(envelope-from ach@meta-x.org)
Received: from [192.168.16.149] (83.157.52.158) by mail.libertysurf.net
(7.1.026) id 41A46BF6011F4AC1; Tue, 25 Jan 2005 17:26:29 +0100
In-Reply-To: <20050125160837.GG59685@obiwan.tataz.chchile.org>
References: <20050124212011.GC59685@obiwan.tataz.chchile.org>
<20050125011615.GB47638@dhcp120.icir.org>
<20050125143327.GD59685@obiwan.tataz.chchile.org>
<20050125144153.GJ47638@dhcp120.icir.org>
<20050125150255.GE59685@obiwan.tataz.chchile.org>
<20050125152209.GK47638@dhcp120.icir.org>
<20050125160837.GG59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D77B2F04-6EED-11D9-A13F-000D936E5C28@meta-x.org>
Content-Transfer-Encoding: 7bit
From: Alex <ach@meta-x.org>
Date: Tue, 25 Jan 2005 17:26:18 +0100
To: Jeremie Le Hen <jeremie@le-hen.org>
X-Mailer: Apple Mail (2.619)
cc: freebsd-net@freebsd.org
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 16:26:31 -0000
Hello,
Since we see ESP traffic directly on the ep0 interface, packets are not
going through gif0 as stated in the routing table. IPsec SPD is
overriding the routing table, can you check (provide us) with setkey
-DP and setkey -D if no SPD is present from your net to 192.168.4.0/24
?
Regards, Alex.
> Yes they are (network on the other side of the tunnel is
> 192.168.4.0/24) :
> %%%
> yoda:tools# netstat -rnf inet
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Netif
> Expire
> default <hidden gw> UGSc 24 17513460 ep0
> [...]
> 192.168.4 192.168.4.13 UGSc 0 691911 gif0
> 192.168.4.13 192.168.1.1 UH 3 6949 gif0
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 16:34:13 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 860A316A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:34:13 +0000 (GMT)
Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252])
by mx1.FreeBSD.org (Postfix) with SMTP id 306C243D3F
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 16:34:13 +0000 (GMT)
(envelope-from darcy@wavefire.com)
Received: (qmail 1564 invoked from network); 25 Jan 2005 17:52:20 -0000
Received: from dbitech.wavefire.com (HELO ?64.141.15.253?)
(darcy@64.141.15.253)
by radius.wavefire.com with SMTP; 25 Jan 2005 17:52:20 -0000
From: Darcy Buskermolen <darcy@wavefire.com>
Organization: Wavefire Technologies Corp.
To: freebsd-net@freebsd.org
Date: Tue, 25 Jan 2005 08:34:11 -0800
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: <200501250834.11393.darcy@wavefire.com>
Subject: ng_nat revisited
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 16:34:13 -0000
It's been a while since the subject of ng_nat appeared on-list, I'm wondering
if there has been anymore work done on this?
--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 17:11:35 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F414D16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:11:34 +0000 (GMT)
Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169])
by mx1.FreeBSD.org (Postfix) with ESMTP id 75FF943D45
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:11:34 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-2.free.fr (Postfix) with ESMTP id DAE35C183;
Tue, 25 Jan 2005 18:11:32 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id EBBD8408E; Tue, 25 Jan 2005 18:11:20 +0100 (CET)
Date: Tue, 25 Jan 2005 18:11:20 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>
Message-ID: <20050125171120.GH59685@obiwan.tataz.chchile.org>
References: <D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
User-Agent: Mutt/1.5.6i
cc: freebsd-net@freebsd.org
cc: Jeremie Le Hen <jeremie@le-hen.org>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 17:11:35 -0000
> Please do the following:
>
> ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
> netstat -I gif0 -w 1
> and see if any packets are counted.
Weirdly, although I get the ICMP echo-reply, the gif0 interface are
not updated.
%%%
yoda:sys# ping -qc 1 -r -S 192.168.1.1 192.168.4.13
PING 192.168.4.13 (192.168.4.13) from 192.168.1.1: 56 data bytes
--- 192.168.4.13 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 56.012/56.012/56.012/0.000 ms
yoda:sys# ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
[1] 63114
yoda:sys# netstat -I gif0 -w 1
input (gif0) output
packets errs bytes packets errs bytes colls
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
^C
%%%
> If you are using IPSec, maybe your packets are encrypted before they go
> to gif. See this article:
> http://groups-beta.google.com/group/sol.lists.freebsd.net/browse_frm/thread/de878d5a36d383f1/ffa608ca991d0c3c?q=tcpdump+gif+freebsd&_done=%2Fgroups%3Fq%3Dtcpdump+gif+freebsd%26&_doneTitle=Back+to+Search&&d#ffa608ca991d0c3c
I prefer this one ;-) :
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=236856+0+archive/2001/freebsd-net/20010506.freebsd-net
Ok, you got it !
In fact, I'm aware that using a gif(4) tunnel and IPSec transport mode is
merely the same as IPSec tunnel mode only and that gif(4) with tunnel mode
is useless, but when I set up my IPSec tunnel, we wanted to have it as
quick as possible, my friend insisted to use gif(4)+tunnel mode, so I did
it. I was planning to change this later back to gif(4)+transport mode
because I believed that the IPSec tunnel was *inside* the gif(4) tunnel,
thus consuming too much bandwidth. In fact it appeared that my gif(4)
interface is totally useless in my setup. I'm going to switch to
transport mode ASAP and tell my friend he owes me and you all a beer.
> Can you post your IPSec policy (with sensitive info removed, of course).
Of course, although this is useless now. Here it is anyway:
%%%
yoda:sys# setkey -DP
192.168.4.0/24[any] 192.168.1.0/24[any] any
in ipsec
esp/tunnel/yy.yy.yy.yy-xx.xx.xx.xx/require
spid=7 seq=1 pid=63145
refcnt=1
192.168.1.0/24[any] 192.168.4.0/24[any] any
out ipsec
esp/tunnel/xx.xx.xx.xx-yy.yy.yy.yy/require
spid=8 seq=0 pid=63145
refcnt=1
%%%
> (Google rulez :-) )
I used Google (but not Google Groups) to look for various strings :
"tcpdump gif0", "gif bpf", ... restricting the search to
site:lists.freebsd.org but I didn't found this post. If I did, I
wouldn't have wasted bandwidth for this thread. I'm sorry. At least,
I hope this will be useful later for someone else. This thread is
after all a bunch of concentrated informations about gif(4) debugging
and IPSec.
Many, many thanks to Bruce and Nickolay, as well as Alex who got the
point too.
Best regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 17:19:42 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F2AA816A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:19:41 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id 523BD43D4C
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:19:39 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id 61C0F65219; Tue, 25 Jan 2005 17:19:35 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 19996-02-2; Tue, 25 Jan 2005 17:19:34 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id CDD89651FC; Tue, 25 Jan 2005 17:19:33 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id BA2F26383; Tue, 25 Jan 2005 17:20:49 +0000 (GMT)
Date: Tue, 25 Jan 2005 17:20:49 +0000
From: Bruce M Simpson <bms@spc.org>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050125172049.GL47638@dhcp120.icir.org>
Mail-Followup-To: Jeremie Le Hen <jeremie@le-hen.org>,
Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>,
freebsd-net@freebsd.org
References:
<D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
<20050125171120.GH59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125171120.GH59685@obiwan.tataz.chchile.org>
cc: freebsd-net@freebsd.org
cc: Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 17:19:42 -0000
On Tue, Jan 25, 2005 at 06:11:20PM +0100, Jeremie Le Hen wrote:
[...]
> thus consuming too much bandwidth. In fact it appeared that my gif(4)
> interface is totally useless in my setup. I'm going to switch to
> transport mode ASAP and tell my friend he owes me and you all a beer.
I forgot to say in my original reply that I was using IPSEC transport
mode. When I was discussing this with Bill Fenner he pointed out that
there was no such thing as IPSEC 'interface mode', though there had
been some discussion during the standards process about the need for
such a thing.
The combination of IPSEC transport mode and a tunneling protocol
provides such a mode.
Regards,
BMS
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 17:38:56 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8F2EA16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:38:56 +0000 (GMT)
Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0376143D39
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:38:56 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix4-2.free.fr (Postfix) with ESMTP id 46ADF2BBA14;
Tue, 25 Jan 2005 18:38:54 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id ADD33407C; Tue, 25 Jan 2005 18:38:42 +0100 (CET)
Date: Tue, 25 Jan 2005 18:38:42 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: Jeremie Le Hen <jeremie@le-hen.org>,
Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>,
freebsd-net@freebsd.org
Message-ID: <20050125173842.GI59685@obiwan.tataz.chchile.org>
References:
<D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
<20050125171120.GH59685@obiwan.tataz.chchile.org>
<20050125172049.GL47638@dhcp120.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125172049.GL47638@dhcp120.icir.org>
User-Agent: Mutt/1.5.6i
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 17:38:56 -0000
> I forgot to say in my original reply that I was using IPSEC transport
> mode. When I was discussing this with Bill Fenner he pointed out that
> there was no such thing as IPSEC 'interface mode', though there had
> been some discussion during the standards process about the need for
> such a thing.
Are you thinking about the enc(4) interface [1] [2] provided with OpenBSD ?
> The combination of IPSEC transport mode and a tunneling protocol
> provides such a mode.
That's exactly what I'm doing now : converting my tunnel mode to gif(4)
and transport mode.
Best regards,
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=enc&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
[2] http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_enc.c
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 19:34:27 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A405B16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 19:34:27 +0000 (GMT)
Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6])
by mx1.FreeBSD.org (Postfix) with SMTP id CAC3743D54
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 19:34:23 +0000 (GMT)
(envelope-from reichert@numachi.com)
Received: (qmail 69913 invoked from network); 25 Jan 2005 19:34:19 -0000
Received: from natto.numachi.com (198.175.254.216)
by meisai.numachi.com with SMTP; 25 Jan 2005 19:34:19 -0000
Received: (qmail 3652 invoked by uid 1001); 25 Jan 2005 19:34:19 -0000
Date: Tue, 25 Jan 2005 14:34:19 -0500
From: Brian Reichert <reichert@numachi.com>
To: Mihai Nitulescu <mihaissa@yahoo.com>
Message-ID: <20050125193419.GJ80512@numachi.com>
References: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
User-Agent: Mutt/1.5.6i
cc: freebsd-net@freebsd.org
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 19:34:27 -0000
On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
> In the LAN i have the other machine application.example.com
> I have some Public IP`s from my ISP :
>
> 193.231.43.25-30
> 255.255.255.248
>
> I want to assign to application.example.com 193.231.43.27 and to route this ip trough nat.example.com
>
> Any ideea how can i do that ?
See 'redirect_address' in natd(8).
I believe you'll also need to assign your public IPs to the external
interface of your NAT box.
I have a similar setup, but I need to review just what I've done
to make that work...
> Please help.
>
> Regards,
>
> Mihai
--
Brian Reichert <reichert@numachi.com>
37 Crystal Ave. #303 Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 19:38:11 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 5CBC116A4CE; Tue, 25 Jan 2005 19:38:11 +0000 (GMT)
Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 2F3E043D53; Tue, 25 Jan 2005 19:38:11 +0000 (GMT)
(envelope-from julian@elischer.org)
Received: from elischer.org (julian.vicor-nb.com [208.206.78.97])
by mail.vicor-nb.com (Postfix) with ESMTP
id 036077A403; Tue, 25 Jan 2005 11:38:11 -0800 (PST)
Message-ID: <41F6A022.5060708@elischer.org>
Date: Tue, 25 Jan 2005 11:38:10 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@freebsd.org>
References: <20050124100717.GA47663@cell.sick.ru>
<41F5FED1.B6EFD246@freebsd.org> <20050125082136.GC57248@cell.sick.ru>
In-Reply-To: <20050125082136.GC57248@cell.sick.ru>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
cc: brooks@freebsd.org
cc: Andre Oppermann <andre@freebsd.org>
cc: net@freebsd.org
Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 19:38:11 -0000
Gleb Smirnoff wrote:
>On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
>A> Style-wise there is only the space after "(void )..." in ip_fw_pfil.c
>A> for the ng_tee case which is too much.
>
>Ok.
>
>A> I don't like the arbitrary back-passing of errors from ng_ipfw. I'm
>A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
>A> else. Getting back any other error is very confusing and non-intuitive
>A> when looking at the error of an application having packets sunk there.
>
>So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
>Julian, Brooks?
>
I don't think that errors should be "sometimes".
we all expect udp to silently discard packets..
and queued data can not return status..
If you want to return the fact that a queue is full somewhere,
then we have messages for that.
>
>A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
>A> doing it? Dummynet should do the same to get it consistent again.
>
>Not sure that this is good. These tags are foreign to ipfw, they belong
>to other facilities.
>
I have no comment
>
>A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
>A> to unwind the stack?
>
>No. The stack will be unwinded when packet travels thru netgraph and returned
>back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
>is configured in ng_ipfw_connect().
>
>
>
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 22:05:45 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 95EBC16A4CE
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 22:05:45 +0000 (GMT)
Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7D08C43D2F
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 22:05:45 +0000 (GMT)
(envelope-from julian@elischer.org)
Received: from elischer.org (julian.vicor-nb.com [208.206.78.97])
by mail.vicor-nb.com (Postfix) with ESMTP
id 6BED37A403; Tue, 25 Jan 2005 14:05:45 -0800 (PST)
Message-ID: <41F6C2B9.8070801@elischer.org>
Date: Tue, 25 Jan 2005 14:05:45 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Darcy Buskermolen <darcy@wavefire.com>
References: <200501250834.11393.darcy@wavefire.com>
In-Reply-To: <200501250834.11393.darcy@wavefire.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: freebsd-net@freebsd.org
Subject: Re: ng_nat revisited
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 22:05:45 -0000
Darcy Buskermolen wrote:
>It's been a while since the subject of ng_nat appeared on-list, I'm wondering
>if there has been anymore work done on this?
>
>
not that I know of.
From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 23:14:00 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 0482016A4CF
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 23:14:00 +0000 (GMT)
Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net
[64.174.116.34])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4B47243D4C
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 23:13:59 +0000 (GMT)
(envelope-from tms3@fskklaw.com)
Received: from fuckms.fsklaw.net [192.168.64.2] by thor-new.fsklaw.com
(ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.0));
Tue, 25 Jan 2005 15:15:05 -0800
Message-ID: <41F6D2F2.9070605@fskklaw.com>
Date: Tue, 25 Jan 2005 15:14:58 -0800
From: "Thomas M. Skeren III" <tms3@fskklaw.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041217
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Reichert <reichert@numachi.com>
References: <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com>
<20050125193419.GJ80512@numachi.com>
In-Reply-To: <20050125193419.GJ80512@numachi.com>
X-ArGoMail-Authenticated: tms3
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
cc: freebsd-net@freebsd.org
cc: Mihai Nitulescu <mihaissa@yahoo.com>
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 23:14:00 -0000
Brian Reichert wrote:
>On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
>
>
>>In the LAN i have the other machine application.example.com
>>I have some Public IP`s from my ISP :
>>
>>193.231.43.25-30
>>255.255.255.248
>>
>>I want to assign to application.example.com 193.231.43.27 and to route this ip trough nat.example.com
>>
>>Any ideea how can i do that ?
>>
>>
I'm having problems with your setup. Is Application.example.com at
193.531.43.27 or is it on the lan with an internal address?
If it's internal, then machines on the lan can see the internal IP, so
there's no reason for it to have a public address. If machines outside
the lan need to get to app.ex.com, then use natd_flags in rc.conf and
point the ports you need opened on app to the local addy of app, and use
the NAT's external addy for the external users of app. That would be
the easiest way if you don't want to give an external addy to app.
Of course the easiest way is to just give app an external addy and plug
it into the ISP supplied router. Unless app is a M$ box, of course.
>
>See 'redirect_address' in natd(8).
>
>I believe you'll also need to assign your public IPs to the external
>interface of your NAT box.
>
>I have a similar setup, but I need to review just what I've done
>to make that work...
>
>
>
>>Please help.
>>
>>Regards,
>>
>>Mihai
>>
>>
>
>
>
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 02:33:49 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 30C4616A4CF
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 02:33:49 +0000 (GMT)
Received: from arginine.spc.org (arginine.spc.org [195.206.69.236])
by mx1.FreeBSD.org (Postfix) with ESMTP id D22AF43D5A
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 02:33:48 +0000 (GMT)
(envelope-from bms@spc.org)
Received: from localhost (localhost [127.0.0.1])
by arginine.spc.org (Postfix) with ESMTP
id 0CD8B653FF; Wed, 26 Jan 2005 02:33:48 +0000 (GMT)
Received: from arginine.spc.org ([127.0.0.1])
by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 27755-01; Wed, 26 Jan 2005 02:33:47 +0000 (GMT)
Received: from empiric.dek.spc.org (unknown [213.210.24.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by arginine.spc.org (Postfix) with ESMTP
id 1ACD2652FE; Wed, 26 Jan 2005 02:33:46 +0000 (GMT)
Received: by empiric.dek.spc.org (Postfix, from userid 1001)
id 27A2F62E0; Wed, 26 Jan 2005 02:33:54 +0000 (GMT)
Date: Wed, 26 Jan 2005 02:33:54 +0000
From: Bruce M Simpson <bms@spc.org>
To: Jeremie Le Hen <jeremie@le-hen.org>
Message-ID: <20050126023354.GJ692@empiric.icir.org>
Mail-Followup-To: Jeremie Le Hen <jeremie@le-hen.org>,
Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>,
freebsd-net@freebsd.org
References:
<D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
<20050125171120.GH59685@obiwan.tataz.chchile.org>
<20050125172049.GL47638@dhcp120.icir.org>
<20050125173842.GI59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050125173842.GI59685@obiwan.tataz.chchile.org>
cc: freebsd-net@freebsd.org
cc: Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>
Subject: Re: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 02:33:49 -0000
On Tue, Jan 25, 2005 at 06:38:42PM +0100, Jeremie Le Hen wrote:
> Are you thinking about the enc(4) interface [1] [2] provided with OpenBSD ?
Somewhat, although whilst enc(4) provides some of this functionality, its
role as far as I can see is mainly to provide a 'tapping point' for filtering
packets as they pass out of the system and into IPSEC (something I believe
we now handle using mbuf tags).
Regards,
BMS
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 09:23:38 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 69C1716A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 09:23:38 +0000 (GMT)
Received: from eddie.nitro.dk (port324.ds1-khk.adsl.cybercity.dk
[212.242.113.79])
by mx1.FreeBSD.org (Postfix) with ESMTP id C5F1343D31
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 09:23:37 +0000 (GMT)
(envelope-from simon@eddie.nitro.dk)
Received: by eddie.nitro.dk (Postfix, from userid 1000)
id A971A119CD9; Wed, 26 Jan 2005 10:23:36 +0100 (CET)
Date: Wed, 26 Jan 2005 10:23:36 +0100
From: "Simon L. Nielsen" <simon@FreeBSD.org>
To: Jeremie Le Hen <jeremie@le-hen.org>,
Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com>,
freebsd-net@freebsd.org
Message-ID: <20050126092335.GA21369@eddie.nitro.dk>
References:
<D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
<20050125171120.GH59685@obiwan.tataz.chchile.org>
<20050125172049.GL47638@dhcp120.icir.org>
<20050125173842.GI59685@obiwan.tataz.chchile.org>
<20050126023354.GJ692@empiric.icir.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <20050126023354.GJ692@empiric.icir.org>
User-Agent: Mutt/1.5.6i
Subject: enc(4) (was: Re: gif(4) and bpf(4))
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 09:23:38 -0000
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2005.01.26 02:33:54 +0000, Bruce M Simpson wrote:
> On Tue, Jan 25, 2005 at 06:38:42PM +0100, Jeremie Le Hen wrote:
> > Are you thinking about the enc(4) interface [1] [2] provided with OpenB=
SD ?
>=20
> Somewhat, although whilst enc(4) provides some of this functionality, its
> role as far as I can see is mainly to provide a 'tapping point' for filte=
ring
> packets as they pass out of the system and into IPSEC (something I believe
> we now handle using mbuf tags).
I have been looking into porting enc(4) from OpenBSD and have some
partial patches at this point. The point of enc(4) AFAIK is to allow
packet filtering of IPsec traffic, basically the ipfw "ipsec" keyword
more generic, and bpf tapping of traffic in and out of IPsec tunnels.
It's not really related to FreeBSD's use of mbuf tags for IPsec
handling, since those are not "visible" from userland. Anyone, please
correct me if I'm wrong.
--=20
Simon L. Nielsen
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFB92GXh9pcDSc1mlERAl4SAJ0ZTirbyYOYqfVaiY89f9OQr31D3gCdHYpy
aXGxKoluKT/fTqmjrPe/bPY=
=f0zv
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 10:12:26 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2902616A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:26 +0000 (GMT)
Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237])
by mx1.FreeBSD.org (Postfix) with ESMTP id DEFBB43D4C
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:24 +0000 (GMT)
(envelope-from Nickolay.Kritsky@astra-sw.com)
Received: from exchange.stardevelopers4msi.com ([192.168.64.10])
j0PGGlT5082449
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 19:16:47 +0300 (MSK)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Jan 2005 19:18:51 +0300
Message-ID: <D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: gif(4) and bpf(4)
thread-index: AcUC+Ix1m4LWvp26T6OqpMlF++pnrAAADyaA
From: "Nickolay Kritsky" <Nickolay.Kritsky@astra-sw.com>
To: "Jeremie Le Hen" <jeremie@le-hen.org>, <freebsd-net@freebsd.org>
Subject: RE: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 10:12:26 -0000
Please do the following:
ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
netstat -I gif0 -w 1
and see if any packets are counted. If you are using IPSec, maybe your =
packets are encrypted before they go to gif. See this article:
http://groups-beta.google.com/group/sol.lists.freebsd.net/browse_frm/thre=
ad/de878d5a36d383f1/ffa608ca991d0c3c?q=3Dtcpdump+gif+freebsd&_done=3D%2Fg=
roups%3Fq%3Dtcpdump+gif+freebsd%26&_doneTitle=3DBack+to+Search&&d#ffa608c=
a991d0c3c
Can you post your IPSec policy (with sensitive info removed, of course).
(Google rulez :-) )
Nick
-----Original Message-----
From: Jeremie Le Hen [mailto:jeremie@le-hen.org]
Sent: Tuesday, January 25, 2005 7:09 PM
To: Jeremie Le Hen; freebsd-net@freebsd.org
Subject: Re: gif(4) and bpf(4)
> Interesting. It seems gif isn't passing anything back at all. Can you =
verify
> that the routes for the addresses you're pinging traverse gif0? I'd
> probably also try csjp@'s bpfstat tool to get a closer look at what's
> going on in bpf.
Yes they are (network on the other side of the tunnel is 192.168.4.0/24) =
:
%%%
yoda:tools# netstat -rnf inet
Routing tables
=20
Internet:
Destination Gateway Flags Refs Use Netif =
Expire
default <hidden gw> UGSc 24 17513460 ep0
<hidden net>/24 link#4 UC 1 0 ep0
<hidden ip> 127.0.0.1 UGHS 0 70 lo0
<hidden gw> 00:07:cb:0e:2e:70 UHLW 25 0 ep0 =
1188
127.0.0.1 127.0.0.1 UH 3 816372 lo0
192.168.0 link#2 UC 1 0 sis1
192.168.0.4 00:a0:cc:da:9f:62 UHLW 2 2188 sis1 =
625
192.168.1 link#1 UC 6 0 sis0
192.168.1.1 00:09:5b:1a:48:94 UHLW 1 31599 lo0
192.168.1.2 00:09:5b:1a:4f:4d UHLW 0 752 sis0 =
1199
192.168.1.25 00:04:23:89:e5:84 UHLW 0 562 sis0 =
353
192.168.1.53 00:04:23:89:e5:84 UHLW 2 167625 sis0 =
1156
192.168.1.222 00:04:23:89:e5:84 UHLW 2 7601091 sis0 =
262
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 15 sis0
192.168.4 192.168.4.13 UGSc 0 691911 gif0
192.168.4.13 192.168.1.1 UH 3 6949 gif0
%%%
I got bpfstat on csjp@'s FreeBSD webpage, but it is designed to work
with devfs. Running RELENG_4, it just does not compile :-(.
> Also try assigning a local address to an instance of gif on the =
affected
> system and pinging a destination through it using the -r and -S =
options
> whilst running tcpdump to be sure.
Here is it, with the interface configuration :
%%%
yoda:sys# ifconfig gif0
gif0: flags=3D8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet <hidden ip> --> <hidden peer ip>
inet6 fe80::209:5bff:fe1a:4894%gif0 prefixlen 64 scopeid 0xa=20
inet 192.168.1.1 --> 192.168.4.13 netmask 0xffffff00=20
yoda:sys# ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
[1] 63095
yoda:sys# /usr/local/sbin/tcpdump -c 2 -ni ep0 'esp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
listening on ep0, link-type EN10MB (Ethernet), capture size 96 bytes
17:06:09.008978 IP 82.233.239.98 > 82.66.245.132: =
ESP(spi=3D0x0f5d2cbd,seq=3D0x3a9)
17:06:09.046998 IP 82.66.245.132 > 82.233.239.98: =
ESP(spi=3D0x00439e94,seq=3D0x3a9)
2 packets captured
106 packets received by filter
0 packets dropped by kernel
yoda:sys# /usr/local/sbin/tcpdump -y null -c 2 -ni gif0 'esp'
tcpdump: data link type null
tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
listening on gif0, link-type NULL (BSD loopback), capture size 96 =
bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
%%%
> Can you post the revision(s) of the source files? e.g.:
> src/sys/net/if_gif.c
> src/sys/netinet/in_gif.c
> src/sys/netinet6/in6_gif.c
> ...and uname -a?
I already looked on CVSweb, but I saw no relevant commit log.
%%%
yoda:sys# ident net/if_gif.c netinet/in_gif.c netinet6/in6_gif.c=20
net/if_gif.c:
$FreeBSD: src/sys/net/if_gif.c,v 1.4.2.15 2002/11/08 16:57:13 ume =
Exp $
$KAME: if_gif.c,v 1.87 2001/10/19 08:50:27 itojun Exp $
=20
netinet/in_gif.c:
$FreeBSD: src/sys/netinet/in_gif.c,v 1.5.2.11 2003/01/23 21:06:45 =
sam Exp $
$KAME: in_gif.c,v 1.54 2001/05/14 14:02:16 itojun Exp $
=20
netinet6/in6_gif.c:
$FreeBSD: src/sys/netinet6/in6_gif.c,v 1.2.2.7 2003/01/23 =
21:06:47 sam Exp $
$KAME: in6_gif.c,v 1.49 2001/05/14 14:02:17 itojun Exp $
yoda:sys# uname -a=20
FreeBSD yoda.tataz.chchile.org 4.10-STABLE FreeBSD 4.10-STABLE #44: =
Wed Jul 7 03:35:21 CEST 2004 =
root@yoda.tataz.chchile.org:/usr/src/sys/compile/YODA i386
%%%
> Hope this helps,
I hope too ;-).
Many thanks,
Regards,
--=20
Jeremie Le Hen
jeremie@le-hen.org
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 10:12:27 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 5CA3116A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:27 +0000 (GMT)
Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9261243D4C
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:26 +0000 (GMT)
(envelope-from Nickolay.Kritsky@astra-sw.com)
Received: from exchange.stardevelopers4msi.com ([192.168.64.10])
j0PEobJ6082157
for <freebsd-net@freebsd.org>; Tue, 25 Jan 2005 17:50:37 +0300 (MSK)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Jan 2005 17:52:40 +0300
Message-ID: <D86BF562467D944EB435513F725B236A07C11F@exchange.stardevelopers4msi.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: gif(4) and bpf(4)
thread-index: AcUCeUmhcZbjTMQFTFGayyOXNQ1USAAcy+xQ
From: "Nickolay Kritsky" <Nickolay.Kritsky@astra-sw.com>
To: "Jeremie Le Hen" <jeremie@le-hen.org>, <freebsd-net@freebsd.org>
Subject: RE: gif(4) and bpf(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 10:12:27 -0000
Hi Jeremie.
Please tell me more about your problem: is it that tcpdump cannot attach =
to device, or it shows no packets when you are sure there is traffic on =
the gif(4) interface, or something else? If there is some error report - =
send it here. Please check that you have free bpf device :-) . What =
version of 4.x are you running? On my 4.9 system if_gif.c has references =
to bpf_mtap in both _input and _output routines. That should work.
Nick
-----Original Message-----
From: Jeremie Le Hen [mailto:jeremie@le-hen.org]
Sent: Tuesday, January 25, 2005 12:20 AM
To: freebsd-net@freebsd.org
Subject: gif(4) and bpf(4)
Hi,
I set up a VPN between a RELENG_4 and a another box. Everything works
well except I can't use tcpdump(8) on the gif(4). IIRC it's a
well-known problem - I already saw this topic here but can't find these
posts again - but I cannot understand why it doesn't work since
if_gif.c in RELENG_4 has bpfattach(), bpf_mtap2(), ...
Is it supposed to work or not ? If not, does it work on RELENG_5 ?
My very -CURRENT laptop succeeds in opening bpf(4) on a gif(4) =
interface.
Regards,
--=20
Jeremie Le Hen
jeremie@le-hen.org
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 10:12:32 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 BE09916A4F4
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:32 +0000 (GMT)
Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237])
by mx1.FreeBSD.org (Postfix) with ESMTP id C56CE43D2D
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:27 +0000 (GMT)
(envelope-from Nickolay.Kritsky@astra-sw.com)
Received: from exchange.stardevelopers4msi.com ([192.168.64.10])
j0IBU6ke043054
for <freebsd-net@freebsd.org>; Tue, 18 Jan 2005 14:30:06 +0300 (MSK)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Jan 2005 14:31:58 +0300
Message-ID: <D86BF562467D944EB435513F725B236A07C0F2@exchange.stardevelopers4msi.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Using aliased IPs for outbound requests
thread-index: AcT83bNpuIBaNqI9Qw6/i4VV2vPH8QAczKYQ
From: "Nickolay Kritsky" <Nickolay.Kritsky@astra-sw.com>
To: "Mike Wesson" <fbsdnet@mikewesson.com>, <freebsd-net@freebsd.org>
Subject: RE: Using aliased IPs for outbound requests
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 10:12:32 -0000
See documentation for squid. It has such option. I cannot look into =
config file right now, but I remember that I have used it successfully.
-----Original Message-----
From: Mike Wesson [mailto:fbsdnet@mikewesson.com]
Sent: Tuesday, January 18, 2005 12:44 AM
To: freebsd-net@freebsd.org
Subject: Using aliased IPs for outbound requests
Hi there, I have a client who wants a http proxy set up using multiple =
ips,
and he wants the IP the request is sent to to send the outbound request,
rather than the interfaces main IP. I've done the usual google =
searching
and consulted the documentation for both Squid and mod_proxy and have =
not
found a solution. If anyone has any suggestions, they would be very =
much
appreciated (Aside from using jails, which I suspect would work but =
would be
cumbersome). Thanks!
Mike
=20
_______________________________________________
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 Jan 26 10:12:34 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 578D116A514
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:34 +0000 (GMT)
Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3224C43D2D
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 10:12:33 +0000 (GMT)
(envelope-from Nickolay.Kritsky@astra-sw.com)
Received: from exchange.stardevelopers4msi.com ([192.168.64.10])
j0IBYbQA043061
for <freebsd-net@freebsd.org>; Tue, 18 Jan 2005 14:34:37 +0300 (MSK)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="WINDOWS-1250"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Jan 2005 14:36:29 +0300
Message-ID: <D86BF562467D944EB435513F725B236A07C0F3@exchange.stardevelopers4msi.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Network accounting
thread-index: AcT80LFoSUWCz4YPSgGiCtgrIeCPngAgO1eg
From: "Nickolay Kritsky" <Nickolay.Kritsky@astra-sw.com>
To: "Andrew Seguin" <asegu@borgtech.ca>, <freebsd-net@freebsd.org>
Subject: RE: Network accounting
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 10:12:34 -0000
I am using trafd and I am quite happy with it, if I dump internal tables =
to disk often enough.
Nick
-----Original Message-----
From: Andrew Seguin [mailto:asegu@borgtech.ca]
Sent: Monday, January 17, 2005 11:11 PM
To: freebsd-net@freebsd.org
Subject: Network accounting
I=92ve searched Google, I=92ve searched through the FreeBSD-net archives =
and
have gotten a few leads to what I=92m seeking, but unfortunately, =
nothing
solid enough for me to go off of (so yes, I=92ve been doing some =
homework
first! ;) )
=20
But, here=92s my situation. A dedicated FreeBSD transparent =
firewall-bridge
with 3 NICs (two for the bridge w/o IP, one for console). I=92m using =
IPFW for
the firewall, and at the moment I=92m doing some very bare-bones =
statistics
via a couple of count rules. I track abusive users through random usage =
of
TCPDump (when I feel like it basically).
=20
However, I have some heavy downloader=92s on the campus so I want to do =
deep
statistics gathering. Mainly, how much is (daily/weekly/monthly) the =
traffic
by IP address and independently the traffic by service (HTTP/SMTP).
=20
So my research seems to indicate that the best is to use something to
generate netflow data (Maybe IPCad?). However, I sort of feel that=92s a =
bit
heavy for my needs, I=92d have only one source of data collection. But =
it=92s
not like I=92m tight in processor power nor hard disk space and I even =
have a
second server already running web/Mysql under my control. I have a small
list of tools, but it all leads up to my question.
=20
I therefore ask out to the list, what recommendations for traffic
accounting/statistics gathering can you give me?
--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 1/16/2005
=20
_______________________________________________
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 Jan 26 17:37:52 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 3AA1916A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 17:37:52 +0000 (GMT)
Received: from mailhost.schluting.com (schluting.com [131.252.214.57])
by mx1.FreeBSD.org (Postfix) with ESMTP id 053B643D4C
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 17:37:52 +0000 (GMT)
(envelope-from charlie@schluting.com)
Received: from localhost (localhost [127.0.0.1])
by mailhost.schluting.com (Postfix) with ESMTP id AE1252281
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 09:37:51 -0800 (PST)
Received: from mailhost.schluting.com ([127.0.0.1])
by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 74959-06 for <freebsd-net@freebsd.org>;
Wed, 26 Jan 2005 09:37:46 -0800 (PST)
Received: from [131.252.213.83] (schrodinger.cat.pdx.edu [131.252.213.83])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mailhost.schluting.com (Postfix) with ESMTP id 5605E20F9
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 09:37:46 -0800 (PST)
Message-ID: <41F7D566.1030601@schluting.com>
Date: Wed, 26 Jan 2005 09:37:42 -0800
From: Charlie Schluting <charlie@schluting.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
References: <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>
In-Reply-To: <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by your mom at schluting.com
Subject: Re: vlans changed?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 17:37:52 -0000
On 1/20/2005 2:33 AM, Robert Watson wrote:
> On Wed, 19 Jan 2005, Charlie Schluting wrote:
>>Now, in 5.3, the only thing I can get working is to configure the em0
>>int with the IP, and set the trunk to have the native vlan corresponding
>>to that IP. Weird.
>>
>>Also, is there a way to stop em(4) from stripping dot1q tags in
>>hardware? I'd like to see them with tcpdump. What kind of a performance
>>hit does this involve?
>
>
> Try "ifconfig em0 -vlanhwtag" and see if that helps. If not, take a look
> in if_em.c:em_setup_interface(), and you'll see two lines like this:
Ok, I seem to have forgotten the nature of this bug, even though I had
previously run into it. Heh. This is a different computer, and em0 (aside from
vlans not working properly) "turns off" every once in a while too. It happened
with the fxp driver on my other box.
What a coincidence that I asked about disabling hw tagging :)
So, I've disabled vlanhwtag with ifconfig. If it worked, the interface will
stay up all day today. It normally doesn't last more than 4 hours on this box.
By "up" I mean it will continue to work.. it doesn't really go down.
I'll let you know.
If this doesn't help, I'll try commenting out the stuff you mentioned in
em_setup_interface().
-Charlie
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 18:16:56 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7F8BE16A4CF
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:16:56 +0000 (GMT)
Received: from web30402.mail.mud.yahoo.com (web30402.mail.mud.yahoo.com
[68.142.200.105])
by mx1.FreeBSD.org (Postfix) with SMTP id 69F4943D2F
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:16:55 +0000 (GMT)
(envelope-from mihaissa@yahoo.com)
Received: (qmail 2834 invoked by uid 60001); 26 Jan 2005 18:16:55 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
b=N9KrKQkbOtesexrhlKLUyI+OEGcARFallTMnLAYp83pxWN/Z0ic4Ikc3CAEVxeZdM9fyHpvEOvgOtkQ9O09PpXrKNbA0zpYrrXKLcJiiO9W0kKLC3gNIV9yfXp90O9BDeQbSdIfyvjGfihyc7uGddVIxBvkV0IXKwwvGvT4Lubw=
;
Message-ID: <20050126181654.2832.qmail@web30402.mail.mud.yahoo.com>
Received: from [193.231.73.33] by web30402.mail.mud.yahoo.com via HTTP;
Wed, 26 Jan 2005 10:16:54 PST
Date: Wed, 26 Jan 2005 10:16:54 -0800 (PST)
From: Mihai Nitulescu <mihaissa@yahoo.com>
To: "Thomas M. Skeren III" <tms3@fskklaw.com>,
Brian Reichert <reichert@numachi.com>
In-Reply-To: <41F6D2F2.9070605@fskklaw.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
cc: freebsd-net@freebsd.org
cc: Mihai Nitulescu <mihaissa@yahoo.com>
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 18:16:56 -0000
Hi all,
Here is what i have done so far.
i worked only on the nat.ex.com
internet
|
|
________rl0(193.23143.33)________
| |
| nat.example.com |
| |
|_______rl1(192.168.0.254)________|
|
_____|______
|___________| switch
| |
-------------------------------| |----------------------|
LAN _xl0(193.231.43.26)
| |
| app.example.com |
| ________________|
OK,
So I created on nat.example.com on rl1 a virtual interface
ifconfig rl1 alias 193.231.43.25 255.255.255.248
After that i created a route for this new interface
route add 193.231.43.25 193.231.43.33 -iface
So now i can ping rl1 rl0 & internet from the app.example.com but i cannot access this machine from the internet.
Any thoughts on that ??
rgds
Mihai
"Thomas M. Skeren III" <tms3@fskklaw.com> wrote:
Brian Reichert wrote:
On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
In the LAN i have the other machine application.example.comI have some Public IP`s from my ISP : 193.231.43.25-30 255.255.255.248 I want to assign to application.example.com 193.231.43.27 and to route this ip trough nat.example.com Any ideea how can i do that ?
I'm having problems with your setup. Is Application.example.com at 193.531.43.27 or is it on the lan with an internal address?
If it's internal, then machines on the lan can see the internal IP, so there's no reason for it to have a public address. If machines outside the lan need to get to app.ex.com, then use natd_flags in rc.conf and point the ports you need opened on app to the local addy of app, and use the NAT's external addy for the external users of app. That would be the easiest way if you don't want to give an external addy to app.
Of course the easiest way is to just give app an external addy and plug it into the ISP supplied router. Unless app is a M$ box, of course.
See 'redirect_address' in natd(8).I believe you'll also need to assign your public IPs to the externalinterface of your NAT box.I have a similar setup, but I need to review just what I've doneto make that work...
Please help. Regards, Mihai
---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 18:33:32 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 9AF7216A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:33:32 +0000 (GMT)
Received: from ded.office.wildcard.net.uk (gw.office.wildcard.net.uk
[82.138.232.49])
by mx1.FreeBSD.org (Postfix) with ESMTP id 26E2C43D49
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:33:31 +0000 (GMT)
(envelope-from lee@wildcard.net.uk)
Received: from gate.internal.office.wildcard.net.uk ([192.168.15.3]
helo=gate.wildcard.net.uk)
by ded.office.wildcard.net.uk with esmtp (Exim 4.24; FreeBSD 4.7)
id 1Ctryr-00038m-0C; Wed, 26 Jan 2005 18:33:29 +0000
Message-Id: <6.1.0.6.0.20050126182620.01b2d928@mail.wildcardinternet.co.uk>
X-Sender: ljohns@mail.wildcardinternet.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Wed, 26 Jan 2005 18:33:39 +0000
To: Mihai Nitulescu <mihaissa@yahoo.com>
From: Lee Johnston <lee@wildcard.net.uk>
In-Reply-To: <20050126181654.2832.qmail@web30402.mail.mud.yahoo.com>
References: <41F6D2F2.9070605@fskklaw.com>
<20050126181654.2832.qmail@web30402.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
cc: freebsd-net@freebsd.org
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 18:33:32 -0000
Hi there,
Basically because NAT is altering all packets leaving on rl0 on your 'nat'
machine, to the outside world the packets leaving your network, from 'app'
machine will appear to be from your 'nat' machines external interface.
The way to get around this is to tell natd not to perform NAT on IP
addresses that are public (i.e. not unregistered addresses as defined in
RFC1918, so not the 192.168. range and the others).
Easy way to do this is to pass natd the -unregistered_only option. Man page
for natd explains this a bit better.
You will only be able to route via your 'nat' box if your ISP has routed
that block of IPs to your external IP on the box.. Hope that makes sense.
Regards,
Lee.
At 18:16 26/01/2005, Mihai Nitulescu wrote:
>Hi all,
>
>Here is what i have done so far.
>
>i worked only on the nat.ex.com
>
> internet
> |
> |
> ________rl0(193.23143.33)________
> | |
> | nat.example.com |
> | |
> |_______rl1(192.168.0.254)________|
> |
> _____|______
> |___________| switch
> | |
> -------------------------------| |----------------------|
> LAN
> _xl0(193.231.43.26)
> |
> |
> |
> app.example.com |
> |
> ________________|
>
>
>
>OK,
>So I created on nat.example.com on rl1 a virtual interface
>ifconfig rl1 alias 193.231.43.25 255.255.255.248
>After that i created a route for this new interface
>route add 193.231.43.25 193.231.43.33 -iface
>
>So now i can ping rl1 rl0 & internet from the app.example.com but i cannot
>access this machine from the internet.
>
>Any thoughts on that ??
>
>rgds
>
>Mihai
>
>
>
>
>
>
>
>"Thomas M. Skeren III" <tms3@fskklaw.com> wrote:
>Brian Reichert wrote:
>
>On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
>
>In the LAN i have the other machine application.example.comI have some
>Public IP`s from my ISP : 193.231.43.25-30 255.255.255.248 I want to
>assign to application.example.com 193.231.43.27 and to route this ip
>trough nat.example.com Any ideea how can i do that ?
>I'm having problems with your setup. Is Application.example.com at
>193.531.43.27 or is it on the lan with an internal address?
>
>If it's internal, then machines on the lan can see the internal IP, so
>there's no reason for it to have a public address. If machines outside
>the lan need to get to app.ex.com, then use natd_flags in rc.conf and
>point the ports you need opened on app to the local addy of app, and use
>the NAT's external addy for the external users of app. That would be the
>easiest way if you don't want to give an external addy to app.
>
>Of course the easiest way is to just give app an external addy and plug it
>into the ISP supplied router. Unless app is a M$ box, of course.
>See 'redirect_address' in natd(8).I believe you'll also need to assign
>your public IPs to the externalinterface of your NAT box.I have a similar
>setup, but I need to review just what I've doneto make that work...
>
>Please help. Regards, Mihai
>
>
>
>
>
>---------------------------------
>Do you Yahoo!?
> Yahoo! Search presents - Jib Jab's 'Second Term'
>_______________________________________________
>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"
Lee Johnston, Wildcard Internet
t: +44 (0)845 165 1510 f: +44 (0)845 165 1511 m: +44 (0)7795 423 617
e: lee@wildcard.net.uk www: http://www.wildcard.net.uk/
Web Development - Domains - Hosting - Co-location - Dedicated Servers
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 18:38:24 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2F91016A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:38:24 +0000 (GMT)
Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35])
by mx1.FreeBSD.org (Postfix) with ESMTP id 76F6743D58
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 18:38:23 +0000 (GMT)
(envelope-from dionch@freemail.gr)
Received: by smtp.freemail.gr (Postfix, from userid 101)
id B56BBBC030; Wed, 26 Jan 2005 20:38:21 +0200 (EET)
Received: from R3B (unknown [62.38.162.62])by smtp.freemail.gr (Postfix) with
ESMTP id 0EE4EBC024;Wed, 26 Jan 2005 20:38:16 +0200 (EET)
Message-ID: <007601c503d6$026bc8b0$0100000a@R3B>
From: "Chris Dionissopoulos" <dionch@freemail.gr>
To: "Mihai Nitulescu" <mihaissa@yahoo.com>,
"Thomas M. Skeren III" <tms3@fskklaw.com>,
"Brian Reichert" <reichert@numachi.com>
References: <20050126181654.2832.qmail@web30402.mail.mud.yahoo.com>
Date: Wed, 26 Jan 2005 20:36:46 +0200
MIME-Version: 1.0
Content-Type: text/plain;format=flowed;charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
cc: freebsd-net@freebsd.org
cc: Mihai Nitulescu <mihaissa@yahoo.com>
Subject: Re: public ip address behind nat
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Chris Dionissopoulos <dionch@freemail.gr>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 18:38:24 -0000
1. Dont add any alias to rl1, just keep 192.168.0.254/24
2. Delete all ip/masks of app.example.com.
3. Add 193.231.43.26/32 as ip/mask to app.example.com
4. Do a "route add 192.168.0.254/32 -interface ($nic) -cloning
on app.example.com
5. and "route add default 192.168.0.254" on app.example.com
6. Delete all ip/masks on rl0 only, of nat.example.com
7. Add 193.231.43.33/32 as ip/mask to nat.example.com (rl0).
8. Do a "route add nat_gateway/32 -interface rl0 -cloning" on
nat.example.com
9. and "route add default nat_gateway" on nat.example.com
10. and "route add 193.231.43.26/32 -interface rl1 -cloning" on
nat.example.com
worked?
Chris.
> Hi all,
>
> Here is what i have done so far.
>
> i worked only on the nat.ex.com
>
> internet
> |
> |
> ________rl0(193.23143.33)________
> | |
> | nat.example.com |
> | |
> |_______rl1(192.168.0.254)________|
> |
> _____|______
> |___________| switch
> | |
> -------------------------------| |----------------------|
> LAN _xl0(193.231.43.26)
> |
> |
> |
> app.example.com |
> |
> ________________|
>
>
>
> OK,
> So I created on nat.example.com on rl1 a virtual interface
> ifconfig rl1 alias 193.231.43.25 255.255.255.248
> After that i created a route for this new interface
> route add 193.231.43.25 193.231.43.33 -iface
>
> So now i can ping rl1 rl0 & internet from the app.example.com but i cannot
> access this machine from the internet.
>
> Any thoughts on that ??
>
> rgds
>
> Mihai
>
>
>
>
>
>
>
> "Thomas M. Skeren III" <tms3@fskklaw.com> wrote:
> Brian Reichert wrote:
>
> On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote:
>
> In the LAN i have the other machine application.example.comI have some
> Public IP`s from my ISP : 193.231.43.25-30 255.255.255.248 I want to
> assign to application.example.com 193.231.43.27 and to route this ip
> trough nat.example.com Any ideea how can i do that ?
> I'm having problems with your setup. Is Application.example.com at
> 193.531.43.27 or is it on the lan with an internal address?
>
> If it's internal, then machines on the lan can see the internal IP, so
> there's no reason for it to have a public address. If machines outside
> the lan need to get to app.ex.com, then use natd_flags in rc.conf and
> point the ports you need opened on app to the local addy of app, and use
> the NAT's external addy for the external users of app. That would be the
> easiest way if you don't want to give an external addy to app.
>
> Of course the easiest way is to just give app an external addy and plug it
> into the ISP supplied router. Unless app is a M$ box, of course.
> See 'redirect_address' in natd(8).I believe you'll also need to assign
> your public IPs to the externalinterface of your NAT box.I have a similar
> setup, but I need to review just what I've doneto make that work...
>
> Please help. Regards, Mihai
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Search presents - Jib Jab's 'Second Term'
> _______________________________________________
> 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"
____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.
From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 20:57:45 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7B96116A4CE
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 20:57:45 +0000 (GMT)
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202])
by mx1.FreeBSD.org (Postfix) with ESMTP id 086EC43D3F
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 20:57:45 +0000 (GMT)
(envelope-from jsimola@gmail.com)
Received: by wproxy.gmail.com with SMTP id 58so163698wri
for <freebsd-net@freebsd.org>; Wed, 26 Jan 2005 12:57:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
b=OtSVaAinaPYU77lPFbYKgSQC+inxWh9bvtKD9Htkls5LyjiF0s25Q9uazvascl+M1E493b/rjyLPHx4KtO9n50v9u6UP+FQOjPjYkwVa2/EHfHGtRD3JuFvRxFyfOcphK3pcP7gn9pZnzUMNIcnPELCpC2wpFUOt7wKcZG7pXKw=
Received: by 10.54.29.22 with SMTP id c22mr301674wrc;
Wed, 26 Jan 2005 12:57:41 -0800 (PST)
Received: by 10.54.39.34 with HTTP; Wed, 26 Jan 2005 12:57:41 -0800 (PST)
Message-ID: <8eea04080501261257583771cf@mail.gmail.com>
Date: Wed, 26 Jan 2005 12:57:41 -0800
From: Jon Simola <jsimola@gmail.com>
To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: em(4) VLAN + PROMISC followup question
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: jon@abccomm.com
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2005 20:57:45 -0000
Referencing:
http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005738.html
I appear to have hit a similar or the same problem (with the exception
that I'm not bridging with the vlan), has anyone (Robert Watson
appears to be the lead) come up with anything?
My config is 5.3-STABLE with em1 the parent for a handful of vlans.
em1: flags=18843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,POLLING> mtu 1500
options=5b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING>
inet6 fe80::230:48ff:fe72:f30b%em1 prefixlen 64 scopeid 0x6
ether 00:30:48:72:f3:0b
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
vlan120: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet xxx.xx.177.254 netmask 0xffffff00 broadcast 209.53.177.255
inet6 fe80::205:5dff:fe71:8d20%vlan120 prefixlen 64 scopeid 0xd
ether 00:30:48:72:f3:0b
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
vlan: 120 parent interface: em1
Running a tcpdump on either em1 or one of the vlan interfaces reduces
throughput by a factor of 10 or so. Running tcpdump with the -p option
does not.
This is a steady stream of 10 to 20 Mbps of traffic, routing 11 /24s
over 4 vlans, kernel polling is enabled for the em devices.
Thank you,
Jon Simola
Systems Administrator
ABC Communications
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 00:43:04 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 31D1616A4CE
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 00:43:04 +0000 (GMT)
Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169])
by mx1.FreeBSD.org (Postfix) with ESMTP id B181043D48
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 00:43:03 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-2.free.fr (Postfix) with ESMTP id 7D43EC023;
Thu, 27 Jan 2005 01:43:01 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id DFE9E407C; Thu, 27 Jan 2005 01:42:48 +0100 (CET)
Date: Thu, 27 Jan 2005 01:42:48 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: jon@abccomm.com
Message-ID: <20050127004248.GP59685@obiwan.tataz.chchile.org>
References: <8eea04080501261257583771cf@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8eea04080501261257583771cf@mail.gmail.com>
User-Agent: Mutt/1.5.6i
cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject: Re: em(4) VLAN + PROMISC followup question
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 00:43:04 -0000
> Referencing:
> http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005738.html
>
> I appear to have hit a similar or the same problem (with the exception
> that I'm not bridging with the vlan), has anyone (Robert Watson
> appears to be the lead) come up with anything?
I think it has just been commited in -CURRENT. See revs 1.58, 1.59 and
1.60. In fact this is a small workaround until there is a working
solution proposed, if I understood correctly.
Regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 08:32:14 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 5814116A4D0
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 08:32:14 +0000 (GMT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp
[202.249.10.124])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4F84043D5F
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 08:32:13 +0000 (GMT)
(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp
[3ffe:501:100f::35])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id C52C415225; Thu, 27 Jan 2005 17:32:08 +0900 (JST)
Date: Thu, 27 Jan 2005 17:32:35 +0900
Message-ID: <y7vy8efuva4.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<jinmei@isl.rdc.toshiba.co.jp>
To: "Michael C. Cambria" <mcc@fid4.com>
In-Reply-To: <41F283CD.1030709@fid4.com>
References: <41F283CD.1030709@fid4.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
cc: freebsd-net@freebsd.org
Subject: Re: starting rtadvd with multiple interfaces
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 08:32:14 -0000
>>>>> On Sat, 22 Jan 2005 11:48:13 -0500,
>>>>> "Michael C. Cambria" <mcc@fid4.com> said:
> On 4.10-Stable & 5.3-Stable, I'm able to forward IPv6 traffic just fine
> when I manually start rtadvd. However, each reboot, only one interface
> supplied to rtadvd_interfaces actually gets enabled. ps ax shows just
> one interface supplied and hosts just never see the router
> advertisements. Only when I kill the process, and restart manually do
> all interfaces get enabled.
At least on a 4.8R(with some patches) machine, the following in
/etc/rc.conf works fine:
rtadvd_interfaces="fxp0 gif0 gif1 gif2 gif3"
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 14:38:40 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A8A5316A4CE
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 14:38:40 +0000 (GMT)
Received: from mail102.csoft.net (lilly.csoft.net [63.111.22.101])
by mx1.FreeBSD.org (Postfix) with SMTP id 3295443D3F
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 14:38:39 +0000 (GMT)
(envelope-from mcc@fid4.com)
Received: (qmail 89383 invoked from network); 27 Jan 2005 14:38:36 -0000
Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110)
by mail102.csoft.net with SMTP; 27 Jan 2005 14:38:36 -0000
Message-ID: <41F8FD69.3080606@fid4.com>
Date: Thu, 27 Jan 2005 09:40:41 -0500
From: "Michael C. Cambria" <mcc@fid4.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
References: <41F283CD.1030709@fid4.com> <y7vy8efuva4.wl@ocean.jinmei.org>
In-Reply-To: <y7vy8efuva4.wl@ocean.jinmei.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: starting rtadvd with multiple interfaces
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 14:38:40 -0000
JINMEI Tatuya / 神明é”哉 wrote:
>>>>>>On Sat, 22 Jan 2005 11:48:13 -0500,
>>>>>>"Michael C. Cambria" <mcc@fid4.com> said:
>
>
>>On 4.10-Stable & 5.3-Stable, I'm able to forward IPv6 traffic just fine
>>when I manually start rtadvd. However, each reboot, only one interface
>>supplied to rtadvd_interfaces actually gets enabled. ps ax shows just
>>one interface supplied and hosts just never see the router
>>advertisements. Only when I kill the process, and restart manually do
>>all interfaces get enabled.
>
>
> At least on a 4.8R(with some patches) machine, the following in
> /etc/rc.conf works fine:
>
> rtadvd_interfaces="fxp0 gif0 gif1 gif2 gif3"
On 4.10 Stable and 5.3 stable listing more than one interface doesn't
"work" for me. By work I mean rtadvd isn't running on all interfaces I
supply to rtadvd_interfaces in rc.conf.
Since I can start rtadvd manually, I'm curious about your setup. Are
you using tspc to setup tunnels (at boot)? If not, this may be my
problem. I've never tried rebooting without the tunnel, so I'll try
that when I get a chance. I'll bet rtadvd is being started just fine,
then tspc starts up and changes things.
We're actually using IPv6 so I can't just take it down at the moment to
try my theory.
Thanks,
MikeC
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 15:00:34 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 9888B16A4CF
for <net@freebsd.org>; Thu, 27 Jan 2005 15:00:34 +0000 (GMT)
Received: from 212.106.239.101.adsl.jazztel.es
(212.106.239.101.adsl.jazztel.es [212.106.239.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id A523A43D2F
for <net@freebsd.org>; Thu, 27 Jan 2005 15:00:32 +0000 (GMT)
(envelope-from josemi@freebsd.jazztel.es)
Received: from orion.redesjm.local (orion.redesjm.local [192.168.254.16])
j0RF0TIK036717
for <net@freebsd.org>; Thu, 27 Jan 2005 16:00:30 +0100 (CET)
(envelope-from josemi@freebsd.jazztel.es)
From: Jose M Rodriguez <josemi@freebsd.jazztel.es>
Organization: Redes JM
To: net@freebsd.org
Date: Thu, 27 Jan 2005 16:00:42 +0100
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200501271600.42408.josemi@freebsd.jazztel.es>
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.8;
VDF: 6.29.0.75; host: antares.redesjm.local)
Subject: [OT] aal5 pdu CRC
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 15:00:34 -0000
Hi,
get some free time to work in uadsl, but have a problem. Hope someone that
can read ITU I.363 can answer this.
Every usb adsl modem implementation I see doesn't obey aal5 pdu encoding
standards, which requires that the PDU trailer come at the begin of a fresh
cell.
So, I think that the modem must rework this and generate two cells on the
wire. Due how this modems works, I doubt that the modem recalculate PDU CRC
itself, So...
Can someone confir if the CRC covers the PAD? I'm begin to think that the CRC
only covers the playload and the pdu-trailer.
--
josemi
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 15:07:29 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 AF8B616A4CE
for <net@freebsd.org>; Thu, 27 Jan 2005 15:07:29 +0000 (GMT)
Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8566743D2F
for <net@freebsd.org>; Thu, 27 Jan 2005 15:07:28 +0000 (GMT)
(envelope-from Hartmut.Brandt@dlr.de)
Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS
secured channel with Microsoft SMTPSVC(5.0.2195.6713);
Thu, 27 Jan 2005 16:07:26 +0100
Date: Thu, 27 Jan 2005 16:10:59 +0100 (CET)
From: Harti Brandt <hartmut.brandt@dlr.de>
X-X-Sender: brandt_h@beagle.kn.op.dlr.de
To: Jose M Rodriguez <josemi@freebsd.jazztel.es>
In-Reply-To: <200501271600.42408.josemi@freebsd.jazztel.es>
Message-ID: <20050127160658.K55581@beagle.kn.op.dlr.de>
References: <200501271600.42408.josemi@freebsd.jazztel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 27 Jan 2005 15:07:26.0858 (UTC)
FILETIME=[E9BB36A0:01C50481]
cc: net@freebsd.org
Subject: Re: [OT] aal5 pdu CRC
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Harti Brandt <harti@freebsd.org>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 15:07:29 -0000
On Thu, 27 Jan 2005, Jose M Rodriguez wrote:
JMR>Hi,
JMR>
JMR>get some free time to work in uadsl, but have a problem. Hope someone that
JMR>can read ITU I.363 can answer this.
JMR>
JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu encoding
JMR>standards, which requires that the PDU trailer come at the begin of a fresh
JMR>cell.
That is not true. The trailer must be on the END of a cell. Before the
trailer there will be padding bytes so that this happens. If, for example,
you have a one byte PDU the AAL5 PDU will consist of 1 byte information,
39 bytes padding and 8 bytes trailer.
JMR>
JMR>So, I think that the modem must rework this and generate two cells on the
JMR>wire. Due how this modems works, I doubt that the modem recalculate PDU CRC
JMR>itself, So...
JMR>
JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that the CRC
JMR>only covers the playload and the pdu-trailer.
The CRC covers everything but the CRC. The PAD must be filled with zeros
though.
harti
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 15:32:30 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 AB43316A4CF; Thu, 27 Jan 2005 15:32:30 +0000 (GMT)
Received: from 212.106.239.101.adsl.jazztel.es
(212.106.239.101.adsl.jazztel.es [212.106.239.101])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 89CB043D3F; Thu, 27 Jan 2005 15:32:27 +0000 (GMT)
(envelope-from josemi@freebsd.jazztel.es)
Received: from orion.redesjm.local (orion.redesjm.local [192.168.254.16])
j0RFWOwt076679; Thu, 27 Jan 2005 16:32:25 +0100 (CET)
(envelope-from josemi@freebsd.jazztel.es)
From: Jose M Rodriguez <josemi@freebsd.jazztel.es>
Organization: Redes JM
To: freebsd-net@freebsd.org, Harti Brandt <harti@freebsd.org>
Date: Thu, 27 Jan 2005 16:32:37 +0100
User-Agent: KMail/1.7.1
References: <200501271600.42408.josemi@freebsd.jazztel.es>
<20050127160658.K55581@beagle.kn.op.dlr.de>
In-Reply-To: <20050127160658.K55581@beagle.kn.op.dlr.de>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200501271632.37457.josemi@freebsd.jazztel.es>
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.8;
VDF: 6.29.0.75; host: antares.redesjm.local)
cc: net@freebsd.org
Subject: Re: [OT] aal5 pdu CRC
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 15:32:30 -0000
El Jueves, 27 de Enero de 2005 16:10, Harti Brandt escribi=F3:
> On Thu, 27 Jan 2005, Jose M Rodriguez wrote:
>
> JMR>Hi,
> JMR>
> JMR>get some free time to work in uadsl, but have a problem. Hope someone
> that JMR>can read ITU I.363 can answer this.
> JMR>
> JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu
> encoding JMR>standards, which requires that the PDU trailer come at the
> begin of a fresh JMR>cell.
>
> That is not true. The trailer must be on the END of a cell. Before the
> trailer there will be padding bytes so that this happens. If, for example,
> you have a one byte PDU the AAL5 PDU will consist of 1 byte information,
> 39 bytes padding and 8 bytes trailer.
>
At last, rfc1483 and the received logic side seems to point that this is tr=
ue.=20
Most implementations sync the begin of a new PDU after detect the last cell=
=20
by header test. Also, PDU lenght and crc is decode from a fixed ptr on the=
=20
ENDPDU cell (lenght=3Dcell[2]..cell[3], crc=3Dcell[4]..cell[7]).
> JMR>
> JMR>So, I think that the modem must rework this and generate two cells on
> the JMR>wire. Due how this modems works, I doubt that the modem
> recalculate PDU CRC JMR>itself, So...
> JMR>
> JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that
> the CRC JMR>only covers the playload and the pdu-trailer.
>
> The CRC covers everything but the CRC. The PAD must be filled with zeros
> though.
>
This is not so clean. This pad may be take as a cell pad or as a PDU pad. =
If=20
this is take as a cell pad, it may not be part of the CRC (the ENDPDU cell =
is=20
also paded from 8 to 48).
My first guest is that the pad is part of the PDU, but I really doubt that =
the=20
modem may be able to do a full CRC reclaculation.
> harti
=2D-
josemi
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 15:32:30 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 AB43316A4CF; Thu, 27 Jan 2005 15:32:30 +0000 (GMT)
Received: from 212.106.239.101.adsl.jazztel.es
(212.106.239.101.adsl.jazztel.es [212.106.239.101])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 89CB043D3F; Thu, 27 Jan 2005 15:32:27 +0000 (GMT)
(envelope-from josemi@freebsd.jazztel.es)
Received: from orion.redesjm.local (orion.redesjm.local [192.168.254.16])
j0RFWOwt076679; Thu, 27 Jan 2005 16:32:25 +0100 (CET)
(envelope-from josemi@freebsd.jazztel.es)
From: Jose M Rodriguez <josemi@freebsd.jazztel.es>
Organization: Redes JM
To: freebsd-net@freebsd.org, Harti Brandt <harti@freebsd.org>
Date: Thu, 27 Jan 2005 16:32:37 +0100
User-Agent: KMail/1.7.1
References: <200501271600.42408.josemi@freebsd.jazztel.es>
<20050127160658.K55581@beagle.kn.op.dlr.de>
In-Reply-To: <20050127160658.K55581@beagle.kn.op.dlr.de>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200501271632.37457.josemi@freebsd.jazztel.es>
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.8;
VDF: 6.29.0.75; host: antares.redesjm.local)
cc: net@freebsd.org
Subject: Re: [OT] aal5 pdu CRC
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 15:32:31 -0000
El Jueves, 27 de Enero de 2005 16:10, Harti Brandt escribi=F3:
> On Thu, 27 Jan 2005, Jose M Rodriguez wrote:
>
> JMR>Hi,
> JMR>
> JMR>get some free time to work in uadsl, but have a problem. Hope someone
> that JMR>can read ITU I.363 can answer this.
> JMR>
> JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu
> encoding JMR>standards, which requires that the PDU trailer come at the
> begin of a fresh JMR>cell.
>
> That is not true. The trailer must be on the END of a cell. Before the
> trailer there will be padding bytes so that this happens. If, for example,
> you have a one byte PDU the AAL5 PDU will consist of 1 byte information,
> 39 bytes padding and 8 bytes trailer.
>
At last, rfc1483 and the received logic side seems to point that this is tr=
ue.=20
Most implementations sync the begin of a new PDU after detect the last cell=
=20
by header test. Also, PDU lenght and crc is decode from a fixed ptr on the=
=20
ENDPDU cell (lenght=3Dcell[2]..cell[3], crc=3Dcell[4]..cell[7]).
> JMR>
> JMR>So, I think that the modem must rework this and generate two cells on
> the JMR>wire. Due how this modems works, I doubt that the modem
> recalculate PDU CRC JMR>itself, So...
> JMR>
> JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that
> the CRC JMR>only covers the playload and the pdu-trailer.
>
> The CRC covers everything but the CRC. The PAD must be filled with zeros
> though.
>
This is not so clean. This pad may be take as a cell pad or as a PDU pad. =
If=20
this is take as a cell pad, it may not be part of the CRC (the ENDPDU cell =
is=20
also paded from 8 to 48).
My first guest is that the pad is part of the PDU, but I really doubt that =
the=20
modem may be able to do a full CRC reclaculation.
> harti
=2D-
josemi
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 16:02:34 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 AC4F816A4CE
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 16:02:34 +0000 (GMT)
Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0478143D4C
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 16:02:34 +0000 (GMT)
(envelope-from Hartmut.Brandt@dlr.de)
Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS
secured channel with Microsoft SMTPSVC(5.0.2195.6713);
Thu, 27 Jan 2005 17:02:32 +0100
Date: Thu, 27 Jan 2005 17:06:16 +0100 (CET)
From: Harti Brandt <hartmut.brandt@dlr.de>
X-X-Sender: brandt_h@beagle.kn.op.dlr.de
To: Jose M Rodriguez <josemi@freebsd.jazztel.es>
In-Reply-To: <200501271632.37457.josemi@freebsd.jazztel.es>
Message-ID: <20050127170022.A55581@beagle.kn.op.dlr.de>
References: <200501271600.42408.josemi@freebsd.jazztel.es>
<200501271632.37457.josemi@freebsd.jazztel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 27 Jan 2005 16:02:33.0037 (UTC)
FILETIME=[9C5E17D0:01C50489]
cc: freebsd-net@freebsd.org
Subject: Re: [OT] aal5 pdu CRC
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Harti Brandt <harti@freebsd.org>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 16:02:34 -0000
On Thu, 27 Jan 2005, Jose M Rodriguez wrote:
JMR>El Jueves, 27 de Enero de 2005 16:10, Harti Brandt escribi?:
JMR>> On Thu, 27 Jan 2005, Jose M Rodriguez wrote:
JMR>>
JMR>> JMR>Hi,
JMR>> JMR>
JMR>> JMR>get some free time to work in uadsl, but have a problem. Hope someone
JMR>> that JMR>can read ITU I.363 can answer this.
JMR>> JMR>
JMR>> JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu
JMR>> encoding JMR>standards, which requires that the PDU trailer come at the
JMR>> begin of a fresh JMR>cell.
JMR>>
JMR>> That is not true. The trailer must be on the END of a cell. Before the
JMR>> trailer there will be padding bytes so that this happens. If, for example,
JMR>> you have a one byte PDU the AAL5 PDU will consist of 1 byte information,
JMR>> 39 bytes padding and 8 bytes trailer.
JMR>>
JMR>
JMR>At last, rfc1483 and the received logic side seems to point that this is true.
JMR>Most implementations sync the begin of a new PDU after detect the last cell
JMR>by header test. Also, PDU lenght and crc is decode from a fixed ptr on the
JMR>ENDPDU cell (lenght=cell[2]..cell[3], crc=cell[4]..cell[7]).
Well, you can trust me. The reference is the ITU-T recommendation in any
case. The AAL5 CPCS PDU consists of:
1...65535 information bytes
0...47 PAD bytes
1 UU byte
1 CPI byte
2 length field
4 CRC
with the padding done so that the sum is a multiple of 48 byte. Sure you
can use fixed offsets to access the header. It's always at cell[40] for
the last cell.
JMR>> JMR>
JMR>> JMR>So, I think that the modem must rework this and generate two cells on
JMR>> the JMR>wire. Due how this modems works, I doubt that the modem
JMR>> recalculate PDU CRC JMR>itself, So...
JMR>> JMR>
JMR>> JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that
JMR>> the CRC JMR>only covers the playload and the pdu-trailer.
JMR>>
JMR>> The CRC covers everything but the CRC. The PAD must be filled with zeros
JMR>> though.
JMR>>
JMR>
JMR>This is not so clean. This pad may be take as a cell pad or as a PDU pad. If
JMR>this is take as a cell pad, it may not be part of the CRC (the ENDPDU cell is
JMR>also paded from 8 to 48).
JMR>
JMR>My first guest is that the pad is part of the PDU, but I really doubt that the
JMR>modem may be able to do a full CRC reclaculation.
The CRC is computed from everything except the CRC field. PAD must be zero
as must be CPI. I've written this code several times :-/.
harti
From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 22:41:16 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 CACC816A4CE
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 22:41:16 +0000 (GMT)
Received: from mailhost.schluting.com (schluting.com [131.252.214.57])
by mx1.FreeBSD.org (Postfix) with ESMTP id 94E1643D46
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 22:41:16 +0000 (GMT)
(envelope-from charlie@schluting.com)
Received: from localhost (localhost [127.0.0.1])
by mailhost.schluting.com (Postfix) with ESMTP id 352E72114
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 14:41:16 -0800 (PST)
Received: from mailhost.schluting.com ([127.0.0.1])
by localhost (schluting.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 92713-05 for <freebsd-net@freebsd.org>;
Thu, 27 Jan 2005 14:41:10 -0800 (PST)
Received: from [131.252.213.83] (schrodinger.cat.pdx.edu [131.252.213.83])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mailhost.schluting.com (Postfix) with ESMTP id 5EB5320FE
for <freebsd-net@freebsd.org>; Thu, 27 Jan 2005 14:41:10 -0800 (PST)
Message-ID: <41F96E06.7020507@schluting.com>
Date: Thu, 27 Jan 2005 14:41:10 -0800
From: Charlie Schluting <charlie@schluting.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
References: <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>
In-Reply-To: <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by your mom at schluting.com
Subject: vlan + promisc + em(4)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2005 22:41:16 -0000
On 1/20/2005 2:33 AM, Robert Watson wrote:
> Try "ifconfig em0 -vlanhwtag" and see if that helps. If not, take a look
> in if_em.c:em_setup_interface(), and you'll see two lines like this:
>
> #if __FreeBSD_version >= 500000
> ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU;
> ifp->if_capenable |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU;
> #endif
>
> Delete the contents "|FCAP_VLAN_HWTAGGING |" from each line, and that
> should disable support for hardware vlan tagging and stripping in the
> driver. There are several bugs relating to the handling of hardware vlan
> tagging and promiscuous mode in both if_re and if_em. I had hoped to have
> a chance to resolve them over the past couple of months but have not as
> yet been able to do so.
I'm sad to report that neither worked. After doing the ifconfig -vlanhwtag,
the interface stopped recieving packets in about an hour.
After deleting IFCAP_VLAN_HWTAGGING and recompiling/rebooting, it worked for
about 4 hours, then stopped.
tcpdump sees nothing when it happens.. bringing the interface down; then back
up seems to fix it. We've got a cron on the job now :)
-Charlie
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 11:07:48 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F211D16A4CE
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 11:07:47 +0000 (GMT)
Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44])
by mx1.FreeBSD.org (Postfix) with ESMTP id 223A143D1D
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 11:07:47 +0000 (GMT)
(envelope-from tataz@tataz.chchile.org)
Received: from tatooine.tataz.chchile.org
(vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98])
by postfix3-1.free.fr (Postfix) with ESMTP id 2FAC61734F0
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 12:07:46 +0100 (CET)
Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000)
id C95CF407C; Fri, 28 Jan 2005 12:07:31 +0100 (CET)
Date: Fri, 28 Jan 2005 12:07:31 +0100
From: Jeremie Le Hen <jeremie@le-hen.org>
To: freebsd-net@freebsd.org
Message-ID: <20050128110731.GU59685@obiwan.tataz.chchile.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Subject: dummynet and vr(4)/egress broken in 4.11 ?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 11:07:48 -0000
Hi,
I've been using DUMMYNET for two years on RELENG_4. It worked quite
well until I upgrade to 4.11 yesterday. I first thought it was due to
some error in my rule file since it is quite complex : each outgoing
packets goes indeed through one queue for traffic scheduling and
multiple pipes for bandwidth resevation (this configuration is so
powerful that I didn't have to switch to ALTQ yet).
FYI, my packet filter is ipf(8), and I use ipfw(8) for traffic shaping
only.
Weirdly, when I try to go to establish a TCP connection to some host
on Internet, I am able to resolve its name, the SYN packet successully
reach its destination, I get the SYN/ACK but the final ACK packet of the
3WHS is blocked (dropped ? sent is orbit ?) by my FreeBSD 4.11 routern.
As far as I tested, this happens to all TCP connections concerning hosts
inside my network (which are NATed), but it works perfectly from the
FreeBSD router itself.
At first glance, this problem looked like a MTU issue, but flushing all
ipfw rules makes things work correctly. I tried disabling rules step by
step to narrow the problem, but it persists until I remove the last
DUMMYNET pipe, whichever it is. Thus I flushed all rules and just used
(217.12.3.11 is yahoo.fr) :
%%%
# ipfw pipe 1 config bw 10 Kbytes/s
# ipfw add pipe 1 tcp from any to 217.12.3.11 out xmit vr0
%%%
and the same problem happened !
I didn't changed my kernel configuration file so much since my last
kernel upgrade, I juste added gif(4), IPSEC_FILTERGIF and vr(4).
I tested using this rule on ingress and egress of both my internal (sis0)
and external interface (vr0) - inverting IPs where needed :-) - here are
the results :
| ingress | egress |
-----------+---------+---------+
vr0 (ext) | OK | - |
-----------+---------+---------+
sis0 (int) | OK | OK |
-----------+---------+---------+
I think that it is now very important to tell you that while upgrading
my box to FreeBSD 4.11, I also changed my external interface from a 10
MBits ep(4) to a 100 MBits vr(4).
I cannot switch back to ep(4) for the moment since it is not an option
to have downtime, but according to the privous results, I'm pretty
convinced there is a problem with the vr(4) driver (although I don't
know how it can impact DUMMYNET). Maybe the last commit on this
driver in RELENG_4 (sys/pci/if_vr.c, rev 1.26.2.14) is the culprit.
Best regards,
--
Jeremie Le Hen
jeremie@le-hen.org
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 12:17:09 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A92F316A4CE
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 12:17:09 +0000 (GMT)
Received: from mail.acquirer.com (mail.acquirer.com [213.94.200.65])
by mx1.FreeBSD.org (Postfix) with ESMTP id 33FD143D41
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 12:16:57 +0000 (GMT)
(envelope-from nick-list@netability.ie)
X-Envelope-To: <freebsd-net@freebsd.org>
Received: from [IPv6:2001:bb0:ccc0:1::44] ([IPv6:2001:bb0:ccc0:1::44])
by mail.acquirer.com (8.12.10/8.12.9) with ESMTP id j0SCGpQ0018395
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 12:16:51 GMT
(envelope-from nick-list@netability.ie)
From: Nick Hilliard <nick-list@netability.ie>
To: freebsd-net@freebsd.org
Content-Type: multipart/mixed; boundary="=-1uKGEFJriN72s3hIgFEh"
Date: Fri, 28 Jan 2005 12:16:50 +0000
Message-Id: <1106914610.32953.12.camel@pancake.netability.ie>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port
Subject: Marvell Yukon 88E8053
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 12:17:09 -0000
--=-1uKGEFJriN72s3hIgFEh
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
I have a new motherboard (intel 915 p combo, aka msi ms-7058) with an
integrated pci-e Marvell Yukon 88E8053 gig nic installed. By the looks
of it, this ought to be supported by the sk driver. However, if I
modify if_sk.c to add the PCI ID (vendor: 0x11ab, device 0x4362) into
struct sk_devs[], it comes up with the following:
> skc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xc800-0xc8ff mem 0xdfefc000-0xdfefffff irq 16 at device 0.0 on pci3
> skc0: unknown device!
> device_attach: skc0 attach returned 6
src diff attached.
It would be nice to get this nic working, if possible. Can anyone
suggest how one might go about figuring out what's wrong and fixing it?
Nick
--=-1uKGEFJriN72s3hIgFEh
Content-Disposition: attachment; filename=diffs
Content-Type: text/plain; name=diffs; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
--- if_sk.c.orig Thu Jan 6 17:54:47 2005
+++ if_sk.c Fri Jan 28 12:12:55 2005
@@ -157,6 +157,11 @@
},
{
VENDORID_MARVELL,
+ DEVICEID_MARVELL_88E8053,
+ "Marvell Yukon 88E8053 Gigabit Ethernet"
+ },
+ {
+ VENDORID_MARVELL,
DEVICEID_BELKIN_5005,
"Belkin F5D5005 Gigabit Ethernet"
},
--- if_skreg.h.orig Thu Jan 6 17:54:47 2005
+++ if_skreg.h Fri Jan 28 12:12:45 2005
@@ -65,6 +65,12 @@
#define VENDORID_MARVELL 0x11AB
/*
+ * Marvell Yukon 88E8053 PCI Express Gigabit Ethernet Controller
+ */
+
+#define DEVICEID_MARVELL_88E8053 0x4362
+
+/*
* SK-NET gigabit ethernet device IDs
*/
#define DEVICEID_SK_V1 0x4300
--=-1uKGEFJriN72s3hIgFEh--
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 16:54:01 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 42A0216A4CE
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 16:54:01 +0000 (GMT)
Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141])
by mx1.FreeBSD.org (Postfix) with ESMTP id C7EA843D45
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 16:54:00 +0000 (GMT)
(envelope-from chris@wayforth.co.uk)
Received: from [82.69.161.254] (helo=[192.168.168.119])
by heisenberg.zen.co.uk with esmtp (Exim 4.30)
id 1CuZNf-0004oG-Kp
for freebsd-net@freebsd.org; Fri, 28 Jan 2005 16:53:59 +0000
Message-ID: <41FA6E06.8040309@wayforth.co.uk>
Date: Fri, 28 Jan 2005 16:53:26 +0000
From: Chris Cowen <chris@wayforth.co.uk>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041124)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-Heisenberg-IP: [82.69.161.254]
Subject: racoon behaviour when SA expires
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 16:54:01 -0000
Hi
I am using a VPN in tunnel mode between two sites, using racoon to
negotiate the SA with x500 certs and everything works well. However,
when the default SA lifetime of 8 hours (28800 secs) expires, racoon
will not re-establish connection automatically. I'm using ipv4.
A workaround is to flush the SPD on both ends, or sometimes, a restart
of racoon on the remote end is necessary.
I could increase the lifetime of the SA in racoon.conf, but I'd like it
to just stay up (or better still, for racoon to renegotiate successfully
when necessary). BTW can I set lifetime to zero to make the SA last forever?
I've looked on various mailing lists and there does seem to be a hint that
racoon's behaviour is slightly odd when SAs expire (although to be fair,
this is in a post dated 1998 - so it may well have been fixed by now).
After the problems start, the logs report that the SA is up and well and
a tcpdump shows that things are partially working. The packets go from
my local machine, through the tunnel, are decrypted and reach the
destination machine
on the remote network. The reply then gets back as far as the remote racoon
gateway machine and disappears there. There doesn't seem to be any log
info to explain it's disappearance.
The (quite poor) diagram below tries to illustrate this:
local -> localgw ----------------------> remotegw --->remote host
site a tunnel site b
remotegw<---remote host
^- gets this far.
This means that we can't properly deploy our VPN, since it effectively
stops working after 8 hours (or whatever time we set the lifetime to).
Anybody seen anything like this before?
Thanks
Chris
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 17:19:00 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 4E77716A4CE; Fri, 28 Jan 2005 17:19:00 +0000 (GMT)
Received: from mail02.solnet.ch (mail02.solnet.ch [212.101.4.136])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 5FDD543D54; Fri, 28 Jan 2005 17:18:59 +0000 (GMT)
(envelope-from freebsdlists@bsdunix.ch)
Received: from mail02.solnet.ch ([127.0.0.1])
by localhost (mail02.solnet.ch [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 90950-01-48; Fri, 28 Jan 2005 17:18:46 +0000 (GMT)
Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83])
by mail02.solnet.ch (Postfix) with ESMTP id 3C0725C315;
Fri, 28 Jan 2005 17:18:46 +0000 (GMT)
From: Thomas Vogt <freebsdlists@bsdunix.ch>
To: freebsd-performance@freebsd.org
Content-Type: text/plain
Date: Fri, 28 Jan 2005 18:18:19 +0100
Message-Id: <1106932700.48903.58.camel@bert.mlan.solnet.ch>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at mail02.solnet.ch
cc: freebsd-net@freebsd.org
Subject: freebsd router project. Problems with polling?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 17:19:00 -0000
Hello
Overview:
ATM, I've a 4.10 router (xeon 2.4ghz UP, dual on board em gigE
interfaces) in a productive enviroment. The routing software is quagga.
It's doing quite well.
It has an average of 200k pakets per seconds with the full routing
table. The System has polling enabled and interrupt is almost idle and
cpu too.
New one:
Now I'm building a FreeBSD 5.3 or -Stable based router system on CF
cards too. Intel whitepaper shows a max pps for the em cards at 1.4mpps.
I doubt that I can reach more than ~600k pps with the fully routing
table loaded! But this would be ok great.
My system: Xeon 2.4Ghz UP, 2x onboard em GigE interface, 5.3-RELEASE-p4
with if_em.c,v 1.44.2.4.
my configs:
sysctl.conf:
vm.swap_enabled=0
kern.ipc.somaxconn=1024
kern.polling.enable=1
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.interrupt=0
net.inet.udp.recvspace=65536
net.inet.tcp.sendspace=65536
net.inet.tcp.delayed_ack=0
net.inet.tcp.msl=5000
net.inet.ip.maxfragpackets=40
net.inet.ip.maxfragsperpacket=4
net.inet.ip.fw.one_pass=0
net.inet.ip.fw.dyn_max=8192
net.inet.ip.fw.dyn_udp_lifetime=15
net.inet.ip.fastforwarding=1
loader.conf:
kern.ipc.nmbclusters=32768
Kernel config:
http://www.bsdunix.ch/public/ROUTER5
Setup:
I've 3 similar machines.
I use my own udpsend.c and udprec.c to send packages and to count the
pakages. It can send up to 300-330k pps (udp size 64 bytes)
ATM, the full routing table is not loaded. It's a very basic setup. The
goal is to find the maximum pps throughput for the router with small
pakets.
But atm I've problems with device polling.
Graphic:
------------------
|10.0.1.2 udp send |
------------------
|
|
-------em0------
|freebsd router |
-------em1------
|
|
-----------------------
| 192.168.1.2 udp recv |
------------------------
netstat -w 1 (polling disabled)
input (Total) output
packets errs bytes packets errs bytes colls
300531 0 23441438 300585 0 23444792 0
300939 0 25872898 300895 0 25870184 0
300738 0 23457584 300768 0 23460626 0
300304 10 25826466 300304 0 25826876 0
...
Interrupt load is about 70% with net.inet.ip.fastforwarding enabled. If
I disable this the system becomes unusable.
The system hasn't reach the limit yet. But the interrupt is much to
high. It's not worthy to add a second udp sender machine, at the moment.
netstat -w 1 (polling enabled)
input (Total) output
packets errs bytes packets errs bytes colls
150151 47647 12910330 150150 0 12911806 0
150151 0 11711798 150152 0 11711876 0
150151 47665 12910986 150151 0 12911810 0
150151 0 11711798 150151 0 11711798 0
...
Interrupt load is about 10%. CPU is about 60% and with
kern.polling.idle_poll enabled it goes to 100% (as expected).
As you see the speed is droping down to 50% with polling enable and and
I got a lot of errors.
kern.polling.lost_polls: 188748 and kern.polling.suspect: 186919 are
also very high. I don't know why polling is so bad on this machine. All
SMP option are disabled in the kernel and bios.
I tried to do as much as in
http://lists.freebsd.org/pipermail/freebsd-questions/2004-November/064427.html described.
I will prepare others tests with -STABLE and -CURRENT in the next few
days. At the mean time, are they some other magic things config option I
can try? Perhaps increase the HZ to 2000 in the kernel or remove polling
and try smp machine? I doubt that I can run the machine without polling.
If you see 70% interrupt load with 300k pps without polling.
regards
Thomas Vogt
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 18:25:10 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 B873216A4CF
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 18:25:10 +0000 (GMT)
Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27])
by mx1.FreeBSD.org (Postfix) with ESMTP id C748543D41
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 18:25:09 +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 0F6041FFDDB; Fri, 28 Jan 2005 19:25:08 +0100 (CET)
Received: by transport.cksoft.de (Postfix, from userid 66)
id 230D11FFDD8; Fri, 28 Jan 2005 19:25:06 +0100 (CET)
Received: by mail.int.zabbadoz.net (Postfix, from userid 1060)
id 977FE157CB; Fri, 28 Jan 2005 18:23:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by mail.int.zabbadoz.net (Postfix) with ESMTP
id 8CC141538F; Fri, 28 Jan 2005 18:23:09 +0000 (UTC)
Date: Fri, 28 Jan 2005 18:23:09 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net
To: Nick Hilliard <nick-list@netability.ie>
In-Reply-To: <1106914610.32953.12.camel@pancake.netability.ie>
Message-ID: <Pine.BSF.4.53.0501281819030.58983@e0-0.zab2.int.zabbadoz.net>
References: <1106914610.32953.12.camel@pancake.netability.ie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de
cc: freebsd-net@freebsd.org
Subject: Re: Marvell Yukon 88E8053
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 18:25:10 -0000
On Fri, 28 Jan 2005, Nick Hilliard wrote:
Hi,
> integrated pci-e Marvell Yukon 88E8053 gig nic installed. By the looks
is this another of the PCIe ones?
> of it, this ought to be supported by the sk driver. However, if I
> modify if_sk.c to add the PCI ID (vendor: 0x11ab, device 0x4362) into
> struct sk_devs[], it comes up with the following:
>
> > skc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xc800-0xc8ff mem 0xdfefc000-0xdfefffff irq 16 at device 0.0 on pci3
> > skc0: unknown device!
> > device_attach: skc0 attach returned 6
>
> src diff attached.
if it would work the patch doesn't cover everything. See
http://sources.zabbadoz.net/freebsd/patchset/EXPERIMENTAL/if_sk-marvell-88e8050-id.diff
what would need to be patched but be sure to read the disclaimer
at the beginning of this file!
> It would be nice to get this nic working, if possible. Can anyone
> suggest how one might go about figuring out what's wrong and fixing it?
if it's one of the 88E8050s (and it seems to be) you will have to wait
for a new driver to come; I know someone is working on this but I don't
know when we might expect something released.
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 21:59:05 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 10D9616A4CE
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 21:59:05 +0000 (GMT)
Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [213.186.42.179])
by mx1.FreeBSD.org (Postfix) with ESMTP id E677C43D39
for <freebsd-net@freebsd.org>; Fri, 28 Jan 2005 21:59:03 +0000 (GMT)
(envelope-from lists@serpe.org)
Received: (qmail 15404 invoked by uid 503); 28 Jan 2005 21:59:01 -0000
Received: (QMFILT: 1.0); 28 Jan 2005 21:59:01 -0000
Received: from b6.ovh.net (HELO mail49.ha.ovh.net) (213.186.33.56)
by 26.mail-out.ovh.net with DES-CBC3-SHA encrypted SMTP;
28 Jan 2005 21:59:01 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50)
by b0.ovh.net with SMTP; 28 Jan 2005 21:58:56 -0000
Received: from m111.net81-66-254.noos.fr (HELO ?192.168.0.2?)
(lists%serpe.org@81.66.254.111)
by ns0.ovh.net with SMTP; 28 Jan 2005 21:58:56 -0000
Message-ID: <41FAB5A0.2000909@serpe.org>
Date: Fri, 28 Jan 2005 22:58:56 +0100
From: Nicolas <lists@serpe.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-questions@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: freebsd-net@freebsd.org
Subject: dhclient stops trying to get a new lease
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2005 21:59:05 -0000
Hi,
I have a cable modem with dynamic IP, and a FreeBSD 5.3 server just
behind. This server gets its IP with the help of dhclient.
Today I got a huge down because of a problem on the ISP side. During
that time, dhclient made his job trying to get a lease every 4 minutes,
unsuccessfully of course.
But at 10 AM, after 10 hours of trying to get a lease every 4 minutes
(unsuccessfully of course), dhclient completely stopped trying. Thus,
when the line came back up, it didn't got its lease. I had to manually
tell him to get that new lease...
Why did it stopped trying ? What should I do to tell him to try forever
until it can acquire a lease ?
Here is a part of my /var/log/messages :
/* the line went down at midnight. dhclient gets a "fake" IP */
Jan 28 00:00:44 sun dhclient: New IP Address (vr0): 192.168.100.11
Jan 28 00:00:44 sun dhclient: New Subnet Mask (vr0): 255.255.255.0
Jan 28 00:00:44 sun dhclient: New Broadcast Address (vr0): 192.168.100.255
/* 4 minutes later, it retries */
Jan 28 00:04:55 sun dhclient: New IP Address (vr0): 192.168.100.11
Jan 28 00:04:55 sun dhclient: New Subnet Mask (vr0): 255.255.255.0
Jan 28 00:04:55 sun dhclient: New Broadcast Address (vr0): 192.168.100.255
/* [...same thing repeating over and over...] */
/* another time... */
Jan 28 09:57:59 sun dhclient: New IP Address (vr0): 192.168.100.11
Jan 28 09:57:59 sun dhclient: New Subnet Mask (vr0): 255.255.255.0
Jan 28 09:57:59 sun dhclient: New Broadcast Address (vr0): 192.168.100.255
/* the last dhclient-related block.. This time it's a bit different.
** after that block dhclient no more tries anything... */
Jan 28 10:00:45 sun kernel: vr0: Using force reset command.
Jan 28 10:00:45 sun dhclient: New IP Address (vr0): 192.168.100.11
Jan 28 10:00:45 sun dhclient: New Subnet Mask (vr0): 255.255.255.0
Jan 28 10:00:45 sun dhclient: New Broadcast Address (vr0): 192.168.100.255
/* finally I had to restart dhclient to get my "real" IP, once the
** cable came back */
Jan 28 19:34:18 sun kernel: vr0: Using force reset command.
Jan 28 19:34:57 sun dhclient: New IP Address (vr0): 81.66.254.111
Jan 28 19:34:57 sun dhclient: New Subnet Mask (vr0): 255.255.254.0
Jan 28 19:34:57 sun dhclient: New Broadcast Address (vr0): 81.66.255.255
Jan 28 19:34:57 sun dhclient: New Routers: 81.66.254.1
From owner-freebsd-net@FreeBSD.ORG Sat Jan 29 12:05:58 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 E0D5D16A4CE
for <freebsd-net@freebsd.org>; Sat, 29 Jan 2005 12:05:58 +0000 (GMT)
Received: from mail.iinet.net.au (mail-01.iinet.net.au [203.59.3.33])
by mx1.FreeBSD.org (Postfix) with SMTP id 5E9F143D49
for <freebsd-net@freebsd.org>; Sat, 29 Jan 2005 12:05:57 +0000 (GMT)
(envelope-from outsidefactor@iinet.net.au)
Received: (qmail 3231 invoked from network); 29 Jan 2005 12:05:56 -0000
Received: from unknown (HELO tyr) (203.206.252.93)
by mail.iinet.net.au with SMTP; 29 Jan 2005 12:05:56 -0000
From: "Chris Martin" <outsidefactor@iinet.net.au>
To: <freebsd-net@freebsd.org>
Date: Sat, 29 Jan 2005 23:05:22 +1100
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcUF+s7T/AVLBeRSRqWCe+sqQZLNRQ==
Message-Id: <20050129120557.5E9F143D49@mx1.FreeBSD.org>
Subject: Destroying gif interface causes kernel panic
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 12:05:59 -0000
Hs anyone else been affected by this issue in systems other than HEAD:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3186449+0+archive/2004/freebsd-
current/20041003.freebsd-current
In that mail it suggests that the issue has been resolved (and a future mail
in the thread from the original bug reporter confirms this) in HEAD.
I believe a system I maintain is being affected by this. Does anyone know if
the fix that was committed to HEAD has made it to release or STABLE?
Secondly, and slightly off topic, is Fast IPSEC suitable for use on
production systems now?
Chris Martin
From owner-freebsd-net@FreeBSD.ORG Sat Jan 29 16:30:10 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 4460A16A4CE; Sat, 29 Jan 2005 16:30:10 +0000 (GMT)
Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 3FFBE43D1F; Sat, 29 Jan 2005 16:30:09 +0000 (GMT)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68])
by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j0TGTnnL042539
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
Sat, 29 Jan 2005 19:29:50 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
by cell.sick.ru (8.12.11/8.12.8) with ESMTP id j0TGTnaX000129
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 29 Jan 2005 19:29:49 +0300 (MSK)
(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
by cell.sick.ru (8.12.11/8.12.11/Submit) id j0TGTnTs000128;
Sat, 29 Jan 2005 19:29:49 +0300 (MSK)
(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
glebius@freebsd.org using -f
Date: Sat, 29 Jan 2005 19:29:48 +0300
From: Gleb Smirnoff <glebius@freebsd.org>
To: Thomas Vogt <freebsdlists@bsdunix.ch>
Message-ID: <20050129162948.GA99968@cell.sick.ru>
Mail-Followup-To: Gleb Smirnoff <glebius@freebsd.org>,
Thomas Vogt <freebsdlists@bsdunix.ch>,
freebsd-performance@freebsd.org, freebsd-net@freebsd.org
References: <1106932700.48903.58.camel@bert.mlan.solnet.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <1106932700.48903.58.camel@bert.mlan.solnet.ch>
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff
on relay.bestcom.ru
X-Virus-Status: Clean
cc: freebsd-net@freebsd.org
cc: freebsd-performance@freebsd.org
Subject: Re: freebsd router project. Problems with polling?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2005 16:30:10 -0000
Thomas,
can you try if_em driver from HEAD and check whether this help.
There were some work done during 5.3-RELEASE.
On Fri, Jan 28, 2005 at 06:18:19PM +0100, Thomas Vogt wrote:
T> netstat -w 1 (polling disabled)
T> input (Total) output
T> packets errs bytes packets errs bytes colls
T> 300531 0 23441438 300585 0 23444792 0
T> 300939 0 25872898 300895 0 25870184 0
T> 300738 0 23457584 300768 0 23460626 0
T> 300304 10 25826466 300304 0 25826876 0
T> ...
T>
T> Interrupt load is about 70% with net.inet.ip.fastforwarding enabled. If
T> I disable this the system becomes unusable.
T> The system hasn't reach the limit yet. But the interrupt is much to
T> high. It's not worthy to add a second udp sender machine, at the moment.
T>
T>
T> netstat -w 1 (polling enabled)
T> input (Total) output
T> packets errs bytes packets errs bytes colls
T> 150151 47647 12910330 150150 0 12911806 0
T> 150151 0 11711798 150152 0 11711876 0
T> 150151 47665 12910986 150151 0 12911810 0
T> 150151 0 11711798 150151 0 11711798 0
T> ...
T>
T> Interrupt load is about 10%. CPU is about 60% and with
T> kern.polling.idle_poll enabled it goes to 100% (as expected).
T>
T> As you see the speed is droping down to 50% with polling enable and and
T> I got a lot of errors.
T> kern.polling.lost_polls: 188748 and kern.polling.suspect: 186919 are
T> also very high. I don't know why polling is so bad on this machine. All
T> SMP option are disabled in the kernel and bios.
T> I tried to do as much as in
T> http://lists.freebsd.org/pipermail/freebsd-questions/2004-November/064427.html described.
T>
T> I will prepare others tests with -STABLE and -CURRENT in the next few
T> days. At the mean time, are they some other magic things config option I
T> can try? Perhaps increase the HZ to 2000 in the kernel or remove polling
T> and try smp machine? I doubt that I can run the machine without polling.
T> If you see 70% interrupt load with 300k pps without polling.
T>
T> regards
T> Thomas Vogt
T>
T> _______________________________________________
T> freebsd-net@freebsd.org mailing list
T> http://lists.freebsd.org/mailman/listinfo/freebsd-net
T> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE