From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 12:33:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5D08106564A for ; Sun, 28 Dec 2008 12:33:47 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD158FC16 for ; Sun, 28 Dec 2008 12:33:46 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from laptop1.loshell.home (124-168-158-65.dyn.iinet.net.au [124.168.158.65]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id mBSCK2Nu083642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 23:20:03 +1100 (EST) (envelope-from lastewart@swin.edu.au) Message-ID: <49576E98.2070403@swin.edu.au> Date: Sun, 28 Dec 2008 23:18:32 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.18 (X11/20081206) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,HELO_LH_HOME, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Subject: CFT: TCP Appropriate Byte Counting (RFC3465) Patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 12:33:47 -0000 Hi all, The first chunk of work from the FreeBSD Foundation sponsored "Improving the FreeBSD TCP Implementation" project [1] is ready for some public review and testing. Being my first project related email, I'll point out to anyone interested that you can track the overall project via [2,3]. TCP appropriate byte counting (ABC) [4] addresses a congestion control related issue introduced by the early TCP specifications. It suggests increasing the congestion window by the number of bytes acknowledged by a TCP ACK, as opposed to the current scheme which relies on an approximation driven by ACK clocking. ABC will most commonly benefit FreeBSD by improving TCP sender performance when communicating with a delayed acknowledgement enabled receiver. The patch against 8-CURRENT svn rev 186471 can be found at [5] along with a readme [6] covering all the necessary juicy bits in more detail. I welcome all feedback and reports of both success or failure. I'm currently working on analysing the small-scale dynamic behaviour effects of the patch in detail, so I'm not asking you to go into minute detail with your testing. I'd like to hear that running with an ABC enabled kernel allows TCP to work as it did previously and is not negatively impacting throughput for any particular TCP workloads you have available for testing. I aim to commit this within the next week or so assuming nothing bad turns up in this round of testing. Cheers, Lawrence http://caia.swin.edu.au/ [1] http://www.freebsdfoundation.org/project%20announcements.shtml#Lawrence [2] http://svn.freebsd.org/viewvc/base/projects/tcp_ffcaia2008_8.x/ [3] http://lists.freebsd.org/mailman/listinfo/svn-src-projects [4] http://www.rfc-editor.org/rfc/rfc3465.txt [5] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch [6] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch.readme From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 15:13:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9745106564A; Sun, 28 Dec 2008 15:13:52 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id ECABB8FC08; Sun, 28 Dec 2008 15:13:51 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAFslV0lXQHIo/2dsb2JhbACBbLsNWI5xhkQ Received: from 40.114-64-87.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([87.64.114.40]) by relay.skynet.be with ESMTP; 28 Dec 2008 16:13:50 +0100 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id mBSFDnr1003012; Sun, 28 Dec 2008 16:13:49 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: "Qing Li" Date: Sun, 28 Dec 2008 16:13:47 +0100 User-Agent: KMail/1.9.10 References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> In-Reply-To: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812281613.49404.tijl@ulyssis.org> Cc: 'Qing Li' , freebsd-net@freebsd.org, Gerald Pfeifer , freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 15:13:52 -0000 On Saturday 27 December 2008 21:21:25 Qing Li wrote: > Right now I am also a bit leaning towards reintroducing > the RTF_LLINFO flag bit. This is mainly due to the recent > discovery of the "route" command issued with the > "-iface/-interface" option, which conflicts with the > way how "arp" and "ndp" is handled in the kernel. > > I renamed this flag bit to RTF_LLDATA because only the > "arp" and "ndp" commands need it. I wouldn't rename it. That breaks old code just the same. >> I didn't want to speak up because I'm no authority in this >> area and in the end I'm OK with any outcome, but personnaly I >> find special-casing {NET_RT_FLAGS,0} to retrieve the L2 >> entries a bit odd. > > As I've indicated previously, a few ports already have the > #ifdef RTF_LLINFO block around the sysctl() setup code. > Perhaps it's because these ports (such as Wine) run on OS > that does not support RTF_LLINFO (e.g. Linux?) ? That's odd, because a quick google shows that for instance NetBSD, OpenBSD, DragonFly and Mac OS X all define this flag. Linux is completely different. It doens't use sysctl(3). You have to read /proc/net/arp and /proc/net/route. >> Surely, letting {NET_RT_FLAGS,RTF_LLINFO} >> return L2 entries is exactly the same to implement, is far >> more descriptive, is fully backwards compatible and >> compatible with other sysctl operating systems like the other >> BSDs and Mac OS X, which helps portability. > > I believe all of the affected ports have been updated to > include the conditional blocks around RTF_LLINFO. So > there is still a level of compatibility, right ? Yes, and I'm OK with this. It's just that this makes FreeBSD 8 a special case. >> AFAIK, the other use of RTF_LLINFO was to filter out L2 >> entries from the entire L2+L3 routing table to obtain just >> the L3 entries. Because the L2 and L3 table have been >> separated this filtering isn't needed anymore, but what harm >> would it do to reintroduce RTF_LLINFO? The filtering code >> would become a useless no-op, but you'd stay fully >> compatible, again both backwards and with other operating systems. >> >> I just think that removing RTF_LLINFO was a bit too >> aggressive an optimisation with little advantage and too many >> disadvantages and I'd like to see it return. > > I believe examining the impacts of RTF_LLINFO on the ports > was a good exercise even if we have to rejuvenate it. > > I hope we could reach a consensus soon now that we have more > input from the ports developers. > > Please provide your input ... If it's easy to reintroduce it and become backwards compatible I would do it. Like Julian said, you can give it the value 0. It would be nice if the kernel tested for the old value as well, perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7 keep working. From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 17:30:36 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852F2106564A; Sun, 28 Dec 2008 17:30:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 49C988FC17; Sun, 28 Dec 2008 17:30:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBSHUVcC002182; Sun, 28 Dec 2008 09:30:33 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBSHU9Po039910; Sun, 28 Dec 2008 09:30:11 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from [172.16.1.197] (cpe-68-175-68-135.nyc.res.rr.com [68.175.68.135]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBSHU2h1004583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Dec 2008 09:30:08 -0800 (PST) (envelope-from gnn@neville-neil.com) Message-Id: <3BE32C00-3AF8-4C8F-B48D-45F50D55A2B2@neville-neil.com> From: George Nevill-Neil To: Julian Elischer In-Reply-To: <495290EF.6020400@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 28 Dec 2008 12:30:02 -0500 References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> <495290EF.6020400@elischer.org> X-Mailer: Apple Mail (2.930.3) X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 2848020 - 2c18ad79d617 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: gnn@freebsd.org, Luigi Rizzo , net@freebsd.org Subject: Re: A new tool for low level testing... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 17:30:36 -0000 On Dec 24, 2008, at 2:43 PM, Julian Elischer wrote: > Luigi Rizzo wrote: >> On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >>> Julian Elischer wrote: >>>> OR >>>> >>>> ngctl mkpeer em0: echo lower echo >>>> >>>> >>>> hmmmmm no this would leave the source and destination headers in >>>> hte same order.. they need to be swapped.. >>>> >>>> ok so I need to make a patch, but it would be much quicker than a >>>> user utility.. >>> what about a netgraph cookbook? >> indeed, that would be a nice Xmas present! >> cheers >> luigi > > > I'm curious, what sort of things would you expect to see in such a > document? Maybe we could get everyone to contribute their favourite > netgraph recipes (scripts?). > I have often thought of updating the docs I've found but as usual $paidwork gets in the way. I may be about to use netgraph at work so I might be able to help with this. The things that I find to be missing in the current netgraph documentation are: 1) Developers Guide How do I write new nodes? Walk through a non trivial node step by step. 2) Updated overall use guide I've found a few docs on netgraph on the net, but I bet most people are still looking at Archie Cobb's old document and it's out of date. 3) Recipes Sure, a fine idea, but it's not the first thing I need. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 18:08:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DDCF1065675; Sun, 28 Dec 2008 18:08:12 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (otrada.od.ua [89.209.81.54]) by mx1.freebsd.org (Postfix) with ESMTP id B22C38FC1A; Sun, 28 Dec 2008 18:08:11 +0000 (UTC) (envelope-from universite@ukr.net) Received: from TOP (TOP [10.0.0.20]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.2) with ESMTP id mBSI0YiD003312; Sun, 28 Dec 2008 20:00:35 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4957BEC7.6010603@ukr.net> Date: Sun, 28 Dec 2008 20:00:39 +0200 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Li, Qing" References: <49528E6F.30600@ukr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_SINGLE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: Qing Li , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Odd behavior routed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 18:08:12 -0000 Thank you. The option "-iface" works as expected. Also solved the problem when the squid 3.0.STABLE10 could not connect to the real ip, which ISP issued on pppoe. Now squid normally sees routes to these IP. Li, Qing writes: > Hi, > I have committed a patch for this problem. Please sync-up to > SVN rev 186500 on 2008-12-26 19:45:24Z by qingli > Thank, > -- Qing From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 23:25:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2571065670; Sun, 28 Dec 2008 23:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id AA23A8FC13; Sun, 28 Dec 2008 23:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F0AF341C707; Mon, 29 Dec 2008 00:25:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vPJiwmeAY+EE; Mon, 29 Dec 2008 00:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 95F8B41C72C; Mon, 29 Dec 2008 00:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7DF364448D5; Sun, 28 Dec 2008 23:24:46 +0000 (UTC) Date: Sun, 28 Dec 2008 23:24:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Qing Li Message-ID: <20081228225956.G28465@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Kip Macy Subject: arp-v2 (void *)-1 "hack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 23:25:08 -0000 Hi, Cc:ing freebsd-net as I came across the (void *)-1 "hack" 1.5 weeks ago while debugging some problems with others and they might be interested as well. I was sure I hadn't seen that hack in patches posted before. I spent some time today and looked a bit more into it (also comitted the LLE_IS_VALID() check). In short: I don't like it and I don't understand why a new API needs a hack already that is passed down through two functions into the code. It was introduced the last days before the commit. I found r186010 and r186027 in SVN but that's just two of the 4 places. I think the proper behavior would be to either return an "errno" or the lle via an additional argument and the other as return value. As the lle is the return value already I would say adding an extra argument 'int *error' will be easier. For now this seems to only affect LLE_DELETE cases but I am not sure all (especially wrt to the future of v6) has been shaken out yet and returning a proper error code (possibly along with the NULL lle) would make this more flexible. I am also not sure if all the "void" callers on delete are right but I got distracted by a "dead" function in one of the callpaths while investigating. What do you think wrt to adding the (possibly optional) int *error and returning the errno rather than a (void *)-1? If you'd be ok, I'd can prepare the patch. I'd rather break the API now than in a few months. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 23:30:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED561065793; Sun, 28 Dec 2008 23:30:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB958FC14; Sun, 28 Dec 2008 23:30:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5736505rvf.43 for ; Sun, 28 Dec 2008 15:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=iQvH7Vjb0wvTEoTQhtU9HV6gzD6N6CZd/fAiLpEu1qM=; b=LVa9ZoJVjIwGLCo83h/rFiaMqqcKFZq/XR9WlsP8IPXw23rlMb0IMbrGZgSMDYN6RY cqxjiWLhwxWFsgHH3F3I9nue8T8hLFzcv1kg+M+sADuadvKYvKl8tIwqS1blH7+xrF3W 1RtT4tp09gWUqVBxh+NzrWAGIZV3d++9f0GZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=FMllzoDGVvoX+DNxyD67/65UNoa+XqnWimqaoNl0QZjhLJcoFebArxnBEcT+KfJ+a4 5lafFboKdsGHh9nbWKujtNTHTW+scIohczBK9rsfFX3FE5KGA0O8ZhYIEpnoA2A0ZAFR LGCPPBcdZOjyBNVKCfSeJ9S9wTXV9aKS3OIKQ= Received: by 10.141.100.15 with SMTP id c15mr6423503rvm.222.1230507059096; Sun, 28 Dec 2008 15:30:59 -0800 (PST) Received: by 10.141.37.17 with HTTP; Sun, 28 Dec 2008 15:30:59 -0800 (PST) Message-ID: <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> Date: Sun, 28 Dec 2008 15:30:59 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Bjoern A. Zeeb" In-Reply-To: <20081228225956.G28465@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081228225956.G28465@maildrop.int.zabbadoz.net> X-Google-Sender-Auth: d797649d93439105 Cc: Qing Li , freebsd-net@freebsd.org Subject: Re: arp-v2 (void *)-1 "hack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 23:30:59 -0000 > What do you think wrt to adding the (possibly optional) int *error and > returning the errno rather than a (void *)-1? If you'd be ok, I'd can > prepare the patch. I'd rather break the API now than in a few months. I would greatly prefer having a dedicated new function that calls in to it. There are a lot of calls to lla_lookup that would have to be changed needlessly. In other words: 1) lla_lookup_internal - a static function which takes all 3 args 2) lla_delete - which returns an errno 3) lla_lookup - which maintains the current interface I'll review the patch as soon as it is ready. -Kip From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 23:55:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78898106564A; Sun, 28 Dec 2008 23:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 33D888FC19; Sun, 28 Dec 2008 23:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 71FB641C733; Mon, 29 Dec 2008 00:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id eTUdRZKzve0O; Mon, 29 Dec 2008 00:55:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 17C3841C730; Mon, 29 Dec 2008 00:55:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CDBB34448D5; Sun, 28 Dec 2008 23:53:43 +0000 (UTC) Date: Sun, 28 Dec 2008 23:53:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kip Macy In-Reply-To: <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> Message-ID: <20081228234501.F28465@maildrop.int.zabbadoz.net> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Qing Li , freebsd-net@freebsd.org Subject: Re: arp-v2 (void *)-1 "hack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Dec 2008 23:55:07 -0000 On Sun, 28 Dec 2008, Kip Macy wrote: Hi, >> What do you think wrt to adding the (possibly optional) int *error and >> returning the errno rather than a (void *)-1? If you'd be ok, I'd can >> prepare the patch. I'd rather break the API now than in a few months. > > I would greatly prefer having a dedicated new function that calls in > to it. There are a lot of calls to lla_lookup that would have to be > changed needlessly. In other words: Right, there are 14 or so of them and at least 2 will need to be touched. > 1) lla_lookup_internal - a static function which takes all 3 args > 2) lla_delete - which returns an errno > 3) lla_lookup - which maintains the current interface I wonder if it's worth adding two more functions for about a dozen calls from basically 2 files; especially considering that we will need to modify the internal API (llt_lookup function pointer in struct lltable and in_lltable_lookup()/in6_lltable_lookup()) anyway. That's why I thought adding the int *error now consistently would be easier and cleaner. Most of the callers, currently not caring could just pass in NULL, if they don't care and we keep the argument optional. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 00:35:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EDE106564A; Mon, 29 Dec 2008 00:35:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7698FC0C; Mon, 29 Dec 2008 00:35:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D914941C711; Mon, 29 Dec 2008 01:35:12 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id g3SeSz0iixCR; Mon, 29 Dec 2008 01:35:12 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 7C62241C710; Mon, 29 Dec 2008 01:35:12 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AD4F74448D5; Mon, 29 Dec 2008 00:33:59 +0000 (UTC) Date: Mon, 29 Dec 2008 00:33:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kip Macy In-Reply-To: <20081228234501.F28465@maildrop.int.zabbadoz.net> Message-ID: <20081229003106.G28465@maildrop.int.zabbadoz.net> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> <20081228234501.F28465@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Qing Li , freebsd-net@freebsd.org Subject: Re: arp-v2 (void *)-1 "hack" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 00:35:16 -0000 On Sun, 28 Dec 2008, Bjoern A. Zeeb wrote: Hi, > On Sun, 28 Dec 2008, Kip Macy wrote: > > Hi, > >>> What do you think wrt to adding the (possibly optional) int *error and >>> returning the errno rather than a (void *)-1? If you'd be ok, I'd can >>> prepare the patch. I'd rather break the API now than in a few months. >> >> I would greatly prefer having a dedicated new function that calls in >> to it. There are a lot of calls to lla_lookup that would have to be >> changed needlessly. In other words: > > Right, there are 14 or so of them and at least 2 will need to be > touched. > >> 1) lla_lookup_internal - a static function which takes all 3 args >> 2) lla_delete - which returns an errno >> 3) lla_lookup - which maintains the current interface > > I wonder if it's worth adding two more functions for about a dozen calls > from basically 2 files; especially considering that we will need to modify > the internal API (llt_lookup function pointer in struct lltable and > in_lltable_lookup()/in6_lltable_lookup()) anyway. > > That's why I thought adding the int *error now consistently would be > easier and cleaner. > > Most of the callers, currently not caring could just pass in NULL, if > they don't care and we keep the argument optional. Just as a follow-up. I talked to Qing and the summary is: * we agree that this should be changed - one way or the other. * we'll wait a bit for things to settle more and possibly (though hopefully not) collect another few cases and fix them all at once should they show up. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 02:30:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78881065670 for ; Mon, 29 Dec 2008 02:30:00 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from mail01.compvia.com (mail01.compvia.com [12.147.132.91]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF978FC08 for ; Mon, 29 Dec 2008 02:30:00 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from [10.10.20.11] ([10.10.20.11]) by mail01.compvia.com (Kerio MailServer 6.5.1) for freebsd-net@freebsd.org; Sun, 28 Dec 2008 19:59:57 -0600 To: freebsd-net@freebsd.org From: "Gerry Weaver" Message-ID: <20081229015957.4fe4d0ac@mail01.compvia.com> Date: Sun, 28 Dec 2008 19:59:57 -0600 X-Mailer: Kerio MailServer 6.5.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pfil + if_bridge hooks not being called X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 02:30:00 -0000 Hello All, I am working on a driver to collect some network statistics using pfil. = I have set up a bridge and set net.link.bridge.pfil=5Fmember=3D1 via sysctl. I have ad= ded hooks for=20 incoming and outgoing packets. I also put a third adapter into the syste= m for=20 dev/managment purposes. My hooks are only being called for outgoing pack= ets on the management (non bridge) interface. I have been searching for info= rmation about what I may have overlooked, but I can't find anything concrete. Is= there=20 something else that I need to do to see packets on the bridge member int= erfaces and incoming packets in general=3F=20 I'm using FreeBSD 7.0-RELEASE. struct pfil=5Fhead *pfh=5Finet; pfh=5Finet =3D pfil=5Fhead=5Fget(PFIL=5FTYPE=5FAF, AF=5FINET); if(pfh=5Finet =3D=3D NULL) { uprintf("ERROR: Cannot get pfil head\n"); return ENOENT; } pfil=5Fadd=5Fhook(packets=5Fin, NULL, PFIL=5FIN | PFIL=5FWAITOK, pfh= =5Finet); pfil=5Fadd=5Fhook(packets=5Fout, NULL, PFIL=5FOUT | PFIL=5FWAITOK, pfh= =5Finet); ... Thanks in advance, Gerry From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 05:04:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF82E1065673 for ; Mon, 29 Dec 2008 05:04:09 +0000 (UTC) (envelope-from invite+ke5r5rmn@facebookmail.com) Received: from vipfallbackmx-out.facebook.com (outmail002.sctm.tfbnw.net [204.15.20.237]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAC18FC13 for ; Mon, 29 Dec 2008 05:04:09 +0000 (UTC) (envelope-from invite+ke5r5rmn@facebookmail.com) Received: from vipmx-out.facebook.com ([10.18.255.177]) by vipfallbackmx-out.facebook.com [hpvipfallback005.snc1.facebook.com] (8.13.1/FB.vipfallback-1.0.0) with ESMTP id mBT1E3Ta031663 for ; Sun, 28 Dec 2008 17:14:03 -0800 Received: from localhost.localdomain ([10.18.255.178]) by vipmx-out.facebook.com [vipemail002.snc1.facebook.com] (8.13.1/8.13.6) with ESMTP id mBT1E2sA014657 for ; Sun, 28 Dec 2008 17:14:03 -0800 X-Facebook: from zuckmail by localhost.localdomain with local (ZuckMail); Date: Sun, 28 Dec 2008 17:14:02 -0800 To: Freebsd-net From: Michael Sierchio Message-ID: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> X-Priority: 3 X-Mailer: ZuckMail [version 1.00] X-Facebook-Notify: general_invite Errors-To: invite+ke5r5rmn@facebookmail.com MIME-Version: 1.0 Content-Type: text/plain; charset = "UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Check out my Facebook profile X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Sierchio List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 05:04:09 -0000 Hi freebsd-net, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Michael To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=3D605054484&k=3D64GZ6VV4W26M5CEIXFY6X3&r From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 05:11:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6D21065673 for ; Mon, 29 Dec 2008 05:11:47 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1A81E8FC13 for ; Mon, 29 Dec 2008 05:11:47 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2303222ywe.13 for ; Sun, 28 Dec 2008 21:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=T773Qdb+rfnt57PfIlLcVqm7tKWT4ZNv454c4aLr3xw=; b=WkOqug2bLJXAPOclRaNsOWAyOJdBi3kuqHbyWgr1dHeVwfBv/MV8vvf2uAbf3Cnk3l TKcU9Exfqvd5Fvue6m6BDmquDWD3BgKw7ixyqRI7uZ/UtpnhEkHE8SB4AjWnC4ibaD/C BQxizkMfQTPqsCzDIkgu13fFt7c/3rtuvLKck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ssrVK6nEb33V5ORazRaU69/UDpnvABKFziY6ecWUL1IGZrjQydf0BoBKM7zxeXH/2f N2vCu5UI71+Ul0yXWJ8AbKRGfvff/Mu0yzZG+ryCeOMfp/kNZEL0HzfF5Nqeuv4Y78LZ B5jIO30IUC+Vh+ZQKLBLuTkO3TP/I6niqtg2o= Received: by 10.100.141.10 with SMTP id o10mr7490090and.41.1230527506312; Sun, 28 Dec 2008 21:11:46 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id d12sm15895782and.2.2008.12.28.21.11.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Dec 2008 21:11:45 -0800 (PST) From: Ferner Cilloniz To: Michael Sierchio In-Reply-To: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> References: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> Content-Type: text/plain Date: Sun, 28 Dec 2008 23:11:43 +0000 Message-Id: <1230505903.4966.0.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: Freebsd-net Subject: Re: Check out my Facebook profile X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 05:11:47 -0000 Because that is clearly related to freebsd-net. Have you lost your mind?? On Sun, 2008-12-28 at 17:14 -0800, Michael Sierchio wrote: > Hi freebsd-net, > > I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. > > Thanks, > Michael > > To sign up for Facebook, follow the link below: > http://www.facebook.com/p.php?i=605054484&k=64GZ6VV4W26M5CEIXFY6X3&r > > _______________________________________________ > 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 Mon Dec 29 07:10:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25D7F106564A for ; Mon, 29 Dec 2008 07:10:41 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C45F58FC12 for ; Mon, 29 Dec 2008 07:10:40 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=P8aLzPMxPv+UjuSagEmZ8rdz5msOdpHcb0Rkl0YyRSJefdpFw/CaTda0I/1DHO5DvKIcvZ+R/Gd49Cc04ujtoJl+6gSTGdwfBqK9Bavb3r9efh+fAumjQrQTX7rLTlba8ojtUr5wL+EfLkKR+mg561JjihhrIivTR1WTK4tb5z4=; Received: from phoenix.codelabs.ru (ppp85-141-64-79.pppoe.mtu-net.ru [85.141.64.79]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LHCGs-0002Cs-BQ; Mon, 29 Dec 2008 10:10:39 +0300 Date: Mon, 29 Dec 2008 10:10:37 +0300 From: Eygene Ryabinkin To: Gerry Weaver Message-ID: References: <20081229015957.4fe4d0ac@mail01.compvia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081229015957.4fe4d0ac@mail01.compvia.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org Subject: Re: pfil + if_bridge hooks not being called X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 07:10:41 -0000 Gerry, good day. Sun, Dec 28, 2008 at 07:59:57PM -0600, Gerry Weaver wrote: > I am working on a driver to collect some network statistics using > pfil. I have set up a bridge and set net.link.bridge.pfil_member=1 via > sysctl. I have added hooks for incoming and outgoing packets. I also > put a third adapter into the system for dev/managment purposes. My > hooks are only being called for outgoing packets on the management > (non bridge) interface. A simple check will be to fire up standard hooks (for example, pf firewall + some rules with 'log' keyword, see 'man pf.conf') and watch for the logged packets on a pflog0 interface using tcpdump. If you'll see the packets you wanted to see, then the problem is probably with your code. If not, then probably your setup is incorrect and/or system has a bug. > I have been searching for information about > what I may have overlooked, but I can't find anything concrete. Is > there something else that I need to do to see packets on the bridge > member interfaces and incoming packets in general? You may want to add some diagnostics to the bridge_pfil() in /sys/net/if_bridge.c, rebuild your kernel and try to see how it goes. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 08:54:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3735106564A; Mon, 29 Dec 2008 08:54:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6378FC16; Mon, 29 Dec 2008 08:54:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 4400F3911C; Mon, 29 Dec 2008 09:54:52 +0100 (CET) Received: by acrux.dbai.tuwien.ac.at (Postfix, from userid 1203) id 5F93810059; Mon, 29 Dec 2008 09:54:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by acrux.dbai.tuwien.ac.at (Postfix) with ESMTP id 4CA3210055; Mon, 29 Dec 2008 09:54:53 +0100 (CET) Date: Mon, 29 Dec 2008 09:54:53 +0100 (CET) From: Gerald Pfeifer To: Tijl Coosemans , Qing Li In-Reply-To: <200812281613.49404.tijl@ulyssis.org> Message-ID: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> User-Agent: Alpine 1.99 (LSU 1142 2008-08-13) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 08:54:53 -0000 On Sun, 28 Dec 2008, Tijl Coosemans wrote: > On Saturday 27 December 2008 21:21:25 Qing Li wrote: >> I believe all of the affected ports have been updated to >> include the conditional blocks around RTF_LLINFO. emulators/wine has not been adjusted yet, pending this discussion. > Yes, and I'm OK with this. It's just that this makes FreeBSD 8 > a special case. Agreed. > If it's easy to reintroduce it and become backwards compatible I > would do it. Like Julian said, you can give it the value 0. It > would be nice if the kernel tested for the old value as well, > perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people > upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7 > keep working. What of this will be doable, Qing? I guess Tijl and me need to understand when/whether/what to submit to Wine upstream... Gerald From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 10:36:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E11A106564A for ; Mon, 29 Dec 2008 10:36:49 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from mail01.compvia.com (mail01.compvia.com [12.147.132.91]) by mx1.freebsd.org (Postfix) with ESMTP id E6F038FC08 for ; Mon, 29 Dec 2008 10:36:48 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from [10.10.20.11] ([10.10.20.11]) by mail01.compvia.com (Kerio MailServer 6.5.1); Mon, 29 Dec 2008 04:36:17 -0600 To: rea-fbsd@codelabs.ru From: "Gerry Weaver" In-Reply-To: "" Message-ID: <20081229103617.cee01bda@mail01.compvia.com> Date: Mon, 29 Dec 2008 04:36:17 -0600 X-Mailer: Kerio MailServer 6.5.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: pfil + if_bridge hooks not being called X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 10:36:49 -0000 =5F=5F=5F=5F=5F =20 From: Eygene Ryabinkin [mailto:rea-fbsd@codelabs.ru] To: Gerry Weaver [mailto:gerryw@compvia.com] Cc: freebsd-net@freebsd.org Sent: Mon, 29 Dec 2008 01:10:37 -0600 Subject: Re: pfil + if=5Fbridge hooks not being called Gerry, good day. =20 Sun, Dec 28, 2008 at 07:59:57PM -0600, Gerry Weaver wrote: > I am working on a driver to collect some network statistics using > pfil. I have set up a bridge and set net.link.bridge.pfil=5Fmember= =3D1 via > sysctl. I have added hooks for incoming and outgoing packets. I also > put a third adapter into the system for dev/managment purposes. My > hooks are only being called for outgoing packets on the management > (non bridge) interface. =20 A simple check will be to fire up standard hooks (for example, pf firewall + some rules with 'log' keyword, see 'man pf.conf') and watch for the logged packets on a pflog0 interface using tcpdump. If you'll see the packets you wanted to see, then the problem is probably with your code. If not, then probably your setup is incorrect and/or syste= m has a bug. =20 > I have been searching for information about > what I may have overlooked, but I can't find anything concrete. Is > there something else that I need to do to see packets on the bridge > member interfaces and incoming packets in general=3F =20 You may want to add some diagnostics to the bridge=5Fpfil() in /sys/net/if=5Fbridge.c, rebuild your kernel and try to see how it goes= . --=20 Eygene =5F =5F=5F=5F =5F.--. # \`.|\..----...-'` `-.=5F.-'=5F.-'` # Remember that it is hard / ' ` , =5F=5F.--' # to read the on-line manual )/' =5F/ \ `-=5F, / # while single-stepping the k= ernel. `-'" `"\=5F ,=5F.-;=5F.-\=5F ', fsc/as # =5F.-'=5F./ {=5F.' ; / # -- FreeBSD Developers h= andbook {=5F.-``-' {=5F/ # =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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" Hello All, =20 Thanks for the advice Eygene. It turns out that the pointer to the if= net structure is null when the hook is called for incoming packets. I had a check for a null pointer, but failed to log the error. Reworking this c= ode fixed the incoming packet problem. I put a printf in the outgoing packe= t hook function and things magically started working. If I take it out, t= hings stop working. Something is getting stepped on. I'm gonna fiddle with it= a=20 bit to see what's happening there. I would assume it's probably somethin= g in my code as well. Also, after having a look at the if=5Fbridge code, = I'm=20 starting to rethink the use of pfil in the first place. Calling my code from the if=5Fbridge code offers some additional protocol support as we= ll as several other possibilities. I appreciate the pointer to if=5Fbridge.= c. It made me look at it a lot sooner than I probably would have otherwise. =20 Thanks Again for your help, Gerry From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 11:06:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DEC7106567B for ; Mon, 29 Dec 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 033308FC2B for ; Mon, 29 Dec 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBTB6wc8024519 for ; Mon, 29 Dec 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBTB6wF7024515 for freebsd-net@FreeBSD.org; Mon, 29 Dec 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Dec 2008 11:06:58 GMT Message-Id: <200812291106.mBTB6wF7024515@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129904 net [vlan] [panic] kernel crash in "ifconfig destroy" o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 202 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 12:01:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 681AC106564A for ; Mon, 29 Dec 2008 12:01:44 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83809.mail.sp1.yahoo.com (web83809.mail.sp1.yahoo.com [69.147.85.81]) by mx1.freebsd.org (Postfix) with SMTP id 4F7438FC2C for ; Mon, 29 Dec 2008 12:01:44 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 12958 invoked by uid 60001); 29 Dec 2008 12:01:44 -0000 X-YMail-OSG: YTV7dgwVM1lXidgsFYOCLBUhpxF7gB_zqTx.0TF9L3mkItIc7TtbB1LriEHc6H687To6hfbV3KwoAPntI1dacHuUIyQ5Q0AovJB0GBVrV6L_3z41OC4ZaR97Hh1DWMtWfuRYo0w_RueBNAo3r.gRRxos Received: from [69.43.143.172] by web83809.mail.sp1.yahoo.com via HTTP; Mon, 29 Dec 2008 04:01:44 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.218.2 Date: Mon, 29 Dec 2008 04:01:44 -0800 (PST) From: Gabe To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <204586.11713.qm@web83809.mail.sp1.yahoo.com> Subject: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 12:01:44 -0000 Anyone know what causes this error message? +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 Thanks, /gabe From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 12:33:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 511511065674 for ; Mon, 29 Dec 2008 12:33:26 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mx1.freebsd.org (Postfix) with ESMTP id BE5688FC19 for ; Mon, 29 Dec 2008 12:33:25 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Dec 2008 12:33:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Dec 2008 12:33:18 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP : problems in sending ASCONF chunks Thread-Index: AclpqT7TlvJ0LkXYSMG8Wr/U12WTBQ== From: To: X-OriginalArrivalTime: 29 Dec 2008 11:33:20.0593 (UTC) FILETIME=[404CBC10:01C969A9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: khadija.daoud@orange-ftgroup.com Subject: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 12:33:26 -0000 Hi all, I have been working with SCTP and more specifically with the mobility features of SCTP at my work. Basically, I have been trying to use SCTP to perform handover tests between 2 separate Wifi networks. I use IPv6 for all my tests. I have a local LAN (wired-network), on which I have 3 machines, one of them is the machine I use to communicate with for the tests (I'll call it T to make things simple), and the other two are used as Wifi Access Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I set up both Access Points to send Router Advertisement messages periodically (minimum of 3 seconds, maximum of 4 seconds). That way I can have automatic address reconfiguration when I connect to either of the access points. The aim of my tests is to use a PC, connect to Wifi1 (for example), launch an SCTP association with T (T sends data to my PC), and then perform a handover on Wifi2. I do make address reconfiguration during the handover process. The important point is that I work with only ONE address on my network interface. Before I start my tests, I set the following sysctl parameters : # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w net.inet.sctp.mobility_fasthandoff=3D1 # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is to dump messages in /var/log/messages) net.inet.sctp.auto_asconf is set to 1 by default. I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful but I'm trying to be thorough. This is the script I use to perform handover : ifconfig rum0 inet6 delete ifconfig rum0 ssid route del -inet6 default rtsol rum0 If I'm not mistaken, the PC should have sent an ASCONF chunk to perform dynamic address reconfiguration. However what I observed is that nothing happens. No ASCONF chunks are sent, and therefore, T doesn't ever know that it should send data on the PC's newly acquired address. I tried to investigate the problem myself, by adding some debug logs in the sctp source code (to see which functions are called during the handover process), and it seems as if the kernel doesn't ever add an ASCONF chunk to send in its queue... But that's just my understanding of the problem... I looked up in the CVS repository for answers, and to see the various changes that were gradually brought on the code. There, I noticed that on the revision dating 24th July 2007, changes were made for dynamic address reconfiguration : "Change behaviour so that when the last address is deleted (auto-asconf on a boudall endpoint) no action is taken until an address is added ; at that time an ASCONF add+delete is sent (if the asoc is still up)" In my humble opinion, this is exactly the case that corresponds to my handover scenario. But I just haven't been able to successfully perform it because I don't seem to send any ASCONF chunk. I'm struggling to understand why I do not see any ASCONF chunk sent. If it can help, I'm also attaching links to the kind of debug logs I got when performing a handover test. This is the kind of debug logs that I got :=20 http://www.divshare.com/download/6200509-560 This is another debug logfile, but with my own debug logs added in the sctp source code : http://www.divshare.com/download/6200504-2e9 Many thanks for your work, and I hope someone will be able to help and shed some light on this problem :-) Aman Jassal From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 12:55:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BD9F106564A for ; Mon, 29 Dec 2008 12:55:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2D90F8FC1C for ; Mon, 29 Dec 2008 12:55:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 737C341C677; Mon, 29 Dec 2008 13:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ic40+2ZwcC5m; Mon, 29 Dec 2008 13:55:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 1BB1C41C65E; Mon, 29 Dec 2008 13:55:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7F07E4448D5; Mon, 29 Dec 2008 12:52:51 +0000 (UTC) Date: Mon, 29 Dec 2008 12:52:51 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <204586.11713.qm@web83809.mail.sp1.yahoo.com> Message-ID: <20081229124113.A28465@maildrop.int.zabbadoz.net> References: <204586.11713.qm@web83809.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 12:55:10 -0000 On Mon, 29 Dec 2008, Gabe wrote: > Anyone know what causes this error message? > > +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 from what I remember without looking, this means that you ahve an IPsec policy for src/dst but no SA matching this pair or rather no matching destination + protocol + security parameter index (see rfc2401). The easiest thing you can do is to check setkey -Da for this tripple the time the printf happens. The first thing in the printf is your destination IP (your local side), the next is the SPI in hex and last is the protocol (50 == ESP). With that you can see if what the peer sends you is what you negotiated/expected. Are you using static keying or an ike daemon like racoon? Do this happen for all packets or just randomly or exactly every n minutes/hours? If you find an exact match of the triplet in setkey -Da you may also want to check if there is another one and/or the state of the entry/entries (state=.. at the end of the fourth line). If it's not "mature" check the time ralted values to see if there is an expiry problem.. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 13:09:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA85106564A for ; Mon, 29 Dec 2008 13:09:18 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id C693D8FC16 for ; Mon, 29 Dec 2008 13:09:17 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [IPv6:2002:508f:e9a7::21e:c2ff:fe00:76c8] (unknown [IPv6:2002:508f:e9a7:0:21e:c2ff:fe00:76c8]) by mail-n.franken.de (Postfix) with ESMTP id 6036A1C0B4624; Mon, 29 Dec 2008 14:09:14 +0100 (CET) Message-Id: <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: In-Reply-To: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 14:09:12 +0100 References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 13:09:18 -0000 Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, wrote: > Hi all, > > I have been working with SCTP and more specifically with the mobility > features of SCTP at my work. Basically, I have been trying to use SCTP > to perform handover tests between 2 separate Wifi networks. I use IPv6 > for all my tests. > > I have a local LAN (wired-network), on which I have 3 machines, one of > them is the machine I use to communicate with for the tests (I'll call > it T to make things simple), and the other two are used as Wifi Access > Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I > set > up both Access Points to send Router Advertisement messages > periodically > (minimum of 3 seconds, maximum of 4 seconds). That way I can have > automatic address reconfiguration when I connect to either of the > access > points. > > The aim of my tests is to use a PC, connect to Wifi1 (for example), > launch an SCTP association with T (T sends data to my PC), and then > perform a handover on Wifi2. I do make address reconfiguration during > the handover process. The important point is that I work with only ONE > address on my network interface. Before I start my tests, I set the > following sysctl parameters : > > # sysctl -w net.inet.sctp.mobility_base=1 > # sysctl -w net.inet.sctp.mobility_fasthandoff=1 > # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump > messages in /var/log/messages) > > net.inet.sctp.auto_asconf is set to 1 by default. > > I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful > but > I'm trying to be thorough. This is the script I use to perform > handover > : > > ifconfig rum0 inet6 delete > ifconfig rum0 ssid > route del -inet6 default > rtsol rum0 > > If I'm not mistaken, the PC should have sent an ASCONF chunk to > perform > dynamic address reconfiguration. However what I observed is that > nothing > happens. No ASCONF chunks are sent, and therefore, T doesn't ever know > that it should send data on the PC's newly acquired address. > > I tried to investigate the problem myself, by adding some debug logs > in > the sctp source code (to see which functions are called during the > handover process), and it seems as if the kernel doesn't ever add an > ASCONF chunk to send in its queue... But that's just my > understanding of > the problem... > > I looked up in the CVS repository for answers, and to see the various > changes that were gradually brought on the code. There, I noticed that > on the revision dating 24th July 2007, changes were made for dynamic > address reconfiguration : "Change behaviour so that when the last > address is deleted (auto-asconf on a boudall endpoint) no action is > taken until an address is added ; at that time an ASCONF add+delete is > sent (if the asoc is still up)" > > In my humble opinion, this is exactly the case that corresponds to my > handover scenario. But I just haven't been able to successfully > perform > it because I don't seem to send any ASCONF chunk. I'm struggling to > understand why I do not see any ASCONF chunk sent. > > If it can help, I'm also attaching links to the kind of debug logs I > got > when performing a handover test. This is the kind of debug logs that I > got : > > http://www.divshare.com/download/6200509-560 > > This is another debug logfile, but with my own debug logs added in the > sctp source code : > > http://www.divshare.com/download/6200504-2e9 > > > Many thanks for your work, and I hope someone will be able to help and > shed some light on this problem :-) > > > Aman Jassal > > _______________________________________________ > 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 Mon Dec 29 13:20:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C44D106564A for ; Mon, 29 Dec 2008 13:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0C09A8FC14 for ; Mon, 29 Dec 2008 13:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1363441C65E; Mon, 29 Dec 2008 14:20:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id flvQapWkai6g; Mon, 29 Dec 2008 14:20:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B7B0241C64C; Mon, 29 Dec 2008 14:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C0E5A4448D5; Mon, 29 Dec 2008 13:19:16 +0000 (UTC) Date: Mon, 29 Dec 2008 13:19:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <20081229124113.A28465@maildrop.int.zabbadoz.net> Message-ID: <20081229131719.K28465@maildrop.int.zabbadoz.net> References: <204586.11713.qm@web83809.mail.sp1.yahoo.com> <20081229124113.A28465@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 13:20:07 -0000 On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > On Mon, 29 Dec 2008, Gabe wrote: > >> Anyone know what causes this error message? >> >> +ipsec_common_input: no key association found for SA >> 69.x.x.x[0]/04e317a1/50 > > from what I remember without looking, this means that you ahve an > IPsec policy for src/dst but no SA matching this pair or rather no > matching destination + protocol + security parameter index (see rfc2401). > > The easiest thing you can do is to check > setkey -Da > for this tripple the time the printf happens. > > The first thing in the printf is your destination IP (your local side), > the next is the SPI in hex and last is the protocol (50 == ESP). With > that you can see if what the peer sends you is what you negotiated/expected. > > Are you using static keying or an ike daemon like racoon? > Do this happen for all packets or just randomly or exactly every n > minutes/hours? > > If you find an exact match of the triplet in setkey -Da you may also > want to check if there is another one and/or the state of the entry/entries > (state=.. at the end of the fourth line). > If it's not "mature" check the time ralted values to see if there is > an expiry problem.. One more thing - you may want to flip the sysctl to net.key.preferred_oldsa=0 and see if that makes a change. But beware - this is going to affect all your peers, not just one, so if you have 99 working and 1 not you'll most likely kill the other 99. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 13:36:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 186211065674 for ; Mon, 29 Dec 2008 13:36:37 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mx1.freebsd.org (Postfix) with ESMTP id 803CE8FC08 for ; Mon, 29 Dec 2008 13:36:34 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Dec 2008 14:36:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Dec 2008 14:36:26 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> In-Reply-To: <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP : problems in sending ASCONF chunks Thread-Index: AclptqdGu6SS40LvT2KApvdAWLta7gAAlsXg References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> From: To: X-OriginalArrivalTime: 29 Dec 2008 13:36:28.0157 (UTC) FILETIME=[73A18AD0:01C969BA] Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: RE: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 13:36:37 -0000 Hello M.T=FCxen, No, only the PC is running under FreeBSD 7.0. T is running under Linux = (kernel version is 2.6.21 and the distribution used is Fedora Core 7). = SCTP is running on T thanks to the lksctp implementation, we loaded the = sctp module on it and made the necessary configurations so that it is = loaded at boot time. Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not = exactly sure if it has an effect on my tests. Kind regards Aman Jassal=20 -----Message d'origine----- De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 =C0 : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, = wrote: > Hi all, > > I have been working with SCTP and more specifically with the mobility=20 > features of SCTP at my work. Basically, I have been trying to use SCTP = > to perform handover tests between 2 separate Wifi networks. I use IPv6 = > for all my tests. > > I have a local LAN (wired-network), on which I have 3 machines, one of = > them is the machine I use to communicate with for the tests (I'll call = > it T to make things simple), and the other two are used as Wifi Access = > Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I=20 > set up both Access Points to send Router Advertisement messages=20 > periodically (minimum of 3 seconds, maximum of 4 seconds). That way I=20 > can have automatic address reconfiguration when I connect to either of = > the access points. > > The aim of my tests is to use a PC, connect to Wifi1 (for example),=20 > launch an SCTP association with T (T sends data to my PC), and then=20 > perform a handover on Wifi2. I do make address reconfiguration during=20 > the handover process. The important point is that I work with only ONE = > address on my network interface. Before I start my tests, I set the=20 > following sysctl parameters : > > # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w=20 > net.inet.sctp.mobility_fasthandoff=3D1 > # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is to dump > messages in /var/log/messages) > > net.inet.sctp.auto_asconf is set to 1 by default. > > I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful=20 > but I'm trying to be thorough. This is the script I use to perform=20 > handover > : > > ifconfig rum0 inet6 delete ifconfig rum0 ssid target access point> route del -inet6 default rtsol=20 > rum0 > > If I'm not mistaken, the PC should have sent an ASCONF chunk to=20 > perform dynamic address reconfiguration. However what I observed is=20 > that nothing happens. No ASCONF chunks are sent, and therefore, T=20 > doesn't ever know that it should send data on the PC's newly acquired=20 > address. > > I tried to investigate the problem myself, by adding some debug logs=20 > in the sctp source code (to see which functions are called during the=20 > handover process), and it seems as if the kernel doesn't ever add an=20 > ASCONF chunk to send in its queue... But that's just my understanding=20 > of the problem... > > I looked up in the CVS repository for answers, and to see the various=20 > changes that were gradually brought on the code. There, I noticed that = > on the revision dating 24th July 2007, changes were made for dynamic=20 > address reconfiguration : "Change behaviour so that when the last=20 > address is deleted (auto-asconf on a boudall endpoint) no action is=20 > taken until an address is added ; at that time an ASCONF add+delete is = > sent (if the asoc is still up)" > > In my humble opinion, this is exactly the case that corresponds to my=20 > handover scenario. But I just haven't been able to successfully=20 > perform it because I don't seem to send any ASCONF chunk. I'm=20 > struggling to understand why I do not see any ASCONF chunk sent. > > If it can help, I'm also attaching links to the kind of debug logs I=20 > got when performing a handover test. This is the kind of debug logs=20 > that I got : > > http://www.divshare.com/download/6200509-560 > > This is another debug logfile, but with my own debug logs added in the = > sctp source code : > > http://www.divshare.com/download/6200504-2e9 > > > Many thanks for your work, and I hope someone will be able to help and = > shed some light on this problem :-) > > > Aman Jassal > > _______________________________________________ > 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 Mon Dec 29 14:18:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27AE81065670 for ; Mon, 29 Dec 2008 14:18:37 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83814.mail.sp1.yahoo.com (web83814.mail.sp1.yahoo.com [69.147.85.91]) by mx1.freebsd.org (Postfix) with SMTP id 00C9D8FC16 for ; Mon, 29 Dec 2008 14:18:36 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 87595 invoked by uid 60001); 29 Dec 2008 14:18:36 -0000 Received: from [69.43.143.172] by web83814.mail.sp1.yahoo.com via HTTP; Mon, 29 Dec 2008 06:18:36 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.218.2 Date: Mon, 29 Dec 2008 06:18:36 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <847488.86907.qm@web83814.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 14:18:37 -0000 > From: Bjoern A. Zeeb > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Monday, December 29, 2008 5:19:16 AM > Subject: Re: +ipsec_common_input: no key association found for SA > > On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > > > On Mon, 29 Dec 2008, Gabe wrote: > > > >> Anyone know what causes this error message? > >> > >> +ipsec_common_input: no key association found for SA > >> 69.x.x.x[0]/04e317a1/50 > > > > from what I remember without looking, this means that you ahve an > > IPsec policy for src/dst but no SA matching this pair or rather no > > matching destination + protocol + security parameter index (see rfc2401). > > > > The easiest thing you can do is to check > > setkey -Da > > for this tripple the time the printf happens. > > > > The first thing in the printf is your destination IP (your local side), > > the next is the SPI in hex and last is the protocol (50 == ESP). With > > that you can see if what the peer sends you is what you negotiated/expected. > > > > Are you using static keying or an ike daemon like racoon? > > Do this happen for all packets or just randomly or exactly every n > > minutes/hours? > > > > If you find an exact match of the triplet in setkey -Da you may also > > want to check if there is another one and/or the state of the entry/entries > > (state=.. at the end of the fourth line). > > If it's not "mature" check the time ralted values to see if there is > > an expiry problem.. This is what setkey -Da returns: box# setkey -Da Invalid extension type Invalid extension type box# I only have one peer (site to site link) and this appears to happen sporadically with no particular pattern that I can figure out. I also tried rebuilding the ipsec-tools port as a just in case and that made no change. This is some more log info: Dec 29 05:50:37 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/03e4aece/50 Dec 29 05:50:39 box last message repeated 64 times Dec 29 05:51:33 box kernel: WARNING: pseudo-random number generator used for IPsec processing Dec 29 05:54:54 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0cb33e2b/50 Dec 29 05:54:56 box last message repeated 8 times Dec 29 06:07:32 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0c4ccc0d/50 Dec 29 06:07:44 box last message repeated 241 times This started happening after I patched the kernel for NAT_T and enabled NAT_T on racoon, perhaps the natt_keepalive is too long at 20 seconds? Here is the racoon.con: padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; natt_keepalive 20 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listening on { isakmp 69.x.x.x [500]; isakmp_natt 69.x.x.x [4500]; } remote 69.x.x.x [500] { exchange_mode main,base; doi ipsec_doi; situation identity_only; my_identifier address 69.x.x.x; peers_identifier address 69.x.x.x; lifetime time 12 hour; passive off; proposal_check obey; nat_traversal on; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 24 hours; dh_group 1; } } sainfo (address 192.168.10.0/24 any address 192.168.20.0/24 any) # address $network/$netmask $type addres s $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; Thanks in advance, /gabe > > One more thing - you may want to flip the sysctl to > net.key.preferred_oldsa=0 > and see if that makes a change. But beware - this is going to affect > all your peers, not just one, so if you have 99 working and 1 not > you'll most likely kill the other 99. > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 14:31:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89F8E1065670 for ; Mon, 29 Dec 2008 14:31:31 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83812.mail.sp1.yahoo.com (web83812.mail.sp1.yahoo.com [69.147.85.87]) by mx1.freebsd.org (Postfix) with SMTP id 619FE8FC19 for ; Mon, 29 Dec 2008 14:31:31 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 54433 invoked by uid 60001); 29 Dec 2008 14:31:31 -0000 X-YMail-OSG: kxOBN5MVM1lV6VH9QFhZxJFvVMhh9UUOEqrFmpzkRhJhTGDjiMOC0Mja1rAiOmpC4G8OEaSjLtoQZb1v8aN3OlQUethhZWxcTssHCfH8f0OLfC7Cr1qK6vZj9_rWoLARTqYf3njApZA1dkefdUZyLNgD9rYMM6nGnbVUt_t09S8HrFyyo_ypLBSpSg6jVQ-- Received: from [69.43.143.172] by web83812.mail.sp1.yahoo.com via HTTP; Mon, 29 Dec 2008 06:31:30 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.218.2 Date: Mon, 29 Dec 2008 06:31:30 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <249410.54381.qm@web83812.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 14:31:31 -0000 > To: Bjoern A. Zeeb > Cc: freebsd-net@freebsd.org > Sent: Monday, December 29, 2008 6:18:36 AM > Subject: Re: +ipsec_common_input: no key association found for SA > > > From: Bjoern A. Zeeb > > To: Gabe > > Cc: freebsd-net@freebsd.org > > Sent: Monday, December 29, 2008 5:19:16 AM > > Subject: Re: +ipsec_common_input: no key association found for SA > > > > On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > > > > > On Mon, 29 Dec 2008, Gabe wrote: > > > > > >> Anyone know what causes this error message? > > >> > > >> +ipsec_common_input: no key association found for SA > > >> 69.x.x.x[0]/04e317a1/50 > > > > > > from what I remember without looking, this means that you ahve an > > > IPsec policy for src/dst but no SA matching this pair or rather no > > > matching destination + protocol + security parameter index (see rfc2401). > > > > > > The easiest thing you can do is to check > > > setkey -Da > > > for this tripple the time the printf happens. > > > > > > The first thing in the printf is your destination IP (your local side), > > > the next is the SPI in hex and last is the protocol (50 == ESP). With > > > that you can see if what the peer sends you is what you negotiated/expected. > > > > > > Are you using static keying or an ike daemon like racoon? > > > Do this happen for all packets or just randomly or exactly every n > > > minutes/hours? > > > > > > If you find an exact match of the triplet in setkey -Da you may also > > > want to check if there is another one and/or the state of the entry/entries > > > (state=.. at the end of the fourth line). > > > If it's not "mature" check the time ralted values to see if there is > > > an expiry problem.. > > This is what setkey -Da returns: > box# setkey -Da > Invalid extension type > Invalid extension type > box# > > I only have one peer (site to site link) and this appears to happen sporadically > with no particular pattern that I can figure out. I also tried rebuilding the > ipsec-tools port as a just in case and that made no change. This is some more > log info: > > Dec 29 05:50:37 box kernel: ipsec_common_input: no key association found for SA > 69.x.x.x[0]/03e4aece/50 > Dec 29 05:50:39 box last message repeated 64 times > Dec 29 05:51:33 box kernel: WARNING: pseudo-random number generator used for > IPsec processing > Dec 29 05:54:54 box kernel: ipsec_common_input: no key association found for SA > 69.x.x.x[0]/0cb33e2b/50 > Dec 29 05:54:56 box last message repeated 8 times > Dec 29 06:07:32 box kernel: ipsec_common_input: no key association found for SA > 69.x.x.x[0]/0c4ccc0d/50 > Dec 29 06:07:44 box last message repeated 241 times > > This started happening after I patched the kernel for NAT_T and enabled NAT_T on > racoon, perhaps the natt_keepalive is too long at 20 seconds? > > Here is the racoon.con: > > padding # options are not to be changed > { > maximum_length 20; > randomize off; > strict_check off; > exclusive_tail off; > > } > > timer # timing options. change as needed > { > counter 5; > interval 20 sec; > persend 1; > natt_keepalive 20 sec; > phase1 30 sec; > phase2 15 sec; > } > > listen # address [port] that racoon will listening on > { > isakmp 69.x.x.x [500]; > isakmp_natt 69.x.x.x [4500]; > } > > remote 69.x.x.x [500] > { > exchange_mode main,base; > doi ipsec_doi; > situation identity_only; > my_identifier address 69.x.x.x; > peers_identifier address 69.x.x.x; > lifetime time 12 hour; > passive off; > proposal_check obey; > nat_traversal on; > generate_policy off; > > proposal { > encryption_algorithm blowfish; > hash_algorithm md5; > authentication_method pre_shared_key; > lifetime time 24 hours; > dh_group 1; > } > } > > sainfo (address 192.168.10.0/24 any address 192.168.20.0/24 any) > # address $network/$netmask $type addres > s $network/$netmask $type ( $type being any or esp) > { # $network must be the two internal networks you > are joining. > pfs_group 1; > lifetime time 36000 sec; > encryption_algorithm blowfish,3des,des; > authentication_algorithm hmac_md5,hmac_sha1; > compression_algorithm deflate; > > Thanks in advance, > > /gabe > > > > > One more thing - you may want to flip the sysctl to > > net.key.preferred_oldsa=0 > > and see if that makes a change. But beware - this is going to affect > > all your peers, not just one, so if you have 99 working and 1 not > > you'll most likely kill the other 99. > > > > /bz > > > > -- > > Bjoern A. Zeeb The greatest risk is not taking one. > I guess more importantly would be the ipsec configuration: spdadd 192.168.10.0/24 192.168.10.165/32 any -P in none; spdadd 192.168.10.165/32 192.168.10.0/24 any -P out none; spdadd 192.168.10.0/24 192.168.20.0/24 any -P out ipsec esp/tunnel/box-box2/unique; spdadd 192.168.20.0/24 192.168.10.0/24 any -P in ipsec esp/tunnel/box-box2/unique; "box" being the server with the error message and box2 being the server at the end, which also has this error message. /gabe From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 15:44:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D8C106564A for ; Mon, 29 Dec 2008 15:44:09 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 24FE68FC12 for ; Mon, 29 Dec 2008 15:44:09 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 35DF5B038097 for ; Mon, 29 Dec 2008 10:44:08 -0500 (EST) Thread-Index: AclpzEkeqItKNHt8S4uy8iCkMg9XwQ== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Dec 2008 10:44:07 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 53B038E297; Mon, 29 Dec 2008 09:44:07 -0600 (CST) Date: Mon, 29 Dec 2008 09:44:07 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20081229154406.GC16134@verio.net> Content-class: urn:content-classes:message Mail-Followup-To: freebsd-net@freebsd.org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Importance: normal Priority: normal References: <249410.54381.qm@web83812.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <249410.54381.qm@web83812.mail.sp1.yahoo.com> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 29 Dec 2008 15:44:07.0695 (UTC) FILETIME=[491249F0:01C969CC] Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 15:44:09 -0000 Gabe wrote: > > spdadd 192.168.10.0/24 192.168.20.0/24 any -P out ipsec esp/tunnel/box-box2/unique; > spdadd 192.168.20.0/24 192.168.10.0/24 any -P in ipsec esp/tunnel/box-box2/unique; One or the other of these should have "box2-box" in place of "box-box2". Though this may just be an information-hiding typo on your part. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 15:48:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13D4E106566B for ; Mon, 29 Dec 2008 15:48:40 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE4B8FC24 for ; Mon, 29 Dec 2008 15:48:39 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [IPv6:2002:508f:e9a7::21e:c2ff:fe00:76c8] (unknown [IPv6:2002:508f:e9a7:0:21e:c2ff:fe00:76c8]) by mail-n.franken.de (Postfix) with ESMTP id A092E1C0C0BD4; Mon, 29 Dec 2008 16:48:37 +0100 (CET) Message-Id: <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: In-Reply-To: <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 16:48:36 +0100 References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 15:48:40 -0000 Hi Aman, I'm not that familiar with the Linux box configuration. If you look at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and the SCTP-AUTH extension? Both are required... Best regards Michael On Dec 29, 2008, at 2:36 PM, = wrote: > > Hello M.T=FCxen, > > No, only the PC is running under FreeBSD 7.0. T is running under =20 > Linux (kernel version is 2.6.21 and the distribution used is Fedora =20= > Core 7). SCTP is running on T thanks to the lksctp implementation, =20 > we loaded the sctp module on it and made the necessary =20 > configurations so that it is loaded at boot time. > > Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not =20= > exactly sure if it has an effect on my tests. > > Kind regards > > > Aman Jassal > > -----Message d'origine----- > De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 > =C0 : zze-Abac JASSAL A ext RD-RESA-ISS > Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS > Objet : Re: SCTP : problems in sending ASCONF chunks > > Hi, > > are both machines (T and you PC) running FreeBSD? > > Best regards > Michael > > On Dec 29, 2008, at 12:33 PM, = > wrote: > >> Hi all, >> >> I have been working with SCTP and more specifically with the mobility >> features of SCTP at my work. Basically, I have been trying to use =20 >> SCTP >> to perform handover tests between 2 separate Wifi networks. I use =20 >> IPv6 >> for all my tests. >> >> I have a local LAN (wired-network), on which I have 3 machines, one =20= >> of >> them is the machine I use to communicate with for the tests (I'll =20 >> call >> it T to make things simple), and the other two are used as Wifi =20 >> Access >> Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I >> set up both Access Points to send Router Advertisement messages >> periodically (minimum of 3 seconds, maximum of 4 seconds). That way I >> can have automatic address reconfiguration when I connect to either =20= >> of >> the access points. >> >> The aim of my tests is to use a PC, connect to Wifi1 (for example), >> launch an SCTP association with T (T sends data to my PC), and then >> perform a handover on Wifi2. I do make address reconfiguration during >> the handover process. The important point is that I work with only =20= >> ONE >> address on my network interface. Before I start my tests, I set the >> following sysctl parameters : >> >> # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w >> net.inet.sctp.mobility_fasthandoff=3D1 >> # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is to dump >> messages in /var/log/messages) >> >> net.inet.sctp.auto_asconf is set to 1 by default. >> >> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful >> but I'm trying to be thorough. This is the script I use to perform >> handover >> : >> >> ifconfig rum0 inet6 delete ifconfig rum0 ssid > target access point> route del -inet6 default rtsol >> rum0 >> >> If I'm not mistaken, the PC should have sent an ASCONF chunk to >> perform dynamic address reconfiguration. However what I observed is >> that nothing happens. No ASCONF chunks are sent, and therefore, T >> doesn't ever know that it should send data on the PC's newly acquired >> address. >> >> I tried to investigate the problem myself, by adding some debug logs >> in the sctp source code (to see which functions are called during the >> handover process), and it seems as if the kernel doesn't ever add an >> ASCONF chunk to send in its queue... But that's just my understanding >> of the problem... >> >> I looked up in the CVS repository for answers, and to see the various >> changes that were gradually brought on the code. There, I noticed =20 >> that >> on the revision dating 24th July 2007, changes were made for dynamic >> address reconfiguration : "Change behaviour so that when the last >> address is deleted (auto-asconf on a boudall endpoint) no action is >> taken until an address is added ; at that time an ASCONF add+delete =20= >> is >> sent (if the asoc is still up)" >> >> In my humble opinion, this is exactly the case that corresponds to my >> handover scenario. But I just haven't been able to successfully >> perform it because I don't seem to send any ASCONF chunk. I'm >> struggling to understand why I do not see any ASCONF chunk sent. >> >> If it can help, I'm also attaching links to the kind of debug logs I >> got when performing a handover test. This is the kind of debug logs >> that I got : >> >> http://www.divshare.com/download/6200509-560 >> >> This is another debug logfile, but with my own debug logs added in =20= >> the >> sctp source code : >> >> http://www.divshare.com/download/6200504-2e9 >> >> >> Many thanks for your work, and I hope someone will be able to help =20= >> and >> shed some light on this problem :-) >> >> >> Aman Jassal >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 17:12:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5483D1065672 for ; Mon, 29 Dec 2008 17:12:34 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mx1.freebsd.org (Postfix) with ESMTP id D04408FC13 for ; Mon, 29 Dec 2008 17:12:33 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Dec 2008 18:12:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Dec 2008 18:12:29 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> In-Reply-To: <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP : problems in sending ASCONF chunks Thread-Index: AclpzRFAyvVPVmWaRsWWbpua9x2wUwABw5sA References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> From: To: X-OriginalArrivalTime: 29 Dec 2008 17:12:30.0552 (UTC) FILETIME=[A1D20D80:01C969D8] Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: RE: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 17:12:34 -0000 Hello M.T=FCxen, I performed a quick test and at the INIT/INIT-ACK exchange, I noticed = the following : - In the INIT chunk, the Supported Extensions Parameter field indicates = that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET and AUTH are = supported - In the INIT-ACK chunk, there is no field indicating that any of the = chunks listed above are supported... I didn't think about looking in this before >_< Since there is no indication given to my PC, perhaps my PC assumes that = T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET = and AUTH. Could it be that, because it doesn't see any Supported Extensions = Parameter field in the INIT-ACK, my PC doesn't try to send any ASCONF = chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK and AUTH = parameters in the Supported Extensions Parameter, in both the INIT and = the INIT-ACK chunks, to have the possibility of sending an ASCONF chunk = ? Kind regards Aman Jassal =20 -----Message d'origine----- De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Envoy=E9 : lundi 29 d=E9cembre 2008 16:49 =C0 : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi Aman, I'm not that familiar with the Linux box configuration. If you look at = the INIT/INIT-ACK exchange, does the Linux box support ASCONF and the = SCTP-AUTH extension? Both are required... Best regards Michael On Dec 29, 2008, at 2:36 PM, = wrote: > > Hello M.T=FCxen, > > No, only the PC is running under FreeBSD 7.0. T is running under Linux = > (kernel version is 2.6.21 and the distribution used is Fedora Core 7). = > SCTP is running on T thanks to the lksctp implementation, we loaded=20 > the sctp module on it and made the necessary configurations so that it = > is loaded at boot time. > > Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not=20 > exactly sure if it has an effect on my tests. > > Kind regards > > > Aman Jassal > > -----Message d'origine----- > De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 > =C0 : zze-Abac JASSAL A ext RD-RESA-ISS > Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet :=20 > Re: SCTP : problems in sending ASCONF chunks > > Hi, > > are both machines (T and you PC) running FreeBSD? > > Best regards > Michael > > On Dec 29, 2008, at 12:33 PM, = > wrote: > >> Hi all, >> >> I have been working with SCTP and more specifically with the mobility = >> features of SCTP at my work. Basically, I have been trying to use=20 >> SCTP to perform handover tests between 2 separate Wifi networks. I=20 >> use >> IPv6 >> for all my tests. >> >> I have a local LAN (wired-network), on which I have 3 machines, one=20 >> of them is the machine I use to communicate with for the tests (I'll=20 >> call it T to make things simple), and the other two are used as Wifi=20 >> Access Points (say Wifi1 and Wifi2 respectively). Since I work with=20 >> IPv6, I set up both Access Points to send Router Advertisement=20 >> messages periodically (minimum of 3 seconds, maximum of 4 seconds).=20 >> That way I can have automatic address reconfiguration when I connect=20 >> to either of the access points. >> >> The aim of my tests is to use a PC, connect to Wifi1 (for example),=20 >> launch an SCTP association with T (T sends data to my PC), and then=20 >> perform a handover on Wifi2. I do make address reconfiguration during = >> the handover process. The important point is that I work with only=20 >> ONE address on my network interface. Before I start my tests, I set=20 >> the following sysctl parameters : >> >> # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w >> net.inet.sctp.mobility_fasthandoff=3D1 >> # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is to dump >> messages in /var/log/messages) >> >> net.inet.sctp.auto_asconf is set to 1 by default. >> >> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful=20 >> but I'm trying to be thorough. This is the script I use to perform=20 >> handover >> : >> >> ifconfig rum0 inet6 delete ifconfig rum0 ssid > target access point> route del -inet6 default rtsol=20 >> rum0 >> >> If I'm not mistaken, the PC should have sent an ASCONF chunk to=20 >> perform dynamic address reconfiguration. However what I observed is=20 >> that nothing happens. No ASCONF chunks are sent, and therefore, T=20 >> doesn't ever know that it should send data on the PC's newly acquired = >> address. >> >> I tried to investigate the problem myself, by adding some debug logs=20 >> in the sctp source code (to see which functions are called during the = >> handover process), and it seems as if the kernel doesn't ever add an=20 >> ASCONF chunk to send in its queue... But that's just my understanding = >> of the problem... >> >> I looked up in the CVS repository for answers, and to see the various = >> changes that were gradually brought on the code. There, I noticed=20 >> that on the revision dating 24th July 2007, changes were made for=20 >> dynamic address reconfiguration : "Change behaviour so that when the=20 >> last address is deleted (auto-asconf on a boudall endpoint) no action = >> is taken until an address is added ; at that time an ASCONF=20 >> add+delete is sent (if the asoc is still up)" >> >> In my humble opinion, this is exactly the case that corresponds to my = >> handover scenario. But I just haven't been able to successfully=20 >> perform it because I don't seem to send any ASCONF chunk. I'm=20 >> struggling to understand why I do not see any ASCONF chunk sent. >> >> If it can help, I'm also attaching links to the kind of debug logs I=20 >> got when performing a handover test. This is the kind of debug logs=20 >> that I got : >> >> http://www.divshare.com/download/6200509-560 >> >> This is another debug logfile, but with my own debug logs added in=20 >> the sctp source code : >> >> http://www.divshare.com/download/6200504-2e9 >> >> >> Many thanks for your work, and I hope someone will be able to help=20 >> and shed some light on this problem :-) >> >> >> Aman Jassal >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 17:59:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B918A106566C for ; Mon, 29 Dec 2008 17:59:49 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id D1BC58FC1C for ; Mon, 29 Dec 2008 17:59:48 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [IPv6:2002:508f:e9a7::21e:c2ff:fe00:76c8] (unknown [IPv6:2002:508f:e9a7:0:21e:c2ff:fe00:76c8]) by mail-n.franken.de (Postfix) with ESMTP id 75D341C0B460C; Mon, 29 Dec 2008 18:59:45 +0100 (CET) Message-Id: <835C2156-9DE3-4C96-94F0-C7E3AF63A1BD@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: In-Reply-To: <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 29 Dec 2008 18:59:43 +0100 References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 17:59:49 -0000 Hi Aman, comments in-line. Best regards Michael On Dec 29, 2008, at 6:12 PM, = wrote: > > Hello M.T=FCxen, > > I performed a quick test and at the INIT/INIT-ACK exchange, I =20 > noticed the following : > > - In the INIT chunk, the Supported Extensions Parameter field =20 > indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, =20 > STREAM_RESET and AUTH are supported OK. That is the FreeBSD box. > > - In the INIT-ACK chunk, there is no field indicating that any of =20 > the chunks listed above are supported... So it does not support ASCONF and AUTH. At least on a Fedora 9 box you need to enable ADD-IP by setting the sysctl variable net.sctp.addip_enable to 1. To enable SCTP-AUTH you need to set the sysctl variable net.sctp.auth_enable to 1. I'm not sure whether the Linux box support SCTP-AUTH or not... So the second step might not work. If this is the case you can disable the AUTH requirement for ASCONF chunks by setting on the FreeBSD box the =20 sysctl variable net.inet.sctp.asconf_auth_nochk to 1 Let me know if this works... > > > I didn't think about looking in this before >_< > > Since there is no indication given to my PC, perhaps my PC assumes =20 > that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, =20 > STREAM_RESET and AUTH. Correct. At least some of the extension are not enabled. > > > Could it be that, because it doesn't see any Supported Extensions =20 > Parameter field in the INIT-ACK, my PC doesn't try to send any =20 > ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK =20= > and AUTH parameters in the Supported Extensions Parameter, in both =20 > the INIT and the INIT-ACK chunks, to have the possibility of sending =20= > an ASCONF chunk ? In principle, yes! You can work around the AUTH chunks as indicated =20 above, but this violates the specification and is only supported to interwork with =20 legacy implementations. > > > > Kind regards > > > Aman Jassal > > > -----Message d'origine----- > De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9 : lundi 29 d=E9cembre 2008 16:49 > =C0 : zze-Abac JASSAL A ext RD-RESA-ISS > Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS > Objet : Re: SCTP : problems in sending ASCONF chunks > > Hi Aman, > > I'm not that familiar with the Linux box configuration. If you look =20= > at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and =20= > the SCTP-AUTH extension? Both are required... > > Best regards > Michael > On Dec 29, 2008, at 2:36 PM, = > wrote: > >> >> Hello M.T=FCxen, >> >> No, only the PC is running under FreeBSD 7.0. T is running under =20 >> Linux >> (kernel version is 2.6.21 and the distribution used is Fedora Core =20= >> 7). >> SCTP is running on T thanks to the lksctp implementation, we loaded >> the sctp module on it and made the necessary configurations so that =20= >> it >> is loaded at boot time. >> >> Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not >> exactly sure if it has an effect on my tests. >> >> Kind regards >> >> >> Aman Jassal >> >> -----Message d'origine----- >> De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] >> Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 >> =C0 : zze-Abac JASSAL A ext RD-RESA-ISS >> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : >> Re: SCTP : problems in sending ASCONF chunks >> >> Hi, >> >> are both machines (T and you PC) running FreeBSD? >> >> Best regards >> Michael >> >> On Dec 29, 2008, at 12:33 PM, = >> wrote: >> >>> Hi all, >>> >>> I have been working with SCTP and more specifically with the =20 >>> mobility >>> features of SCTP at my work. Basically, I have been trying to use >>> SCTP to perform handover tests between 2 separate Wifi networks. I >>> use >>> IPv6 >>> for all my tests. >>> >>> I have a local LAN (wired-network), on which I have 3 machines, one >>> of them is the machine I use to communicate with for the tests (I'll >>> call it T to make things simple), and the other two are used as Wifi >>> Access Points (say Wifi1 and Wifi2 respectively). Since I work with >>> IPv6, I set up both Access Points to send Router Advertisement >>> messages periodically (minimum of 3 seconds, maximum of 4 seconds). >>> That way I can have automatic address reconfiguration when I connect >>> to either of the access points. >>> >>> The aim of my tests is to use a PC, connect to Wifi1 (for example), >>> launch an SCTP association with T (T sends data to my PC), and then >>> perform a handover on Wifi2. I do make address reconfiguration =20 >>> during >>> the handover process. The important point is that I work with only >>> ONE address on my network interface. Before I start my tests, I set >>> the following sysctl parameters : >>> >>> # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w >>> net.inet.sctp.mobility_fasthandoff=3D1 >>> # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is = to dump >>> messages in /var/log/messages) >>> >>> net.inet.sctp.auto_asconf is set to 1 by default. >>> >>> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful >>> but I'm trying to be thorough. This is the script I use to perform >>> handover >>> : >>> >>> ifconfig rum0 inet6 delete ifconfig rum0 ssid >> target access point> route del -inet6 default rtsol >>> rum0 >>> >>> If I'm not mistaken, the PC should have sent an ASCONF chunk to >>> perform dynamic address reconfiguration. However what I observed is >>> that nothing happens. No ASCONF chunks are sent, and therefore, T >>> doesn't ever know that it should send data on the PC's newly =20 >>> acquired >>> address. >>> >>> I tried to investigate the problem myself, by adding some debug logs >>> in the sctp source code (to see which functions are called during =20= >>> the >>> handover process), and it seems as if the kernel doesn't ever add an >>> ASCONF chunk to send in its queue... But that's just my =20 >>> understanding >>> of the problem... >>> >>> I looked up in the CVS repository for answers, and to see the =20 >>> various >>> changes that were gradually brought on the code. There, I noticed >>> that on the revision dating 24th July 2007, changes were made for >>> dynamic address reconfiguration : "Change behaviour so that when the >>> last address is deleted (auto-asconf on a boudall endpoint) no =20 >>> action >>> is taken until an address is added ; at that time an ASCONF >>> add+delete is sent (if the asoc is still up)" >>> >>> In my humble opinion, this is exactly the case that corresponds to =20= >>> my >>> handover scenario. But I just haven't been able to successfully >>> perform it because I don't seem to send any ASCONF chunk. I'm >>> struggling to understand why I do not see any ASCONF chunk sent. >>> >>> If it can help, I'm also attaching links to the kind of debug logs I >>> got when performing a handover test. This is the kind of debug logs >>> that I got : >>> >>> http://www.divshare.com/download/6200509-560 >>> >>> This is another debug logfile, but with my own debug logs added in >>> the sctp source code : >>> >>> http://www.divshare.com/download/6200504-2e9 >>> >>> >>> Many thanks for your work, and I hope someone will be able to help >>> and shed some light on this problem :-) >>> >>> >>> Aman Jassal >>> >>> _______________________________________________ >>> 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 Mon Dec 29 18:53:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3A91065676 for ; Mon, 29 Dec 2008 18:53:39 +0000 (UTC) (envelope-from pulse@mx.plaxo.com) Received: from mx.plaxo.com (mx.plaxo.com [66.151.128.13]) by mx1.freebsd.org (Postfix) with ESMTP id 83D988FC27 for ; Mon, 29 Dec 2008 18:53:39 +0000 (UTC) (envelope-from pulse@mx.plaxo.com) Received: from localhost by mx.plaxo.com (StrongMail Enterprise 3.2.2.2(3.00.287)); Mon, 29 Dec 2008 10:53:36 -0800 X-VirtualServer: Pulse, mx.plaxo.com, 10.1.6.55 X-PlaxoMailType: Pulse X-Destination-ID: freebsd-net@freebsd.org X-MailingID: 00000::00000::00000::00000::::1769306 X-SMHeaderMap: mid="X-MailingID" X-SMFBL: ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc= From: "Kayven Riese" To: freebsd-net@freebsd.org Message-Id: X-VirtualServerGroup: Pulse Errors-To: pulse@mx.plaxo.com Date: Mon, 29 Dec 2008 10:17:39 -0800 X-Mailer: XPM4 v.0.3 < www.xpertmailer.com > MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kayven Riese added you as a connection on Plaxo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kayvey@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 18:53:40 -0000 Kayven Riese wants to add you as a connection on Plaxo. To accept this connection request, go to: http://www.plaxo.com/invite?i=3D55229637&k=3D947635066&l=3Den&src=3Demail&e= t=3D1&est=3Dnolevels&etv=3Dnnic1b2&el=3Den Thanks! The Plaxo team More than 20 million people use Plaxo to keep in touch with the people they care about.=20 Don't want to receive emails from Plaxo any more? Go to: http://www.plaxo.com/stop?src=3Demail&et=3D1&est=3Dnolevels&etv=3Dnnic1b2&e= l=3Den From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 22:20:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44CB3106566B for ; Mon, 29 Dec 2008 22:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id F20708FC21 for ; Mon, 29 Dec 2008 22:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BB31C41C7B8; Mon, 29 Dec 2008 23:20:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id fjXm1g1xU8Q4; Mon, 29 Dec 2008 23:20:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5E50E41C7B7; Mon, 29 Dec 2008 23:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BAAC24448D5; Mon, 29 Dec 2008 22:18:17 +0000 (UTC) Date: Mon, 29 Dec 2008 22:18:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <847488.86907.qm@web83814.mail.sp1.yahoo.com> Message-ID: <20081229221714.G28465@maildrop.int.zabbadoz.net> References: <847488.86907.qm@web83814.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 22:20:08 -0000 On Mon, 29 Dec 2008, Gabe wrote: > This is what setkey -Da returns: > box# setkey -Da > Invalid extension type > Invalid extension type > box# you are running with the NAT-T patch (as I see you say further down). Try /usr/local/sbin/setkey -Da in that case. -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 22:20:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 417711065672 for ; Mon, 29 Dec 2008 22:20:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 055ED8FC1F for ; Mon, 29 Dec 2008 22:20:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 8912846B17; Mon, 29 Dec 2008 17:20:40 -0500 (EST) Date: Mon, 29 Dec 2008 22:20:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yony Yossef In-Reply-To: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> Message-ID: References: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: eitans@mellanox.co.il, freebsd-net@freebsd.org, Yehonatan Yossef , liranl@mellanox.co.il, yevgenyp@mellanox.co.il Subject: Re: net.inet.udp.blackhole issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 22:20:42 -0000 On Wed, 24 Dec 2008, Yony Yossef wrote: > I'm facing lots of UDP "Connection refused" errors while running multistream > iperf test. Analyzing it with wireshark showed several "ICMP Port > Unreachable" problems. > > I've overriden it with "sysctl net.inet.udp.blackhole=1", but I'm not sure > this is the correct thing to do, I feel like I've sweeped the problem under > the carpet. > > PS - I see similar failures with TCP bidirectional iperf test, it can also > be overriden by "sysctl net.inet.tcp.blackhole=1". > > My question is - can it be a NIC problem? If so, how can a driver problem > cause an iperf UDP socket to be in a "non listening state"? Hi Yony: This is fairly unlikely to be a NIC problem, although anything is possible in software. I'm not familiar with iperf, but generally speaking ICMP port unreachable is a result of packets arriving at a closed socket; net.inet.udp.blackhole suppresses that ICMP: if (udp_blackhole) goto badheadlocked; if (badport_bandlim(BANDLIM_ICMP_UNREACH) < 0) goto badheadlocked; *ip = save_ip; ip->ip_len += iphlen; icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); I think I'd suspect an application bug/feature, in which socket gets closed and opened during execution and once in a while a datagram is delivered in that window. Perhaps packets are being delivered with a non-trivial delay causing them to arrive after the application has timed out waiting for it? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 22:23:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6A81065670 for ; Mon, 29 Dec 2008 22:23:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1342C8FC16 for ; Mon, 29 Dec 2008 22:23:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 42EC941C7AE; Mon, 29 Dec 2008 23:23:20 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id EBydyPG8XKul; Mon, 29 Dec 2008 23:23:19 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E260E41C7BB; Mon, 29 Dec 2008 23:23:19 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E609B4448D5; Mon, 29 Dec 2008 22:20:47 +0000 (UTC) Date: Mon, 29 Dec 2008 22:20:47 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <249410.54381.qm@web83812.mail.sp1.yahoo.com> Message-ID: <20081229221821.O28465@maildrop.int.zabbadoz.net> References: <249410.54381.qm@web83812.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 22:23:21 -0000 On Mon, 29 Dec 2008, Gabe wrote: > I guess more importantly would be the ipsec configuration: > > spdadd 192.168.10.0/24 192.168.10.165/32 any -P in none; > spdadd 192.168.10.165/32 192.168.10.0/24 any -P out none; > > spdadd 192.168.10.0/24 192.168.20.0/24 any -P out ipsec esp/tunnel/box-box2/unique; > spdadd 192.168.20.0/24 192.168.10.0/24 any -P in ipsec esp/tunnel/box-box2/unique; > > "box" being the server with the error message and box2 being the server at the end, which also has this error message. And I assume there is a typo in the spdadd lines. 1) I cannot see why you'd need the first two if the two tuples are your entire policy. 2) for the 2nd tuple both are box-box2 but one should be box2-box (but I assume this is a typo into the mail). -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 22:30:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D5910656F6 for ; Mon, 29 Dec 2008 22:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id B57238FC08 for ; Mon, 29 Dec 2008 22:30:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E51E341C7B0; Mon, 29 Dec 2008 23:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id y2Ureq+6sJL7; Mon, 29 Dec 2008 23:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9348741C7BB; Mon, 29 Dec 2008 23:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 240334448D5; Mon, 29 Dec 2008 22:25:33 +0000 (UTC) Date: Mon, 29 Dec 2008 22:25:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <20081229221714.G28465@maildrop.int.zabbadoz.net> Message-ID: <20081229222334.D28465@maildrop.int.zabbadoz.net> References: <847488.86907.qm@web83814.mail.sp1.yahoo.com> <20081229221714.G28465@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Dec 2008 22:30:07 -0000 On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > On Mon, 29 Dec 2008, Gabe wrote: > >> This is what setkey -Da returns: >> box# setkey -Da >> Invalid extension type >> Invalid extension type >> box# > > you are running with the NAT-T patch (as I see you say further down). > Try /usr/local/sbin/setkey -Da in that case. One more thing; if you are comparing SPIs from the log with setkey, you can also run tcpdump -s 0 -vv -ln proto 50 and it will show you something like ... ESP(spi=0x12345678,seq=0x..), so you could as well compare what you receive on the wire with what you get in the log. This would help to eliminiate the case of a promblematic patch. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 09:44:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C843106566C for ; Tue, 30 Dec 2008 09:44:29 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83813.mail.sp1.yahoo.com (web83813.mail.sp1.yahoo.com [69.147.85.89]) by mx1.freebsd.org (Postfix) with SMTP id 8BB028FC08 for ; Tue, 30 Dec 2008 09:44:29 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 25698 invoked by uid 60001); 30 Dec 2008 09:44:29 -0000 X-YMail-OSG: zNGaGakVM1nH5Qz6ijDM9_im9OSa5rkvRJqVXaM491JnVE0ruVO9NUjtZnj56GLjaAR8w5yo8utIiTCCZ16YISzZ_oZ_DJSnHTtjQw9SUWMdRHII1Oe9vFFycTaaC4gEFJGpN3YtZ5qzTt47kWSRvrOfGS52bluAGP.F3KvRtR7ZiLXM0zdDj5EkqmWW.Q-- Received: from [69.43.143.172] by web83813.mail.sp1.yahoo.com via HTTP; Tue, 30 Dec 2008 01:44:29 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.218.2 Date: Tue, 30 Dec 2008 01:44:29 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <258438.24300.qm@web83813.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 09:44:29 -0000 ----- Original Message ---- > From: Bjoern A. Zeeb > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Monday, December 29, 2008 2:25:32 PM > Subject: Re: +ipsec_common_input: no key association found for SA > > On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > > > On Mon, 29 Dec 2008, Gabe wrote: > > > >> This is what setkey -Da returns: > >> box# setkey -Da > >> Invalid extension type > >> Invalid extension type > >> box# > > > > you are running with the NAT-T patch (as I see you say further down). > > Try /usr/local/sbin/setkey -Da in that case. > > > One more thing; if you are comparing SPIs from the log with setkey, > you can also run > tcpdump -s 0 -vv -ln proto 50 > and it will show you something like > ... ESP(spi=0x12345678,seq=0x..), > so you could as well compare what you receive on the wire with what > you get in the log. This would help to eliminiate the case of a > promblematic patch. > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. Thanks for the help on this. As far as the box-box2 mistake it was no typo. This is what I've changed it to: local server: flush; spdflush; spdadd 192.168.10.0/24 192.168.20.0/24 any -P out ipsec esp/tunnel/box-box2/unique; spdadd 192.168.20.0/24 192.168.10.0/24 any -P in ipsec esp/tunnel/box2-box/unique; and on the remote server: flush; spdflush; spdadd 192.168.20.0/24 192.168.10.0/24 any -P out ipsec esp/tunnel/box2-box/unique; spdadd 192.168.10.0/24 192.168.20.0/24 any -P in ipsec esp/tunnel/box-box2/unique; However I still get the ipsec_common message albeit not as often, it appears to only be when I restart racoon now. I also tried matching the SPIs but the SPIs given by setkey -Da did not match the ones on the log. From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 12:17:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3143106566C; Tue, 30 Dec 2008 12:17:40 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 09C658FC12; Tue, 30 Dec 2008 12:17:39 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so988488ugs.39 for ; Tue, 30 Dec 2008 04:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references:subject :date:message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:in-reply-to:x-mimeole; bh=/vG8e4XHdDsYsmN6vZKYRmT/Wl5Np2yc+XNzHXAaWeM=; b=v6lkn3u+bL3yTVje3v2KZOTkmauecoSlu4evObSAtn9yh8qeZgdoLzfnv/5URH9EWm jid/UDCsOn7kyAS1m98FKRAJ9wIy0oRJO+YchDaZxHNi3lyPJkNvx6KExj8IsqC/SAdB 5pYACHXtDhMMJ0z5KR0cewb3DdjCDJF3YjLXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; b=MdPxqMb+Gcc4JiWtG1dd9buiZaK6s/2vviVXo/PN5a/i2f3N+WfZNEEUzcrGl95XRa MUFSPH/iScECnBvDULEfF6bDQyFfL0B01dDVCUASj53tsilryMeAbWpl5HNU0Mn7CcRk lMJw28zmcHkdoMM2xfYCbbb9sEK5FAdSPqdSg= Received: by 10.66.245.2 with SMTP id s2mr10108539ugh.66.1230639458851; Tue, 30 Dec 2008 04:17:38 -0800 (PST) Received: from mtllpt03 (DSL212-235-20-133.bb.netvision.net.il [212.235.20.133]) by mx.google.com with ESMTPS id q40sm37412179ugc.1.2008.12.30.04.17.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Dec 2008 04:17:37 -0800 (PST) From: "Yony Yossef" To: "'Robert Watson'" , "Yony Yossef" References: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> Date: Tue, 30 Dec 2008 14:17:29 +0200 Message-ID: <000001c96a78$9a5b3c20$220f000a@mtl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclqA7ElGmqwGnwUQnqAaLLLK9ukzQAYa/Uw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Eitan Shefi , freebsd-net@freebsd.org, Liran Liss , Yevgeny Petrilin Subject: RE: net.inet.udp.blackhole issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 12:17:40 -0000 > > I'm facing lots of UDP "Connection refused" errors while running > > multistream iperf test. Analyzing it with wireshark showed several > > "ICMP Port Unreachable" problems. > > > > I've overriden it with "sysctl net.inet.udp.blackhole=1", > but I'm not > > sure this is the correct thing to do, I feel like I've sweeped the > > problem under the carpet. > > > > PS - I see similar failures with TCP bidirectional iperf > test, it can > > also be overriden by "sysctl net.inet.tcp.blackhole=1". > > > > My question is - can it be a NIC problem? If so, how can a driver > > problem cause an iperf UDP socket to be in a "non listening state"? > > Hi Yony: > > This is fairly unlikely to be a NIC problem, although > anything is possible in software. I'm not familiar with > iperf, but generally speaking ICMP port unreachable is a > result of packets arriving at a closed socket; > net.inet.udp.blackhole suppresses that ICMP: > > if (udp_blackhole) > goto badheadlocked; > if (badport_bandlim(BANDLIM_ICMP_UNREACH) < 0) > goto badheadlocked; > *ip = save_ip; > ip->ip_len += iphlen; > icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); > > I think I'd suspect an application bug/feature, in which > socket gets closed and opened during execution and once in a > while a datagram is delivered in that window. Perhaps > packets are being delivered with a non-trivial delay causing > them to arrive after the application has timed out waiting for it? > > Robert N M Watson > Computer Laboratory > University of Cambridge > I'm talking about a simple multistream UDP iperf test. One stream always works fine. More than one UDP stream has a chance of failing because of this problem. Wireshark analysis shows no such delay and no packet loss nor corruption, for what I've seen and understood. On the other hand, same test on a 1Gig NIC (I'm using a 10Gig) doesn't suffer from this issue without the blackhole assistance. Yony From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 14:25:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D73106564A for ; Tue, 30 Dec 2008 14:25:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id D85708FC16 for ; Tue, 30 Dec 2008 14:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2BE3E41C7BF; Tue, 30 Dec 2008 15:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id WPvuLstgtsPh; Tue, 30 Dec 2008 15:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B867841C7B7; Tue, 30 Dec 2008 15:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B2A1C4448D5; Tue, 30 Dec 2008 14:24:02 +0000 (UTC) Date: Tue, 30 Dec 2008 14:24:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <258438.24300.qm@web83813.mail.sp1.yahoo.com> Message-ID: <20081230115445.A28465@maildrop.int.zabbadoz.net> References: <258438.24300.qm@web83813.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-281300904-1230643331=:28465" Content-ID: <20081230132214.U28465@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 14:25:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-281300904-1230643331=:28465 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20081230132214.Q28465@maildrop.int.zabbadoz.net> On Tue, 30 Dec 2008, Gabe wrote: >> One more thing; if you are comparing SPIs from the log with setkey, >> you can also run >> tcpdump -s 0 -vv -ln proto 50 >> and it will show you something like >> ... ESP(spi=0x12345678,seq=0x..), >> so you could as well compare what you receive on the wire with what >> you get in the log. This would help to eliminiate the case of a >> promblematic patch. > > However I still get the ipsec_common message albeit not as often, it > appears to only be when I restart racoon now. I also tried matching the > SPIs but the SPIs given by setkey -Da did not match the ones on the log. Ok, can you try running the following script and see if the output times match your racoon restarts or the log entries? You need to set your interface and the tunnel endpoint IPs (as in box/box2). /bz -- Bjoern A. Zeeb The greatest risk is not taking one. --0-281300904-1230643331=:28465 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=track-spi.sh Content-Transfer-Encoding: BASE64 Content-ID: <20081230132211.P28465@maildrop.int.zabbadoz.net> Content-Description: track-spi.sh Content-Disposition: ATTACHMENT; FILENAME=track-spi.sh IyEvYmluL3NoDQoNCklOVD1YWFgNClJFTU9URVRVTk5FTEVORFBPSU5UPWFh YS5iYmIuY2NjLmRkZA0KTVlUVU5ORUxFTkRQT0lOVD13d3cueHh4Lnl5eS56 enoNCg0KdGNwZHVtcCAtbG4gLWkgJHtJTlR9IC1zMCBzcmMgJHtSRU1PVEVU VU5ORUxFTkRQT0lOVH0gYW5kIGRzdCAke01ZVFVOTkVMRU5EUE9JTlR9IGFu ZCBwcm90byA1MCB8IFwNCglhd2sgJ0JFR0lOIHsgZGVidWc9MTsgc3BpPSJ1 bmluaXRpYWxpemVkIjsgfQ0KCQl7DQoJCQlpZiAoIS9FU1Auc3BpPS8pIHsg bmV4dDsgfQ0KCQkJc3ViKCJFU1Auc3BpPSIsICIiLCAkNik7DQoJCQlzdWIo IiwuKiIsICIiLCAkNik7DQoJCQlpZiAoJDYgPT0gIiIpIHsgaWYgKGRlYnVn KSB7IHByaW50ZiAiREVCVUc6ICVzXG4iLCAkMDsgfSBuZXh0OyB9DQoJCQlp ZiAoc3BpICE9ICQ2KSB7DQoJCQkJcHJpbnRmICIlcyBTUEkgY2hhbmdlZCAl cyAtPiAlc1xuIiwgJDEsIHNwaSwgJDY7DQoJCQkJc3BpPSQ2Ow0KCQkJfQ0K CQl9Jw0KDQojIGVuZA0K --0-281300904-1230643331=:28465-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 16:00:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF521065670 for ; Tue, 30 Dec 2008 16:00:04 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mx1.freebsd.org (Postfix) with ESMTP id B74ED8FC0C for ; Tue, 30 Dec 2008 16:00:03 +0000 (UTC) (envelope-from ajassal.ext@orange-ftgroup.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Dec 2008 16:59:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Dec 2008 16:59:58 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E09106883@ftrdmel2> In-Reply-To: <835C2156-9DE3-4C96-94F0-C7E3AF63A1BD@lurchi.franken.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP : problems in sending ASCONF chunks Thread-Index: Aclp309QnScXw1DXTMyCFYpy7k/CSAAtZFwA References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> <835C2156-9DE3-4C96-94F0-C7E3AF63A1BD@lurchi.franken.de> From: To: X-OriginalArrivalTime: 30 Dec 2008 15:59:58.0963 (UTC) FILETIME=[AA7C0430:01C96A97] Cc: freebsd-net@freebsd.org, khadija.daoud@orange-ftgroup.com Subject: RE: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 16:00:04 -0000 Hello M.T=FCxen, Today I switched T (the machine I use for testing, and that sends data = to my PC) to FreeBSD 7.0. And I was very glad to see that my SCTP hard = handover tests went through successfully :-) I am very grateful to you, for pointing out that I should check the INIT = - INIT-ACK exchange, because so far I really didn't understand why my = tests failed all the time. About lksctp : up until now, my problems were due to the fact that the = CN was running under Linux, with the lksctp implementation, and that it = didn't indicate in the INIT-ACK that it supports ASCONF, ASCONF-ACK and = AUTH chunks at least, even if we have set the parameter = net.sctp.addip_enable to 1. These are required for Dynamic Address = Reconfiguration according to the RFC and very likely in FreeBSD = implementation for sending ASCONF. I will perform tests between my PC running under FreeBSD and T running = on Fedora Core 9 to see if I have better results than what I've had so = far (since I was using Fedora Core 7). I will keep you updated :-) Again, thanks a LOT for the help you provided, I'm truly thankful for = this. Aman Jassal =20 -----Message d'origine----- De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Envoy=E9 : lundi 29 d=E9cembre 2008 19:00 =C0 : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi Aman, comments in-line. Best regards Michael On Dec 29, 2008, at 6:12 PM, = wrote: > > Hello M.T=FCxen, > > I performed a quick test and at the INIT/INIT-ACK exchange, I noticed=20 > the following : > > - In the INIT chunk, the Supported Extensions Parameter field=20 > indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET=20 > and AUTH are supported OK. That is the FreeBSD box. > > - In the INIT-ACK chunk, there is no field indicating that any of =20 > the chunks listed above are supported... So it does not support ASCONF and AUTH. At least on a Fedora 9 box you need to enable ADD-IP by setting the sysctl variable net.sctp.addip_enable to 1. To enable SCTP-AUTH you need to set the sysctl variable net.sctp.auth_enable to 1. I'm not sure whether the Linux box support SCTP-AUTH or not... So the second step might not work. If this is the case you can disable the AUTH requirement for ASCONF chunks by setting on the FreeBSD box the =20 sysctl variable net.inet.sctp.asconf_auth_nochk to 1 Let me know if this works... > > > I didn't think about looking in this before >_< > > Since there is no indication given to my PC, perhaps my PC assumes =20 > that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, =20 > STREAM_RESET and AUTH. Correct. At least some of the extension are not enabled. > > > Could it be that, because it doesn't see any Supported Extensions =20 > Parameter field in the INIT-ACK, my PC doesn't try to send any =20 > ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK =20 > and AUTH parameters in the Supported Extensions Parameter, in both =20 > the INIT and the INIT-ACK chunks, to have the possibility of sending =20 > an ASCONF chunk ? In principle, yes! You can work around the AUTH chunks as indicated =20 above, but this violates the specification and is only supported to interwork with =20 legacy implementations. > > > > Kind regards > > > Aman Jassal > > > -----Message d'origine----- > De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9 : lundi 29 d=E9cembre 2008 16:49 > =C0 : zze-Abac JASSAL A ext RD-RESA-ISS > Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS > Objet : Re: SCTP : problems in sending ASCONF chunks > > Hi Aman, > > I'm not that familiar with the Linux box configuration. If you look =20 > at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and =20 > the SCTP-AUTH extension? Both are required... > > Best regards > Michael > On Dec 29, 2008, at 2:36 PM, = > wrote: > >> >> Hello M.T=FCxen, >> >> No, only the PC is running under FreeBSD 7.0. T is running under =20 >> Linux >> (kernel version is 2.6.21 and the distribution used is Fedora Core =20 >> 7). >> SCTP is running on T thanks to the lksctp implementation, we loaded >> the sctp module on it and made the necessary configurations so that =20 >> it >> is loaded at boot time. >> >> Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not >> exactly sure if it has an effect on my tests. >> >> Kind regards >> >> >> Aman Jassal >> >> -----Message d'origine----- >> De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] >> Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 >> =C0 : zze-Abac JASSAL A ext RD-RESA-ISS >> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : >> Re: SCTP : problems in sending ASCONF chunks >> >> Hi, >> >> are both machines (T and you PC) running FreeBSD? >> >> Best regards >> Michael >> >> On Dec 29, 2008, at 12:33 PM, = >> wrote: >> >>> Hi all, >>> >>> I have been working with SCTP and more specifically with the =20 >>> mobility >>> features of SCTP at my work. Basically, I have been trying to use >>> SCTP to perform handover tests between 2 separate Wifi networks. I >>> use >>> IPv6 >>> for all my tests. >>> >>> I have a local LAN (wired-network), on which I have 3 machines, one >>> of them is the machine I use to communicate with for the tests (I'll >>> call it T to make things simple), and the other two are used as Wifi >>> Access Points (say Wifi1 and Wifi2 respectively). Since I work with >>> IPv6, I set up both Access Points to send Router Advertisement >>> messages periodically (minimum of 3 seconds, maximum of 4 seconds). >>> That way I can have automatic address reconfiguration when I connect >>> to either of the access points. >>> >>> The aim of my tests is to use a PC, connect to Wifi1 (for example), >>> launch an SCTP association with T (T sends data to my PC), and then >>> perform a handover on Wifi2. I do make address reconfiguration =20 >>> during >>> the handover process. The important point is that I work with only >>> ONE address on my network interface. Before I start my tests, I set >>> the following sysctl parameters : >>> >>> # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w >>> net.inet.sctp.mobility_fasthandoff=3D1 >>> # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is to dump >>> messages in /var/log/messages) >>> >>> net.inet.sctp.auto_asconf is set to 1 by default. >>> >>> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful >>> but I'm trying to be thorough. This is the script I use to perform >>> handover >>> : >>> >>> ifconfig rum0 inet6 delete ifconfig rum0 ssid >> target access point> route del -inet6 default rtsol >>> rum0 >>> >>> If I'm not mistaken, the PC should have sent an ASCONF chunk to >>> perform dynamic address reconfiguration. However what I observed is >>> that nothing happens. No ASCONF chunks are sent, and therefore, T >>> doesn't ever know that it should send data on the PC's newly =20 >>> acquired >>> address. >>> >>> I tried to investigate the problem myself, by adding some debug logs >>> in the sctp source code (to see which functions are called during =20 >>> the >>> handover process), and it seems as if the kernel doesn't ever add an >>> ASCONF chunk to send in its queue... But that's just my =20 >>> understanding >>> of the problem... >>> >>> I looked up in the CVS repository for answers, and to see the =20 >>> various >>> changes that were gradually brought on the code. There, I noticed >>> that on the revision dating 24th July 2007, changes were made for >>> dynamic address reconfiguration : "Change behaviour so that when the >>> last address is deleted (auto-asconf on a boudall endpoint) no =20 >>> action >>> is taken until an address is added ; at that time an ASCONF >>> add+delete is sent (if the asoc is still up)" >>> >>> In my humble opinion, this is exactly the case that corresponds to =20 >>> my >>> handover scenario. But I just haven't been able to successfully >>> perform it because I don't seem to send any ASCONF chunk. I'm >>> struggling to understand why I do not see any ASCONF chunk sent. >>> >>> If it can help, I'm also attaching links to the kind of debug logs I >>> got when performing a handover test. This is the kind of debug logs >>> that I got : >>> >>> http://www.divshare.com/download/6200509-560 >>> >>> This is another debug logfile, but with my own debug logs added in >>> the sctp source code : >>> >>> http://www.divshare.com/download/6200504-2e9 >>> >>> >>> Many thanks for your work, and I hope someone will be able to help >>> and shed some light on this problem :-) >>> >>> >>> Aman Jassal >>> >>> _______________________________________________ >>> 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 Dec 30 16:18:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F12C106564A for ; Tue, 30 Dec 2008 16:18:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFC98FC08 for ; Tue, 30 Dec 2008 16:18:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LHgzi-0007NY-9C for freebsd-net@freebsd.org; Tue, 30 Dec 2008 07:58:58 -0800 Message-ID: <21218952.post@talk.nabble.com> Date: Tue, 30 Dec 2008 07:58:58 -0800 (PST) From: ibmed To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ibmed@mail.ru Subject: em driver problems? taskq em goes up to 100% CPU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 16:18:12 -0000 Hi, I seem to have the following problem: Preamble: There's two FreeBSD boxes that do ipfw nat. Both worked with natd until some time ago, when it became clear that we need a better solution. So I upgraded sources and recompiled to kernel to include ipfw nat features. The boxes have onboard msk-net cards that worked fine under natd. After moving to ipfw nat the overall load of the boxes has significantly reduced. But: when the traffic load increased, the boxes started to print the following messages: kernel: msk0: Rx FIFO overrun! kernel: msk1: Rx FIFO overrun! and after some time just hang up. I assumed that there's a problem with msk driver urgently buy two Intel cards (Intel PRO/1000 PT Quad Port (OEM) PCI-E x4 10/100/1000Mbps) - one for each box. It solved to FIFO problem, BUT: there's now a problem with spontaneous peaks of system load: irrelatively to anything I can guess the system processes taskq em0, em1, em2 begin to eat 100% of CPU (and stay like that for about 1 or 2 minutes). And when that happens, traffic stops to pass through the box. The problem is there on both boxes. I tried upgrading both of them to RELENG_7_0, RELENG_7_1 (RC2 currently), RELENG_7 - the problem remains. Any suggestions on what can I do to solve the problem? I have just no idea on what causes that and what to do to fix it. I would really appreciate your help.. And just to be thorough, here's my kernel options: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=400 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_NAT options LIBALIAS options DUMMYNET options IPDIVERT fastforwarding is on, polling is off: net.inet.ip.fastforwarding: 1 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:00:10:01:1:01 inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255 media: Ethernet autoselect (1000baseTX ) status: active -- View this message in context: http://www.nabble.com/em-driver-problems--taskq-em-goes-up-to-100--CPU-tp21218952p21218952.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 17:49:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0FA51065670 for ; Tue, 30 Dec 2008 17:49:59 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 593098FC21 for ; Tue, 30 Dec 2008 17:49:59 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by an-out-0708.google.com with SMTP id c2so1950443anc.13 for ; Tue, 30 Dec 2008 09:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=rxu5kaJ4/q5D85xOQGPON4yGO50Yl5UaoQiOdlfy0CY=; b=RS1OlhnBMsJLDHL4yMSOqmKP8Bkepbo1eOy3yaVKt5HlkpUbdz9fMgQWVmyIsBY84P IkacSVsiaKY68IQV7tjqFn4xNROcH2jbccup/nUZXUKFTupgDmwR1ivAvDb89Jq9Yk4R KAzL9fJ4Db9dvdycQHDVqXI61uQWsBBxRl/xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=hwYYXJasNpKTkuwBzmEJWw9IFcwzpzXcHQoN1+FgD5GPwrTvq93aJEUxv/wk7bz1F3 cWRs9E5I6EnpUl9Z5lq8WgWu64y3VLkBVZspeO8WFF+jj3gb4dW0h/g57bAQA/Ffe/Ji /vomSIaqQhXGrzHeyh7/X51SklXfE8bLFhRb4= Received: by 10.100.128.2 with SMTP id a2mr8465460and.93.1230659398607; Tue, 30 Dec 2008 09:49:58 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id d24sm21839334and.44.2008.12.30.09.49.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Dec 2008 09:49:57 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 30 Dec 2008 11:49:55 +0000 Message-Id: <1230637795.4966.20.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 17:49:59 -0000 Guys, I do not think I could ever be more tired of this topic but I cannot seem to understand what to do. I have tried more about a month now to send arbitrary UDP packets from a kernel module but cannot achieve it. I have looked at udp_send but found that building a socket* was much to tedious. Later i looked at in-kernel webservers (http://openketa.sourceforge.net/) but could not find anything useful. Netgraph is a possibility, but there isn't any documentation on accessing the network from kernel space. What do you all suggest? From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 18:12:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 025491065676 for ; Tue, 30 Dec 2008 18:12:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 85D7A8FC1A for ; Tue, 30 Dec 2008 18:12:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-019-033.pools.arcor-ip.net [88.66.19.33]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LHj4u0Lo8-0002Ew; Tue, 30 Dec 2008 19:12:28 +0100 Received: (qmail 88772 invoked from network); 30 Dec 2008 18:12:27 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 30 Dec 2008 18:12:27 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 30 Dec 2008 19:05:56 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <1230637795.4966.20.camel@mobiliare.Belkin> In-Reply-To: <1230637795.4966.20.camel@mobiliare.Belkin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812301905.57164.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19RvYJrpCs1UsEc/Lu8AZltN+MyLwFMV3PAbF+ Q0aeKZwVrU3qgbXw/dmU+6XvpBnhAGrP96wTQbWHZed3yzR42k 5GH5BoAyrilv3rLCdYj6Q== Cc: Ferner Cilloniz Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 18:12:30 -0000 On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote: > Guys, > > I do not think I could ever be more tired of this topic but I cannot > seem to understand what to do. I have tried more about a month now to > send arbitrary UDP packets from a kernel module but cannot achieve it. I > have looked at udp_send but found that building a socket* was much to > tedious. Later i looked at in-kernel webservers > (http://openketa.sourceforge.net/) but could not find anything useful. > > Netgraph is a possibility, but there isn't any documentation on > accessing the network from kernel space. > > What do you all suggest? $ man 9 socket -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 18:46:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBFBA1065717 for ; Tue, 30 Dec 2008 18:46:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B2FA98FC36 for ; Tue, 30 Dec 2008 18:46:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 2A57A46B29; Tue, 30 Dec 2008 13:46:46 -0500 (EST) Date: Tue, 30 Dec 2008 18:46:46 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200812301905.57164.max@love2party.net> Message-ID: References: <1230637795.4966.20.camel@mobiliare.Belkin> <200812301905.57164.max@love2party.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ferner Cilloniz Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 18:46:47 -0000 On Tue, 30 Dec 2008, Max Laier wrote: > On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote: > >> I do not think I could ever be more tired of this topic but I cannot seem >> to understand what to do. I have tried more about a month now to send >> arbitrary UDP packets from a kernel module but cannot achieve it. I have >> looked at udp_send but found that building a socket* was much to tedious. >> Later i looked at in-kernel webservers (http://openketa.sourceforge.net/) >> but could not find anything useful. >> >> Netgraph is a possibility, but there isn't any documentation on accessing >> the network from kernel space. >> >> What do you all suggest? > > $ man 9 socket Definitely the preferred solution, if it meets the application model. Call socreate(9) to allocate the socket, sobind(9) if required, calls to sosend(9) to generate packets, and soclose(9) when done. Direct calls to the udp_output() and udp_send() functions won't work without a socket context, and doing sosend(9) will isolate in-kernel consumers from future changes in UDP internals. ip_output() could be invoked directly to generate IP packets, but won't allow you to easily receive replies, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 18:50:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05FE106566B for ; Tue, 30 Dec 2008 18:50:20 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id B68818FC0C for ; Tue, 30 Dec 2008 18:50:20 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id CB41A1FF00B5; Tue, 30 Dec 2008 13:50:19 -0500 (EST) Thread-Index: Aclqr3ZTsmB1g2EAT2akJrHlWkhdbA== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Dec 2008 13:50:19 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id EFE3E8E297; Tue, 30 Dec 2008 12:50:18 -0600 (CST) Date: Tue, 30 Dec 2008 12:50:18 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Message-ID: <20081230185018.GF16514@verio.net> Importance: normal Priority: normal Mail-Followup-To: freebsd-net@freebsd.org, Gabe References: <258438.24300.qm@web83813.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <258438.24300.qm@web83813.mail.sp1.yahoo.com> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 30 Dec 2008 18:50:19.0297 (UTC) FILETIME=[76473910:01C96AAF] Cc: Gabe Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 18:50:21 -0000 Gabe wrote: > > However I still get the ipsec_common message albeit not as often, it > appears to only be when I restart racoon now. I also tried matching > the SPIs but the SPIs given by setkey -Da did not match the ones on > the log. That is exactly what the kernel is trying to tell you. The SPI's on packets being received do not match SPI's currently negotiated by raccoon. Therefore, the kernel cannot decrypt the packet, so it logs an error. If you want to know why that SPI is being sent, it may be helpful to login to the OTHER endpoint and find out what SPI's it thinks are supposed to be in use. They appear to be getting out of sync. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 18:58:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C360E106566B for ; Tue, 30 Dec 2008 18:58:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id A4AA28FC08 for ; Tue, 30 Dec 2008 18:58:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0A234242A; Tue, 30 Dec 2008 10:58:25 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 8E37D2D600E; Tue, 30 Dec 2008 10:58:24 -0800 (PST) Message-ID: <495A6F50.2070305@elischer.org> Date: Tue, 30 Dec 2008 10:58:24 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Ferner Cilloniz References: <1230637795.4966.20.camel@mobiliare.Belkin> In-Reply-To: <1230637795.4966.20.camel@mobiliare.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 18:58:26 -0000 Ferner Cilloniz wrote: > Guys, > > I do not think I could ever be more tired of this topic but I cannot > seem to understand what to do. I have tried more about a month now to > send arbitrary UDP packets from a kernel module but cannot achieve it. I > have looked at udp_send but found that building a socket* was much to > tedious. Later i looked at in-kernel webservers > (http://openketa.sourceforge.net/) but could not find anything useful. > > Netgraph is a possibility, but there isn't any documentation on > accessing the network from kernel space. > > What do you all suggest? > where are your packets supposed to come from? I think I asked you this before so sorry if you answered it and I have forgotten. i.e. what is in them? start with /usr/src/sys/netgraph/ng_sample.c and ng_source.c and make a nolde that generates teh packets you want to send, and then attach it to an ng_ksocket node.. end of job From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 19:04:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B69C106564A for ; Tue, 30 Dec 2008 19:04:16 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from mail01.compvia.com (mail01.compvia.com [12.147.132.91]) by mx1.freebsd.org (Postfix) with ESMTP id F1C8C8FC23 for ; Tue, 30 Dec 2008 19:04:15 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from [10.10.20.11] ([10.10.20.11]) by mail01.compvia.com (Kerio MailServer 6.5.1); Tue, 30 Dec 2008 13:04:12 -0600 To: "Ferner Cilloniz" , freebsd-net@freebsd.org From: "Gerry Weaver" In-Reply-To: 1230637795.4966.20.camel@mobiliare.Belkin Message-ID: <20081230190412.b20e996c@mail01.compvia.com> Date: Tue, 30 Dec 2008 13:04:12 -0600 X-Mailer: Kerio MailServer 6.5.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 19:04:16 -0000 =5F=5F=5F=5F=5F =20 From: Ferner Cilloniz [mailto:fernercc@gmail.com] To: freebsd-net@freebsd.org Sent: Tue, 30 Dec 2008 05:49:55 -0600 Subject: kernel network Guys, =20 I do not think I could ever be more tired of this topic but I cannot seem to understand what to do. I have tried more about a month now to send arbitrary UDP packets from a kernel module but cannot achieve it.= I have looked at udp=5Fsend but found that building a socket* was much t= o tedious. Later i looked at in-kernel webservers (http://openketa.sourceforge.net/) but could not find anything useful. =20 Netgraph is a possibility, but there isn't any documentation on accessing the network from kernel space. =20 What do you all suggest=3F =20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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" Hello Ferner, =20 I am working on a module that needs to do the same thing. I'm starting= work on the socket code today. If and when I have something working, I= will be more than happy to share some code snippets with you.=20 Thanks, Gerry =20 =20 From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 19:09:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53513106566B for ; Tue, 30 Dec 2008 19:09:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3391A8FC17 for ; Tue, 30 Dec 2008 19:09:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 16CE32416; Tue, 30 Dec 2008 11:09:04 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B7F622D6023; Tue, 30 Dec 2008 11:09:03 -0800 (PST) Message-ID: <495A71CF.2030000@elischer.org> Date: Tue, 30 Dec 2008 11:09:03 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Gerry Weaver References: <20081230190412.b20e996c@mail01.compvia.com> In-Reply-To: <20081230190412.b20e996c@mail01.compvia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ferner Cilloniz Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 19:09:06 -0000 Gerry Weaver wrote: > _____ > > From: Ferner Cilloniz [mailto:fernercc@gmail.com] > To: freebsd-net@freebsd.org > Sent: Tue, 30 Dec 2008 05:49:55 -0600 > Subject: kernel network > > Guys, > > I do not think I could ever be more tired of this topic but I cannot > seem to understand what to do. I have tried more about a month now to > send arbitrary UDP packets from a kernel module but cannot achieve it. I > have looked at udp_send but found that building a socket* was much to > tedious. Later i looked at in-kernel webservers > (http://openketa.sourceforge.net/) but could not find anything useful. > > Netgraph is a possibility, but there isn't any documentation on > accessing the network from kernel space. > > What do you all suggest? > > > _______________________________________________ > 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" > Hello Ferner, > > I am working on a module that needs to do the same thing. I'm starting work on the socket code today. If and when I have something working, I will be more than happy to share some code snippets with you. > > Thanks, > Gerry > ng_ksocket of course does all this so you will find code samples in there. From owner-freebsd-net@FreeBSD.ORG Tue Dec 30 23:16:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF0D106566B for ; Tue, 30 Dec 2008 23:16:55 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 957498FC08 for ; Tue, 30 Dec 2008 23:16:55 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2565247ywe.13 for ; Tue, 30 Dec 2008 15:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=2hVjlr3K07MVZczkHObpHOR0R6b5qLQ74kDsKHtCkVE=; b=iYbjUDtG6xNgQvqT1Dos63Q7Y7ThWHimNZsPsq4VEO9ZUdL2z2Bb3nFMEO2Ma1hCPk F5IGhd7bBK+X19YyUFhe0RoCqa3X7kBk45BG9LCvYJWFGU3adBHYof+mNVd8b6bdewW1 m9ide2N9zOCUa9zYNcuHmYuX9XqixmJhXTlCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=tNIcKHFf6cltZ6Dodvc0HTyemtUCRKgTkYdLw9Q/t/cMy3jtjnrC9TOzK/SgKPPhL+ 5nUbF53jP+yKYsOH3yC5WV3OmGICGVay35Zy6VDdpkbPxrSQzZRROsQytodxvMboT/lk /wtD6II9pGytaQic5SNkMw1KzoDkdVut7XpKU= Received: by 10.100.209.5 with SMTP id h5mr8646084ang.79.1230679014742; Tue, 30 Dec 2008 15:16:54 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id b29sm12945640ana.13.2008.12.30.15.16.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Dec 2008 15:16:54 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org In-Reply-To: References: <1230637795.4966.20.camel@mobiliare.Belkin> <200812301905.57164.max@love2party.net> Content-Type: text/plain Date: Tue, 30 Dec 2008 17:16:52 +0000 Message-Id: <1230657412.4966.24.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Dec 2008 23:16:56 -0000 I have been tackling this today. This is what i have so far: ------------------------------------------------------------------------- static int my_udp_send(struct thread *td, void *syscall_args) { struct socket *sock = NULL; if( socreate(AF_INET, &sock, SOCK_DGRAM, 0, td->td_proc->p_ucred, td) != 0 ) { uprintf("socreate() returned error\n"); return -1; } struct sockaddr sa; sa.sa_len = sizeof(struct sockaddr_in); struct sockaddr_in *sin = (struct sockaddr_in *)&sa; sin->sin_family = AF_INET; inet_aton("192.168.2.2", (struct sockaddr_in *)&sin->sin_addr); sin->sin_port = htons(8080); sin->sin_len = sizeof(*sin); memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); // int soconnect_error = soconnect(sock, (struct sockaddr *)sin, td); // uprintf("soconnect(): %d\n", soconnect_error); struct mbuf *top = m_getclr(M_TRYWAIT, MT_CONTROL); // IP is 0 int sosend_error = sosend(sock, (struct sockaddr *)sin, NULL, top, NULL, 0, td); uprintf("sosend(): %d\n", sosend_error); soclose(sock); return 0; } ------------------------------------------------------------------------- However, when listening to my home network using wireshark, I filter out everything but UDP packets with the 192.168.2.2 address on them. I'm afraid to say that there aren't any packets showing. Am i doing something wrong? Note, that I am not filling in the mbuf and all the wacking casting done. Thanks. On Tue, 2008-12-30 at 18:46 +0000, Robert Watson wrote: > On Tue, 30 Dec 2008, Max Laier wrote: > > > On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote: > > > >> I do not think I could ever be more tired of this topic but I cannot seem > >> to understand what to do. I have tried more about a month now to send > >> arbitrary UDP packets from a kernel module but cannot achieve it. I have > >> looked at udp_send but found that building a socket* was much to tedious. > >> Later i looked at in-kernel webservers (http://openketa.sourceforge.net/) > >> but could not find anything useful. > >> > >> Netgraph is a possibility, but there isn't any documentation on accessing > >> the network from kernel space. > >> > >> What do you all suggest? > > > > $ man 9 socket > > Definitely the preferred solution, if it meets the application model. Call > socreate(9) to allocate the socket, sobind(9) if required, calls to sosend(9) > to generate packets, and soclose(9) when done. Direct calls to the > udp_output() and udp_send() functions won't work without a socket context, and > doing sosend(9) will isolate in-kernel consumers from future changes in UDP > internals. ip_output() could be invoked directly to generate IP packets, but > won't allow you to easily receive replies, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 01:10:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D1181065670 for ; Wed, 31 Dec 2008 01:10:04 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D38698FC1E for ; Wed, 31 Dec 2008 01:10:03 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LHpb0-0001zu-S3 for freebsd-net@freebsd.org; Wed, 31 Dec 2008 01:10:03 +0000 Received: from 93-138-86-178.adsl.net.t-com.hr ([93.138.86.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Dec 2008 01:10:02 +0000 Received: from ivoras by 93-138-86-178.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Dec 2008 01:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Wed, 31 Dec 2008 02:06:35 +0100 Lines: 40 Message-ID: References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE980AA4F25C14A8580FCF0CB" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-86-178.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: <495215A6.2040002@oltrelinux.com> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: A new tool for low level testing... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 01:10:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE980AA4F25C14A8580FCF0CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paolo Pisati wrote: > Julian Elischer wrote: >> >> OR >> >> ngctl mkpeer em0: echo lower echo >> >> >> hmmmmm no this would leave the source and destination headers in hte >> same order.. they need to be swapped.. >> >> ok so I need to make a patch, but it would be much quicker than a user= >> utility.. > what about a netgraph cookbook? Those who don't know Netgraph are doomed to reinvent it :) (I also don't know it :) ) --------------enigE980AA4F25C14A8580FCF0CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklaxZsACgkQldnAQVacBcjj+gCdEsOldsU0ZBkzXad8eVFQWfdt 9jYAn2Mc0+G2uYz8sD5ZL7+qMZSpPJrn =VDmU -----END PGP SIGNATURE----- --------------enigE980AA4F25C14A8580FCF0CB-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 03:36:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC561065670 for ; Wed, 31 Dec 2008 03:36:11 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.187]) by mx1.freebsd.org (Postfix) with ESMTP id AFF878FC08 for ; Wed, 31 Dec 2008 03:36:10 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so3655286rne.12 for ; Tue, 30 Dec 2008 19:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=8yu0HAeQqq9CnZpQTnFXkWxM1SViEzJQ9e8vpPdllC8=; b=BXo+5W7lyUB+i89xq7mWAz9fXLfJzMedhrA/1wSyrxOzCPdl5Enu1J+NQmJINgohmm bLoX1rv8EErIJ7H072ifWbxdEa4QjwT2XZRL00W4qxuY82Ho5w3L29HQP5X3+KSAx6tC YRHAmCMQLMFd6kLaWOpw5uZhtTbwkeRDHbjxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=u4fm0jvWu16tqvvkSTcUVZ4k6DXAJAJW4Kq0VZ1HcYBpLbteKpUNqnCK7SGJns5Mdk P775UDvtNqbYCAL5ZqnzfepGMj6hO9SXsdAnXtK/i/9AwsevQbJf1Cc+0EjYj7giq6C3 TcQmJzUA08cMT43/hxipwlXbnmEoVmZvilLgk= Received: by 10.100.41.9 with SMTP id o9mr8738098ano.49.1230694569531; Tue, 30 Dec 2008 19:36:09 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id d35sm27424131and.45.2008.12.30.19.36.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Dec 2008 19:36:09 -0800 (PST) From: Ferner Cilloniz To: freebsd-net@freebsd.org In-Reply-To: <1230657412.4966.24.camel@mobiliare.Belkin> References: <1230637795.4966.20.camel@mobiliare.Belkin> <200812301905.57164.max@love2party.net> <1230657412.4966.24.camel@mobiliare.Belkin> Content-Type: text/plain Date: Tue, 30 Dec 2008 21:36:07 +0000 Message-Id: <1230672967.4966.26.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 03:36:11 -0000 I tried another approach. The code is below. However, wireshark does not pick up anything happening. I don't know what is going on. static int my_udp_send(struct thread *td, void *syscall_args) { struct socket *sock = NULL; if( socreate(AF_INET, &sock, SOCK_DGRAM, 0, td->td_proc->p_ucred, td) != 0 ) { uprintf("socreate() returned error\n"); return -1; } struct sockaddr_in sin; sin.sin_len = sizeof(struct sockaddr_in); sin.sin_family = AF_INET; sin.sin_port = htons(8080); inet_aton("192.168.2.2", &sin.sin_addr); struct mbuf *top = m_getclr(M_TRYWAIT, MT_CONTROL); // IP is 0 int sosend_error = sosend(sock, (struct sockaddr *)&sin, NULL, top, NULL, 0, td); uprintf("sosend(): %d\n", sosend_error); soclose(sock); return 0; } On Tue, 2008-12-30 at 17:16 +0000, Ferner Cilloniz wrote: > I have been tackling this today. This is what i have so far: > > ------------------------------------------------------------------------- > static int my_udp_send(struct thread *td, void *syscall_args) > { > struct socket *sock = NULL; > > if( socreate(AF_INET, &sock, SOCK_DGRAM, 0, td->td_proc->p_ucred, > td) != 0 ) { > uprintf("socreate() returned error\n"); > return -1; > } > > struct sockaddr sa; > sa.sa_len = sizeof(struct sockaddr_in); > > struct sockaddr_in *sin = (struct sockaddr_in *)&sa; > sin->sin_family = AF_INET; > inet_aton("192.168.2.2", (struct sockaddr_in *)&sin->sin_addr); > sin->sin_port = htons(8080); > sin->sin_len = sizeof(*sin); > memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); > > // int soconnect_error = soconnect(sock, (struct sockaddr *)sin, td); > // uprintf("soconnect(): %d\n", soconnect_error); > > struct mbuf *top = m_getclr(M_TRYWAIT, MT_CONTROL); > > // IP is 0 > int sosend_error = sosend(sock, (struct sockaddr *)sin, NULL, top, > NULL, 0, td); > uprintf("sosend(): %d\n", sosend_error); > > soclose(sock); > > return 0; > } > ------------------------------------------------------------------------- > > > However, when listening to my home network using wireshark, I filter out > everything but UDP packets with the 192.168.2.2 address on them. I'm > afraid to say that there aren't any packets showing. > > Am i doing something wrong? Note, that I am not filling in the mbuf and > all the wacking casting done. > > Thanks. > > On Tue, 2008-12-30 at 18:46 +0000, Robert Watson wrote: > > On Tue, 30 Dec 2008, Max Laier wrote: > > > > > On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote: > > > > > >> I do not think I could ever be more tired of this topic but I cannot seem > > >> to understand what to do. I have tried more about a month now to send > > >> arbitrary UDP packets from a kernel module but cannot achieve it. I have > > >> looked at udp_send but found that building a socket* was much to tedious. > > >> Later i looked at in-kernel webservers (http://openketa.sourceforge.net/) > > >> but could not find anything useful. > > >> > > >> Netgraph is a possibility, but there isn't any documentation on accessing > > >> the network from kernel space. > > >> > > >> What do you all suggest? > > > > > > $ man 9 socket > > > > Definitely the preferred solution, if it meets the application model. Call > > socreate(9) to allocate the socket, sobind(9) if required, calls to sosend(9) > > to generate packets, and soclose(9) when done. Direct calls to the > > udp_output() and udp_send() functions won't work without a socket context, and > > doing sosend(9) will isolate in-kernel consumers from future changes in UDP > > internals. ip_output() could be invoked directly to generate IP packets, but > > won't allow you to easily receive replies, etc. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 05:03:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9E5106564A for ; Wed, 31 Dec 2008 05:03:22 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from mail01.compvia.com (mail01.compvia.com [12.147.132.91]) by mx1.freebsd.org (Postfix) with ESMTP id A877A8FC14 for ; Wed, 31 Dec 2008 05:03:22 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from [10.10.20.11] ([10.10.20.11]) by mail01.compvia.com (Kerio MailServer 6.5.1); Tue, 30 Dec 2008 23:03:18 -0600 To: "Ferner Cilloniz" , freebsd-net@freebsd.org From: "Gerry Weaver" In-Reply-To: 1230672967.4966.26.camel@mobiliare.Belkin Message-ID: <20081231050318.616ef838@mail01.compvia.com> Date: Tue, 30 Dec 2008 23:03:18 -0600 X-Mailer: Kerio MailServer 6.5.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 05:03:23 -0000 =5F=5F=5F=5F=5F =20 From: Ferner Cilloniz [mailto:fernercc@gmail.com] To: freebsd-net@freebsd.org Sent: Tue, 30 Dec 2008 15:36:07 -0600 Subject: Re: kernel network I tried another approach. The code is below. However, wireshark does not pick up anything happening. I don't know what is going on. =20 static int my=5Fudp=5Fsend(struct thread *td, void *syscall=5Fargs) { struct socket *sock =3D NULL; =20 if( socreate(AF=5FINET, &sock, SOCK=5FDGRAM, 0, td->td=5Fproc->p= =5Fucred, td) !=3D 0 ) { uprintf("socreate() returned error\n"); return -1; } =20 struct sockaddr=5Fin sin; sin.sin=5Flen =3D sizeof(struct sockaddr=5Fin); sin.sin=5Ffamily =3D AF=5FINET; sin.sin=5Fport =3D htons(8080); inet=5Faton("192.168.2.2", &sin.sin=5Faddr); =20 struct mbuf *top =3D m=5Fgetclr(M=5FTRYWAIT, MT=5FCONTROL); =20 // IP is 0 int sosend=5Ferror =3D sosend(sock, (struct sockaddr *)&sin, NULL,= top, NULL, 0, td); uprintf("sosend(): %d\n", sosend=5Ferror); =20 soclose(sock); =20 return 0; } =20 =20 =20 =20 On Tue, 2008-12-30 at 17:16 +0000, Ferner Cilloniz wrote: > I have been tackling this today. This is what i have so far: >=20 > --------------------------------------------------------------------= ----- > static int my=5Fudp=5Fsend(struct thread *td, void *syscall=5Fargs) > { > struct socket *sock =3D NULL; >=20 > if( socreate(AF=5FINET, &sock, SOCK=5FDGRAM, 0, td->td=5Fproc->p= =5Fucred, > td) !=3D 0 ) { > uprintf("socreate() returned error\n"); > return -1; > } >=20 > struct sockaddr sa; > sa.sa=5Flen =3D sizeof(struct sockaddr=5Fin); >=20 > struct sockaddr=5Fin *sin =3D (struct sockaddr=5Fin *)&sa; > sin->sin=5Ffamily =3D AF=5FINET; > inet=5Faton("192.168.2.2", (struct sockaddr=5Fin *)&sin->sin=5Fa= ddr); > sin->sin=5Fport =3D htons(8080); > sin->sin=5Flen =3D sizeof(*sin); > memset(sin->sin=5Fzero, 0, sizeof(sin->sin=5Fzero)); >=20 > // int soconnect=5Ferror =3D soconnect(sock, (struct sockaddr *)s= in, td); > // uprintf("soconnect(): %d\n", soconnect=5Ferror); >=20 > struct mbuf *top =3D m=5Fgetclr(M=5FTRYWAIT, MT=5FCONTROL); >=20 > // IP is 0 > int sosend=5Ferror =3D sosend(sock, (struct sockaddr *)sin, NULL= , top, > NULL, 0, td); > uprintf("sosend(): %d\n", sosend=5Ferror); >=20 > soclose(sock); >=20 > return 0; > } > --------------------------------------------------------------------= ----- >=20 >=20 > However, when listening to my home network using wireshark, I filter= out > everything but UDP packets with the 192.168.2.2 address on them. I'm > afraid to say that there aren't any packets showing. >=20 > Am i doing something wrong=3F Note, that I am not filling in the mbu= f and > all the wacking casting done. >=20 > Thanks.=20 >=20 > On Tue, 2008-12-30 at 18:46 +0000, Robert Watson wrote: > > On Tue, 30 Dec 2008, Max Laier wrote: > >=20 > > > On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz wrote: > > > > > >> I do not think I could ever be more tired of this topic but I c= annot seem=20 > > >> to understand what to do. I have tried more about a month now t= o send=20 > > >> arbitrary UDP packets from a kernel module but cannot achieve i= t. I have=20 > > >> looked at udp=5Fsend but found that building a socket* was much= to tedious.=20 > > >> Later i looked at in-kernel webservers (http://openketa.sourcef= orge.net/)=20 > > >> but could not find anything useful. > > >> > > >> Netgraph is a possibility, but there isn't any documentation on= accessing=20 > > >> the network from kernel space. > > >> > > >> What do you all suggest=3F > > > > > > $ man 9 socket > >=20 > > Definitely the preferred solution, if it meets the application mod= el. Call=20 > > socreate(9) to allocate the socket, sobind(9) if required, calls t= o sosend(9)=20 > > to generate packets, and soclose(9) when done. Direct calls to th= e=20 > > udp=5Foutput() and udp=5Fsend() functions won't work without a soc= ket context, and=20 > > doing sosend(9) will isolate in-kernel consumers from future chang= es in UDP=20 > > internals. ip=5Foutput() could be invoked directly to generate IP= packets, but=20 > > won't allow you to easily receive replies, etc. > >=20 > > Robert N M Watson > > Computer Laboratory > > University of Cambridge --=20 Cilloniz Bicchi, Ferner =20 Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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"= Hello Ferner, I believe you need a packet header in your mbuf. Try m=5Fgethdr instead = of=20 m=5Fgetclr. Thanks, Gerry From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 06:06:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1150106566C for ; Wed, 31 Dec 2008 06:06:54 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 985848FC1A for ; Wed, 31 Dec 2008 06:06:54 +0000 (UTC) (envelope-from fernercc@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2600244ywe.13 for ; Tue, 30 Dec 2008 22:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=+5xnjxL6rQNhDGUDysLhUsWFmKx3VxHV+pJ8T89YK/A=; b=O6Nd+3QDhTN+EskwhJEILFCXaQ3ccq5jbHasxJ9o2vD/WUaBWrxp/WHgvUiaVpj7wo FuHkNau+SNMpCEm8UIVGPezK5EOvt89k8gAkRKdF/RdTbCrKESIO64uKOGPkvrTShfla f283kvHEXJrFgAIKgfzriyedkBYRI+dJU6OWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Bkr3AXm+XLsOecHTcPMQVlBtvOVvYp5l4m5SLHjq83H8YjbzQGQ/PhX+n+qilAao3T FzpR7GV6tA606GH5Tdmf3j/R6NQHoAfIVBdgc5gvhbW+snTZcbbTqwN7rR8NbwWMp7ly 1A85ihJO2Di9dIMLPYT6kSTuvfY2GqfrSJpbk= Received: by 10.100.191.9 with SMTP id o9mr8774929anf.63.1230703613278; Tue, 30 Dec 2008 22:06:53 -0800 (PST) Received: from ?192.168.2.2? (cpe-70-112-179-136.austin.res.rr.com [70.112.179.136]) by mx.google.com with ESMTPS id c28sm20891128anc.47.2008.12.30.22.06.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Dec 2008 22:06:52 -0800 (PST) From: Ferner Cilloniz To: Gerry Weaver In-Reply-To: <20081231050318.616ef838@mail01.compvia.com> References: <20081231050318.616ef838@mail01.compvia.com> Content-Type: text/plain Date: Wed, 31 Dec 2008 00:06:50 +0000 Message-Id: <1230682010.4966.27.camel@mobiliare.Belkin> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kernel network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 06:06:56 -0000 Thanks! That solved it. On Tue, 2008-12-30 at 23:03 -0600, Gerry Weaver wrote: > > ______________________________________________________________ > From: Ferner Cilloniz [mailto:fernercc@gmail.com] > To: freebsd-net@freebsd.org > Sent: Tue, 30 Dec 2008 15:36:07 -0600 > Subject: Re: kernel network > > I tried another approach. The code is below. However, > wireshark does not > pick up anything happening. I don't know what is going on. > > static int my_udp_send(struct thread *td, void *syscall_args) > { > struct socket *sock = NULL; > > if( socreate(AF_INET, &sock, SOCK_DGRAM, 0, > td->td_proc->p_ucred, > td) != 0 ) { > uprintf("socreate() returned error\n"); > return -1; > } > > struct sockaddr_in sin; > sin.sin_len = sizeof(struct sockaddr_in); > sin.sin_family = AF_INET; > sin.sin_port = htons(8080); > inet_aton("192.168.2.2", &sin.sin_addr); > > struct mbuf *top = m_getclr(M_TRYWAIT, MT_CONTROL); > > // IP is 0 > int sosend_error = sosend(sock, (struct sockaddr *)&sin, NULL, > top, > NULL, 0, td); > uprintf("sosend(): %d\n", sosend_error); > > soclose(sock); > > return 0; > } > > > > > On Tue, 2008-12-30 at 17:16 +0000, Ferner Cilloniz wrote: > > I have been tackling this today. This is what i have so far: > > > > > ------------------------------------------------------------------------- > > static int my_udp_send(struct thread *td, void > *syscall_args) > > { > > struct socket *sock = NULL; > > > > if( socreate(AF_INET, &sock, SOCK_DGRAM, 0, > td->td_proc->p_ucred, > > td) != 0 ) { > > uprintf("socreate() returned error\n"); > > return -1; > > } > > > > struct sockaddr sa; > > sa.sa_len = sizeof(struct sockaddr_in); > > > > struct sockaddr_in *sin = (struct sockaddr_in *)&sa; > > sin->sin_family = AF_INET; > > inet_aton("192.168.2.2", (struct sockaddr_in > *)&sin->sin_addr); > > sin->sin_port = htons(8080); > > sin->sin_len = sizeof(*sin); > > memset(sin->sin_zero, 0, sizeof(sin->sin_zero)); > > > > // int soconnect_error = soconnect(sock, (struct sockaddr > *)sin, td); > > // uprintf("soconnect(): %d\n", soconnect_error); > > > > struct mbuf *top = m_getclr(M_TRYWAIT, MT_CONTROL); > > > > // IP is 0 > > int sosend_error = sosend(sock, (struct sockaddr *)sin, > NULL, top, > > NULL, 0, td); > > uprintf("sosend(): %d\n", sosend_error); > > > > soclose(sock); > > > > return 0; > > } > > > ------------------------------------------------------------------------- > > > > > > However, when listening to my home network using wireshark, > I filter out > > everything but UDP packets with the 192.168.2.2 address on > them. I'm > > afraid to say that there aren't any packets showing. > > > > Am i doing something wrong? Note, that I am not filling in > the mbuf and > > all the wacking casting done. > > > > Thanks. > > > > On Tue, 2008-12-30 at 18:46 +0000, Robert Watson wrote: > > > On Tue, 30 Dec 2008, Max Laier wrote: > > > > > > > On Tuesday 30 December 2008 12:49:55 Ferner Cilloniz > wrote: > > > > > > > >> I do not think I could ever be more tired of this topic > but I cannot seem > > > >> to understand what to do. I have tried more about a > month now to send > > > >> arbitrary UDP packets from a kernel module but cannot > achieve it. I have > > > >> looked at udp_send but found that building a socket* > was much to tedious. > > > >> Later i looked at in-kernel webservers > (http://openketa.sourceforge.net/) > > > >> but could not find anything useful. > > > >> > > > >> Netgraph is a possibility, but there isn't any > documentation on accessing > > > >> the network from kernel space. > > > >> > > > >> What do you all suggest? > > > > > > > > $ man 9 socket > > > > > > Definitely the preferred solution, if it meets the > application model. Call > > > socreate(9) to allocate the socket, sobind(9) if required, > calls to sosend(9) > > > to generate packets, and soclose(9) when done. Direct > calls to the > > > udp_output() and udp_send() functions won't work without a > socket context, and > > > doing sosend(9) will isolate in-kernel consumers from > future changes in UDP > > > internals. ip_output() could be invoked directly to > generate IP packets, but > > > won't allow you to easily receive replies, etc. > > > > > > Robert N M Watson > > > Computer Laboratory > > > University of Cambridge > -- > Cilloniz Bicchi, Ferner > > Research Assistant > Dept. of Computer Sciences > The University of Texas at Austin > http://www.cs.utexas.edu/~fernercc > fernercc@cs.utexas.edu > > _______________________________________________ > 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" > Hello Ferner, > > I believe you need a packet header in your mbuf. Try m_gethdr instead > of > m_getclr. > > Thanks, > Gerry -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 06:18:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255B0106566B; Wed, 31 Dec 2008 06:18:17 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 091448FC0C; Wed, 31 Dec 2008 06:18:16 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBV6IE8T029866; Tue, 30 Dec 2008 22:18:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Dec 2008 22:18:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: Aclpr6yJwObcoU6mQNmwNb7Ozx71+QBW+YpQ References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> From: "Li, Qing" To: "Gerald Pfeifer" , "Tijl Coosemans" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 06:18:17 -0000 Hi, >=20 > > If it's easy to reintroduce it and become backwards compatible I > > would do it. Like Julian said, you can give it the value 0. It > > would be nice if the kernel tested for the old value as well, > > perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people > > upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7 > > keep working. >=20 > What of this will be doable, Qing? I guess Tijl and me need to > understand when/whether/what to submit to Wine upstream... >=20 I don't think we can provide binary compatibility without putting back RTF_LLINFO exactly as it was. My preference is to continue down=20 the new path without RTF_LLINFO. We still have some time before the 8.0 release. It's straightforward for me to retain some of the RTF_LLINFO support in the new kernel if and when the situation becomes necessary. >>>=20 >>> I believe all of the affected ports have been updated to=20 >>> include the conditional blocks around RTF_LLINFO. So=20 >>> there is still a level of compatibility, right ? >> Yes, and I'm OK with this. It's just that this makes FreeBSD 8 >> a special case. >=20 > Agreed. > Since the affected ports now have the conditional code around RTF_LLINFO,=20 the updates would allow these ports to compile in both -current and in the=20 previous releases. Let's go with this approach.=20 Thanks, -- Qing From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 07:36:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DB9A1065674 for ; Wed, 31 Dec 2008 07:36:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 97C6B8FC1E for ; Wed, 31 Dec 2008 07:36:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 24004 invoked by uid 399); 31 Dec 2008 07:09:53 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Dec 2008 07:09:53 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <495B1ABF.4080302@FreeBSD.org> Date: Tue, 30 Dec 2008 23:09:51 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.18 (X11/20081128) MIME-Version: 1.0 To: "Li, Qing" References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 07:36:35 -0000 Li, Qing wrote: > I don't think we can provide binary compatibility without putting > back RTF_LLINFO exactly as it was. My preference is to continue down > the new path without RTF_LLINFO. Out of curiosity, what's your reasoning for this decision? If I've missed this explanation previously, my apologies. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 07:56:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF440106566C for ; Wed, 31 Dec 2008 07:56:16 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83811.mail.sp1.yahoo.com (web83811.mail.sp1.yahoo.com [69.147.85.85]) by mx1.freebsd.org (Postfix) with SMTP id 9BDC48FC1B for ; Wed, 31 Dec 2008 07:56:16 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 14959 invoked by uid 60001); 31 Dec 2008 07:56:16 -0000 X-YMail-OSG: ruUzrs4VM1n5yU6dOb.Wyftx2NipCsh1P9KWXXiNOpWBDJzopgfsD3M2piNmVurz.6oYzVVLTL5__t3.B.ltKS9M9choKwIxBIFTp5tMZs4hJxFAPBoh4iipXLjgajnxfGzFGuJBYSB2syWwxZ6bES6hjcepYAEedAYpkzuGVG7p39o4FTkWpJyiPjH3Zt4nnufcdLRiDvE6w_.QXn0S0YV_FuvZ Received: from [69.43.143.172] by web83811.mail.sp1.yahoo.com via HTTP; Tue, 30 Dec 2008 23:56:16 PST X-Mailer: YahooMailWebService/0.7.218.2 Date: Tue, 30 Dec 2008 23:56:16 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" In-Reply-To: <20081230115445.A28465@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <480896.12029.qm@web83811.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: +ipsec_common_input: no key association found for SA X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nrml@att.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 07:56:16 -0000 > From: Bjoern A. Zeeb > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Gabe" > Cc: freebsd-net@freebsd.org > Date: Tuesday, December 30, 2008, 6:24 AM > On Tue, 30 Dec 2008, Gabe wrote: > > >> One more thing; if you are comparing SPIs from the > log with setkey, > >> you can also run > >> tcpdump -s 0 -vv -ln proto 50 > >> and it will show you something like > >> ... ESP(spi=0x12345678,seq=0x..), > >> so you could as well compare what you receive on > the wire with what > >> you get in the log. This would help to eliminiate > the case of a > >> promblematic patch. > > > > However I still get the ipsec_common message albeit > not as often, it > > appears to only be when I restart racoon now. I also > tried matching the > > SPIs but the SPIs given by setkey -Da did not match > the ones on the log. > > Ok, can you try running the following script and see if the > output > times match your racoon restarts or the log entries? > > You need to set your interface and the tunnel endpoint IPs > (as in box/box2). > > /bz I restarted racoon and cleared out the keys then I ran the script which returned: on BOX: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 23:51:13.032336 SPI changed uninitialized -> 0x0878469a 23:51:13.063318 SPI changed 0x0878469a -> 0x091b7ada ^C1154 packets captured 1597 packets received by filter 0 packets dropped by kernel on BOX2: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 23:53:43.594785 SPI changed uninitialized -> 0x01d66237 ^C2404 packets captured 9701 packets received by filter 0 packets dropped by kernel box and box2 are the local and end point respectively. /gabe From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 13:53:36 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3791065672; Wed, 31 Dec 2008 13:53:36 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA0DF8FC1B; Wed, 31 Dec 2008 13:53:36 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBVDracA042044; Wed, 31 Dec 2008 13:53:36 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBVDraLJ042040; Wed, 31 Dec 2008 13:53:36 GMT (envelope-from vwe) Date: Wed, 31 Dec 2008 13:53:36 GMT Message-Id: <200812311353.mBVDraLJ042040@freefall.freebsd.org> To: jd@ods.org, vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/130059: [panic] Leaking 50k mbufs/hour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 13:53:37 -0000 Synopsis: [panic] Leaking 50k mbufs/hour State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Dec 31 13:44:37 UTC 2008 State-Changed-Why: Jason, your network setup is looking very complex. Are all these aliases to lo0 really needed? If these are required for IPSec, can you give us an idea of the IPSec SPD entries being used without leaking sensitive information to the public? I think we need to also have a look at the routing tables and output of `sysctl net.inet kern.ipc` might be useful. Also give us the list of loaded modules (kldstat). Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Dec 31 13:44:37 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130059 From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 15:42:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2C21065670; Wed, 31 Dec 2008 15:42:08 +0000 (UTC) (envelope-from vanhu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BADE88FC23; Wed, 31 Dec 2008 15:42:08 +0000 (UTC) (envelope-from vanhu@FreeBSD.org) Received: from freefall.freebsd.org (vanhu@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBVFg8L3027264; Wed, 31 Dec 2008 15:42:08 GMT (envelope-from vanhu@freefall.freebsd.org) Received: (from vanhu@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBVFg83V027260; Wed, 31 Dec 2008 15:42:08 GMT (envelope-from vanhu) Date: Wed, 31 Dec 2008 15:42:08 GMT Message-Id: <200812311542.mBVFg83V027260@freefall.freebsd.org> To: adeepv@gmail.com, vanhu@FreeBSD.org, freebsd-net@FreeBSD.org, vanhu@FreeBSD.org From: vanhu@FreeBSD.org Cc: Subject: Re: kern/129904: [vlan] [panic] kernel crash in "ifconfig destroy" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 15:42:09 -0000 Synopsis: [vlan] [panic] kernel crash in "ifconfig destroy" State-Changed-From-To: open->feedback State-Changed-By: vanhu State-Changed-When: Wed Dec 31 15:38:46 UTC 2008 State-Changed-Why: Your problem seems to be the same as described in kern/126850. It has been fixed in TRUNK by jfv@ and I MFCed it for FreeBSD 7.1-RC2. Please try again with RC2 and confirm us that it also fixes your issue. Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: vanhu Responsible-Changed-When: Wed Dec 31 15:38:46 UTC 2008 Responsible-Changed-Why: Your problem seems to be the same as described in kern/126850. It has been fixed in TRUNK by jfv@ and I MFCed it for FreeBSD 7.1-RC2. Please try again with RC2 and confirm us that it also fixes your issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=129904 From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 18:41:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D80E6106566B for ; Wed, 31 Dec 2008 18:41:50 +0000 (UTC) (envelope-from jason.dicioccio@ods.org) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8403E8FC0C for ; Wed, 31 Dec 2008 18:41:49 +0000 (UTC) (envelope-from jason.dicioccio@ods.org) Received: by nf-out-0910.google.com with SMTP id h3so1185565nfh.33 for ; Wed, 31 Dec 2008 10:41:47 -0800 (PST) Received: by 10.210.43.10 with SMTP id q10mr8031963ebq.179.1230748907352; Wed, 31 Dec 2008 10:41:47 -0800 (PST) Received: by 10.210.80.20 with HTTP; Wed, 31 Dec 2008 10:41:47 -0800 (PST) Message-ID: Date: Wed, 31 Dec 2008 10:41:47 -0800 From: "Jason DiCioccio" To: vwe@freebsd.org In-Reply-To: <200812311353.mBVDraLJ042040@freefall.freebsd.org> MIME-Version: 1.0 References: <200812311353.mBVDraLJ042040@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/130059: [panic] Leaking 50k mbufs/hour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 18:41:51 -0000 (oops.. replying to list(s) as well this time) Hello, On Wed, Dec 31, 2008 at 05:53, wrote: > Synopsis: [panic] Leaking 50k mbufs/hour > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Wed Dec 31 13:44:37 UTC 2008 > State-Changed-Why: > Jason, > your network setup is looking very complex. > Are all these aliases to lo0 really needed? Probably not all of them anymore. The 66.29.58 addresses, while still allocated to us aren't really used anymore, so they could probably go. The rest are needed. > If these are required for IPSec, can you give us an idea > of the IPSec SPD entries being used without leaking sensitive > information to the public? You know.. IPSec is probably the only thing I'm *not* using, though you probably noticed I was at least thinking about it at one point :).. It might not be a bad idea for me to remove it from the kernel though and see what happens.. > I think we need to also have a look at the routing tables and > output of `sysctl net.inet kern.ipc` might be useful. > Also give us the list of loaded modules (kldstat). Sure.. The routing table is managed mainly by quagga (outside of the default route) bgpd. Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 66.246.72.1 UGS 1 2724330 em0 10.8.0.0/25 10.8.0.2 UGS 0 0 tun10 10.8.0.2 10.8.0.1 UH 1 0 tun10 10.8.8.0/24 link#5 UC 0 0 tap0 10.8.8.6 10.8.8.5 UH 0 467 gre0 10.8.8.32 00:ff:9b:11:23:64 UHLW 3 328 tap0 1198 10.8.8.33 00:bd:7f:46:00:00 UHLW 2 13 tap0 845 10.8.8.36 00:ff:c4:72:96:17 UHLW 2 14 tap0 803 10.8.10.0/24 10.8.8.33 UG1 0 0 tap0 64.247.11.248 64.247.11.248 UH 0 0 lo0 64.247.11.249 64.247.11.249 UH 0 0 lo0 64.247.11.250 64.247.11.250 UH 0 0 lo0 64.247.11.251 64.247.11.251 UH 0 0 lo0 64.247.11.252 64.247.11.252 UH 0 0 lo0 64.247.11.253 64.247.11.253 UH 0 0 lo0 64.247.11.254 64.247.11.254 UH 0 0 lo0 64.247.11.255 64.247.11.255 UH 0 0 lo0 66.29.58.64 66.29.58.64 UH 0 0 lo0 66.29.58.65 66.29.58.65 UH 0 0 lo0 66.29.58.66 66.29.58.66 UH 0 0 lo0 66.29.58.67 66.29.58.67 UH 0 0 lo0 66.29.58.68 66.29.58.68 UH 0 0 lo0 66.29.58.69 66.29.58.69 UH 0 0 lo0 66.29.58.70 66.29.58.70 UH 0 0 lo0 66.246.72.0/24 link#1 UC 0 0 em0 66.246.72.1 00:00:5e:00:01:01 UHLW 2 0 em0 671 66.246.72.2 00:90:69:9d:24:00 UHLW 1 0 em0 1200 66.246.72.3 00:90:69:9e:74:00 UHLW 1 0 em0 1199 66.246.72.188 00:1b:21:26:13:f2 UHLW 1 3078 lo0 127.0.0.1 127.0.0.1 UH 0 54997 lo0 172.16.0.0/24 10.8.8.32 UG1 0 0 tap0 192.168.1.0/24 10.8.8.33 UG1 0 210 tap0 192.168.2.0/24 10.8.8.33 UG1 0 0 tap0 192.168.5.0/24 10.8.8.32 UG1 0 3357 tap0 192.168.15.1 192.168.15.1 UH 0 57808 lo0 192.168.21.0/24 10.8.8.33 UG1 0 0 tap0 192.168.25.0/24 10.8.8.36 UG1 0 102 tap0 192.168.30.0/24 10.8.8.33 UG1 0 0 tap0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2001:470:1f06:208::1 UGS gif0 ::1 ::1 UHL lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:470:1f06:208::1 link#4 UHL gif0 2001:470:1f06:208::2 link#4 UHL lo0 2001:470:1f07:208::/64 fe80::1%lo0 U lo0 2001:470:1f07:208::beef:cafe link#2 UHL lo0 2001:470:89e1::/112 link#5 UC tap0 2001:470:89e1::1 00:bd:89:02:01:00 UHL lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 UC em0 fe80::21b:21ff:fe26:13f2%em0 00:1b:21:26:13:f2 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#2 UHL lo0 fe80::%gre0/64 link#3 UC gre0 fe80::21b:21ff:fe26:13f2%gre0 link#3 UHL lo0 fe80::%gif0/64 link#4 UC gif0 fe80::21b:21ff:fe26:13f2%gif0 link#4 UHL lo0 fe80::%tap0/64 link#5 UC tap0 fe80::2bd:89ff:fe02:100%tap0 00:bd:89:02:01:00 UHL lo0 fe80::%tun10/64 link#6 UC tun10 fe80::21b:21ff:fe26:13f2%tun10 link#6 UHL lo0 ff01:1::/32 link#1 UC em0 ff01:2::/32 ::1 UC lo0 ff01:3::/32 link#3 UC gre0 ff01:4::/32 link#4 UC gif0 ff01:5::/32 link#5 UC tap0 ff01:6::/32 link#6 UC tun10 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 link#1 UC em0 ff02::%lo0/32 ::1 UC lo0 ff02::%gre0/32 link#3 UC gre0 ff02::%gif0/32 link#4 UC gif0 ff02::%tap0/32 link#5 UC tap0 ff02::%tun10/32 link#6 UC tun10 -- sysctl net.inet kern.ipc -- net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.ipip.ipip_allow: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 472 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 134 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 13 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.soreceive_dgram_enabled: 0 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.esp.esp_enable: 1 net.inet.ah.ah_cleartos: 1 net.inet.ah.ah_enable: 1 net.inet.ipcomp.ipcomp_enable: 0 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.early_fast_retran_msec: 250 net.inet.sctp.early_fast_retran: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_pf: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 3200 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 0 net.inet.sctp.ecn_nonce: 0 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 233016 net.inet.sctp.sendspace: 233016 net.inet.ipsec.def_policy: 1 net.inet.ipsec.esp_trans_deflev: 1 net.inet.ipsec.esp_net_deflev: 1 net.inet.ipsec.ah_trans_deflev: 1 net.inet.ipsec.ah_net_deflev: 1 net.inet.ipsec.ah_cleartos: 1 net.inet.ipsec.ah_offsetmask: 0 net.inet.ipsec.dfbit: 0 net.inet.ipsec.ecn: 0 net.inet.ipsec.debug: 0 net.inet.ipsec.esp_randpad: -1 net.inet.ipsec.crypto_support: 50331648 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 128 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 25600 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 1409024 kern.ipc.maxpipekva: 26841088 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 812 kern.ipc.semume: 100 kern.ipc.semopm: 100 kern.ipc.semmsl: 512 kern.ipc.semmnu: 256 kern.ipc.semmns: 512 kern.ipc.semmni: 128 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 131072 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 536870912 kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 348 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 37 kern.ipc.nsfbufs: 6656 -- kldstat -- Id Refs Address Size Name 1 7 0xc0400000 4a4314 kernel 2 1 0xc08a5000 6a2c4 acpi.ko 3 1 0xc3e2b000 4000 if_gre.ko 4 1 0xc3e36000 5000 if_gif.ko 5 1 0xc3eda000 33000 pf.ko 6 1 0xc433f000 5000 if_tap.ko > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Wed Dec 31 13:44:37 UTC 2008 > Responsible-Changed-Why: > > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130059 > From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 20:16:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ED4F1065678 for ; Wed, 31 Dec 2008 20:16:54 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id BC4E78FC13 for ; Wed, 31 Dec 2008 20:16:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBVKGoUf010200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Dec 2008 15:16:50 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: "" In-Reply-To: <3418F3471F1CA4409901547349FFAE2E09106883@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 31 Dec 2008 15:16:50 -0500 References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> <835C2156-9DE3-4C96-94F0-C7E3AF63A1BD@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E09106883@ftrdmel2> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Michael Tuexen , khadija.daoud@orange-ftgroup.com, freebsd-net Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 20:16:55 -0000 Aman: You may also want to contact Vlad (copied above) who is responsible for the lk-sctp implementation.. he may be able to direct you to the one that will have all his latest fixes.. Regards R On Dec 30, 2008, at 10:59 AM, = wrote: > > Hello M.T=FCxen, > > Today I switched T (the machine I use for testing, and that sends =20 > data to my PC) to FreeBSD 7.0. And I was very glad to see that my =20 > SCTP hard handover tests went through successfully :-) > > I am very grateful to you, for pointing out that I should check the =20= > INIT - INIT-ACK exchange, because so far I really didn't understand =20= > why my tests failed all the time. > > About lksctp : up until now, my problems were due to the fact that =20 > the CN was running under Linux, with the lksctp implementation, and =20= > that it didn't indicate in the INIT-ACK that it supports ASCONF, =20 > ASCONF-ACK and AUTH chunks at least, even if we have set the =20 > parameter net.sctp.addip_enable to 1. These are required for Dynamic =20= > Address Reconfiguration according to the RFC and very likely in =20 > FreeBSD implementation for sending ASCONF. > > I will perform tests between my PC running under FreeBSD and T =20 > running on Fedora Core 9 to see if I have better results than what =20 > I've had so far (since I was using Fedora Core 7). I will keep you =20 > updated :-) > > Again, thanks a LOT for the help you provided, I'm truly thankful =20 > for this. > > > Aman Jassal > > > > -----Message d'origine----- > De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Envoy=E9 : lundi 29 d=E9cembre 2008 19:00 > =C0 : zze-Abac JASSAL A ext RD-RESA-ISS > Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS > Objet : Re: SCTP : problems in sending ASCONF chunks > > Hi Aman, > > comments in-line. > > Best regards > Michael > > On Dec 29, 2008, at 6:12 PM, = > wrote: > >> >> Hello M.T=FCxen, >> >> I performed a quick test and at the INIT/INIT-ACK exchange, I noticed >> the following : >> >> - In the INIT chunk, the Supported Extensions Parameter field >> indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET >> and AUTH are supported > OK. That is the FreeBSD box. >> >> - In the INIT-ACK chunk, there is no field indicating that any of >> the chunks listed above are supported... > So it does not support ASCONF and AUTH. > At least on a Fedora 9 box you need to enable ADD-IP by setting the > sysctl variable > net.sctp.addip_enable > to 1. > To enable SCTP-AUTH you need to set the sysctl variable > net.sctp.auth_enable > to 1. > I'm not sure whether the Linux box support SCTP-AUTH or not... So the > second step might not work. If this is the case you can disable the > AUTH requirement for ASCONF chunks by setting on the FreeBSD box the > sysctl > variable > net.inet.sctp.asconf_auth_nochk > to 1 > > Let me know if this works... >> >> >> I didn't think about looking in this before >_< >> >> Since there is no indication given to my PC, perhaps my PC assumes >> that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, >> STREAM_RESET and AUTH. > Correct. At least some of the extension are not enabled. >> >> >> Could it be that, because it doesn't see any Supported Extensions >> Parameter field in the INIT-ACK, my PC doesn't try to send any >> ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK >> and AUTH parameters in the Supported Extensions Parameter, in both >> the INIT and the INIT-ACK chunks, to have the possibility of sending >> an ASCONF chunk ? > In principle, yes! You can work around the AUTH chunks as indicated > above, but this > violates the specification and is only supported to interwork with > legacy implementations. >> >> >> >> Kind regards >> >> >> Aman Jassal >> >> >> -----Message d'origine----- >> De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] >> Envoy=E9 : lundi 29 d=E9cembre 2008 16:49 >> =C0 : zze-Abac JASSAL A ext RD-RESA-ISS >> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS >> Objet : Re: SCTP : problems in sending ASCONF chunks >> >> Hi Aman, >> >> I'm not that familiar with the Linux box configuration. If you look >> at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and >> the SCTP-AUTH extension? Both are required... >> >> Best regards >> Michael >> On Dec 29, 2008, at 2:36 PM, = >> wrote: >> >>> >>> Hello M.T=FCxen, >>> >>> No, only the PC is running under FreeBSD 7.0. T is running under >>> Linux >>> (kernel version is 2.6.21 and the distribution used is Fedora Core >>> 7). >>> SCTP is running on T thanks to the lksctp implementation, we loaded >>> the sctp module on it and made the necessary configurations so that >>> it >>> is loaded at boot time. >>> >>> Also, I enable net.sctp.addip_enable=3D1 on T, just in case, I'm not >>> exactly sure if it has an effect on my tests. >>> >>> Kind regards >>> >>> >>> Aman Jassal >>> >>> -----Message d'origine----- >>> De : Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Envoy=E9 : lundi 29 d=E9cembre 2008 14:09 >>> =C0 : zze-Abac JASSAL A ext RD-RESA-ISS >>> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS =20 >>> Objet : >>> Re: SCTP : problems in sending ASCONF chunks >>> >>> Hi, >>> >>> are both machines (T and you PC) running FreeBSD? >>> >>> Best regards >>> Michael >>> >>> On Dec 29, 2008, at 12:33 PM, = >>> wrote: >>> >>>> Hi all, >>>> >>>> I have been working with SCTP and more specifically with the >>>> mobility >>>> features of SCTP at my work. Basically, I have been trying to use >>>> SCTP to perform handover tests between 2 separate Wifi networks. I >>>> use >>>> IPv6 >>>> for all my tests. >>>> >>>> I have a local LAN (wired-network), on which I have 3 machines, one >>>> of them is the machine I use to communicate with for the tests =20 >>>> (I'll >>>> call it T to make things simple), and the other two are used as =20 >>>> Wifi >>>> Access Points (say Wifi1 and Wifi2 respectively). Since I work with >>>> IPv6, I set up both Access Points to send Router Advertisement >>>> messages periodically (minimum of 3 seconds, maximum of 4 seconds). >>>> That way I can have automatic address reconfiguration when I =20 >>>> connect >>>> to either of the access points. >>>> >>>> The aim of my tests is to use a PC, connect to Wifi1 (for example), >>>> launch an SCTP association with T (T sends data to my PC), and then >>>> perform a handover on Wifi2. I do make address reconfiguration >>>> during >>>> the handover process. The important point is that I work with only >>>> ONE address on my network interface. Before I start my tests, I set >>>> the following sysctl parameters : >>>> >>>> # sysctl -w net.inet.sctp.mobility_base=3D1 # sysctl -w >>>> net.inet.sctp.mobility_fasthandoff=3D1 >>>> # sysctl -w net.inet.sctp.debug=3D0x00f301f0 (that is = to dump >>>> messages in /var/log/messages) >>>> >>>> net.inet.sctp.auto_asconf is set to 1 by default. >>>> >>>> I use FreeBSD 7.0 on my PC, I don't know if that is extremely =20 >>>> useful >>>> but I'm trying to be thorough. This is the script I use to perform >>>> handover >>>> : >>>> >>>> ifconfig rum0 inet6 delete ifconfig rum0 ssid >>> target access point> route del -inet6 default =20 >>>> rtsol >>>> rum0 >>>> >>>> If I'm not mistaken, the PC should have sent an ASCONF chunk to >>>> perform dynamic address reconfiguration. However what I observed is >>>> that nothing happens. No ASCONF chunks are sent, and therefore, T >>>> doesn't ever know that it should send data on the PC's newly >>>> acquired >>>> address. >>>> >>>> I tried to investigate the problem myself, by adding some debug =20 >>>> logs >>>> in the sctp source code (to see which functions are called during >>>> the >>>> handover process), and it seems as if the kernel doesn't ever add =20= >>>> an >>>> ASCONF chunk to send in its queue... But that's just my >>>> understanding >>>> of the problem... >>>> >>>> I looked up in the CVS repository for answers, and to see the >>>> various >>>> changes that were gradually brought on the code. There, I noticed >>>> that on the revision dating 24th July 2007, changes were made for >>>> dynamic address reconfiguration : "Change behaviour so that when =20= >>>> the >>>> last address is deleted (auto-asconf on a boudall endpoint) no >>>> action >>>> is taken until an address is added ; at that time an ASCONF >>>> add+delete is sent (if the asoc is still up)" >>>> >>>> In my humble opinion, this is exactly the case that corresponds to >>>> my >>>> handover scenario. But I just haven't been able to successfully >>>> perform it because I don't seem to send any ASCONF chunk. I'm >>>> struggling to understand why I do not see any ASCONF chunk sent. >>>> >>>> If it can help, I'm also attaching links to the kind of debug =20 >>>> logs I >>>> got when performing a handover test. This is the kind of debug logs >>>> that I got : >>>> >>>> http://www.divshare.com/download/6200509-560 >>>> >>>> This is another debug logfile, but with my own debug logs added in >>>> the sctp source code : >>>> >>>> http://www.divshare.com/download/6200504-2e9 >>>> >>>> >>>> Many thanks for your work, and I hope someone will be able to help >>>> and shed some light on this problem :-) >>>> >>>> >>>> Aman Jassal >>>> >>>> _______________________________________________ >>>> 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" >>>> >>> >>> >> >> > > _______________________________________________ > 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Dec 31 23:27:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AADDC106566B for ; Wed, 31 Dec 2008 23:27:38 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD8C8FC12 for ; Wed, 31 Dec 2008 23:27:38 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBVNRZSI015533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:27:36 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBVNRYS8045875; Thu, 1 Jan 2009 10:27:34 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBVNRY6p045874; Thu, 1 Jan 2009 10:27:34 +1100 (EST) (envelope-from peter) Date: Thu, 1 Jan 2009 10:27:34 +1100 From: Peter Jeremy To: ibmed Message-ID: <20081231232734.GE87057@server.vk2pj.dyndns.org> References: <21218952.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline In-Reply-To: <21218952.post@talk.nabble.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: em driver problems? taskq em goes up to 100% CPU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Dec 2008 23:27:39 -0000 --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-30 07:58:58 -0800, ibmed wrote: >There's two FreeBSD boxes that do ipfw nat. >Both worked with natd until some time ago, when it became clear that we ne= ed >a better solution. So I upgraded sources and recompiled to kernel to inclu= de >ipfw nat features. The boxes have onboard msk-net cards that worked fine >under natd. When I ran into similar load issues, I switched to ipfilter because the IPFW kernel NAT didn't exist at the time. If you are unable to find another solution, possibly you could try a different firewall. >options DUMMYNET >options IPDIVERT Are you using dummynet or ipdivert functionality? >fastforwarding is on, polling is off: >net.inet.ip.fastforwarding: 1 Have you tried disabling fastforwarding? What if your hardware configuration and how much traffic are you pushing through the system? --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklb/+YACgkQ/opHv/APuIdY/ACfRKDrhw1wbK0gg9MnB2pyv8Mv hqcAnA05l0TYowJBk+CVPSxZwVdLkYO2 =j3k4 -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG--