From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 06:05:22 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A827F16A4D0 for ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Brooks Davis 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 cc: Jeremie Le Hen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Boris Kovalenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; Sun, 23 Jan 2005 22:31:30 +0000 (GMT) From: "Andrew Seguin" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; Sun, 23 Jan 2005 22:42:52 +0000 (GMT) From: "Andrew Seguin" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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' ? - "" : 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' ? "" : 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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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: Type: hole ID: 00000006 Num hooks: 1 Name: 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 hole 00000006 qqq 100 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: 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 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: 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 ; 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 ; 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 ; 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 To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: 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 To: "Pawel Jakub Dawidek" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Boris Kovalenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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' ? > - "" : 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' ? "" : 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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 To: Clark Gaylord 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen Message-ID: <20050125011615.GB47638@dhcp120.icir.org> Mail-Followup-To: Jeremie Le Hen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Mihai Nitulescu Message-ID: <20050125011800.GC47638@dhcp120.icir.org> Mail-Followup-To: Mihai Nitulescu , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" To: Date: Mon, 24 Jan 2005 21:59:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Boris Kovalenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 <20050124232119.66192.qmail@web30406.mail.mud.yahoo.com> Date: Tue, 25 Jan 2005 07:13:36 +0000 From: Anne Marcel Roorda 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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' ? - "" : 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' ? "" : 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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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: Type: hole ID: 00000006 Num hooks: 1 > Name: 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 hole 00000006 qqq > 100 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: 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 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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Andre Oppermann 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 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 X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Andre Oppermann 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Bruce M Simpson 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen Message-ID: <20050125144153.GJ47638@dhcp120.icir.org> Mail-Followup-To: Jeremie Le Hen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen Message-ID: <20050125152209.GK47638@dhcp120.icir.org> Mail-Followup-To: Jeremie Le Hen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Nickolay Kritsky Message-ID: <20050125153547.GF59685@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Jeremie Le Hen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, --- 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: 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 ; 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 ; 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 ; 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 To: Jeremie Le Hen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 UGSc 24 17513460 ep0 /24 link#4 UC 1 0 ep0 127.0.0.1 UGHS 0 70 lo0 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 mtu 1280 tunnel inet --> 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: 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 ; 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 ; 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: Content-Transfer-Encoding: 7bit From: Alex Date: Tue, 25 Jan 2005 17:26:18 +0100 To: Jeremie Le Hen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Nickolay Kritsky Message-ID: <20050125171120.GH59685@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Jeremie Le Hen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen Message-ID: <20050125172049.GL47638@dhcp120.icir.org> Mail-Followup-To: Jeremie Le Hen , Nickolay Kritsky , freebsd-net@freebsd.org References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen , Nickolay Kritsky , freebsd-net@freebsd.org Message-ID: <20050125173842.GI59685@obiwan.tataz.chchile.org> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Mihai Nitulescu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: Jeremie Le Hen Message-ID: <20050126023354.GJ692@empiric.icir.org> Mail-Followup-To: Jeremie Le Hen , Nickolay Kritsky , freebsd-net@freebsd.org References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" To: Jeremie Le Hen , Nickolay Kritsky , freebsd-net@freebsd.org Message-ID: <20050126092335.GA21369@eddie.nitro.dk> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gif(4) and bpf(4) thread-index: AcUC+Ix1m4LWvp26T6OqpMlF++pnrAAADyaA From: "Nickolay Kritsky" To: "Jeremie Le Hen" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 UGSc 24 17513460 ep0 /24 link#4 UC 1 0 ep0 127.0.0.1 UGHS 0 70 lo0 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 mtu 1280 tunnel inet --> 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: 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 ; 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 ; 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 ; 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gif(4) and bpf(4) thread-index: AcUCeUmhcZbjTMQFTFGayyOXNQ1USAAcy+xQ From: "Nickolay Kritsky" To: "Jeremie Le Hen" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using aliased IPs for outbound requests thread-index: AcT83bNpuIBaNqI9Qw6/i4VV2vPH8QAczKYQ From: "Nickolay Kritsky" To: "Mike Wesson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network accounting thread-index: AcT80LFoSUWCz4YPSgGiCtgrIeCPngAgO1eg From: "Nickolay Kritsky" To: "Andrew Seguin" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "freebsd-net@freebsd.org" References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 To: "Thomas M. Skeren III" , Brian Reichert 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; 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 From: Lee Johnston 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; 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" To: "Mihai Nitulescu" , "Thomas M. Skeren III" , "Brian Reichert" 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 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; Wed, 26 Jan 2005 20:57:45 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so163698wri for ; 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 To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 mtu 1500 options=5b inet6 fe80::230:48ff:fe72:f30b%em1 prefixlen 64 scopeid 0x6 ether 00:30:48:72:f3:0b media: Ethernet autoselect (1000baseTX ) status: active vlan120: flags=8843 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 ) 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: 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 ; 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 ; 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 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Michael C. Cambria" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; 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" 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> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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: 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 ; 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 ; 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 ; Thu, 27 Jan 2005 16:00:30 +0100 (CET) (envelope-from josemi@freebsd.jazztel.es) From: Jose M Rodriguez 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Jose M Rodriguez 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: Redes JM To: freebsd-net@freebsd.org, Harti Brandt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 Organization: Redes JM To: freebsd-net@freebsd.org, Harti Brandt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Jose M Rodriguez 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; Fri, 28 Jan 2005 12:16:57 +0000 (GMT) (envelope-from nick-list@netability.ie) X-Envelope-To: 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 ; Fri, 28 Jan 2005 12:16:51 GMT (envelope-from nick-list@netability.ie) From: Nick Hilliard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Nick Hilliard In-Reply-To: <1106914610.32953.12.camel@pancake.netability.ie> Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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: 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 To: Thomas Vogt Message-ID: <20050129162948.GA99968@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Thomas Vogt , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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