From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 09:36:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CD7916A4CE for ; Sun, 26 Sep 2004 09:36:47 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id E55A843D1D for ; Sun, 26 Sep 2004 09:36:46 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 493CF346F1 for ; Sun, 26 Sep 2004 03:36:40 -0600 (MDT) Received: by faith.cs.utah.edu (Postfix, from userid 4969) id 44B2F2EC21; Sun, 26 Sep 2004 03:36:38 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id BD51534406 for ; Sun, 26 Sep 2004 09:36:38 +0000 (UTC) Date: Sun, 26 Sep 2004 03:36:38 -0600 (MDT) From: Vaibhave Agarwal To: freebsd-net@FreeBSD.ORG In-Reply-To: <200205080916.g489GDec019355@cairo.anu.edu.au> Message-ID: References: <200205080916.g489GDec019355@cairo.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: configure Intel 82559 Ethernet card for "Early Interrupts" 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, 26 Sep 2004 09:36:47 -0000 hi all I am trying to configure Intel 82559 10/100 Mbps Ethernet card to generate "Early Interrupts", so that I can receive interrupts from the driver, long before the whole packet is transferred to the host memory. I have set the Early Receive Interrupt field in the CSR register of the card. But still I am not getting these interrupts. The reason I found out was that the card generates interrupt if the ethernet header's type/length field is set to 0-1500 value i.e. set to length of the packet. But if it is set to Type field ( 0x800 for ip packet) then according to the Intel's manual , the interrupt is generated only if "the device is configured to generate early interrupts on IP frames" Do anybody know how can I configure the device to generate early interrupts for IP frames OR any other way to get around with this problem?? thanks vaibhave From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 19:50:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C17216A4D0 for ; Sun, 26 Sep 2004 19:50:10 +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 D57CC43D1D for ; Sun, 26 Sep 2004 19:50:09 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F3F9715263; Mon, 27 Sep 2004 04:50:06 +0900 (JST) Date: Mon, 27 Sep 2004 04:50:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: 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 cc: snap-users@kame.net Subject: Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 26 Sep 2004 19:50:10 -0000 >>>>> On Sat, 25 Sep 2004 14:34:39 +0300 (EEST), >>>>> Pekka Savola said: >> >> 1. do you see massive number of entries with "netstat -rna"? >> >> > Yes. >> >> > # netstat -nra | wc -l >> > 32468 >> > # >> >> Okay, to be sure, most of them are IPv6 routing entries, right? > Yes, 99.99%. I can think of several possibilities that may cause the entries: - when this node sends ICMPv6 error messages to those addresses, it can create route entries. I suspect this is the main reason since in this case the destination of route entries would contain other types of addresses than 6to4. You can (implicitly) check if this happened by looking at the result of 'netstat -s -p icmp6' - if this node can be the originator (i.e., not a forwarder as a router) to those destinations, it can create host routes for the destinations. - if you use some network-level hooks (e.g., packet filters) that rely on routing table lookups, the node may have the host routes. Can one of those be the case in your environment? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 04:57:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA20416A4CE for ; Mon, 27 Sep 2004 04:57:19 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B49D843D2D for ; Mon, 27 Sep 2004 04:57:18 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8R4v3T28107; Mon, 27 Sep 2004 07:57:03 +0300 Date: Mon, 27 Sep 2004 07:57:02 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org cc: snap-users@kame.net Subject: Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 27 Sep 2004 04:57:19 -0000 On Mon, 27 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > I can think of several possibilities that may cause the entries: > > - when this node sends ICMPv6 error messages to those addresses, it > can create route entries. I suspect this is the main reason since > in this case the destination of route entries would contain other > types of addresses than 6to4. You can (implicitly) check if this > happened by looking at the result of 'netstat -s -p icmp6' This is likely the case. Due to Microsoft's implementation of '6to4 relay probing', each host tries to send an IPv6 packet of Hop Count=1, which results in an ICMP unreachable back from the relays. See below. # netstat -s -p icmp6 icmp6: 2633683 calls to icmp_error 4 errors not generated because old message was icmp error or so 0 errors not generated because rate limitation Output histogram: unreach: 2465 packet too big: 416 time exceed: 2630798 echo reply: 824 multicast listener report: 6053 neighbor solicitation: 7587 neighbor advertisement: 4587 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 6 echo: 824 multicast listener query: 2014 neighbor solicitation: 4587 neighbor advertisement: 7575 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 4 address unreachable 2461 port unreachable 416 packet too big 2630802 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 3308 redirect 0 unknown 824 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes I'd estimate the router sends out about 1 million such ICMP time exceeded messages per day. > - if this node can be the originator (i.e., not a forwarder as a > router) to those destinations, it can create host routes for the > destinations. Yes, above. > - if you use some network-level hooks (e.g., packet filters) that rely > on routing table lookups, the node may have the host routes. I don't have these. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 06:50:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10A5216A4CF for ; Mon, 27 Sep 2004 06:50:09 +0000 (GMT) Received: from variant6.bg (cable-provisioning.variant6.bg [213.91.180.2]) by mx1.FreeBSD.org (Postfix) with SMTP id C89F543D1D for ; Mon, 27 Sep 2004 06:50:07 +0000 (GMT) (envelope-from kalin@variant6.bg) Received: (qmail 62250 invoked by uid 0); 27 Sep 2004 06:50:22 -0000 Received: from kalin@variant6.bg by variant6.bg by uid 83 with qmail-scanner-1.16 (f-prot: 3.12. Clear:. Processed in 0.26183 secs); 27 Sep 2004 06:50:22 -0000 Received: from noc.variant6.bg (213.91.180.26) by pns.variant6.bg with SMTP; 27 Sep 2004 06:50:22 -0000 Date: Mon, 27 Sep 2004 10:05:17 +0300 (EEST) From: Kalin Hristov X-X-Sender: kalin@Stealth To: freebsd-net@freebsd.org Message-ID: <20040927100319.K30470@Stealth> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FreBSD & MPLS stack 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, 27 Sep 2004 06:50:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'd like to ask is there any plans to implement MPLS control and forwarding plane into FreeBSD? This is extremely valuable feature :-) -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBQVe7sWcb2v9P9sWHEQL1OwCghfJuTzX/sWEwSSRVY9LCmoTULksAn39U WoZY+suX2ftM1fY3P4DDv5Gd =YnNx -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 10:07:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABC5D16A4CE for ; Mon, 27 Sep 2004 10:07:58 +0000 (GMT) Received: from pathfinder.roks.biz (roks.biz [82.207.80.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C32B43D1D for ; Mon, 27 Sep 2004 10:07:57 +0000 (GMT) (envelope-from padla@roks.biz) Received: from admin.office.roks.biz (admin.office.roks.biz [192.168.100.103]) by pathfinder.roks.biz (8.12.11/8.12.11) with ESMTP id i8RA7sAS081408; Mon, 27 Sep 2004 13:07:54 +0300 (EEST) (envelope-from padla@pathfinder.roks.biz) Received: from admin.office.roks.biz (localhost.roks.biz [127.0.0.1]) i8RA7tKp001021; Mon, 27 Sep 2004 13:07:55 +0300 (EEST) (envelope-from padla@admin.office.roks.biz) Received: (from padla@localhost) by admin.office.roks.biz (8.12.11/8.12.11/Submit) id i8RA7m9u001020; Mon, 27 Sep 2004 13:07:48 +0300 (EEST) (envelope-from padla) Date: Mon, 27 Sep 2004 13:07:48 +0300 From: Nikolay Pavlov To: Muhammad Reza Message-ID: <20040927100748.GA491@roks.biz> Mail-Followup-To: Nikolay Pavlov , Muhammad Reza , freebsd-net@freebsd.org References: <4148C2D0.6060907@mra.co.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4148C2D0.6060907@mra.co.id> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: DVB card 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, 27 Sep 2004 10:07:58 -0000 Hi, Muhammad. On Thursday, 16 September 2004 at 5:31:44 +0700, Muhammad Reza wrote: > Dear List, > > Is there any DVB card (C band) that FreeBSD kernel support ? > please recommend us There is a driver for skystar-I dvb card that you can find in this pages: 1) For FreeBSD STABLE (quite old, but works on my 4.10-p2 with some configuration shades) http://www.gs.ru/soft/ss1bsd/skystar1-20021126b.tgz 2) For FreeBSD CURRENT (Not tested for me, even by the author ;)) http://www.gs.ru/soft/ss1bsd/skystar1-fbsd50-20040312.tar.bz2 Both are very bugy, but you can ask me how to force one of them (for freebsd stable) to work well. Best regards, Nikolay Pavlov. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 10:36:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3B1C16A4CE; Mon, 27 Sep 2004 10:36:52 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE7843D2F; Mon, 27 Sep 2004 10:36:51 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.1/8.13.1) with SMTP id i8RAaQuJ015277; Mon, 27 Sep 2004 11:36:26 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 27 Sep 2004 11:36:24 +0100 From: Brian Somers To: freebsd-net@FreeBSD.org Message-ID: <20040927113624.4a342952@dev.lan.Awfulhak.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 gw.lan.Awfulhak.org cc: Andre Opperman Subject: ICMP_UNREACH_NEEDFRAG broken in -current 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, 27 Sep 2004 10:36:52 -0000 It seems that the code to handle ICMP_UNREACH_NEEDFRAG is broken in -current, although it doesn't seem broken in RELENG_5 - which is odd as the code in ip_icmp.c looks the same :( I have a fairly standard scenario: - 172.16.10.201/24 -| [route add 172.16.0.0/24 172.16.10.212] | | |--- 172.16.10.212/24 - | 194.242.157.46/28 ---| - | | - 80.177.173.150/32 ---| |--- 172.16.0.1/24 - | 172.16.0.5/24 -| [route add default 172.16.0.1] - The outside network segment is an IPSEC configuration with gif interfaces on the endpoints, and an MTU of 1280. Internal network MTUs are 1500. 172.16.0.5 is running -current, everything else is running RELENG_5. When I send tcp traffic from 172.16.0.5 -> 172.16.10.201 the link dies. 172.16.0.5 sees the ICMP-must-fragment messages coming back from 172.16.0.1, but continues to use the default route with an MTU of 1500. On 172.16.0.5, ``route add 172.16.10.0/24 172.16.0.1 -mtu 1280'' fixes the problem (traffic flows ok *both* ways), although 172.16.10.201 still looks broken (route get -n 172.16.0.5 says the mtu is 1500!!). The problem seems to be in netinet/ip_icmp.c where ntohs(icp->icmp_nextmtu) has a value of zero: mtu = ntohs(icp->icmp_nextmtu); if (!mtu) mtu = ip_next_mtu(mtu, 1); which returns another zero and nothing interesting happens (cvs blame says Andre (cc'd) last touched these lines, but I don't think the problem came from that change!). So what's it supposed to do? I would suspect it should be getting a route to icmpsrc, cloning it if it's not a host route, then setting the route mtu to ip_next_mtu(rt->rt_rmx.rmx_mtu, 1). Comments/suggestions/flames? -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:00:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F17716A4CE for ; Mon, 27 Sep 2004 11:00:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48A143D2D for ; Mon, 27 Sep 2004 11:00: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 207751FFDD7; Mon, 27 Sep 2004 13:00:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 0D5CC1FF9A8; Mon, 27 Sep 2004 13:00:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 3740615674; Mon, 27 Sep 2004 10:59:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2C478154FC; Mon, 27 Sep 2004 10:59:54 +0000 (UTC) Date: Mon, 27 Sep 2004 10:59:54 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Brian Somers In-Reply-To: <20040927113624.4a342952@dev.lan.Awfulhak.org> Message-ID: References: <20040927113624.4a342952@dev.lan.Awfulhak.org> 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: ICMP_UNREACH_NEEDFRAG broken in -current 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, 27 Sep 2004 11:00:10 -0000 On Mon, 27 Sep 2004, Brian Somers wrote: > The outside network segment is an IPSEC configuration with gif interfaces ... > Comments/suggestions/flames? most likely unrelated but I need input on this so ... why do you need gif(4) ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:02:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 775E316A4D8 for ; Mon, 27 Sep 2004 11:02:00 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B94F43D5E for ; Mon, 27 Sep 2004 11:02:00 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i8RB20qV014654 for ; Mon, 27 Sep 2004 11:02:00 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i8RB1xsV014646 for freebsd-net@freebsd.org; Mon, 27 Sep 2004 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Sep 2004 11:01:59 GMT Message-Id: <200409271101.i8RB1xsV014646@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, 27 Sep 2004 11:02:00 -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 o [2002/10/21] kern/44355 net After deletion of an IPv6 alias, the rout o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:23:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B37D816A4CE for ; Mon, 27 Sep 2004 11:23:27 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id D51CE43D60 for ; Mon, 27 Sep 2004 11:23:26 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.1/8.13.1) with SMTP id i8RBN03E015748; Mon, 27 Sep 2004 12:23:00 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 27 Sep 2004 12:22:55 +0100 From: Brian Somers To: "Bjoern A. Zeeb" Message-ID: <20040927122255.71d60282@dev.lan.Awfulhak.org> In-Reply-To: References: <20040927113624.4a342952@dev.lan.Awfulhak.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: ICMP_UNREACH_NEEDFRAG broken in -current 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, 27 Sep 2004 11:23:27 -0000 On Mon, 27 Sep 2004 10:59:54 +0000 (UTC), "Bjoern A. Zeeb" wrote: > On Mon, 27 Sep 2004, Brian Somers wrote: > > > The outside network segment is an IPSEC configuration with gif interfaces > ... > > Comments/suggestions/flames? > > most likely unrelated but I need input on this so ... > why do you need gif(4) ? With an ipsec-only solution, talking from a gateway box to an internal host on the ``other'' network doesn't work nicely.... especially if the internal host on the other network doesn't have a route for it. In my scenario, some 172.16.10.0/24 machines don't have a default route and therefore can't reach 80.177.173.150. Using gif results in traffic from the gatway box using the gateway boxes internal IP number as the source rather than it's external IP number. This allows a simple security policy: 172.16.10.212 $ cat /etc/ipsec.conf spdadd 80.177.173.150/32 194.242.157.46/32 ip4 -P in ipsec esp/transport//require; spdadd 194.242.157.46/32 80.177.173.150/32 ip4 -P out ipsec esp/transport//require; 172.16.0.1 $ ifconfig -a re0: flags=8843 mtu 1500 options=1b inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 ether 00:40:f4:b1:1c:85 media: Ethernet autoselect (1000baseTX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 80.177.173.150 --> 194.242.157.46 inet 172.16.0.1 --> 172.16.10.212 netmask 0xffffffff tun0: flags=8051 mtu 1500 inet 80.177.173.150 --> 217.47.133.74 netmask 0xffffffff Opened by PID 876 172.16.10.212 $ ifconfig -a bge0: flags=8843 mtu 1500 options=1a inet 194.242.157.46 netmask 0xfffffff8 broadcast 194.242.157.47 ether 00:03:ba:2d:d9:f0 media: Ethernet autoselect (1000baseSX ) status: active bge2: flags=8843 mtu 1500 options=1a inet 172.16.10.212 netmask 0xffffff00 broadcast 172.16.10.255 ether 00:03:ba:2d:d9:f1 media: Ethernet autoselect (1000baseSX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 194.242.157.46 --> 80.177.173.150 inet 172.16.10.212 --> 172.16.0.1 netmask 0xffffffff -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:40:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCC916A4CE for ; Mon, 27 Sep 2004 11:40:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAE0D43D31 for ; Mon, 27 Sep 2004 11:40:08 +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 B7DAD1FFDD7; Mon, 27 Sep 2004 13:40:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id A0F491FF9A8; Mon, 27 Sep 2004 13:40:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 434F315674; Mon, 27 Sep 2004 11:39:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 387CE154FC; Mon, 27 Sep 2004 11:39:40 +0000 (UTC) Date: Mon, 27 Sep 2004 11:39:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Brian Somers In-Reply-To: <20040927122255.71d60282@dev.lan.Awfulhak.org> Message-ID: References: <20040927113624.4a342952@dev.lan.Awfulhak.org> <20040927122255.71d60282@dev.lan.Awfulhak.org> 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: gif(4) & ipsec [was: ICMP_UNREACH_NEEDFRAG broken in -current] 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, 27 Sep 2004 11:40:09 -0000 On Mon, 27 Sep 2004, Brian Somers wrote: > On Mon, 27 Sep 2004 10:59:54 +0000 (UTC), "Bjoern A. Zeeb" wrote: > > On Mon, 27 Sep 2004, Brian Somers wrote: > > > > > The outside network segment is an IPSEC configuration with gif interfaces > > ... > > > Comments/suggestions/flames? > > > > most likely unrelated but I need input on this so ... > > why do you need gif(4) ? > > With an ipsec-only solution, talking from a gateway box to an internal > host on the ``other'' network doesn't work nicely.... ok. > especially if the internal host on the other network doesn't have a > route for it. considering the usage of a vpn-gw/router most services needed like ssh, ping and possibly telnet can be given a source address on command line to use the internal IP. anyway it's complicating things, you are right. thanks for the detailed explanation. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 13:26:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECEF316A4CE for ; Mon, 27 Sep 2004 13:26:28 +0000 (GMT) Received: from asum.kodu.ee (asum.kodu.ee [212.27.241.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A775E43D3F for ; Mon, 27 Sep 2004 13:26:27 +0000 (GMT) (envelope-from juhani@kernel.ee) Received: from [192.168.1.9] (panic.kernel.ee [212.27.241.3]) by asum.kodu.ee (8.12.9p2/8.12.8) with ESMTP id i8RDQONC000594 for ; Mon, 27 Sep 2004 16:26:24 +0300 (EEST) (envelope-from juhani@kernel.ee) Message-ID: <415814FD.8010109@kernel.ee> Date: Mon, 27 Sep 2004 16:26:21 +0300 From: Juhani Tali User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040824) 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 X-Virus-Scanned: by amavisd-new Subject: Nat problem, nat and proxy_address at the same time. 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, 27 Sep 2004 13:26:29 -0000 Hi I am trying to use in Linux terminology "SNAT" and "DNAT" at the same time. The result should be: client 192.168.1.9 sees instead of remote web server 96.98 a remote (routed) web server 240.17 natd -port 8675 -alias_address 212.27.241.3 -proxy_rule port 80 server 212.27.240.17:80 ipfw add 125 divert 8675 ip from 192.168.1.9 to 194.106.96.98 ipfw add 126 divert 8675 ip from 212.27.240.17 to any In the gw, tcpdump shows me on the external interface traffic both ways, to and from 240.17 (the "new" web server) on the internal interface traffic only outgoing traffic towards 96.98 ipfw show 00125 102 5064 divert 8675 ip from 192.168.1.9 to 194.106.96.98 00126 36 2096 divert 8675 ip from 212.27.240.17 to any So it seems that these (testing only) rules do get traffic and the problem is in nat. What might be the problem? Juhani From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 14:22:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C848316A4CF for ; Mon, 27 Sep 2004 14:22:02 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 54E8F43D2F for ; Mon, 27 Sep 2004 14:22:02 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.221.121 with login) by smtp003.bizmail.yahoo.com with SMTP; 27 Sep 2004 14:22:02 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 1E7546230; Mon, 27 Sep 2004 09:22:01 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41092-01-2; Mon, 27 Sep 2004 09:21:59 -0500 (CDT) Received: from www.noacks.org (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 86733622C; Mon, 27 Sep 2004 09:21:59 -0500 (CDT) Received: from 69.53.57.66 (SquirrelMail authenticated user noackjr); by www.noacks.org with HTTP; Mon, 27 Sep 2004 09:21:59 -0500 (CDT) Message-ID: <55800.69.53.57.66.1096294919.squirrel@69.53.57.66> In-Reply-To: <20040927141224.R55054@p-i-n.com> References: <414ADD15.FAC42CDB@freebsd.org> <20040917231922.G55054@p-i-n.com> <414B567C.9060904@freebsd.org> <414B5777.1030901@freebsd.org> <20040918000303.J55054@p-i-n.com> <414B6F11.5070902@freebsd.org> <20040918013929.O55054@p-i-n.com> <414B8C1B.2E7C971C@freebsd.org> <20040918155408.P55054@p-i-n.com> <414CB896.8070408@alumni.rice.edu> <20040927141224.R55054@p-i-n.com> Date: Mon, 27 Sep 2004 09:21:59 -0500 (CDT) From: "Jon Noack" To: "Raphael H. Becker" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at noacks.org cc: rwatson@freebsd.org cc: net@freebsd.org Subject: Re: Strange things on GBit / 1000->100 / net.inet.tcp.sack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 14:22:03 -0000 Raphael H. Becker wrote: > Hi Jon, > > On Sat, Sep 18, 2004 at 05:37:10PM -0500, Jon Noack wrote: >> Have you tried disabling SACK (net.inet.tcp.sack.enable) on the 5.3 >> machine? > > Tried that now. > > case 1000->100: > > sack.enable:1 300kbytes/sec > sack.enable:0 1.4MBytes/sec (should be around 10MBytes/sec) > > say: slightly better performance without sack. Interesting. While I don't think that sack is to blame here, it appears to aggravate the situation. Your network setup is not going to significantly benefit from sack, so you could leave it off to help... > case 1000->1000: > > sack.enable:1 76.82 MBytes/sec > sack.enable:0 76.80 MBytes/sec > > say: exactly no difference. > > The FTP-server is a 5.3-BETA4, the client(100) still a 4.10-p2 and > client(1000) a 5.3-BETA5. > > Any idea? > > I still guess the rubbish switch has a problem with its store&forward > engine and cannot buffer much data, maybe broken by design. I think others may have asked this, but have you tried using a different switch? Also, what happens if you force the card to 100Mbit? Do you still get poor performance? > On the other hand, freebsd 5.3 seems not to recognize this and I don't > know where in the network stack the traffic is limited to effectivly > 100MBit/sec, when sending to a 100MBit-node. With 4.10 as GBit-sender > the transfer to a 100MBit-Node works perfectly (10.5 MBytes/sec ftp). Yeah, ideally we would gracefully handle finicky hardware. > The differences on sender's side are: > > a) 5.3-BETA (poor) 4.10-p2 (perfect) > b) (poor) vs > (perfect) > > HTH > Raphael Becker > > Maybe you have an idea about the switch-specs: > http://www.netgearinc.co.jp/support/pdf/gs516t_manual.pdf page 22 of 34 Sorry, I'm not knowledgeable enough to comment intelligently on switch specs. Jon From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 15:23:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8078E16A4CE for ; Mon, 27 Sep 2004 15:23:30 +0000 (GMT) Received: from musashi.fi.uba.ar (musashi.fi.uba.ar [157.92.49.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB5B43D55 for ; Mon, 27 Sep 2004 15:23:24 +0000 (GMT) (envelope-from gkullak@fi.uba.ar) Received: from musashi.fi.uba.ar (localhost.localdomain [127.0.0.1]) by musashi.fi.uba.ar (8.12.10/8.12.10) with ESMTP id i8RFMYHZ030762 for ; Mon, 27 Sep 2004 12:22:34 -0300 Received: (from apache@localhost) by musashi.fi.uba.ar (8.12.10/8.12.10/Submit) id i8RFMYpU030760; Mon, 27 Sep 2004 12:22:34 -0300 Received: from 161.190.1.253 (SquirrelMail authenticated user gkullak); by webmail.fi.uba.ar with HTTP; Mon, 27 Sep 2004 12:22:34 -0300 (ART) Message-ID: <32934.161.190.1.253.1096298554.squirrel@161.190.1.253> Date: Mon, 27 Sep 2004 12:22:34 -0300 (ART) From: gkullak@fi.uba.ar To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-FIUBA-MailScanner-Information: Please contact the ISP for more information X-FIUBA-MailScanner: Found to be clean X-FIUBA-MailScanner-SpamCheck: no es spam (whitelisted), SpamAssassin (puntaje=-3.205, requerido 5, AWL -0.29, BAYES_00 -4.90, J_CHICKENPOX_53 0.60, J_CHICKENPOX_66 0.60, NO_REAL_NAME 0.16, RATWR20_MESSID 0.62) X-MailScanner-From: gkullak@fi.uba.ar Subject: ipnat of ipfilter crash with too many mapping? 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, 27 Sep 2004 15:23:30 -0000 Hi! I'm running FreeBSD 4.10 with ProFTP,Apache, Tomcat, Samba, Squid,SSH Server, MySQL and PostgreSQL. This machine is direct connected to Internet and is a firewall for an internet LAN. For firewall I am using ipfilter (ipf and ipnat). |-> 172.16.0.2 Internet ---> (200.0.0.1)FreeBSD Box (172.16.0.254) | fxp0 fxp1 |-> 172.16.0.3 Te problem is that when I run Overnet from 172.16.0.2, the NAT die. What it mean: FreeBSD run transparent proxy to Squid in port 8080. ipnat redirect all request to outside 80 to 8080. This work fine but when I start Overnet the nat table begin to grow up to 600 mapping!!! The bandwith of my Internet connection is of 512Kbps. If I view the system status (top), the system was normal = 98% iddle. I am really thinking that ipnat daemon work not to fine for this type of connection, because in my work I have the same schema with more machines in the LAN but for firewalling I am using "iptables" in Red Hat Linux 7.3 box with 2 overnet programs runnig in diferents machines and the connection never die. I refer in all case to "connection", but I don't know if the die is the connection, the system, the ipnat program or other thing. I try ipnat compiled in the kernel and i try ipnat loaded like module in rc.conf (actual form). The really thing is that when I stop the overnet and run "ipnat -CF - /etc/ipnat.rules" for flush and reload the NAT rules, the connection run fast again. Example: If it running Overnet in 172.16.0.2 and I want to start RealPlayer for listen a radio channel in 172.16.0.3 and got an error (can not connect). In this same case, I try to navegate to www.yahoo.com, but a got "Page not found" (remmeber transparent proxy use ipnat to resolve). But in this situation, I set to use the proxy server in Internet Options of my browser, the Yahoo page load (slow but load). I know that Overnet use very much bandwith of Internet connection, but I am thinking that ipnat not work very well with this type of load. For probe I will go to try putting a Red Hat Linux box to manage the NAT and look if work better. Do you have another idea that I can try to resolve the problem? Thanks! Regards. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 18:27:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 070A016A4CE; Mon, 27 Sep 2004 18:27:25 +0000 (GMT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBF6343D31; Mon, 27 Sep 2004 18:27:24 +0000 (GMT) (envelope-from beyssac@bofh.enst.fr) Received: from bofh.enst.fr (bofh.enst.fr [137.194.32.191]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "bofh.enst.fr", Issuer "ENST CA" (not verified)) by smtp2.enst.fr (Postfix) with ESMTP id 4E39253B26; Mon, 27 Sep 2004 20:27:23 +0200 (CEST) Received: from bofh.enst.fr (localhost [127.0.0.1]) by bofh.enst.fr (8.13.1/8.13.1) with ESMTP id i8RIRMSw002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Sep 2004 20:27:22 +0200 (CEST) (envelope-from beyssac@bofh.enst.fr) Received: (from beyssac@localhost) by bofh.enst.fr (8.13.1/8.13.1/Submit) id i8RIRM1J002465; Mon, 27 Sep 2004 20:27:22 +0200 (CEST) (envelope-from beyssac) Date: Mon, 27 Sep 2004 20:27:22 +0200 From: Pierre Beyssac To: freebsd-net@freebsd.org Message-ID: <20040927182722.GA1664@bofh.enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: tackerman@freebsd.org cc: mlaier@freebsd.org Subject: reproductible hang with if_em 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, 27 Sep 2004 18:27:25 -0000 Hello, I'm having a problem (under 5.3-BETA, but I don't think it matters much) with the if_em driver on bursty outbound traffic: the card is stuck in a state where it only returns ENOBUFS. No buffers ever become available again, but ifconfig down+up fixes the problem. >From a quick analysis it looks like the TX descriptor cleanup routine em_clean_transmit_interrupts() as called by em_encap() in such cases doesn't manage to find anything free with E1000_TXD_STAT_DD set. The card seems stuck in this state. A simple albeit dirty fix would be to cancel some or all untransmitted packets in such cases. Perhaps this is related to my using the card on a 100Mbps switch. I have a small program to exercise the hang in case someone would like to have a look at it. See below for the result of "sysctl hw.em0.debug_info=1" (notice the not avail1 = 12 and not avail2 = 0 hinting at em_clean_transmit_interrupts). em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:0d:56:d0:5c:15 em0: Speed:N/A Duplex:N/A em0: Link is up 100 Mbps Full Duplex em0: Adapter hardware address = 0xc3570b34 em0:tx_int_delay = 66, tx_abs_int_delay = 66 em0:rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset = 0 em0: hw tdh = 238, hw tdt = 238 em0: Num Tx descriptors avail = 256 em0: Tx Descriptors not avail1 = 12 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 -- Pierre Beyssac pb@enst.fr From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 18:30:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A05516A4CE for ; Mon, 27 Sep 2004 18:30:09 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5E6443D39 for ; Mon, 27 Sep 2004 18:30:08 +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 01F607A440; Mon, 27 Sep 2004 11:30:08 -0700 (PDT) Message-ID: <41585C2F.9020500@elischer.org> Date: Mon, 27 Sep 2004 11:30:07 -0700 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: Kalin Hristov References: <20040927100319.K30470@Stealth> In-Reply-To: <20040927100319.K30470@Stealth> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FreBSD & MPLS stack 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, 27 Sep 2004 18:30:09 -0000 Kalin Hristov wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hello, > >I'd like to ask is there any plans to implement MPLS control and >forwarding plane into FreeBSD? This is extremely valuable feature :-) > I don't think there are plans yet, but if you and a few like minded peopel want to implement it, we would certainly welcome your contributions. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 20:28:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E323916A4D0 for ; Mon, 27 Sep 2004 20:28:01 +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 263C943D31 for ; Mon, 27 Sep 2004 20:28:01 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 943ED1525D; Tue, 28 Sep 2004 05:27:58 +0900 (JST) Date: Tue, 28 Sep 2004 05:27:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: 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: (KAME-snap 8803) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 27 Sep 2004 20:28:02 -0000 >>>>> On Mon, 27 Sep 2004 07:57:02 +0300 (EEST), >>>>> Pekka Savola said: >> I can think of several possibilities that may cause the entries: >> >> - when this node sends ICMPv6 error messages to those addresses, it >> can create route entries. I suspect this is the main reason since >> in this case the destination of route entries would contain other >> types of addresses than 6to4. You can (implicitly) check if this >> happened by looking at the result of 'netstat -s -p icmp6' > This is likely the case. Due to Microsoft's implementation of '6to4 > relay probing', each host tries to send an IPv6 packet of Hop Count=1, > which results in an ICMP unreachable back from the relays. See below. Okay. Now I think I figure out the problem. Those host routes were created not deliberately, so the kernel will eventually need a fix to this. But if you are in a hurry and/or cannot replace the kernel soon, I think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with this you even do not have to reboot the kernel - though rebooting may also help if you can). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 01:39:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A0116A4CE; Tue, 28 Sep 2004 01:39:40 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C2843D2F; Tue, 28 Sep 2004 01:39:38 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8S1dJr4029817; Mon, 27 Sep 2004 18:39:20 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i8S1dDqF074028; Mon, 27 Sep 2004 18:39:17 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 28 Sep 2004 10:39:09 +0900 Message-ID: From: "George V. Neville-Neil" To: snap-users@kame.net User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: rwatson@freebsd.org Subject: Patch for fragment problem in key.c 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, 28 Sep 2004 01:39:41 -0000 Hi Folks, Robert Watson tried to send email about this but it never got through, and then Sam Leffler got ahold of me and told me he fixed something similar in the FAST_IPSEC code. So, the following patch fixes, in KAME IPSec. This patch was generated against 6.0-CURRENT and I included Sam's commit message. Later, George Correct handling of SADB_UPDATE and SADB_ADD requests. key_align may split the mbuf due to use of m_pulldown. Discarding the result because of this does not make sense as no subsequent code depends on the entire msg being linearized (only the individual pieces). It's likely something else is wrong here but for now this appears to get things back to a working state. Index: sys/netkey/key.c =================================================================== RCS file: /Volumes/exported/FreeBSD-CVS/src/sys/netkey/key.c,v retrieving revision 1.67 diff -u -r1.67 key.c --- sys/netkey/key.c 2 Sep 2004 20:14:03 -0000 1.67 +++ sys/netkey/key.c 27 Sep 2004 16:08:31 -0000 @@ -6952,11 +6952,6 @@ if (error) return error; - if (m->m_next) { /*XXX*/ - m_freem(m); - return ENOBUFS; - } - msg = mh.msg; /* check SA type */ From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 03:41:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A807916A4CE for ; Tue, 28 Sep 2004 03:41:44 +0000 (GMT) Received: from agok.alrosa-mir.ru (agok.alrosa-mir.ru [194.84.226.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1206143D2F for ; Tue, 28 Sep 2004 03:41:40 +0000 (GMT) (envelope-from r.stadnik@agok.alrosa-mir.ru) Received: from stadnik.fabrika-14.agok.alrosa-mir.ru (f14.agok.alrosa-mir.ru [192.168.120.4] (may be forged)) by agok.alrosa-mir.ru (8.13.1/8.13.1) with ESMTP id i8S3sHpV010062 for ; Tue, 28 Sep 2004 13:54:22 +1000 Date: Tue, 28 Sep 2004 13:44:06 +1000 From: Roman Stadnik Organization: Home X-Priority: 3 (Normal) Message-ID: <128093050.20040928134406@agok.alrosa-mir.ru> To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on agok.alrosa-mir.ru X-Virus-Status: Clean Subject: q? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Roman Stadik List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 03:41:44 -0000 From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 09:07:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FF7A16A4CE; Tue, 28 Sep 2004 09:07:55 +0000 (GMT) Received: from coconut.itojun.org (coconut.itojun.org [221.249.121.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40C9743D2D; Tue, 28 Sep 2004 09:07:55 +0000 (GMT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ED7E91C060; Tue, 28 Sep 2004 18:07:52 +0900 (JST) To: snap-users@kame.net In-reply-to: gnn's message of Tue, 28 Sep 2004 10:39:09 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Tue, 28 Sep 2004 18:07:52 +0900 Sender: itojun@itojun.org Message-Id: <20040928090752.ED7E91C060@coconut.itojun.org> cc: freebsd-net@freebsd.org cc: rwatson@freebsd.org Subject: Re: (KAME-snap 8809) Patch for fragment problem in key.c 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, 28 Sep 2004 09:07:55 -0000 >Hi Folks, > > Robert Watson tried to send email about this but it never got > through, and then Sam Leffler got ahold of me and told me he > fixed something similar in the FAST_IPSEC code. So, the > following patch fixes, in KAME IPSec. This patch was > generated against 6.0-CURRENT and I included Sam's commit > message. > >Later, >George the fix is already in kame repository. tnx. itojun From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 09:59:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52D9F16A4CE for ; Tue, 28 Sep 2004 09:59:54 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4308143D46 for ; Tue, 28 Sep 2004 09:59:53 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8S9ufxJ033338 for freebsd-net@freebsd.org.checked; (8.12.8/vak/2.1) Tue, 28 Sep 2004 13:56:41 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8S9swi5033219; (8.12.8/vak/2.1) Tue, 28 Sep 2004 13:54:58 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4159358F.1060200@cronyx.ru> Date: Tue, 28 Sep 2004 13:57:35 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20040927100319.K30470@Stealth> <41585C2F.9020500@elischer.org> In-Reply-To: <41585C2F.9020500@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Kalin Hristov Subject: Re: FreBSD & MPLS stack 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, 28 Sep 2004 09:59:54 -0000 Julian Elischer wrote: > Kalin Hristov wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> >> I'd like to ask is there any plans to implement MPLS control and >> forwarding plane into FreeBSD? This is extremely valuable feature :-) > > I don't think there are plans yet, but if you and a few like minded > peopel want to implement it, > we would certainly welcome your contributions. If I didn't catch any bugs like last one that was fixed by me (which took almos a month of my work and private time). A may start some work in that direction. ;-) But at first I need back to the work and make my drivers MPSAFE. rik > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:08:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B704A16A4CE; Tue, 28 Sep 2004 10:08:47 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C3C43D45; Tue, 28 Sep 2004 10:08:41 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from mail-vc.jaist.ac.jp (mail-vc.jaist.ac.jp [150.65.5.31]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i8SA8bN03722; Tue, 28 Sep 2004 19:08:37 +0900 (JST) Received: from mail-vc.jaist.ac.jp (localhost [127.0.0.1]) by localhost.jaist.ac.jp (Postfix) with ESMTP id F3878848C; Tue, 28 Sep 2004 19:08:36 +0900 (JST) Received: from smtp.jaist.ac.jp (smtp.jaist.ac.jp [150.65.38.97]) by mail-vc.jaist.ac.jp (Postfix) with ESMTP id D2E6F8489; Tue, 28 Sep 2004 19:08:36 +0900 (JST) Received: from jaist.ac.jp (is32e1b21.jaist.ac.jp [150.65.118.21]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i8SA70h02621; Tue, 28 Sep 2004 19:07:00 +0900 (JST) Message-ID: <41593824.9030006@jaist.ac.jp> Date: Tue, 28 Sep 2004 19:08:36 +0900 From: Zrelli Saber Ben Mohamed User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020921 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, hackers@freebsd.org, net@freebsd.org Content-Type: multipart/mixed; boundary="------------080104040208090602080700" Subject: divert , ipfw 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: Tue, 28 Sep 2004 10:08:47 -0000 This is a multi-part message in MIME format. --------------080104040208090602080700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi , I'm interesed in the "divert" mechanism and want to try it out , so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the IPDIVERT option and then added the needed lines in the rc.conf file, after that , I set up ipfw to divert packets to some port here is my ipfw rule set . 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65100 divert 5000 ip from any 22 to me <---- the divert rule 65535 deny ip from any to any then, I wanted to monitor the diverted traffic using tcpdump : $ tcpdump port 5000 when I do a telnet connection to the port 22 from a remote host , I was expecting that tcpdump will display packets diverted to the port 5000 by ipfw. The remote host I use shows that it connects to port 22 and the ipfw divert rule seems not to work. I can set another rule to block the traffic in the port 22 , and it works. only the divert rule seems to fail. I wrote some piece of code using divert socket to read packets from the divert port , but no result ... I think I'm missing something , so please enlighten my mind ... Many Thanks -- Saber --------------080104040208090602080700 Content-Type: text/plain; name="divertd.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="divertd.c" /*#include #include #include #include #include #include #include */ #include /* NB: we rely on this for */ #include #include #include #include #include #include #include #include #include #include #ifdef IPSEC #include #endif /*IPSEC*/ #include #include #include #include #include #include #include #include #include #include #include #include #define BUFSIZE 65535 int main(int argc, char **argv) { int fd, rawfd, fdfw, ret, n; int on = 1; struct sockaddr_in bindPort, sin; int sinlen; int port_nb; struct ip *hdr; unsigned char packet[BUFSIZE]; struct in_addr addr; int i, direction; struct ip_mreq mreq; if (argc != 2) { fprintf(stderr, "Usage: %s \n", argv[0]); exit(1); } bindPort.sin_family = AF_INET; bindPort.sin_port = htons(atol(argv[1])); bindPort.sin_addr.s_addr = 0; fprintf(stderr, "%s:Creating a socket\n", argv[0]); /* open a divert socket */ fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); if (fd == -1) { fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); exit(1); } bindPort.sin_family = AF_INET; bindPort.sin_port = htons(atol(argv[1])); bindPort.sin_addr.s_addr = 0; fprintf(stderr, "%s:Binding a socket\n", argv[0]); ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); if (ret != 0) { close(fd); fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); exit(2); } printf("%s: Waiting for data...\n", argv[0]); /* read data in */ sinlen = sizeof(struct sockaddr_in); while (1) { n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); hdr = (struct ip *) packet; printf("%s: The packet looks like this:\n", argv[0]); for (i = 0; i < 40; i++) { printf("%02x ", (int)*(packet + i)); if (!((i + 1) % 16)) printf("\n"); }; printf("\n"); printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); } } --------------080104040208090602080700-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:08:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B704A16A4CE; Tue, 28 Sep 2004 10:08:47 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C3C43D45; Tue, 28 Sep 2004 10:08:41 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from mail-vc.jaist.ac.jp (mail-vc.jaist.ac.jp [150.65.5.31]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i8SA8bN03722; Tue, 28 Sep 2004 19:08:37 +0900 (JST) Received: from mail-vc.jaist.ac.jp (localhost [127.0.0.1]) by localhost.jaist.ac.jp (Postfix) with ESMTP id F3878848C; Tue, 28 Sep 2004 19:08:36 +0900 (JST) Received: from smtp.jaist.ac.jp (smtp.jaist.ac.jp [150.65.38.97]) by mail-vc.jaist.ac.jp (Postfix) with ESMTP id D2E6F8489; Tue, 28 Sep 2004 19:08:36 +0900 (JST) Received: from jaist.ac.jp (is32e1b21.jaist.ac.jp [150.65.118.21]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i8SA70h02621; Tue, 28 Sep 2004 19:07:00 +0900 (JST) Message-ID: <41593824.9030006@jaist.ac.jp> Date: Tue, 28 Sep 2004 19:08:36 +0900 From: Zrelli Saber Ben Mohamed User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020921 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, hackers@freebsd.org, net@freebsd.org Content-Type: multipart/mixed; boundary="------------080104040208090602080700" Subject: divert , ipfw 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: Tue, 28 Sep 2004 10:08:48 -0000 This is a multi-part message in MIME format. --------------080104040208090602080700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi , I'm interesed in the "divert" mechanism and want to try it out , so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the IPDIVERT option and then added the needed lines in the rc.conf file, after that , I set up ipfw to divert packets to some port here is my ipfw rule set . 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65100 divert 5000 ip from any 22 to me <---- the divert rule 65535 deny ip from any to any then, I wanted to monitor the diverted traffic using tcpdump : $ tcpdump port 5000 when I do a telnet connection to the port 22 from a remote host , I was expecting that tcpdump will display packets diverted to the port 5000 by ipfw. The remote host I use shows that it connects to port 22 and the ipfw divert rule seems not to work. I can set another rule to block the traffic in the port 22 , and it works. only the divert rule seems to fail. I wrote some piece of code using divert socket to read packets from the divert port , but no result ... I think I'm missing something , so please enlighten my mind ... Many Thanks -- Saber --------------080104040208090602080700 Content-Type: text/plain; name="divertd.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="divertd.c" /*#include #include #include #include #include #include #include */ #include /* NB: we rely on this for */ #include #include #include #include #include #include #include #include #include #include #ifdef IPSEC #include #endif /*IPSEC*/ #include #include #include #include #include #include #include #include #include #include #include #include #define BUFSIZE 65535 int main(int argc, char **argv) { int fd, rawfd, fdfw, ret, n; int on = 1; struct sockaddr_in bindPort, sin; int sinlen; int port_nb; struct ip *hdr; unsigned char packet[BUFSIZE]; struct in_addr addr; int i, direction; struct ip_mreq mreq; if (argc != 2) { fprintf(stderr, "Usage: %s \n", argv[0]); exit(1); } bindPort.sin_family = AF_INET; bindPort.sin_port = htons(atol(argv[1])); bindPort.sin_addr.s_addr = 0; fprintf(stderr, "%s:Creating a socket\n", argv[0]); /* open a divert socket */ fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); if (fd == -1) { fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); exit(1); } bindPort.sin_family = AF_INET; bindPort.sin_port = htons(atol(argv[1])); bindPort.sin_addr.s_addr = 0; fprintf(stderr, "%s:Binding a socket\n", argv[0]); ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); if (ret != 0) { close(fd); fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); exit(2); } printf("%s: Waiting for data...\n", argv[0]); /* read data in */ sinlen = sizeof(struct sockaddr_in); while (1) { n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); hdr = (struct ip *) packet; printf("%s: The packet looks like this:\n", argv[0]); for (i = 0; i < 40; i++) { printf("%02x ", (int)*(packet + i)); if (!((i + 1) % 16)) printf("\n"); }; printf("\n"); printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); } } --------------080104040208090602080700-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:36:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 10:36:25 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:36:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 10:36:25 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:38:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3201216A4CE; Tue, 28 Sep 2004 10:38:19 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D937643D39; Tue, 28 Sep 2004 10:38:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-67-124-49-205.dsl.snfc21.pacbell.net [67.124.49.205])i8SAcMqM024628; Tue, 28 Sep 2004 06:38:22 -0400 Message-ID: <41593F14.8050603@elischer.org> Date: Tue, 28 Sep 2004 03:38:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Zrelli Saber Ben Mohamed References: <41593824.9030006@jaist.ac.jp> In-Reply-To: <41593824.9030006@jaist.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw 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: Tue, 28 Sep 2004 10:38:19 -0000 Zrelli Saber Ben Mohamed wrote: > Hi , > > I'm interesed in the "divert" mechanism and want to try it out , > so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the > IPDIVERT option and then added the needed lines in the rc.conf file, > after that , I set up ipfw to divert packets to some port > here is my ipfw rule set . > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65100 divert 5000 ip from any 22 to me <---- the divert rule > 65535 deny ip from any to any > > then, I wanted to monitor the diverted traffic using tcpdump : > > $ tcpdump port 5000 > > when I do a telnet connection to the port 22 from a remote host , I was > expecting that tcpdump will display packets diverted to the port 5000 by > ipfw. > The remote host I use shows that it connects to port 22 and the ipfw > divert rule seems not to work. > I can set another rule to block the traffic in the port 22 , and it works. > only the divert rule seems to fail. > > I wrote some piece of code using divert socket to read packets from the > divert port , but no result ... > > I think I'm missing something , > > so please enlighten my mind ... you have 2 problems.. firstly, all packats never get to your divert rule ecause they are accepted by the previous rule.. 65000 allow ip from any to any secondly "divert" sends teh data to a "DIVERT" socket.. you can also use a 'tee' command in teh ipfw to just get a copy of the packet in which case you will see the negotioation continue. Divert sockets remove the packet from the kernel. Since you do not pass the packet BACK to the kernel again no further negotiation will occur as no tcp handshake will occur. If you use the 'tee' rule you are effectively simulating bpf and libpcap. If you use 'divert' then you need to write the packet (and the sockaddr) back to the divert socket to reinject it to the system after you have examined (and possibly modified) it. > > > Many Thanks > > > -- > Saber > > > > > > > ------------------------------------------------------------------------ > > > /*#include > #include > #include > #include > #include > #include > #include > */ > #include /* NB: we rely on this for */ > #include > #include > #include > #include > > #include > #include > #include > #include > #include > #include > > #ifdef IPSEC > #include > #endif /*IPSEC*/ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > #define BUFSIZE 65535 > > > int > main(int argc, char **argv) > { > int fd, rawfd, fdfw, ret, n; > int on = 1; > struct sockaddr_in bindPort, sin; > int sinlen; > int port_nb; > struct ip *hdr; > unsigned char packet[BUFSIZE]; > struct in_addr addr; > int i, direction; > struct ip_mreq mreq; > > if (argc != 2) { > fprintf(stderr, "Usage: %s \n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > > fprintf(stderr, "%s:Creating a socket\n", argv[0]); > /* open a divert socket */ > fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); > > if (fd == -1) { > fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > fprintf(stderr, "%s:Binding a socket\n", argv[0]); > ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); > > if (ret != 0) { > close(fd); > fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); > exit(2); > } > printf("%s: Waiting for data...\n", argv[0]); > /* read data in */ > sinlen = sizeof(struct sockaddr_in); > while (1) { > n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); > hdr = (struct ip *) packet; > > printf("%s: The packet looks like this:\n", argv[0]); > for (i = 0; i < 40; i++) { > printf("%02x ", (int)*(packet + i)); > if (!((i + 1) % 16)) > printf("\n"); > }; > printf("\n"); > > printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); > printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); > printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); > printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); > > } > } > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:38:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3201216A4CE; Tue, 28 Sep 2004 10:38:19 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D937643D39; Tue, 28 Sep 2004 10:38:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-67-124-49-205.dsl.snfc21.pacbell.net [67.124.49.205])i8SAcMqM024628; Tue, 28 Sep 2004 06:38:22 -0400 Message-ID: <41593F14.8050603@elischer.org> Date: Tue, 28 Sep 2004 03:38:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Zrelli Saber Ben Mohamed References: <41593824.9030006@jaist.ac.jp> In-Reply-To: <41593824.9030006@jaist.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw 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: Tue, 28 Sep 2004 10:38:19 -0000 Zrelli Saber Ben Mohamed wrote: > Hi , > > I'm interesed in the "divert" mechanism and want to try it out , > so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the > IPDIVERT option and then added the needed lines in the rc.conf file, > after that , I set up ipfw to divert packets to some port > here is my ipfw rule set . > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65100 divert 5000 ip from any 22 to me <---- the divert rule > 65535 deny ip from any to any > > then, I wanted to monitor the diverted traffic using tcpdump : > > $ tcpdump port 5000 > > when I do a telnet connection to the port 22 from a remote host , I was > expecting that tcpdump will display packets diverted to the port 5000 by > ipfw. > The remote host I use shows that it connects to port 22 and the ipfw > divert rule seems not to work. > I can set another rule to block the traffic in the port 22 , and it works. > only the divert rule seems to fail. > > I wrote some piece of code using divert socket to read packets from the > divert port , but no result ... > > I think I'm missing something , > > so please enlighten my mind ... you have 2 problems.. firstly, all packats never get to your divert rule ecause they are accepted by the previous rule.. 65000 allow ip from any to any secondly "divert" sends teh data to a "DIVERT" socket.. you can also use a 'tee' command in teh ipfw to just get a copy of the packet in which case you will see the negotioation continue. Divert sockets remove the packet from the kernel. Since you do not pass the packet BACK to the kernel again no further negotiation will occur as no tcp handshake will occur. If you use the 'tee' rule you are effectively simulating bpf and libpcap. If you use 'divert' then you need to write the packet (and the sockaddr) back to the divert socket to reinject it to the system after you have examined (and possibly modified) it. > > > Many Thanks > > > -- > Saber > > > > > > > ------------------------------------------------------------------------ > > > /*#include > #include > #include > #include > #include > #include > #include > */ > #include /* NB: we rely on this for */ > #include > #include > #include > #include > > #include > #include > #include > #include > #include > #include > > #ifdef IPSEC > #include > #endif /*IPSEC*/ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > #define BUFSIZE 65535 > > > int > main(int argc, char **argv) > { > int fd, rawfd, fdfw, ret, n; > int on = 1; > struct sockaddr_in bindPort, sin; > int sinlen; > int port_nb; > struct ip *hdr; > unsigned char packet[BUFSIZE]; > struct in_addr addr; > int i, direction; > struct ip_mreq mreq; > > if (argc != 2) { > fprintf(stderr, "Usage: %s \n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > > fprintf(stderr, "%s:Creating a socket\n", argv[0]); > /* open a divert socket */ > fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); > > if (fd == -1) { > fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > fprintf(stderr, "%s:Binding a socket\n", argv[0]); > ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); > > if (ret != 0) { > close(fd); > fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); > exit(2); > } > printf("%s: Waiting for data...\n", argv[0]); > /* read data in */ > sinlen = sizeof(struct sockaddr_in); > while (1) { > n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); > hdr = (struct ip *) packet; > > printf("%s: The packet looks like this:\n", argv[0]); > for (i = 0; i < 40; i++) { > printf("%02x ", (int)*(packet + i)); > if (!((i + 1) % 16)) > printf("\n"); > }; > printf("\n"); > > printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); > printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); > printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); > printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); > > } > } > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 11:13:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA9416A4CE; Tue, 28 Sep 2004 11:13:36 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049CC43D1F; Tue, 28 Sep 2004 11:13:31 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from mail-vc.jaist.ac.jp (mail-vc.jaist.ac.jp [150.65.5.31]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i8SBDUN22068; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from mail-vc.jaist.ac.jp (localhost [127.0.0.1]) by localhost.jaist.ac.jp (Postfix) with ESMTP id 326DD8489; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from smtp.jaist.ac.jp (smtp.jaist.ac.jp [150.65.38.97]) by mail-vc.jaist.ac.jp (Postfix) with ESMTP id 0C6178484; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from jaist.ac.jp (is32e1b21.jaist.ac.jp [150.65.118.21]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i8SBBqh04276; Tue, 28 Sep 2004 20:11:52 +0900 (JST) Message-ID: <41594759.5010104@jaist.ac.jp> Date: Tue, 28 Sep 2004 20:13:29 +0900 From: Zrelli Saber Ben Mohamed User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020921 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zrelli Saber Ben Mohamed References: <41593824.9030006@jaist.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw 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: Tue, 28 Sep 2004 11:13:37 -0000 Thanks ! I got it working. -- Saber Zrelli Saber Ben Mohamed wrote: > Hi , > > I'm interesed in the "divert" mechanism and want to try it out , > so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding > the IPDIVERT option and then added the needed lines in the rc.conf file, > after that , I set up ipfw to divert packets to some port > here is my ipfw rule set . > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65100 divert 5000 ip from any 22 to me <---- the divert rule > 65535 deny ip from any to any > > then, I wanted to monitor the diverted traffic using tcpdump : > > $ tcpdump port 5000 > > when I do a telnet connection to the port 22 from a remote host , I > was expecting that tcpdump will display packets diverted to the port > 5000 by ipfw. > The remote host I use shows that it connects to port 22 and the ipfw > divert rule seems not to work. > I can set another rule to block the traffic in the port 22 , and it > works. > only the divert rule seems to fail. > > I wrote some piece of code using divert socket to read packets from > the divert port , but no result ... > > I think I'm missing something , > > so please enlighten my mind ... > > > Many Thanks > > > -- > Saber > > > > > >------------------------------------------------------------------------ > > >/*#include >#include >#include >#include >#include >#include >#include >*/ >#include /* NB: we rely on this for */ >#include >#include >#include >#include > >#include >#include >#include >#include >#include >#include > >#ifdef IPSEC >#include >#endif /*IPSEC*/ > >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include > > >#define BUFSIZE 65535 > > >int >main(int argc, char **argv) >{ > int fd, rawfd, fdfw, ret, n; > int on = 1; > struct sockaddr_in bindPort, sin; > int sinlen; > int port_nb; > struct ip *hdr; > unsigned char packet[BUFSIZE]; > struct in_addr addr; > int i, direction; > struct ip_mreq mreq; > > if (argc != 2) { > fprintf(stderr, "Usage: %s \n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > > fprintf(stderr, "%s:Creating a socket\n", argv[0]); > /* open a divert socket */ > fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); > > if (fd == -1) { > fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > fprintf(stderr, "%s:Binding a socket\n", argv[0]); > ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); > > if (ret != 0) { > close(fd); > fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); > exit(2); > } > printf("%s: Waiting for data...\n", argv[0]); > /* read data in */ > sinlen = sizeof(struct sockaddr_in); > while (1) { > n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); > hdr = (struct ip *) packet; > > printf("%s: The packet looks like this:\n", argv[0]); > for (i = 0; i < 40; i++) { > printf("%02x ", (int)*(packet + i)); > if (!((i + 1) % 16)) > printf("\n"); > }; > printf("\n"); > > printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); > printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); > printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); > printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); > > } >} > > >------------------------------------------------------------------------ > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 11:13:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA9416A4CE; Tue, 28 Sep 2004 11:13:36 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049CC43D1F; Tue, 28 Sep 2004 11:13:31 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from mail-vc.jaist.ac.jp (mail-vc.jaist.ac.jp [150.65.5.31]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i8SBDUN22068; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from mail-vc.jaist.ac.jp (localhost [127.0.0.1]) by localhost.jaist.ac.jp (Postfix) with ESMTP id 326DD8489; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from smtp.jaist.ac.jp (smtp.jaist.ac.jp [150.65.38.97]) by mail-vc.jaist.ac.jp (Postfix) with ESMTP id 0C6178484; Tue, 28 Sep 2004 20:13:30 +0900 (JST) Received: from jaist.ac.jp (is32e1b21.jaist.ac.jp [150.65.118.21]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i8SBBqh04276; Tue, 28 Sep 2004 20:11:52 +0900 (JST) Message-ID: <41594759.5010104@jaist.ac.jp> Date: Tue, 28 Sep 2004 20:13:29 +0900 From: Zrelli Saber Ben Mohamed User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020921 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zrelli Saber Ben Mohamed References: <41593824.9030006@jaist.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: divert , ipfw 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: Tue, 28 Sep 2004 11:13:37 -0000 Thanks ! I got it working. -- Saber Zrelli Saber Ben Mohamed wrote: > Hi , > > I'm interesed in the "divert" mechanism and want to try it out , > so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding > the IPDIVERT option and then added the needed lines in the rc.conf file, > after that , I set up ipfw to divert packets to some port > here is my ipfw rule set . > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65100 divert 5000 ip from any 22 to me <---- the divert rule > 65535 deny ip from any to any > > then, I wanted to monitor the diverted traffic using tcpdump : > > $ tcpdump port 5000 > > when I do a telnet connection to the port 22 from a remote host , I > was expecting that tcpdump will display packets diverted to the port > 5000 by ipfw. > The remote host I use shows that it connects to port 22 and the ipfw > divert rule seems not to work. > I can set another rule to block the traffic in the port 22 , and it > works. > only the divert rule seems to fail. > > I wrote some piece of code using divert socket to read packets from > the divert port , but no result ... > > I think I'm missing something , > > so please enlighten my mind ... > > > Many Thanks > > > -- > Saber > > > > > >------------------------------------------------------------------------ > > >/*#include >#include >#include >#include >#include >#include >#include >*/ >#include /* NB: we rely on this for */ >#include >#include >#include >#include > >#include >#include >#include >#include >#include >#include > >#ifdef IPSEC >#include >#endif /*IPSEC*/ > >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include >#include > > >#define BUFSIZE 65535 > > >int >main(int argc, char **argv) >{ > int fd, rawfd, fdfw, ret, n; > int on = 1; > struct sockaddr_in bindPort, sin; > int sinlen; > int port_nb; > struct ip *hdr; > unsigned char packet[BUFSIZE]; > struct in_addr addr; > int i, direction; > struct ip_mreq mreq; > > if (argc != 2) { > fprintf(stderr, "Usage: %s \n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > > fprintf(stderr, "%s:Creating a socket\n", argv[0]); > /* open a divert socket */ > fd = socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT); > > if (fd == -1) { > fprintf(stderr, "%s:We could not open a divert socket\n", argv[0]); > exit(1); > } > bindPort.sin_family = AF_INET; > bindPort.sin_port = htons(atol(argv[1])); > bindPort.sin_addr.s_addr = 0; > > fprintf(stderr, "%s:Binding a socket\n", argv[0]); > ret = bind(fd, (struct sockaddr*)&bindPort, sizeof(struct sockaddr_in)); > > if (ret != 0) { > close(fd); > fprintf(stderr, "%s: Error bind(): %s", argv[0], strerror(ret)); > exit(2); > } > printf("%s: Waiting for data...\n", argv[0]); > /* read data in */ > sinlen = sizeof(struct sockaddr_in); > while (1) { > n = recvfrom(fd, packet, BUFSIZE, 0, (struct sockaddr*)&sin, &sinlen); > hdr = (struct ip *) packet; > > printf("%s: The packet looks like this:\n", argv[0]); > for (i = 0; i < 40; i++) { > printf("%02x ", (int)*(packet + i)); > if (!((i + 1) % 16)) > printf("\n"); > }; > printf("\n"); > > printf("%s: Source address: %s\n", argv[0], inet_ntoa(hdr->ip_src)); > printf("%s: Destination address: %s\n", argv[0], inet_ntoa(hdr->ip_dst)); > printf("%s: Receiving IF address: %s\n", argv[0], inet_ntoa(sin.sin_addr)); > printf("%s: Protocol number: %i\n", argv[0], hdr->ip_p); > > } >} > > >------------------------------------------------------------------------ > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 14:27:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4259216A4CE for ; Tue, 28 Sep 2004 14:27:51 +0000 (GMT) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC93D43D1D for ; Tue, 28 Sep 2004 14:27:46 +0000 (GMT) (envelope-from fming@borderware.com) Message-ID: <415974DF.8080009@borderware.com> Date: Tue, 28 Sep 2004 10:27:43 -0400 From: ming fu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Pierre Beyssac References: <20040927182722.GA1664@bofh.enst.fr> In-Reply-To: <20040927182722.GA1664@bofh.enst.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: reproductible hang with if_em 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, 28 Sep 2004 14:27:51 -0000 I have experienced the same thing with 4.7 as well. The driver just refuse to send anymore and won't self recover. However, tcpdump on the interface will still see traffic on the network, so receive seem working. Upgrade the driver to the most up-to-date code from 4.10 tree or from Intel does not help. Looking at the em_watchdog, there is a test that could cause the watchdog to do nothing. Comparing to the similar fxp driver, fxp watchdog just go ahead to restart the driver. Ming Pierre Beyssac wrote: >Hello, > >I'm having a problem (under 5.3-BETA, but I don't think it matters >much) with the if_em driver on bursty outbound traffic: the card >is stuck in a state where it only returns ENOBUFS. No buffers ever >become available again, but ifconfig down+up fixes the problem. > >>From a quick analysis it looks like the TX descriptor cleanup routine >em_clean_transmit_interrupts() as called by em_encap() in such cases >doesn't manage to find anything free with E1000_TXD_STAT_DD set. >The card seems stuck in this state. A simple albeit dirty fix would >be to cancel some or all untransmitted packets in such cases. > >Perhaps this is related to my using the card on a 100Mbps switch. >I have a small program to exercise the hang in case someone would >like to have a look at it. > >See below for the result of "sysctl hw.em0.debug_info=1" (notice >the not avail1 = 12 and not avail2 = 0 hinting at >em_clean_transmit_interrupts). > >em0: [MPSAFE] >em0: bpf attached >em0: Ethernet address: 00:0d:56:d0:5c:15 >em0: Speed:N/A Duplex:N/A >em0: Link is up 100 Mbps Full Duplex >em0: Adapter hardware address = 0xc3570b34 >em0:tx_int_delay = 66, tx_abs_int_delay = 66 >em0:rx_int_delay = 0, rx_abs_int_delay = 66 >em0: fifo workaround = 0, fifo_reset = 0 >em0: hw tdh = 238, hw tdt = 238 >em0: Num Tx descriptors avail = 256 >em0: Tx Descriptors not avail1 = 12 >em0: Tx Descriptors not avail2 = 0 >em0: Std mbuf failed = 0 >em0: Std mbuf cluster failed = 0 >em0: Driver dropped packets = 0 > > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 14:29:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A24D16A4CE; Tue, 28 Sep 2004 14:29:59 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC7C143D39; Tue, 28 Sep 2004 14:29:58 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8SETEr2040690; Tue, 28 Sep 2004 07:29:14 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i8SET2jt083514; Tue, 28 Sep 2004 07:29:06 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 28 Sep 2004 23:28:50 +0900 Message-ID: From: "George V. Neville-Neil" To: freebsd-net@freebsd.org, rwatson@freebsd.org In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: Re: (KAME-snap 8809) Patch for fragment problem in key.c 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, 28 Sep 2004 14:29:59 -0000 So, I checked and the change in Kame is identical. Can we get this committed to our code? It's a simple, five line, removal. Thanks, George At Tue, 28 Sep 2004 10:39:09 +0900, George V. Neville-Neil wrote: > > Hi Folks, > > Robert Watson tried to send email about this but it never got > through, and then Sam Leffler got ahold of me and told me he > fixed something similar in the FAST_IPSEC code. So, the > following patch fixes, in KAME IPSec. This patch was > generated against 6.0-CURRENT and I included Sam's commit > message. > > Later, > George > > Correct handling of SADB_UPDATE and SADB_ADD requests. key_align may split > the mbuf due to use of m_pulldown. Discarding the result because of this > does not make sense as no subsequent code depends on the entire msg being > linearized (only the individual pieces). It's likely something else is wrong > here but for now this appears to get things back to a working state. > > Index: sys/netkey/key.c > =================================================================== > RCS file: /Volumes/exported/FreeBSD-CVS/src/sys/netkey/key.c,v > retrieving revision 1.67 > diff -u -r1.67 key.c > --- sys/netkey/key.c 2 Sep 2004 20:14:03 -0000 1.67 > +++ sys/netkey/key.c 27 Sep 2004 16:08:31 -0000 > @@ -6952,11 +6952,6 @@ > if (error) > return error; > > - if (m->m_next) { /*XXX*/ > - m_freem(m); > - return ENOBUFS; > - } > - > msg = mh.msg; > > /* check SA type */ > From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 14:33:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23A2516A4CE for ; Tue, 28 Sep 2004 14:33:44 +0000 (GMT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A358543D39 for ; Tue, 28 Sep 2004 14:33:43 +0000 (GMT) (envelope-from beyssac@bofh.enst.fr) Received: from bofh.enst.fr (bofh.enst.fr [137.194.32.191]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "bofh.enst.fr", Issuer "ENST CA" (not verified)) by smtp2.enst.fr (Postfix) with ESMTP id 5D935348; Tue, 28 Sep 2004 16:33:39 +0200 (CEST) Received: from bofh.enst.fr (localhost [127.0.0.1]) by bofh.enst.fr (8.13.1/8.13.1) with ESMTP id i8SEXdKH041114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Sep 2004 16:33:39 +0200 (CEST) (envelope-from beyssac@bofh.enst.fr) Received: (from beyssac@localhost) by bofh.enst.fr (8.13.1/8.13.1/Submit) id i8SEXdjO041113; Tue, 28 Sep 2004 16:33:39 +0200 (CEST) (envelope-from beyssac) Date: Tue, 28 Sep 2004 16:33:39 +0200 From: Pierre Beyssac To: ming fu Message-ID: <20040928143339.GI1881@bofh.enst.fr> References: <20040927182722.GA1664@bofh.enst.fr> <415974DF.8080009@borderware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415974DF.8080009@borderware.com> User-Agent: Mutt/1.4.2.1i X-message-flag: Warning! Use of Microsoft Outlook makes your system susceptible to worms and viruses cc: freebsd-net@freebsd.org Subject: Re: reproductible hang with if_em 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, 28 Sep 2004 14:33:44 -0000 On Tue, Sep 28, 2004 at 10:27:43AM -0400, ming fu wrote: > I have experienced the same thing with 4.7 as well. The driver just > refuse to send anymore and won't self recover. However, tcpdump on the > interface will still see traffic on the network, so receive seem > working. Upgrade the driver to the most up-to-date code from 4.10 tree > or from Intel does not help. Your problem seems to be similar to mine (I also see received packets on the interface), however I haven't been able to reproduce it on any of several 4.9 and 4.10 machines I tested it on (on the other hand my test program works every time on 5.3). It may be a subtle timing issue. I got a private reply from Tony Ackerman, he is looking into this. -- Pierre Beyssac pb@enst.fr From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 16:14:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC27216A4CE; Tue, 28 Sep 2004 16:14:23 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED79743D58; Tue, 28 Sep 2004 16:14:22 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 28 Sep 2004 19:14:22 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 17:55:45 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 940105728A; Tue, 28 Sep 2004 14:54:57 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 615D916A595; Tue, 28 Sep 2004 14:54:41 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] X-Mailman-Approved-At: Tue, 28 Sep 2004 14:53:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: net@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:14:24 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 16:14:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC27216A4CE; Tue, 28 Sep 2004 16:14:23 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED79743D58; Tue, 28 Sep 2004 16:14:22 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 28 Sep 2004 19:14:22 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 17:55:45 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 940105728A; Tue, 28 Sep 2004 14:54:57 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 615D916A595; Tue, 28 Sep 2004 14:54:41 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] X-Mailman-Approved-At: Tue, 28 Sep 2004 14:53:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: net@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:14:24 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 16:14:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D351916A4CE; Tue, 28 Sep 2004 16:14:24 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FBD43D5A; Tue, 28 Sep 2004 16:14:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 28 Sep 2004 19:14:22 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 17:56:07 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5549957397; Tue, 28 Sep 2004 14:55:34 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A38F16A5C1; Tue, 28 Sep 2004 14:54:47 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] X-Mailman-Approved-At: Tue, 28 Sep 2004 14:53:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: net@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:14:25 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 16:14:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D351916A4CE; Tue, 28 Sep 2004 16:14:24 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FBD43D5A; Tue, 28 Sep 2004 16:14:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 28 Sep 2004 19:14:22 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 17:56:07 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5549957397; Tue, 28 Sep 2004 14:55:34 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A38F16A5C1; Tue, 28 Sep 2004 14:54:47 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1F16A4CE; Tue, 28 Sep 2004 10:36:25 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FBE43D31; Tue, 28 Sep 2004 10:36:24 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i8SAaI7n009918; Tue, 28 Sep 2004 14:36:18 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Sep 2004 14:23:56 +0400 Date: Tue, 28 Sep 2004 14:23:56 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <381891561234.20040928142356@star-sw.com> To: Zrelli Saber Ben Mohamed In-reply-To: <41593824.9030006@jaist.ac.jp> References: <41593824.9030006@jaist.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2004 10:23:56.0537 (UTC) FILETIME=[42CE7690:01C4A545] X-Mailman-Approved-At: Tue, 28 Sep 2004 14:53:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: net@freebsd.org Subject: Re: divert , ipfw question X-BeenThere: freebsd-net@freebsd.org Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 16:14:25 -0000 Hello Zrelli, the rule 65000 allow ip from any to any stops processing of a packet, so it will never reach diverting rule 65100. see man ipfw about rule-processing Tuesday, September 28, 2004, 2:08:36 PM, Zrelli Saber Ben Mohamed wrote: ZSBM> Hi , ZSBM> I'm interesed in the "divert" mechanism and want to try it out , ZSBM> so I recompiled the kernel ( FreeBSD 5.2.1-RELEASE #0 ) after adding the ZSBM> IPDIVERT option and then added the needed lines in the rc.conf file, ZSBM> after that , I set up ipfw to divert packets to some port ZSBM> here is my ipfw rule set . ZSBM> 00100 allow ip from any to any via lo0 ZSBM> 00200 deny ip from any to 127.0.0.0/8 ZSBM> 00300 deny ip from 127.0.0.0/8 to any ZSBM> 65000 allow ip from any to any ZSBM> 65100 divert 5000 ip from any 22 to me <---- the divert rule ZSBM> 65535 deny ip from any to any ZSBM> then, I wanted to monitor the diverted traffic using tcpdump : ZSBM> $ tcpdump port 5000 ZSBM> when I do a telnet connection to the port 22 from a remote host , I was ZSBM> expecting that tcpdump will display packets diverted to the port 5000 by ZSBM> ipfw. ZSBM> The remote host I use shows that it connects to port 22 and the ipfw ZSBM> divert rule seems not to work. ZSBM> I can set another rule to block the traffic in the port 22 , and it works. ZSBM> only the divert rule seems to fail. ZSBM> I wrote some piece of code using divert socket to read packets from the ZSBM> divert port , but no result ... ZSBM> I think I'm missing something , ZSBM> so please enlighten my mind ... ZSBM> Many Thanks ZSBM> -- ZSBM> Saber -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 16:17:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FE2C16A4CE; Tue, 28 Sep 2004 16:17:11 +0000 (GMT) Received: from tron.telenetwork.com (tron.telenetwork.com [204.57.81.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E3543D46; Tue, 28 Sep 2004 16:17:10 +0000 (GMT) (envelope-from jmarquez@x25.net) Received: from [209.163.253.130] (helo=tni1411) by tron.telenetwork.com with smtp (Exim 3.35 #1 (Debian)) id 1CCKf8-0000eN-00; Tue, 28 Sep 2004 11:17:10 -0500 Message-ID: <002b01c4a576$9b65f1d0$82fda3d1@sanmarcos.x25.net> From: "Jesse Marquez" To: , Date: Tue, 28 Sep 2004 11:17:04 -0500 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: dc0 acting up 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, 28 Sep 2004 16:17:11 -0000 -FreeBSD 5.2-CURRENT Hi all, I've recently started having major problems with my internet = connection. If I try to do any type of internet activty it just lags = away until my system freezes. I'm receiving the following error below error repeats dc0: discard oversize frame (ether type 8864 flags 3 len 1514 > max = 1506) I've never had any problems till now. Only thing I used to notice was = this acd0: CDRW at ata1-master PIO4 acd1: DVDROM at ata1-slave = PIO4 Mounting root from ufs:/dev/ad1s1a dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state any ideas? From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 17:10:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2771C16A4CE for ; Tue, 28 Sep 2004 17:10:28 +0000 (GMT) Received: from smtp.ucsb.edu (hub.ucsb.edu [128.111.24.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9454E43D39 for ; Tue, 28 Sep 2004 17:10:04 +0000 (GMT) (envelope-from kps@ucsb.edu) Received: from splat.oit.ucsb.edu ([128.111.12.20]) by smtp.ucsb.edu with asmtp TLSv1:RC4-MD5:128 id 1CCLUK-000BOY-FZ for freebsd-net@freebsd.org; Tue, 28 Sep 2004 10:10:04 -0700 From: Kevin Schmidt Organization: University of California, Santa Barbara To: freebsd-net@freebsd.org Date: Tue, 28 Sep 2004 10:10:02 -0700 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409281010.02904.kps@ucsb.edu> Subject: Bridging vlans w/firewall and selective HTTP redirect? 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, 28 Sep 2004 17:10:28 -0000 Hi all, I'm interested in placing an FBSD box (prefer 4.x since it's production, though I've also used 5.2) inline on a link with 802.1Q-tagged vlans with firewalling and selective HTTP redirects. Bridging a couple of ethernets isn't a problem, and it appears I can enable ipf or ipfw (but not pf; too bad, ALTQ and pfsync would be nice). What does not appear viable is the interception and transparent redirect of HTTP traffic in this bridged environment. Anyone know of a good way to do this? The purpose of the above is to support a wireless network where users may be associated with various vlans, some of which will require selective traffic filtering and transparent http redirects. For example, there might be an SSID for a "readme" vlan network where people could log in to a web page and download an 802.1X supplicant. The supplicant would be preconfigured to join another SSID, e.g. "campus wireless", which would allow authenticated users full Internet access. If a particular user is known to have a compromised/infected system, they'd be mapped to a quanantine vlan, which ideally would block most traffic and redirect them to a web page with additional information and remediation tools. Similar techniques would be used to support an https login process that would selectively open the firewall for authenticated users. I'm sure someone reading this is wondering, "why not do the web redirects on a routed interface instead of with an inline bridge, since redirects at an L3 interface work?" The answer is scalability and roaming: I'd like routing to be done at a couple of upstream Cisco boxes, with two or more FBSD boxes inline on the downstream vlans supporting wireless and (ultimately) some wired ports. I'll do it routed if I must, but it would be great if I could redirect locally at the bridge. I'm looking at Linux/OpenBSD/NetBSD, too, though I've always preferred FBSD (still have my 1.x CDs) and have happily used it for DNS, web, ftp, etc. servers for years. Any suggestions/comments/questions welcome. Cheers, -- Kevin Schmidt Campus Network Programmer Office of Information Technology University of California, Santa Barbara North Hall 2124 Santa Barbara, CA 93106-3201 805-893-7779 805-893-5051 FAX kps@ucsb.edu From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 21:28:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42E5316A4CE; Tue, 28 Sep 2004 21:28:46 +0000 (GMT) Received: from dns.p-i-n.com (dns.p-i-n.com [145.253.185.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 260E643D46; Tue, 28 Sep 2004 21:28:45 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from p-i-n.com (inside.p-i-n.com [129.10.9.21]) by dns.p-i-n.com (8.12.9p2/8.12.9) with ESMTP id i8SLSfXt094845; Tue, 28 Sep 2004 23:28:42 +0200 (CEST) (envelope-from rabe@p-i-n.com) Received: (from rabe@localhost) by p-i-n.com (8.11.6/8.11.6) id i8SLSfr76431; Tue, 28 Sep 2004 23:28:41 +0200 (CEST) (envelope-from rabe) Date: Tue, 28 Sep 2004 23:28:41 +0200 From: "Raphael H. Becker" To: freebsd-current@freebsd.org Message-ID: <20040928232841.W55054@p-i-n.com> References: <20040917104356.E55054@p-i-n.com> <414ADD15.FAC42CDB@freebsd.org> <20040917231922.G55054@p-i-n.com> <414B567C.9060904@freebsd.org> <20040917235056.I55054@p-i-n.com> <414B6234.8060904@freebsd.org> <20040918011644.N55054@p-i-n.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040918011644.N55054@p-i-n.com>; from rabe@p-i-n.com on Sat, Sep 18, 2004 at 01:16:44AM +0200 Organization: PHOENIX Pharmahandel AG & Co KG, Mannheim, Deutschland cc: freebsd-net@freebsd.org Subject: if_bge with (was: Re: Strange things on GBit / 1000->100 / net.inet.tcp.inflight.* ) 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, 28 Sep 2004 21:28:46 -0000 On Sat, Sep 18, 2004 at 01:16:44AM +0200, Raphael H. Becker wrote: > On Sat, Sep 18, 2004 at 12:16:20AM +0200, Andre Oppermann wrote: > > Would you mind trying a 5.3 to 5.3 transfer but the target 5.3 box forced to > > only 100Mbit full-duplex? Same statistics again. > > Sorry, ifconfig is not possible now. See PM. > I may retest with physical access (without ssh) next days, if needed. Today I had some time for testing AND physical access ... With bge0 bound to 100baseTX / full-duplex the transfer breaks down to <100kBytes/sec, with 1000byseTX its about 250-350kBytes/sec, should be ~10MBytes/sec ifconfig bge0 down ifconfig bge0 media ... ifconfig bge0 up I will do some more and detailed testing next time I'm in our data center, including the netstat-output etc. Hmm. if_bge buggy? But, same machine on a FE-Switich worked perfectly (with 100MBit). By default ifconfig says: bge0: flags=8843 mtu 1500 options=1a inet 10.101.240.56 netmask 0xffffff00 broadcast 10.101.240.255 inet6 fe80::20d:56ff:febb:9c27%bge0 prefixlen 64 scopeid 0x1 ether 00:0d:56:bb:9c:27 media: Ethernet autoselect (1000baseTX ) status: active from dmesg: FreeBSD 5.3-BETA6 #2: Mon Sep 27 10:40:24 CEST 2004 root@pinserv6.p-i-n.com:/usr/obj/usr/src/sys/PE2650 <-- PE2650 is a copy of GENERIC this time. [...] acpi0: on motherboard [...] pcib3: on acpi0 pci3: on pcib3 bge0: mem 0xfcf10000-0xfcf1ffff irq 28 at device 6.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:0d:56:bb:9c:27 bge1: mem 0xfcf00000-0xfcf0ffff irq 29 at device 8.0 on pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:0d:56:bb:9c:28 Any idea? Regards Raphael Becker From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 06:48:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089AD16A4CE; Wed, 29 Sep 2004 06:48:28 +0000 (GMT) Received: from proxy.nelsonbay.com (proxy.nelsonbay.com [203.222.55.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BC5043D55; Wed, 29 Sep 2004 06:48:25 +0000 (GMT) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (bell.nelsonbay.com [203.222.55.34]) by proxy.nelsonbay.com (8.12.9/8.12.9) with ESMTP id i8T6mOhn089975; Wed, 29 Sep 2004 16:48:24 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: (from root@localhost) by bell.nelsonbay.com (8.12.11/8.12.11) id i8T6mOqJ072146; Wed, 29 Sep 2004 16:48:24 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (localhost [127.0.0.1]) by bell.nelsonbay.com (8.12.11/8.12.11) with ESMTP id i8T6mNTb072106; Wed, 29 Sep 2004 16:48:23 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from localhost (leon@localhost)i8T6mNv5072102; Wed, 29 Sep 2004 16:48:23 +1000 (EST) X-Authentication-Warning: bell.nelsonbay.com: leon owned process doing -bs Date: Wed, 29 Sep 2004 16:48:23 +1000 (EST) From: Leon Garde X-X-Sender: leon@localhost To: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Message-ID: <20040929162559.P31282@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.0 required=5.0 tests=SARE_SUB_RAND_LETTRS4 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on bell.nelsonbay.com X-scanner: scanned by Inflex 1.0.12.3 Subject: IPFW and 5.2.1 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, 29 Sep 2004 06:48:28 -0000 Any explanation or fix for my problem with ipfw ... yes I did search the mailing list archives, couldnt find anything relevant. Kernel 5.2.1, freshly loaded off CD, as in rm -rf /usr/src/* ../install.sh base ../install.sh tools ../install.sh sys cp ~leon/GUASS /usr/src/sys/i386/conf/GUASS cd /usr/src make buildkernel KERNCONF=GUASS make installkernel KERNCONF=GUASS reboot Its a relatively fresh install of 5.2.1.. and a picobsd style install derived from same. guass# ipfw -a list 00001 0 0 deny ip from any to 203.222.55.37 via rl0 65535 1287 499525 allow ip from any to any guass# ping 203.222.55.37 PING 203.222.55.37 (203.222.55.37): 56 data bytes 64 bytes from 203.222.55.37: icmp_seq=0 ttl=255 time=0.281 ms 64 bytes from 203.222.55.37: icmp_seq=1 ttl=255 time=0.207 ms < packets are flowing by rl0, despite the ipfw rule to stop them !, rl0 being the only network interface 'connected' ) guass# ipfw delete 1 guass# ipfw add 1 deny ip from any to any guass# ping 203.222.55.37 < No answer, like u would hope> Yes, I have searched archives. Why does "via rl0" , "in recv rl0" , "out xmit rl0" , (or via wi0, in recv wi0, out xmit wi0 ) Is it a known bug ? Can't think of anything else relevant to add. ipfw seems seriously broken in 5.2.1 ??? ------------------------ Leon leon@nelsonbay.com Ph 02 4984 1422 From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 07:59:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16BFE16A4E2 for ; Wed, 29 Sep 2004 07:59:55 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE3943D3F for ; Wed, 29 Sep 2004 07:59:52 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8T7xWt32198; Wed, 29 Sep 2004 10:59:32 +0300 Date: Wed, 29 Sep 2004 10:59:32 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8807) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 29 Sep 2004 07:59:55 -0000 On Tue, 28 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > Okay. Now I think I figure out the problem. Those host routes were > created not deliberately, so the kernel will eventually need a fix to > this. > > But if you are in a hurry and/or cannot replace the kernel soon, I > think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with > this you even do not have to reboot the kernel - though rebooting may > also help if you can). Warning: this freezed the system immediately [all network connectivity broke, and I had to do a quick reset]. Maybe I should have set it up at reboot before the system was in a 'bad' shape.. Speaking of 6to4, if_stf.c does not support setting the MTU, because there's no ioctl handler for it. It wouldn't IMHO hurt to be able to raise it from the glued-in default of 1280.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 08:15:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E646D16A4CE for ; Wed, 29 Sep 2004 08:15:22 +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 221BD43D1F for ; Wed, 29 Sep 2004 08:15:21 +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 BB2201525D; Wed, 29 Sep 2004 17:14:59 +0900 (JST) Date: Wed, 29 Sep 2004 17:14:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: 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: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 29 Sep 2004 08:15:23 -0000 >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), >>>>> Pekka Savola said: >> Okay. Now I think I figure out the problem. Those host routes were >> created not deliberately, so the kernel will eventually need a fix to >> this. >> >> But if you are in a hurry and/or cannot replace the kernel soon, I >> think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with >> this you even do not have to reboot the kernel - though rebooting may >> also help if you can). > Warning: this freezed the system immediately [all network connectivity > broke, and I had to do a quick reset]. Maybe I should have set it up > at reboot before the system was in a 'bad' shape.. Sorry for the trouble, but could you be more specific on "freeze"? Does it mean the kernel hanged (you could not type anything from the keyboard, etc)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 08:15:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6E8716A4CE for ; Wed, 29 Sep 2004 08:15:32 +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 1186843D1F for ; Wed, 29 Sep 2004 08:15:31 +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 617AF15263; Wed, 29 Sep 2004 17:15:29 +0900 (JST) Date: Wed, 29 Sep 2004 17:15:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: 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: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 29 Sep 2004 08:15:33 -0000 >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), >>>>> Pekka Savola said: >> Okay. Now I think I figure out the problem. Those host routes were >> created not deliberately, so the kernel will eventually need a fix to >> this. >> >> But if you are in a hurry and/or cannot replace the kernel soon, I >> think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with >> this you even do not have to reboot the kernel - though rebooting may >> also help if you can). > Warning: this freezed the system immediately [all network connectivity > broke, and I had to do a quick reset]. Maybe I should have set it up > at reboot before the system was in a 'bad' shape.. Sorry for the trouble, but could you be more specific on "freeze"? Does it mean the kernel hanged (you could not type anything from the keyboard, etc)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 08:40:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E39B16A4CE for ; Wed, 29 Sep 2004 08:40:29 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFF143D3F for ; Wed, 29 Sep 2004 08:40:28 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8T8eN100718; Wed, 29 Sep 2004 11:40:23 +0300 Date: Wed, 29 Sep 2004 11:40:23 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8816) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 29 Sep 2004 08:40:29 -0000 On Wed, 29 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >> Okay. Now I think I figure out the problem. Those host routes were > >> created not deliberately, so the kernel will eventually need a fix to > >> this. > >> > >> But if you are in a hurry and/or cannot replace the kernel soon, I > >> think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with > >> this you even do not have to reboot the kernel - though rebooting may > >> also help if you can). > > > Warning: this freezed the system immediately [all network connectivity > > broke, and I had to do a quick reset]. Maybe I should have set it up > > at reboot before the system was in a 'bad' shape.. > > Sorry for the trouble, but could you be more specific on "freeze"? > Does it mean the kernel hanged (you could not type anything from the > keyboard, etc)? Unfortunately, I can't. The when my SSH session froze, and the 6to4 SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk push of reset button (because the box has no keyboard attached). Sorry for being inprecise. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 11:50:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D99BE16A4CF for ; Wed, 29 Sep 2004 11:50:52 +0000 (GMT) Received: from xout.mail.su29.ru (xout.mail.su29.ru [81.200.3.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 940A143D2F for ; Wed, 29 Sep 2004 11:50:52 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from [81.200.13.122] (helo=[192.168.28.30]) by mail.su29.ru with esmtp (Exim 4.42 (FreeBSD)) id 1CCcyx-0008Ui-AO; Wed, 29 Sep 2004 15:50:51 +0400 From: dima <_pppp@mail.ru> To: Kevin Schmidt In-Reply-To: <200409281010.02904.kps@ucsb.edu> References: <200409281010.02904.kps@ucsb.edu> Content-Type: text/plain Organization: SU29 Telecom Message-Id: <1096458648.2423.11.camel@pppp> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 29 Sep 2004 15:50:48 +0400 Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Bridging vlans w/firewall and selective HTTP redirect? 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, 29 Sep 2004 11:50:53 -0000 Would you bother reading cisco tech documentation regarding 802.1x? http://cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a008022995b.html It states you can configure guest vlan for non-authentified users; you can also temporarily disable infected users' accounts. So, I guess you should only configure your networking hardware & radius server properly. Also make a common remedy web/ftp server in the guest vlan (which would contain both 802.1x software and anti-compromise/infection information). PS: A PC wouldn't ever give you the traffic/packet rates equal to the hardware ones; especially at the layer 2. Just use the things in the tasks they were designed for. > I'm interested in placing an FBSD box (prefer 4.x since it's production, > though I've also used 5.2) inline on a link with 802.1Q-tagged vlans with > firewalling and selective HTTP redirects. Bridging a couple of ethernets > isn't a problem, and it appears I can enable ipf or ipfw (but not pf; too > bad, ALTQ and pfsync would be nice). What does not appear viable is the > interception and transparent redirect of HTTP traffic in this bridged > environment. Anyone know of a good way to do this? > > The purpose of the above is to support a wireless network where users may be > associated with various vlans, some of which will require selective traffic > filtering and transparent http redirects. For example, there might be an > SSID for a "readme" vlan network where people could log in to a web page and > download an 802.1X supplicant. The supplicant would be preconfigured to join > another SSID, e.g. "campus wireless", which would allow authenticated users > full Internet access. If a particular user is known to have a > compromised/infected system, they'd be mapped to a quanantine vlan, which > ideally would block most traffic and redirect them to a web page with > additional information and remediation tools. Similar techniques would be > used to support an https login process that would selectively open the > firewall for authenticated users. I'm sure someone reading this is > wondering, "why not do the web redirects on a routed interface instead of > with an inline bridge, since redirects at an L3 interface work?" The answer > is scalability and roaming: I'd like routing to be done at a couple of > upstream Cisco boxes, with two or more FBSD boxes inline on the downstream > vlans supporting wireless and (ultimately) some wired ports. I'll do it > routed if I must, but it would be great if I could redirect locally at the > bridge. > > I'm looking at Linux/OpenBSD/NetBSD, too, though I've always preferred FBSD > (still have my 1.x CDs) and have happily used it for DNS, web, ftp, etc. > servers for years. > > Any suggestions/comments/questions welcome. > > Cheers, From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 11:56:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C2A216A4CE; Wed, 29 Sep 2004 11:56:46 +0000 (GMT) Received: from xout.mail.su29.ru (xout.mail.su29.ru [81.200.3.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA9143D1F; Wed, 29 Sep 2004 11:56:46 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from [81.200.13.122] (helo=[192.168.28.30]) by mail.su29.ru with esmtp (Exim 4.42 (FreeBSD)) id 1CCd4f-00096x-AO; Wed, 29 Sep 2004 15:56:45 +0400 From: dima <_pppp@mail.ru> To: Leon Garde In-Reply-To: <20040929162559.P31282@localhost> References: <20040929162559.P31282@localhost> Content-Type: text/plain Organization: SU29 Telecom Message-Id: <1096459000.2423.17.camel@pppp> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 29 Sep 2004 15:56:40 +0400 Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-bugs@freebsd.org Subject: Re: IPFW and 5.2.1 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, 29 Sep 2004 11:56:46 -0000 > guass# ipfw -a list > 00001 0 0 deny ip from any to 203.222.55.37 via rl0 > 65535 1287 499525 allow ip from any to any > > guass# ping 203.222.55.37 > PING 203.222.55.37 (203.222.55.37): 56 data bytes > 64 bytes from 203.222.55.37: icmp_seq=0 ttl=255 time=0.281 ms > 64 bytes from 203.222.55.37: icmp_seq=1 ttl=255 time=0.207 ms > > < packets are flowing by rl0, despite the ipfw rule to stop them !, > rl0 being the only network interface 'connected' ) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are you sure your ping requests/replies really go via rl0? Try to use the ruleset like this: # ipfw add deny ip from any to 203.222.55.37 via rl0 # ipfw add deny ip from any to 203.222.55.37 via lo0 :) > > guass# ipfw delete 1 > > guass# ipfw add 1 deny ip from any to any > > guass# ping 203.222.55.37 > > < No answer, like u would hope> > > > Yes, I have searched archives. > > > Why does "via rl0" , "in recv rl0" , "out xmit rl0" , > (or via wi0, in recv wi0, out xmit wi0 ) > > > Is it a known bug ? > > Can't think of anything else relevant to add. > ipfw seems seriously broken in 5.2.1 ??? From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 15:24:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55D4416A4CF; Wed, 29 Sep 2004 15:24:03 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CF6743D48; Wed, 29 Sep 2004 15:23:58 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.68.250] (HELO rogue.acs.lan) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP id 58581950; Wed, 29 Sep 2004 18:16:42 +0300 Received: by rogue.acs.lan (Postfix, from userid 1000) id D8F44B833; Wed, 29 Sep 2004 18:24:03 +0300 (EAT) Date: Wed, 29 Sep 2004 18:24:03 +0300 From: Mike Makonnen To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <20040929152403.GA37746@rogue.acs.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/6.0-CURRENT (i386) Subject: Making bfe MPSAFE 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, 29 Sep 2004 15:24:03 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I've cleaned-up the bfe driver's locking. I've also fixed it up so it doesn't need a recursive mute anymore. I'm running it locally and it's working with mpsafenet=1. Please test it on your bfe nics and let me know how it goes. I would also like to here from the networking folks as to the correctness of the cleanups. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff Index: sys/dev/bfe/if_bfe.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bfe/if_bfe.c,v retrieving revision 1.16 diff -u -r1.16 if_bfe.c --- sys/dev/bfe/if_bfe.c 1 Sep 2004 06:10:11 -0000 1.16 +++ sys/dev/bfe/if_bfe.c 29 Sep 2004 08:24:53 -0000 @@ -94,8 +94,10 @@ static void bfe_release_resources (struct bfe_softc *); static void bfe_intr (void *); static void bfe_start (struct ifnet *); +static void bfe_start_locked (struct ifnet *); static int bfe_ioctl (struct ifnet *, u_long, caddr_t); static void bfe_init (void *); +static void bfe_init_locked (void *); static void bfe_stop (struct bfe_softc *); static void bfe_watchdog (struct ifnet *); static void bfe_shutdown (device_t); @@ -329,7 +331,7 @@ sc = device_get_softc(dev); mtx_init(&sc->bfe_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, - MTX_DEF | MTX_RECURSE); + MTX_DEF); unit = device_get_unit(dev); sc->bfe_dev = dev; @@ -411,7 +413,9 @@ bfe_get_config(sc); /* Reset the chip and turn on the PHY */ + BFE_LOCK(sc); bfe_chip_reset(sc); + BFE_UNLOCK(sc); if (mii_phy_probe(dev, &sc->bfe_miibus, bfe_ifmedia_upd, bfe_ifmedia_sts)) { @@ -433,7 +437,7 @@ /* * Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->bfe_irq, INTR_TYPE_NET, + error = bus_setup_intr(dev, sc->bfe_irq, INTR_TYPE_NET | INTR_MPSAFE, bfe_intr, sc, &sc->bfe_intrhand); if (error) { @@ -456,7 +460,7 @@ sc = device_get_softc(dev); KASSERT(mtx_initialized(&sc->bfe_mtx), ("bfe mutex not initialized")); - BFE_LOCK(scp); + BFE_LOCK(sc); ifp = &sc->arpcom.ac_if; @@ -674,15 +678,13 @@ { u_long reg; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); CSR_WRITE_4(sc, BFE_MIB_CTRL, BFE_MIB_CLR_ON_READ); for (reg = BFE_TX_GOOD_O; reg <= BFE_TX_PAUSE; reg += 4) CSR_READ_4(sc, reg); for (reg = BFE_RX_GOOD_O; reg <= BFE_RX_NPAUSE; reg += 4) CSR_READ_4(sc, reg); - - BFE_UNLOCK(sc); } static int @@ -690,23 +692,20 @@ { u_int32_t val; - BFE_LOCK(sc); bfe_writephy(sc, 0, BMCR_RESET); DELAY(100); bfe_readphy(sc, 0, &val); if (val & BMCR_RESET) { printf("bfe%d: PHY Reset would not complete.\n", sc->bfe_unit); - BFE_UNLOCK(sc); return (ENXIO); } - BFE_UNLOCK(sc); return (0); } static void bfe_chip_halt(struct bfe_softc *sc) { - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); /* disable interrupts - not that it actually does..*/ CSR_WRITE_4(sc, BFE_IMASK, 0); CSR_READ_4(sc, BFE_IMASK); @@ -717,8 +716,6 @@ CSR_WRITE_4(sc, BFE_DMARX_CTRL, 0); CSR_WRITE_4(sc, BFE_DMATX_CTRL, 0); DELAY(10); - - BFE_UNLOCK(sc); } static void @@ -726,7 +723,7 @@ { u_int32_t val; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); /* Set the interrupt vector for the enet core */ bfe_pci_setup(sc, BFE_INTVEC_ENET0); @@ -804,8 +801,6 @@ bfe_resetphy(sc); bfe_setupphy(sc); - - BFE_UNLOCK(sc); } static void @@ -1032,7 +1027,6 @@ { int err; - BFE_LOCK(sc); /* Clear MII ISR */ CSR_WRITE_4(sc, BFE_EMAC_ISTAT, BFE_EMAC_INT_MII); CSR_WRITE_4(sc, BFE_MDIO_DATA, (BFE_MDIO_SB_START | @@ -1043,7 +1037,6 @@ err = bfe_wait_bit(sc, BFE_EMAC_ISTAT, BFE_EMAC_INT_MII, 100, 0); *val = CSR_READ_4(sc, BFE_MDIO_DATA) & BFE_MDIO_DATA_DATA; - BFE_UNLOCK(sc); return (err); } @@ -1052,7 +1045,6 @@ { int status; - BFE_LOCK(sc); CSR_WRITE_4(sc, BFE_EMAC_ISTAT, BFE_EMAC_INT_MII); CSR_WRITE_4(sc, BFE_MDIO_DATA, (BFE_MDIO_SB_START | (BFE_MDIO_OP_WRITE << BFE_MDIO_OP_SHIFT) | @@ -1061,7 +1053,6 @@ (BFE_MDIO_TA_VALID << BFE_MDIO_TA_SHIFT) | (val & BFE_MDIO_DATA_DATA))); status = bfe_wait_bit(sc, BFE_EMAC_ISTAT, BFE_EMAC_INT_MII, 100, 0); - BFE_UNLOCK(sc); return (status); } @@ -1074,7 +1065,6 @@ bfe_setupphy(struct bfe_softc *sc) { u_int32_t val; - BFE_LOCK(sc); /* Enable activity LED */ bfe_readphy(sc, 26, &val); @@ -1085,7 +1075,6 @@ bfe_readphy(sc, 27, &val); bfe_writephy(sc, 27, val | (1 << 6)); - BFE_UNLOCK(sc); return (0); } @@ -1111,7 +1100,7 @@ struct ifnet *ifp; int i, chipidx; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); ifp = &sc->arpcom.ac_if; @@ -1141,8 +1130,6 @@ ifp->if_timer = 0; else ifp->if_timer = 5; - - BFE_UNLOCK(sc); } /* Pass a received packet up the stack */ @@ -1156,7 +1143,7 @@ int cons; u_int32_t status, current, len, flags; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); cons = sc->bfe_rx_cons; status = CSR_READ_4(sc, BFE_DMARX_STAT); current = (status & BFE_STAT_CDMASK) / sizeof(struct bfe_desc); @@ -1206,7 +1193,6 @@ BFE_INC(cons, BFE_RX_LIST_CNT); } sc->bfe_rx_cons = cons; - BFE_UNLOCK(sc); } static void @@ -1248,7 +1234,7 @@ ifp->if_ierrors++; ifp->if_flags &= ~IFF_RUNNING; - bfe_init(sc); + bfe_init_locked(sc); } /* A packet was received */ @@ -1261,7 +1247,7 @@ /* We have packets pending, fire them out */ if (ifp->if_flags & IFF_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - bfe_start(ifp); + bfe_start_locked(ifp); BFE_UNLOCK(sc); } @@ -1350,11 +1336,22 @@ } /* - * Set up to transmit a packet + * Set up to transmit a packet. */ static void bfe_start(struct ifnet *ifp) { + BFE_LOCK((struct bfe_softc *)ifp->if_softc); + bfe_start_locked(ifp); + BFE_UNLOCK((struct bfe_softc *)ifp->if_softc); +} + +/* + * Set up to transmit a packet. The softc is already locked. + */ +static void +bfe_start_locked(struct ifnet *ifp) +{ struct bfe_softc *sc; struct mbuf *m_head = NULL; int idx; @@ -1362,21 +1359,17 @@ sc = ifp->if_softc; idx = sc->bfe_tx_prod; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); /* * Not much point trying to send if the link is down * or we have nothing to send. */ - if (!sc->bfe_link && ifp->if_snd.ifq_len < 10) { - BFE_UNLOCK(sc); + if (!sc->bfe_link && ifp->if_snd.ifq_len < 10) return; - } - if (ifp->if_flags & IFF_OACTIVE) { - BFE_UNLOCK(sc); + if (ifp->if_flags & IFF_OACTIVE) return; - } while(sc->bfe_tx_ring[idx].bfe_mbuf == NULL) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); @@ -1409,21 +1402,26 @@ * Set a timeout in case the chip goes out to lunch. */ ifp->if_timer = 5; - BFE_UNLOCK(sc); } static void bfe_init(void *xsc) { + BFE_LOCK((struct bfe_softc *)xsc); + bfe_init_locked(xsc); + BFE_UNLOCK((struct bfe_softc *)xsc); +} + +static void +bfe_init_locked(void *xsc) +{ struct bfe_softc *sc = (struct bfe_softc*)xsc; struct ifnet *ifp = &sc->arpcom.ac_if; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); - if (ifp->if_flags & IFF_RUNNING) { - BFE_UNLOCK(sc); + if (ifp->if_flags & IFF_RUNNING) return; - } bfe_stop(sc); bfe_chip_reset(sc); @@ -1447,7 +1445,6 @@ ifp->if_flags &= ~IFF_OACTIVE; sc->bfe_stat_ch = timeout(bfe_tick, sc, hz); - BFE_UNLOCK(sc); } /* @@ -1461,8 +1458,6 @@ sc = ifp->if_softc; - BFE_LOCK(sc); - mii = device_get_softc(sc->bfe_miibus); sc->bfe_link = 0; if (mii->mii_instance) { @@ -1473,7 +1468,6 @@ } mii_mediachg(mii); - BFE_UNLOCK(sc); return (0); } @@ -1486,14 +1480,10 @@ struct bfe_softc *sc = ifp->if_softc; struct mii_data *mii; - BFE_LOCK(sc); - mii = device_get_softc(sc->bfe_miibus); mii_pollstat(mii); ifmr->ifm_active = mii->mii_media_active; ifmr->ifm_status = mii->mii_media_status; - - BFE_UNLOCK(sc); } static int @@ -1504,22 +1494,24 @@ struct mii_data *mii; int error = 0; - BFE_LOCK(sc); - switch(command) { case SIOCSIFFLAGS: + BFE_LOCK(sc); if(ifp->if_flags & IFF_UP) if(ifp->if_flags & IFF_RUNNING) bfe_set_rx_mode(sc); else - bfe_init(sc); + bfe_init_locked(sc); else if(ifp->if_flags & IFF_RUNNING) bfe_stop(sc); + BFE_UNLOCK(sc); break; case SIOCADDMULTI: case SIOCDELMULTI: + BFE_LOCK(sc); if(ifp->if_flags & IFF_RUNNING) bfe_set_rx_mode(sc); + BFE_UNLOCK(sc); break; case SIOCGIFMEDIA: case SIOCSIFMEDIA: @@ -1532,7 +1524,6 @@ break; } - BFE_UNLOCK(sc); return (error); } @@ -1548,7 +1539,7 @@ printf("bfe%d: watchdog timeout -- resetting\n", sc->bfe_unit); ifp->if_flags &= ~IFF_RUNNING; - bfe_init(sc); + bfe_init_locked(sc); ifp->if_oerrors++; @@ -1593,7 +1584,7 @@ { struct ifnet *ifp; - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); untimeout(bfe_tick, sc, sc->bfe_stat_ch); @@ -1604,6 +1595,4 @@ bfe_rx_ring_free(sc); ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); - - BFE_UNLOCK(sc); } Index: sys/dev/bfe/if_bfereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bfe/if_bfereg.h,v retrieving revision 1.4 diff -u -r1.4 if_bfereg.h --- sys/dev/bfe/if_bfereg.h 1 Sep 2004 06:10:11 -0000 1.4 +++ sys/dev/bfe/if_bfereg.h 28 Sep 2004 19:37:25 -0000 @@ -445,8 +445,9 @@ #define BFE_AND(sc, name, val) \ CSR_WRITE_4(sc, name, CSR_READ_4(sc, name) & val) -#define BFE_LOCK(scp) mtx_lock(&sc->bfe_mtx) -#define BFE_UNLOCK(scp) mtx_unlock(&sc->bfe_mtx) +#define BFE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->bfe_mtx, MA_OWNED) +#define BFE_LOCK(_sc) mtx_lock(&(_sc)->bfe_mtx) +#define BFE_UNLOCK(_sc) mtx_unlock(&(_sc)->bfe_mtx) #define BFE_INC(x, y) (x) = ((x) == ((y)-1)) ? 0 : (x)+1 --2fHTh5uZTiUOsy+g-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 15:31:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C95E16A4D0 for ; Wed, 29 Sep 2004 15:31:36 +0000 (GMT) Received: from smtp.ucsb.edu (ucsb.edu [128.111.24.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 479B743D1D for ; Wed, 29 Sep 2004 15:31:36 +0000 (GMT) (envelope-from kps@ucsb.edu) Received: from lsanca1-ar1-4-35-113-141.lsanca1.elnk.dsl.genuity.net ([4.35.113.141] helo=[192.168.2.192]) by smtp.ucsb.edu with asmtp TLSv1:RC4-MD5:128 id 1CCgQZ-0000Lh-Q0; Wed, 29 Sep 2004 08:31:35 -0700 From: Kevin Schmidt Organization: University of California, Santa Barbara To: dima <_pppp@mail.ru> Date: Wed, 29 Sep 2004 08:31:34 -0700 User-Agent: KMail/1.6.2 References: <200409281010.02904.kps@ucsb.edu> <1096458648.2423.11.camel@pppp> In-Reply-To: <1096458648.2423.11.camel@pppp> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409290831.34763.kps@ucsb.edu> cc: freebsd-net@freebsd.org Subject: Re: Bridging vlans w/firewall and selective HTTP redirect? 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, 29 Sep 2004 15:31:36 -0000 On Wednesday 29 September 2004 04:50, dima wrote: > Would you bother reading cisco tech documentation regarding 802.1x? I have. Would you bother dropping invalid assumptions? > http://cisco.com/en/US/products/hw/switches/ps628/products_configuration_gu >ide_chapter09186a008022995b.html It states you can configure guest vlan for > non-authentified users; you can also temporarily disable infected users' > accounts. I'm familiar with Cisco's guest-vlan capability. This is fine if you're using Cisco wireless gear, and it would make part of this exercise easier. A major objective is to implement a solution that is as vendor-independent as possible and maintains similar behavior in wired and wireless environments. There is a variety of existing non-Cisco wired equipment that is capable of 802.1x, but does not have guest-vlan support. -- Kevin Schmidt Campus Network Programmer Office of Information Technology University of California, Santa Barbara North Hall 2124 Santa Barbara, CA 93106-3201 805-893-7779 805-893-5051 FAX kps@ucsb.edu From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 17:08:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 169F116A4CE; Wed, 29 Sep 2004 17:08:52 +0000 (GMT) Received: from ms1.as.pvp.se (dns.pvp.se [213.64.187.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69A4843D48; Wed, 29 Sep 2004 17:08:51 +0000 (GMT) (envelope-from kama@pvp.se) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id 895A3B3; Wed, 29 Sep 2004 19:08:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id 87FC1B2; Wed, 29 Sep 2004 19:08:49 +0200 (CEST) Date: Wed, 29 Sep 2004 19:08:49 +0200 (CEST) From: kama X-X-Sender: kama@ns1.as.pvp.se To: "Raphael H. Becker" In-Reply-To: <20040928232841.W55054@p-i-n.com> Message-ID: <20040929185852.C9118@ns1.as.pvp.se> References: <20040917104356.E55054@p-i-n.com> <414ADD15.FAC42CDB@freebsd.org> <20040917231922.G55054@p-i-n.com> <414B567C.9060904@freebsd.org> <20040917235056.I55054@p-i-n.com> <414B6234.8060904@freebsd.org> <20040918011644.N55054@p-i-n.com> <20040928232841.W55054@p-i-n.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: if_bge with (was: Re: Strange things on GBit / 1000->100 / net.inet.tcp.inflight.* ) 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, 29 Sep 2004 17:08:52 -0000 On Tue, 28 Sep 2004, Raphael H. Becker wrote: > Hmm. if_bge buggy? > But, same machine on a FE-Switich worked perfectly (with 100MBit). > > By default ifconfig says: > > bge0: flags=8843 mtu 1500 > options=1a > inet 10.101.240.56 netmask 0xffffff00 broadcast 10.101.240.255 > inet6 fe80::20d:56ff:febb:9c27%bge0 prefixlen 64 scopeid 0x1 > ether 00:0d:56:bb:9c:27 > media: Ethernet autoselect (1000baseTX ) > status: active > If the switch is manageable. Force the settings to 1000baseTX fd on both ends. I only have a crappy non manageable 1Gbps switch, so I tested to link the two servers with a crossed linked cable instead of through the switch. I now seems to have no noticable problems with the cards. If I connect it to the switch I get that link goes down and up all the time. It seems that it cant stop negotiating for the speed and update the settings all the time. Btw, I have the bge patch, posted earlier this month, installed. This happens on both 5.2.1p10 and BETA6. with or without the patch. /Bjorn From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 18:50:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AEE116A4D0 for ; Wed, 29 Sep 2004 18:50:03 +0000 (GMT) Received: from variant6.bg (cable-provisioning.variant6.bg [213.91.180.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F14243D46 for ; Wed, 29 Sep 2004 18:50:02 +0000 (GMT) (envelope-from kalin@variant6.bg) Received: (qmail 74399 invoked by uid 0); 29 Sep 2004 18:50:19 -0000 Received: from kalin@variant6.bg by variant6.bg by uid 83 with qmail-scanner-1.16 (f-prot: 3.12. Clear:. Processed in 0.339527 secs); 29 Sep 2004 18:50:19 -0000 Received: from noc.variant6.bg (213.91.180.26) by pns.variant6.bg with SMTP; 29 Sep 2004 18:50:18 -0000 Date: Wed, 29 Sep 2004 22:05:21 +0300 (EEST) From: Kalin Hristov X-X-Sender: kalin@Stealth To: freebsd-net@freebsd.org Message-ID: <20040929220455.F39395@Stealth> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FreBSD & MPLS stack (fwd) 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, 29 Sep 2004 18:50:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It would be very nice As they say about the MPLS "The feature of the Internet" -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBQVsHc2cb2v9P9sWHEQJxQgCglXvPzlF6R9Ev7pKzM+p7QW35SIgAnAmV uJxBcDZODDPamn2C6230+cO8 =jyFP -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 20:57:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AB5716A4CE for ; Wed, 29 Sep 2004 20:57:13 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04BBA43D2F for ; Wed, 29 Sep 2004 20:57:12 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id i8TKv98h021408; Wed, 29 Sep 2004 23:57:10 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <415B21A6.4020205@he.iki.fi> Date: Wed, 29 Sep 2004 23:57:10 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalin Hristov References: <20040929220455.F39395@Stealth> In-Reply-To: <20040929220455.F39395@Stealth> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FreBSD & MPLS stack (fwd) 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, 29 Sep 2004 20:57:13 -0000 Kalin Hristov wrote: > >It would be very nice >As they say about the MPLS "The feature of the Internet" > > > Did they change the acronym from "Mostly Pointless Lamp Switching"? Pete From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 23:59:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 852AC16A4CE for ; Wed, 29 Sep 2004 23:59:25 +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 2CE1343D45 for ; Wed, 29 Sep 2004 23:59:25 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C21921525D; Thu, 30 Sep 2004 08:59:22 +0900 (JST) Date: Thu, 30 Sep 2004 08:59:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: 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: (KAME-snap 8818) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 29 Sep 2004 23:59:25 -0000 >>>>> On Wed, 29 Sep 2004 11:40:23 +0300 (EEST), >>>>> Pekka Savola said: >> >> Okay. Now I think I figure out the problem. Those host routes were >> >> created not deliberately, so the kernel will eventually need a fix to >> >> this. >> >> >> >> But if you are in a hurry and/or cannot replace the kernel soon, I >> >> think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with >> >> this you even do not have to reboot the kernel - though rebooting may >> >> also help if you can). >> >> > Warning: this freezed the system immediately [all network connectivity >> > broke, and I had to do a quick reset]. Maybe I should have set it up >> > at reboot before the system was in a 'bad' shape.. >> >> Sorry for the trouble, but could you be more specific on "freeze"? >> Does it mean the kernel hanged (you could not type anything from the >> keyboard, etc)? > Unfortunately, I can't. The when my SSH session froze, and the 6to4 > SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk > push of reset button (because the box has no keyboard attached). Sorry > for being inprecise. Okay, I just found a bug that only happens when ip6.rtexpire is 0. Please try the following patch (with rtexpire=0). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Index: in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.1.2.3 diff -u -r1.1.2.3 in6_rmx.c --- in6_rmx.c 28 Apr 2002 05:40:27 -0000 1.1.2.3 +++ in6_rmx.c 29 Sep 2004 23:57:07 -0000 @@ -270,10 +270,16 @@ rt->rt_flags |= RTPRF_OURS; rt->rt_rmx.rmx_expire = time_second + rtq_reallyold; } else { + struct rtentry *dummy; + + /* + * rtrequest() would recursively call rtfree() without the + * dummy entry argument, causing duplicated free. + */ rtrequest(RTM_DELETE, (struct sockaddr *)rt_key(rt), rt->rt_gateway, rt_mask(rt), - rt->rt_flags, 0); + rt->rt_flags, &dummy); } } From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 09:04:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47B1816A4CE for ; Thu, 30 Sep 2004 09:04:27 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 580B743D39 for ; Thu, 30 Sep 2004 09:04:26 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8U945n02861; Thu, 30 Sep 2004 12:04:08 +0300 Date: Thu, 30 Sep 2004 12:04:05 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8820) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 30 Sep 2004 09:04:27 -0000 On Thu, 30 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > > Unfortunately, I can't. The when my SSH session froze, and the 6to4 > > SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk > > push of reset button (because the box has no keyboard attached). Sorry > > for being inprecise. > > Okay, I just found a bug that only happens when ip6.rtexpire is 0. > Please try the following patch (with rtexpire=0). Well, the box no longer crashed at least, so I'd guess it works. :-) Btw, is there any particular reason why net.inet.ip.rtexpire automatically dynamically re-adjusts itself (here, it's typically around 10 or 12), while net.inet6.ip6.rtexpire does not? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 09:18:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D8D216A4CE; Thu, 30 Sep 2004 09:18:14 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD8D43D2F; Thu, 30 Sep 2004 09:18:14 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 433415C8E6; Thu, 30 Sep 2004 02:18:14 -0700 (PDT) Date: Thu, 30 Sep 2004 02:18:14 -0700 From: Alfred Perlstein To: alc@freebsd.org Message-ID: <20040930091814.GG39252@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: net@freebsd.org Subject: aio patch for review. 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, 30 Sep 2004 09:18:14 -0000 properly cover the socket buffer for operations that need locking. please review. Index: vfs_aio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_aio.c,v retrieving revision 1.176 diff -u -r1.176 vfs_aio.c --- vfs_aio.c 23 Sep 2004 14:45:04 -0000 1.176 +++ vfs_aio.c 30 Sep 2004 09:15:10 -0000 @@ -1297,6 +1297,7 @@ struct kevent kev; struct kqueue *kq; struct file *kq_fp; + struct sockbuf *sb; aiocbe = uma_zalloc(aiocb_zone, M_WAITOK); aiocbe->inputcharge = 0; @@ -1451,29 +1452,28 @@ * If it is not ready for io, then queue the aiocbe on the * socket, and set the flags so we get a call when sbnotify() * happens. + * + * Note if opcode is neither LIO_WRITE nor LIO_READ we lock + * and unlock the snd sockbuf for no reason. */ so = fp->f_data; + sb = (opcode == LIO_READ) ? &so->so_rcv : &so->so_snd; + SOCKBUF_LOCK(sb); s = splnet(); if (((opcode == LIO_READ) && (!soreadable(so))) || ((opcode == LIO_WRITE) && (!sowriteable(so)))) { TAILQ_INSERT_TAIL(&so->so_aiojobq, aiocbe, list); TAILQ_INSERT_TAIL(&ki->kaio_sockqueue, aiocbe, plist); - if (opcode == LIO_READ) { - SOCKBUF_LOCK(&so->so_rcv); - so->so_rcv.sb_flags |= SB_AIO; - SOCKBUF_UNLOCK(&so->so_rcv); - } else { - SOCKBUF_LOCK(&so->so_snd); - so->so_snd.sb_flags |= SB_AIO; - SOCKBUF_UNLOCK(&so->so_snd); - } + sb->sb_flags |= SB_AIO; aiocbe->jobstate = JOBST_JOBQGLOBAL; /* XXX */ ki->kaio_queue_count++; num_queue_count++; + SOCKBUF_UNLOCK(sb); splx(s); error = 0; goto done; } + SOCKBUF_UNLOCK(sb); splx(s); } -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 15:31:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3984716A4CE for ; Thu, 30 Sep 2004 15:31:25 +0000 (GMT) Received: from web14826.mail.yahoo.com (web14826.mail.yahoo.com [216.136.225.197]) by mx1.FreeBSD.org (Postfix) with SMTP id D4D2343D48 for ; Thu, 30 Sep 2004 15:31:24 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20040930153124.59272.qmail@web14826.mail.yahoo.com> Received: from [212.143.154.227] by web14826.mail.yahoo.com via HTTP; Thu, 30 Sep 2004 08:31:24 PDT Date: Thu, 30 Sep 2004 08:31:24 -0700 (PDT) From: Rostislav Krasny To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: default resolver(5) configuration and behavior of functions like gethostbyname(3) 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, 30 Sep 2004 15:31:25 -0000 Hello all. Please consider following two questions: 1. According to the resolver(5) manual page the default number of times the resolver will send a query to each of its name servers is defined as RES_DFLRETRY in resolv.h standard header file. Actually there was no RES_DFLRETRY in the resolv.h before following commits to HEAD made by Yar Tikhiy: http://docs.freebsd.org/cgi/mid.cgi?200409091739.i89HdlwM019548 http://docs.freebsd.org/cgi/mid.cgi?200409091742.i89HgIan019681 http://docs.freebsd.org/cgi/mid.cgi?200409091719.i89HJRGu019026 This default number of retries (the RES_DFLRETRY macro in the HEAD and a hardcoded constant value in 5.x) is 4. But in most of other UNIX or UNIX-like systems (Solaris, AIX, Linux, NetBSD) this default value is 2. Only in OpenBSD it is 4 and also it is a hardcoded constant there. Please explain why developers of FreeBSD had chose 4 instead of 2? Maybe they should change it to 2, as this default value is defined on most of other systems, including NetBSD? 2. Please consider following experimets I did on FreeBSD 5.3-BETA2-BETA6: I changed the /etc/resolv.conf so it had only one following line: nameserver 21.21.21.21 21.21.21.21 is just some black-hole host without any working DNS on it. Then I ran 'tcpdump -nvi ed1' on one pseudo terminal and 'ping yahoo.com' on other pseudo terminal. This way I counted the "A? yahoo.com." DNS queries before ping(8) returned an error. With this configuration there were 8 "A? yahoo.com." DNS queries. Then I added following line to the /etc/resolv.conf options attempts:1 With this configuration there were 2 "A? yahoo.com." DNS queries. With "attempts:2" there were 4 "A? yahoo.com." DNS queries, with "attempts:3" there were 6 "A? yahoo.com." DNS queries, with "attempts:5" there were 10 "A? yahoo.com." DNS queries and so on. I repeated this experiment with following program been used instead of the ping(8): #include #include #include #include #include #include int main(void) { const char *name="yahoo.com"; struct hostent *ps_hostent; char **st; ps_hostent=gethostbyname(name); if (ps_hostent!=NULL) { printf("%s\n", ps_hostent->h_name); for (st=ps_hostent->h_addr_list; *st!=NULL; st++) { printf("%s\n", inet_ntoa(*(struct in_addr *)*st)); } if (st==ps_hostent->h_addr_list) fputs("It have no address.\n", stderr); } else { herror(name); } return 0; } The results where exactly the same. Why the number of DNS queries is always doubled? With default resolver(5) configuration there are 8 DNS queries to one non-working DNS server and it takes 2:30 minutes before an error returned. IMHO this is too much time and too much queries for default resolver(5) configuration. Who and why is doubling the number of DNS queries? Is it gethostbyname(3) function or the resolver itself? _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 18:17:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB78716A4CF for ; Thu, 30 Sep 2004 18:17:11 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B6343D46 for ; Thu, 30 Sep 2004 18:17:08 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 34269 invoked from network); 30 Sep 2004 18:09:41 -0000 Received: from unknown (HELO networx.ch) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Sep 2004 18:09:41 -0000 Message-ID: <415C4DB3.1042A076@networx.ch> Date: Thu, 30 Sep 2004 20:17:23 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Raphael H. Becker" References: <20040917104356.E55054@p-i-n.com> <414ADD15.FAC42CDB@freebsd.org> <20040917231922.G55054@p-i-n.com> <414B567C.9060904@freebsd.org> <20040917235056.I55054@p-i-n.com> <414B6234.8060904@freebsd.org> <20040918011644.N55054@p-i-n.com> <20040928232841.W55054@p-i-n.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: if_bge with (was: Re: Strange things on GBit / 1000->100 /net.inet.tcp.inflight.* ) 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, 30 Sep 2004 18:17:12 -0000 "Raphael H. Becker" wrote: > > On Sat, Sep 18, 2004 at 01:16:44AM +0200, Raphael H. Becker wrote: > > On Sat, Sep 18, 2004 at 12:16:20AM +0200, Andre Oppermann wrote: > > > Would you mind trying a 5.3 to 5.3 transfer but the target 5.3 box forced to > > > only 100Mbit full-duplex? Same statistics again. > > > > Sorry, ifconfig is not possible now. See PM. > > I may retest with physical access (without ssh) next days, if needed. > > Today I had some time for testing AND physical access ... > > With bge0 bound to 100baseTX / full-duplex the transfer breaks down to > <100kBytes/sec, with 1000byseTX its about 250-350kBytes/sec, should be > ~10MBytes/sec > > ifconfig bge0 down > ifconfig bge0 media ... > ifconfig bge0 up > > I will do some more and detailed testing next time I'm in our data > center, including the netstat-output etc. > > Hmm. if_bge buggy? > But, same machine on a FE-Switich worked perfectly (with 100MBit). -snip- > Any idea? Could you do a transfer of about 5MB and capture the entire TCP session with tcpdump on the source *and* target machine at the same time? I'll have a look at it to find out why TCP is unable to open the window. tcpdump -n -i bge0 -p -w dump_source "tcp host 1.2.3.4" And then make the two files available somewhere I can download them. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 20:45:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC2E16A4D0 for ; Thu, 30 Sep 2004 20:45:05 +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 8156343D3F for ; Thu, 30 Sep 2004 20:45:04 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7677F1525D; Fri, 1 Oct 2004 05:45:01 +0900 (JST) Date: Fri, 01 Oct 2004 05:45:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: 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 cc: snap-users@kame.net Subject: Re: (KAME-snap 8820) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 30 Sep 2004 20:45:05 -0000 >>>>> On Thu, 30 Sep 2004 12:04:05 +0300 (EEST), >>>>> Pekka Savola said: >> > Unfortunately, I can't. The when my SSH session froze, and the 6to4 >> > SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk >> > push of reset button (because the box has no keyboard attached). Sorry >> > for being inprecise. >> >> Okay, I just found a bug that only happens when ip6.rtexpire is 0. >> Please try the following patch (with rtexpire=0). > Well, the box no longer crashed at least, so I'd guess it works. :-) Glad to hear that. > Btw, is there any particular reason why net.inet.ip.rtexpire > automatically dynamically re-adjusts itself (here, it's typically > around 10 or 12), while net.inet6.ip6.rtexpire does not? Hmm, good point. I was also wondering why such a massive number of route entries remained despite the periodical cleanup mechanism. Then I found another bug, which set the cleanup interval to a huge value (almost infinite in a practical sense). The patch below, including the previous fix, should also solve the problem (I must confess I even did not compile it, so please be careful). Perhaps you can then live with the original rtexpire value. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Index: in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.1.2.3 diff -u -r1.1.2.3 in6_rmx.c --- in6_rmx.c 28 Apr 2002 05:40:27 -0000 1.1.2.3 +++ in6_rmx.c 30 Sep 2004 20:40:14 -0000 @@ -270,10 +270,16 @@ rt->rt_flags |= RTPRF_OURS; rt->rt_rmx.rmx_expire = time_second + rtq_reallyold; } else { + struct rtentry *dummy; + + /* + * rtrequest() would recursively call rtfree() without the + * dummy entry argument, causing duplicated free. + */ rtrequest(RTM_DELETE, (struct sockaddr *)rt_key(rt), rt->rt_gateway, rt_mask(rt), - rt->rt_flags, 0); + rt->rt_flags, &dummy); } } @@ -379,7 +385,7 @@ } atv.tv_usec = 0; - atv.tv_sec = arg.nextstop; + atv.tv_sec = arg.nextstop - time_second; timeout(in6_rtqtimo, rock, tvtohz(&atv)); } From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 00:43:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4E9916A4CE for ; Fri, 1 Oct 2004 00:43:15 +0000 (GMT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF1D543D1D for ; Fri, 1 Oct 2004 00:43:15 +0000 (GMT) (envelope-from Andrew.Zhu@hp.com) Received: from tsx2.cup.hp.com (tsx2.cup.hp.com [15.13.185.29]) by palrel13.hp.com (Postfix) with ESMTP id 8D1741C05EAD for ; Thu, 30 Sep 2004 17:43:15 -0700 (PDT) Received: from AZ735044 (az730541.cup.hp.com [15.13.105.111]) by tsx2.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with SMTP id RAA20744 for ; Thu, 30 Sep 2004 17:43:15 -0700 (PDT) From: "Andrew Wenlang Zhu" To: Date: Thu, 30 Sep 2004 17:43:11 -0700 Message-ID: <01ae01c4a74f$a12fb5d0$6f690d0f@americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Subject: How to use FreeBSD/Dummynet to fragment IP packets 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, 01 Oct 2004 00:43:15 -0000 Hello: I use a freebsd system running Dummynet as a middle box to test network behavior. The setup likes this: System A ------------- FreeBSD with Dummynet ------------ System B Network traffic flows between System A and B, and the traffic is a mix of TCP, UDP and ICMP. I need the Dummynet system to fragment IP packet to a specified packet size. It is OK that all traffic get fragmented, but even it is better if I can specify a certain percentage of packet to be fragmented. I looked into Dummynet man page, but cannot find how to do packet fragmentation. Does any one know how to use Dummynet to fragment packet? Or any other open source software can achieve this? Thanks, Andrew From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:19:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2389D16A4CE; Fri, 1 Oct 2004 04:19:22 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5B5F43D31; Fri, 1 Oct 2004 04:19:21 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 1B6964A9F7; Thu, 30 Sep 2004 23:19:21 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 19570-01-36; Thu, 30 Sep 2004 23:19:19 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 363E64A9F6; Thu, 30 Sep 2004 23:19:19 -0500 (CDT) Date: Thu, 30 Sep 2004 23:19:19 -0500 From: Alan Cox To: Alfred Perlstein Message-ID: <20041001041919.GC16408@cs.rice.edu> References: <20040930091814.GG39252@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930091814.GG39252@elvis.mu.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: alc@freebsd.org cc: net@freebsd.org Subject: Re: aio patch for review. 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, 01 Oct 2004 04:19:22 -0000 On Thu, Sep 30, 2004 at 02:18:14AM -0700, Alfred Perlstein wrote: > properly cover the socket buffer for operations that need locking. > Just to be clear, your point is that soreadable() and sowriteable() should be performed with the corresponding socket buffer locked. Correct? If so, yes, please go ahead and commit it. Alan From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:39:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBC4116A4CE; Fri, 1 Oct 2004 04:39:28 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E8B43D31; Fri, 1 Oct 2004 04:39:28 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BCF5F5C90F; Thu, 30 Sep 2004 21:39:28 -0700 (PDT) Date: Thu, 30 Sep 2004 21:39:28 -0700 From: Alfred Perlstein To: Alan Cox Message-ID: <20041001043928.GN39252@elvis.mu.org> References: <20040930091814.GG39252@elvis.mu.org> <20041001041919.GC16408@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041001041919.GC16408@cs.rice.edu> User-Agent: Mutt/1.4.2.1i cc: alc@freebsd.org cc: net@freebsd.org Subject: Re: aio patch for review. 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, 01 Oct 2004 04:39:29 -0000 * Alan Cox [040930 21:19] wrote: > On Thu, Sep 30, 2004 at 02:18:14AM -0700, Alfred Perlstein wrote: > > properly cover the socket buffer for operations that need locking. > > > > Just to be clear, your point is that soreadable() and sowriteable() > should be performed with the corresponding socket buffer locked. > Correct? If so, yes, please go ahead and commit it. Yup. thank you, -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:47:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE98216A4CE for ; Fri, 1 Oct 2004 04:47:00 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5E36E43D3F for ; Fri, 1 Oct 2004 04:47:00 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 31565 invoked from network); 1 Oct 2004 04:46:58 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Oct 2004 04:46:58 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 30 Sep 2004 23:46:58 -0500 (CDT) From: Mike Silbersack To: Andrew Wenlang Zhu In-Reply-To: <01ae01c4a74f$a12fb5d0$6f690d0f@americas.hpqcorp.net> Message-ID: <20040930234627.B1375@odysseus.silby.com> References: <01ae01c4a74f$a12fb5d0$6f690d0f@americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: How to use FreeBSD/Dummynet to fragment IP packets 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, 01 Oct 2004 04:47:01 -0000 On Thu, 30 Sep 2004, Andrew Wenlang Zhu wrote: > Does any one know how to use Dummynet to fragment packet? Or any other open > source software can achieve this? > > Thanks, > > Andrew I don't think that dummynet can fragment packets. The program you're looking for is fragrouter, I think it's in ports. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 05:43:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD4316A4CF for ; Fri, 1 Oct 2004 05:43:46 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 99F9043D48 for ; Fri, 1 Oct 2004 05:43:46 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 94253 invoked by uid 113); 30 Sep 2004 22:43:46 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 1.59693 secs); 01 Oct 2004 05:43:46 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 30 Sep 2004 22:43:44 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Fri, 1 Oct 2004 05:43:42 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410010543.42789.miha@ghuug.org> cc: freebsd-isp@freebsd.org Subject: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 05:43:47 -0000 Hello FreeBSD Users, I have been playing with OpenVPN for a while, and have successfully configured pretty simple tunnel between local router (FreeBSD, which NATs LAN into inet) and remote host. Now my next target is to route some of the computers in the LAN into above VPN tunnel - that's where I'm stuck. Here's my detailed setup (should be pretty basic and regular): HOST_A: FreeBSD, serves as gateway (NAT) for LAN (192.168.0.0/24) has two NICs: rl0 - internal (192.168.0.1) rl1 - external (connected to DSL modem), runs natd (natd -n rl1) net.inet.ip.forwarding=1 openvpn from ports HOST_B: FreeBSD, remote host, single NIC, public IP. net.inet.ip.forwarding=1 openvpn from ports What has been done so far - I have configured OpenVPN between HOST_A and HOST_B. As in tunnel, HOST_A has ip of 192.168.10.1 and HOST_B has 192.168.10.2, so basically there is P-t-P link over tun0 on each side. I should probably note that HOST_B has no public ip, as it sees inet via DSL modem (which is also most likely NAT'ed by ISP). All is great, and both parties can ping each other via tun0 iface. Now, as noted above, I want to route some of computers in 192.168.0.0/24 into this tunnel, so basically they go internet via HOST_B as the end point. My attempts to play with route never ended well, so I thought of natd on tun0 on HOST_B. I ran into small problem where I can't run more than one instance of natd, but it has been quickly solved by searching google database, so I ended up running natd on tun0 of HOST_B as: natd -interface rl1 natd -port 8568 -interface tun0 As mentioned above, there is already natd on rl1, and thus I have the following rules (the only rules in ipfw) in ipfw: 10 divert 8668 ip from 192.168.0.0/24 to any out xmit rl1 12 divert 8668 ip from any to 192.168.254.1 in recv rl1 (192.168.254.1 is the IP given by DSL modem via DHCP) Next (well, they are actually before these rules) two rules I added into ipfw ipfw add 4 divert 8568 ip from 192.168.0.3 to any out xmit tun0 ipfw add 6 divert 8568 ip from any to any in recv tun0 So basically, this supposed to give me the following picture: 192.168.0.3 travels to "any" via tun0. That picture, however, does not work in real life, and that's why I'm posting here for advise of more experienced users. I can ping "192.168.10.1" (which is HOST_A, remote host) from 192.168.0.3, and packets travel via tun0 with src/dst addresses overwritten by natd. However, if I try to ping any other host on the internet from 192.168.0.3, packets travel via natd on rl1 (I found that using tcpdump), and not via tun0 - that's my major confusion right now. There are no blocking ipfw rules - the only 4 rules sitting in ipfw are those divert rules. I have been pulling hair off my poor head for few hours on this issue, but did not come to solution, so I'm looking for advises. kind regards, M. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 06:41:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8DF616A4CF for ; Fri, 1 Oct 2004 06:41:24 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC46B43D2F for ; Fri, 1 Oct 2004 06:41:23 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i916fII01525; Fri, 1 Oct 2004 09:41:18 +0300 Date: Fri, 1 Oct 2004 09:41:18 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8822) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE 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, 01 Oct 2004 06:41:25 -0000 On Fri, 1 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > > Btw, is there any particular reason why net.inet.ip.rtexpire > > automatically dynamically re-adjusts itself (here, it's typically > > around 10 or 12), while net.inet6.ip6.rtexpire does not? > > Hmm, good point. I was also wondering why such a massive number of > route entries remained despite the periodical cleanup mechanism. Then > I found another bug, which set the cleanup interval to a huge value > (almost infinite in a practical sense). > > The patch below, including the previous fix, should also solve the > problem (I must confess I even did not compile it, so please be > careful). Perhaps you can then live with the original rtexpire value. Thanks. Yes, now both rtexpire values are dynamically automatically adjusting appropriately. Whether this fixes the root cause of the problem or not is another issue, but I guess it works around it for now. We'll see in a week or two, I guess.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 06:52:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A17E16A4CE; Fri, 1 Oct 2004 06:52:02 +0000 (GMT) Received: from asum.kodu.ee (asum.kodu.ee [212.27.241.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1321743D2F; Fri, 1 Oct 2004 06:52:01 +0000 (GMT) (envelope-from juhani@kernel.ee) Received: from [192.168.1.9] (panic.kernel.ee [212.27.241.3]) by asum.kodu.ee (8.12.9p2/8.12.8) with ESMTP id i916pvNC091419; Fri, 1 Oct 2004 09:51:58 +0300 (EEST) (envelope-from juhani@kernel.ee) Message-ID: <415CFE85.8040005@kernel.ee> Date: Fri, 01 Oct 2004 09:51:49 +0300 From: Juhani Tali User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040824) X-Accept-Language: en-us, en MIME-Version: 1.0 To: miha@ghuug.org References: <200410010543.42789.miha@ghuug.org> In-Reply-To: <200410010543.42789.miha@ghuug.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: confusion with natd 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, 01 Oct 2004 06:52:02 -0000 Mikhail P. wrote: > HOST_A: > FreeBSD, serves as gateway (NAT) for LAN (192.168.0.0/24) > has two NICs: > rl0 - internal (192.168.0.1) > rl1 - external (connected to DSL modem), runs natd (natd -n rl1) > net.inet.ip.forwarding=1 > openvpn from ports > > HOST_B: > FreeBSD, remote host, single NIC, public IP. > net.inet.ip.forwarding=1 > openvpn from ports I would set it up like so: This one in host B > natd -interface rl1 And this in host A > natd -port 8568 -interface tun0 You need to translate all the 192.168.0.x to tunnel's address and you cannot do it in host B, because it has no direct connection to 192.168.0.x. Another solution is with routing, so host B has direct access to the 192.168.0.x network. > I have been pulling hair off my poor head for few hours on this issue, but did > not come to solution, so I'm looking for advises. Juhani Tali From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 07:11:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AF6416A4CF for ; Fri, 1 Oct 2004 07:11:31 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 402D643D1F for ; Fri, 1 Oct 2004 07:11:31 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 64636 invoked by uid 113); 1 Oct 2004 00:11:29 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 1.545129 secs); 01 Oct 2004 07:11:29 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 1 Oct 2004 00:11:27 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: Juhani Tali Date: Fri, 1 Oct 2004 07:11:24 +0000 User-Agent: KMail/1.7 References: <200410010543.42789.miha@ghuug.org> <415CFE85.8040005@kernel.ee> In-Reply-To: <415CFE85.8040005@kernel.ee> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410010711.24829.miha@ghuug.org> cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 07:11:31 -0000 On Friday 01 October 2004 06:51, Juhani Tali wrote: > I would set it up like so: > > This one in host B > > > natd -interface rl1 > > And this in host A > > > natd -port 8568 -interface tun0 > > You need to translate all the 192.168.0.x to tunnel's address and you > cannot do it in host B, because it has no direct connection to 192.168.0.x. Did not quite understand what you meant here. I can translate 192.168.0.0/24 into tunnel, but as my original message states, only packets to HOST_A fall into that route, any other packets (even ipfw has "ip from 192.168.0.3 to any") travel out regular way (not via tun0). That's the most confusing part ("any != "any"), and I'm stuck there. HOST_B (which is seen as "192.168.0.1" to LAN) has direct connection to 192.168.0.x, and basically it acts as a gateway for 192.168.0.x, so I dance from there. > Another solution is with routing, so host B has direct access to the > 192.168.0.x network. Tried that already as - on HOST_A (remote host) - route add 192.168.0.0/24 192.168.10.2 After that, I can ping 192.168.0.x directly (no NAT) from remote VPN host and backwards. This, however, does not change anything apart from giving me direct access to "HOST_A <<-->> 192.168.0.0/24". > > > I have been pulling hair off my poor head for few hours on this issue, > > but did not come to solution, so I'm looking for advises. > > Juhani Tali regards, M. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 07:27:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8EFA16A4CE for ; Fri, 1 Oct 2004 07:27:31 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 022D143D1D for ; Fri, 1 Oct 2004 07:27:31 +0000 (GMT) (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 i917RSFQ050321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 11:27:28 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i917RRIh050320; Fri, 1 Oct 2004 11:27:27 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 1 Oct 2004 11:27:27 +0400 From: Gleb Smirnoff To: Kalin Hristov Message-ID: <20041001072727.GD49512@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Kalin Hristov , freebsd-net@freebsd.org References: <20040929220455.F39395@Stealth> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040929220455.F39395@Stealth> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FreBSD & MPLS stack (fwd) 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, 01 Oct 2004 07:27:31 -0000 On Wed, Sep 29, 2004 at 10:05:21PM +0300, Kalin Hristov wrote: K> It would be very nice K> As they say about the MPLS "The feature of the Internet" This is a very big piece of work to be done. In my humble opinion it would be at least one year of full time work for a couple of developers. It also require a number of testers and some hardware for reference testing. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 07:38:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEF1A16A4CE; Fri, 1 Oct 2004 07:38:46 +0000 (GMT) Received: from asum.kodu.ee (asum.kodu.ee [212.27.241.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21A1643D1D; Fri, 1 Oct 2004 07:38:46 +0000 (GMT) (envelope-from juhani@kernel.ee) Received: from [192.168.1.9] (panic.kernel.ee [212.27.241.3]) by asum.kodu.ee (8.12.9p2/8.12.8) with ESMTP id i917cdNC095520; Fri, 1 Oct 2004 10:38:40 +0300 (EEST) (envelope-from juhani@kernel.ee) Message-ID: <415D0977.4000006@kernel.ee> Date: Fri, 01 Oct 2004 10:38:31 +0300 From: Juhani Tali User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040824) X-Accept-Language: en-us, en MIME-Version: 1.0 To: miha@ghuug.org References: <200410010543.42789.miha@ghuug.org> <415CFE85.8040005@kernel.ee> <200410010711.24829.miha@ghuug.org> In-Reply-To: <200410010711.24829.miha@ghuug.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: confusion with natd 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, 01 Oct 2004 07:38:46 -0000 Mikhail P. wrote: > On Friday 01 October 2004 06:51, Juhani Tali wrote: > > Did not quite understand what you meant here. ---- ended up running natd on tun0 of HOST_B as: natd -interface rl1 natd -port 8568 -interface tun0 ---- I should have read it as HOST_A, because HOST_B does not have a rl1, only rl0. ---- ipfw add 4 divert 8568 ip from 192.168.0.3 to any out xmit tun0 ipfw add 6 divert 8568 ip from any to any in recv tun0 ---- replace these with ipfw add 4 divert 8568 ip from 192.168.0.3 to any prior to this rule the packet was not destined to go out through tun0 but rl1, so the (xmit tun0) condition does not match. ipfw add 6 divert 8568 ip from any to any in recv tun0 or perhaps ipfw add 6 divert 8568 ip from any to 192.168.10.1 > I can translate 192.168.0.0/24 > into tunnel, but as my original message states, only packets to HOST_A fall > into that route, any other packets (even ipfw has "ip from 192.168.0.3 to > any") travel out regular way (not via tun0). That's the most confusing part > ("any != "any"), and I'm stuck there. Hope this works. Juhani Tali From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 08:14:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2519A16A4CE for ; Fri, 1 Oct 2004 08:14:56 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6680543D53 for ; Fri, 1 Oct 2004 08:14:55 +0000 (GMT) (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 i918ErCj050596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Oct 2004 12:14:54 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i918ErQp050595 for net@freebsd.org; Fri, 1 Oct 2004 12:14:53 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 1 Oct 2004 12:14:53 +0400 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20041001081453.GE49512@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: [TEST/REVIEW] bridge(4) and ng_ether(4) interaction 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, 01 Oct 2004 08:14:56 -0000 This patch is intended to fix interoperation between bridge(4) and ng_ether(4). The problem is described in this message: http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html I hope that some CURRENT bridge users will help me testing it. After applying patch you need to: # kldload netgraph.ko # kldload ng_socket.ko # kldload ng_ether.ko # kldload ng_tee.ko .. and do the following for all your bridged interfaces: # ngctl mkpeer fxp0: tee lower right # ngctl connect fxp0: fxp0:lower upper left where fxp0 stands for interface name. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 08:17:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAED616A4CE for ; Fri, 1 Oct 2004 08:17:00 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21DBB43D3F for ; Fri, 1 Oct 2004 08:17:00 +0000 (GMT) (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 i918Gwf4050639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Oct 2004 12:16:59 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i918GwQd050638 for net@freebsd.org; Fri, 1 Oct 2004 12:16:58 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 1 Oct 2004 12:16:58 +0400 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20041001081658.GF49512@cell.sick.ru> References: <20041001081453.GE49512@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20041001081453.GE49512@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Re: [TEST/REVIEW] bridge(4) and ng_ether(4) interaction 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, 01 Oct 2004 08:17:01 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Fri, Oct 01, 2004 at 12:14:53PM +0400, Gleb Smirnoff wrote: T> This patch is intended to fix interoperation and the patch is in this message. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_ether+bridge.patch2" Index: netgraph/ng_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v retrieving revision 1.38 diff -u -r1.38 ng_ether.c --- netgraph/ng_ether.c 28 Jul 2004 06:54:55 -0000 1.38 +++ netgraph/ng_ether.c 6 Sep 2004 22:07:20 -0000 @@ -53,6 +53,7 @@ #include #include +#include #include #include #include @@ -552,6 +553,10 @@ m->m_pkthdr.rcvif = priv->ifp; + if (BDG_ACTIVE(priv->ifp) ) + if ((m = bridge_in_ptr(priv->ifp, m)) == NULL) + return (0); + /* Route packet back in */ ether_demux(priv->ifp, m); return (0); Index: net/bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.c,v retrieving revision 1.83 diff -u -r1.83 bridge.c --- net/bridge.c 27 Aug 2004 15:16:22 -0000 1.83 +++ net/bridge.c 6 Sep 2004 22:16:38 -0000 @@ -240,6 +240,7 @@ static int bdginit(void); static void parse_bdg_cfg(void); +static struct mbuf *bdg_forward(struct mbuf *, struct ifnet *); static int bdg_ipf; /* IPFilter enabled in bridge */ SYSCTL_INT(_net_link_ether_bridge, OID_AUTO, ipf, CTLFLAG_RW, @@ -760,13 +761,16 @@ * to fetch more of the packet, or simply drop it completely. */ -static struct ifnet * -bridge_in(struct ifnet *ifp, struct ether_header *eh) +static struct mbuf * +bridge_in(struct ifnet *ifp, struct mbuf *m) { - int index; + struct ether_header *eh; struct ifnet *dst, *old; bdg_hash_table *bt; /* location in hash table */ int dropit = BDG_MUTED(ifp); + int index; + + eh = mtod(m, struct ether_header *); /* * hash the source address @@ -856,7 +860,28 @@ (dst <= BDG_FORWARD) ? bdg_dst_names[(uintptr_t)dst] : dst->if_xname)); - return dst; + switch ((uintptr_t)dst) { + case (uintptr_t)BDG_DROP: + m_freem(m); + return (NULL); + case (uintptr_t)BDG_LOCAL: + return (m); + case (uintptr_t)BDG_BCAST: + case (uintptr_t)BDG_MCAST: + m = bdg_forward(m, dst); +#ifdef DIAGNOSTIC /* glebius: am I right here? */ + if (m == NULL) { + if_printf(ifp, "bridge dropped %s packet\n", + dst == BDG_BCAST ? "broadcast" : "multicast"); + return (NULL); + } +#endif + return (m); + default: + m = bdg_forward(m, dst); + } + + return (NULL); /* not reached */ } /* Index: net/bridge.h =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.h,v retrieving revision 1.12 diff -u -r1.12 bridge.h --- net/bridge.h 15 Nov 2002 00:00:14 -0000 1.12 +++ net/bridge.h 6 Sep 2004 22:03:36 -0000 @@ -101,7 +101,7 @@ #define BDG_STAT(ifp, type) bdg_stats.s[ifp->if_index].p_in[(uintptr_t)type]++ #ifdef _KERNEL -typedef struct ifnet *bridge_in_t(struct ifnet *, struct ether_header *); +typedef struct mbuf *bridge_in_t(struct ifnet *, struct mbuf *); /* bdg_forward frees the mbuf if necessary, returning null */ typedef struct mbuf *bdg_forward_t(struct mbuf *, struct ifnet *); typedef void bdgtakeifaces_t(void); Index: net/if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.177 diff -u -r1.177 if_ethersubr.c --- net/if_ethersubr.c 27 Jul 2004 23:20:45 -0000 1.177 +++ net/if_ethersubr.c 6 Sep 2004 22:02:27 -0000 @@ -566,53 +566,9 @@ } /* Check for bridging mode */ - if (BDG_ACTIVE(ifp) ) { - struct ifnet *bif; - - /* - * Check with bridging code to see how the packet - * should be handled. Possibilities are: - * - * BDG_BCAST broadcast - * BDG_MCAST multicast - * BDG_LOCAL for local address, don't forward - * BDG_DROP discard - * ifp forward only to specified interface(s) - * - * Non-local destinations are handled by passing the - * packet back to the bridge code. - */ - bif = bridge_in_ptr(ifp, eh); - if (bif == BDG_DROP) { /* discard packet */ - m_freem(m); + if (BDG_ACTIVE(ifp) ) + if ((m = bridge_in_ptr(ifp, m)) == NULL) return; - } - if (bif != BDG_LOCAL) { /* non-local, forward */ - m = bdg_forward_ptr(m, bif); - /* - * The bridge may consume the packet if it's not - * supposed to be passed up or if a problem occurred - * while doing its job. This is reflected by it - * returning a NULL mbuf pointer. - */ - if (m == NULL) { - if (bif == BDG_BCAST || bif == BDG_MCAST) - if_printf(ifp, - "bridge dropped %s packet\n", - bif == BDG_BCAST ? "broadcast" : - "multicast"); - return; - } - /* - * But in some cases the bridge may return the - * packet for us to free; sigh. - */ - if (bif != BDG_BCAST && bif != BDG_MCAST) { - m_freem(m); - return; - } - } - } ether_demux(ifp, m); /* First chunk of an mbuf contains good entropy */ --IJpNTDwzlM2Ie8A6-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 08:18:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 543C516A4CE for ; Fri, 1 Oct 2004 08:18:21 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 28E3543D4C for ; Fri, 1 Oct 2004 08:18:21 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 73749 invoked by uid 113); 1 Oct 2004 01:18:21 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 5.086475 secs); 01 Oct 2004 08:18:21 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 1 Oct 2004 01:18:15 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: Juhani Tali Date: Fri, 1 Oct 2004 08:18:07 +0000 User-Agent: KMail/1.7 References: <200410010543.42789.miha@ghuug.org> <200410010711.24829.miha@ghuug.org> <415D0977.4000006@kernel.ee> In-Reply-To: <415D0977.4000006@kernel.ee> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410010818.07826.miha@ghuug.org> cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 08:18:21 -0000 On Friday 01 October 2004 07:38, Juhani Tali wrote: > ---- > ipfw add 4 divert 8568 ip from 192.168.0.3 to any out xmit tun0 > ipfw add 6 divert 8568 ip from any to any in recv tun0 > ---- > > replace these with > ipfw add 4 divert 8568 ip from 192.168.0.3 to any > prior to this rule the packet was not destined to go out through tun0 > but rl1, so the (xmit tun0) condition does not match. I see your point, and I tried suggested ipfw rules, but I'm still unable to get it working. What I ended with now (with above ipfw rules applied) - e.g. I ping "216.239.37.99" (google's ip) from 192.168.0.3, the 4th ipfw rule matches (see below), however pings don't get back and no traffic passes through tun0 (as supposed), instead packet travels via rl0 and then rl1: core# ipfw show 00004 55 3923 divert 8568 ip from 192.168.0.3 to any 00006 0 0 divert 8568 ip from any to any in recv tun0 00010 809517 109015055 divert 8668 ip from 192.168.0.0/24 to any out xmit rl1 00010 804261 407529807 divert 8668 ip from any to 192.168.254.1 in recv rl1 65535 3304709 1040001522 allow ip from any to any core# core# tcpdump -n -i rl0 host 216.239.37.99 tcpdump: listening on rl0 08:00:25.829749 192.168.0.3 > 216.239.37.99: icmp: echo request 08:00:26.839735 192.168.0.3 > 216.239.37.99: icmp: echo request 08:00:27.849675 192.168.0.3 > 216.239.37.99: icmp: echo request ^C 100 packets received by filter 0 packets dropped by kernel core# core# tcpdump -n -i rl1 host 216.239.37.99 tcpdump: listening on rl1 08:00:37.949283 192.168.10.2 > 216.239.37.99: icmp: echo request 08:00:38.959154 192.168.10.2 > 216.239.37.99: icmp: echo request 08:00:39.969102 192.168.10.2 > 216.239.37.99: icmp: echo request 08:00:40.979069 192.168.10.2 > 216.239.37.99: icmp: echo request ^C 57 packets received by filter 0 packets dropped by kernel core# core# netstat -nr|grep tun0 192.168.10.1 192.168.10.2 UH 0 49 tun0 core# ps ax | grep nat|grep tun0 52578 ?? Ss 0:00.51 natd -port 8568 -interface tun0 core# core# netstat -nr|grep tun0 192.168.10.1 192.168.10.2 UH 0 49 tun0 and tcpdump on tun0 shows nothing. Basically we got back to the point where we all started - I can ping remote party (HOST_B) from 192.168.0.x, but no further. Some piece in this mosaic is probably missing.. launched ping from 192.168.0.3 to 192.168.10.1: core# tcpdump -n -i tun0 tcpdump: listening on tun0 08:14:36.959198 192.168.10.1 > 192.168.10.2: icmp: echo reply 08:14:37.711774 192.168.10.2 > 192.168.10.1: icmp: echo request ^C 3 packets received by filter 0 packets dropped by kernel core# > Juhani Tali regards, M. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 08:21:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F36EC16A4CF for ; Fri, 1 Oct 2004 08:21:41 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id B781343D2D for ; Fri, 1 Oct 2004 08:21:41 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 67087 invoked by uid 113); 1 Oct 2004 01:21:41 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 0.572309 secs); 01 Oct 2004 08:21:41 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 1 Oct 2004 01:21:41 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Fri, 1 Oct 2004 08:21:39 +0000 User-Agent: KMail/1.7 References: <200410010543.42789.miha@ghuug.org> <415D0977.4000006@kernel.ee> <200410010818.07826.miha@ghuug.org> In-Reply-To: <200410010818.07826.miha@ghuug.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410010821.39284.miha@ghuug.org> cc: freebsd-isp@freebsd.org cc: Juhani Tali Subject: Re: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 08:21:42 -0000 On Friday 01 October 2004 08:18, Mikhail P. wrote: > Basically we got back to the point where we > all started - I can ping remote party (HOST_B) from 192.168.0.x, but no > further. Sorry, supposed to be HOST_A in above sentence. regards, M. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 14:49:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD17316A4D1 for ; Fri, 1 Oct 2004 14:49:40 +0000 (GMT) Received: from mail.minutemenu.com (mail.minutemenu.com [69.93.74.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E19443D2F for ; Fri, 1 Oct 2004 14:49:40 +0000 (GMT) (envelope-from jreeder@minutemenu.com) Received: from localhost (localhost.minutemenu.com [127.0.0.1]) by mail.minutemenu.com (Postfix) with ESMTP id E9FAF228810 for ; Fri, 1 Oct 2004 09:52:10 -0500 (CDT) Received: from mail.minutemenu.com ([69.93.74.12]) by localhost (lisa.minutemenu.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06981-04 for ; Fri, 1 Oct 2004 09:52:10 -0500 (CDT) Received: from jreed (unknown [216.138.72.218]) by mail.minutemenu.com (Postfix) with SMTP id 0ED8E2285D7 for ; Fri, 1 Oct 2004 09:52:10 -0500 (CDT) From: "Jonathan Reeder" To: Date: Fri, 1 Oct 2004 09:58:44 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by amavisd-new at mail.minutemenu.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: MPD Routing 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, 01 Oct 2004 14:49:40 -0000 Got a question about routing with regards to MPD. I'm able to make connections to my MPD-based VPN server just fine, but once connected, I can't communicate with anything on the other side of the tunnel, and it appears to be a routing problem. My ifconfig results for the ng0 device on the MPD server look as follows: ng0: flags=88d1 mtu 1400 inet6 fe80::2a0:ffff:feff:9cfc%ng0 prefixlen 64 scopeid 0x5 inet 192.168.2.254 --> 192.168.2.200 netmask 0xffffffff The MPD server has two NICs, one externally routable that clients connect on, and then a 192.168.1.10 address for the internal LAN. Here is what troubles me, when I ping 192.168.2.200 from the server while a client is connected, I get: ping: sendto: No route to host That was what got me thinking about routing problems. My routing table on the MPD server looks as follows: # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 216.138.x.x UGSc 3 12634 dc0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.1 link#2 UC 13 0 rl0 ... ... 192.168.2.200 192.168.2.254 UH 0 3 ng0 192.168.2.254 lo0 UHS 0 0 lo0 216.138.x.x/29 link#1 UC 1 0 dc0 216.138.x.x 00:06:53:40:0a:60 UHLW 3 0 dc0 1197 I'm a little concerned about the two entries related to the VPN client. I understand that 192.168.2.200 should be routed through 192.168.2.254 on the virtual ng0 device, but the fact that 192.168.2.254 is routed to the loopback doesn't seem to click with me. If my packets to the VPN client (192.168.2.200) are being routed through "gateway" 192.168.2.254, and 192.168.2.254 just gets dumped on the loopback, how would packets ever make it to the VPN client? Seems like they would just die on the loopback. By the way, I do have gateway_enable="YES" and my IPFILTER isn't blocking any packets. Any suggestions? I'll be happy to post any more info that would be helpful. Thanks a bunch. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 16:21:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 605BC16A4CE for ; Fri, 1 Oct 2004 16:21:21 +0000 (GMT) Received: from proxy.nelsonbay.com (proxy.nelsonbay.com [203.222.55.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A362C43D4C for ; Fri, 1 Oct 2004 16:21:20 +0000 (GMT) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (bell.nelsonbay.com [203.222.55.34]) by proxy.nelsonbay.com (8.12.9/8.12.9) with ESMTP id i91GLHhn041002; Sat, 2 Oct 2004 02:21:18 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: (from root@localhost) by bell.nelsonbay.com (8.12.11/8.12.11) id i91GLHCW072766; Sat, 2 Oct 2004 02:21:17 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (localhost [127.0.0.1]) by bell.nelsonbay.com (8.12.11/8.12.11) with ESMTP id i91GLHg3072720; Sat, 2 Oct 2004 02:21:17 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from localhost (leon@localhost)i91GLGC4072691; Sat, 2 Oct 2004 02:21:16 +1000 (EST) X-Authentication-Warning: bell.nelsonbay.com: leon owned process doing -bs Date: Sat, 2 Oct 2004 02:21:16 +1000 (EST) From: Leon Garde X-X-Sender: leon@localhost To: miha@ghuug.org Message-ID: <20041001232632.Y93609@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 bell.nelsonbay.com X-scanner: scanned by Inflex 1.0.12.3 cc: freebsd-net@freebsd.org Subject: Re: confusion with natd 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, 01 Oct 2004 16:21:21 -0000 Confusion 1. nat replaces routing. Mikail says he cant get routing to work, so he is using nat. Seems to me that to get nat going, he needs to fix the routing. Confusion 2. The sentiment "routing is hard" is wrong. Routing is easy. routes specify where to send a packet based on where it is going. confusion 3. Routing by source is not easy. routing by source is a subfunction of policy routing, an overview here,... http://www.bsdnews.org/01/policy_routing.php The other way to route by source is to use a rule like this 'ipfw add 1 fwd 192.168.10.2 from 192.168.0.3 to any ' What this does is set the default route for packets from 192.168.0.3 to go via the tunnel, which cures the problem. No further firewall rules apply, its on its way down tun0! to make use of this, turn off the nat on host A's tunnel. On host b, you need a route back to 192.168.0 via the tunnel in rc.conf put ... static_routes="192.168.0" route_192.168="-net 192.168.0/24 192.168.10.1" .... which means the 192.168.0/24 network is reached by 192.68.10.1 That allows the return packets from host b's nat. Another way to solve the problem is to VPN 192.168.0.3 to host B instead of /as well as Host A to host B. I think the problem with mikail's rules is that the vpn packets upon return appear at 10 and so bypass tun0's divert in recv tun0. So move rule 6 to rule 16, and the packets then appear after rule 10, hit rule 16 and get de-nat'ed, and so work as normal. I might be wrong there, but I think the vpn traffic is natd'd by rl1's NATD, so is avoiding tun0's natd... the order of the rules would appear to be important. (or would the ipfw table have to be looked through more than once for each packet? ie by sysctl setting the one_pass variable ? ) ------------------------ Leon Garde leon@nelsonbay.com Ph 02 4984 1422 From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 19:32:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CF9316A4CF for ; Fri, 1 Oct 2004 19:32:36 +0000 (GMT) Received: from blacksheep.csh.rit.edu (blacksheep.csh.rit.edu [129.21.60.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3F2F43D1F for ; Fri, 1 Oct 2004 19:32:35 +0000 (GMT) (envelope-from wxs@csh.rit.edu) Received: from fury.csh.rit.edu (fury.csh.rit.edu [IPv6:2001:470:1f00:135:a00:20ff:fe8d:5399]) by blacksheep.csh.rit.edu (Postfix) with ESMTP id 157BE928D for ; Fri, 1 Oct 2004 15:32:35 -0400 (EDT) Received: by fury.csh.rit.edu (Postfix, from userid 44963) id E81DF14AC; Fri, 1 Oct 2004 15:32:34 -0400 (EDT) Date: Fri, 1 Oct 2004 15:32:34 -0400 From: Wesley Shields To: freebsd-net@freebsd.org Message-ID: <20041001193234.GA14576@csh.rit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: ifconfig 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: Fri, 01 Oct 2004 19:32:36 -0000 Per a message about a month ago[1] I recently started some work on adding a -v flag to ifconfig. I've been able to get the index number and epoch as those are exposed to userland, but both the dname and dunit are in an ifnet struct which AFAIK is not visible. I initially thought you might be able to get them through an ioctl but that is not the case. Unless I'm mistaken I'd have to either move the parts I would like to see to the if_data struct (which is visible through a sysctl()), or make them visible through an ioctl. Am I correct in thinking that these are the only way to go about this problem, and if so which way is the best way? If neither of them are a wanted solution then any suggestions you have would be helpful, otherwise I guess I'm just barking up the wrong tree here. :) -- WXS [1]: http://lists.freebsd.org/pipermail/freebsd-net/2004-September/004964.html From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 20:06:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24B8F16A4CE for ; Fri, 1 Oct 2004 20:06:01 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 082D443D31 for ; Fri, 1 Oct 2004 20:06:01 +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 i91KAE3P000946; Fri, 1 Oct 2004 13:10:14 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i91KAE9b000945; Fri, 1 Oct 2004 13:10:14 -0700 Date: Fri, 1 Oct 2004 13:10:14 -0700 From: Brooks Davis To: Wesley Shields Message-ID: <20041001201014.GA7913@odin.ac.hmc.edu> References: <20041001193234.GA14576@csh.rit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20041001193234.GA14576@csh.rit.edu> 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: ifconfig 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: Fri, 01 Oct 2004 20:06:01 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2004 at 03:32:34PM -0400, Wesley Shields wrote: > Per a message about a month ago[1] I recently started some work on > adding a -v flag to ifconfig. I've been able to get the index number > and epoch as those are exposed to userland, but both the dname and dunit > are in an ifnet struct which AFAIK is not visible. I initially thought > you might be able to get them through an ioctl but that is not the case. >=20 > Unless I'm mistaken I'd have to either move the parts I would like to > see to the if_data struct (which is visible through a sysctl()), or make > them visible through an ioctl. >=20 > Am I correct in thinking that these are the only way to go about this > problem, and if so which way is the best way? >=20 > If neither of them are a wanted solution then any suggestions you have > would be helpful, otherwise I guess I'm just barking up the wrong tree > here. :) A pair of new per-interface sysctls is the right answer. Those members are't really intened to be used by public interfaces and if_data can not grow in -current until at least the 5.4 release and never can grow in 5.x. An ioctl could work, but a sysctls are a bit cheaper to add. -- 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 --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBXbmmXY6L6fI4GtQRAuyQAKDHTQ3SjeYCYiy4s10VL0ONW5WU2wCgmFXq COZIuhQ057QEjkSHOtzwoSo= =cm4o -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 20:21:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0FFF16A4CE for ; Fri, 1 Oct 2004 20:21:18 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 83B4343D4C for ; Fri, 1 Oct 2004 20:21:18 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 33979 invoked by uid 113); 1 Oct 2004 13:21:16 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 3.806583 secs); 01 Oct 2004 20:21:16 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 1 Oct 2004 13:21:12 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Fri, 1 Oct 2004 20:21:10 +0000 User-Agent: KMail/1.7 References: <20041001232632.Y93609@localhost> In-Reply-To: <20041001232632.Y93609@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410012021.10200.miha@ghuug.org> cc: Leon Garde Subject: Re: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 20:21:18 -0000 On Friday 01 October 2004 16:21, Leon Garde wrote: > The other way =A0to route by source is to use a rule like this > > 'ipfw add =A01 fwd =A0192.168.10.2 =A0from 192.168.0.3 to any ' Thanks! That did the job, and now 192.168.0.3 is being routed to the inet v= ia=20 tun0. on HOST_B (local router), rules now look like: ipfw add 1 allow ip from 192.168.0.0/24 to me ipfw add 2 fwd 192.168.10.1 ip from 192.168.0.3 to any if I delete 2nd rule, 192.168.0.3 is being routed as the rest of the LAN. and HOST_A (remote host), has natd running on rl0 + the following routing: route add 192.168.0.0/24 192.168.10.2 kind regards, M.