From owner-freebsd-ipfw@FreeBSD.ORG Sun May 5 11:06:06 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C7B44FC8 for ; Sun, 5 May 2013 11:06:06 +0000 (UTC) (envelope-from prvs=18375574d3=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id A6D2B9A4 for ; Sun, 5 May 2013 11:06:06 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50001888165.msg; Sun, 05 May 2013 04:05:51 -0700 X-Spam-Processed: mail02.amotive.com, Sun, 05 May 2013 04:05:51 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=18375574d3=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-ipfw@freebsd.org Date: Sun, 5 May 2013 04:04:41 -0700 To: freebsd-ipfw From: CAD Americas Subject: CAD Americas Early Bird Registration Ends May 7 Message-ID: <0ea53551291173236a194cd9c1f177d4@agave.cadamericas.com> X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 77ccc95b-32c7-9bc8-6b39-51863c3218c9 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: CAD Americas List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 11:06:06 -0000 TIME IS RUNNING OUT! Register for CAD Americas Training Days by MAY 7 and S= AVE!=0ACAD AMERICAS TRAINING DAYS ARRIVE IN YOUR AREA SOON Join us for this= one-day training event in your area. Whether your focus is Mechanical Desi= gn, Construction, BIM, Electrical Design or Plant Design, there will be ses= sions that will improve your productivity immediately!=0AJune 4June 6June 7= June 12June 13June 26 June 27=0A Cleveland Cincinnati Detroit Atlanta D= allas San Jose San_Bernardino =0ATAKE HOME NEW TOOLS AND TECHNIQUES THAT = WILL IMPROVE YOUR PERFORMANCE IMMEDIATELY=0A=0A=0A=0A=0ALynn AllenTechnical= Evangelist More =0ARobert GreenCAD Mgmt Expert More =0ASteve SchainAutoCAD= Expert More =0ATod StephensRevit Expert More =0AClick here to see current = session descriptions.Please note that sessions will vary by location =0ALea= rn from well-known industry instructors who will share best practices and t= rends, product tips and tricks, new features =E2=80=A6 and more.=0AImprove = your productivity with new techniques that you can put to work right away.= =0AMeet your peers and exchange ideas on how to best use the CAD tools you = have to meet the demands of your job.=0ATake a closer look at services and = technologies offered by resellers in your area.=0AREGISTER BY MAY 7TH AND S= AVERegister for=C2=A0a CAD Americas Training Day by May 7th and save.=0AEar= ly Bird Rate: $150 (Until May 7th)=0AStandard Rate: $195 (AFTER May 7th)=0A= Student/Faculty Rate: $95 (must present current student ID upon check-in at= registration)=0AREGISTER FOR CAD AMERICAS TRAINING TODAY!=0A=0A=0A=0A=0AJo= in us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL SPONSORS=0A= =0A=0A=C2=A0=C2=A0 =C2=A0=C2=A0 =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONS= ORS=0A=0A=C2=A0=0AThis email was sent to email address: freebsd-ipfw@freebs= d.org Click here to Opt-Out=0A From owner-freebsd-ipfw@FreeBSD.ORG Sun May 5 11:40:01 2013 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A58D5215 for ; Sun, 5 May 2013 11:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 97706A5D for ; Sun, 5 May 2013 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r45Be14Z048255 for ; Sun, 5 May 2013 11:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r45Be1DV048254; Sun, 5 May 2013 11:40:01 GMT (envelope-from gnats) Date: Sun, 5 May 2013 11:40:01 GMT Message-Id: <201305051140.r45Be1DV048254@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Kirill Diduk Subject: Re: misc/178317: IPFW options need to specifed in specific order X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Kirill Diduk List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 11:40:01 -0000 The following reply was made to PR kern/178317; it has been noted by GNATS. From: Kirill Diduk To: bug-followup@FreeBSD.org, jens.kassel@aptilo.com Cc: luigi@FreeBSD.org Subject: Re: misc/178317: IPFW options need to specifed in specific order Date: Sun, 5 May 2013 14:35:44 +0300 --047d7b6dc9a814b57404dbf6fc68 Content-Type: text/plain; charset=ISO-8859-1 Hello, The problem is related to the command line parsing implementation in the file "sbin/ipfw/dummynet.c" (function "ipfw_config_pipe"). Consider the example: # ipfw pipe 3 config bw 1000000kbit/s mask src-ip 0xffffffff queue 92 When the "mask" token is encountered, it starts to parse FLOW_MASK options ('src-ip", etc.), and skips the "queue" option. After that, "92" is parsed as a standalone option which causes an "unrecognised option" error. I suggest a simple solution that fixes this problem (attached as "patch_01.txt"). -------------------------------------------------------------------------------- --- /usr/src/sbin/ipfw/dummynet.c.orig 2013-04-21 01:39:08.000000000 +0000 +++ /usr/src/sbin/ipfw/dummynet.c 2013-05-05 08:45:58.000000000 +0000 @@ -929,6 +929,7 @@ case TOK_QUEUE: mask->extra = ~0; *flags |= DN_HAVE_MASK; + ac++; av--; /* backtrack */ goto end_mask; case TOK_DSTIP: -------------------------------------------------------------------------------- Also, there is a more elegant solution (attached as "patch_02.txt"), but I'm not sure about it : -------------------------------------------------------------------------------- --- /usr/src/sbin/ipfw/dummynet.c.orig 2013-04-21 01:39:08.000000000 +0000 +++ /usr/src/sbin/ipfw/dummynet.c 2013-05-05 10:03:40.000000000 +0000 @@ -926,11 +926,6 @@ *flags |= DN_HAVE_MASK; goto end_mask; - case TOK_QUEUE: - mask->extra = ~0; - *flags |= DN_HAVE_MASK; - goto end_mask; - case TOK_DSTIP: mask->addr_type = 4; p32 = &mask->dst_ip; -------------------------------------------------------------------------------- Luigi, could you help, please? Can we remove the whole case-branch "TOK_QUEUE" here? If no, we can apply the first solution ("patch_01.txt"): it restores the previous behavior of the "ipfw" command line parsing. Thanks, Kirill P.S. This issue is also observed on other FreeBSD releases (e.g. 9.0 and 9.1). --047d7b6dc9a814b57404dbf6fc68 Content-Type: text/plain; charset=US-ASCII; name="patch_01.txt" Content-Disposition: attachment; filename="patch_01.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgc54wgp0 LS0tIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jLm9yaWcJMjAxMy0wNC0yMSAwMTozOTow OC4wMDAwMDAwMDAgKzAwMDAKKysrIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jCTIwMTMt MDUtMDUgMDg6NDU6NTguMDAwMDAwMDAwICswMDAwCkBAIC05MjksNiArOTI5LDcgQEAKIAkJCSAg ICBjYXNlIFRPS19RVUVVRToKIAkJCQkgICAgbWFzay0+ZXh0cmEgPSB+MDsKIAkJCQkgICAgKmZs YWdzIHw9IEROX0hBVkVfTUFTSzsKKwkJCQkgICAgYWMrKzsgYXYtLTsgLyogYmFja3RyYWNrICov CiAJCQkJICAgIGdvdG8gZW5kX21hc2s7CiAKIAkJCSAgICBjYXNlIFRPS19EU1RJUDoK --047d7b6dc9a814b57404dbf6fc68 Content-Type: text/plain; charset=US-ASCII; name="patch_02.txt" Content-Disposition: attachment; filename="patch_02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgc54zqq1 LS0tIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jLm9yaWcJMjAxMy0wNC0yMSAwMTozOTow OC4wMDAwMDAwMDAgKzAwMDAKKysrIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jCTIwMTMt MDUtMDUgMTA6MDM6NDAuMDAwMDAwMDAwICswMDAwCkBAIC05MjYsMTEgKzkyNiw2IEBACiAJCQkJ ICAgICpmbGFncyB8PSBETl9IQVZFX01BU0s7CiAJCQkJICAgIGdvdG8gZW5kX21hc2s7CiAKLQkJ CSAgICBjYXNlIFRPS19RVUVVRToKLQkJCQkgICAgbWFzay0+ZXh0cmEgPSB+MDsKLQkJCQkgICAg KmZsYWdzIHw9IEROX0hBVkVfTUFTSzsKLQkJCQkgICAgZ290byBlbmRfbWFzazsKLQogCQkJICAg IGNhc2UgVE9LX0RTVElQOgogCQkJCSAgICBtYXNrLT5hZGRyX3R5cGUgPSA0OwogCQkJCSAgICBw MzIgPSAmbWFzay0+ZHN0X2lwOwo= --047d7b6dc9a814b57404dbf6fc68-- From owner-freebsd-ipfw@FreeBSD.ORG Sun May 5 13:50:02 2013 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DD52AB0 for ; Sun, 5 May 2013 13:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E9B32E94 for ; Sun, 5 May 2013 13:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r45Do1WM072084 for ; Sun, 5 May 2013 13:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r45Do1Qb072083; Sun, 5 May 2013 13:50:01 GMT (envelope-from gnats) Date: Sun, 5 May 2013 13:50:01 GMT Message-Id: <201305051350.r45Do1Qb072083@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Luigi Rizzo Subject: Re: misc/178317: IPFW options need to specifed in specific order X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Luigi Rizzo List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 13:50:02 -0000 The following reply was made to PR kern/178317; it has been noted by GNATS. From: Luigi Rizzo To: Kirill Diduk Cc: bug-followup@FreeBSD.org, jens.kassel@aptilo.com, luigi@FreeBSD.org Subject: Re: misc/178317: IPFW options need to specifed in specific order Date: Sun, 5 May 2013 15:51:10 +0200 On Sun, May 05, 2013 at 02:35:44PM +0300, Kirill Diduk wrote: > Hello, > > The problem is related to the command line parsing implementation in > the file "sbin/ipfw/dummynet.c" (function "ipfw_config_pipe"). > > Consider the example: > > # ipfw pipe 3 config bw 1000000kbit/s mask src-ip 0xffffffff queue 92 > > When the "mask" token is encountered, it starts to parse FLOW_MASK > options ('src-ip", etc.), and skips the "queue" option. After that, > "92" is parsed as a standalone option which causes an "unrecognised > option" error. > > I suggest a simple solution that fixes this problem (attached as > "patch_01.txt"). > > -------------------------------------------------------------------------------- > --- /usr/src/sbin/ipfw/dummynet.c.orig 2013-04-21 01:39:08.000000000 +0000 > +++ /usr/src/sbin/ipfw/dummynet.c 2013-05-05 08:45:58.000000000 +0000 > @@ -929,6 +929,7 @@ > case TOK_QUEUE: > mask->extra = ~0; > *flags |= DN_HAVE_MASK; > + ac++; av--; /* backtrack */ > goto end_mask; > > case TOK_DSTIP: > -------------------------------------------------------------------------------- > > > Also, there is a more elegant solution (attached as "patch_02.txt"), > but I'm not sure about it : > > -------------------------------------------------------------------------------- > --- /usr/src/sbin/ipfw/dummynet.c.orig 2013-04-21 01:39:08.000000000 +0000 > +++ /usr/src/sbin/ipfw/dummynet.c 2013-05-05 10:03:40.000000000 +0000 > @@ -926,11 +926,6 @@ > *flags |= DN_HAVE_MASK; > goto end_mask; > > - case TOK_QUEUE: > - mask->extra = ~0; > - *flags |= DN_HAVE_MASK; > - goto end_mask; > - > case TOK_DSTIP: > mask->addr_type = 4; > p32 = &mask->dst_ip; > -------------------------------------------------------------------------------- > > > Luigi, could you help, please? Can we remove the whole case-branch > "TOK_QUEUE" here? > > If no, we can apply the first solution ("patch_01.txt"): it restores > the previous behavior of the "ipfw" command line parsing. i haven't touched this code in a while, so i will let it to your judgement. I suppose that any non-mask option (e.g. queue, plr, delay, ... ) should exit the flow-mask parsing. The second patch seems more appropriate. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sun May 5 17:02:04 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D9062DF; Sun, 5 May 2013 17:02:04 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABCF401; Sun, 5 May 2013 17:02:02 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UZ2NK-00058o-KU; Sun, 05 May 2013 21:05:26 +0400 Message-ID: <51869038.8060302@ipfw.ru> Date: Sun, 05 May 2013 21:00:40 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [patch] ipfw interface tracking and opcode rewriting References: <517801D3.5040502@FreeBSD.org> <20130424162349.GA8439@onelab2.iet.unipi.it> <51780C49.7000204@FreeBSD.org> <20130424190930.GA10395@onelab2.iet.unipi.it> <51783798.4020004@FreeBSD.org> <20130424202308.GA11146@onelab2.iet.unipi.it> In-Reply-To: <20130424202308.GA11146@onelab2.iet.unipi.it> Content-Type: multipart/mixed; boundary="------------080306070304010006020308" Cc: freebsd-ipfw@freebsd.org, luigi@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 17:02:04 -0000 This is a multi-part message in MIME format. --------------080306070304010006020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 25.04.2013 00:23, Luigi Rizzo wrote: > On Wed, Apr 24, 2013 at 11:50:48PM +0400, Alexander V. Chernikov wrote: >> On 24.04.2013 23:09, Luigi Rizzo wrote: >>> On Wed, Apr 24, 2013 at 08:46:01PM +0400, Alexander V. Chernikov wrote: >>>> On 24.04.2013 20:23, Luigi Rizzo wrote: > ... >>>> Well, actually I'm thinking of the next 2 steps: >>>> 1) making kernel rule header more compact (20 bytes instead of 48) and >>>> making it invisible for userland. >>>> This involves rule counters to be stored separately (and possibly as >>>> pcpu-based ones). >>>> 2) since ruleset is now nearly readonly and more or less compact we can >>>> try to store it in >>>> contiguous address space to optimize cache line usage. >>> certainly a worthwhile goal (also using gleb's new counters) >>> but i suspect that compacting rules are a second order effect. >>> I a bit skeptical they make a big difference on the in-kernel >>> version of ipfw. You might see some difference in the Well, direct tests with 1-2 rules shows results nearly within the limits of error with all 3 approaches. Production shows better results, but there are too many factors here.. >> My current numbers are ~5mpps of IPv4 forwarding with ipfw turned on (1 >> rule) for vlans over ixgbe, with 60% cpu usage (2xE5646). > > yes, but that means about 1mpps per core. the userspace version, > i have been told, reached 14.2mpps with one core when running > on netmap interfaces (single rule). So the impact of 20-30ns > per rule is much higher in the second case. > > Speaking of which -- it would be better to report performance > in terms of ns per packet (or per rule), rather than Mpps, because > it is much easier to compare results. Yes, this is true if you can scale linearly. With kernel-based forwarding this is not the case, actually speed is more or less constant (1mpps per core), and (nearly) all my patches are related to decrease locking (e.g. scaling, not code optimization). > Saying "20% better" or "300Kpps more" requires a lot more > context to understand how much things improved. > >> For lagg with 2x ixgbe it is ~7mpps with the same 60% usage. >> (And, say, 70% of CPU usage on our production is ipfw, despite low >> number of rules). >>> userspace version, which runs on top of netmap. >> We are preparing to move forward in this direction (and thinking of >> 20-30mpps as our goal). >> (And I hope some changes of kernel-based version can migrate to userland >> one :)) > > yes, my goal is to have a single source tree that builds both in kernel > and userspace. The diffs are very small, I just have a little bit > of glue code to hook the packet path and the control socket. Yep. While such changes may be not significant in kernel-based ipfw version, there is netmap-based one. Personally I think that userland ipfw definitely should have some interface tracking anyway (since one of the fastest/easiest way to speed up forwarding is to retain control plain the same, while making forwarding plane configurable based on routing socket messages) and having this functionality can help kernel a bit (ipfw nat interface tracking, for example) Opcode rewriting can help in keeping ABI the same while changing everything inside kernel. It can be currently used to eliminate O_IP6_SRC_ME, O_IP6_DST_ME, O_IPPRECEDENCE and O_IPTOS opcodes, The last one splits kernel/user ip_fw rule headers and prepares interface counters to be switched to per-cpu (and here there is definitely visible performance difference even in kernel-based ipfw). What do you think? > > cheers > luigi > --------------080306070304010006020308 Content-Type: text/plain; charset=UTF-8; name="ipfw_rule_abi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw_rule_abi.diff" Index: sys/netinet/ip_fw.h =================================================================== --- sys/netinet/ip_fw.h (revision 250230) +++ sys/netinet/ip_fw.h (working copy) @@ -468,6 +468,7 @@ typedef struct _ipfw_insn_icmp6 { */ } ipfw_insn_icmp6; +#ifndef _KERNEL /* * Here we have the structure representing an ipfw rule. * @@ -489,10 +490,6 @@ typedef struct _ipfw_insn_icmp6 { * (at ACTION_PTR(r)) MUST be O_LOG * + if a rule has an "altq" option, it comes after "log" * + if a rule has an O_TAG option, it comes after "log" and "altq" - * - * NOTE: we use a simple linked list of rules because we never need - * to delete a rule without scanning the list. We do not use - * queue(3) macros for portability and readability. */ struct ip_fw { @@ -521,6 +518,7 @@ struct ip_fw { #define RULESIZE(rule) (sizeof(struct ip_fw) + \ ((struct ip_fw *)(rule))->cmd_len * 4 - 4) +#endif #if 1 // should be moved to in.h /* Index: sys/netpfil/ipfw/ip_fw2.c =================================================================== --- sys/netpfil/ipfw/ip_fw2.c (revision 250246) +++ sys/netpfil/ipfw/ip_fw2.c (working copy) @@ -2637,8 +2637,7 @@ vnet_ipfw_init(const void *unused) chain->n_rules = 1; chain->static_len = sizeof(struct ip_fw); chain->map = malloc(sizeof(struct ip_fw *), M_IPFW, M_WAITOK | M_ZERO); - if (chain->map) - rule = malloc(chain->static_len, M_IPFW, M_WAITOK | M_ZERO); + rule = ipfw_alloc_rule(chain, sizeof(struct ip_fw)); /* Set initial number of tables */ V_fw_tables_max = default_fw_tables; Index: sys/netpfil/ipfw/ip_fw_private.h =================================================================== --- sys/netpfil/ipfw/ip_fw_private.h (revision 250230) +++ sys/netpfil/ipfw/ip_fw_private.h (working copy) @@ -212,6 +212,63 @@ VNET_DECLARE(int, autoinc_step); VNET_DECLARE(unsigned int, fw_tables_max); #define V_fw_tables_max VNET(fw_tables_max) +#ifdef _KERNEL +typedef struct ip_fw_cntr { + uint64_t pcnt; /* Packet counter */ + uint64_t bcnt; /* Byte counter */ + uint32_t timestamp; /* tv_sec of last match */ +} ip_fw_cntr; + +/* + * Here we have the structure representing an ipfw rule. + * + * It starts with a general area (with link fields and counters) + * followed by an array of one or more instructions, which the code + * accesses as an array of 32-bit values. + * + * Given a rule pointer r: + * + * r->cmd is the start of the first instruction. + * ACTION_PTR(r) is the start of the first action (things to do + * once a rule matched). + * + * When assembling instruction, remember the following: + * + * + if a rule has a "keep-state" (or "limit") option, then the + * first instruction (at r->cmd) MUST BE an O_PROBE_STATE + * + if a rule has a "log" option, then the first action + * (at ACTION_PTR(r)) MUST be O_LOG + * + if a rule has an "altq" option, it comes after "log" + * + if a rule has an O_TAG option, it comes after "log" and "altq" + * + * NOTE: we use a simple linked list of rules because we never need + * to delete a rule without scanning the list. We do not use + * queue(3) macros for portability and readability. + */ + +struct ip_fw { + uint16_t act_ofs; /* offset of action in 32-bit units */ + uint16_t cmd_len; /* # of 32-bit words in cmd */ + uint16_t rulenum; /* rule number */ + uint8_t set; /* rule set (0..31) */ +#define RESVD_SET 31 /* set for default and persistent rules */ + uint8_t _pad; /* padding */ + struct ip_fw_cntr *cntr; /* Pointer to rule counters */ + struct ip_fw *x_next; /* linked list of rules */ + struct ip_fw *next_rule; /* ptr to next [skipto] rule */ + uint32_t id; /* rule id */ + + ipfw_insn cmd[1]; /* storage for commands */ +}; + +/* Kernel rule length */ +#define RULESIZE(rule) (sizeof(struct ip_fw) + \ + ((struct ip_fw *)(rule))->cmd_len * 4 - 4) + +#define ACTION_PTR(rule) \ + (ipfw_insn *)( (u_int32_t *)((rule)->cmd) + ((rule)->act_ofs) ) +#endif + struct ip_fw_chain { struct ip_fw *rules; /* list of rules */ struct ip_fw *reap; /* list of rules to reap */ @@ -238,9 +295,9 @@ struct sockopt; /* used by tcp_var.h */ /* Macro for working with various counters */ #define IPFW_INC_RULE_COUNTER(_cntr, _bytes) do { \ - (_cntr)->pcnt++; \ - (_cntr)->bcnt += _bytes; \ - (_cntr)->timestamp = time_uptime; \ + (_cntr)->cntr->pcnt++; \ + (_cntr)->cntr->bcnt += _bytes; \ + (_cntr)->cntr->timestamp = time_uptime; \ } while (0) #define IPFW_INC_DYN_COUNTER(_cntr, _bytes) do { \ @@ -249,9 +306,9 @@ struct sockopt; /* used by tcp_var.h */ } while (0) #define IPFW_ZERO_RULE_COUNTER(_cntr) do { \ - (_cntr)->pcnt = 0; \ - (_cntr)->bcnt = 0; \ - (_cntr)->timestamp = 0; \ + (_cntr)->cntr->pcnt = 0; \ + (_cntr)->cntr->bcnt = 0; \ + (_cntr)->cntr->timestamp = 0; \ } while (0) #define IPFW_ZERO_DYN_COUNTER(_cntr) do { \ @@ -298,6 +355,7 @@ int ipfw_find_rule(struct ip_fw_chain *chain, uint int ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule); int ipfw_ctl(struct sockopt *sopt); int ipfw_chk(struct ip_fw_args *args); +struct ip_fw *ipfw_alloc_rule(struct ip_fw_chain *chain, size_t rulesize); void ipfw_reap_rules(struct ip_fw *head); /* In ip_fw_table.c */ Index: sys/netpfil/ipfw/ip_fw_sockopt.c =================================================================== --- sys/netpfil/ipfw/ip_fw_sockopt.c (revision 250230) +++ sys/netpfil/ipfw/ip_fw_sockopt.c (working copy) @@ -73,6 +73,27 @@ MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct * static variables followed by global ones (none in this file) */ +struct ip_fw * +ipfw_alloc_rule(struct ip_fw_chain *chain, size_t rulesize) +{ + struct ip_fw *rule; + struct ip_fw_cntr *cntr; + + rule = malloc(rulesize, M_IPFW, M_WAITOK | M_ZERO); + cntr = malloc(sizeof(struct ip_fw_cntr), M_IPFW, M_WAITOK | M_ZERO); + rule->cntr = cntr; + + return (rule); +} + +static void +free_rule(struct ip_fw *rule) +{ + + free(rule->cntr, M_IPFW); + free(rule, M_IPFW); +} + /* * Find the smallest rule >= key, id. * We could use bsearch but it is so simple that we code it directly @@ -158,20 +179,27 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip struct ip_fw *rule; int i, l, insert_before; struct ip_fw **map; /* the new array of pointers */ + struct ip_fw_cntr *cntr; if (chain->rules == NULL || input_rule->rulenum > IPFW_DEFAULT_RULE-1) return (EINVAL); l = RULESIZE(input_rule); - rule = malloc(l, M_IPFW, M_WAITOK | M_ZERO); + rule = ipfw_alloc_rule(chain, l); /* get_map returns with IPFW_UH_WLOCK if successful */ map = get_map(chain, 1, 0 /* not locked */); if (map == NULL) { - free(rule, M_IPFW); - return ENOSPC; + free_rule(rule); + return (ENOSPC); } + /* Save old data */ + cntr = rule->cntr; + bcopy(input_rule, rule, l); + + rule->cntr = cntr; + /* clear fields not settable from userland */ rule->x_next = NULL; rule->next_rule = NULL; @@ -220,7 +248,7 @@ ipfw_reap_rules(struct ip_fw *head) while ((rule = head) != NULL) { head = head->x_next; - free(rule, M_IPFW); + free_rule(rule); } } @@ -830,7 +858,6 @@ bad_size: return EINVAL; } - /* * Translation of requests for compatibility with FreeBSD 7.2/8. * a static variable tells us if we have an old client from userland, @@ -859,15 +886,44 @@ struct ip_fw7 { ipfw_insn cmd[1]; /* storage for commands */ }; - int convert_rule_to_7(struct ip_fw *rule); -int convert_rule_to_8(struct ip_fw *rule); - -#ifndef RULESIZE7 -#define RULESIZE7(rule) (sizeof(struct ip_fw7) + \ +#define RULESIZE7(rule) (sizeof(struct ip_fw7) + \ ((struct ip_fw7 *)(rule))->cmd_len * 4 - 4) -#endif +/* Size difference between FreeBSD7 userland and kernel */ +#define RULEDIFF7 (sizeof(struct ip_fw7) - sizeof(struct ip_fw)) +struct ip_fw8 { + struct ip_fw *x_next; /* linked list of rules */ + struct ip_fw *next_rule; /* ptr to next [skipto] rule */ + /* 'next_rule' is used to pass up 'set_disable' status */ + + uint16_t act_ofs; /* offset of action in 32-bit units */ + uint16_t cmd_len; /* # of 32-bit words in cmd */ + uint16_t rulenum; /* rule number */ + uint8_t set; /* rule set (0..31) */ +#define RESVD_SET 31 /* set for default and persistent rules */ + uint8_t _pad; /* padding */ + uint32_t id; /* rule id */ + + /* These fields are present in all rules. */ + uint64_t pcnt; /* Packet counter */ + uint64_t bcnt; /* Byte counter */ + uint32_t timestamp; /* tv_sec of last match */ + + ipfw_insn cmd[1]; /* storage for commands */ +}; + +#define RULESIZE8(rule) (sizeof(struct ip_fw8) + \ + ((struct ip_fw8 *)(rule))->cmd_len * 4 - 4) + +/* Size difference between FreeBSD8 userland and kernel */ +#define RULEDIFF8 (sizeof(struct ip_fw8) - sizeof(struct ip_fw)) + +static int convert_rule_from_7(void *src, struct ip_fw *rule); +static int convert_rule_to_7(struct ip_fw *rule, void *dst_rule, size_t *psize); +static int convert_rule_from_8(void *src, struct ip_fw *rule); +static int convert_rule_to_8(struct ip_fw *rule, void *dst_rule, size_t *psize); + /* * Copy the static and dynamic rules to the supplied buffer * and return the amount of space actually used. @@ -878,56 +934,21 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf { char *bp = buf; char *ep = bp + space; - struct ip_fw *rule, *dst; + struct ip_fw *rule; int l, i; - time_t boot_seconds; - boot_seconds = boottime.tv_sec; for (i = 0; i < chain->n_rules; i++) { rule = chain->map[i]; - if (is7) { - /* Convert rule to FreeBSd 7.2 format */ - l = RULESIZE7(rule); - if (bp + l + sizeof(uint32_t) <= ep) { - int error; - bcopy(rule, bp, l + sizeof(uint32_t)); - error = convert_rule_to_7((struct ip_fw *) bp); - if (error) - return 0; /*XXX correct? */ - /* - * XXX HACK. Store the disable mask in the "next" - * pointer in a wild attempt to keep the ABI the same. - * Why do we do this on EVERY rule? - */ - bcopy(&V_set_disable, - &(((struct ip_fw7 *)bp)->next_rule), - sizeof(V_set_disable)); - if (((struct ip_fw7 *)bp)->timestamp) - ((struct ip_fw7 *)bp)->timestamp += boot_seconds; - bp += l; - } - continue; /* go to next rule */ - } - - /* normal mode, don't touch rules */ - l = RULESIZE(rule); - if (bp + l > ep) { /* should not happen */ - printf("overflow dumping static rules\n"); - break; - } - dst = (struct ip_fw *)bp; - bcopy(rule, dst, l); - /* - * XXX HACK. Store the disable mask in the "next" - * pointer in a wild attempt to keep the ABI the same. - * Why do we do this on EVERY rule? - */ - bcopy(&V_set_disable, &dst->next_rule, sizeof(V_set_disable)); - if (dst->timestamp) - dst->timestamp += boot_seconds; + if (is7) + l = convert_rule_to_7(rule, bp, &space); + else + l = convert_rule_to_8(rule, bp, &space); + if (l == 0) + return (0); bp += l; } + ipfw_get_dynamic(chain, &bp, ep); /* protected by the dynamic lock */ return (bp - (char *)buf); } @@ -999,6 +1020,12 @@ ipfw_ctl(struct sockopt *sopt) int len = 0, want; size = chain->static_len; + /* + * Currently the only (size-related) differece between + * kernel and 7/8 userland are rule headers. + * Calculate size change depending on version. + */ + size += chain->n_rules * (is7 ? RULEDIFF7 : RULEDIFF8); size += ipfw_dyn_len(); if (size >= sopt->sopt_valsize) break; @@ -1023,9 +1050,14 @@ ipfw_ctl(struct sockopt *sopt) break; case IP_FW_ADD: - rule = malloc(RULE_MAXSIZE, M_TEMP, M_WAITOK); - error = sooptcopyin(sopt, rule, RULE_MAXSIZE, - sizeof(struct ip_fw7) ); + buf = malloc(RULE_MAXSIZE * 2, M_TEMP, M_WAITOK); + rule = (struct ip_fw *)((char *)buf + RULE_MAXSIZE); + /* + * Note that ip_fw7 has the smallest size between all other + * userland rule structures. + */ + error = sooptcopyin(sopt, buf, RULE_MAXSIZE, + sizeof(struct ip_fw7)); /* * If the size of commands equals RULESIZE7 then we assume @@ -1037,32 +1069,33 @@ ipfw_ctl(struct sockopt *sopt) * the ipfw binary may crash or loop infinitly... */ if (sopt->sopt_valsize == RULESIZE7(rule)) { - is7 = 1; - error = convert_rule_to_8(rule); - if (error) - return error; - if (error == 0) - error = check_ipfw_struct(rule, RULESIZE(rule)); + is7 = 1; + error = convert_rule_from_7(buf, rule); } else { - is7 = 0; + is7 = 0; + error = convert_rule_from_8(buf, rule); + } + if (error == 0) - error = check_ipfw_struct(rule, sopt->sopt_valsize); + error = check_ipfw_struct(rule, RULESIZE(rule)); + + if (error != 0) + return (error); + + /* locking is done within ipfw_add_rule() */ + error = ipfw_add_rule(chain, rule); + if (!error && sopt->sopt_dir == SOPT_GET) { + if (is7) + size = convert_rule_to_7(rule, buf, NULL); + else + size = convert_rule_to_8(rule, buf, NULL); + + if (size == 0) + return (EINVAL); + + error = sooptcopyout(sopt, buf, size); } - if (error == 0) { - /* locking is done within ipfw_add_rule() */ - error = ipfw_add_rule(chain, rule); - size = RULESIZE(rule); - if (!error && sopt->sopt_dir == SOPT_GET) { - if (is7) { - error = convert_rule_to_7(rule); - size = RULESIZE7(rule); - if (error) - return error; - } - error = sooptcopyout(sopt, rule, size); - } - } - free(rule, M_TEMP); + free(buf, M_TEMP); break; case IP_FW_DEL: @@ -1327,47 +1360,121 @@ ipfw_ctl(struct sockopt *sopt) #undef RULE_MAXSIZE } +/* + * Functions to convert rules between FreeBSD 7 userland and kernel. + * No input validation (except general size checking) is done here. + */ -#define RULE_MAXSIZE (256*sizeof(u_int32_t)) +#define _COPYFIELD(_f) rule8->_f = rule->_f +static int +convert_rule_to_8(struct ip_fw *rule, void *dst_rule, size_t *psize) +{ + struct ip_fw8 *rule8; + size_t len; -/* Functions to convert rules 7.2 <==> 8.0 */ -int -convert_rule_to_7(struct ip_fw *rule) + if (psize != NULL && *psize < RULESIZE(rule) + RULEDIFF8) + return (0); + + rule8 = (struct ip_fw8 *)dst_rule; + memset(rule8, 0, sizeof(struct ip_fw8)); + + _COPYFIELD(act_ofs); + _COPYFIELD(cmd_len); + _COPYFIELD(rulenum); + _COPYFIELD(set); + _COPYFIELD(id); + + /* + * Store the disable mask in the "next_rule" field. + * Why do we do this on EVERY rule? + */ + memcpy(&rule8->next_rule, &V_set_disable, sizeof(V_set_disable)); + if (rule8->timestamp > 0) + rule8->timestamp += boottime.tv_sec; + + /* Export counters */ + if (rule->cntr != NULL) { + rule8->bcnt = rule->cntr->bcnt; + rule8->pcnt = rule->cntr->pcnt; + rule8->timestamp = rule->cntr->timestamp; + } + + memcpy(rule8->cmd, rule->cmd, rule->cmd_len * sizeof(uint32_t)); + + len = RULESIZE8(rule8); + if (psize != NULL) + *psize -= len; + + return (len); +} +#undef _COPYFIELD + +#define _COPYFIELD(_f) rule->_f = rule8->_f +static int +convert_rule_from_8(void *src, struct ip_fw *rule) { - /* Used to modify original rule */ - struct ip_fw7 *rule7 = (struct ip_fw7 *)rule; - /* copy of original rule, version 8 */ - struct ip_fw *tmp; + struct ip_fw8 *rule8; - /* Used to copy commands */ + rule8 = (struct ip_fw8 *)src; + memset(rule, 0, sizeof(struct ip_fw)); + + _COPYFIELD(act_ofs); + _COPYFIELD(cmd_len); + _COPYFIELD(rulenum); + _COPYFIELD(set); + _COPYFIELD(id); + + memcpy(rule->cmd, rule8->cmd, rule8->cmd_len * sizeof(uint32_t)); + + return (0); +} +#undef _COPYFIELD + + +static int +convert_rule_to_7(struct ip_fw *rule, void *dst_rule, size_t *psize) +{ ipfw_insn *ccmd, *dst; int ll = 0, ccmdlen = 0; + struct ip_fw7 *rule7; + size_t len; - tmp = malloc(RULE_MAXSIZE, M_TEMP, M_NOWAIT | M_ZERO); - if (tmp == NULL) { - return 1; //XXX error - } - bcopy(rule, tmp, RULE_MAXSIZE); + if (psize != NULL && *psize < RULESIZE(rule) + RULEDIFF7) + return (0); + rule7 = (struct ip_fw7 *)dst_rule; + memset(rule7, 0, sizeof(struct ip_fw7)); + /* Copy fields */ - rule7->_pad = tmp->_pad; - rule7->set = tmp->set; - rule7->rulenum = tmp->rulenum; - rule7->cmd_len = tmp->cmd_len; - rule7->act_ofs = tmp->act_ofs; - rule7->next_rule = (struct ip_fw7 *)tmp->next_rule; - rule7->next = (struct ip_fw7 *)tmp->x_next; - rule7->cmd_len = tmp->cmd_len; - rule7->pcnt = tmp->pcnt; - rule7->bcnt = tmp->bcnt; - rule7->timestamp = tmp->timestamp; + rule7->_pad = rule->_pad; + rule7->set = rule->set; + rule7->rulenum = rule->rulenum; + rule7->cmd_len = rule->cmd_len; + rule7->act_ofs = rule->act_ofs; + rule7->next_rule = (struct ip_fw7 *)rule->next_rule; + rule7->next = (struct ip_fw7 *)rule->x_next; + rule7->cmd_len = rule->cmd_len; + if (rule->cntr != NULL) { + rule7->pcnt = rule->cntr->pcnt; + rule7->bcnt = rule->cntr->bcnt; + rule7->timestamp = rule->cntr->timestamp; + } + + /* + * Store the disable mask in the "next" + * Why do we do this on EVERY rule? + */ + memcpy(&rule7->next_rule, &V_set_disable, sizeof(V_set_disable)); + if (rule7->timestamp > 0) + rule7->timestamp += boottime.tv_sec; + /* Copy commands */ - for (ll = tmp->cmd_len, ccmd = tmp->cmd, dst = rule7->cmd ; - ll > 0 ; ll -= ccmdlen, ccmd += ccmdlen, dst += ccmdlen) { + for (ll = rule->cmd_len, ccmd = rule->cmd, dst = rule7->cmd; ll > 0; + ll -= ccmdlen, ccmd += ccmdlen, dst += ccmdlen) { ccmdlen = F_LEN(ccmd); - bcopy(ccmd, dst, F_LEN(ccmd)*sizeof(uint32_t)); + memcpy(dst, ccmd, F_LEN(ccmd) * sizeof(uint32_t)); if (dst->opcode > O_NAT) /* O_REASS doesn't exists in 7.2 version, so @@ -1378,37 +1485,43 @@ ipfw_ctl(struct sockopt *sopt) if (ccmdlen > ll) { printf("ipfw: opcode %d size truncated\n", ccmd->opcode); - return EINVAL; + return (EINVAL); } } - free(tmp, M_TEMP); - return 0; + len = RULESIZE7(rule7); + if (psize != NULL) + *psize -= len; + + return (len); } -int -convert_rule_to_8(struct ip_fw *rule) +static int +convert_rule_from_7(void *src, struct ip_fw *rule) { - /* Used to modify original rule */ - struct ip_fw7 *rule7 = (struct ip_fw7 *) rule; - /* Used to copy commands */ ipfw_insn *ccmd, *dst; int ll = 0, ccmdlen = 0; + struct ip_fw7 *rule7; + + rule7 = (struct ip_fw7 *)src; + memset(rule, 0, sizeof(struct ip_fw)); - /* Copy of original rule */ - struct ip_fw7 *tmp = malloc(RULE_MAXSIZE, M_TEMP, M_NOWAIT | M_ZERO); - if (tmp == NULL) { - return 1; //XXX error - } + rule->_pad = rule7->_pad; + rule->set = rule7->set; + rule->rulenum = rule7->rulenum; + rule->cmd_len = rule7->cmd_len; + rule->act_ofs = rule7->act_ofs; + rule->next_rule = (struct ip_fw *)rule7->next_rule; + rule->x_next = (struct ip_fw *)rule7->next; + rule->cmd_len = rule7->cmd_len; + rule->id = 0; /* XXX see if is ok = 0 */ - bcopy(rule7, tmp, RULE_MAXSIZE); - - for (ll = tmp->cmd_len, ccmd = tmp->cmd, dst = rule->cmd ; + for (ll = rule7->cmd_len, ccmd = rule7->cmd, dst = rule->cmd ; ll > 0 ; ll -= ccmdlen, ccmd += ccmdlen, dst += ccmdlen) { ccmdlen = F_LEN(ccmd); - bcopy(ccmd, dst, F_LEN(ccmd)*sizeof(uint32_t)); + memcpy(dst, ccmd, F_LEN(ccmd) * sizeof(uint32_t)); if (dst->opcode > O_NAT) /* O_REASS doesn't exists in 7.2 version, so @@ -1419,25 +1532,11 @@ ipfw_ctl(struct sockopt *sopt) if (ccmdlen > ll) { printf("ipfw: opcode %d size truncated\n", ccmd->opcode); - return EINVAL; + return (EINVAL); } } - rule->_pad = tmp->_pad; - rule->set = tmp->set; - rule->rulenum = tmp->rulenum; - rule->cmd_len = tmp->cmd_len; - rule->act_ofs = tmp->act_ofs; - rule->next_rule = (struct ip_fw *)tmp->next_rule; - rule->x_next = (struct ip_fw *)tmp->next; - rule->cmd_len = tmp->cmd_len; - rule->id = 0; /* XXX see if is ok = 0 */ - rule->pcnt = tmp->pcnt; - rule->bcnt = tmp->bcnt; - rule->timestamp = tmp->timestamp; - - free (tmp, M_TEMP); - return 0; + return (0); } /* end of file */ --------------080306070304010006020308-- From owner-freebsd-ipfw@FreeBSD.ORG Mon May 6 10:10:01 2013 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7188A13E for ; Mon, 6 May 2013 10:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 638853F6 for ; Mon, 6 May 2013 10:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46AA1UK011990 for ; Mon, 6 May 2013 10:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46AA1d0011989; Mon, 6 May 2013 10:10:01 GMT (envelope-from gnats) Date: Mon, 6 May 2013 10:10:01 GMT Message-Id: <201305061010.r46AA1d0011989@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: Kirill Diduk Subject: Re: kern/178317: [ipfw] ipfw options need to specifed in specific order X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Kirill Diduk List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 10:10:01 -0000 The following reply was made to PR kern/178317; it has been noted by GNATS. From: Kirill Diduk To: bug-followup@FreeBSD.org, jens.kassel@aptilo.com Cc: Subject: Re: kern/178317: [ipfw] ipfw options need to specifed in specific order Date: Mon, 6 May 2013 13:06:11 +0300 --001a11c2bd12aaf3a904dc09d903 Content-Type: text/plain; charset=ISO-8859-1 OK, here is the final solution (attached as "patch.txt"). I reviewed it once again. Now, someone who has write-access to the FreeBSD svn, may have to apply it. Thanks, Kirill --001a11c2bd12aaf3a904dc09d903 Content-Type: text/plain; charset=US-ASCII; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgdh83rh0 LS0tIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jLm9yaWcJMjAxMy0wNC0yMSAwMTozOTow OC4wMDAwMDAwMDAgKzAwMDAKKysrIC91c3Ivc3JjL3NiaW4vaXBmdy9kdW1teW5ldC5jCTIwMTMt MDUtMDUgMTA6MDM6NDAuMDAwMDAwMDAwICswMDAwCkBAIC05MjYsMTEgKzkyNiw2IEBACiAJCQkJ ICAgICpmbGFncyB8PSBETl9IQVZFX01BU0s7CiAJCQkJICAgIGdvdG8gZW5kX21hc2s7CiAKLQkJ CSAgICBjYXNlIFRPS19RVUVVRToKLQkJCQkgICAgbWFzay0+ZXh0cmEgPSB+MDsKLQkJCQkgICAg KmZsYWdzIHw9IEROX0hBVkVfTUFTSzsKLQkJCQkgICAgZ290byBlbmRfbWFzazsKLQogCQkJICAg IGNhc2UgVE9LX0RTVElQOgogCQkJCSAgICBtYXNrLT5hZGRyX3R5cGUgPSA0OwogCQkJCSAgICBw MzIgPSAmbWFzay0+ZHN0X2lwOwo= --001a11c2bd12aaf3a904dc09d903-- From owner-freebsd-ipfw@FreeBSD.ORG Mon May 6 11:06:47 2013 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AE629B4 for ; Mon, 6 May 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7F2A02 for ; Mon, 6 May 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46B6lWo023822 for ; Mon, 6 May 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46B6lQI023820 for freebsd-ipfw@FreeBSD.org; Mon, 6 May 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 May 2013 11:06:47 GMT Message-Id: <201305061106.r46B6lQI023820@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/169206 ipfw [ipfw] ipfw does not flush entries in table o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed May 8 09:51:05 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D318489C for ; Wed, 8 May 2013 09:51:05 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe11.ukr.net (ffe11.ukr.net [195.214.192.31]) by mx1.freebsd.org (Postfix) with ESMTP id 90B51221 for ; Wed, 8 May 2013 09:51:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=yReWeKhTHkoTawNEeF9loeRWqb7ewyK/ju3oVGr5NpQ=; b=PvALn5F9J1pKFdCCv4jPC0KCSZK4Z0jnnMYW21C3o5Q13sMtwkcoSl/Er2aFpklt2p28T+8RQ7USKfIWujv5Ol2X7GRZ5DUAVapxy2lReQ8+Ovkj9DLFaNPGmMc42ZMN0k7uV5her0Smby3zAMhsCA/g1kCINcrwMPwVogBAsc4=; Received: from mail by ffe11.ukr.net with local ID 1Ua0mb-000Lvn-Cn for freebsd-ipfw@freebsd.org; Wed, 08 May 2013 12:35:33 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="utf-8" Subject: ipfw nat show? To: freebsd-ipfw@freebsd.org From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <82656.1368005733.3214182123969773568@ffe11.ukr.net> Date: Wed, 08 May 2013 12:35:33 +0300 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:51:05 -0000 Hi, Recently, I have switched from pf to ipfw. All works fine, except nat statistic. When I type ipfw nat show or ipfw nat 1 show nothing is on output. FreeBSD xxx.com 9.1-STABLE FreeBSD 9.1-STABLE #0: Tue Apr 30 22:03:16 EEST 2013 wishmaster@xxx.com:/usr/obj/usr/src/sys/MY6 i386 Kernel with VIMAGE option. On another machine with -CURRENT all fine. Is it bug? From owner-freebsd-ipfw@FreeBSD.ORG Thu May 9 08:56:55 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28C1AF9E; Thu, 9 May 2013 08:56:55 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id E7FB79BA; Thu, 9 May 2013 08:56:54 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id b11so5008788iee.37 for ; Thu, 09 May 2013 01:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YInPpZH2hSttC0xXAF4+fwiDjuZCVGRy37zK2ss9Rnc=; b=shQmiR3tgmB8kmtmL3betv0SG58xmLNTbUiRT6dXCe9QDZ61aNhxnLOAGyHyU1qHnD pUJOe4r/IEsysgSo4BsuCPfCVk/5ySY1sPcDGCeK/Iiw1kUq9/XSa0NKnVAgU3nZjTdt gdc3VHiTWNMNZ/43VLGrIjXzN6A+exILtFNXydNEgVJkHtz58FlsIl48OKHWm15Aybms Q667AI0HILTbrtMIIhYOehI1sgj9nnupC1j1VepQlxy/fppuQJp2VTahQhXxYjKbh9Ut e5tNr8/qMM1DRypgIHTANkN3zkyIaV/HRjNAl5ewGOlxLxMFffOw1+Px7S8LDZ+0druR S/2A== MIME-Version: 1.0 X-Received: by 10.50.140.73 with SMTP id re9mr7813550igb.59.1368089814647; Thu, 09 May 2013 01:56:54 -0700 (PDT) Received: by 10.42.189.4 with HTTP; Thu, 9 May 2013 01:56:54 -0700 (PDT) In-Reply-To: <20130417133637.W56386@sola.nimnet.asn.au> References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> <20130417133637.W56386@sola.nimnet.asn.au> Date: Thu, 9 May 2013 10:56:54 +0200 Message-ID: Subject: Re: Problems with ipfw/natd and axe(4) From: Spil Oss To: freebsd-ipfw@freebsd.org, current Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 08:56:55 -0000 Hi all, So I bought another AX88772B part, this time an Edimax UE-4208 and it behaved exactly like the no-name part I bought on eBay. Looking at YongHyeong's feedback on his engineering sample I decided to revert back to 9.1-RELEASE and try again, this works like expected. (see my post "Problems with axe(4) and checksum offloading" thread started Apr 7 in freebsd-current@) So somewhere between 9.1-RELEASE and 10-CURRENT r248351 there's a regression that breaks this. Any pointers on getting this to work? Kind regards, Spil. On Wed, Apr 17, 2013 at 7:03 AM, Ian Smith wrote: > On Tue, 16 Apr 2013 20:52:05 +0200, Spil Oss wrote: > > Hi all, > > > > If I disable checksum offloading on the NIC I do the tcpdump on, then I > > assume that the checksum-check will provide accurate results? > > It certainly should. > > > With checksum disabled, I see that the checksum is incorrect when the > > client does not respond to the SYN,ACK, and correct when it does. > > I'm having trouble fully parsing that. > > Using 'tcpdump -vr ue0-ssh-fail.pcap | less -S' shows these incorrect > checksums alright; before adding -v I'd only noticed 172.17.2.1 sending > SYNs and clearly not responding to 172.17.2.111's SYN/ACKs. > > Since it works ok with the divert rule bypassed - presumably still with > tx/rxcsum enabled - then it seems that (surprise!) Luigi picked the > issue being in natd / divert socket handling. > > > Out of curiousity I tried with pf as well and it behaves the same. > > Can't comment on that. What's not clear is why the NIC "doesn't work" > (symptoms?) with -txcsum -rxcsum. With the 'fail' pcap it seems the > received checksum from the client SYN is ok on capture, and the server > is responding with SYN/ACK (with mangled cksum), but the rxcsum must be > ok after natd, so maybe it's only -txcsum needed? Might that work? > > Sorry, I'm just bouncing around on what I can see from here and could be > missing something someone else might find obvious, I'm just an amateur.. > > > On Mon, Apr 15, 2013 at 9:04 PM, Spil Oss wrote: > > > > Network dumps as promised > > > On 172.17.2.1: > > > tcpdump -p -i bridge0 -s 0 -w ssh-fail.pcap host not 172.17.2.167 > > You didn't post that one; I assume it showed the bad cksums back from > 172.17.2.111? ie that the SYN/ACK packet make it to the client's > interface, but was dropped for its bad cksum on the client side? > > > > From 172.17.2.1 I ran > > > telnet 172.17.2.111/157 22 > > > In Wireshark I trimmed the capture a bit further with expression > > > 'not stp and not http' > > > > > > Initial setup (ue0 ext, re0 int, rule 10 to allow ssh) > > > -> ue0-ssh-success.pcap > > > Removed rule 10 > > > -> ue0-ssh-fail.pcap > > > Switched re0 and ue0, default ruleset (without 10) > > > -> re0-ssh-success.pcap > > > > > > According to YungHyeong the sample ASIX NIC he has works normally when > > > checksumming is disabled. > > I guess trying another of the same NIC is the only way to rule out a > faulty unit? I'm having similarly frustrating issues with a cardbus > USB2 card, unrelated but proving just as indeterminate .. > > [..] > > > >> Does anyone know whether this is an issue with libalias(3) generally - > > >> in which case using nat instead of divert shouldn't help - or just with > > >> natd in particular? > > Question still stands .. I could redo that rc.firewall patch for nat in > 'simple' but if the problem is with libalias(3) it won't help with this. > > cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu May 9 11:03:58 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14682BF0 for ; Thu, 9 May 2013 11:03:58 +0000 (UTC) (envelope-from prvs=18414728a6=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id E7940F5A for ; Thu, 9 May 2013 11:03:57 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50001988504.msg; Thu, 09 May 2013 04:03:44 -0700 X-Spam-Processed: mail02.amotive.com, Thu, 09 May 2013 04:03:44 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=18414728a6=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-ipfw@freebsd.org Date: Thu, 9 May 2013 04:02:44 -0700 To: freebsd-ipfw From: CAD Americas Subject: AutoCAD and Electrical Evangelists Lynn Allen and Randy Brunette Speak at CAD Americas Message-ID: <8f646b9deb0f543c57d7622fc5b996ed@agave.cadamericas.com> X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 62397c5b-82bd-c7cf-c8f9-518b82ef8227 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: CAD Americas List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 11:03:58 -0000 CAD AMERICAS TECHNICAL SESSSIONS NOW ONLINE: Attend CAD Americas Training D= ays to learn how to optimize your CAD tools=C2=A0=0A=C2=A0=0A=0A=0ADiscover= new productivity techniques that are certain to improve your everyday draw= ing life. Lynn Allen, Autodesk Technical Evangelist, Cadalyst columnist and= author, will walk you through a whirlwind of tips and tricks you can put t= o use immediately.=0A=0ALynn Allen Autodesk Evangelist More=0A=C2=A0=0A=C2= =A0=0A=0A=0AExplore new CAD Management techniques with Robert Green, a well= known author, instructor and consultant. Join the discussions on how to mi= grate from 2D to 3D, automate your CAD environment to reduce keystrokes, be= tter manage your CAD/BIM environment, speed processes, take the drudgery ou= t of the day-to-day CAD usage =E2=80=A6 and much more.=0A=0ARobert Green CA= D Mgmt. Expert More=0A=C2=A0=0A=C2=A0=0A=0A=0ALearn how to build 3D design= models with Steve Schain, an industry luminary, instructor and consultant.= During his sessions, Steve will demonstrate motion simulation, show how to= integrate rapid prototyping into the product design process, and much more= .=0A=0ASteve Schain Mechanical Design Expert More=0A=C2=A0=0A=C2=A0=0A=0A= =0AFind out how to optimize factory layouts using the latest software tools= Tod Stephens, frequent speaker and consultant, will demonstrates how Finit= e Element Analysis minimizes the prototyping phase of product development = =E2=80=A6 and much more.=0A=0ATod Stephens Design Expert More=0A=C2=A0=0ACl= ick here to see more session descriptions.=0ACAD AMERICAS TRAINING DAYS ARR= IVE IN YOUR AREA SOON!=0AJune 4June 6June 7June 12June 13June 26 June 27=0A= Cleveland Cincinnati Detroit Atlanta Dallas San Jose San_Bernardino = =0AREGISTER BY MAY 7th AND SAVERegister for this CAD Americas Training Day = by May 7th and save.=0ABird Rate: $150 (Until May 7th)=0AStandard Rate: $19= 5 (AFTER May 7th)=0AStudent/Faculty Rate: $95 (must present current student= ID upon check-in at registration)=0AREGISTER FOR CAD AMERICAS TRAINING TOD= AY!=0A=0A=0A=0A Join us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL= SPONSORS=0A=0A=0A =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONSORS=0A=0A=C2= =A0=0AThis email was sent to email address: here to Opt-Out=0A From owner-freebsd-ipfw@FreeBSD.ORG Fri May 10 07:06:36 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 198FBC73; Fri, 10 May 2013 07:06:36 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id D78AE2DA; Fri, 10 May 2013 07:06:35 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id a14so7322308iee.41 for ; Fri, 10 May 2013 00:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=T71cCx0AaUPydO5tEwTcsqZh7xYRgI5feOaUsdV3FDg=; b=Y+jARyJbsXrd4rVHEtgDBkZiNNEx1An6p0xHrJ4k0+ZYXnGNyovL0jE3GxVkH3nzc1 4YQ4zsZGCHPyepeGyhzn10WeZDcAtc/rtDvDABSiyxhWpueKn81Yy0FoSmVO5/utzXga mKY3mBPFGPRDMY60C4omkU2PVlD8jEIGRhZyIvOcJ1tZ3+znEaZAOiSOoAMVxlqX3r7l APSQUCVMz895vxdlfy5468BVoFksPi56q22cpXZfFDhX3VNFqsaE++bMcv9vMC03sbP+ K82K2N58GJajUd308g41jWjUamCOtrJPaqYeAC5zmgAQwjw+ymPlwJCMse+YsXHUYWvq Jskw== MIME-Version: 1.0 X-Received: by 10.50.29.9 with SMTP id f9mr1037120igh.38.1368169595642; Fri, 10 May 2013 00:06:35 -0700 (PDT) Received: by 10.42.189.4 with HTTP; Fri, 10 May 2013 00:06:35 -0700 (PDT) In-Reply-To: References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> <20130417133637.W56386@sola.nimnet.asn.au> Date: Fri, 10 May 2013 09:06:35 +0200 Message-ID: Subject: Re: Problems with ipfw/natd and axe(4) From: Spil Oss To: freebsd-ipfw@freebsd.org, current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 07:06:36 -0000 Hi, There seems to be quite a bit of overhaul on the firewall code, pf and ipfw have been moved to sys/netpfil? Can there be some regressions in there that I hit? Just upgraded to r250404 but that does not help. Should I file a PR? Kind regards, Spil. On Thu, May 9, 2013 at 10:56 AM, Spil Oss wrote: > Hi all, > > So I bought another AX88772B part, this time an Edimax UE-4208 and it > behaved exactly like the no-name part I bought on eBay. > > Looking at YongHyeong's feedback on his engineering sample I decided > to revert back to 9.1-RELEASE and try again, this works like expected. > (see my post > "Problems with axe(4) and checksum offloading" thread started Apr 7 in > freebsd-current@) > > So somewhere between 9.1-RELEASE and 10-CURRENT r248351 there's a > regression that breaks this. Any pointers on getting this to work? > > Kind regards, > > Spil. > > On Wed, Apr 17, 2013 at 7:03 AM, Ian Smith wrote: >> On Tue, 16 Apr 2013 20:52:05 +0200, Spil Oss wrote: >> > Hi all, >> > >> > If I disable checksum offloading on the NIC I do the tcpdump on, then I >> > assume that the checksum-check will provide accurate results? >> >> It certainly should. >> >> > With checksum disabled, I see that the checksum is incorrect when the >> > client does not respond to the SYN,ACK, and correct when it does. >> >> I'm having trouble fully parsing that. >> >> Using 'tcpdump -vr ue0-ssh-fail.pcap | less -S' shows these incorrect >> checksums alright; before adding -v I'd only noticed 172.17.2.1 sending >> SYNs and clearly not responding to 172.17.2.111's SYN/ACKs. >> >> Since it works ok with the divert rule bypassed - presumably still with >> tx/rxcsum enabled - then it seems that (surprise!) Luigi picked the >> issue being in natd / divert socket handling. >> >> > Out of curiousity I tried with pf as well and it behaves the same. >> >> Can't comment on that. What's not clear is why the NIC "doesn't work" >> (symptoms?) with -txcsum -rxcsum. With the 'fail' pcap it seems the >> received checksum from the client SYN is ok on capture, and the server >> is responding with SYN/ACK (with mangled cksum), but the rxcsum must be >> ok after natd, so maybe it's only -txcsum needed? Might that work? >> >> Sorry, I'm just bouncing around on what I can see from here and could be >> missing something someone else might find obvious, I'm just an amateur.. >> >> > On Mon, Apr 15, 2013 at 9:04 PM, Spil Oss wrote: >> >> > > Network dumps as promised >> > > On 172.17.2.1: >> > > tcpdump -p -i bridge0 -s 0 -w ssh-fail.pcap host not 172.17.2.167 >> >> You didn't post that one; I assume it showed the bad cksums back from >> 172.17.2.111? ie that the SYN/ACK packet make it to the client's >> interface, but was dropped for its bad cksum on the client side? >> >> > > From 172.17.2.1 I ran >> > > telnet 172.17.2.111/157 22 >> > > In Wireshark I trimmed the capture a bit further with expression >> > > 'not stp and not http' >> > > >> > > Initial setup (ue0 ext, re0 int, rule 10 to allow ssh) >> > > -> ue0-ssh-success.pcap >> > > Removed rule 10 >> > > -> ue0-ssh-fail.pcap >> > > Switched re0 and ue0, default ruleset (without 10) >> > > -> re0-ssh-success.pcap >> > > >> > > According to YungHyeong the sample ASIX NIC he has works normally when >> > > checksumming is disabled. >> >> I guess trying another of the same NIC is the only way to rule out a >> faulty unit? I'm having similarly frustrating issues with a cardbus >> USB2 card, unrelated but proving just as indeterminate .. >> >> [..] >> >> > >> Does anyone know whether this is an issue with libalias(3) generally - >> > >> in which case using nat instead of divert shouldn't help - or just with >> > >> natd in particular? >> >> Question still stands .. I could redo that rc.firewall patch for nat in >> 'simple' but if the problem is with libalias(3) it won't help with this. >> >> cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Fri May 10 20:04:17 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45D55676; Fri, 10 May 2013 20:04:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id C6B5F5E8; Fri, 10 May 2013 20:04:16 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r4AK49Xj002077; Sat, 11 May 2013 00:04:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r4AK49OU002076; Sat, 11 May 2013 00:04:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 11 May 2013 00:04:09 +0400 From: Gleb Smirnoff To: Spil Oss Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <20130510200409.GT15182@FreeBSD.org> References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> <20130417133637.W56386@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ipfw@freebsd.org, current X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:04:17 -0000 Spil, On Fri, May 10, 2013 at 09:06:35AM +0200, Spil Oss wrote: S> There seems to be quite a bit of overhaul on the firewall code, pf and S> ipfw have been moved to sys/netpfil? Can there be some regressions in S> there that I hit? Yes, a regression is possible there. However, the issue seems to be axe(4) specific, since there are no reports on more common NICs. S> Just upgraded to r250404 but that does not help. Should I file a PR? Having a PR, with all information gathered in one report, is definitely better than not having one. -- Totus tuus, Glebius.