From owner-freebsd-isp@FreeBSD.ORG Sun Jun 11 16:13:16 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33EF916A41A for ; Sun, 11 Jun 2006 16:13:16 +0000 (UTC) (envelope-from szlists@szarka.org) Received: from hustle.szarka.net (hustle.szarka.net [204.89.131.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1A6843D45 for ; Sun, 11 Jun 2006 16:13:15 +0000 (GMT) (envelope-from szlists@szarka.org) Received: from BUCKY.szarka.org (ip-65-75-16-177.ct.dsl.ntplx.com [65.75.16.177]) by hustle.szarka.net (8.13.6/8.13.6) with ESMTP id k5BGDDJx083074 for ; Sun, 11 Jun 2006 12:13:14 -0400 (EDT) (envelope-from szlists@szarka.org) Message-Id: <7.0.1.0.0.20060611113015.072d4698@szarka.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Jun 2006 12:13:13 -0400 To: freebsd-isp@freebsd.org From: Rob Szarka Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Sendmail/SASL2/saslauthdb problem X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 16:13:16 -0000 I'm trying to configure sendmail to authenticate against the system password file for SMTP using the ports collection and having a heck of a time with it. saslauthdb works great when tested with testsaslauthd (testsaslauthd -s smtp -u XXXXX -p XXXXX returns Success), but when testing by hand with the same account through sendmail (with the same bare username, no realm), I get the following error: saslauthd[38367]: do_auth : auth failure: [user=XXXXXXX] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] From the other side, I see sendmail offering "250-AUTH PLAIN LOGIN" (what I want) in the ESTMP session and doing the auth login prompting, but then returning "535 5.7.0 authentication failed" in response to the base64-ed username and password. Can anyone shed light on this? Here's my configuration: FreeBSD 6.0-RELEASE #1 Sendmail 8.13.6/8.13.6 (installed via mail/sendmail-sasl compiled against an earlier install of security/cyrus-sasl2 -- I can see it passing the "-DSASL=2" during make) /usr/local/lib/sasl2/Sendmail.conf has "pwcheck_method: saslauthd" and, I'm assuming from the error message, sendmail is actually calling it. From owner-freebsd-isp@FreeBSD.ORG Sun Jun 11 19:55:30 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51B916A41A for ; Sun, 11 Jun 2006 19:55:30 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AA1443D45 for ; Sun, 11 Jun 2006 19:55:30 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 60DE61CF4D; Sun, 11 Jun 2006 15:55:29 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 5A1194AC45; Sun, 11 Jun 2006 15:55:03 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17548.29975.326996.34162@canoe.dclg.ca> Date: Sun, 11 Jun 2006 15:55:03 -0400 To: Mark Bucciarelli In-Reply-To: <20060609132028.GB468@rabbit> References: <20060609132028.GB468@rabbit> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Cc: freebsd-isp@freebsd.org Subject: "smart" switch recommendations? X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 19:55:30 -0000 >>>>> "Mark" == Mark Bucciarelli writes: Mark> We are looking to buy a new smart (aka a dumbed-down managed) Mark> switch. Mark> I read the recent Tom's Hardware review [1] of the Netgear Mark> FS728TS, and price- and feature-wise it looks like what we need Mark> EXCEPT THAT the setup utility is Windows-only and the web gui Mark> doesn't display properly in Firefox, two show-stoppers for us. Cisco 2924 (and 2950's and their ilk) continue to be budget-priced on eBay. 24 10/100 ports for $100 to $300 is a good buy. But the Cisco GigE offerings have been slow to come down in price. We recently bought a Linksys SRW2024. They're managable. The latest firmware plays well with firefox. They have a minimal telnet or serial console. And their front panel (right down to two mini-gbics) match one of the cisco models (prices 10x more on eBay) exactly. Now... I suppose what you loose is the cisco interface. I'm convinced it's in there. I'm convinced the hardware is the same, but $550 vs. $5500 is a big jump. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-isp@FreeBSD.ORG Sun Jun 11 20:01:53 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D79416A473; Sun, 11 Jun 2006 20:01:53 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211AF43D46; Sun, 11 Jun 2006 20:01:50 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k5BK1nrl092952; Sun, 11 Jun 2006 15:01:50 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <448C76B6.9050200@centtech.com> Date: Sun, 11 Jun 2006 15:01:58 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.2 (X11/20060506) MIME-Version: 1.0 To: Robin Elfrink References: <44852CF1.5070300@introweb.nl> <62208.10.20.200.100.1149598242.squirrel@10.20.200.100> <44857BA4.90405@introweb.nl> <56782.10.20.200.100.1149599550.squirrel@10.20.200.100> <4486C4DA.6080905@introweb.nl> <4486D193.3000801@centtech.com> <4486E0F2.8080809@introweb.nl> In-Reply-To: <4486E0F2.8080809@introweb.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1525/Sun Jun 11 10:56:09 2006 on mh2.centtech.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 11 Jun 2006 20:03:11 +0000 Cc: freebsd-fs@freebsd.org Subject: Re: Recovery from disk+fs crash X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:01:53 -0000 Robin Elfrink wrote: > Eric Anderson wrote: > >> Can you run dumpfs on it, and put the output somewhere accessible on the >> web? > > Yes, here it is: > > http://eddy.introweb.nl/~robin/dump/ > > File da0s1f.dump is the output from 'dumpfs /dev/da0s1f', dumpfs.core is > the result of dumpfs dumping core. > > > > Robin Robin, I looked at it, and it looks like the reading of cylindar group 185 is the culprit. Without fsdb usable, it's hard to attempt fixing. I think the routine that attempts to alloc memory needs to be tweaked to recognize ridiculous numbers, but I'm not sure the best way to do it - I suppose for this case, one could just truncate at some ceiling to get past it, but that would definitely be the wrong thing to do, and dangerous too most likely. I've cc'ed the -fs list, and bcc'ed the -isp list, since this is a filesystem issue, and more people with fs-foo will be able to chime in. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-isp@FreeBSD.ORG Sun Jun 11 20:20:33 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Sun Jun 11 22:30:19 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2223A16A418 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.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32CE843D55 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 i31so810847wxd 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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 09:13:18 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E034016A41B for ; Mon, 12 Jun 2006 09:13:18 +0000 (UTC) (envelope-from szlists@szarka.org) Received: from hustle.szarka.net (hustle.szarka.net [204.89.131.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B54243D46 for ; Mon, 12 Jun 2006 09:13:18 +0000 (GMT) (envelope-from szlists@szarka.org) Received: from BUCKY.szarka.org (ip-65-75-16-177.ct.dsl.ntplx.com [65.75.16.177]) (authenticated bits=0) by hustle.szarka.net (8.13.6/8.13.6) with ESMTP id k5C9DGGk008639 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jun 2006 05:13:17 -0400 (EDT) (envelope-from szlists@szarka.org) Message-Id: <7.0.1.0.0.20060612051259.04bbfd10@szarka.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Jun 2006 05:13:17 -0400 To: freebsd-isp@freebsd.org From: Rob Szarka In-Reply-To: <7.0.1.0.0.20060611113015.072d4698@szarka.org> References: <7.0.1.0.0.20060611113015.072d4698@szarka.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Sendmail/SASL2/saslauthdb problem X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 09:13:19 -0000 *ahem* I would like to point out the following obvious (in retrospect) advice about testing smtp auth by hand: when using mmencode to translate to base64, one should printf "username" | mmencode not echo "username" | mmencode Of course, it wasn't working from my usual MUA either, originally; but after I fixed my problem, I didn't know it was fixed because I was testing with a bad username and password. *sigh* After a complete deinstall/reinstall/reconfigure didn't work, I caught on... From owner-freebsd-isp@FreeBSD.ORG Mon Jun 12 09:56:01 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 10:09:37 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 11:29:17 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2706016A418 for ; Mon, 12 Jun 2006 11:29:17 +0000 (UTC) (envelope-from jflowers@ezo.net) Received: from mbox.ezo.net (mbox.ezo.net [12.156.78.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C986043D46 for ; Mon, 12 Jun 2006 11:29:16 +0000 (GMT) (envelope-from jflowers@ezo.net) Received: from ezo.net (localhost [127.0.0.1]) by mbox.ezo.net (Postfix) with ESMTP id 805DD5C1D for ; Mon, 12 Jun 2006 07:29:27 -0400 (EDT) Received: from 127.0.0.1 ([127.0.0.1] helo=ezo.net) by MXSentry; 12 Jun 2006 07:29:26 -0400 From: "jflowers" To: freebsd-isp@freebsd.org Date: Mon, 12 Jun 2006 07:29:26 -0400 Message-Id: <20060612111724.M53249@ezo.net> In-Reply-To: <7.0.1.0.0.20060612051259.04bbfd10@szarka.org> References: <7.0.1.0.0.20060611113015.072d4698@szarka.org> <7.0.1.0.0.20060612051259.04bbfd10@szarka.org> X-Mailer: OpenWebMail 2.52 20060502 X-OriginatingIP: 65.25.65.37 (jflowers@ezo.net) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: Sendmail/SASL2/saslauthdb problem X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jflowers@ezo.net List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 11:29:17 -0000 Nibbed in here without reading the rest of the thread as I just finished debugging some dovecot SASL. On FreeBSD mmencode can't be used, even with printf for 'auth plain' because it can't handle the null (\0) characters required. At least I couldn't figure out how to do it. My solution was to use perl with MIME::Base64 installed as in: perl -MMIME::Base64 -e 'print encode_base64("user\@domain.tld\0user\@domain.tld\0password");' mmencode -u can be used to test the encoding as there are no nulls: perl -MMIME::Base64 -e 'print encode_base64("user\@domain.tld\0user\@domain.tld\0password");' | mmencode -u On Mon, 12 Jun 2006 05:13:17 -0400, Rob Szarka wrote > *ahem* > > I would like to point out the following obvious (in retrospect) > advice about testing smtp auth by hand: > > when using mmencode to translate to base64, one should > > printf "username" | mmencode > > not > > echo "username" | mmencode > > Of course, it wasn't working from my usual MUA either, originally; > but after I fixed my problem, I didn't know it was fixed because I > was testing with a bad username and password. > > *sigh* > > After a complete deinstall/reinstall/reconfigure didn't work, I > caught on... > > _______________________________________________ > freebsd-isp@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-isp > To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" -- Jim Flowers From owner-freebsd-isp@FreeBSD.ORG Mon Jun 12 12:50:24 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 18:47:02 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C3816A473 for ; Mon, 12 Jun 2006 18:47:02 +0000 (UTC) (envelope-from sklauder@trimind.de) Received: from rhiannon.shopkeeper.de (rhiannon.shopkeeper.de [217.65.28.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C5143D70 for ; Mon, 12 Jun 2006 18:47:00 +0000 (GMT) (envelope-from sklauder@trimind.de) Received: from avalon.dobu.local (p54B86EC6.dip.t-dialin.net [84.184.110.198]) (authenticated bits=0) by rhiannon.shopkeeper.de (8.13.4/8.13.4) with ESMTP id k5CIkrOM071175; Mon, 12 Jun 2006 20:46:54 +0200 (CEST) (envelope-from sklauder@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.13.6/8.12.11) with ESMTP id k5CIkr2R011720; Mon, 12 Jun 2006 20:46:53 +0200 (CEST) (envelope-from sklauder@avalon.dobu.local) Received: (from sklauder@localhost) by avalon.dobu.local (8.13.6/8.13.6/Submit) id k5CIkqpJ011719; Mon, 12 Jun 2006 20:46:52 +0200 (CEST) (envelope-from sklauder) Date: Mon, 12 Jun 2006 20:46:52 +0200 From: Sascha Klauder To: Dirk Meyer Message-ID: <20060612184652.GA11655@trimind.de> References: <7.0.1.0.0.20060611113015.072d4698@szarka.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at trimind.de Cc: freebsd-isp@freebsd.org Subject: Re: Sendmail/SASL2/saslauthdb problem X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 18:47:03 -0000 On Mon, Jun 12, 2006 at 04:43:55PM +0200, Dirk Meyer wrote: > For detailed Links to this topic: > cd /usr/ports/mail/sendmail-sasl && make howto-sasldb http://www.asp.ogi.edu/people/paja/linux/sendmail/ http://blue-labs.org/clue/sendmail.php http://www.digitalanswers.org/sendmail/ are dead. Cheers, -sascha From owner-freebsd-isp@FreeBSD.ORG Mon Jun 12 19:51:39 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 383B416A473 for ; Mon, 12 Jun 2006 19:51:39 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D89C43D46 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 i2so952492nfe 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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:51:39 -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-isp@FreeBSD.ORG Mon Jun 12 20:21:10 2006 Return-Path: X-Original-To: freebsd-isp@FreeBSD.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 20:30:39 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Mon Jun 12 22:51:51 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@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-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers 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-isp@FreeBSD.ORG Tue Jun 13 00:53:16 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EE4116A41A for ; Tue, 13 Jun 2006 00:53:16 +0000 (UTC) (envelope-from szlists@szarka.org) Received: from hustle.szarka.net (hustle.szarka.net [204.89.131.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id D653543D46 for ; Tue, 13 Jun 2006 00:53:15 +0000 (GMT) (envelope-from szlists@szarka.org) Received: from BUCKY.szarka.org (ip-65-75-16-177.ct.dsl.ntplx.com [65.75.16.177]) (authenticated bits=0) by hustle.szarka.net (8.13.6/8.13.6) with ESMTP id k5D0rEJH044914 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jun 2006 20:53:14 -0400 (EDT) (envelope-from szlists@szarka.org) Message-Id: <7.0.1.0.0.20060612204915.0683fc98@szarka.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Jun 2006 20:53:14 -0400 To: freebsd-isp@freebsd.org From: Rob Szarka In-Reply-To: <20060612111724.M53249@ezo.net> References: <7.0.1.0.0.20060611113015.072d4698@szarka.org> <7.0.1.0.0.20060612051259.04bbfd10@szarka.org> <20060612111724.M53249@ezo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Sendmail/SASL2/saslauthdb problem X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 00:53:16 -0000 At 07:29 AM 6/12/2006, jflowers wrote: >On FreeBSD mmencode can't be used, even with >printf for 'auth plain' because it can't handle the null (\0) characters >required. At least I couldn't figure out how to do it. My solution was to use >perl with MIME::Base64 installed as in: Another alternative, apparently, is printf "foo" | openssl base64 I didn't think of it at the time, but then I read July's issue of Linux Journal. :) From owner-freebsd-isp@FreeBSD.ORG Tue Jun 13 08:48:54 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B743816A418 for ; Tue, 13 Jun 2006 08:48:54 +0000 (UTC) (envelope-from abuse@nntpserver.com) Received: from nibble.net (mail.nibble.net [64.74.111.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C31E43D49 for ; Tue, 13 Jun 2006 08:48:53 +0000 (GMT) (envelope-from abuse@nntpserver.com) Received: from IMAIL_LOCAL (unverified [localhost]) by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 33141989 for ; Tue, 13 Jun 2006 03:48:53 -0500 X-Confirm: 1150188533.8760_70319.griffin From: "abuse@nntpserver.com (Friends system)" To: "Mail User" Date: Tue, 13 Jun 2006 03:48:53 -0500 Message-ID: <1150188533_26911@griffin> Subject: Please reply to confirm(1150188533.8760_70319.griffin) message and allow delivery X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 08:48:54 -0000 Your email to "abuse@nntpserver.com" with the subject "fake" has been blocked by the Friends system. abuse@nntpserver.com only accepts email from people on a list of approved senders to minimize spam, you are not currently on this list. If you would like to be added to the list simply reply to this message without changing the subject line. From owner-freebsd-isp@FreeBSD.ORG Tue Jun 13 22:19:34 2006 Return-Path: X-Original-To: isp@freebsd.org Delivered-To: freebsd-isp@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D676B16A41A for ; Tue, 13 Jun 2006 22:19:34 +0000 (UTC) (envelope-from www@bsd.zcp.bf) Received: from bsd.zcp.bf (www.zcp.bf [212.52.154.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A663543D45 for ; Tue, 13 Jun 2006 22:19:30 +0000 (GMT) (envelope-from www@bsd.zcp.bf) Received: from bsd.zcp.bf (3b02260ff51934e1d40e38669493ad57@localhost.zcp.bf [127.0.0.1]) by bsd.zcp.bf (8.12.10/8.12.10) with ESMTP id k5DMjrQp001990 for ; Tue, 13 Jun 2006 22:45:54 GMT (envelope-from www@bsd.zcp.bf) Received: (from www@localhost) by bsd.zcp.bf (8.12.10/8.12.8/Submit) id k5DMjqSv001989; Tue, 13 Jun 2006 22:45:52 GMT Date: Tue, 13 Jun 2006 22:45:52 GMT Message-Id: <200606132245.k5DMjqSv001989@bsd.zcp.bf> To: isp@freebsd.org From: Halifax Online Banking Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Failed Login X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 22:19:35 -0000 [1.GIF] IMPORTANT SECURITY ALERT _________________________________________________________________ Please note that our system recently noted that your attemption of signing on to your account was failed while some errors occured during the processing update of your online account you are having with our bank.. We sincerely hereby to notify you that you should kindly follow below link to update your online account for your security safety ensured by our financial insititution. [1]https://www.halifax-online.co.uk/_mem_bin/FormsLogin.asp?source=hal ifaxouk Thank you for your prompt attention to this matter. Please understand that this is a security measure meant to help protect you and your account. We apologize for any inconvenience. If you choose to ignore our request, your account may leads to be temporarily suspended _________________________________________________________________ Investment Fund Managers Limited, Halifax Life Limited and Halifax Share Dealing Limited are authorised and regulated by the Financial Services AuthorityThey are entered in the Financial Services Authority's Register and their Register Numbers are 106048, 119223, 171881 and 183332. This is an English language site, all contracts will be in the English language only. For optimal viewing of this site you will need [2]Macromedia Flash version 5 or above. Copyright © 2005, Halifax plc. All rights reserved References 1. http://www.icon-kanon.ru/news/rublev/images/account/resolve/member/halifax/login 2. http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash