From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 00:36:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8489C16A41F for ; Sun, 11 Jun 2006 00:36:40 +0000 (UTC) (envelope-from shaun@rsc.cx) Received: from mail.rsc.cx (mail.rsc.cx [64.235.233.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58D2343D53 for ; Sun, 11 Jun 2006 00:36:37 +0000 (GMT) (envelope-from shaun@rsc.cx) Received: from [::1] (helo=webmail.rsc.cx) by mail.rsc.cx with esmtp (Exim 4.52 (FreeBSD)) id 1FpDwN-0005OO-IP for freebsd-net@freebsd.org; Sat, 10 Jun 2006 17:36:32 -0700 Received: from 81.107.58.115 (SquirrelMail authenticated user shaun@rsc.cx) by webmail.rsc.cx with HTTP; Sat, 10 Jun 2006 17:36:31 -0700 (PDT) Message-ID: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> Date: Sat, 10 Jun 2006 17:36:31 -0700 (PDT) From: "Shaun Colley" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20060610173631_26678" X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -2.8 (--) X-Spam-Report: Spam detection software, running on the system "mail.rsc.cx", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi list. My system is: --- FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 --- I'm writing a kernel module whose job is to modify the inetsw[] switch table for the IPPROTO_TCP protocol. The pr_output hook for TCP needs to be changed, such that my own custom tcp_output function will be called when transmitting TCP packets. The reason for doing this is so that I can do some modification on TCP packets before they are transmitted, but the semantics of this are not important. [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts Subject: Unexpected behavior after altering inetsw[] switch table 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, 11 Jun 2006 00:36:40 -0000 ------=_20060610173631_26678 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi list. My system is: --- FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 --- I'm writing a kernel module whose job is to modify the inetsw[] switch table for the IPPROTO_TCP protocol. The pr_output hook for TCP needs to be changed, such that my own custom tcp_output function will be called when transmitting TCP packets. The reason for doing this is so that I can do some modification on TCP packets before they are transmitted, but the semantics of this are not important. The part of the module of interest is: --- switch (what) { case MOD_LOAD: /* kldload */ uprintf("Skeleton KLD loaded.\n"); old_handler = inetsw[ip_protox[IPPROTO_TCP]].pr_output; inetsw[ip_protox[IPPROTO_TCP]].pr_output = (pr_output_t *)my_tcp_output; break; case MOD_UNLOAD: uprintf("Skeleton KLD unloaded.\n"); inetsw[ip_protox[IPPROTO_TCP]].pr_output = old_handler; break; default: err = EINVAL; break; } --- my_tcp_output is a hacked version of tcp_output. When the module is built and loaded, the modification to the switch table seems to have no effect whatsoever. That is, my custom routine does not seem to be called when outputting TCP packets. This can be demonstrated fully by changing the modification line to: inetsw[ip_protox[IPPROTO_TCP]].pr_output = (pr_output_t *)0x0; - no kernel panic occurs in this case. This ultimately leads me to believe that the hook is not being called, even though it should be (I am attempting to send TCP packets, so my function should be getting called). This is very odd, because when I instead modify the pr_input hook, my custom function *does* get called (i.e. when incoming packets are passed up). For example, by inserting the line 'inetsw[ip_protox[IPPROTO_TCP]].pr_input = (pr_input_t *)my_input_handler;', and then receiving TCP packets from below, my_input_handler *is* entered, whereas if the corresponding TCP pr_output hook is modified, that function does not get called (the regular tcp_output() function seems to get used as normal). I've attached a testcase module which demonstrates the behavior. If the hook replacement works correctly, you'll have a TCP output hook which essentially does nothing (i.e. doesn't pass packet down to next layer), hence your TCP stack shouldn't work properly (so to speak). However, that doesn't happen (at least on my system), as I've said. A makefile is also attached. Note, I'm not saying this is a bug. I'm just wondering what is going wrong. My information (i.e. the way I'm trying to do this) may be out of date, for example. I'm wondering if someone can cast some light on what the problem might be. Also attached is a kernel module that alters the pr_input hook of TCP to a dummy function, similarly to the pr_input one. Loading this one will leave you with a dummy input function, rendering your TCP stack not able to process packets until you unload the module. Note that unloading both of the modules will leave you good to go again. cheers, Shaun ------=_20060610173631_26678 Content-Type: application/octet-stream; name="Makefile.1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile.1" U1JDUz1wcl9vdXRwdXQuYwpLTU9EPXByX291dHB1dAoKLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgo= ------=_20060610173631_26678 Content-Type: application/octet-stream; name="Makefile.2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Makefile.2" U1JDUz1wcl9pbnB1dC5jCktNT0Q9cHJfaW5wdXQKCi5pbmNsdWRlIDxic2Qua21vZC5taz4K ------=_20060610173631_26678 Content-Type: application/octet-stream; name="pr_input.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pr_input.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL21vZHVsZS5oPgojaW5jbHVkZSA8 c3lzL3N5c3RtLmg+ICAvKiB1cHJpbnRmICovIAojaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiNpbmNs dWRlIDxzeXMvcGFyYW0uaD4gIC8qIGRlZmluZXMgdXNlZCBpbiBrZXJuZWwuaCAqLwojaW5jbHVk ZSA8c3lzL2tlcm5lbC5oPiAvKiB0eXBlcyB1c2VkIGluIG1vZHVsZSBpbml0aWFsaXphdGlvbiAq LwojaW5jbHVkZSA8c3lzL3Byb3Rvc3cuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1 ZGUgPHN5cy90aW1lLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvc3lz bG9nLmg+CiNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiNpbmNsdWRlIDxzeXMvZG9tYWluLmg+CiNp bmNsdWRlIDxzeXMvbG9jay5oPgojaW5jbHVkZSA8c3lzL21hYy5oPgojaW5jbHVkZSA8c3lzL21i dWYuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXR2YXIuaD4KI2luY2x1ZGUgPHN5cy9tdXRleC5oPgoK I2luY2x1ZGUgPG5ldC9wZmlsLmg+CiNpbmNsdWRlIDxuZXQvaWYuaD4KI2luY2x1ZGUgPG5ldC9p Zl90eXBlcy5oPgojaW5jbHVkZSA8bmV0L2lmX3Zhci5oPgojaW5jbHVkZSA8bmV0L2lmX2RsLmg+ CiNpbmNsdWRlIDxuZXQvcm91dGUuaD4KI2luY2x1ZGUgPG5ldGluZXQvdGNwX2ZzbS5oPgojaW5j bHVkZSA8bmV0aW5ldC90Y3Bfc2VxLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgojaW5jbHVk ZSA8bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8bmV0aW5ldC9pbl9zeXN0bS5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbl92YXIuaD4KI2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KI2luY2x1ZGUgPG5ldGlu ZXQvdGNwX3RpbWVyLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcF92YXIuaD4KLy8jaW5jbHVkZSA8 bmV0aW5ldC90Y3BpcC5oPgojaW5jbHVkZSA8bmV0aXBzZWMvaXBzZWMuaD4KI2luY2x1ZGUgPG5l dGluZXQvaW5fcGNiLmg+Ci8vI2luY2x1ZGUgPG5ldGluZXQvaXBfdmFyLmg+CiNpbmNsdWRlIDxu ZXRpbmV0L2lwX2ljbXAuaD4KI2luY2x1ZGUgPG1hY2hpbmUvaW5fY2tzdW0uaD4KCmV4dGVybiAg c3RydWN0IHByb3Rvc3cgaW5ldHN3W107CmV4dGVybiB1X2NoYXIgaXBfcHJvdG94W107CnZvaWQg Km9sZF9oYW5kbGVyOwppbnQgbW9vKHN0cnVjdCB0Y3BjYiAqdHApOwovKiAKICogTG9hZCBoYW5k bGVyIHRoYXQgZGVhbHMgd2l0aCB0aGUgbG9hZGluZyBhbmQgdW5sb2FkaW5nIG9mIGEgS0xELgog Ki8KaW50IG1vbyhzdHJ1Y3QgdGNwY2IgKnRwKSB7CnJldHVybiAwOwp9CgpzdGF0aWMgaW50CnNr ZWxfbG9hZGVyKHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0LCB2b2lkICphcmcpCnsKICBpbnQg ZXJyID0gMDsKICAKICBzd2l0Y2ggKHdoYXQpIHsKICBjYXNlIE1PRF9MT0FEOiAgICAgICAgICAg ICAgICAvKiBrbGRsb2FkICovCiAgICB1cHJpbnRmKCJTa2VsZXRvbiBLTEQgbG9hZGVkLlxuIik7 CiAgICBvbGRfaGFuZGxlciA9IGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9pbnB1 dDsKICAgIGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9pbnB1dCA9IChwcl9pbnB1 dF90ICopbW9vOwogICAgYnJlYWs7CiAgY2FzZSBNT0RfVU5MT0FEOgogICAgdXByaW50ZigiU2tl bGV0b24gS0xEIHVubG9hZGVkLlxuIik7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9fVENQ XV0ucHJfaW5wdXQgPSBvbGRfaGFuZGxlcjsKICAgIGJyZWFrOwogIGRlZmF1bHQ6CiAgICBlcnIg PSBFSU5WQUw7CiAgICBicmVhazsKICB9CiAgcmV0dXJuKGVycik7Cn0KCi8qIERlY2xhcmUgdGhp cyBtb2R1bGUgdG8gdGhlIHJlc3Qgb2YgdGhlIGtlcm5lbCAqLwoKCnN0YXRpYyBtb2R1bGVkYXRh X3Qgc2tlbF9tb2QgPSB7CiAgInNrZWwiLAogIHNrZWxfbG9hZGVyLAogIE5VTEwKfTsgIAoKREVD TEFSRV9NT0RVTEUoc2tlbGV0b24sIHNrZWxfbW9kLCBTSV9TVUJfS0xELCBTSV9PUkRFUl9BTlkp Owo= ------=_20060610173631_26678 Content-Type: application/octet-stream; name="pr_output.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pr_output.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL21vZHVsZS5oPgojaW5jbHVkZSA8 c3lzL3N5c3RtLmg+ICAvKiB1cHJpbnRmICovIAojaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiNpbmNs dWRlIDxzeXMvcGFyYW0uaD4gIC8qIGRlZmluZXMgdXNlZCBpbiBrZXJuZWwuaCAqLwojaW5jbHVk ZSA8c3lzL2tlcm5lbC5oPiAvKiB0eXBlcyB1c2VkIGluIG1vZHVsZSBpbml0aWFsaXphdGlvbiAq LwojaW5jbHVkZSA8c3lzL3Byb3Rvc3cuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1 ZGUgPHN5cy90aW1lLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvc3lz bG9nLmg+CiNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiNpbmNsdWRlIDxzeXMvZG9tYWluLmg+CiNp bmNsdWRlIDxzeXMvbG9jay5oPgojaW5jbHVkZSA8c3lzL21hYy5oPgojaW5jbHVkZSA8c3lzL21i dWYuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXR2YXIuaD4KI2luY2x1ZGUgPHN5cy9tdXRleC5oPgoK I2luY2x1ZGUgPG5ldC9wZmlsLmg+CiNpbmNsdWRlIDxuZXQvaWYuaD4KI2luY2x1ZGUgPG5ldC9p Zl90eXBlcy5oPgojaW5jbHVkZSA8bmV0L2lmX3Zhci5oPgojaW5jbHVkZSA8bmV0L2lmX2RsLmg+ CiNpbmNsdWRlIDxuZXQvcm91dGUuaD4KI2luY2x1ZGUgPG5ldGluZXQvdGNwX2ZzbS5oPgojaW5j bHVkZSA8bmV0aW5ldC90Y3Bfc2VxLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgojaW5jbHVk ZSA8bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8bmV0aW5ldC9pbl9zeXN0bS5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbl92YXIuaD4KI2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KI2luY2x1ZGUgPG5ldGlu ZXQvdGNwX3RpbWVyLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcF92YXIuaD4KLy8jaW5jbHVkZSA8 bmV0aW5ldC90Y3BpcC5oPgojaW5jbHVkZSA8bmV0aXBzZWMvaXBzZWMuaD4KI2luY2x1ZGUgPG5l dGluZXQvaW5fcGNiLmg+Ci8vI2luY2x1ZGUgPG5ldGluZXQvaXBfdmFyLmg+CiNpbmNsdWRlIDxu ZXRpbmV0L2lwX2ljbXAuaD4KI2luY2x1ZGUgPG1hY2hpbmUvaW5fY2tzdW0uaD4KCmV4dGVybiAg c3RydWN0IHByb3Rvc3cgaW5ldHN3W107CmV4dGVybiB1X2NoYXIgaXBfcHJvdG94W107CnZvaWQg Km9sZF9oYW5kbGVyOwppbnQgbW9vKHN0cnVjdCB0Y3BjYiAqdHApOwovKiAKICogTG9hZCBoYW5k bGVyIHRoYXQgZGVhbHMgd2l0aCB0aGUgbG9hZGluZyBhbmQgdW5sb2FkaW5nIG9mIGEgS0xELgog Ki8KaW50IG1vbyhzdHJ1Y3QgdGNwY2IgKnRwKSB7CnJldHVybiAwOwp9CgpzdGF0aWMgaW50CnNr ZWxfbG9hZGVyKHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0LCB2b2lkICphcmcpCnsKICBpbnQg ZXJyID0gMDsKICAKICBzd2l0Y2ggKHdoYXQpIHsKICBjYXNlIE1PRF9MT0FEOiAgICAgICAgICAg ICAgICAvKiBrbGRsb2FkICovCiAgICB1cHJpbnRmKCJTa2VsZXRvbiBLTEQgbG9hZGVkLlxuIik7 CiAgICBvbGRfaGFuZGxlciA9IGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9vdXRw dXQ7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9fVENQXV0ucHJfb3V0cHV0ID0gKHByX291 dHB1dF90ICopbW9vOwogICAgYnJlYWs7CiAgY2FzZSBNT0RfVU5MT0FEOgogICAgdXByaW50Zigi U2tlbGV0b24gS0xEIHVubG9hZGVkLlxuIik7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9f VENQXV0ucHJfb3V0cHV0ID0gb2xkX2hhbmRsZXI7CiAgICBicmVhazsKICBkZWZhdWx0OgogICAg ZXJyID0gRUlOVkFMOwogICAgYnJlYWs7CiAgfQogIHJldHVybihlcnIpOwp9CgovKiBEZWNsYXJl IHRoaXMgbW9kdWxlIHRvIHRoZSByZXN0IG9mIHRoZSBrZXJuZWwgKi8KCgpzdGF0aWMgbW9kdWxl ZGF0YV90IHNrZWxfbW9kID0gewogICJza2VsIiwKICBza2VsX2xvYWRlciwKICBOVUxMCn07ICAK CkRFQ0xBUkVfTU9EVUxFKHNrZWxldG9uLCBza2VsX21vZCwgU0lfU1VCX0tMRCwgU0lfT1JERVJf QU5ZKTsK ------=_20060610173631_26678-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 01:50:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B978F16A41A; Sun, 11 Jun 2006 01:50:13 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 540E143D45; Sun, 11 Jun 2006 01:50:13 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:0:8002:cc24:87fd:497a:419a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A984815228; Sun, 11 Jun 2006 10:50:11 +0900 (JST) Date: Sun, 11 Jun 2006 10:49:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bruce A. Mah" In-Reply-To: <4488C625.9060103@freebsd.org> References: <20060506172742.GM15353@hoeg.nl> <445EC341.60406@freebsd.org> <20060508065841.GN15353@hoeg.nl> <44885141.1000400@freebsd.org> <4488C625.9060103@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net , Ed Schouten Subject: Re: nd6_lookup prints bogus messages with point to point devices 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, 11 Jun 2006 01:50:13 -0000 >>>>> On Thu, 08 Jun 2006 17:51:49 -0700, >>>>> "Bruce A. Mah" said: >> If memory serves me right, George V. Neville-Neil wrote: >>> After way too long this has been tested and committed to HEAD, with an >>> MFC timout of 1 week. I have done only limited, aka, ping, testing of >>> this fix. >>> >>> I am currently setting up my own outbound IPv6 network so that I can >>> do more real world testing of such patches in future. >> >> Thanks George and JINMEI-san! I've merged this patch into my local >> RELENG_6 tree and will give it a try on my IPv6 tunnel endpoint...will >> report back results. > So far so good...no signs of those error messages after a workday's > worth of uptime. Although I can't claim to be a heavy IPv6 user, I > would have noticed those messages by now with pre-patch code. I'll keep > an eye on it for a few more days, but if you don't hear anything from > me, please count me as an "the fix works for me". I'm happy to hear that. Thanks for the test and confirmation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 11:08:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B66EF16A41B for ; Sun, 11 Jun 2006 11:08:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A95C643D46 for ; Sun, 11 Jun 2006 11:08:43 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.176.255] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu10) with ESMTP (Nemesis), id 0ML31I-1FpNnx0V3g-0000RU; Sun, 11 Jun 2006 13:08:31 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 11 Jun 2006 13:08:13 +0200 User-Agent: KMail/1.9.1 References: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> In-Reply-To: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5383948.DQHWhtUWyu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606111308.28468.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Shaun Colley Subject: Re: Unexpected behavior after altering inetsw[] switch table 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, 11 Jun 2006 11:08:44 -0000 --nextPart5383948.DQHWhtUWyu Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 11 June 2006 02:36, Shaun Colley wrote: > I'm writing a kernel module whose job is to modify the inetsw[] switch > table for the IPPROTO_TCP protocol. The pr_output hook for TCP needs to > be changed, such that my own custom tcp_output function will be called > when transmitting TCP packets. The reason for doing this is so that I can > do some modification on TCP packets before they are transmitted, but the > semantics of this are not important. > > The part of the module of interest is: > > --- > switch (what) { > case MOD_LOAD: /* kldload */ > uprintf("Skeleton KLD loaded.\n"); > old_handler =3D inetsw[ip_protox[IPPROTO_TCP]].pr_output; > inetsw[ip_protox[IPPROTO_TCP]].pr_output =3D (pr_output_t > *)my_tcp_output; break; > case MOD_UNLOAD: > uprintf("Skeleton KLD unloaded.\n"); > inetsw[ip_protox[IPPROTO_TCP]].pr_output =3D old_handler; > break; > default: > err =3D EINVAL; > break; > } > --- > > my_tcp_output is a hacked version of tcp_output. As you can see in netinet/in_proto.c, tcp does not use pr_output, but calls= =20 tcp_output() directly where needed. Depending on what you want to achive i= t=20 might be enough to hack up tcp_usr_send() and replace tcp_usrreqs.pru_send= =20 instead. Replaceing tcp_output() is not easily possible. You could start=20 with telling us what you *really* want to do so we can point you to a=20 workable option. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5383948.DQHWhtUWyu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEi/msXyyEoT62BG0RAoJbAJ9phWmhrJVesn05D8DTRJPj4Kr0AwCfYhsS 1qI0LId/zt1FrCCu+GA/Ep8= =slsg -----END PGP SIGNATURE----- --nextPart5383948.DQHWhtUWyu-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 12:29:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D5716A418 for ; Sun, 11 Jun 2006 12:29:10 +0000 (UTC) (envelope-from shaun@rsc.cx) Received: from mail.rsc.cx (mail.rsc.cx [64.235.233.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4354943D58 for ; Sun, 11 Jun 2006 12:29:08 +0000 (GMT) (envelope-from shaun@rsc.cx) Received: from [::1] (helo=webmail.rsc.cx) by mail.rsc.cx with esmtp (Exim 4.52 (FreeBSD)) id 1FpP3t-0005xC-J4; Sun, 11 Jun 2006 05:29:02 -0700 Received: from 81.107.58.115 (SquirrelMail authenticated user shaun@rsc.cx) by webmail.rsc.cx with HTTP; Sun, 11 Jun 2006 05:29:01 -0700 (PDT) Message-ID: <52332.81.107.58.115.1150028941.squirrel@webmail.rsc.cx> In-Reply-To: <200606111308.28468.max@love2party.net> References: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> <200606111308.28468.max@love2party.net> Date: Sun, 11 Jun 2006 05:29:01 -0700 (PDT) From: "Shaun Colley" To: "Max Laier" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -2.8 (--) X-Spam-Report: Spam detection software, running on the system "mail.rsc.cx", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Max & group, > As you can see in netinet/in_proto.c, tcp does not use pr_output, but > calls > tcp_output() directly where needed. Depending on what you want to achive > it > might be enough to hack up tcp_usr_send() and replace tcp_usrreqs.pru_send > instead. Replaceing tcp_output() is not easily possible. You could start > with telling us what you *really* want to do so we can point you to a > workable option. [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts Cc: freebsd-net@freebsd.org, Shaun Colley Subject: Re: Unexpected behavior after altering inetsw[] switch table 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, 11 Jun 2006 12:29:10 -0000 Hi Max & group, > As you can see in netinet/in_proto.c, tcp does not use pr_output, but > calls > tcp_output() directly where needed. Depending on what you want to achive > it > might be enough to hack up tcp_usr_send() and replace tcp_usrreqs.pru_send > instead. Replaceing tcp_output() is not easily possible. You could start > with telling us what you *really* want to do so we can point you to a > workable option. Right, I'll start by telling you what I'm actually trying to achieve. Everytime an IP datagram with a TCP header is sent, I want to mangle (i.e. modify) part of the TCP packet and it's payload with 'random' data. Although this may sound a bit pointless, I want to do this to implement a form of dumb fuzzing, which is a form of stress testing used a lot in computer security. Does that make a bit of sense? So I was attempting to modify the pr_output hook for TCP (which I now know isn't possible) and replace it with a ptr to my own hacked tcp_output routine. Can you see a way to do what I'm trying to achieve? Cheers, shaun From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 12:52:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD33D16A41F for ; Sun, 11 Jun 2006 12:52:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33E8E43D45 for ; Sun, 11 Jun 2006 12:52:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.176.255] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FpPQQ0u56-0000se; Sun, 11 Jun 2006 14:52:20 +0200 From: Max Laier Organization: FreeBSD To: "Shaun Colley" Date: Sun, 11 Jun 2006 14:52:05 +0200 User-Agent: KMail/1.9.1 References: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> <200606111308.28468.max@love2party.net> <52332.81.107.58.115.1150028941.squirrel@webmail.rsc.cx> In-Reply-To: <52332.81.107.58.115.1150028941.squirrel@webmail.rsc.cx> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1859497.ntLraXUpWu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606111452.17556.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: Re: Unexpected behavior after altering inetsw[] switch table 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, 11 Jun 2006 12:52:25 -0000 --nextPart1859497.ntLraXUpWu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 11 June 2006 14:29, Shaun Colley wrote: > Hi Max & group, > > > As you can see in netinet/in_proto.c, tcp does not use pr_output, but > > calls > > tcp_output() directly where needed. Depending on what you want to achi= ve > > it > > might be enough to hack up tcp_usr_send() and replace > > tcp_usrreqs.pru_send instead. Replaceing tcp_output() is not easily > > possible. You could start with telling us what you *really* want to do = so > > we can point you to a workable option. > > Right, I'll start by telling you what I'm actually trying to achieve. > Everytime an IP datagram with a TCP header is sent, I want to mangle (i.e. > modify) part of the TCP packet and it's payload with 'random' data. > Although this may sound a bit pointless, I want to do this to implement a > form of dumb fuzzing, which is a form of stress testing used a lot in > computer security. Does that make a bit of sense? > > So I was attempting to modify the pr_output hook for TCP (which I now know > isn't possible) and replace it with a ptr to my own hacked tcp_output > routine. > > Can you see a way to do what I'm trying to achieve? You should tap into the generic IP packet filter hook and modify the packet= =20 from there. Look in netinet/ip_fw_pfil.c or contrib/pf/net/pf_ioctl.c for= =20 examples how to place a hook in there. The PFIL_OUT hook is what you want= =20 and lets you see every packet sent outbound after IP header has been=20 prepended. You will have to do some parsing of the IP header to get to the= =20 TCP part, but ip_fw2.c and pf.c should offer enough information on how to d= o=20 that. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1859497.ntLraXUpWu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEjBIBXyyEoT62BG0RAnX4AJ9WnxdBXqthanMDWslKxWt/A1uUVwCeOjip MxKykqr51/Mx+i0eqn0fqVQ= =7ehD -----END PGP SIGNATURE----- --nextPart1859497.ntLraXUpWu-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 15:36:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86AD316A418 for ; Sun, 11 Jun 2006 15:36:11 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F4B43D4C for ; Sun, 11 Jun 2006 15:36:10 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so776790wxd for ; Sun, 11 Jun 2006 08:36:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZRCp/419X29TNH5XgGbeg/HTcOEBWvPl+lhW/e/ynEgGCuychZ8976BR+7L0xyGEi1hIWQfNECX66QMT2V/0uOr3ppxeRsAHgbIJbwpmJ1C7keAH1z8nvm+YKVWHgEztg84S2n1IWWUrxvUDTzFfmsncALtiLk4ySdp90GrG6I8= Received: by 10.70.73.15 with SMTP id v15mr5561749wxa; Sun, 11 Jun 2006 08:36:08 -0700 (PDT) Received: by 10.70.108.17 with HTTP; Sun, 11 Jun 2006 08:36:08 -0700 (PDT) Message-ID: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> Date: Sun, 11 Jun 2006 16:36:08 +0100 From: "Joao Barros" To: "Vadim Goncharov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 11 Jun 2006 15:36:11 -0000 Hi, I'm very interested in this, great work! :-) I can't load the kld on my Sun Sparc, I think I messed up ld yesterday trying to patch for a bug that show's in firefox and mozilla. It compiles, just doesn't run. As soon as I have it up and running I'll give you feedback. Have you tested it with pf? If so can you give me some examples? I'm particularly interested in this for doing packed shaping, especially on P2P. Thanks for your work! On 6/10/06, Vadim Goncharov wrote: > Hello All! > > I wrote new netgraph(4) node, called ng_tag, able to match packets by > their mbuf_tags(9) and assign new tags to mbufs. This can be used for > many things in the kernel network subsystem, but particularly useful > with recently added ipfw(8) tag/tagged functionality (will be MFCed to > RELENG_6 after Jun 24). > > With this node, in conjunction with ng_bpf(4), I was able to match and > block (perhaps shaping is also possible, but this relies solely on ipfw) > DirectConnect P2P data connections traffic - you know, they're using > random ports, so you can't match them with usual firewall rules and must > check data payload contents of the packets. See man page for example of > how to do this. > > Download files from here: http://antigreen.org/vadim/freebsd/ng_tag/ > Then do: > > make > kldload ./ng_tag.ko > > Man page can be viewed as: > > cat ng_tag.4 | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man \ > -Tascii | /usr/bin/col | more -s > > Please especially test tags with non-zero tag_len, if you can (though it's > not needed for ipfw). > > P.S. BTW, what is correct subject prefix for new contributions? I think > [PATCH] is not correct as these are new files, not patch :) > > -- > WBR, Vadim Goncharov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Joao Barros From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 20:20:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C9216A418; Sun, 11 Jun 2006 20:20:33 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 526DF43D48; Sun, 11 Jun 2006 20:20:33 +0000 (GMT) (envelope-from vadim_nuclight@mail.ru) Received: from [82.211.136.13] (port=16189 helo=nuclight.avtf.net) by mx6.mail.ru with esmtp id 1FpWQ5-000K4p-00; Mon, 12 Jun 2006 00:20:29 +0400 Date: Mon, 12 Jun 2006 03:19:44 +0700 To: "Joao Barros" References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: freebsd-isp@freebsd.org, "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-ipfw@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 11 Jun 2006 20:20:34 -0000 11.06.06 @ 22:36 Joao Barros wrote: Original message is at: http://lists.freebsd.org/pipermail/freebsd-current/2006-June/063821.html > I'm very interested in this, great work! :-) > I can't load the kld on my Sun Sparc, I think I messed up ld yesterday > trying to patch for a bug that show's in firefox and mozilla. It > compiles, just doesn't run. As soon as I have it up and running I'll > give you feedback. Umm, that's a kernel module, it shouldn't have any relations with ld. What diagnostics has it said on failed load? > Have you tested it with pf? If so can you give me some examples? No, it wasn't tested with pf. The problem with pf is that pf compiles all the rules at the time, so exact tags representation can change each time (for this reason ipfw tags were made incompatible with pf), and you must that values to supply them to . However, if you find a method how to obtain tag values info from in-kernel pf structures, you'll be able to use it with pf. It doesn't support well integration with netgraph, though. Another option is to use ipfw - it supports pf's altq(4) shaping, if that is all you need. > I'm particularly interested in this for doing packed shaping, especially > on P2P. Yes, I'm also looking for possibility of shaping, but I can't test (no resources) it currently. Also, as it seems non-trivial on current ipfw dynamic rules implementation, I don't know if shaping will work at all. But you can try to test such ruleset (it supposes that dynamic rules are checked twice, on incoming packets and on outgoing also, as with all other rules as ipfw manpage says): # first, split traffic to incoming to our router and outgoing ipfw add 100 skipto 600 ip from any to any out # check-state for incoming packets will catch all already matched # p2p connections, and continue to "tag 412" rest of them ipfw add 200 check-state # pass yet unrecognized incoming traffic to netgraph for analyzing # note that only one packet for connection will be tagged, not others # in the flow! ipfw add 300 netgraph 41 ip from any to any # XXX more limits? # let's create a state dynamic rule after one tagged packet - dynamic # rules only match addresses and ports, and then use parent rule to # determine action, and will also "tag 412" for every next packet # in that connection, so that's the way how we can catch packets on output # from our router ipfw add 400 pass tag 412 ip from any to any tagged 412 keep-state # this is the point where all other unmatched incoming traffic goes so # it must caught here or it will be matched for next rule, but next rule # should match outgoing traffic only ipfw add 500 pass ip from any to any # here is output were all packets which belong to p2p connections are # tagged 412 by dynamic rules, so we can send them all to pipe (or you # can use altq(4) here, of course).. the only thing to note that packets # to both directions of our router are sent to only one pipe, but for # my example it's enough ipfw add 600 pipe 40 ip from any to any tagged 412 -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 22:30:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 236F616A41A for ; Sun, 11 Jun 2006 22:30:19 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31E2543D53 for ; Sun, 11 Jun 2006 22:30:17 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so810845wxd for ; Sun, 11 Jun 2006 15:30:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uT/hS15Lafsp+iWe7oaHe4R3KV1FU7FlhPpsfvQEIx8LtCK9MWEc2H/t0l13kNCl2VDe1SmRenO6WDxmRMk56PCAdgNztESwPyynWNOjjGXo9Jpp59T9xtllvzQ6kmeQ/tPgg+o0ESrbEY3o8HJnqd5pq/YlenuwVc9PUkzUNiY= Received: by 10.70.8.2 with SMTP id 2mr5859431wxh; Sun, 11 Jun 2006 15:30:16 -0700 (PDT) Received: by 10.70.108.17 with HTTP; Sun, 11 Jun 2006 15:30:16 -0700 (PDT) Message-ID: <70e8236f0606111530i5ec5cd7eh7230ac76f466f1d@mail.gmail.com> Date: Sun, 11 Jun 2006 23:30:16 +0100 From: "Joao Barros" To: "Vadim Goncharov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> Cc: freebsd-isp@freebsd.org, "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-ipfw@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 11 Jun 2006 22:30:19 -0000 On 6/11/06, Vadim Goncharov wrote: > 11.06.06 @ 22:36 Joao Barros wrote: > > Original message is at: > http://lists.freebsd.org/pipermail/freebsd-current/2006-June/063821.html > > > I'm very interested in this, great work! :-) > > I can't load the kld on my Sun Sparc, I think I messed up ld yesterday > > trying to patch for a bug that show's in firefox and mozilla. It > > compiles, just doesn't run. As soon as I have it up and running I'll > > give you feedback. > > Umm, that's a kernel module, it shouldn't have any relations with ld. What > diagnostics has it said on failed load? ultra5# make Warning: Object directory not changed from original /root/ng_tag @ -> /usr/src/sys machine -> /usr/src/sys/sparc64/include touch opt_netgraph.h cc -O2 -pipe -g -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/root/ng_tag -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=15000 -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c ng_tag.c ld -d -warn-common -r -d -o ng_tag.kld ng_tag.o touch export_syms awk -f /sys/conf/kmod_syms.awk ng_tag.kld export_syms | xargs -J% objcopy % ng_tag.kld ld -Bshareable -d -warn-common -o ng_tag.ko ng_tag.kld objcopy --strip-debug ng_tag.ko ultra5# kldload ./ng_tag.kld kldload: can't load ./ng_tag.kld: Exec format error ultra5# file ng_tag.kld ng_tag.kld: ELF 64-bit MSB relocatable, SPARC V9, version 1 (FreeBSD), not stripped > > > Have you tested it with pf? If so can you give me some examples? > > No, it wasn't tested with pf. The problem with pf is that pf compiles all > the rules at the time, so exact tags representation can change each time > (for this reason ipfw tags were made incompatible with pf), and you must > that values to supply them to . However, if you find a method how to > obtain tag values info from in-kernel pf structures, you'll be able to use > it with pf. It doesn't support well integration with netgraph, though. > > Another option is to use ipfw - it supports pf's altq(4) shaping, if that > is all you need. > > > I'm particularly interested in this for doing packed shaping, especially > > on P2P. > > Yes, I'm also looking for possibility of shaping, but I can't test (no > resources) it currently. Also, as it seems non-trivial on current ipfw > dynamic rules implementation, I don't know if shaping will work at all. I'm not a ipfw user, but if this were to be possible it would be very nice :-) -- Joao Barros From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 09:56:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52ADC16A41F; Mon, 12 Jun 2006 09:56:01 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79F3943D48; Mon, 12 Jun 2006 09:56:00 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 6DA2E10D33C; Mon, 12 Jun 2006 16:55:57 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 2F35510D337; Mon, 12 Jun 2006 16:55:57 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 16:55:57 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 16:55:56 +0700 To: "Joao Barros" References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> <70e8236f0606111530i5ec5cd7eh7230ac76f466f1d@mail.gmail.com> Message-ID: Date: Mon, 12 Jun 2006 16:55:41 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <70e8236f0606111530i5ec5cd7eh7230ac76f466f1d@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 12 Jun 2006 09:55:56.0951 (UTC) FILETIME=[66A27A70:01C68E06] Cc: freebsd-isp@freebsd.org, "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-ipfw@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 09:56:01 -0000 12.06.06 @ 05:30 Joao Barros wrote: > ld -d -warn-common -r -d -o ng_tag.kld ng_tag.o > touch export_syms > awk -f /sys/conf/kmod_syms.awk ng_tag.kld export_syms | xargs -J% > objcopy % ng_tag.kld > ld -Bshareable -d -warn-common -o ng_tag.ko ng_tag.kld > objcopy --strip-debug ng_tag.ko > ultra5# kldload ./ng_tag.kld > kldload: can't load ./ng_tag.kld: Exec format error > ultra5# file ng_tag.kld > ng_tag.kld: ELF 64-bit MSB relocatable, SPARC V9, version 1 (FreeBSD), > not stripped Huh, you should load ng_tag.ko, not ng_tag.kld - as you can see ng_tag.ko (final version) is produced from ng_tag.kld (immediate file). Another possibility you should mention is using both firewalls at the same time, ipfw and pf. The rule order traversal, AFAIK, depends on order of module loading, so you should experiment a little with it. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 10:09:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C3C316A41A; Mon, 12 Jun 2006 10:09:37 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A91E43D45; Mon, 12 Jun 2006 10:09:36 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 63A9C10D33B; Mon, 12 Jun 2006 17:09:35 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 49CF410D337; Mon, 12 Jun 2006 17:09:35 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 17:09:35 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 17:09:34 +0700 To: Ganbold References: <448CDBA0.2010203@micom.mng.net> Message-ID: Date: Mon, 12 Jun 2006 17:09:19 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <448CDBA0.2010203@micom.mng.net> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 12 Jun 2006 10:09:35.0066 (UTC) FILETIME=[4E44EBA0:01C68E08] Cc: freebsd-isp@freebsd.org, "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 10:09:37 -0000 12.06.06 @ 10:12 Ganbold wrote: > Vadim Goncharov wrote: >> Hello All! >> >> I wrote new netgraph(4) node, called ng_tag, able to match packets by >> their mbuf_tags(9) and assign new tags to mbufs. This can be used for >> many things in the kernel network subsystem, but particularly useful >> with recently added ipfw(8) tag/tagged functionality (will be MFCed to >> RELENG_6 after Jun 24). >> >> With this node, in conjunction with ng_bpf(4), I was able to match and >> block (perhaps shaping is also possible, but this relies solely on >> ipfw) DirectConnect P2P data connections traffic - you know, they're >> using random ports, so you can't match them with usual firewall rules >> and must check data payload contents of the packets. See man page for >> example of how to do this. >> >> Download files from here: http://antigreen.org/vadim/freebsd/ng_tag/ >> Then do: >> >> make >> kldload ./ng_tag.ko >> >> Man page can be viewed as: >> >> cat ng_tag.4 | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char \ >> -man -Tascii | /usr/bin/col | more -s >> >> Please especially test tags with non-zero tag_len, if you can (though >> it's not needed for ipfw). >> >> P.S. BTW, what is correct subject prefix for new contributions? I think >> [PATCH] is not correct as these are new files, not patch :) > You mentioned about L7 filtering possibility, is it possible to filter > skype, msn, yahoo messenger traffics using ng_tag? No. True L7 filtering requires complete flow analysis (especially for skype), and in kernel we only can do per-packet analysis - but that's enough for simple things, like most P2P networks. > If you can put some additional examples how to block above that would be > great. This is just my thought. No. Man page is an example of using ng_tag node only, and creating matching patterns for another nodes is another great topic. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 11:03:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B85B16A4CB for ; Mon, 12 Jun 2006 11:03:06 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C8543D46 for ; Mon, 12 Jun 2006 11:03:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5CB35Tq098940 for ; Mon, 12 Jun 2006 11:03:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5CB34ZG098936 for freebsd-net@freebsd.org; Mon, 12 Jun 2006 11:03:04 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Jun 2006 11:03:04 GMT Message-Id: <200606121103.k5CB34ZG098936@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 12 Jun 2006 11:03:06 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro a [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 12:00:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9308416A484 for ; Mon, 12 Jun 2006 12:00:12 +0000 (UTC) (envelope-from sebastien.valsemey@vsystems.eu) Received: from pallena.vsystems.eu (pallena.vsystems.eu [195.5.252.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711AF43D45 for ; Mon, 12 Jun 2006 12:00:10 +0000 (GMT) (envelope-from sebastien.valsemey@vsystems.eu) DKIM-Signature: a=rsa-sha1; c=simple; d=vsystems.eu; s=VSystems; t=1150114014; x=1150718814; q=dns; h=DomainKey-Signature:From:To: Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:Thread-Index; b=QETYoQXAv9tILZJM0oq9+q FkVIVjZdACQ0JOB7Xwe2qiZLgjSM2UAcoHx9246bCWKE1xhROxkWePaiESWzxhNR Ht35DUnwHZPTaosklB060iLyRJ2dXVRacjcBGpPlOUOpPAiD0KdiGjQWish/dwh5 Qljufx6ew3wQKcrtIkWGU= DomainKey-Signature: a=rsa-sha1; s=VSystems; d=vsystems.eu; c=simple; q=dns; h=from:message-id; b=r443xXWyGaQlnRaiBb/V/wJDcVGjInDB0JOIVR8i6bAeJfnQbsv5j08/pkPD JeL0YyMzZPV5Iicu1rhM1EZhGVT3QSeouIdhRHnlvSVa2w4/17o+GlBPh Vicm7u5FqYJEzDb7UPcJxbealPXzYv/C+/34eQtPJPLz01SoyW1nPc=; From: =?iso-8859-1?Q?S=E9bastien_A._VALSEMEY?= To: Date: Mon, 12 Jun 2006 14:02:17 +0200 Message-ID: <009e01c68e18$0e1738c0$0da7a8c0@FR.B3W> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaOGAzmx9EGBtcZSV+mYYnENhe26A== X-HashCash: 1:20:060612:freebsd-net@freebsd.org::yUubZzkyteW5HOSa:000000000000000000000000000000000000004joU X-Return-Path: sebastien.valsemey@vsystems.eu X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-Spam-Processed: pallena.vsystems.eu, Mon, 12 Jun 2006 14:06:53 +0200 Subject: IPF and OOW problems 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, 12 Jun 2006 12:00:12 -0000 Hello, I currently have a FreeBSD 6.1-STABLE box configured as a router/firewall with ipfilter v4.1.8. WAN_IP/32 | tun0 | |---------| | FreeBSD | |---------| / \ xl0 xl1 / \ 192.168.0.0/24 DMZ_BLOCK/29 I often experience in my ipf logs such packet drops (the following example is for an active upload on a FTP server located on the first IP of the DMZ network). My IPs have been voluntary hidden for privacy purposes. ipmon[329]: 13:12:41.185263 tun0 @0:110 b REMOTE_WAN_IP,8600 -> DMZ_IP_1,20 PR tcp len 20 1300 -A IN OOW ipmon[329]: 13:12:41.186493 tun0 @0:110 b REMOTE_WAN_IP,8600 -> DMZ_IP_1,20 PR tcp len 20 356 -AP IN OOW Packet drop occurs a few seconds after the beginning of the transfer, even allowing a few kilobytes to be uploaded, which means that the connection establishes well. And on another hand, when I try to reach DMZ machines from the LAN (for example via RDP), I am systematically dropped with the same kind of OOW packet, I mean the connection is not even established. As ICMP is allowed on the whole network, I can traceroute and reach each host in the network, from inside and outside (except for the natted LAN...). The IP masquerading for hosts located on LAN works perfectly as they can go on the Internet without any problem. When I add the two following lines in my ipf ruleset, everything runs smoothly (but insecured!): pass in quick all pass out quick all I heard that such problems occur with the same version of ipf on Solaris (http://msgs.securepoint.com/cgi-bin/get/ipfilter-0605/28.html), but I am not sure it happens because of that. What I did wrong? Thank you by advance for your help. Here are extracts from my main configuration files: [/etc/rc.conf] <... *snip*! ...> firewall_enable="NO" firewall_script="/etc/rc.firewall" firewall_type="/etc/rc.firewall.rules" firewall_logging="YES" gateway_enable="YES" icmp_drop_redirects="YES" ifconfig_lo0="inet 127.0.0.1" ifconfig_xl0="inet 192.168.0.254 netmask 255.255.255.0" ifconfig_xl1="inet DMZ_IP_6 netmask 255.255.255.248" ipfilter_enable="YES" ipfilter_rules="/etc/ipf.rules" ipnat_enable="YES" ipnat_program="/sbin/ipnat" ipnat_rules="/etc/ipnat.rules" ipnat_flags="" ipmon_enable="YES" ipmon_program="/sbin/ipmon" ipmon_flags="-Ds" kern_securelevel="0" kern_securelevel_enable="NO" network_interfaces="lo0 xl0 xl1" ppp_enable="YES" ppp_mode="ddial" ppp_nat="NO" ppp_profile="My_ISP_PROFILE" <... *snip*! ...> [/etc/ipf.rules] # Allow localhost traffic pass in quick on lo0 all pass out quick on lo0 all # Allow all outgoing traffic from this gateway pass out quick on tun0 from any to any keep state pass out quick on tun0 proto tcp from any to any keep state pass out quick on xl0 from any to 192.168.0.0/24 keep state pass out quick on xl0 proto tcp from any to 192.168.0.0/24 keep state pass out quick on xl1 from any to DMZ_BLOCK/29 keep state pass out quick on xl1 proto tcp from any to DMZ_BLOCK/29 keep state # Allow ICMP traffic (for testing purposes) pass in quick on xl0 proto icmp from 192.168.0.0/24 to any keep state pass in quick on xl1 proto icmp from DMZ_BLOCK/29 to any keep state pass in quick on tun0 proto icmp from any to 192.168.0.0/24 keep state pass in quick on tun0 proto icmp from any to DMZ_BLOCK/29 keep state pass out quick proto icmp from any to any keep state # Allow FTP server pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = ftp-data keep state pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = ftp-data keep state pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = ftp keep state pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = ftp keep state # This is for the passive ports range... pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port 4000 >< 4049 keep state pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port 4000 >< 4049 keep state # Allow Terminal services pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = rdp keep state pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = rdp keep state # Default block in log all block return-rst in log proto tcp from any to any block return-icmp-as-dest(port-unr) in log proto udp from any to any [/etc/ipnat.rules] map tun0 192.168.0.0/24 -> WAN_IP/32 map tun0 192.168.0.0/24 -> WAN_IP/32 portmap tcp/udp auto [KERNEL_CONFIG] device bpf options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_SOCKET From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 12:09:45 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4445116A473; Mon, 12 Jun 2006 12:09:45 +0000 (UTC) (envelope-from wooded@queries.co.uk) Received: from ip80-74.baltnet.ru (ip80-74.baltnet.ru [217.168.74.80]) by mx1.FreeBSD.org (Postfix) with SMTP id EEC9643D46; Mon, 12 Jun 2006 12:09:39 +0000 (GMT) (envelope-from wooded@queries.co.uk) Date: Mon, 12 Jun 2006 12:09:57 +0000 From: "roy yarian" X-Mailer: The Bat! (v3.0.9.18) Professional X-Priority: 3 (Normal) Message-ID: <017956329.20060311073644@217.168.74.80> To: net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/related; boundary="----------53D40CE1F627A89B" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: He who goes to sleep with itchy ass, wakes up with smelly finger X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wooded@queries.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:09:45 -0000 ------------53D40CE1F627A89B Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Good evening, [cid:53D40CE1.F627A89B.53D40CE1.F627A89B_csseditor] untavirazolas[dot]com ---- fine--the early calves were the size of a peasant's cow, and Pava's daughter, at three months old, was as big as a yearling-- Levin gave orders for a trough to be brought out and for them to be fed in the paddock. But it appeared that as the paddock had not been used during the winter, the hurdles made in the autumn for it were broken. He sent for the carpenter, who, according to his orders, ought to have been at work at the thrashing machine. But it appeared that the carpenter was repairing the harrows, which ought to have been repaired before Lent. This was very annoying to Levin. It was annoying to come upon that everlasting slovenliness in the farm work against which he had been striving with all his might for so many years. The hurdles, as he ascertained, being not wanted in winter, had been carried to the cart-horses' stable; and there broken, as they were of light construction, only meant for feeding calves. Moreover, it was apparent also that the harrows and all the agricultural implements, which he had directed to be looked over and repaired in the winter, for which very purpose he had hired three carpenters, had not been put into repair, and the harrows were being repaired when they ought to have been harrowing the field. Levin sent for his bailiff, but immediately went off himself to ------------53D40CE1F627A89B-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 12:50:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E61E616A4CA; Mon, 12 Jun 2006 12:50:24 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 996C443D80; Mon, 12 Jun 2006 12:50:14 +0000 (GMT) (envelope-from vadim_nuclight@mail.ru) Received: from [82.211.136.13] (port=4686 helo=nuclight.avtf.net) by mx27.mail.ru with esmtp id 1Fplri-0004V8-00; Mon, 12 Jun 2006 16:50:04 +0400 Date: Mon, 12 Jun 2006 19:48:50 +0700 To: "Eduardo Meyer" , freebsd-current@freebsd.org References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 12:50:25 -0000 12.06.06 @ 05:34 Eduardo Meyer wrote: > I read the messages and man page but did not understand. Maybe it is > my lack of knowledge regarding netgraph? Well, in man page it seems > that you looked at ipfw source code (.h in fact) to find out the tag > number. Can you explain this? Yes, netgraph always was a semi-programmer system, less or more, especially true with ng_tag, as it tries to be generalized mbuf_tags(9) manipulating interface, and this is more kernel internals. For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. > A practical example, how could I, for example, block Kazaa or > bittorrent based on L7 with ng_tag? Can you please explain the steps > on how to do this? The truth is that, in fact, ng_tag doesn't do any traffic analysis. It merely provides an easy way to distinguish different packets after returning to ipfw. Currently the only analyzing node in FreeBSD src tree is ng_bpf(4), but it merely splits incoming packets in two streams, matched and not. There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. So, that's merely a framework allowing you to create custom filters, and if you need to match some kind of traffic, you should sit, understand what patterns that traffic has and then program ng_bpf(4) with appropriate filter. In fact, it allows to create it from tcpdump(1) expressions, so you don't need to be a C programmer, and that's good, isn't it? :) > I don't run -CURRENT but I need this kind of feature very much, I am > downloading a 7.0 snapshot just to test this with ipfw tag. You'll be able to do this with RELENG_6 about two weeks later. I simply couldn't wait a month for MFC and wrote it earlier :) > How this addresses the problem on system level L7 filtering? I always > though that someone would show up with a userland application that > tags packets and returns the tag to ipfw filtering, but you came up > with a kernel approach. How better and why it is when compared to evil > regexp evaluation on kernel or how efficient is this when compared to > Linux L7 which is know to fail a lot (let a number of packets pass)? Yes, in general case you do - correct way is to have a userland application which will do analysis, this easier, simpler and safer (imagine a security flaw inside kernel matcher?). Like snort. But the main disadvantage - it is SLOW. And for many kinds of traffic you do not need to perform complete flow analysis, as that is simple enough to do per-packet matching, then to say "Huh.. I found such packet, so entire connection must be of that type". Actually, I've found Linux iptables P2P matching module named ipp2p at http://www.ipp2p.org/ which was told to work reasonable well, looked at the code and found that one-packet match is enough for this work. So, per-packet matching can be implemented in kernel. After that I've discovered that FreeBSD already have in-kernel packet matcher for a long time, since 4.0. Briefly inspecting ipp2p code shown that most recognized P2P types can be matched by tcpdump and thus are programmable on ng_bpf(4). For some patterns, still, that's not enough, as bpf can't search for a substring on a variable, not fixed, offset. Then we can imagine another netgraph node which will do substring search (like iptables --string), so with both bpf and string-matching all P2P traffic can be caught. Anyway, that work yet to be done. The main benefit of ng_tag at the moment is that everybody wishing this have no longer principial barriers to do, like needing skills to write kernel module or even userland matching daemon. > Sorry for all those questions, but I am an end user in the average, > so, I can not understand it myself only reading the code. > > Thank you for your work and help. It seems that I will have a 7.0 > snapshot doing this job to me untill the ipfw tag MFC happens, if I > can understand this approach. I hope that my explanation was helpful enough to understand :) Also, if you will be using 7.0, include BPF_JITTER in your kernel config as this will enable native code-compiling for bpf and ng_bpf - this will speed things up. ========================================================================== P.S. Here is quick-and-dirty primer how to convert ipp2p functions to ng_bpf(4) input expression for tcpdump(1). Go to http://www.ipp2p.org/ and download source, unpack and open file pt_ipp2p.c and find function for your P2P type, let it be BitTorrent for our example. So look (I've formatted that bad Linux code a little to be a more style(9)'ish): int search_bittorrent (const unsigned char *payload, const u16 plen) { if (plen > 20) { /* test for match 0x13+"BitTorrent protocol" */ if (payload[0] == 0x13) if (memcmp(payload+1, "BitTorrent protocol", 19) == 0) return (IPP2P_BIT * 100); /* get tracker commandos, all starts with GET / * then it can follow: scrape| announce * and then ?hash_info= */ if (memcmp(payload,"GET /",5) == 0) { /* message scrape */ if (memcmp(payload+5, "scrape?info_hash=", 17)==0) return (IPP2P_BIT * 100 + 1); /* message announce */ if (memcmp(payload+5, "announce?info_hash=", 19)==0) return (IPP2P_BIT * 100 + 2); } } else { /* * bitcomet encryptes the first packet, so we have to detect another * one later in the flow */ /* first try failed, too many missdetections */ //if (size == 5 && get_u32(t,0) == __constant_htonl(1) && t[4] < 3) // return (IPP2P_BIT * 100 + 3); /* second try: block request packets */ if ((plen == 17) && (get_u32(payload,0) == __constant_htonl(0x0d)) && (payload[4] == 0x06) && (get_u32(payload,13) == __constant_htonl(0x4000))) return (IPP2P_BIT * 100 + 3); } return 0; } So, what do we see? BitTorrent packet can start with one of three fixed strings (we see memcmp() checks for them). Author of ipp2p employs one more check, but as we can see from comments, he's not sure. Let's find out what are the byte sequences for these strings: $ echo -n "BitTorrent protocol" | hd 00000000 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 6f |BitTorrent proto| 00000010 63 6f 6c |col| 00000013 $ echo -n "GET /scrape?info_hash=" | hd 00000000 47 45 54 20 2f 73 63 72 61 70 65 3f 69 6e 66 6f |GET /scrape?info| 00000010 5f 68 61 73 68 3d |_hash=| 00000016 $ echo -n "GET /announce?info_hash=" | hd 00000000 47 45 54 20 2f 61 6e 6e 6f 75 6e 63 65 3f 69 6e |GET /announce?in| 00000010 66 6f 5f 68 61 73 68 3d |fo_hash=| 00000018 We can give 1, 2 or 4 bytes to tcpdump for comarison at one time. The "payload" variable in the source points to beginning of data in TCP packet. Remember from man ng_tag that tcpdump assumes packets to have 14-byte Ethernet header for it's arrays like "tcp[]", but packets come from ipfw to ng_bpf without this header, and that affects our offset calculations. So we must give offsets from very beginning of packets, which is done through "ether[]" tcpdump's prime, and parse headers manually. Let's assume (for simplicity and speed), however, that IP and TCP headers have no any options and thus always have length 20 bytes each, then ipp2p's "payload[0]" will be tcpdump's "ether[40]". Also, let's assume that ipfw checked packet len for us so we don't do that in netgraph too. Then, we simply take hex bytes in order hd(1) told us, as this is network byte order also, and write them as tcpdump expressions (remember that first string ("...protocol") actually have 0x13 prepended to it). So, we write follow in ng_bpf(4) script: PATTERN="(ether[40:4]=0x13426974 && ether[44:4]=0x546f7272 && ether[48:4]=0x656e7420 && ether[52:4]=0x70726f74 && ether[56:4]=0x6f636f6c ) || (ether[40:4]=0x47455420 && (ether[44:4]=0x2f736372 && ether[48:4]=0x6170653f && ether[52:4]=0x696e666f && ether[56:4]=0x5f686173 && ether[60:2]=0x683d ) || (ether[44:4]=0x2f616e6e && ether[48:4]=0x6f756e63 && ether[52:4]=0x653f696e && ether[56:4]=0x666f5f68 && ether[60:4]=0x6173683d) ) || (ether[2:2]=57 && ether[40:4]=0x0000000d && ether[44]=0x06 && ether[53:4]=0x00004000)" Note the last OR block in expression - this is translation of that "not sure" checking request packets. I've explicitly written packet length - plen=17 + 20 byte IP header len + 20 byte TCP header len, check at offset 2 in IP header, according to RFC 791. Construction "get_u32 == __constant_htonl()" means comparing 4-byte values at given offset. P.P.S. I have not tested that pattern on real packets, as I have no BitTorrent today, but it should work. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 19:51:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A549716A418 for ; Mon, 12 Jun 2006 19:51:40 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0218D43D53 for ; Mon, 12 Jun 2006 19:51:38 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so952507nfe for ; Mon, 12 Jun 2006 12:51:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=abYFkMZRV9KxlRRQ7OamDDCPH0T3Sy93K/zI3z0ml0VNFLJKA+YJNb3oGJqB9OPwi/ntGGyDRG+NiMtSB72tw9pZlJY1UzNPhSFMl9aP6pwUyM1830sMqJjTKAdEeKGTbnxJONsj/qBrSuJ0f9mTTGFt8eGpo+AjqnRayZoMkQs= Received: by 10.49.93.18 with SMTP id v18mr5170269nfl; Mon, 12 Jun 2006 12:51:37 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.194]) by mx.gmail.com with ESMTP id p72sm6813446nfc.2006.06.12.12.51.34; Mon, 12 Jun 2006 12:51:37 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k5CJpXPf002834; Mon, 12 Jun 2006 21:51:35 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k5CIvpR6002033; Mon, 12 Jun 2006 20:57:51 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Mon, 12 Jun 2006 20:57:51 +0200 From: Ulrich Spoerlein To: Vadim Goncharov Message-ID: <20060612185751.GB1226@roadrunner.aventurien.local> Mail-Followup-To: Vadim Goncharov , freebsd-current@freebsd.org, freebsd-isp@freebsd.org, freebsd-net@freebsd.org References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 19:51:40 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Vadim Goncharov wrote: > I hope that my explanation was helpful enough to understand :) Also, if y= ou will be using=20 > 7.0, include BPF_JITTER in your kernel config as this will enable native = code-compiling for=20 > bpf and ng_bpf - this will speed things up. Am I the only one, that thinks BPF_JITTER is a stupid name? It suggest you add or enable jitter for the packet flow. No one wants jitter! It sucks. Why isn't it called simply BPF_JIT? Everyone knows what JIT stands for, JITTER on the other hand is to be avoided. > P.S. Here is quick-and-dirty primer how to convert ipp2p functions to ng_= bpf(4) input=20 > expression for tcpdump(1). Go to http://www.ipp2p.org/ and download sourc= e, unpack and open=20 > file pt_ipp2p.c and find function for your P2P type, let it be BitTorrent= for our example. So=20 > look (I've formatted that bad Linux code a little to be a more style(9)'i= sh): > [snip] > We can give 1, 2 or 4 bytes to tcpdump for comarison at one time. The "pa= yload" variable in=20 > the source points to beginning of data in TCP packet. Remember from man n= g_tag that tcpdump=20 > assumes packets to have 14-byte Ethernet header for it's arrays like "tcp= []", but packets=20 > come from ipfw to ng_bpf without this header, and that affects our offset= calculations. So we=20 > must give offsets from very beginning of packets, which is done through "= ether[]" tcpdump's=20 > prime, and parse headers manually. Let's assume (for simplicity and speed= ), however, that IP=20 > and TCP headers have no any options and thus always have length 20 bytes = each, then ipp2p's=20 > "payload[0]" will be tcpdump's "ether[40]". Also, let's assume that ipfw = checked packet len=20 > for us so we don't do that in netgraph too. >=20 > Then, we simply take hex bytes in order hd(1) told us, as this is network= byte order also,=20 > and write them as tcpdump expressions (remember that first string ("...pr= otocol") actually=20 > have 0x13 prepended to it). So, we write follow in ng_bpf(4) script: > [snip] > Note the last OR block in expression - this is translation of that "not s= ure" checking=20 > request packets. I've explicitly written packet length - plen=3D17 + 20 b= yte IP header len + 20=20 > byte TCP header len, check at offset 2 in IP header, according to RFC 791= =2E Construction=20 > "get_u32 =3D=3D __constant_htonl()" means comparing 4-byte values at give= n offset. Great stuff, this should make it somewhere into /usr/share/examples! Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEjbkv524iJyD+6d0RAsCmAJ9TnrhmRItXr/duWMSv2sIkdq6NVgCgmA9S EWI/jDS2ECluq4ww7LT7k6I= =YXjO -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 20:21:10 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA52D16A418; Mon, 12 Jun 2006 20:21:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC92743D45; Mon, 12 Jun 2006 20:21:08 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k5CKL3Wm061811; Mon, 12 Jun 2006 16:21:03 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Mon, 12 Jun 2006 16:20:42 -0400 User-Agent: KMail/1.6.2 References: <20060612185751.GB1226@roadrunner.aventurien.local> In-Reply-To: <20060612185751.GB1226@roadrunner.aventurien.local> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606121620.44136.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1534/Mon Jun 12 08:30:53 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Vadim Goncharov , freebsd-isp@FreeBSD.org, freebsd-current@FreeBSD.org, Ulrich Spoerlein Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 20:21:10 -0000 On Monday 12 June 2006 02:57 pm, Ulrich Spoerlein wrote: > Vadim Goncharov wrote: > > I hope that my explanation was helpful enough to understand :) > > Also, if you will be using 7.0, include BPF_JITTER in your kernel > > config as this will enable native code-compiling for bpf and > > ng_bpf - this will speed things up. > > Am I the only one, that thinks BPF_JITTER is a stupid name? It > suggest you add or enable jitter for the packet flow. No one wants > jitter! It sucks. Why isn't it called simply BPF_JIT? Everyone > knows what JIT stands for, JITTER on the other hand is to be > avoided. I am the guilty one and I hate the name myself. :-) This feature was imported from WinPcap: http://www.winpcap.org/docs/docs31/html/group__NPF__code.html#ga33 I didn't want another name for the same thing. Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 20:30:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B19EA16A41A; Mon, 12 Jun 2006 20:30:39 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD68E43D58; Mon, 12 Jun 2006 20:30:37 +0000 (GMT) (envelope-from vadim_nuclight@mail.ru) Received: from [82.211.136.13] (port=50714 helo=nuclight.avtf.net) by mx27.mail.ru with esmtp id 1Fpt3T-0009DE-00; Tue, 13 Jun 2006 00:30:35 +0400 Date: Tue, 13 Jun 2006 03:30:12 +0700 From: "Vadim Goncharov" To: "Ulrich Spoerlein" References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> <20060612185751.GB1226@roadrunner.aventurien.local> Organization: AVTF TPU Hostel Message-ID: In-Reply-To: <20060612185751.GB1226@roadrunner.aventurien.local> User-Agent: Opera M2/7.54 (Win32, build 3865) Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 20:30:39 -0000 13.06.06 @ 01:57 Ulrich Spoerlein wrote: > Vadim Goncharov wrote: >> I hope that my explanation was helpful enough to understand :) Also, if >> you will be using >> 7.0, include BPF_JITTER in your kernel config as this will enable >> native code-compiling for >> bpf and ng_bpf - this will speed things up. > > Am I the only one, that thinks BPF_JITTER is a stupid name? It suggest > you add or enable jitter for the packet flow. No one wants jitter! It > sucks. Why isn't it called simply BPF_JIT? Everyone knows what JIT > stands for, JITTER on the other hand is to be avoided. I also think so, but that is not in my competence. But I, after two days of discussion, I must say another thing: WHERE ARE TESTERS ?! You all are wanting this node to be included into FreeBSD src tree, so that it will be available in standard distribution. But before this code should be tested and bugs fixed, if any. And I don't yet see any success stories / bug reports ! >> P.S. Here is quick-and-dirty primer how to convert ipp2p functions to >> ng_bpf(4) input expression for tcpdump(1). [...] >> "get_u32 == __constant_htonl()" means comparing 4-byte values at given >> offset. > > Great stuff, this should make it somewhere into /usr/share/examples! Good idea, but still to be worked for more P2P types examples, and BPF assembly language explanation, as I suspect some things can't be done but tcpdump expressions, though still possible on ng_bpf. Unfortunatelly I do not have much time for this. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Mon Jun 12 21:45:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E95F16A46F; Mon, 12 Jun 2006 21:45:48 +0000 (UTC) (envelope-from melifaro@su29.net) Received: from fxng.vds.in (fxng.vds.in [217.199.221.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A005343D45; Mon, 12 Jun 2006 21:45:47 +0000 (GMT) (envelope-from melifaro@su29.net) Received: from [10.0.0.5] (ppp83-237-7-77.pppoe.mtu-net.ru [83.237.7.77]) by fxng.vds.in (Postfix) with ESMTP id 06A185C36; Tue, 13 Jun 2006 01:46:29 +0400 (MSD) Message-ID: <448DE088.8070700@su29.net> Date: Tue, 13 Jun 2006 01:45:44 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 1.5 (X11/20060330) MIME-Version: 1.0 To: Vadim Goncharov References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 21:45:48 -0000 Hi, I have recent 7.0-current and this node seems to work for me. Node code compiles and loads into kernel without any problems. After some time experimenting with ng_bpf(4) i was able to tag packets matched by bpf filter. Of course, the following is not a real-world example, but it confirms module is working. Great job! [root@ws /home/melifaro/ng]# make @ -> /usr/src/sys machine -> /usr/src/sys/i386/include touch opt_netgraph.h cc -O2 -fno-strict-aliasing -pipe -g -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/home/melifaro/ng -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c ng_tag.c ld -d -warn-common -r -d -o ng_tag.kld ng_tag.o touch export_syms awk -f /sys/conf/kmod_syms.awk ng_tag.kld export_syms | xargs -J% objcopy % ng_tag.kld ld -Bshareable -d -warn-common -o ng_tag.ko ng_tag.kld objcopy --strip-debug ng_tag.ko [root@ws /home/melifaro/ng]# make load /sbin/kldload -v /usr/home/melifaro/ng/ng_tag.ko Loaded /usr/home/melifaro/ng/ng_tag.ko, id=14 [root@ws /usr/home/melifaro/ng]# sysctl -w net.inet.ip.fw.one_pass=0 net.inet.ip.fw.one_pass: 1 -> 0 [root@ws /home/melifaro/ng]# ngctl mkpeer ipfw: bpf 41 ipfw [root@ws /home/melifaro/ng]# ngctl name ipfw:41 dcbpf [root@ws /home/melifaro/ng]# ngctl mkpeer dcbpf: tag matched th1 [root@ws /home/melifaro/ng]# ngctl name dcbpf:matched ngdc root@ws /usr/home/melifaro/ng]# [root@ws /home/melifaro/ng]# ngctl msg ngdc: sethookin { thisHook=\"th1\" ifNotMatch=\"th1\" } [root@ws /home/melifaro/ng]# ngctl msg ngdc: sethookout { thisHook=\"th1\" tag_cookie=1148380143 tag_id=412 } root@ws /usr/home/melifaro/ng]# [root@ws /home/melifaro/ng]# ngctl msg dcbpf: setprogram '{ thisHook="matched" ifMatch="ipfw" bpf_prog_len=1 bpf_prog=[ { code=6 k=8192 } ] }' root@ws /usr/home/melifaro/ng]# ; Matching part now, generated by script from ng_bpf(4) man page ; We are trying to tag all packets with dst port = 8888 ; link layer is cut, so offset is 20 + 2 [root@ws /usr/home/melifaro/ng]# head -n 5 bpf.script PATTERN="ether[22:2]=8888" NODEPATH="dcbpf:" INHOOK="ipfw" MATCHHOOK="matched" NOTMATCHHOOK="ipfw" root@ws /usr/home/melifaro/ng]# ./bpf.script root@ws /usr/home/melifaro/ng]# [root@ws /usr/home/melifaro/ng]# ipfw add 100 netgraph 41 tcp from me to 1.2.3.4 8888 00100 netgraph 41 tcp from me to 1.2.3.4 dst-port 8888 [root@ws /usr/home/melifaro/ng]# ipfw add 110 reset tcp from any to any tagged 412 00110 reset tcp from any to any tagged 412 [root@ws /usr/home/melifaro/ng]# [root@ws /usr/home/melifaro/ng]# telnet 1.2.3.4 8888 Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection refused telnet: Unable to connect to remote host [root@ws /usr/home/melifaro/ng]# ipfw show 100-110 00100 1 64 netgraph 41 tcp from me to 1.2.3.4 dst-port 8888 00110 1 64 reset tcp from any to any tagged 412 Vadim Goncharov wrote: > Hello All! > > I wrote new netgraph(4) node, called ng_tag, able to match packets by > their mbuf_tags(9) and assign new tags to mbufs. This can be used for > many things in the kernel network subsystem, but particularly useful > with recently added ipfw(8) tag/tagged functionality (will be MFCed to > RELENG_6 after Jun 24). > > With this node, in conjunction with ng_bpf(4), I was able to match and > block (perhaps shaping is also possible, but this relies solely on ipfw) > DirectConnect P2P data connections traffic - you know, they're using > random ports, so you can't match them with usual firewall rules and must > check data payload contents of the packets. See man page for example of > how to do this. > > Download files from here: http://antigreen.org/vadim/freebsd/ng_tag/ > Then do: > > make > kldload ./ng_tag.ko > > Man page can be viewed as: > > cat ng_tag.4 | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man \ > -Tascii | /usr/bin/col | more -s > > Please especially test tags with non-zero tag_len, if you can (though it's > not needed for ipfw). > > P.S. BTW, what is correct subject prefix for new contributions? I think > [PATCH] is not correct as these are new files, not patch :) > > --WBR, Vadim Goncharov > _______________________________________________ > 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 Jun 12 22:51:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2046C16A41A; Mon, 12 Jun 2006 22:51:51 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7022D43D4C; Mon, 12 Jun 2006 22:51:41 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 087BA10D3AF; Tue, 13 Jun 2006 05:51:39 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 128E010D3AC; Tue, 13 Jun 2006 05:51:38 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 03:32:00 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 03:32:00 +0700 Date: Tue, 13 Jun 2006 03:29:12 +0700 From: "Vadim Goncharov" To: "Ulrich Spoerlein" References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> <20060612185751.GB1226@roadrunner.aventurien.local> Organization: AVTF TPU Hostel Message-ID: In-Reply-To: <20060612185751.GB1226@roadrunner.aventurien.local> User-Agent: Opera M2/7.54 (Win32, build 3865) Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jun 2006 20:32:00.0430 (UTC) FILETIME=[41D73CE0:01C68E5F] Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) 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, 12 Jun 2006 22:51:51 -0000 13.06.06 @ 01:57 Ulrich Spoerlein wrote: > Vadim Goncharov wrote: >> I hope that my explanation was helpful enough to understand :) Also, if >> you will be using >> 7.0, include BPF_JITTER in your kernel config as this will enable >> native code-compiling for >> bpf and ng_bpf - this will speed things up. > > Am I the only one, that thinks BPF_JITTER is a stupid name? It suggest > you add or enable jitter for the packet flow. No one wants jitter! It > sucks. Why isn't it called simply BPF_JIT? Everyone knows what JIT > stands for, JITTER on the other hand is to be avoided. I also think so, but that is not in my competence. But I, after two days of discussion, I must say another thing: WHERE ARE TESTERS ?! You all are wanting this node to be included into FreeBSD src tree, so that it will be available in standard distribution. But before this code should be tested and bugs fixed, if any. And I don't yet see any success stories / bug reports ! >> P.S. Here is quick-and-dirty primer how to convert ipp2p functions to >> ng_bpf(4) input expression for tcpdump(1). [...] >> "get_u32 == __constant_htonl()" means comparing 4-byte values at given >> offset. > > Great stuff, this should make it somewhere into /usr/share/examples! Good idea, but still to be worked for more P2P types examples, and BPF assembly language explanation, as I suspect some things can't be done but tcpdump expressions, though still possible on ng_bpf. Unfortunatelly I do not have much time for this. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Tue Jun 13 02:22:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B44F216A418 for ; Tue, 13 Jun 2006 02:22:15 +0000 (UTC) (envelope-from bsdlogical@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D1AC43D45 for ; Tue, 13 Jun 2006 02:22:15 +0000 (GMT) (envelope-from bsdlogical@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so997418wxd for ; Mon, 12 Jun 2006 19:22:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:user-agent:x-accept-language:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding:from; b=PJLLDEInQ3CkDm/ZocSQMkBmVoz21JgrUK0gXhkpelqi5yoEOOkI34h3X7d5D3bsoLRQ0maqHsEGuGjtQQNeLE6wzFogoMQIg5QNVIUO+FvrzYvb3wHYzKhQpQxbk2tE8UGtkcvaTBcVYt7VXUtdODXwR04iJ3260I4ySMD+2wM= Received: by 10.70.116.11 with SMTP id o11mr4586635wxc; Mon, 12 Jun 2006 19:22:14 -0700 (PDT) Received: from ?192.168.1.15? ( [68.18.109.121]) by mx.gmail.com with ESMTP id i39sm5994345wxd.2006.06.12.19.22.13; Mon, 12 Jun 2006 19:22:13 -0700 (PDT) Message-ID: <448E2157.7020302@bellsouth.net> Date: Mon, 12 Jun 2006 22:22:15 -0400 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Nick Fishman Subject: FreeBSD VPN client to a Windows network using MPD 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, 13 Jun 2006 02:22:15 -0000 I recently tried to set up a VPN connection from home to the office (running Windows Server 2003). I used the mpd port (net/mpd, the 3.x branch), but found configuration much more difficult than it should be. Configuration options seemed to lead to dead ends, but I finally found a working version. I post it here in an effort to dispel confusion and assist others having the same problem. I urge others to correct me and clarify things in my explanation, as I've probably neglected to mention parts. Much configuration and assistance came from a post on this list by Peter Cornelius on 2003/10/09. For this installation, MPD requires three files: mpd.conf, mpd.links, and mpd.secret. They're stored in /usr/local/etc/mpd. Here's my mpd.links (note that 1.2.3.4 is the address of your VPN gateway): vpn: set link type pptp set pptp peer 1.2.3.4 set pptp enable originate outcall Here's my mpd.secret (in my case, I used my Windows (Active Directory) username without specifying the domain. Your installation may be different; try using "DOMAIN\\username". Note that the quotes are necessary, and two slashes are needed instead of one): "username" "password" Here's my mpd.conf: default: load vpn vpn: new -i ng0 vpn vpn # the session value does matter, but I'm not sure why set iface session 28800 # "username" here should match "username" in mpd.secret set bundle authname "username" set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 # set this to your correct routing information set iface route 192.168.0.0/24 open This is more compact than existing examples on the web, but some options are key to a working connection. The following lines caused my connection to fail (don't use them!): set ccp yes mpp-compress set bundle enable encryption Compression is absolutely necessary, but MPPE didn't work in my case. This may differ for you. Encryption is necessary, but don't use "set bundle enable encryption". The Windows RDP server switches to MPPE, which provides encryption. The following lines didn't visibly affect my connection. After leaving them out, my connection still worked. Some of these probably matter; it would help to get some clarification here: set link yes acfcomp protocomp set ipcp yes vjcomp set iface disable on-demand set iface idle 0 set link keep-alive 61 753 set link mtu 1460 set ccp yes mpp-stateless set link no pap set link accept chap set link enable no-orig-auth Note that the last line is necessary for NT servers, as recommended by Peter. The "no pap" and "accept chap" lines appear in various incarnations in online examples, but aren't necessary for the connection to succeed. It appears as if MPD switches to MPPE automatically during negotiation. I apologize for the long email. I hope this helps others trying to use FreeBSD as a client for a Windows VPN. Please correct me if I'm wrong on anything. Nick bsdlogical From owner-freebsd-net@FreeBSD.ORG Tue Jun 13 07:16:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9CE216A418 for ; Tue, 13 Jun 2006 07:16:06 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E050E43D48 for ; Tue, 13 Jun 2006 07:16:03 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Tue, 13 Jun 2006 15:24:11 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 15:15:59 +0800 Received: from [172.23.17.39] ([172.23.17.39]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 15:15:59 +0800 Message-ID: <448E6635.4010800@zyxel.com.tw> Date: Tue, 13 Jun 2006 15:16:05 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 07:15:59.0311 (UTC) FILETIME=[386895F0:01C68EB9] Subject: [FreeBSD6.1-RELEASE]problem about soisconnected() in uipc_socket2.c 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, 13 Jun 2006 07:16:06 -0000 Hi,all: I have found a questionable code in soisconnected() function in uipc_socket2.c. In the very beginning, the SOCK_LOCK() would lock the socket. However, in line 127, it unlocks socket. I am wondering that SOCK_UNLOCK() should be called until all the socket's parameters are done. In my opinion, it should be located right before ACCEPT_UNLOCK(). Best regards, blue From owner-freebsd-net@FreeBSD.ORG Tue Jun 13 11:52:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF9C616A41B for ; Tue, 13 Jun 2006 11:52:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B8B343D64 for ; Tue, 13 Jun 2006 11:52:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1A39E46C34; Tue, 13 Jun 2006 07:52:51 -0400 (EDT) Date: Tue, 13 Jun 2006 12:52:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Blue In-Reply-To: <448E6635.4010800@zyxel.com.tw> Message-ID: <20060613124552.V74063@fledge.watson.org> References: <448E6635.4010800@zyxel.com.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: [FreeBSD6.1-RELEASE]problem about soisconnected() in uipc_socket2.c 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, 13 Jun 2006 11:52:52 -0000 On Tue, 13 Jun 2006, Blue wrote: > I have found a questionable code in soisconnected() function in > uipc_socket2.c. In the very beginning, the SOCK_LOCK() would lock the > socket. However, in line 127, it unlocks socket. I am wondering that > SOCK_UNLOCK() should be called until all the socket's parameters are done. > In my opinion, it should be located right before ACCEPT_UNLOCK(). Some fields of the socket are protected by accept_mtx rather than the socket lock. You can check the field locking key in socketvar.h for details: /*- * Locking key to struct socket: * (a) constant after allocation, no locking required. * (b) locked by SOCK_LOCK(so). * (c) locked by SOCKBUF_LOCK(&so->so_rcv). * (d) locked by SOCKBUF_LOCK(&so->so_snd). * (e) locked by ACCEPT_LOCK(). * (f) not locked since integer reads/writes are atomic. * (g) used only as a sleep/wakeup address, no value. * (h) locked by global mutex so_global_mtx. */ ... int so_qstate; /* (e) internal state flags SQ_* */ TAILQ_HEAD(, socket) so_incomp; /* (e) queue of partial unaccepted connections */ TAILQ_HEAD(, socket) so_comp; /* (e) queue of complete unaccepted connections */ TAILQ_ENTRY(socket) so_list; /* (e) list of unaccepted connections */ u_short so_qlen; /* (e) number of unaccepted connections */ u_short so_incqlen; /* (e) number of unaccepted incomplete connections */ u_short so_qlimit; /* (e) max number queued connections */ The socket lock is dropped at the earliest point in each case after which no further manipulation of the socket lock protected fields take place. The only really dubious thing about what's there right now is the handling of socket upcalls, which has poorly defined locking properties, but I think in the non-accept filter case, the locking looks generally correct. Right now we call so_upcall in different places with different locks, and some upcalls perform activities that may require acquiring further locks, possibly in bad orders. We rely to some extent on the behavior of the protocol to keep certain races from happening, and that reliance is not well documented. I have several works in progress related to socket locking which improve this to some extent. One breaks out the single upcall function pointer into a series of upcalls each with well defined behavior; another coalesces the various socket locks, also resulting in well defined behavior. Robert N M Watson Computer Laboratory Universty of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Jun 13 16:48:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F26BB16A476 for ; Tue, 13 Jun 2006 16:48:27 +0000 (UTC) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207E043D79 for ; Tue, 13 Jun 2006 16:48:15 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (localhost [127.0.0.1]) by quark.cs.earlham.edu (8.13.6/8.13.3) with ESMTP id k5DGmEnF044162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jun 2006 12:48:14 -0400 (EDT) (envelope-from skylar@cs.earlham.edu) Received: (from skylar@localhost) by quark.cs.earlham.edu (8.13.6/8.13.3/Submit) id k5DGmEfE044161 for freebsd-net@freebsd.org; Tue, 13 Jun 2006 12:48:14 -0400 (EDT) (envelope-from skylar@cs.earlham.edu) X-Authentication-Warning: quark.cs.earlham.edu: skylar set sender to skylar@quark.cs.earlham.edu using -f Date: Tue, 13 Jun 2006 12:48:14 -0400 From: Skylar Thompson To: freebsd-net@freebsd.org Message-ID: <20060613164814.GA43973@quark.cs.earlham.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es SMTP-Mailing-Host: quark.cs.earlham.edu X-Operating-System: FreeBSD 5.4-RELEASE-p1 X-Uptime: 12:43PM up 29 days, 19:41, 20 users, load averages: 0.17, 0.12, 0.13 X-Editor: VIM - Vi IMproved 6.3 (2004 June 7, compiled May 14 2005 15:15:17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [127.0.0.1]); Tue, 13 Jun 2006 12:48:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.2/1464/Tue May 16 05:36:19 2006 on quark.cs.earlham.edu X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.56 on 192.168.0.3 X-Spam-Status: No, score=-4.4 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on quark.cs.earlham.edu Subject: bge(4) and gigabit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Skylar Thompson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 16:48:28 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've got a Poweredge 1750 6-STABLE, and I'm having problems getting its onb= oard Ethernet interfaces negotiated to gigabit speeds. It has dual Broadcom BCM5704C copper interfaces, which are supported by the bge(4) driver. I've tried this againt a managed gigabit switch: I plugged in both interfaces, and start out at 10baseT. Increasing to 100 works fine, but going to 1000baseT causes the link to drop. I've tried using ifconfig to force media settings, and these also only work up to 100baseT. I've also tried the cabling and switch with other gigabit gear, and these negotiate fine. I also had this machine running Linux at one point, and it negotiated to gigabit then, so the interfaces themselves shouldn't be the problem. Any ideas? --=20 -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFEjuxOsc4yyULgN4YRAkJgAJ9xVg3atU6/0Dz850u2bfsMyZbV0QCgmgs8 MJWYjWPlXJEqpD6o06wY9mY= =hB4K -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 14 01:00:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08E4B16A41A for ; Wed, 14 Jun 2006 01:00:04 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBEC43D48 for ; Wed, 14 Jun 2006 01:00:02 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Wed, 14 Jun 2006 09:08:11 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 08:59:55 +0800 Received: from [172.23.17.39] ([172.23.17.39]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 08:59:55 +0800 Message-ID: <448F5F92.1090502@zyxel.com.tw> Date: Wed, 14 Jun 2006 09:00:02 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 00:59:55.0268 (UTC) FILETIME=[D99A9C40:01C68F4D] Subject: T/TCP in FreeBSD6.1-RELEASE 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, 14 Jun 2006 01:00:05 -0000 Hi, All: Why has FreeBSD6.1-RELEASE removed T/TCP extensions? The TCP options of "connection count" suggested in RFC 1379 no longer exists in the version. However, I could still see some "T/TCP logic" in functions such as tcp_input() or tcp_output(). Shouldn't these logic be removed, either? Best regards, blue From owner-freebsd-net@FreeBSD.ORG Wed Jun 14 02:51:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06B3816A41A for ; Wed, 14 Jun 2006 02:51:58 +0000 (UTC) (envelope-from beastie@mra.co.id) Received: from mx3.mra.co.id (fw.mra.co.id [202.51.31.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7194843D45; Wed, 14 Jun 2006 02:51:56 +0000 (GMT) (envelope-from beastie@mra.co.id) Received: from localhost (localhost.mra.co.id [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id F363730F99; Wed, 14 Jun 2006 09:54:24 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58743-14; Wed, 14 Jun 2006 09:54:24 +0700 (WIT) Received: from mail.mra.co.id (unknown [172.16.0.224]) by mx3.mra.co.id (Postfix) with ESMTP id BFFAF30F91; Wed, 14 Jun 2006 09:54:24 +0700 (WIT) Received: from [172.16.0.228] (unknown [172.16.0.228]) by mail.mra.co.id (Postfix) with ESMTP id 037F165F3EA5; Wed, 14 Jun 2006 09:54:20 +0700 (WIT) Message-ID: <448F7E55.5030407@mra.co.id> Date: Wed, 14 Jun 2006 10:11:17 +0700 From: User Beastie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060515 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-question@freebsd.org, misc@openbsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mra.co.id Cc: Subject: IP Routing Question. 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, 14 Jun 2006 02:51:58 -0000 Dear All. I have one simple question. If my ISP assign one point to point ip address and one full subnet mask address (/28), can i have those in one my ethernet interface ? If it's possible, is there any network routing problem ? FYI , i have one private network and DMZ . regards Beastie From owner-freebsd-net@FreeBSD.ORG Wed Jun 14 04:25:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0299216A474 for ; Wed, 14 Jun 2006 04:25:34 +0000 (UTC) (envelope-from sparctacus@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DAE543D4C for ; Wed, 14 Jun 2006 04:25:32 +0000 (GMT) (envelope-from sparctacus@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so122762uge for ; Tue, 13 Jun 2006 21:25:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ALd3whU5GuQQpfeALmxNFZINSs+2894m+sgtB1Zk+FYa1ZT012MK4agP8ZoHRc2+XqzhJQhybRhXidKJRN0gN49EFKYxdk55qr/hls+DcGu5H2o04kNICxHcf2dV+pH7NQerUOGx8028GGyicffXIok3q5WnZiSDvxJDk0CYcn8= Received: by 10.66.216.20 with SMTP id o20mr273914ugg; Tue, 13 Jun 2006 21:18:56 -0700 (PDT) Received: by 10.67.97.14 with HTTP; Tue, 13 Jun 2006 21:18:56 -0700 (PDT) Message-ID: <53d706300606132118y658d0d5eq8d6dd7ca7b17780b@mail.gmail.com> Date: Tue, 13 Jun 2006 21:18:56 -0700 From: "Bryan Irvine" To: "User Beastie" In-Reply-To: <448F7E55.5030407@mra.co.id> MIME-Version: 1.0 References: <448F7E55.5030407@mra.co.id> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: misc@openbsd.org, freebsd-net@freebsd.org, freebsd-question@freebsd.org Subject: Re: IP Routing Question. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: root@allyourbasearebelongto.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 04:25:34 -0000 YOu mean you want all 6(?) IP's on the same interface? Ya, it's called aliases. I think you are looking for man(5) hostname.if. --Bryan On 6/13/06, User Beastie wrote: > > Dear All. > > I have one simple question. > If my ISP assign one point to point ip address and one full subnet > mask address (/28), can i have those in one my ethernet interface ? > If it's possible, is there any network routing problem ? > FYI , i have one private network and DMZ . > > > regards > Beastie > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 14 14:30:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E9016A47C; Wed, 14 Jun 2006 14:30:32 +0000 (UTC) (envelope-from admin@su29.net) Received: from fxng.vds.in (fxng.vds.in [217.199.221.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B62043D66; Wed, 14 Jun 2006 14:30:27 +0000 (GMT) (envelope-from admin@su29.net) Received: from localhost (fxng.vds.in [217.199.221.5]) by fxng.vds.in (Postfix) with ESMTP id 551205D2E; Wed, 14 Jun 2006 18:31:20 +0400 (MSD) Date: Wed, 14 Jun 2006 18:31:17 +0400 From: "Alexander V. Chernikov" X-Mailer: The Bat! (v3.71.03) Professional Organization: URSU X-Priority: 3 (Normal) Message-ID: <783346175.20060614183117@su29.net> To: "Vadim Goncharov" In-Reply-To: References: <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re[2]: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:30:32 -0000 Hello Vadim. you wrote 12 =C9=C0=CE=D1 2006 =C7., 16:48:50: Vadim Goncharov> 12.06.06 @ 05:34 Eduardo Meyer wrote: >> I read the messages and man page but did not understand. Maybe it is >> my lack of knowledge regarding netgraph? Well, in man page it seems >> that you looked at ipfw source code (.h in fact) to find out the tag >> number. Can you explain this? Vadim Goncharov> Yes, netgraph always was a semi-programmer system, less or= more, =20 Vadim Goncharov> especially true with ng_tag, as it tries to be Vadim Goncharov> generalized mbuf_tags(9) =20 Vadim Goncharov> manipulating interface, and this is more kernel internals.= For simple Vadim Goncharov> using, however, you don't need to bother all that details = - just remember Vadim Goncharov> magic number and where to place it, and it is now Vadim Goncharov> simple for use with ipfw =20 Vadim Goncharov> tags. >> A practical example, how could I, for example, block Kazaa or >> bittorrent based on L7 with ng_tag? Can you please explain the steps >> on how to do this? Unfortunately i have never analyzed p2p protocols, but for ICQ solution is very simple. Of course, this is not what you asked for, but it is a practical example using ng_tag node At the beginning of icq session server always sends us 10 bytes length packet of data: 2A 01 XX XX 00 04 00 00 00 01 ^ ^ ^ ^ ^ ^ ^ ^ SEQ Length ^ Channel ICQ flap ID so we can easily match and block this packet with iplen =3D 50 in ipfw and by 8 bytes exact match in ng_bpf The following line is for ng_bpf(4) script from manpage PATTERN=3D"ether[40:2] =3D 0x2A01 and ether[44:4] =3D 0x00040000 and ether[48:2] =3D 0x0001" Vadim Goncharov> The truth is that, in fact, ng_tag doesn't do any traffic = analysis. It Vadim Goncharov> merely provides an easy way to distinguish different packe= ts after =20 Vadim Goncharov> returning to ipfw. Currently the only analyzing node in Fr= eeBSD src tree Vadim Goncharov> is ng_bpf(4), but it merely splits incoming packets in two= streams, =20 Vadim Goncharov> matched and not. There are reasons to this, as netgraph ne= eds to be =20 Vadim Goncharov> modular, and each node does a small thing, but does it wel= l. For long time Vadim Goncharov> ng_bpf was used for another purposes in the kernel, and no= w, as new ipfw Vadim Goncharov> features appeared, ng_tag came up for easy integration. Vadim Goncharov> So, that's merely a framework allowing you to create custo= m filters, and Vadim Goncharov> if you need to match some kind of traffic, you Vadim Goncharov> should sit, understand what =20 Vadim Goncharov> patterns that traffic has and then program ng_bpf(4) with = appropriate Vadim Goncharov> filter. In fact, it allows to create it from Vadim Goncharov> tcpdump(1) expressions, so =20 Vadim Goncharov> you don't need to be a C programmer, and that's good, isn'= t it? :) >> I don't run -CURRENT but I need this kind of feature very much, I am >> downloading a 7.0 snapshot just to test this with ipfw tag. Vadim Goncharov> You'll be able to do this with RELENG_6 about two weeks la= ter. I simply Vadim Goncharov> couldn't wait a month for MFC and wrote it earlier :) >> How this addresses the problem on system level L7 filtering? I always >> though that someone would show up with a userland application that >> tags packets and returns the tag to ipfw filtering, but you came up >> with a kernel approach. How better and why it is when compared to evil >> regexp evaluation on kernel or how efficient is this when compared to >> Linux L7 which is know to fail a lot (let a number of packets pass)? Vadim Goncharov> Yes, in general case you do - correct way is to have a use= rland =20 Vadim Goncharov> application which will do analysis, this easier, simpler a= nd safer =20 Vadim Goncharov> (imagine a security flaw inside kernel matcher?). Like sno= rt. But the Vadim Goncharov> main disadvantage - it is SLOW. And for many kinds of traf= fic you do not Vadim Goncharov> need to perform complete flow analysis, as that is simple = enough to do Vadim Goncharov> per-packet matching, then to say "Huh.. I found such packe= t, so entire Vadim Goncharov> connection must be of that type". Actually, I've Vadim Goncharov> found Linux iptables P2P =20 Vadim Goncharov> matching module named ipp2p at http://www.ipp2p.org/ which= was told to Vadim Goncharov> work reasonable well, looked at the code and found that on= e-packet match Vadim Goncharov> is enough for this work. So, per-packet matching can be im= plemented in Vadim Goncharov> kernel. Vadim Goncharov> After that I've discovered that FreeBSD already have in-ke= rnel packet Vadim Goncharov> matcher for a long time, since 4.0. Briefly Vadim Goncharov> inspecting ipp2p code shown =20 Vadim Goncharov> that most recognized P2P types can be matched by tcpdump a= nd thus are Vadim Goncharov> programmable on ng_bpf(4). For some patterns, still, that'= s not enough, as Vadim Goncharov> bpf can't search for a substring on a variable, not fixed,= offset. Then we Vadim Goncharov> can imagine another netgraph node which will do substring = search (like Vadim Goncharov> iptables --string), so with both bpf and Vadim Goncharov> string-matching all P2P traffic =20 Vadim Goncharov> can be caught. Vadim Goncharov> Anyway, that work yet to be done. The main benefit of ng_t= ag at the moment Vadim Goncharov> is that everybody wishing this have no longer Vadim Goncharov> principial barriers to do, =20 Vadim Goncharov> like needing skills to write kernel module or even userlan= d matching =20 Vadim Goncharov> daemon. >> Sorry for all those questions, but I am an end user in the average, >> so, I can not understand it myself only reading the code. >> >> Thank you for your work and help. It seems that I will have a 7.0 >> snapshot doing this job to me untill the ipfw tag MFC happens, if I >> can understand this approach. Vadim Goncharov> I hope that my explanation was helpful enough to understan= d :) Also, if Vadim Goncharov> you will be using 7.0, include BPF_JITTER in your kernel c= onfig as this Vadim Goncharov> will enable native code-compiling for bpf and ng_bpf - thi= s will speed Vadim Goncharov> things up. Vadim Goncharov> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Vadim Goncharov> P.S. Here is quick-and-dirty primer how to convert ipp2p f= unctions to Vadim Goncharov> ng_bpf(4) input expression for tcpdump(1). Go to Vadim Goncharov> http://www.ipp2p.org/ and =20 Vadim Goncharov> download source, unpack and open file pt_ipp2p.c and find = function for Vadim Goncharov> your P2P type, let it be BitTorrent for our example. So lo= ok (I've =20 Vadim Goncharov> formatted that bad Linux code a little to be a more style(= 9)'ish): Vadim Goncharov> int Vadim Goncharov> search_bittorrent (const unsigned char *payload, const u16= plen) Vadim Goncharov> { Vadim Goncharov> if (plen > 20) { Vadim Goncharov> /* test for match 0x13+"BitTorrent protocol" */ Vadim Goncharov> if (payload[0] =3D=3D 0x13) Vadim Goncharov> if (memcmp(payload+1, "BitTorrent protocol= ", 19) =3D=3D 0) Vadim Goncharov> return (IPP2P_BIT * 100); Vadim Goncharov> /* get tracker commandos, all starts with GET / Vadim Goncharov> * then it can follow: scrape| announce Vadim Goncharov> * and then ?hash_info=3D Vadim Goncharov> */ Vadim Goncharov> if (memcmp(payload,"GET /",5) =3D=3D 0) { Vadim Goncharov> /* message scrape */ Vadim Goncharov> if (memcmp(payload+5, "scrape?info_hash=3D= ", 17)=3D=3D0) Vadim Goncharov> return (IPP2P_BIT * 100 + 1); Vadim Goncharov> /* message announce */ Vadim Goncharov> if (memcmp(payload+5, "announce?info_hash= =3D", 19)=3D=3D0) Vadim Goncharov> return (IPP2P_BIT * 100 + 2); Vadim Goncharov> } Vadim Goncharov> } else { Vadim Goncharov> /* Vadim Goncharov> * bitcomet encryptes the first packet, so we have= to detect another Vadim Goncharov> * one later in the flow Vadim Goncharov> */ Vadim Goncharov> /* first try failed, too many missdetections */ Vadim Goncharov> //if (size =3D=3D 5 && get_u32(t,0) =3D=3D Vadim Goncharov> __constant_htonl(1) && t[4] < 3) Vadim Goncharov> // return (IPP2P_BIT * 100 + 3); Vadim Goncharov> =20 Vadim Goncharov> /* second try: block request packets */ Vadim Goncharov> if ((plen =3D=3D 17) && Vadim Goncharov> (get_u32(payload,0) =3D=3D __constant_htonl(0x= 0d)) && Vadim Goncharov> (payload[4] =3D=3D 0x06) && Vadim Goncharov> (get_u32(payload,13) =3D=3D __constant_htonl(0= x4000))) Vadim Goncharov> return (IPP2P_BIT * 100 + 3); Vadim Goncharov> } Vadim Goncharov> return 0; Vadim Goncharov> } Vadim Goncharov> So, what do we see? BitTorrent packet can start with one o= f three fixed Vadim Goncharov> strings (we see memcmp() checks for them). Author of ipp2p= employs one Vadim Goncharov> more check, but as we can see from comments, he's not sure. Vadim Goncharov> Let's find out what are the byte sequences for these strin= gs: Vadim Goncharov> $ echo -n "BitTorrent protocol" | hd Vadim Goncharov> 00000000 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 6f= |BitTorrent Vadim Goncharov> proto| Vadim Goncharov> 00000010 63 6f 6c = |col| Vadim Goncharov> 00000013 Vadim Goncharov> $ echo -n "GET /scrape?info_hash=3D" | hd Vadim Goncharov> 00000000 47 45 54 20 2f 73 63 72 61 70 65 3f 69 6e 66 6f= |GET =20 Vadim Goncharov> /scrape?info| Vadim Goncharov> 00000010 5f 68 61 73 68 3d = |_hash=3D| Vadim Goncharov> 00000016 Vadim Goncharov> $ echo -n "GET /announce?info_hash=3D" | hd Vadim Goncharov> 00000000 47 45 54 20 2f 61 6e 6e 6f 75 6e 63 65 3f 69 6e= |GET =20 Vadim Goncharov> /announce?in| Vadim Goncharov> 00000010 66 6f 5f 68 61 73 68 3d = |fo_hash=3D| Vadim Goncharov> 00000018 Vadim Goncharov> We can give 1, 2 or 4 bytes to tcpdump for comarison at on= e time. The Vadim Goncharov> "payload" variable in the source points to beginning of da= ta in TCP =20 Vadim Goncharov> packet. Remember from man ng_tag that tcpdump assumes pack= ets to have Vadim Goncharov> 14-byte Ethernet header for it's arrays like Vadim Goncharov> "tcp[]", but packets come =20 Vadim Goncharov> from ipfw to ng_bpf without this header, and that affects= our offset Vadim Goncharov> calculations. So we must give offsets from very beginning = of packets, Vadim Goncharov> which is done through "ether[]" tcpdump's prime, and parse= headers =20 Vadim Goncharov> manually. Let's assume (for simplicity and speed), however= , that IP and Vadim Goncharov> TCP headers have no any options and thus always have lengt= h 20 bytes each, Vadim Goncharov> then ipp2p's "payload[0]" will be tcpdump's "ether[40]". A= lso, let's =20 Vadim Goncharov> assume that ipfw checked packet len for us so we Vadim Goncharov> don't do that in netgraph =20 Vadim Goncharov> too. Vadim Goncharov> Then, we simply take hex bytes in order hd(1) told us, as = this is network Vadim Goncharov> byte order also, and write them as tcpdump Vadim Goncharov> expressions (remember that =20 Vadim Goncharov> first string ("...protocol") actually have 0x13 Vadim Goncharov> prepended to it). So, we =20 Vadim Goncharov> write follow in ng_bpf(4) script: Vadim Goncharov> PATTERN=3D"(ether[40:4]=3D0x13426974 && Vadim Goncharov> ether[44:4]=3D0x546f7272 && Vadim Goncharov> ether[48:4]=3D0x656e7420 && Vadim Goncharov> ether[52:4]=3D0x70726f74 && Vadim Goncharov> ether[56:4]=3D0x6f636f6c Vadim Goncharov> ) || Vadim Goncharov> (ether[40:4]=3D0x47455420 && Vadim Goncharov> (ether[44:4]=3D0x2f736372 && Vadim Goncharov> ether[48:4]=3D0x6170653f && Vadim Goncharov> ether[52:4]=3D0x696e666f && Vadim Goncharov> ether[56:4]=3D0x5f686173 && Vadim Goncharov> ether[60:2]=3D0x683d Vadim Goncharov> ) || Vadim Goncharov> (ether[44:4]=3D0x2f616e6e && Vadim Goncharov> ether[48:4]=3D0x6f756e63 && Vadim Goncharov> ether[52:4]=3D0x653f696e && Vadim Goncharov> ether[56:4]=3D0x666f5f68 && Vadim Goncharov> ether[60:4]=3D0x6173683d) Vadim Goncharov> ) || Vadim Goncharov> (ether[2:2]=3D57 && Vadim Goncharov> ether[40:4]=3D0x0000000d && Vadim Goncharov> ether[44]=3D0x06 && Vadim Goncharov> ether[53:4]=3D0x00004000)" Vadim Goncharov> Note the last OR block in expression - this is Vadim Goncharov> translation of that "not =20 Vadim Goncharov> sure" checking request packets. I've explicitly written pa= cket length - Vadim Goncharov> plen=3D17 + 20 byte IP header len + 20 byte TCP header len= , check at offset Vadim Goncharov> 2 in IP header, according to RFC 791. Construction "get_u3= 2 =3D=3D =20 Vadim Goncharov> __constant_htonl()" means comparing 4-byte values at given= offset. Vadim Goncharov> P.P.S. I have not tested that pattern on real packets, as = I have no =20 Vadim Goncharov> BitTorrent today, but it should work. --=20 Cheers, Alexander V. Chernikov mailto:admin@su29.net From owner-freebsd-net@FreeBSD.ORG Wed Jun 14 18:49:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06CDA16A474 for ; Wed, 14 Jun 2006 18:49:26 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A93243D45 for ; Wed, 14 Jun 2006 18:49:25 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.1/8.13.1) with ESMTP id k5EInOPA030383 for ; Wed, 14 Jun 2006 11:49:24 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 14 Jun 2006 11:49:24 -0700 (PDT) From: John Polstra To: freebsd-net@freebsd.org Subject: IF_HANDOFF vs. IFQ_HANDOFF 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, 14 Jun 2006 18:49:26 -0000 Can somebody explain why there is both an IF_HANDOFF macro and an IFQ_HANDOFF macro? Except for a slight difference in parameters, they both seem to do roughly the same thing using completely distinct blocks of code. Is IF_HANDOFF supposed to be used only when the target queue is not the interface's if_snd queue? That seems likely, but a few pieces of code (e.g., ng_fec.c) use IF_HANDOFF to put a packet into the if_snd queue. Thanks, John From owner-freebsd-net@FreeBSD.ORG Thu Jun 15 11:04:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25F9B16A47B for ; Thu, 15 Jun 2006 11:04:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BE9743D62 for ; Thu, 15 Jun 2006 11:04:33 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5916B46C22; Thu, 15 Jun 2006 07:04:33 -0400 (EDT) Date: Thu, 15 Jun 2006 12:04:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Polstra In-Reply-To: Message-ID: <20060615115738.J2512@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF 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: Thu, 15 Jun 2006 11:04:35 -0000 On Wed, 14 Jun 2006, John Polstra wrote: > Can somebody explain why there is both an IF_HANDOFF macro and an > IFQ_HANDOFF macro? Except for a slight difference in parameters, they both > seem to do roughly the same thing using completely distinct blocks of code. > Is IF_HANDOFF supposed to be used only when the target queue is not the > interface's if_snd queue? That seems likely, but a few pieces of code > (e.g., ng_fec.c) use IF_HANDOFF to put a packet into the if_snd queue. In essense, yes. One is used when the default interface queue is used, and the other is used when a specific queue is desired. However, the names are, in fact, backwards from what you expect, for historical reasons. You'll notice, also, that the behavior of an interface queue in the presence of altq is quite different than the non-altq case, also for historical reasons, and that the handoff routines are sometimes without used any ifnet at all (e.g., the netisr handoff). I've looked at cleaning this up a few times, as well as a potential race in the use of the IFF_OACTIVE flag, but have gotten side-tracked in the socket and protocol code for the last 4-6 months. I hope to get back to it later this summer, but if someone else gets there first, that wouldn't be such a problem. :-) On a number of occasions, we've discussed moving towards an if_startmbuf() call, which pushes the selection of queueing logic into the network device driver, which is increasingly desirable when network interfaces support multiple queues, significant queues in hardware, and where we have pseudo-interfaces wrapped around real ones and want to avoid multiple enqueue operations (i.e., if_vlan). A related question is whether or not the generice queueing primitives should provide implicit locking (as they do now), and whether coalescing that locking with existing driver locking makes sense. For example, in the case where oactive isn't currently set, we actually perform six lock operations during mbuf handoff: lock/unlock the queue for enqueue, enter the device driver, lock driver mutex, lock/unlock the queue for dequeue, unlock the device driver lock. In the case where oactive is set (i.e., there's queued output), which is frequently the case under load, this becomes significantly more efficient, because having a separate queue mutex avoids contention on the driver mutex during send if the driver is busy, etc. Evaluating the benefits of the additional granularity there is something that has never been done thoroughly, though. In short, it's a bit of a mess, but it's non-trivial to fix beyond some basics because it will require us to figure out where we want to go with interface queuing and handoff. Moving to if_startmbuf is relatively easy (I've prototyped it at least once, and have a relatively recent version in p4 somewhere), as you can migrate drivers gradually. On the other hand, without a clear message to driver writers about how we want them to do queueing in the general case, this also comes with risks. Robert N M Watson Computer Laboratory Universty of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Jun 15 16:18:09 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2285316A41A; Thu, 15 Jun 2006 16:18:09 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6698943D45; Thu, 15 Jun 2006 16:18:08 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.1/8.13.1) with ESMTP id k5FGI761042671; Thu, 15 Jun 2006 09:18:07 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20060615115738.J2512@fledge.watson.org> Date: Thu, 15 Jun 2006 09:18:07 -0700 (PDT) From: John Polstra To: Robert Watson Cc: freebsd-net@FreeBSD.org Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF 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: Thu, 15 Jun 2006 16:18:09 -0000 On 15-Jun-2006 Robert Watson wrote: > On Wed, 14 Jun 2006, John Polstra wrote: > >> Can somebody explain why there is both an IF_HANDOFF macro and an >> IFQ_HANDOFF macro? Except for a slight difference in parameters, they both >> seem to do roughly the same thing using completely distinct blocks of code. >> Is IF_HANDOFF supposed to be used only when the target queue is not the >> interface's if_snd queue? That seems likely, but a few pieces of code >> (e.g., ng_fec.c) use IF_HANDOFF to put a packet into the if_snd queue. > > In essense, yes. One is used when the default interface queue is used, and > the other is used when a specific queue is desired. However, the names are, > in fact, backwards from what you expect, for historical reasons. You'll > notice, also, that the behavior of an interface queue in the presence of altq > is quite different than the non-altq case, also for historical reasons, and > that the handoff routines are sometimes without used any ifnet at all (e.g., > the netisr handoff). I've looked at cleaning this up a few times, as well as > a potential race in the use of the IFF_OACTIVE flag, but have gotten > side-tracked in the socket and protocol code for the last 4-6 months. Yep, the IFF_OACTIVE race was one of the things that made it catch my eye in the first place. Luckily (?), most of the FreeBSD drivers use IFF_OACTIVE completely incorrectly. (The em and bge drivers certainly do.) If they used it properly, the race would matter a lot more. > On a number of occasions, we've discussed moving towards an > if_startmbuf() call, which pushes the selection of queueing logic > into the network device driver, which is increasingly desirable when > network interfaces support multiple queues, significant queues in > hardware, and where we have pseudo-interfaces wrapped around real > ones and want to avoid multiple enqueue operations (i.e., if_vlan). Yes! The if_snd queue is obsolete with modern hardware. All it does is slow things down. The network adapter's transmit descriptor ring is all the send queue we need. We obviously can't get rid of the if_snd queue entirely as long as low-end hardware still exists (i.e., until Hell freezes over), but it would be nice if it were possible to bypass it. > A related question is whether or not the generice queueing > primitives should provide implicit locking (as they do now), and > whether coalescing that locking with existing driver locking makes > sense. For example, in the case where oactive isn't currently > set, we actually perform six lock operations during mbuf handoff: > lock/unlock the queue for enqueue, enter the device driver, lock > driver mutex, lock/unlock the queue for dequeue, unlock the device > driver lock. In the case where oactive is set (i.e., there's queued > output), which is frequently the case under load, Good -- I'm glad somebody else understands how IFF_OACTIVE is supposed to be used. Too bad our most important drivers don't use it properly. The whole point of the IFF_OACTIVE flag is to suppress the call to the if_start function when it's not needed -- i.e., whenever we can rely on the driver to come back later on its own initiative and process the if_snd queue. In practice, that means the flag should be set whenever the driver has one or more transmit packets that have been initiated in the HW but have not yet completed. When the completion interrupt comes in, the driver is supposed to check the if_snd queue for more mbufs and process them. Only when the transmit side of the HW goes totally idle should IFF_OACTIVE be cleared again. Most of our drivers set the flag only when they run out of transmit descriptors (i.e., practically never), which is just plain wrong. > this becomes significantly more efficient, because having a separate > queue mutex avoids contention on the driver mutex during send if > the driver is busy, etc. Evaluating the benefits of the additional > granularity there is something that has never been done thoroughly, > though. > > In short, it's a bit of a mess, but it's non-trivial to fix beyond > some basics because it will require us to figure out where we want > to go with interface queuing and handoff. Moving to if_startmbuf > is relatively easy (I've prototyped it at least once, and have a > relatively recent version in p4 somewhere), as you can migrate > drivers gradually. On the other hand, without a clear message to > driver writers about how we want them to do queueing in the general > case, this also comes with risks. Well, I'm glad somebody has been thinking about it. John From owner-freebsd-net@FreeBSD.ORG Thu Jun 15 22:53:23 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9013E16A47D for ; Thu, 15 Jun 2006 22:53:23 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt6.ihug.co.nz (grunt6.ihug.co.nz [203.109.254.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89E8143D67 for ; Thu, 15 Jun 2006 22:53:15 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt6.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1Fr0i9-0005w2-00; Fri, 16 Jun 2006 10:53:13 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 945EF1CC37; Fri, 16 Jun 2006 10:53:12 +1200 (NZST) Date: Fri, 16 Jun 2006 10:53:12 +1200 From: Andrew Thompson To: arch@freebsd.org Message-ID: <20060615225312.GB64552@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: enc0 patch for ipsec 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: Thu, 15 Jun 2006 22:53:23 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have a patch attached that implements the much requested feature of packet filtering ipsec connections. This is a device to expose packets going in/out of ipsec and comes from OpenBSD. There are two functions, a bpf tap which has a basic header with the SPI number which our current tcpdump knows how to display, and handoff to pfil(9) for packet filtering. They way I have hooked it in is compiling it in with fast_ipsec and the extra work is only done when the enc0 interface is created. The interface is not created by default so its a minimal hit, the user will need to 'ifconfig enc0 create' in order to activate it. I believe the locking is correct so it can be created and destroyed at runtime. PRs 98219 and 94829 are requesting this feature. Andrew --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_enc.diff" Index: share/man/man4/enc.4 =================================================================== RCS file: share/man/man4/enc.4 diff -N share/man/man4/enc.4 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ share/man/man4/enc.4 15 Jun 2006 22:08:24 -0000 @@ -0,0 +1,111 @@ +.\" $OpenBSD: enc.4,v 1.22 2006/05/26 08:51:29 jmc Exp $ +.\" +.\" Copyright (c) 1999 Angelos D. Keromytis +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by Angelos D. Keromytis. +.\" 4. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 16, 2006 +.Dt ENC 4 +.Os +.Sh NAME +.Nm enc +.Nd Encapsulating Interface +.Sh DESCRIPTION +The +.Nm +interface is a software loopback mechanism that allows hosts or +firewalls to filter +.Xr fast_ipsec 4 +traffic using any firewall package that hooks in via the +.Xr pfil 9 +framework. +.Pp +In order to enable packet handoff to +.Xr pfil 9 +and +.Xr bpf 4 , +the +.Dq enc0 +interface needs to be created and marked up. +This is most easily done with the +.Xr ifconfig 8 +.Cm create +command or using the +.Va cloned_interfaces +variable in +.Xr rc.conf 5 . +The interface can also be destroyed at runtime, this will disable packet +interception and filtering. +.Pp +The +.Nm +interface allows an administrator +to see outgoing packets before they have been processed by +.Xr fast_ipsec 4 , +or incoming packets after they have been similarly processed, via +.Xr tcpdump 8 . +.Pp +The +.Dq enc0 +interface inherits all IPsec traffic. +Thus all IPsec traffic can be filtered based on +.Dq enc0 , +and all IPsec traffic could be seen by invoking +.Xr tcpdump 8 +on the +.Dq enc0 +interface. +.Sh EXAMPLES +To create the interface and enable IPsec packet filtering: +.Pp +.Bd -literal -offset indent +ifconfig enc0 create up +.Ed +.Pp +To see all outgoing packets before they have been processed via +.Xr fast_ipsec 4 , +or all incoming packets after they have been similarly processed: +.Pp +.Bd -literal -offset indent +tcpdump -i enc0 +.Ed +.Pp +To disable packet filtering: +.Pp +.Bd -literal -offset indent +ifconfig enc0 destroy +.Ed +.Sh SEE ALSO +.Xr bpf 4 , +.Xr fast_ipsec 4 , +.Xr ipf 4 , +.Xr ipfw 4 , +.Xr pf 4 , +.Xr tcpdump 8 Index: share/man/man4/fast_ipsec.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/fast_ipsec.4,v retrieving revision 1.3 diff -u -p -r1.3 fast_ipsec.4 --- share/man/man4/fast_ipsec.4 21 Jan 2005 08:36:37 -0000 1.3 +++ share/man/man4/fast_ipsec.4 15 Jun 2006 22:32:58 -0000 @@ -78,10 +78,16 @@ When the protocols are configured for use, all protocols are included in the system. To selectively enable/disable protocols, use .Xr sysctl 8 . +.Pp +The packets can be passed to a virtual interface, +.Dq enc0 , +to perform packet filtering before outbound encryption and after decapsulation +inbound. .Sh DIAGNOSTICS To be added. .Sh SEE ALSO .Xr crypto 4 , +.Xr enc 4 , .Xr ipsec 4 , .Xr setkey 8 , .Xr sysctl 8 Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1125 diff -u -p -r1.1125 files --- sys/conf/files 14 Jun 2006 03:03:08 -0000 1.1125 +++ sys/conf/files 15 Jun 2006 21:38:18 -0000 @@ -1459,6 +1459,7 @@ net/if_bridge.c optional if_bridge net/if_clone.c standard net/if_disc.c optional disc net/if_ef.c optional ef +net/if_enc.c optional fast_ipsec net/if_ethersubr.c optional ether net/if_faith.c optional faith net/if_fddisubr.c optional fddi Index: sys/net/if_enc.c =================================================================== RCS file: sys/net/if_enc.c diff -N sys/net/if_enc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/net/if_enc.c 15 Jun 2006 21:38:18 -0000 @@ -0,0 +1,323 @@ +/*- + * Copyright (c) 2006 Andrew Thompson + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of Broadcom Corporation nor the name of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written consent. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS' + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF + * THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include "opt_inet6.h" + +#ifdef INET6 +#include +#include +#endif + +#include + +#define ENCMTU (1024+512) +#define ENC_HDRLEN 12 + +/* XXX this define must have the same value as in OpenBSD */ +#define M_CONF 0x0400 /* payload was encrypted (ESP-transport) */ +#define M_AUTH 0x0800 /* payload was authenticated (AH or ESP auth) */ +#define M_AUTH_AH 0x2000 /* header was authenticated (AH) */ + +struct enchdr { + u_int32_t af; + u_int32_t spi; + u_int32_t flags; +}; + +struct ifnet *encif; +struct mtx enc_mtx; + +struct enc_softc { + struct ifnet *sc_ifp; +}; + +int encioctl(struct ifnet *, u_long, caddr_t); +int encoutput(struct ifnet *ifp, struct mbuf *m, + struct sockaddr *dst, struct rtentry *rt); +static int enc_clone_create(struct if_clone *, int); +static void enc_clone_destroy(struct ifnet *); + +IFC_SIMPLE_DECLARE(enc, 0); + +static void +enc_clone_destroy(struct ifnet *ifp) +{ + + KASSERT(encif == ifp, ("%s: unknown ifnet", __func__)); + + mtx_lock(&enc_mtx); + encif = NULL; + mtx_unlock(&enc_mtx); + + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + +} + +static int +enc_clone_create(struct if_clone *ifc, int unit) +{ + struct ifnet *ifp; + struct enc_softc *sc; + + mtx_lock(&enc_mtx); + if (encif != NULL) + return (EBUSY); + mtx_unlock(&enc_mtx); + + sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); + ifp = sc->sc_ifp = if_alloc(IFT_ENC); + if (ifp == NULL) { + free(sc, M_DEVBUF); + return (ENOSPC); + } + + if_initname(ifp, ifc->ifc_name, unit); + ifp->if_mtu = ENCMTU; + ifp->if_ioctl = encioctl; + ifp->if_output = encoutput; + ifp->if_snd.ifq_maxlen = ifqmaxlen; + ifp->if_softc = sc; + if_attach(ifp); + bpfattach(ifp, DLT_ENC, ENC_HDRLEN); + + mtx_lock(&enc_mtx); + encif = ifp; + mtx_unlock(&enc_mtx); + + return (0); +} + +static int +enc_modevent(module_t mod, int type, void *data) +{ + switch (type) { + case MOD_LOAD: + mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); + if_clone_attach(&enc_cloner); + break; + case MOD_UNLOAD: + printf("enc module unload - not possible for this module\n"); + return (EINVAL); + default: + return (EOPNOTSUPP); + } + return (0); +} + +static moduledata_t enc_mod = { + "enc", + enc_modevent, + 0 +}; + +DECLARE_MODULE(enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); + +int +encoutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt) +{ + m_freem(m); + return (0); +} + +/* + * Process an ioctl request. + */ +/* ARGSUSED */ +int +encioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + int error = 0; + + switch (cmd) { + + case SIOCSIFFLAGS: + if (ifp->if_flags & IFF_UP) + ifp->if_drv_flags |= IFF_DRV_RUNNING; + else + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + + break; + + default: + error = EINVAL; + } + return (error); +} + +int +ipsec_filter(struct mbuf **mp, int dir) +{ + int error, i; + struct ip *ip; + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return (0); + } + + /* Skip pfil(9) if no filters are loaded */ + if (inet_pfil_hook.ph_busy_count < 0 +#ifdef INET6 + && inet6_pfil_hook.ph_busy_count < 0 +#endif + ) { + mtx_unlock(&enc_mtx); + return (0); + } + + i = min((*mp)->m_pkthdr.len, max_protohdr); + if ((*mp)->m_len < i) { + *mp = m_pullup(*mp, i); + if (*mp == NULL) { + printf("%s: m_pullup failed\n", __func__); + mtx_unlock(&enc_mtx); + return (-1); + } + } + + error = 0; + ip = mtod(*mp, struct ip *); + switch (ip->ip_v) { + case 4: + /* + * before calling the firewall, swap fields the same as + * IP does. here we assume the header is contiguous + */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + + error = pfil_run_hooks(&inet_pfil_hook, mp, + encif, dir, NULL); + + if (*mp == NULL || error != 0) + break; + + /* restore byte ordering */ + ip = mtod(*mp, struct ip *); + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + break; + +#ifdef INET6 + case 6: + error = pfil_run_hooks(&inet6_pfil_hook, mp, + encif, dir, NULL); + break; +#endif + default: + printf("%s: unknown IP version\n", __func__); + } + + mtx_unlock(&enc_mtx); + if (*mp == NULL) + return (error); + if (error != 0) + goto bad; + + return (error); + +bad: + mtx_unlock(&enc_mtx); + m_freem(*mp); + *mp = NULL; + return (error); +} + +void +ipsec_bpf(struct mbuf *m, struct secasvar *sav, int af) +{ + int flags; + struct enchdr hdr; + struct mbuf m1; + + KASSERT(sav != NULL, ("%s: sav is null", __func__)); + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return; + } + + if (encif->if_bpf) { + flags = 0; + if (sav->alg_enc != SADB_EALG_NONE) + flags |= M_CONF; + if (sav->alg_auth != SADB_AALG_NONE) + flags |= M_AUTH; + + /* + * We need to prepend the address family as a four byte + * field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf + * (i.e., it won't try to free it or keep a pointer a + * to it). + */ + hdr.af = af; + hdr.spi = sav->spi; + hdr.flags = flags; + + m1.m_flags = 0; + m1.m_next = m; + m1.m_len = ENC_HDRLEN; + m1.m_data = (char *) &hdr; + + bpf_mtap(encif->if_bpf, &m1); + } + mtx_unlock(&enc_mtx); +} Index: sys/net/if_types.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_types.h,v retrieving revision 1.21 diff -u -p -r1.21 if_types.h --- sys/net/if_types.h 10 Jun 2005 16:49:19 -0000 1.21 +++ sys/net/if_types.h 15 Jun 2006 21:38:18 -0000 @@ -246,6 +246,7 @@ #define IFT_GIF 0xf0 #define IFT_PVC 0xf1 #define IFT_FAITH 0xf2 +#define IFT_ENC 0xf4 #define IFT_PFLOG 0xf6 #define IFT_PFSYNC 0xf7 #define IFT_CARP 0xf8 /* Common Address Redundancy Protocol */ Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec.h,v retrieving revision 1.11 diff -u -p -r1.11 ipsec.h --- sys/netipsec/ipsec.h 10 Apr 2006 15:04:36 -0000 1.11 +++ sys/netipsec/ipsec.h 15 Jun 2006 21:38:18 -0000 @@ -335,6 +335,8 @@ extern int ipsec_replay; extern int ipsec_integrity; #endif +extern struct ifnet *encif; + extern struct newipsecstat newipsecstat; extern struct secpolicy ip4_def_policy; extern int ip4_esp_trans_deflev; @@ -417,6 +419,9 @@ extern void m_checkalignment(const char* extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); +extern int ipsec_filter(struct mbuf **, int); +extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); + #endif /* _KERNEL */ #ifndef _KERNEL Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_input.c --- sys/netipsec/ipsec_input.c 4 Jun 2006 19:32:32 -0000 1.11 +++ sys/netipsec/ipsec_input.c 15 Jun 2006 21:38:18 -0000 @@ -443,6 +443,18 @@ ipsec4_common_input_cb(struct mbuf *m, s key_sa_recordxfer(sav, m); /* record data transfer */ /* + * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP + * packet later after it has been decapsulated. + */ + if (encif != NULL) { + ipsec_bpf(m, sav, AF_INET); + + if (prot != IPPROTO_IPIP) + if ((error = ipsec_filter(&m, 1)) != 0) + return (error); + } + + /* * Re-dispatch via software interrupt. */ if ((error = netisr_queue(NETISR_IP, m))) { Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_output.c --- sys/netipsec/ipsec_output.c 2 Nov 2005 13:46:32 -0000 1.11 +++ sys/netipsec/ipsec_output.c 15 Jun 2006 21:38:18 -0000 @@ -358,6 +358,11 @@ ipsec4_process_packet( goto bad; sav = isr->sav; + + /* pass the mbuf to enc0 for packet filtering */ + if (encif != NULL && (error = ipsec_filter(&m, 2)) != 0) + goto bad; + if (!tunalready) { union sockaddr_union *dst = &sav->sah->saidx.dst; int setdf; @@ -455,6 +460,10 @@ ipsec4_process_packet( } } + /* pass the mbuf to enc0 for bpf processing */ + if (encif != NULL) + ipsec_bpf(m, sav, AF_INET); + /* * Dispatch to the appropriate IPsec transform logic. The * packet will be returned for transmission after crypto Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.12 diff -u -p -r1.12 xform_ipip.c --- sys/netipsec/xform_ipip.c 30 Mar 2006 18:57:04 -0000 1.12 +++ sys/netipsec/xform_ipip.c 15 Jun 2006 21:38:18 -0000 @@ -345,6 +345,10 @@ _ipip_input(struct mbuf *m, int iphlen, /* Statistics */ ipipstat.ipips_ibytes += m->m_pkthdr.len - iphlen; + /* pass the mbuf to enc0 for packet filtering */ + if (encif != NULL && ipsec_filter(&m, 1) != 0) + return; + /* * Interface pointer stays the same; if no IPsec processing has * been done (or will be done), this will point to a normal --ReaqsoxgOBHFXBhH-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 02:57:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DB3616A474 for ; Fri, 16 Jun 2006 02:57:50 +0000 (UTC) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207FB43D45 for ; Fri, 16 Jun 2006 02:57:48 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from [159.28.58.193] (wir058193.rpa.earlham.edu [159.28.58.193]) (authenticated bits=0) by quark.cs.earlham.edu (8.13.6/8.13.3) with ESMTP id k5G2viMU096351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jun 2006 22:57:45 -0400 (EDT) (envelope-from skylar@cs.earlham.edu) X-Authentication-Warning: quark.cs.earlham.edu: Host wir058193.rpa.earlham.edu [159.28.58.193] claimed to be [159.28.58.193] Message-ID: <44922162.6060709@cs.earlham.edu> Date: Thu, 15 Jun 2006 23:11:30 -0400 From: Skylar Thompson Organization: Earlham College Computer Science Department User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <20060613164814.GA43973@quark.cs.earlham.edu> <4lqu82t2u0p8ol5ih51ad37em2bb6ll52k@4ax.com> In-Reply-To: <4lqu82t2u0p8ol5ih51ad37em2bb6ll52k@4ax.com> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1CC933F90BE4649DB03E128D" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [159.28.230.3]); Thu, 15 Jun 2006 22:57:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.2/1464/Tue May 16 05:36:19 2006 on quark.cs.earlham.edu X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.56 on 159.28.230.3 X-Spam-Status: No, score=-4.0 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on quark.cs.earlham.edu Cc: freebsd-net@freebsd.org Subject: Re: bge(4) and gigabit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: skylar@cs.earlham.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 02:57:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1CC933F90BE4649DB03E128D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike Tancsa wrote: >On Tue, 13 Jun 2006 12:48:14 -0400, in sentex.lists.freebsd.net you >wrote: > > > >>I've got a Poweredge 1750 6-STABLE, and I'm having problems getting its onboard >>Ethernet interfaces negotiated to gigabit speeds. It has dual Broadcom >>BCM5704C copper interfaces, which are supported by the bge(4) driver. >> >>I've tried this againt a managed gigabit switch: I plugged in both >>interfaces, and start out at 10baseT. Increasing to 100 works fine, but >>going to 1000baseT causes the link to drop. I've tried using ifconfig to >>force media settings, and these also only work up to 100baseT. I've also >>tried the cabling and switch with other gigabit gear, and these negotiate >>fine. >> >>I also had this machine running Linux at one point, and it negotiated to >>gigabit then, so the interfaces themselves shouldn't be the problem. >> >>Any ideas? >> >> > >Hi, > >Can you post to the list the output of >ifconfig -a >and >dmesg >and >uname -a > > I've upgraded to 6.1-RELEASE, and it seems like the problem has gone away. I used to get lots of messages like this: bge1: link state changed to DOWN bge1: link state changed to UP but now I just get the link state changing to UP once. -- -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --------------enig1CC933F90BE4649DB03E128D 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.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEkiFisc4yyULgN4YRAvNwAJ4zhMhAfimkMeKj3WSy9rK5leaQqgCZAXTl dAxKakoHNolPZws/HXZuf4w= =kEAB -----END PGP SIGNATURE----- --------------enig1CC933F90BE4649DB03E128D-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 03:44:02 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91EF716A47E for ; Fri, 16 Jun 2006 03:44:02 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FA0B43D48 for ; Fri, 16 Jun 2006 03:43:59 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id EB6834CAF5 for ; Fri, 16 Jun 2006 03:44:08 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 8E4E54CAAB for ; Fri, 16 Jun 2006 03:44:08 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 812898A01F for ; Fri, 16 Jun 2006 13:43:55 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 754418A00D for ; Fri, 16 Jun 2006 13:43:55 +1000 (EST) Message-ID: <449228FA.50303@thebeastie.org> Date: Fri, 16 Jun 2006 13:43:54 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: VPN with FAST_IPSEC and ipsec tools 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: Fri, 16 Jun 2006 03:44:02 -0000 Hey all. I have been trying to setup a VPN between 2 FreeBSD hosts, but I can't get any IKE exchange activity via ipsec tools happening. I used this script http://thebeastie.org/projects/vpnsetup/vpnsetup.pl which I created for my self to help me remember all the knobs, its been about a year since I last did a VPN and I am finding that with FAST_IPSEC (haven't tested yet with other IPSec) and with FreeBSD 6.1release that I am not getting any IKE exchange activity including any kind of attempts for the VPNs to connect to each other, it just appear that ipsec-tools doesn't identify any interesting traffic that I set, I am guessing its something to do with FAST_IPSEC but I am not sure. I have setup the GRE tunneling and that is working fine doing pings and tracerts when I disable ipsec and ipsec-tools, its just the encryption side thats the problem. Can any one help? Thanks Mike From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 12:29:08 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A106516A47A for ; Fri, 16 Jun 2006 12:29:08 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71A643D7B for ; Fri, 16 Jun 2006 12:29:00 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 98B7424C30; Fri, 16 Jun 2006 08:28:59 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 5B0F556D3C; Fri, 16 Jun 2006 08:28:57 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FrDRX-0007cV-J6; Fri, 16 Jun 2006 13:28:55 +0100 Date: Fri, 16 Jun 2006 13:28:55 +0100 From: Brian Candler To: Michael Vince Message-ID: <20060616122855.GA29279@uk.tiscali.com> References: <449228FA.50303@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449228FA.50303@thebeastie.org> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: VPN with FAST_IPSEC and ipsec tools 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: Fri, 16 Jun 2006 12:29:08 -0000 On Fri, Jun 16, 2006 at 01:43:54PM +1000, Michael Vince wrote: > I have setup the GRE tunneling and that is working fine doing pings and > tracerts when I disable ipsec and ipsec-tools, its just the encryption > side thats the problem. Ah, I guess this means you're following the instructions in the FreeBSD handbook, which last time I looked gave a most bizarre and unnecessary way of setting up IPSEC (GIF tunneling running on top of IPSEC *tunnel* mode). I raised it on this list before. Most people are better off just setting up IPSEC tunnel mode. A few use GIF running on top of IPSEC _transport_ mode (e.g. those running routing protocols like OSPF over tunnels) Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 15:35:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A79D16A47D; Fri, 16 Jun 2006 15:35:36 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87ED243D45; Fri, 16 Jun 2006 15:35:35 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGMA331i-0000Cf; Fri, 16 Jun 2006 17:35:34 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 16 Jun 2006 17:35:27 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> In-Reply-To: <20060615225312.GB64552@heff.fud.org.nz> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2154621.EIZNAYH37s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161735.33801.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: arch@freebsd.org, Andrew Thompson , net@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 15:35:36 -0000 --nextPart2154621.EIZNAYH37s Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 00:53, Andrew Thompson wrote: > I have a patch attached that implements the much requested feature of > packet filtering ipsec connections. > > This is a device to expose packets going in/out of ipsec and comes > from OpenBSD. There are two functions, a bpf tap which has a basic > header with the SPI number which our current tcpdump knows how to > display, and handoff to pfil(9) for packet filtering. > > They way I have hooked it in is compiling it in with fast_ipsec and > the extra work is only done when the enc0 interface is created. The > interface is not created by default so its a minimal hit, the user > will need to 'ifconfig enc0 create' in order to activate it. I > believe the locking is correct so it can be created and destroyed at > runtime. I think it should get a "device enc" on its own. Some people might conside= r=20 enc(4) to be a security problem so getting it with FAST_IPSEC automatically= =20 isn't preferable. Other than that, great news. Thanks a lot. > PRs 98219 and 94829 are requesting this feature. > > > > Andrew =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2154621.EIZNAYH37s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEks/FXyyEoT62BG0RAtKgAJ4tmOL2iMvLf7KaAmyUB23gT0gAPgCaAyv9 JCyNxxVv06CA/LSaRXMX2d0= =Mtlo -----END PGP SIGNATURE----- --nextPart2154621.EIZNAYH37s-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 15:35:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A79D16A47D; Fri, 16 Jun 2006 15:35:36 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87ED243D45; Fri, 16 Jun 2006 15:35:35 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGMA331i-0000Cf; Fri, 16 Jun 2006 17:35:34 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 16 Jun 2006 17:35:27 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> In-Reply-To: <20060615225312.GB64552@heff.fud.org.nz> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2154621.EIZNAYH37s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161735.33801.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: arch@freebsd.org, Andrew Thompson , net@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 15:35:36 -0000 --nextPart2154621.EIZNAYH37s Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 00:53, Andrew Thompson wrote: > I have a patch attached that implements the much requested feature of > packet filtering ipsec connections. > > This is a device to expose packets going in/out of ipsec and comes > from OpenBSD. There are two functions, a bpf tap which has a basic > header with the SPI number which our current tcpdump knows how to > display, and handoff to pfil(9) for packet filtering. > > They way I have hooked it in is compiling it in with fast_ipsec and > the extra work is only done when the enc0 interface is created. The > interface is not created by default so its a minimal hit, the user > will need to 'ifconfig enc0 create' in order to activate it. I > believe the locking is correct so it can be created and destroyed at > runtime. I think it should get a "device enc" on its own. Some people might conside= r=20 enc(4) to be a security problem so getting it with FAST_IPSEC automatically= =20 isn't preferable. Other than that, great news. Thanks a lot. > PRs 98219 and 94829 are requesting this feature. > > > > Andrew =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2154621.EIZNAYH37s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEks/FXyyEoT62BG0RAtKgAJ4tmOL2iMvLf7KaAmyUB23gT0gAPgCaAyv9 JCyNxxVv06CA/LSaRXMX2d0= =Mtlo -----END PGP SIGNATURE----- --nextPart2154621.EIZNAYH37s-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 15:42:13 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB3D16A47B; Fri, 16 Jun 2006 15:42:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id C707A43D58; Fri, 16 Jun 2006 15:42:11 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k5GFg8V7001639; Fri, 16 Jun 2006 17:42:09 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id BDE2C3F17; Fri, 16 Jun 2006 17:42:03 +0200 (CEST) Date: Fri, 16 Jun 2006 17:42:03 +0200 From: VANHULLEBUS Yvan To: Andrew Thompson Message-ID: <20060616154203.GA11590@zen.inc> References: <20060615225312.GB64552@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060615225312.GB64552@heff.fud.org.nz> User-Agent: All mail clients suck. This one just sucks less. Cc: arch@freebsd.org, net@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 15:42:13 -0000 On Fri, Jun 16, 2006 at 10:53:12AM +1200, Andrew Thompson wrote: > Hi, Hi. > PRs 98219 and 94829 are requesting this feature. Patch provided in PR 94829 does not provide filters hook, but it has support for both IPSEC and FAST_IPSEC. Perhaps we could merge some "features" of both patches, I'll have a look at that. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 15:43:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DDBE16A47A for ; Fri, 16 Jun 2006 15:43:12 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C28E43D49 for ; Fri, 16 Jun 2006 15:43:12 +0000 (GMT) (envelope-from fox@verio.net) Received: from [129.250.36.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 1FrGTU-0006vg-8z for freebsd-net@freebsd.org; Fri, 16 Jun 2006 15:43:08 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp1.email.verio.net with esmtp id 1FrGTU-00054I-5c for freebsd-net@freebsd.org; Fri, 16 Jun 2006 15:43:08 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 9DAD68E2CC; Fri, 16 Jun 2006 10:43:07 -0500 (CDT) Date: Fri, 16 Jun 2006 10:43:07 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20060616154306.GA18578@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20060616122855.GA29279@uk.tiscali.com> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: VPN with FAST_IPSEC and ipsec tools 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: Fri, 16 Jun 2006 15:43:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Candler wrote: > > Ah, I guess this means you're following the instructions in the > FreeBSD handbook, which last time I looked gave a most bizarre and > unnecessary way of setting up IPSEC (GIF tunneling running on top of > IPSEC *tunnel* mode). I raised it on this list before. I ran into the same thing when analyzing the handbook's examples, and quickly abandoned the handbook when writing my own configs. > Most people are better off just setting up IPSEC tunnel mode. A few > use GIF running on top of IPSEC _transport_ mode (e.g. those running > routing protocols like OSPF over tunnels) The main reason to use IPSEC tunnel mode and avoid GIF is that such a config is interoperable with other IPSEC implementations (Cisco, Checkpoint, etc), and thus is much more useful in the real world. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEktGKFSrKRjX5eCoRAq7JAJwIljDoGlZu+PDcFRT8842UpvXPkwCfZP8l IXMhmlNoy/++m/CxIoIhfHI= =ftpL -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 16:05:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73F7416A47D; Fri, 16 Jun 2006 16:05:09 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4473C43D7E; Fri, 16 Jun 2006 16:05:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGol1vD6-0000AE; Fri, 16 Jun 2006 18:05:07 +0200 From: Max Laier Organization: FreeBSD To: "Scott Ullrich" Date: Fri, 16 Jun 2006 18:04:55 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4110410.kbyFMc9pHU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161805.06651.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 16:05:09 -0000 --nextPart4110410.kbyFMc9pHU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 17:41, Scott Ullrich wrote: > On 6/16/06, Max Laier wrote: > > I think it should get a "device enc" on its own. Some people might > > consider enc(4) to be a security problem so getting it with FAST_IPSEC > > automatically isn't preferable. > > You have to specifically create the enc0 interface (ifconfig enc0 > create) before it becomes active. Otherwise it will not hit the enc > code path unless the device is created. The issue is, if an attacker manages to get root on your box they are=20 automatically able to read your IPSEC traffic ending at that box. If you=20 don't have enc(4) compiled in, that would be more difficult to do. Same=20 reason you don't want SADB_FLUSH on by default. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4110410.kbyFMc9pHU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEktayXyyEoT62BG0RAsneAJ9O1gLgquzP085Nqi+8um5aXpnQ/QCfdQVw Xw51C+T0P5BCfzA43UczxwI= =eusH -----END PGP SIGNATURE----- --nextPart4110410.kbyFMc9pHU-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 16:14:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D8D316A479; Fri, 16 Jun 2006 16:14:22 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F95143D49; Fri, 16 Jun 2006 16:14:21 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGxg0zHV-0000Bm; Fri, 16 Jun 2006 18:14:20 +0200 From: Max Laier Organization: FreeBSD To: "Scott Ullrich" Date: Fri, 16 Jun 2006 18:14:12 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4390624.zale1C6xGP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161814.19336.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 16:14:22 -0000 --nextPart4390624.zale1C6xGP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 18:09, Scott Ullrich wrote: > On 6/16/06, Max Laier wrote: > > The issue is, if an attacker manages to get root on your box they are > > automatically able to read your IPSEC traffic ending at that box. If y= ou > > don't have enc(4) compiled in, that would be more difficult to do. Same > > reason you don't want SADB_FLUSH on by default. > > Okay, this makes sense. But couldn't you also argue that if someone > gets access to the machine they could also use tcpdump to do the same > thing technically on the internal interface? Just playing devils > advocate.. :) Think tunnel2tunnel or an SA for a local connection, then. Given, if you a= re=20 root you *might* have other means to obtain that information, but that is w= hy=20 we have a switch to turn off bpf, kmem or the like. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4390624.zale1C6xGP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEktjbXyyEoT62BG0RAmjNAJ9WLPc7LByESWUlyzHR/dt0J9OiigCbBAms Fo8vKq0DHjCKaUeltXeskjk= =FL6S -----END PGP SIGNATURE----- --nextPart4390624.zale1C6xGP-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 17:22:21 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFC4A16A474; Fri, 16 Jun 2006 17:22:21 +0000 (UTC) (envelope-from gordon@FreeBSD.org) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F3E43D49; Fri, 16 Jun 2006 17:22:21 +0000 (GMT) (envelope-from gordon@FreeBSD.org) Received: from [192.168.1.50] (cpe-66-91-238-221.san.res.rr.com [66.91.238.221]) (authenticated bits=0) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id k5GHMIiR038251; Fri, 16 Jun 2006 10:22:19 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Message-ID: <4492E8CE.1020405@FreeBSD.org> Date: Fri, 16 Jun 2006 10:22:22 -0700 From: Gordon Tetlow User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Max Laier References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> In-Reply-To: <200606161805.06651.max@love2party.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org, Andrew Thompson , Scott Ullrich Subject: Re: enc0 patch for ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gordon@tetlows.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 17:22:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max Laier wrote: > On Friday 16 June 2006 17:41, Scott Ullrich wrote: >> On 6/16/06, Max Laier wrote: >>> I think it should get a "device enc" on its own. Some people might >>> consider enc(4) to be a security problem so getting it with FAST_IPSEC >>> automatically isn't preferable. >> You have to specifically create the enc0 interface (ifconfig enc0 >> create) before it becomes active. Otherwise it will not hit the enc >> code path unless the device is created. > > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. Max is absolutely right here. The snooping interface should be a separate option altogether (a la bpf). - -gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEktfGRu2t9DV9ZfsRAvyzAJ9jnUigVW7t2SGV89vXStXAZ30b7QCeJ4tZ tBeTqHk9LofxCRf40uFvpZE= =RGmG -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 17:43:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DE9816A474 for ; Fri, 16 Jun 2006 17:43:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97B9143D48 for ; Fri, 16 Jun 2006 17:43:57 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 13453 invoked from network); 16 Jun 2006 17:44:12 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Jun 2006 17:44:12 -0000 Message-ID: <4492EDDA.6080406@freebsd.org> Date: Fri, 16 Jun 2006 19:43:54 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Max Laier References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> In-Reply-To: <200606161805.06651.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, Andrew Thompson , Scott Ullrich Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 17:43:59 -0000 Max Laier wrote: > On Friday 16 June 2006 17:41, Scott Ullrich wrote: >> On 6/16/06, Max Laier wrote: >>> I think it should get a "device enc" on its own. Some people might >>> consider enc(4) to be a security problem so getting it with FAST_IPSEC >>> automatically isn't preferable. >> You have to specifically create the enc0 interface (ifconfig enc0 >> create) before it becomes active. Otherwise it will not hit the enc >> code path unless the device is created. > > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. *If* someone manages to get root on you IPSEC endpoint you've lost anyway. The availability of enc(4) then is no longer of importance. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 18:57:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A11316A479 for ; Fri, 16 Jun 2006 18:57:26 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id C09F143D45 for ; Fri, 16 Jun 2006 18:57:25 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1914237uge for ; Fri, 16 Jun 2006 11:57:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hb566xrx7XnJdRXM676wDgvgW/FAfTKW55zizv3TfbT/tLDwxDoOkNI9qW7EGtqoJO7zJtIvlwDOOFkvsuWHXLE1Pa4WhW6cKvbbk6i7D4//IpXQRhVrouMPW/k6IYHvsfffcEZ+h4+Ct7uN1wme2skGnORDen0krOkES+iREoY= Received: by 10.66.216.6 with SMTP id o6mr1636550ugg; Fri, 16 Jun 2006 09:09:03 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 09:09:03 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 12:09:03 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161805.06651.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 18:57:26 -0000 On 6/16/06, Max Laier wrote: > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. Okay, this makes sense. But couldn't you also argue that if someone gets access to the machine they could also use tcpdump to do the same thing technically on the internal interface? Just playing devils advocate.. :) From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 19:02:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F28D16A47B for ; Fri, 16 Jun 2006 19:02:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 981A743D45 for ; Fri, 16 Jun 2006 19:02:01 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 20523 invoked by uid 399); 16 Jun 2006 19:02:00 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jun 2006 19:02:00 -0000 Message-ID: <44930029.5050308@FreeBSD.org> Date: Fri, 16 Jun 2006 12:02:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> <20060616154306.GA18578@verio.net> In-Reply-To: <20060616154306.GA18578@verio.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: VPN with FAST_IPSEC and ipsec tools 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: Fri, 16 Jun 2006 19:02:02 -0000 David DeSimone wrote: > I ran into the same thing when analyzing the handbook's examples, and > quickly abandoned the handbook when writing my own configs. Those who are more knowledgeable on this topic might want to consider writing an update, or an entirely new section for this. You don't need to learn the docbook stuff to do this, there are folks on freebsd-doc@ who would be glad to take that on as a project. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 19:14:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F23116A47D for ; Fri, 16 Jun 2006 19:14:22 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id C715C43D73 for ; Fri, 16 Jun 2006 19:14:13 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1922730uge for ; Fri, 16 Jun 2006 12:14:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P1Ya1AeiSPcUdky4eoAhLh8eMbAu4Kr81rOhk64uzqAUISHK3RdgyHC5KRcwT8TnjaMA2TC/Ug4pRwa9vNvtkD0qf4P4+fBmWMrie16fKeRWGFAgeeNJdz3KCMlubIOBjE4Y57jxAhk06dqyKXJGJA57NzZ3OtT/Vm8fXxZf2q0= Received: by 10.67.106.3 with SMTP id i3mr2882344ugm; Fri, 16 Jun 2006 09:15:33 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 09:15:32 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 12:15:32 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161814.19336.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 19:14:22 -0000 On 6/16/06, Max Laier wrote: > Think tunnel2tunnel or an SA for a local connection, then. Given, if you are > root you *might* have other means to obtain that information, but that is why > we have a switch to turn off bpf, kmem or the like. Gotcha. Thanks for clarifying :) Scott From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 19:38:16 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6807416A47D for ; Fri, 16 Jun 2006 19:38:16 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id A194B43D46 for ; Fri, 16 Jun 2006 19:38:15 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1934266uge for ; Fri, 16 Jun 2006 12:38:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QNdmAY6uaOMRV4xX9vi4O5mALyKCmc9B41W9yBR+ohUc08gDE6w9g/7EAtviHUQaBFQJ7sZ6F2x4HoHJojj5Sj7QoYYqwFM8rwmXCy9krvz5Dzvv3NWlrrGJO51eHlHKTsAWKlavev48TA9aG747PmhFjGgXD1qEG1mmpLg7Bos= Received: by 10.67.30.6 with SMTP id h6mr2859112ugj; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 11:41:27 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161735.33801.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> Cc: freebsd-net@freebsd.org, net@freebsd.org, Andrew Thompson , arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 19:38:16 -0000 On 6/16/06, Max Laier wrote: > I think it should get a "device enc" on its own. Some people might consider > enc(4) to be a security problem so getting it with FAST_IPSEC automatically > isn't preferable. You have to specifically create the enc0 interface (ifconfig enc0 create) before it becomes active. Otherwise it will not hit the enc code path unless the device is created. Scott From owner-freebsd-net@FreeBSD.ORG Fri Jun 16 22:22:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5263A16A47D for ; Fri, 16 Jun 2006 22:22:49 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt8.ihug.co.nz (grunt8.ihug.co.nz [203.109.254.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 839FD43D4C for ; Fri, 16 Jun 2006 22:22:47 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt8.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1FrMiC-0005fj-00; Sat, 17 Jun 2006 10:22:44 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 062591CC37; Sat, 17 Jun 2006 10:22:44 +1200 (NZST) Date: Sat, 17 Jun 2006 10:22:43 +1200 From: Andrew Thompson To: Max Laier Message-ID: <20060616222243.GC64552@heff.fud.org.nz> References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <200606161814.19336.max@love2party.net> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, Scott Ullrich Subject: Re: enc0 patch for ipsec 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: Fri, 16 Jun 2006 22:22:49 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 16, 2006 at 06:14:12PM +0200, Max Laier wrote: > On Friday 16 June 2006 18:09, Scott Ullrich wrote: > > On 6/16/06, Max Laier wrote: > > > The issue is, if an attacker manages to get root on your box they are > > > automatically able to read your IPSEC traffic ending at that box. If you > > > don't have enc(4) compiled in, that would be more difficult to do. Same > > > reason you don't want SADB_FLUSH on by default. > > > > Okay, this makes sense. But couldn't you also argue that if someone > > gets access to the machine they could also use tcpdump to do the same > > thing technically on the internal interface? Just playing devils > > advocate.. :) > > Think tunnel2tunnel or an SA for a local connection, then. Given, if you are > root you *might* have other means to obtain that information, but that is why > we have a switch to turn off bpf, kmem or the like. While the encryption keys are just a setkey -D away, I can see the reason for seperating it out. I have attached another patch with the changes made. Andrew --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_enc.diff" Index: share/man/man4/enc.4 =================================================================== RCS file: share/man/man4/enc.4 diff -N share/man/man4/enc.4 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ share/man/man4/enc.4 16 Jun 2006 22:04:25 -0000 @@ -0,0 +1,82 @@ +.\" $OpenBSD: enc.4,v 1.22 2006/05/26 08:51:29 jmc Exp $ +.\" +.\" Copyright (c) 1999 Angelos D. Keromytis +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by Angelos D. Keromytis. +.\" 4. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 16, 2006 +.Dt ENC 4 +.Os +.Sh NAME +.Nm enc +.Nd Encapsulating Interface +.Sh SYNOPSIS +.Cd "device enc" +.Sh DESCRIPTION +The +.Nm +interface is a software loopback mechanism that allows hosts or +firewalls to filter +.Xr fast_ipsec 4 +traffic using any firewall package that hooks in via the +.Xr pfil 9 +framework. +.Pp +The +.Nm +interface allows an administrator +to see outgoing packets before they have been processed by +.Xr fast_ipsec 4 , +or incoming packets after they have been similarly processed, via +.Xr tcpdump 8 . +.Pp +The +.Dq enc0 +interface inherits all IPsec traffic. +Thus all IPsec traffic can be filtered based on +.Dq enc0 , +and all IPsec traffic could be seen by invoking +.Xr tcpdump 8 +on the +.Dq enc0 +interface. +.Sh EXAMPLES +To see all outgoing packets before they have been processed via +.Xr fast_ipsec 4 , +or all incoming packets after they have been similarly processed: +.Pp +.Dl # tcpdump -i enc0 +.Sh SEE ALSO +.Xr bpf 4 , +.Xr fast_ipsec 4 , +.Xr ipf 4 , +.Xr ipfw 4 , +.Xr pf 4 , +.Xr tcpdump 8 Index: share/man/man4/fast_ipsec.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/fast_ipsec.4,v retrieving revision 1.3 diff -u -p -r1.3 fast_ipsec.4 --- share/man/man4/fast_ipsec.4 21 Jan 2005 08:36:37 -0000 1.3 +++ share/man/man4/fast_ipsec.4 15 Jun 2006 22:32:58 -0000 @@ -78,10 +78,16 @@ When the protocols are configured for use, all protocols are included in the system. To selectively enable/disable protocols, use .Xr sysctl 8 . +.Pp +The packets can be passed to a virtual interface, +.Dq enc0 , +to perform packet filtering before outbound encryption and after decapsulation +inbound. .Sh DIAGNOSTICS To be added. .Sh SEE ALSO .Xr crypto 4 , +.Xr enc 4 , .Xr ipsec 4 , .Xr setkey 8 , .Xr sysctl 8 Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1125 diff -u -p -r1.1125 files --- sys/conf/files 14 Jun 2006 03:03:08 -0000 1.1125 +++ sys/conf/files 16 Jun 2006 21:13:10 -0000 @@ -1459,6 +1459,7 @@ net/if_bridge.c optional if_bridge net/if_clone.c standard net/if_disc.c optional disc net/if_ef.c optional ef +net/if_enc.c optional enc net/if_ethersubr.c optional ether net/if_faith.c optional faith net/if_fddisubr.c optional fddi Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.546 diff -u -p -r1.546 options --- sys/conf/options 13 Jun 2006 13:12:55 -0000 1.546 +++ sys/conf/options 16 Jun 2006 21:24:28 -0000 @@ -340,6 +340,7 @@ BOOTP_NFSROOT opt_bootp.h BOOTP_NFSV3 opt_bootp.h BOOTP_WIRED_TO opt_bootp.h DEVICE_POLLING +DEV_ENC opt_enc.h DEV_PF opt_pf.h DEV_PFLOG opt_pf.h DEV_PFSYNC opt_pf.h Index: sys/net/if_enc.c =================================================================== RCS file: sys/net/if_enc.c diff -N sys/net/if_enc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/net/if_enc.c 16 Jun 2006 21:15:45 -0000 @@ -0,0 +1,323 @@ +/*- + * Copyright (c) 2006 The FreeBSD Project. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include "opt_inet6.h" + +#ifdef INET6 +#include +#include +#endif + +#include + +#define ENCMTU (1024+512) +#define ENC_HDRLEN 12 + +/* XXX this define must have the same value as in OpenBSD */ +#define M_CONF 0x0400 /* payload was encrypted (ESP-transport) */ +#define M_AUTH 0x0800 /* payload was authenticated (AH or ESP auth) */ +#define M_AUTH_AH 0x2000 /* header was authenticated (AH) */ + +struct enchdr { + u_int32_t af; + u_int32_t spi; + u_int32_t flags; +}; + +struct ifnet *encif; +struct mtx enc_mtx; + +struct enc_softc { + struct ifnet *sc_ifp; +}; + +int encioctl(struct ifnet *, u_long, caddr_t); +int encoutput(struct ifnet *ifp, struct mbuf *m, + struct sockaddr *dst, struct rtentry *rt); +static int enc_clone_create(struct if_clone *, int); +static void enc_clone_destroy(struct ifnet *); + +IFC_SIMPLE_DECLARE(enc, 1); + +static void +enc_clone_destroy(struct ifnet *ifp) +{ + + KASSERT(encif == ifp, ("%s: unknown ifnet", __func__)); + + mtx_lock(&enc_mtx); + encif = NULL; + mtx_unlock(&enc_mtx); + + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + +} + +static int +enc_clone_create(struct if_clone *ifc, int unit) +{ + struct ifnet *ifp; + struct enc_softc *sc; + + mtx_lock(&enc_mtx); + if (encif != NULL) + return (EBUSY); + mtx_unlock(&enc_mtx); + + sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); + ifp = sc->sc_ifp = if_alloc(IFT_ENC); + if (ifp == NULL) { + free(sc, M_DEVBUF); + return (ENOSPC); + } + + if_initname(ifp, ifc->ifc_name, unit); + ifp->if_mtu = ENCMTU; + ifp->if_ioctl = encioctl; + ifp->if_output = encoutput; + ifp->if_snd.ifq_maxlen = ifqmaxlen; + ifp->if_softc = sc; + if_attach(ifp); + bpfattach(ifp, DLT_ENC, ENC_HDRLEN); + + mtx_lock(&enc_mtx); + encif = ifp; + mtx_unlock(&enc_mtx); + + return (0); +} + +static int +enc_modevent(module_t mod, int type, void *data) +{ + switch (type) { + case MOD_LOAD: + mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); + if_clone_attach(&enc_cloner); + break; + case MOD_UNLOAD: + printf("enc module unload - not possible for this module\n"); + return (EINVAL); + default: + return (EOPNOTSUPP); + } + return (0); +} + +static moduledata_t enc_mod = { + "enc", + enc_modevent, + 0 +}; + +DECLARE_MODULE(enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); + +int +encoutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt) +{ + m_freem(m); + return (0); +} + +/* + * Process an ioctl request. + */ +/* ARGSUSED */ +int +encioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + int error = 0; + + switch (cmd) { + + case SIOCSIFFLAGS: + if (ifp->if_flags & IFF_UP) + ifp->if_drv_flags |= IFF_DRV_RUNNING; + else + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + + break; + + default: + error = EINVAL; + } + return (error); +} + +int +ipsec_filter(struct mbuf **mp, int dir) +{ + int error, i; + struct ip *ip; + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return (0); + } + + /* Skip pfil(9) if no filters are loaded */ + if (inet_pfil_hook.ph_busy_count < 0 +#ifdef INET6 + && inet6_pfil_hook.ph_busy_count < 0 +#endif + ) { + mtx_unlock(&enc_mtx); + return (0); + } + + i = min((*mp)->m_pkthdr.len, max_protohdr); + if ((*mp)->m_len < i) { + *mp = m_pullup(*mp, i); + if (*mp == NULL) { + printf("%s: m_pullup failed\n", __func__); + mtx_unlock(&enc_mtx); + return (-1); + } + } + + error = 0; + ip = mtod(*mp, struct ip *); + switch (ip->ip_v) { + case 4: + /* + * before calling the firewall, swap fields the same as + * IP does. here we assume the header is contiguous + */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + + error = pfil_run_hooks(&inet_pfil_hook, mp, + encif, dir, NULL); + + if (*mp == NULL || error != 0) + break; + + /* restore byte ordering */ + ip = mtod(*mp, struct ip *); + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + break; + +#ifdef INET6 + case 6: + error = pfil_run_hooks(&inet6_pfil_hook, mp, + encif, dir, NULL); + break; +#endif + default: + printf("%s: unknown IP version\n", __func__); + } + + mtx_unlock(&enc_mtx); + if (*mp == NULL) + return (error); + if (error != 0) + goto bad; + + return (error); + +bad: + mtx_unlock(&enc_mtx); + m_freem(*mp); + *mp = NULL; + return (error); +} + +void +ipsec_bpf(struct mbuf *m, struct secasvar *sav, int af) +{ + int flags; + struct enchdr hdr; + struct mbuf m1; + + KASSERT(sav != NULL, ("%s: sav is null", __func__)); + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return; + } + + if (encif->if_bpf) { + flags = 0; + if (sav->alg_enc != SADB_EALG_NONE) + flags |= M_CONF; + if (sav->alg_auth != SADB_AALG_NONE) + flags |= M_AUTH; + + /* + * We need to prepend the address family as a four byte + * field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf + * (i.e., it won't try to free it or keep a pointer a + * to it). + */ + hdr.af = af; + hdr.spi = sav->spi; + hdr.flags = flags; + + m1.m_flags = 0; + m1.m_next = m; + m1.m_len = ENC_HDRLEN; + m1.m_data = (char *) &hdr; + + bpf_mtap(encif->if_bpf, &m1); + } + mtx_unlock(&enc_mtx); +} Index: sys/net/if_types.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_types.h,v retrieving revision 1.21 diff -u -p -r1.21 if_types.h --- sys/net/if_types.h 10 Jun 2005 16:49:19 -0000 1.21 +++ sys/net/if_types.h 15 Jun 2006 21:38:18 -0000 @@ -246,6 +246,7 @@ #define IFT_GIF 0xf0 #define IFT_PVC 0xf1 #define IFT_FAITH 0xf2 +#define IFT_ENC 0xf4 #define IFT_PFLOG 0xf6 #define IFT_PFSYNC 0xf7 #define IFT_CARP 0xf8 /* Common Address Redundancy Protocol */ Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec.h,v retrieving revision 1.11 diff -u -p -r1.11 ipsec.h --- sys/netipsec/ipsec.h 10 Apr 2006 15:04:36 -0000 1.11 +++ sys/netipsec/ipsec.h 16 Jun 2006 21:21:57 -0000 @@ -417,6 +417,8 @@ extern void m_checkalignment(const char* extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); +extern int ipsec_filter(struct mbuf **, int); +extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); #endif /* _KERNEL */ #ifndef _KERNEL Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_input.c --- sys/netipsec/ipsec_input.c 4 Jun 2006 19:32:32 -0000 1.11 +++ sys/netipsec/ipsec_input.c 16 Jun 2006 21:21:19 -0000 @@ -43,6 +43,7 @@ #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipsec.h" +#include "opt_enc.h" #include #include @@ -442,6 +443,18 @@ ipsec4_common_input_cb(struct mbuf *m, s key_sa_recordxfer(sav, m); /* record data transfer */ +#ifdef DEV_ENC + /* + * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP + * packet later after it has been decapsulated. + */ + ipsec_bpf(m, sav, AF_INET); + + if (prot != IPPROTO_IPIP) + if ((error = ipsec_filter(&m, 1)) != 0) + return (error); +#endif + /* * Re-dispatch via software interrupt. */ Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_output.c --- sys/netipsec/ipsec_output.c 2 Nov 2005 13:46:32 -0000 1.11 +++ sys/netipsec/ipsec_output.c 16 Jun 2006 21:21:33 -0000 @@ -32,6 +32,7 @@ #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipsec.h" +#include "opt_enc.h" #include #include @@ -358,6 +359,13 @@ ipsec4_process_packet( goto bad; sav = isr->sav; + +#ifdef DEV_ENC + /* pass the mbuf to enc0 for packet filtering */ + if ((error = ipsec_filter(&m, 2)) != 0) + goto bad; +#endif + if (!tunalready) { union sockaddr_union *dst = &sav->sah->saidx.dst; int setdf; @@ -455,6 +463,11 @@ ipsec4_process_packet( } } +#ifdef DEV_ENC + /* pass the mbuf to enc0 for bpf processing */ + ipsec_bpf(m, sav, AF_INET); +#endif + /* * Dispatch to the appropriate IPsec transform logic. The * packet will be returned for transmission after crypto Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.12 diff -u -p -r1.12 xform_ipip.c --- sys/netipsec/xform_ipip.c 30 Mar 2006 18:57:04 -0000 1.12 +++ sys/netipsec/xform_ipip.c 16 Jun 2006 21:21:02 -0000 @@ -41,6 +41,7 @@ */ #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_enc.h" #include #include @@ -345,6 +346,12 @@ _ipip_input(struct mbuf *m, int iphlen, /* Statistics */ ipipstat.ipips_ibytes += m->m_pkthdr.len - iphlen; +#ifdef DEV_ENC + /* pass the mbuf to enc0 for packet filtering */ + if (ipsec_filter(&m, 1) != 0) + return; +#endif + /* * Interface pointer stays the same; if no IPsec processing has * been done (or will be done), this will point to a normal --H+4ONPRPur6+Ovig-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 00:16:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE8816A47A for ; Sat, 17 Jun 2006 00:16:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7055543D46 for ; Sat, 17 Jun 2006 00:16:38 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so84827uge for ; Fri, 16 Jun 2006 17:16:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QNdmAY6uaOMRV4xX9vi4O5mALyKCmc9B41W9yBR+ohUc08gDE6w9g/7EAtviHUQaBFQJ7sZ6F2x4HoHJojj5Sj7QoYYqwFM8rwmXCy9krvz5Dzvv3NWlrrGJO51eHlHKTsAWKlavev48TA9aG747PmhFjGgXD1qEG1mmpLg7Bos= Received: by 10.67.30.6 with SMTP id h6mr2859112ugj; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 11:41:27 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161735.33801.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> Cc: freebsd-net@freebsd.org, net@freebsd.org, Andrew Thompson , arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Sat, 17 Jun 2006 00:16:39 -0000 On 6/16/06, Max Laier wrote: > I think it should get a "device enc" on its own. Some people might consider > enc(4) to be a security problem so getting it with FAST_IPSEC automatically > isn't preferable. You have to specifically create the enc0 interface (ifconfig enc0 create) before it becomes active. Otherwise it will not hit the enc code path unless the device is created. Scott From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 06:58:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6803316A47B; Sat, 17 Jun 2006 06:58:38 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC45C43D49; Sat, 17 Jun 2006 06:58:37 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5H6vRJw011536; Fri, 16 Jun 2006 23:57:28 -0700 (PDT) Date: Sat, 17 Jun 2006 13:07:10 +0900 Message-ID: From: gnn@freebsd.org To: Andrew Thompson In-Reply-To: <20060616222243.GC64552@heff.fud.org.nz> References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> <20060616222243.GC64552@heff.fud.org.nz> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.5.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Max Laier , Scott Ullrich , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: enc0 patch for ipsec 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: Sat, 17 Jun 2006 06:58:38 -0000 I knew there was something bothering me about enc, now I know what it was. I'm glad someone else caught this and that you fixed it. Thanks. I'll be testing the patch today. Later, George From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 18:02:15 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D0F16A47B; Sat, 17 Jun 2006 18:02:15 +0000 (UTC) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE6943D72; Sat, 17 Jun 2006 18:02:10 +0000 (GMT) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (gnn@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5HI2AqL002475; Sat, 17 Jun 2006 18:02:10 GMT (envelope-from gnn@freefall.freebsd.org) Received: (from gnn@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5HI2AXG002471; Sat, 17 Jun 2006 18:02:10 GMT (envelope-from gnn) Date: Sat, 17 Jun 2006 18:02:10 GMT From: "George V. Neville-Neil" Message-Id: <200606171802.k5HI2AXG002471@freefall.freebsd.org> To: arved@FreeBSD.org, diffie@blazebox.homeip.net, gnn@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/93220: [inet6] nd6_lookup: failed to add route for a neighbor 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: Sat, 17 Jun 2006 18:02:15 -0000 Synopsis: [inet6] nd6_lookup: failed to add route for a neighbor State-Changed-From-To: analyzed->feedback State-Changed-By: gnn State-Changed-When: Sat Jun 17 18:01:32 UTC 2006 State-Changed-Why: This is fixed in HEAD and MFC'd to STABLE (6). http://www.freebsd.org/cgi/query-pr.cgi?pr=93220 From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 18:13:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 167F016A47C for ; Sat, 17 Jun 2006 18:13:35 +0000 (UTC) (envelope-from henri.lubkeiqat@connection.se) Received: from 158.124.100-84.rev.gaoland.net (158.124.100-84.rev.gaoland.net [84.100.124.158]) by mx1.FreeBSD.org (Postfix) with SMTP id BF1AA43D66 for ; Sat, 17 Jun 2006 18:13:32 +0000 (GMT) (envelope-from henri.lubkeiqat@connection.se) Received: from mail3.connection.se by 158.124.100-84.rev.gaoland.net (Postfix) with ESMTP id 98ADAD52CA for ; Sat, 17 Jun 2006 14:13:34 -0400 Received: from unknown (dsnat [83.19.247.109]) by mail3.connection.se (8.9.3/8.9.3) id dcnxlX1kI76C for ; Sat, 17 Jun 2006 14:13:34 -0400 From: "Son Lloyd" Message-ID: <6668306710.5559586762@connection.se> Date: Sat, 17 Jun 2006 14:13:34 -0400 To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: stunning russiian Hussy in poono! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Son Lloyd List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 18:13:35 -0000 heavenly russian Hussy! http://barcelonetaze.info/lzalesbians.htm?eSffiRg-WfQ.eSffiRg,VSd D_e_l_e_tt_e http://barcelonetaze.info From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 19:04:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3BD116A47A for ; Sat, 17 Jun 2006 19:04:27 +0000 (UTC) (envelope-from shhebm@svenhuggins.com) Received: from lib59-4-82-239-16-77.fbx.proxad.net (lib59-4-82-239-16-77.fbx.proxad.net [82.239.16.77]) by mx1.FreeBSD.org (Postfix) with SMTP id 0B28C43D6E for ; Sat, 17 Jun 2006 19:04:21 +0000 (GMT) (envelope-from shhebm@svenhuggins.com) Received: from addr-mx03.addr.com by lib59-4-82-239-16-77.fbx.proxad.net (8.9.3/8.9.3) with SMTP id SkHWMH0xGXqO for ; Sat, 17 Jun 2006 15:04:22 -0400 Received: from unknown (HELO moisjjaxltfrz) (30.70.191.56) by addr-mx03.addr.com with ESMTP (Exim 4.05) id 4LaUnKzVne5h for ; Sat, 17 Jun 2006 15:04:22 -0400 From: "Kennith" Message-ID: <1776420435.20060617150422@moisjjaxltfrz> Date: Sat, 17 Jun 2006 15:04:22 -0400 To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: gorgeous Just Teen and pleasant Teenie from Your dreeam! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kennith Garland List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 19:04:27 -0000 aesthetical Just Teenie and adorable Teens from Your dreeam! http://hazeo.info/lzawebcams.htm?eSffiRg-WfQ.eSffiRg,VSd R_E_M_O_\/_EE http://hazeo.info From owner-freebsd-net@FreeBSD.ORG Sat Jun 17 23:55:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 865F116A47C for ; Sat, 17 Jun 2006 23:55:04 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2951B43D45 for ; Sat, 17 Jun 2006 23:55:02 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from 64-144-229-193.client.dsl.net ([64.144.229.193] helo=[192.168.0.3] ident=HF/3TgbX/9/UIYum8LqbwJCi0wGFcdYb) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1Frket-000NsX-48 for freebsd-net@freebsd.org; Sat, 17 Jun 2006 16:57:31 -0700 Date: Sat, 17 Jun 2006 16:54:14 -0700 From: Pat Lashley To: freebsd-net@freebsd.org Message-ID: <5F4490F8BF56DA5CC71AFBBC@clarke.phoenix.volant.org> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scan-Signature: 4de86cbcd03a6dda1a120864d4b7ad3490d36406 X-Spam-User: nobody X-Spam-Score: -4.9 (----) X-Spam-Score-Int: -48 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.9 points total, 5.0 required) -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0006] Subject: IPv4 Link Local ? 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: Sat, 17 Jun 2006 23:55:04 -0000 I'm trying to set up a Zeroconf/Bonjour based network. The net/avahi port should handle the service publication and discovery; but so far I haven't figured out how to do the RFC 3330 IPv4 Link Local addressing negotiation. Is there an implementation for FreeBSD (6.1) ? Thanks, -Pat