From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 00:58:20 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6734106564A; Sun, 25 Dec 2011 00:58:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4568FC19; Sun, 25 Dec 2011 00:58:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2950146B32; Sat, 24 Dec 2011 19:58:20 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 98FEEB944; Sat, 24 Dec 2011 19:58:19 -0500 (EST) Message-ID: <4EF6752C.4040109@FreeBSD.org> Date: Sat, 24 Dec 2011 19:58:20 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sergey Kandaurov References: <201112231446.38057.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 24 Dec 2011 19:58:19 -0500 (EST) Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Minor fixes to netinet6/icmp6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 00:58:20 -0000 On 12/23/11 6:38 PM, Sergey Kandaurov wrote: > On 23 December 2011 23:46, John Baldwin wrote: >> I found these nits while working on the patches to convert if_addr_mtx to an >> rwlock. The first change is cosmetic, it just un-inlines a TAILQ_FOREACH(). >> The second change is an actual bug. The code is currently reading >> TAILQ_FIRST(&V_ifnet) without holding the appropriate lock. >> >> Index: icmp6.c >> =================================================================== >> --- icmp6.c (revision 228777) >> +++ icmp6.c (working copy) >> @@ -1780,7 +1780,7 @@ ni6_addrs(struct icmp6_nodeinfo *ni6, struct mbuf >> } >> >> IFNET_RLOCK_NOSLEEP(); >> - for (ifp = TAILQ_FIRST(&V_ifnet); ifp; ifp = TAILQ_NEXT(ifp, if_list)) { >> + TAILQ_FOREACH(ifp,&V_ifnet, if_list) { >> addrsofif = 0; >> IF_ADDR_LOCK(ifp); >> TAILQ_FOREACH(ifa,&ifp->if_addrhead, ifa_link) { > > FWIW, there are much more of them in netinet6. > Some time ago I started to un-expand them to queue(3). > [not unfinished yet..] I went ahead and did a sweep for queue(3) changes in netinet6. I went a bit further and removed things like the ndpr_next hack, etc. This only includes queue(3) changes though, not your other fixes like moving common code out of blocks. I also fixed a few places to use *_EMPTY() instead of checking *_FIRST() against NULL. There should be no functional change. http://www.FreeBSD.org/~jhb/patches/inet6_queue.patch -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 07:51:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2474106566C for ; Sun, 25 Dec 2011 07:51:36 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 687D78FC13 for ; Sun, 25 Dec 2011 07:51:36 +0000 (UTC) Received: by eekc50 with SMTP id c50so12248086eek.13 for ; Sat, 24 Dec 2011 23:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=G1dYMoPTC+KIbhgTGClXc5Uz22zPFwoHRMhkwUE/UHo=; b=s6d2jVtW06AruGtLyIhSTBbxreQq+CzbB/rZAq9RhcB1KHwjj77QcdAh2UfmneN4Ii T2Kei+vfWmBoGUakHY0enoDGiCSl625/6AxgsMQm3r/uABcLN8JqmIZNS0MDCNRlOs30 1NUoKWxxGZ9iIIRQEZeqvcXRYrpGzJ2UBRNs8= MIME-Version: 1.0 Received: by 10.213.14.66 with SMTP id f2mr7407562eba.125.1324797649287; Sat, 24 Dec 2011 23:20:49 -0800 (PST) Received: by 10.14.96.5 with HTTP; Sat, 24 Dec 2011 23:20:49 -0800 (PST) Date: Sun, 25 Dec 2011 12:50:49 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ARP Mechanism Modification Issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 07:51:36 -0000 Hello, I have designed a new ARP mechanism that would probably stop ARP poisoning on LAN. I programmed it according to the ARP mechanism mentioned in Steven's Book (TCP/IP Illustrated Vol 2). But that kernel is too old now. I want to test that code whether it would work well or not. What is the way? Can I have that kernel installed now? And then compile the modified kernel on that machine? -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 09:45:56 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 924B51065670; Sun, 25 Dec 2011 09:45:56 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 414F48FC14; Sun, 25 Dec 2011 09:45:55 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so9134298obb.13 for ; Sun, 25 Dec 2011 01:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+0KAVv+aZ5vbXNxTgMAyAdouKhTvZBbVyHTsd/z3olI=; b=SLdKTxnWCt/Z9aMarkEkigDocSiHK/4bn6VOfg6HtDNOhou2XFtCrMEQpryeleGymU nggJBv80Srryx4c2cDTVBGUFF+n/FmXXV/UU1yHmTJv8b/1gPvjAO15BuXFJZXLcEbX/ 7XZ6p3M5TeH+3AODNyPqzwqszWsbeUIXVPzg8= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr10261015obw.10.1324806355648; Sun, 25 Dec 2011 01:45:55 -0800 (PST) Received: by 10.182.171.67 with HTTP; Sun, 25 Dec 2011 01:45:55 -0800 (PST) In-Reply-To: <4EF6752C.4040109@FreeBSD.org> References: <201112231446.38057.jhb@freebsd.org> <4EF6752C.4040109@FreeBSD.org> Date: Sun, 25 Dec 2011 12:45:55 +0300 Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Minor fixes to netinet6/icmp6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 09:45:56 -0000 On 25 December 2011 04:58, John Baldwin wrote: > On 12/23/11 6:38 PM, Sergey Kandaurov wrote: >> >> On 23 December 2011 23:46, John Baldwin =A0wrote: >>> >>> I found these nits while working on the patches to convert if_addr_mtx = to >>> an >>> rwlock. =A0The first change is cosmetic, it just un-inlines a >>> TAILQ_FOREACH(). >>> The second change is an actual bug. =A0The code is currently reading >>> TAILQ_FIRST(&V_ifnet) without holding the appropriate lock. >>> >>> Index: icmp6.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- icmp6.c =A0 =A0 (revision 228777) >>> +++ icmp6.c =A0 =A0 (working copy) >>> @@ -1780,7 +1780,7 @@ ni6_addrs(struct icmp6_nodeinfo *ni6, struct mbuf >>> =A0 =A0 =A0 =A0} >>> >>> =A0 =A0 =A0 =A0IFNET_RLOCK_NOSLEEP(); >>> - =A0 =A0 =A0 for (ifp =3D TAILQ_FIRST(&V_ifnet); ifp; ifp =3D TAILQ_NE= XT(ifp, >>> if_list)) { >>> + =A0 =A0 =A0 TAILQ_FOREACH(ifp,&V_ifnet, if_list) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addrsofif =3D 0; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF_ADDR_LOCK(ifp); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TAILQ_FOREACH(ifa,&ifp->if_addrhead, ifa= _link) { >> >> >> FWIW, there are much more of them in netinet6. >> Some time ago I started to un-expand them to queue(3). >> [not unfinished yet..] > > > I went ahead and did a sweep for queue(3) changes in netinet6. =A0I went = a bit Great, thank you! This sweep is long overdue. > further and removed things like the ndpr_next hack, etc. =A0This only inc= ludes > queue(3) changes though, not your other fixes like moving common code out= of Oops, yeah. This is an unrelated change. > blocks. =A0I also fixed a few places to use *_EMPTY() instead of checking > *_FIRST() against NULL. =A0There should be no functional change. > > http://www.FreeBSD.org/~jhb/patches/inet6_queue.patch Looks good. Please, commit with two notes: a) You changed a loop with precondition while (i < DRLSTSIZ) { ... } into if (i >=3D DRLSTSIZ) and moved it below i++ increment, which effectively became a loop with post-condition like do { ...} while (). To preserve the current behavior I would move this check up right under *_FOREACH() loop, like this: TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { if (i >=3D DRLSTSIZ) break; b) It should be safe to use non-SAFE() FOREACH() variants of queue(3) macros for most occurrences. SAFE() versions are usually only used when you need to add/remove an element on list w/o need to subsequent restart the *_FOREACH() loop. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 12:16:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A97106564A for ; Sun, 25 Dec 2011 12:16:24 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2918FC0A for ; Sun, 25 Dec 2011 12:16:23 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 8B56869AFE; Sun, 25 Dec 2011 13:16:22 +0100 (CET) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk 8B56869AFE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1324815382; bh=cicumQwSbsr7IaBeR34qLRi3rTCC3fGolP6RN/p14A4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NQQ0/xPICOO/W32uUEh0lSPVkaHMgBHTLYo/7cVSn8zORUOg8hWZbi1jQbP02Cyr+ HCV8zBCwdKt0eOvuD5TBqfMcY5R2O8f60zi2K0MYL4XmxOoOhyUncvVnqghnYFOrBa Vnsc0tWX1Yes5T+pUsVoONjIGCizNMdMhNUAWbSE= Message-ID: <4EF71415.2010002@gibfest.dk> Date: Sun, 25 Dec 2011 13:16:21 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111014 Thunderbird/7.0.1 MIME-Version: 1.0 To: lrh@alum.mit.edu References: <201112221018.54462.lrh@alum.mit.edu> In-Reply-To: <201112221018.54462.lrh@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: re%d on FitPC2? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 12:16:24 -0000 On 22.12.2011 18:18, Dr. Lyman Hazelton wrote: > Hi! First post to this list. Was directed here from FreeBSD Forums. > > I'm trying to get FreeBSD running on a FitPC2. > > I have heard that at least one other user has gotten the FitPC2 to work with > the re driver, so, at least in theory, it should work. Question is how? Hello, I am the happy owner of a FitPC2i which (as far as I know) is identical to the FitPC2 with an extra ethernet nic, and a WLAN nic. I haven't had any problems with the nics, but I am running an older version of FreeBSD which may explain the difference: [tykling@fitfw ~]$ uname -rmsi FreeBSD 8.1-STABLE-201010 i386 GENERIC This is the verbose dmesg messages for re0 and re1 on my machine: ---------------------------------------------------------------- [tykling@fitfw ~]$ grep ^re /var/run/dmesg.boot real memory = 2147483648 (2048 MB) re0: port 0x2000-0x20ff mem 0xd8100000-0xd8100fff,0xd8500000-0xd850ffff irq 16 at device 0.0 on pci2 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xd8100000 re0: MSI count : 1 re0: attempting to allocate 1 MSI vectors (1 supported) re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 re0: bpf attached re0: Ethernet address: 00:01:c0:08:25:1f re0: [MPSAFE] re0: [FILTER] re1: port 0x3000-0x30ff mem 0xd8200000-0xd8200fff,0xd8600000-0xd860ffff irq 17 at device 0.0 on pci3 re1: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xd8200000 re1: MSI count : 1 re1: attempting to allocate 1 MSI vectors (1 supported) re1: using IRQ 257 for MSI re1: Using 1 MSI messages re1: Chip rev. 0x3c000000 re1: MAC rev. 0x00400000 re1: bpf attached re1: Ethernet address: 00:01:c0:08:25:20 re1: [MPSAFE] re1: [FILTER] [tykling@fitfw ~]$ grep ^rge /var/run/dmesg.boot rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto [tykling@fitfw ~]$ ---------------------------------------------------------------- I am very happy with the machine, except for an acpi problem which makes it hang at reboot. shutdown -p turns the machine off as expected, but shutdown -r hangs right after "Stopping other CPUs..." when it should reboot. I reported this to acpi@ but never found a solution. I use it as home firewall, so I practically never reboot it, so I learned to live with it :) Good luck with getting your problem solved! Best regards Thomas Steen Rasmussen From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 15:00:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6032106566B; Sun, 25 Dec 2011 15:00:35 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49B948FC12; Sun, 25 Dec 2011 15:00:34 +0000 (UTC) Received: from secured.by.ipfw.ru ([81.200.11.182] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RepYq-000HGF-QA; Sun, 25 Dec 2011 19:00:29 +0400 Message-ID: <4EF73A4A.3050902@FreeBSD.org> Date: Sun, 25 Dec 2011 18:59:22 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Jason Hellenthal References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> In-Reply-To: <20111220163355.GA87584@DataIX.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigABFE081192EEA4308BF10E2C" Cc: Pawel Tyll , freebsd-net@freebsd.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org Subject: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 15:00:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigABFE081192EEA4308BF10E2C Content-Type: multipart/mixed; boundary="------------030403040904080105030905" This is a multi-part message in MIME format. --------------030403040904080105030905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello everyone. Final patch version now uses single IP_FW3 socket option. Together with other changes this makes me think such changes should be reviewed by a wider number of people. If there are no objections/comments I plan to commit this on tuesday. Changes: * Tables (actually, radix trees) are now created/freed on demand. * Tables can be of different types (CIDR and interfaces are supported at the moment) * Each tables has 2 pointers (basic and eXtended tree) which are initialized independently permitting both IPv4/IPv6 address to be specified in the same table without performance loss * Every new opcode uses IP_FW3 socket option This change does not break ABI, old ipfw(8) binary can configure IPv4 addresses on CIDR-type tables and flush every table. --------------030403040904080105030905 Content-Type: text/plain; name="ipfw_tables8.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ipfw_tables8.diff" Index: sbin/ipfw/ipfw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/ipfw/ipfw2.c (revision 228874) +++ sbin/ipfw/ipfw2.c (working copy) @@ -42,6 +42,8 @@ #include /* _long_to_time */ #include #include +#include /* MIN */ +#include /* offsetof */ =20 #include #include /* only IFNAMSIZ */ @@ -57,6 +59,12 @@ struct cmdline_opts co; /* global options */ =20 int resvd_set_number =3D RESVD_SET; =20 +int ipfw_socket =3D -1; + +#ifndef s6_addr32 +#define s6_addr32 __u6_addr.__u6_addr32 +#endif + #define GET_UINT_ARG(arg, min, max, tok, s_x) do { \ if (!av[0]) \ errx(EX_USAGE, "%s: missing argument", match_value(s_x, tok)); \ @@ -370,33 +378,65 @@ safe_realloc(void *ptr, size_t size) int do_cmd(int optname, void *optval, uintptr_t optlen) { - static int s =3D -1; /* the socket */ int i; =20 if (co.test_only) return 0; =20 - if (s =3D=3D -1) - s =3D socket(AF_INET, SOCK_RAW, IPPROTO_RAW); - if (s < 0) + if (ipfw_socket =3D=3D -1) + ipfw_socket =3D socket(AF_INET, SOCK_RAW, IPPROTO_RAW); + if (ipfw_socket < 0) err(EX_UNAVAILABLE, "socket"); =20 if (optname =3D=3D IP_FW_GET || optname =3D=3D IP_DUMMYNET_GET || - optname =3D=3D IP_FW_ADD || optname =3D=3D IP_FW_TABLE_LIST || - optname =3D=3D IP_FW_TABLE_GETSIZE || + optname =3D=3D IP_FW_ADD || optname =3D=3D IP_FW3 || optname =3D=3D IP_FW_NAT_GET_CONFIG || optname < 0 || optname =3D=3D IP_FW_NAT_GET_LOG) { if (optname < 0) optname =3D -optname; - i =3D getsockopt(s, IPPROTO_IP, optname, optval, + i =3D getsockopt(ipfw_socket, IPPROTO_IP, optname, optval, (socklen_t *)optlen); } else { - i =3D setsockopt(s, IPPROTO_IP, optname, optval, optlen); + i =3D setsockopt(ipfw_socket, IPPROTO_IP, optname, optval, optlen); } return i; } =20 +/* + * do_setcmd3 - pass ipfw control cmd to kernel + * @optname: option name + * @optval: pointer to option data + * @optlen: option length + * + * Function encapsulates option value in IP_FW3 socket option + * and calls setsockopt(). + * Function returns 0 on success or -1 overwise. + */ +int +do_setcmd3(int optname, void *optval, socklen_t optlen) +{ + socklen_t len; + ip_fw3_opheader *op3; + + if (co.test_only) + return (0); + + if (ipfw_socket =3D=3D -1) + ipfw_socket =3D socket(AF_INET, SOCK_RAW, IPPROTO_RAW); + if (ipfw_socket < 0) + err(EX_UNAVAILABLE, "socket"); + + len =3D sizeof(ip_fw3_opheader) + optlen; + op3 =3D alloca(len); + /* Zero reserved fields */ + memset(op3, 0, sizeof(ip_fw3_opheader)); + memcpy(op3 + 1, optval, optlen); + op3->opcode =3D optname; + + return setsockopt(ipfw_socket, IPPROTO_IP, IP_FW3, op3, len); +} + /** * match_token takes a table and a string, returns the value associated * with the string (-1 in case of failure). @@ -3854,7 +3894,7 @@ ipfw_flush(int force) } =20 =20 -static void table_list(ipfw_table_entry ent, int need_header); +static void table_list(uint16_t num, int need_header); =20 /* * This one handles all table-related commands @@ -3866,12 +3906,12 @@ ipfw_flush(int force) void ipfw_table_handler(int ac, char *av[]) { - ipfw_table_entry ent; + ipfw_table_xentry xent; int do_add; int is_all; size_t len; char *p; - uint32_t a; + uint32_t a, type, mask, addrlen; uint32_t tables_max; =20 len =3D sizeof(tables_max); @@ -3886,18 +3926,20 @@ ipfw_table_handler(int ac, char *av[]) #endif } =20 + memset(&xent, 0, sizeof(xent)); + ac--; av++; if (ac && isdigit(**av)) { - ent.tbl =3D atoi(*av); + xent.tbl =3D atoi(*av); is_all =3D 0; ac--; av++; } else if (ac && _substrcmp(*av, "all") =3D=3D 0) { - ent.tbl =3D 0; + xent.tbl =3D 0; is_all =3D 1; ac--; av++; } else errx(EX_USAGE, "table number or 'all' keyword required"); - if (ent.tbl >=3D tables_max) + if (xent.tbl >=3D tables_max) errx(EX_USAGE, "The table number exceeds the maximum allowed " "value (%d)", tables_max - 1); NEED1("table needs command"); @@ -3910,104 +3952,181 @@ ipfw_table_handler(int ac, char *av[]) do_add =3D **av =3D=3D 'a'; ac--; av++; if (!ac) - errx(EX_USAGE, "IP address required"); - p =3D strchr(*av, '/'); - if (p) { - *p++ =3D '\0'; - ent.masklen =3D atoi(p); - if (ent.masklen > 32) - errx(EX_DATAERR, "bad width ``%s''", p); - } else - ent.masklen =3D 32; - if (lookup_host(*av, (struct in_addr *)&ent.addr) !=3D 0) - errx(EX_NOHOST, "hostname ``%s'' unknown", *av); + errx(EX_USAGE, "address required"); + /*=20 + * Let's try to guess type by agrument. + * Possible types:=20 + * 1) IPv4[/mask] + * 2) IPv6[/mask] + * 3) interface name + * 4) port ? + */ + type =3D 0; + if (ishexnumber(*av[0])) { + /* Remove / if exists */ + if ((p =3D strchr(*av, '/')) !=3D NULL) { + *p =3D '\0'; + mask =3D atoi(p + 1); + } + + if (inet_pton(AF_INET, *av, &xent.k.addr6) =3D=3D 1) { + type =3D IPFW_TABLE_CIDR; + if ((p !=3D NULL) && (mask > 32)) + errx(EX_DATAERR, "bad IPv4 mask width: %s", p + 1); + xent.masklen =3D p ? mask : 32; + addrlen =3D sizeof(struct in_addr); + } else if (inet_pton(AF_INET6, *av, &xent.k.addr6) =3D=3D 1) { + type =3D IPFW_TABLE_CIDR; + if ((p !=3D NULL) && (mask > 128)) + errx(EX_DATAERR, "bad IPv6 mask width: %s", p + 1); + xent.masklen =3D p ? mask : 128; + addrlen =3D sizeof(struct in6_addr); + } + } + + if ((type =3D=3D 0) && (strchr(*av, '.') =3D=3D NULL)) { + /* Assume interface name. Copy significant data only */ + mask =3D MIN(strlen(*av), IF_NAMESIZE - 1); + memcpy(xent.k.iface, *av, mask); + /* Set mask to exact match */ + xent.masklen =3D 8 * IF_NAMESIZE; + type =3D IPFW_TABLE_INTERFACE; + addrlen =3D IF_NAMESIZE; + } + + if (type =3D=3D 0) { + if (lookup_host(*av, (struct in_addr *)&xent.k.addr6) !=3D 0) + errx(EX_NOHOST, "hostname ``%s'' unknown", *av); + xent.masklen =3D 32; + type =3D IPFW_TABLE_CIDR; + addrlen =3D sizeof(struct in_addr); + } + + xent.type =3D type; + xent.len =3D offsetof(ipfw_table_xentry, k) + addrlen; + ac--; av++; if (do_add && ac) { unsigned int tval; /* isdigit is a bit of a hack here.. */ if (strchr(*av, (int)'.') =3D=3D NULL && isdigit(**av)) { - ent.value =3D strtoul(*av, NULL, 0); + xent.value =3D strtoul(*av, NULL, 0); } else { if (lookup_host(*av, (struct in_addr *)&tval) =3D=3D 0) { /* The value must be stored in host order * * so that the values < 65k can be distinguished */ - ent.value =3D ntohl(tval); + xent.value =3D ntohl(tval); } else { errx(EX_NOHOST, "hostname ``%s'' unknown", *av); } } } else - ent.value =3D 0; - if (do_cmd(do_add ? IP_FW_TABLE_ADD : IP_FW_TABLE_DEL, - &ent, sizeof(ent)) < 0) { + xent.value =3D 0; + if (do_setcmd3(do_add ? IP_FW_TABLE_XADD : IP_FW_TABLE_XDEL, + &xent, xent.len) < 0) { /* If running silent, don't bomb out on these errors. */ if (!(co.do_quiet && (errno =3D=3D (do_add ? EEXIST : ESRCH)))) err(EX_OSERR, "setsockopt(IP_FW_TABLE_%s)", - do_add ? "ADD" : "DEL"); + do_add ? "XADD" : "XDEL"); /* In silent mode, react to a failed add by deleting */ if (do_add) { - do_cmd(IP_FW_TABLE_DEL, &ent, sizeof(ent)); - if (do_cmd(IP_FW_TABLE_ADD, - &ent, sizeof(ent)) < 0) + do_setcmd3(IP_FW_TABLE_XDEL, &xent, xent.len); + if (do_setcmd3(IP_FW_TABLE_XADD, &xent, xent.len) < 0) err(EX_OSERR, - "setsockopt(IP_FW_TABLE_ADD)"); + "setsockopt(IP_FW_TABLE_XADD)"); } } } else if (_substrcmp(*av, "flush") =3D=3D 0) { - a =3D is_all ? tables_max : (uint32_t)(ent.tbl + 1); + a =3D is_all ? tables_max : (uint32_t)(xent.tbl + 1); do { - if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, - sizeof(ent.tbl)) < 0) + if (do_cmd(IP_FW_TABLE_FLUSH, &xent.tbl, + sizeof(xent.tbl)) < 0) err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)"); - } while (++ent.tbl < a); + } while (++xent.tbl < a); } else if (_substrcmp(*av, "list") =3D=3D 0) { - a =3D is_all ? tables_max : (uint32_t)(ent.tbl + 1); + a =3D is_all ? tables_max : (uint32_t)(xent.tbl + 1); do { - table_list(ent, is_all); - } while (++ent.tbl < a); + table_list(xent.tbl, is_all); + } while (++xent.tbl < a); } else errx(EX_USAGE, "invalid table command %s", *av); } =20 static void -table_list(ipfw_table_entry ent, int need_header) +table_list(uint16_t num, int need_header) { - ipfw_table *tbl; + ipfw_xtable *tbl; + ipfw_table_xentry *xent; socklen_t l; - uint32_t a; + uint32_t *a, sz, tval; + char tbuf[128]; + struct in6_addr *addr6; + ip_fw3_opheader *op3; =20 - a =3D ent.tbl; - l =3D sizeof(a); - if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); + /* Prepend value with IP_FW3 header */ + l =3D sizeof(ip_fw3_opheader) + sizeof(uint32_t); + op3 =3D alloca(l); + /* Zero reserved fields */ + memset(op3, 0, sizeof(ip_fw3_opheader)); + a =3D (uint32_t *)(op3 + 1); + *a =3D num; + op3->opcode =3D IP_FW_TABLE_XGETSIZE; + if (do_cmd(IP_FW3, op3, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_XGETSIZE)"); =20 /* If a is zero we have nothing to do, the table is empty. */ - if (a =3D=3D 0) + if (*a =3D=3D 0) return; =20 - l =3D sizeof(*tbl) + a * sizeof(ipfw_table_entry); + l =3D *a; tbl =3D safe_calloc(1, l); - tbl->tbl =3D ent.tbl; - if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); + tbl->opheader.opcode =3D IP_FW_TABLE_XLIST; + tbl->tbl =3D num; + if (do_cmd(IP_FW3, tbl, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_XLIST)"); if (tbl->cnt && need_header) printf("---table(%d)---\n", tbl->tbl); - for (a =3D 0; a < tbl->cnt; a++) { - unsigned int tval; - tval =3D tbl->ent[a].value; - if (co.do_value_as_ip) { - char tbuf[128]; - strncpy(tbuf, inet_ntoa(*(struct in_addr *) - &tbl->ent[a].addr), 127); - /* inet_ntoa expects network order */ - tval =3D htonl(tval); - printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, - inet_ntoa(*(struct in_addr *)&tval)); - } else { - printf("%s/%u %u\n", - inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), - tbl->ent[a].masklen, tval); + sz =3D tbl->size - sizeof(ipfw_xtable); + xent =3D &tbl->xent[0]; + while (sz > 0) { + switch (tbl->type) { + case IPFW_TABLE_CIDR: + /* IPv4 or IPv6 prefixes */ + tval =3D xent->value; + addr6 =3D &xent->k.addr6; + + if ((addr6->s6_addr32[0] =3D=3D 0) && (addr6->s6_addr32[1] =3D=3D 0) = &&=20 + (addr6->s6_addr32[2] =3D=3D 0)) { + /* IPv4 address */ + inet_ntop(AF_INET, &addr6->s6_addr32[3], tbuf, sizeof(tbuf)); + } else { + /* IPv6 address */ + inet_ntop(AF_INET6, addr6, tbuf, sizeof(tbuf)); + } + + if (co.do_value_as_ip) { + tval =3D htonl(tval); + printf("%s/%u %s\n", tbuf, xent->masklen, + inet_ntoa(*(struct in_addr *)&tval)); + } else + printf("%s/%u %u\n", tbuf, xent->masklen, tval); + break; + case IPFW_TABLE_INTERFACE: + /* Interface names, direct match at the moment */ + tval =3D xent->value; + if (co.do_value_as_ip) { + tval =3D htonl(tval); + printf("%s/%s %s\n", xent->k.iface, xent->k.iface, + inet_ntoa(*(struct in_addr *)&tval)); + } else + printf("%s/%s %u\n", xent->k.iface, xent->k.iface, tval); } + + if (sz < xent->len) + break; + sz -=3D xent->len; + xent =3D (void *)xent + xent->len; } + free(tbl); } Index: sys/netinet/ip_fw.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet/ip_fw.h (revision 228874) +++ sys/netinet/ip_fw.h (working copy) @@ -62,6 +62,19 @@ */ #define IPFW_CALLSTACK_SIZE 16 =20 +/* IP_FW3 header/opcodes */ +typedef struct _ip_fw3_opheader { + uint16_t opcode; /* Operation opcode */ + uint16_t reserved[3]; /* Align to 64-bit boundary */ +} ip_fw3_opheader; + + +/* IPFW extented tables support */ +#define IP_FW_TABLE_XADD 86 /* add entry */ +#define IP_FW_TABLE_XDEL 87 /* delete entry */ +#define IP_FW_TABLE_XGETSIZE 88 /* get table size */ +#define IP_FW_TABLE_XLIST 89 /* list table contents */ + /* * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF @@ -581,6 +594,11 @@ struct _ipfw_dyn_rule { /* * These are used for lookup tables. */ + +#define IPFW_TABLE_CIDR 1 /* Table for holding IPv4/IPv6 prefixes */ +#define IPFW_TABLE_INTERFACE 2 /* Table for holding interface names */ +#define IPFW_TABLE_MAXTYPE 2 /* Maximum valid number */ + typedef struct _ipfw_table_entry { in_addr_t addr; /* network address */ u_int32_t value; /* value */ @@ -588,6 +606,19 @@ typedef struct _ipfw_table_entry { u_int8_t masklen; /* mask length */ } ipfw_table_entry; =20 +typedef struct _ipfw_table_xentry { + uint16_t len; /* Total entry length */ + uint8_t type; /* entry type */ + uint8_t masklen; /* mask length */ + uint16_t tbl; /* table number */ + uint32_t value; /* value */ + union { + /* Longest field needs to be aligned by 4-byte boundary */ + struct in6_addr addr6; /* IPv6 address */ + char iface[IF_NAMESIZE]; /* interface name */ + } k; +} ipfw_table_xentry; + typedef struct _ipfw_table { u_int32_t size; /* size of entries in bytes */ u_int32_t cnt; /* # of entries */ @@ -595,4 +626,13 @@ typedef struct _ipfw_table { ipfw_table_entry ent[0]; /* entries */ } ipfw_table; =20 +typedef struct _ipfw_xtable { + ip_fw3_opheader opheader; /* eXtended tables are controlled via IP_FW3 = */ + uint32_t size; /* size of entries in bytes */ + uint32_t cnt; /* # of entries */ + uint16_t tbl; /* table number */ + uint8_t type; /* table type */ + ipfw_table_xentry xent[0]; /* entries */ +} ipfw_xtable; + #endif /* _IPFW2_H */ Index: sys/netinet/ipfw/ip_fw_private.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet/ipfw/ip_fw_private.h (revision 228874) +++ sys/netinet/ipfw/ip_fw_private.h (working copy) @@ -216,8 +216,6 @@ struct ip_fw_chain { int n_rules; /* number of static rules */ int static_len; /* total len of static rules */ struct ip_fw **map; /* array of rule ptrs to ease lookup */ - LIST_HEAD(nat_list, cfg_nat) nat; /* list of nat entries */ - struct radix_node_head *tables[IPFW_TABLES_MAX]; #if defined( __linux__ ) || defined( _WIN32 ) spinlock_t rwmtx; spinlock_t uh_lock; @@ -227,6 +225,10 @@ struct ip_fw_chain { #endif uint32_t id; /* ruleset id */ uint32_t gencnt; /* generation count */ + LIST_HEAD(nat_list, cfg_nat) nat; /* list of nat entries */ + struct radix_node_head *tables[IPFW_TABLES_MAX]; /* IPv4 tables */ + struct radix_node_head *xtables[IPFW_TABLES_MAX]; /* extended tables */= + uint8_t tabletype[IPFW_TABLES_MAX]; /* Table type */ }; =20 struct sockopt; /* used by tcp_var.h */ @@ -273,16 +275,20 @@ int ipfw_check_hook(void *arg, struct mbuf **m0, s struct radix_node; int ipfw_lookup_table(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t ad= dr, uint32_t *val); +int ipfw_lookup_table_extended(struct ip_fw_chain *ch, uint16_t tbl, voi= d *paddr, + uint32_t *val, int type); int ipfw_init_tables(struct ip_fw_chain *ch); void ipfw_destroy_tables(struct ip_fw_chain *ch); int ipfw_flush_table(struct ip_fw_chain *ch, uint16_t tbl); -int ipfw_add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t= addr, - uint8_t mlen, uint32_t value); +int ipfw_add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, void *pad= dr, + uint8_t plen, uint8_t mlen, uint8_t type, uint32_t value); +int ipfw_del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, void *pad= dr, + uint8_t plen, uint8_t mlen, uint8_t type); +int ipfw_count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt= ); int ipfw_dump_table_entry(struct radix_node *rn, void *arg); -int ipfw_del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t= addr, - uint8_t mlen); -int ipfw_count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt= ); int ipfw_dump_table(struct ip_fw_chain *ch, ipfw_table *tbl); +int ipfw_count_xtable(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cn= t); +int ipfw_dump_xtable(struct ip_fw_chain *ch, ipfw_xtable *tbl); =20 /* In ip_fw_nat.c -- XXX to be moved to ip_var.h */ =20 Index: sys/netinet/ipfw/ip_fw_sockopt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet/ipfw/ip_fw_sockopt.c (revision 228874) +++ sys/netinet/ipfw/ip_fw_sockopt.c (working copy) @@ -668,7 +668,6 @@ check_ipfw_struct(struct ip_fw *rule, int size) cmdlen !=3D F_INSN_SIZE(ipfw_insn_u32)) goto bad_size; break; - case O_MACADDR2: if (cmdlen !=3D F_INSN_SIZE(ipfw_insn_mac)) goto bad_size; @@ -941,6 +940,7 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf } =20 =20 +#define IP_FW3_OPLENGTH(x) ((x)->sopt_valsize - sizeof(ip_fw3_opheader))= /** * {set|get}sockopt parser. */ @@ -949,10 +949,13 @@ ipfw_ctl(struct sockopt *sopt) { #define RULE_MAXSIZE (256*sizeof(u_int32_t)) int error; - size_t size; + size_t size, len, valsize; struct ip_fw *buf, *rule; struct ip_fw_chain *chain; u_int32_t rulenum[2]; + uint32_t opt; + char xbuf[128]; + ip_fw3_opheader *op3 =3D NULL; =20 error =3D priv_check(sopt->sopt_td, PRIV_NETINET_IPFW); if (error) @@ -972,7 +975,17 @@ ipfw_ctl(struct sockopt *sopt) chain =3D &V_layer3_chain; error =3D 0; =20 - switch (sopt->sopt_name) { + /* Save original valsize before it is altered via sooptcopyin() */ + valsize =3D sopt->sopt_valsize; + if ((opt =3D sopt->sopt_name) =3D=3D IP_FW3) { + if ((error =3D sooptcopyin(sopt, xbuf, sizeof(xbuf), + sizeof(ip_fw3_opheader))) !=3D 0) + return (error); + op3 =3D (ip_fw3_opheader *)xbuf; + opt =3D op3->opcode; + } + + switch (opt) { case IP_FW_GET: /* * pass up a copy of the current rules. Static rules @@ -1111,7 +1124,8 @@ ipfw_ctl(struct sockopt *sopt) if (error) break; error =3D ipfw_add_table_entry(chain, ent.tbl, - ent.addr, ent.masklen, ent.value); + &ent.addr, sizeof(ent.addr), ent.masklen,=20 + IPFW_TABLE_CIDR, ent.value); } break; =20 @@ -1124,10 +1138,36 @@ ipfw_ctl(struct sockopt *sopt) if (error) break; error =3D ipfw_del_table_entry(chain, ent.tbl, - ent.addr, ent.masklen); + &ent.addr, sizeof(ent.addr), ent.masklen, IPFW_TABLE_CIDR); } break; =20 + case IP_FW_TABLE_XADD: /* IP_FW3 */ + case IP_FW_TABLE_XDEL: /* IP_FW3 */ + { + ipfw_table_xentry *xent =3D (ipfw_table_xentry *)(op3 + 1); + + /* Check minimum header size */ + if (IP_FW3_OPLENGTH(sopt) < offsetof(ipfw_table_xentry, k)) { + error =3D EINVAL; + break; + } + + /* Check if len field is valid */ + if ((len =3D xent->len - offsetof(ipfw_table_xentry, k)) >=20 + sizeof(ipfw_table_xentry)) { + error =3D EINVAL; + break; + } + + error =3D (opt =3D=3D IP_FW_TABLE_XADD) ? + ipfw_add_table_entry(chain, xent->tbl, &xent->k,=20 + len, xent->masklen, xent->type, xent->value) : + ipfw_del_table_entry(chain, xent->tbl, &xent->k, + len, xent->masklen, xent->type); + } + break; + case IP_FW_TABLE_FLUSH: { u_int16_t tbl; @@ -1136,9 +1176,7 @@ ipfw_ctl(struct sockopt *sopt) sizeof(tbl), sizeof(tbl)); if (error) break; - IPFW_WLOCK(chain); error =3D ipfw_flush_table(chain, tbl); - IPFW_WUNLOCK(chain); } break; =20 @@ -1187,6 +1225,62 @@ ipfw_ctl(struct sockopt *sopt) } break; =20 + case IP_FW_TABLE_XGETSIZE: /* IP_FW3 */ + { + uint32_t *tbl; + + if (IP_FW3_OPLENGTH(sopt) < sizeof(uint32_t)) { + error =3D EINVAL; + break; + } + + tbl =3D (uint32_t *)(op3 + 1); + + IPFW_RLOCK(chain); + error =3D ipfw_count_xtable(chain, *tbl, tbl); + IPFW_RUNLOCK(chain); + if (error) + break; + error =3D sooptcopyout(sopt, op3, sopt->sopt_valsize); + } + break; + + case IP_FW_TABLE_XLIST: /* IP_FW3 */ + { + ipfw_xtable *tbl; + + if ((size =3D valsize) < sizeof(ipfw_xtable)) { + error =3D EINVAL; + break; + } + + tbl =3D malloc(size, M_TEMP, M_ZERO | M_WAITOK); + memcpy(tbl, op3, sizeof(ipfw_xtable)); + + /* Get maximum number of entries we can store */ + tbl->size =3D (size - sizeof(ipfw_xtable)) / + sizeof(ipfw_table_xentry); + IPFW_RLOCK(chain); + error =3D ipfw_dump_xtable(chain, tbl); + IPFW_RUNLOCK(chain); + if (error) { + free(tbl, M_TEMP); + break; + } + + /* Revert size field back to bytes */ + tbl->size =3D tbl->size * sizeof(ipfw_table_xentry) + + sizeof(ipfw_table); + /*=20 + * Since we call sooptcopyin() with small buffer, sopt_valsize is + * decreased to reflect supplied buffer size. Set it back to original= value + */ + sopt->sopt_valsize =3D valsize; + error =3D sooptcopyout(sopt, tbl, size); + free(tbl, M_TEMP); + } + break; + /*--- NAT operations are protected by the IPFW_LOCK ---*/ case IP_FW_NAT_CFG: if (IPFW_NAT_LOADED) Index: sys/netinet/ipfw/ip_fw_table.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet/ipfw/ip_fw_table.c (revision 228874) +++ sys/netinet/ipfw/ip_fw_table.c (working copy) @@ -76,6 +76,29 @@ struct table_entry { u_int32_t value; }; =20 +struct xaddr_iface { + uint8_t if_len; /* length of this struct */ + uint8_t pad[7]; /* Align name */ + char ifname[IF_NAMESIZE]; /* Interface name */ +}; + +struct table_xentry { + struct radix_node rn[2]; + union { +#ifdef INET6 + struct sockaddr_in6 addr6; +#endif + struct xaddr_iface iface; + } a; + union { +#ifdef INET6 + struct sockaddr_in6 mask6; +#endif + struct xaddr_iface ifmask; + } m; + u_int32_t value; +}; + /* * The radix code expects addr and mask to be array of bytes, * with the first byte being the length of the array. rn_inithead @@ -87,57 +110,264 @@ struct table_entry { */ #define KEY_LEN(v) *((uint8_t *)&(v)) #define KEY_OFS (8*offsetof(struct sockaddr_in, sin_addr)) +/* + * Do not require radix to compare more than actual IPv4/IPv6 address + */ +#define KEY_LEN_INET (offsetof(struct sockaddr_in, sin_addr) + sizeof(in= _addr_t)) +#define KEY_LEN_INET6 (offsetof(struct sockaddr_in6, sin6_addr) + sizeof= (struct in6_addr)) =20 +static inline void +ipv6_writemask(struct in6_addr *addr6, uint8_t mask) +{ + uint32_t *cp; + + for (cp =3D (uint32_t *)addr6; mask >=3D 32; mask -=3D 32) + *cp++ =3D 0xFFFFFFFF; + *cp =3D htonl(mask ? ~((1 << (32 - mask)) - 1) : 0); +} + int -ipfw_add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t add= r, - uint8_t mlen, uint32_t value) +ipfw_add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, void *paddr, + uint8_t plen, uint8_t mlen, uint8_t type, uint32_t value) { - struct radix_node_head *rnh; + struct radix_node_head *rnh, **rnh_ptr; struct table_entry *ent; + struct table_xentry *xent; struct radix_node *rn; + in_addr_t addr; + int offset; + void *ent_ptr; + struct sockaddr *addr_ptr, *mask_ptr; + char c; =20 if (tbl >=3D IPFW_TABLES_MAX) return (EINVAL); - rnh =3D ch->tables[tbl]; - ent =3D malloc(sizeof(*ent), M_IPFW_TBL, M_NOWAIT | M_ZERO); - if (ent =3D=3D NULL) - return (ENOMEM); - ent->value =3D value; - KEY_LEN(ent->addr) =3D KEY_LEN(ent->mask) =3D 8; - ent->mask.sin_addr.s_addr =3D htonl(mlen ? ~((1 << (32 - mlen)) - 1) : = 0); - ent->addr.sin_addr.s_addr =3D addr & ent->mask.sin_addr.s_addr; + + switch (type) { + case IPFW_TABLE_CIDR: + if (plen =3D=3D sizeof(in_addr_t)) { + ent =3D malloc(sizeof(*ent), M_IPFW_TBL, M_WAITOK | M_ZERO); + ent->value =3D value; + /* Set 'total' structure length */ + KEY_LEN(ent->addr) =3D KEY_LEN_INET; + KEY_LEN(ent->mask) =3D KEY_LEN_INET; + /* Set offset of IPv4 address in bits */ + offset =3D (8 * offsetof(struct sockaddr_in, sin_addr)); + ent->mask.sin_addr.s_addr =3D htonl(mlen ? ~((1 << (32 - mlen)) - 1) = : 0); + addr =3D *((in_addr_t *)paddr); + ent->addr.sin_addr.s_addr =3D addr & ent->mask.sin_addr.s_addr; + /* Set pointers */ + rnh_ptr =3D &ch->tables[tbl]; + ent_ptr =3D ent; + addr_ptr =3D (struct sockaddr *)&ent->addr; + mask_ptr =3D (struct sockaddr *)&ent->mask; +#ifdef INET6 + } else if (plen =3D=3D sizeof(struct in6_addr)) { + /* IPv6 case */ + if (mlen > 128) + return (EINVAL); + xent =3D malloc(sizeof(*xent), M_IPFW_TBL, M_WAITOK | M_ZERO); + xent->value =3D value; + /* Set 'total' structure length */ + KEY_LEN(xent->a.addr6) =3D KEY_LEN_INET6; + KEY_LEN(xent->m.mask6) =3D KEY_LEN_INET6; + /* Set offset of IPv6 address in bits */ + offset =3D (8 * offsetof(struct sockaddr_in6, sin6_addr)); + ipv6_writemask(&xent->m.mask6.sin6_addr, mlen); + memcpy(&xent->a.addr6.sin6_addr, paddr, sizeof(struct in6_addr)); + APPLY_MASK(&xent->a.addr6.sin6_addr, &xent->m.mask6.sin6_addr); + /* Set pointers */ + rnh_ptr =3D &ch->xtables[tbl]; + ent_ptr =3D xent; + addr_ptr =3D (struct sockaddr *)&xent->a.addr6; + mask_ptr =3D (struct sockaddr *)&xent->m.mask6; +#endif + } else { + /* Unknown CIDR type */ + return (EINVAL); + } + break; +=09 + case IPFW_TABLE_INTERFACE: + /* Check if string is terminated */ + c =3D ((char *)paddr)[IF_NAMESIZE - 1]; + ((char *)paddr)[IF_NAMESIZE - 1] =3D '\0'; + if (((mlen =3D strlen((char *)paddr)) =3D=3D IF_NAMESIZE - 1) && (c !=3D= '\0')) + return (EINVAL); + + xent =3D malloc(sizeof(*xent), M_IPFW_TBL, M_WAITOK | M_ZERO); + xent->value =3D value; + /* Set 'total' structure length */ + KEY_LEN(xent->a.iface) =3D mlen; + KEY_LEN(xent->m.ifmask) =3D mlen; + /* Set offset of interface name in bits */ + offset =3D (8 * offsetof(struct xaddr_iface, ifname)); + /* Assume direct match */ + /* FIXME: Add interface pattern matching */ +#if 0 + memset(xent->m.ifmask.ifname, 0xFF, IF_NAMESIZE); + mask_ptr =3D (struct sockaddr *)&xent->m.ifmask; +#endif + mask_ptr =3D NULL; + memcpy(xent->a.iface.ifname, paddr, mlen); + /* Set pointers */ + rnh_ptr =3D &ch->xtables[tbl]; + ent_ptr =3D xent; + addr_ptr =3D (struct sockaddr *)&xent->a.iface; + break; + + default: + return (EINVAL); + } + IPFW_WLOCK(ch); - rn =3D rnh->rnh_addaddr(&ent->addr, &ent->mask, rnh, (void *)ent); + + /* Check if tabletype is valid */ + if ((ch->tabletype[tbl] !=3D 0) && (ch->tabletype[tbl] !=3D type)) { + IPFW_WUNLOCK(ch); + free(ent_ptr, M_IPFW_TBL); + return (EINVAL); + } + + /* Check if radix tree exists */ + if ((rnh =3D *rnh_ptr) =3D=3D NULL) { + IPFW_WUNLOCK(ch); + /* Create radix for a new table */ + if (!rn_inithead((void **)&rnh, offset)) { + free(ent_ptr, M_IPFW_TBL); + return (ENOMEM); + } + + IPFW_WLOCK(ch); + if (*rnh_ptr !=3D NULL) { + /* Tree is already attached by other thread */ + rn_detachhead((void **)&rnh); + rnh =3D *rnh_ptr; + /* Check table type another time */ + if (ch->tabletype[tbl] !=3D type) { + IPFW_WUNLOCK(ch); + free(ent_ptr, M_IPFW_TBL); + return (EINVAL); + } + } else { + *rnh_ptr =3D rnh; + /*=20 + * Set table type. It can be set already + * (if we have IPv6-only table) but setting + * it another time does not hurt + */ + ch->tabletype[tbl] =3D type; + } + } + + rn =3D rnh->rnh_addaddr(addr_ptr, mask_ptr, rnh, ent_ptr); + IPFW_WUNLOCK(ch); + if (rn =3D=3D NULL) { - IPFW_WUNLOCK(ch); - free(ent, M_IPFW_TBL); + free(ent_ptr, M_IPFW_TBL); return (EEXIST); } - IPFW_WUNLOCK(ch); return (0); } =20 int -ipfw_del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t add= r, - uint8_t mlen) +ipfw_del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, void *paddr, + uint8_t plen, uint8_t mlen, uint8_t type) { - struct radix_node_head *rnh; + struct radix_node_head *rnh, **rnh_ptr; struct table_entry *ent; + in_addr_t addr; struct sockaddr_in sa, mask; + struct sockaddr *sa_ptr, *mask_ptr; + char c; =20 if (tbl >=3D IPFW_TABLES_MAX) return (EINVAL); - rnh =3D ch->tables[tbl]; - KEY_LEN(sa) =3D KEY_LEN(mask) =3D 8; - mask.sin_addr.s_addr =3D htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); - sa.sin_addr.s_addr =3D addr & mask.sin_addr.s_addr; + + switch (type) { + case IPFW_TABLE_CIDR: + if (plen =3D=3D sizeof(in_addr_t)) { + /* Set 'total' structure length */ + KEY_LEN(sa) =3D KEY_LEN_INET; + KEY_LEN(mask) =3D KEY_LEN_INET; + mask.sin_addr.s_addr =3D htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0);= + addr =3D *((in_addr_t *)paddr); + sa.sin_addr.s_addr =3D addr & mask.sin_addr.s_addr; + rnh_ptr =3D &ch->tables[tbl]; + sa_ptr =3D (struct sockaddr *)&sa; + mask_ptr =3D (struct sockaddr *)&mask; +#ifdef INET6 + } else if (plen =3D=3D sizeof(struct in6_addr)) { + /* IPv6 case */ + if (mlen > 128) + return (EINVAL); + struct sockaddr_in6 sa6, mask6; + memset(&sa6, 0, sizeof(struct sockaddr_in6)); + memset(&mask6, 0, sizeof(struct sockaddr_in6)); + /* Set 'total' structure length */ + KEY_LEN(sa6) =3D KEY_LEN_INET6; + KEY_LEN(mask6) =3D KEY_LEN_INET6; + ipv6_writemask(&mask6.sin6_addr, mlen); + memcpy(&sa6.sin6_addr, paddr, sizeof(struct in6_addr)); + APPLY_MASK(&sa6.sin6_addr, &mask6.sin6_addr); + rnh_ptr =3D &ch->xtables[tbl]; + sa_ptr =3D (struct sockaddr *)&sa6; + mask_ptr =3D (struct sockaddr *)&mask6; +#endif + } else { + /* Unknown CIDR type */ + return (EINVAL); + } + break; + + case IPFW_TABLE_INTERFACE: + /* Check if string is terminated */ + c =3D ((char *)paddr)[IF_NAMESIZE - 1]; + ((char *)paddr)[IF_NAMESIZE - 1] =3D '\0'; + if (((mlen =3D strlen((char *)paddr)) =3D=3D IF_NAMESIZE - 1) && (c !=3D= '\0')) + return (EINVAL); + + struct xaddr_iface ifname, ifmask; + memset(&ifname, 0, sizeof(ifname)); + + /* Set 'total' structure length */ + KEY_LEN(ifname) =3D mlen; + KEY_LEN(ifmask) =3D mlen; + /* Assume direct match */ + /* FIXME: Add interface pattern matching */ +#if 0 + memset(ifmask.ifname, 0xFF, IF_NAMESIZE); + mask_ptr =3D (struct sockaddr *)&ifmask; +#endif + mask_ptr =3D NULL; + memcpy(ifname.ifname, paddr, mlen); + /* Set pointers */ + rnh_ptr =3D &ch->xtables[tbl]; + sa_ptr =3D (struct sockaddr *)&ifname; + + break; + + default: + return (EINVAL); + } + IPFW_WLOCK(ch); - ent =3D (struct table_entry *)rnh->rnh_deladdr(&sa, &mask, rnh); - if (ent =3D=3D NULL) { + if ((rnh =3D *rnh_ptr) =3D=3D NULL) { IPFW_WUNLOCK(ch); return (ESRCH); } + + if (ch->tabletype[tbl] !=3D type) { + IPFW_WUNLOCK(ch); + return (EINVAL); + } + + ent =3D (struct table_entry *)rnh->rnh_deladdr(sa_ptr, mask_ptr, rnh); IPFW_WUNLOCK(ch); + + if (ent =3D=3D NULL) + return (ESRCH); + free(ent, M_IPFW_TBL); return (0); } @@ -158,15 +388,38 @@ flush_table_entry(struct radix_node *rn, void *arg int ipfw_flush_table(struct ip_fw_chain *ch, uint16_t tbl) { - struct radix_node_head *rnh; + struct radix_node_head *rnh, *xrnh; =20 - IPFW_WLOCK_ASSERT(ch); - if (tbl >=3D IPFW_TABLES_MAX) return (EINVAL); - rnh =3D ch->tables[tbl]; - KASSERT(rnh !=3D NULL, ("NULL IPFW table")); - rnh->rnh_walktree(rnh, flush_table_entry, rnh); + + /* + * We free both (IPv4 and extended) radix trees and + * clear table type here to permit table to be reused + * for different type without module reload + */ + + IPFW_WLOCK(ch); + /* Set IPv4 table pointer to zero */ + if ((rnh =3D ch->tables[tbl]) !=3D NULL) + ch->tables[tbl] =3D NULL; + /* Set extended table pointer to zero */ + if ((xrnh =3D ch->xtables[tbl]) !=3D NULL) + ch->xtables[tbl] =3D NULL; + /* Zero table type */ + ch->tabletype[tbl] =3D 0; + IPFW_WUNLOCK(ch); + + if (rnh !=3D NULL) { + rnh->rnh_walktree(rnh, flush_table_entry, rnh); + rn_detachhead((void **)&rnh); + } + + if (xrnh !=3D NULL) { + xrnh->rnh_walktree(xrnh, flush_table_entry, xrnh); + rn_detachhead((void **)&xrnh); + } + return (0); } =20 @@ -174,31 +427,15 @@ void ipfw_destroy_tables(struct ip_fw_chain *ch) { uint16_t tbl; - struct radix_node_head *rnh; =20 - IPFW_WLOCK_ASSERT(ch); - - for (tbl =3D 0; tbl < IPFW_TABLES_MAX; tbl++) { + for (tbl =3D 0; tbl < IPFW_TABLES_MAX; tbl++) ipfw_flush_table(ch, tbl); - rnh =3D ch->tables[tbl]; - rn_detachhead((void **)&rnh); - } } =20 int ipfw_init_tables(struct ip_fw_chain *ch) -{=20 - int i; - uint16_t j; - - for (i =3D 0; i < IPFW_TABLES_MAX; i++) { - if (!rn_inithead((void **)&ch->tables[i], KEY_OFS)) { - for (j =3D 0; j < i; j++) { - (void) ipfw_flush_table(ch, j); - } - return (ENOMEM); - } - } +{ + /* Init tables on demand */ return (0); } =20 @@ -212,8 +449,9 @@ ipfw_lookup_table(struct ip_fw_chain *ch, uint16_t =20 if (tbl >=3D IPFW_TABLES_MAX) return (0); - rnh =3D ch->tables[tbl]; - KEY_LEN(sa) =3D 8; + if ((rnh =3D ch->tables[tbl]) =3D=3D NULL) + return (0); + KEY_LEN(sa) =3D KEY_LEN_INET; sa.sin_addr.s_addr =3D addr; ent =3D (struct table_entry *)(rnh->rnh_lookup(&sa, NULL, rnh)); if (ent !=3D NULL) { @@ -223,6 +461,45 @@ ipfw_lookup_table(struct ip_fw_chain *ch, uint16_t return (0); } =20 +int +ipfw_lookup_table_extended(struct ip_fw_chain *ch, uint16_t tbl, void *p= addr, + uint32_t *val, int type) +{ + struct radix_node_head *rnh; + struct table_xentry *xent; + struct sockaddr_in6 sa6; + struct xaddr_iface iface; + + if (tbl >=3D IPFW_TABLES_MAX) + return (0); + if ((rnh =3D ch->xtables[tbl]) =3D=3D NULL) + return (0); + + switch (type) { + case IPFW_TABLE_CIDR: + KEY_LEN(sa6) =3D KEY_LEN_INET6; + memcpy(&sa6.sin6_addr, paddr, sizeof(struct in6_addr)); + xent =3D (struct table_xentry *)(rnh->rnh_lookup(&sa6, NULL, rnh)); + break; + + case IPFW_TABLE_INTERFACE: + KEY_LEN(iface) =3D strlcpy(iface.ifname, (char *)paddr, IF_NAMESIZE); + /* Assume direct match */ + /* FIXME: Add interface pattern matching */ + xent =3D (struct table_xentry *)(rnh->rnh_lookup(&iface, NULL, rnh)); + break; + + default: + return (0); + } + + if (xent !=3D NULL) { + *val =3D xent->value; + return (1); + } + return (0); +} + static int count_table_entry(struct radix_node *rn, void *arg) { @@ -239,8 +516,9 @@ ipfw_count_table(struct ip_fw_chain *ch, uint32_t =20 if (tbl >=3D IPFW_TABLES_MAX) return (EINVAL); - rnh =3D ch->tables[tbl]; *cnt =3D 0; + if ((rnh =3D ch->tables[tbl]) =3D=3D NULL) + return (0); rnh->rnh_walktree(rnh, count_table_entry, cnt); return (0); } @@ -273,9 +551,122 @@ ipfw_dump_table(struct ip_fw_chain *ch, ipfw_table =20 if (tbl->tbl >=3D IPFW_TABLES_MAX) return (EINVAL); - rnh =3D ch->tables[tbl->tbl]; tbl->cnt =3D 0; + if ((rnh =3D ch->tables[tbl->tbl]) =3D=3D NULL) + return (0); rnh->rnh_walktree(rnh, dump_table_entry, tbl); return (0); } + +static int +count_table_xentry(struct radix_node *rn, void *arg) +{ + uint32_t * const cnt =3D arg; + + (*cnt) +=3D sizeof(ipfw_table_xentry); + return (0); +} + +int +ipfw_count_xtable(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt) +{ + struct radix_node_head *rnh; + + if (tbl >=3D IPFW_TABLES_MAX) + return (EINVAL); + *cnt =3D 0; + if ((rnh =3D ch->tables[tbl]) !=3D NULL) + rnh->rnh_walktree(rnh, count_table_xentry, cnt); + if ((rnh =3D ch->xtables[tbl]) !=3D NULL) + rnh->rnh_walktree(rnh, count_table_xentry, cnt); + /* Return zero if table is empty */ + if (*cnt > 0) + (*cnt) +=3D sizeof(ipfw_xtable); + return (0); +} + + +static int +dump_table_xentry_base(struct radix_node *rn, void *arg) +{ + struct table_entry * const n =3D (struct table_entry *)rn; + ipfw_xtable * const tbl =3D arg; + ipfw_table_xentry *xent; + + /* Out of memory, returning */ + if (tbl->cnt =3D=3D tbl->size) + return (1); + xent =3D &tbl->xent[tbl->cnt]; + xent->len =3D sizeof(ipfw_table_xentry); + xent->tbl =3D tbl->tbl; + if (in_nullhost(n->mask.sin_addr)) + xent->masklen =3D 0; + else + xent->masklen =3D 33 - ffs(ntohl(n->mask.sin_addr.s_addr)); + /* Save IPv4 address as deprecated IPv6 compatible */ + xent->k.addr6.s6_addr32[3] =3D n->addr.sin_addr.s_addr; + xent->value =3D n->value; + tbl->cnt++; + return (0); +} + +static int +dump_table_xentry_extended(struct radix_node *rn, void *arg) +{ + struct table_xentry * const n =3D (struct table_xentry *)rn; + ipfw_xtable * const tbl =3D arg; + ipfw_table_xentry *xent; +#ifdef INET6 + int i; + uint32_t *v; +#endif + /* Out of memory, returning */ + if (tbl->cnt =3D=3D tbl->size) + return (1); + xent =3D &tbl->xent[tbl->cnt]; + xent->len =3D sizeof(ipfw_table_xentry); + xent->tbl =3D tbl->tbl; + + switch (tbl->type) { +#ifdef INET6 + case IPFW_TABLE_CIDR: + /* Count IPv6 mask */ + v =3D (uint32_t *)&n->m.mask6.sin6_addr; + for (i =3D 0; i < sizeof(struct in6_addr) / 4; i++, v++) + xent->masklen +=3D bitcount32(*v); + memcpy(&xent->k, &n->a.addr6.sin6_addr, sizeof(struct in6_addr)); + break; +#endif + case IPFW_TABLE_INTERFACE: + /* Assume exact mask */ + xent->masklen =3D 8 * IF_NAMESIZE; + memcpy(&xent->k, &n->a.iface.ifname, IF_NAMESIZE); + break; +=09 + default: + /* unknown, skip entry */ + return (0); + } + + xent->value =3D n->value; + tbl->cnt++; + return (0); +} + +int +ipfw_dump_xtable(struct ip_fw_chain *ch, ipfw_xtable *tbl) +{ + struct radix_node_head *rnh; + + if (tbl->tbl >=3D IPFW_TABLES_MAX) + return (EINVAL); + tbl->cnt =3D 0; + tbl->type =3D ch->tabletype[tbl->tbl]; + if ((rnh =3D ch->tables[tbl->tbl]) !=3D NULL) + rnh->rnh_walktree(rnh, dump_table_xentry_base, tbl); + if ((rnh =3D ch->xtables[tbl->tbl]) !=3D NULL) + rnh->rnh_walktree(rnh, dump_table_xentry_extended, tbl); + return (0); +} + /* end of file */ Index: sys/netinet/ipfw/ip_fw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet/ipfw/ip_fw2.c (revision 228874) +++ sys/netinet/ipfw/ip_fw2.c (working copy) @@ -1449,6 +1449,17 @@ do { \ ((ipfw_insn_u32 *)cmd)->d[0] =3D=3D v; else tablearg =3D v; + } else if (is_ipv6) { + uint32_t v =3D 0; + void *pkey =3D (cmd->opcode =3D=3D O_IP_DST_LOOKUP) ? + &args->f_id.dst_ip6: &args->f_id.src_ip6; + match =3D ipfw_lookup_table_extended(chain, + cmd->arg1, pkey, &v, + IPFW_TABLE_CIDR); + if (cmdlen =3D=3D F_INSN_SIZE(ipfw_insn_u32)) + match =3D ((ipfw_insn_u32 *)cmd)->d[0] =3D=3D v; + if (match) + tablearg =3D v; } break; =20 @@ -2630,12 +2641,12 @@ vnet_ipfw_uninit(const void *unused) IPFW_UH_WLOCK(chain); =20 IPFW_WLOCK(chain); + ipfw_dyn_uninit(0); /* run the callout_drain */ IPFW_WUNLOCK(chain); - IPFW_WLOCK(chain); =20 - ipfw_dyn_uninit(0); /* run the callout_drain */ ipfw_destroy_tables(chain); reap =3D NULL; + IPFW_WLOCK(chain); for (i =3D 0; i < chain->n_rules; i++) { rule =3D chain->map[i]; rule->x_next =3D reap; --------------030403040904080105030905-- --------------enigABFE081192EEA4308BF10E2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk73OlgACgkQwcJ4iSZ1q2nzvQCfTDW9r7rVhSOHKD3QAEL93Myb x1EAn1z3xVlHujXf7Me5dvyiqOh4HQLB =hhVM -----END PGP SIGNATURE----- --------------enigABFE081192EEA4308BF10E2C-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 15:36:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B7D1065670; Sun, 25 Dec 2011 15:36:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id E53048FC13; Sun, 25 Dec 2011 15:36:36 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 573DC25D3892; Sun, 25 Dec 2011 15:36:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 170F1BD7C2F; Sun, 25 Dec 2011 15:36:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 0g5pGV8cEuhN; Sun, 25 Dec 2011 15:36:33 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 61694BD7C2E; Sun, 25 Dec 2011 15:36:32 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4EF73A4A.3050902@FreeBSD.org> Date: Sun, 25 Dec 2011 15:36:31 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> To: Alexander V. Chernikov X-Mailer: Apple Mail (2.1084) Cc: Jason Hellenthal , freebsd-net@freebsd.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, Pawel Tyll Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 15:36:37 -0000 On 25. Dec 2011, at 14:59 , Alexander V. Chernikov wrote: > Hello everyone. > > Final patch version now uses single IP_FW3 socket option. > Together with other changes this makes me think such changes should be > reviewed by a wider number of people. If there are no > objections/comments I plan to commit this on tuesday. Aehm if you want review by a larger number of people and maybe some testing, 2 days, especially over the holiday season is far from reasonable. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 16:01:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BDF1065672; Sun, 25 Dec 2011 16:01:41 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [IPv6:2a02:6b8:0:202::5]) by mx1.freebsd.org (Postfix) with ESMTP id 17E798FC17; Sun, 25 Dec 2011 16:01:40 +0000 (UTC) Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward10.mail.yandex.net (Yandex) with ESMTP id 4118610225DC; Sun, 25 Dec 2011 20:01:38 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324828898; bh=IlbN3TjqAn+dhOz/gzskEBYjDpZsZpIjNL0B1VDZ/HU=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O1uEpugWBedkPBsX5T4/1yQs0epHDnmjFw984WHU2DcgZWpJpecVU0miv5evnRmd1 ybEIpWgjj62lQoj8JR3RmbDdnT+fvY/LTxej+fYwrHJCY/B+kK7gtEAP6MRxAgaBI2 Q+XPSq4EWhpr3dmlSuNmME70tkaCoEKzzH6n/ewE= Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id D953715203E1; Sun, 25 Dec 2011 20:01:37 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324828898; bh=IlbN3TjqAn+dhOz/gzskEBYjDpZsZpIjNL0B1VDZ/HU=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O1uEpugWBedkPBsX5T4/1yQs0epHDnmjFw984WHU2DcgZWpJpecVU0miv5evnRmd1 ybEIpWgjj62lQoj8JR3RmbDdnT+fvY/LTxej+fYwrHJCY/B+kK7gtEAP6MRxAgaBI2 Q+XPSq4EWhpr3dmlSuNmME70tkaCoEKzzH6n/ewE= Received: from unknown (unknown [77.93.52.22]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1bBmZVVa-1bBC6wHY; Sun, 25 Dec 2011 20:01:37 +0400 X-Yandex-Spam: 1 Date: Sun, 25 Dec 2011 18:01:33 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <1632420869.20111225180133@yandex.ru> To: John Baldwin In-Reply-To: <201112200952.44690.jhb@freebsd.org> References: <20111022084931.GD1697@garage.freebsd.pl> <201112121100.23567.jhb@freebsd.org> <20111217232125.GA1685@garage.freebsd.pl> <201112200952.44690.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: Andre Oppermann , freebsd-net@freebsd.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org, Kostik Belousov , Lawrence Stewart Subject: Re[2]: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 16:01:41 -0000 Çäðàâñòâóéòå, John. Âû ïèñàëè 20 äåêàáðÿ 2011 ã., 16:52:44: JB> On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote: >> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: >> > An update. I've sent Pawel a testing patch to see if my hypothesis is correct >> > (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is then I intend >> > to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fix. >> >> Unfortunately it paniced today. Take a look at: >> >> http://people.freebsd.org/~pjd/misc/tcp_panic.jpg JB> Ok, the one use case I was worried about is happening regularly before your JB> panic, so that is good. Can you use gdb to figure out which call to JB> tcp_output() is actually panic'ing? I wonder if it is this case: JB> /* JB> * Return any desired output. JB> */ JB> if (needoutput || (tp->t_flags & TF_ACKNOW)) { JB> (void) tcp_output(tp); JB> /* XXX: Debug */ JB> KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), JB> ("tcp_input: negative window after ACK")); JB> And if 'needoutput' is true, but TF_ACKNOW is not set, and tcp_output() decides JB> to not do anything. I've updated tcp_negwin_test.patch to not panic if that call JB> to tcp_output() doesn't actually send a packet. Please re-test. # uname -a FreeBSD meta-up 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #4: Sat Dec 24 13:59:20 EET 2011 @:/usr/obj/usr/src/sys/KES_KERN_v10 i386 rebooting once per day. Now I compile kernel with debug options. Can you advice me which and where I find debug info when it will reboting next time? so I can help to debug problem -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 17:47:23 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2FA0106564A for ; Sun, 25 Dec 2011 17:47:23 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7B04E8FC0A for ; Sun, 25 Dec 2011 17:47:23 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1ResAM-000BWm-GB for freebsd-net@freebsd.org; Sun, 25 Dec 2011 18:47:22 +0100 Date: Sun, 25 Dec 2011 18:47:12 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1413850829.20111225184712@nitronet.pl> To: "Alexander V. Chernikov" In-Reply-To: <4EF73A4A.3050902@FreeBSD.org> References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Jason Hellenthal , "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 17:47:23 -0000 Hi Alexander, > Changes: > * Tables (actually, radix trees) are now created/freed on demand. Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily high number that would allow flexible numbering of tables? Arbitrarily high being 0xFFFFFFFF or some other nice large number that won't step on my ideas :) Again, nice set of long-needed additions. Thanks. Cheers. From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 18:18:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB9E1065670; Sun, 25 Dec 2011 18:18:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 74D988FC1B; Sun, 25 Dec 2011 18:18:47 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 06E7125D3872; Sun, 25 Dec 2011 18:18:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9BF5DBD7C50; Sun, 25 Dec 2011 18:18:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id qc7WeBomN0Ch; Sun, 25 Dec 2011 18:18:43 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3E2F2BD7C4F; Sun, 25 Dec 2011 18:18:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" X-Priority: 3 (Normal) In-Reply-To: <1413850829.20111225184712@nitronet.pl> Date: Sun, 25 Dec 2011 18:18:42 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> <1413850829.20111225184712@nitronet.pl> To: Pawel Tyll X-Mailer: Apple Mail (2.1084) Cc: Jason Hellenthal , freebsd-net@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org, "Andrey V. Elsukov" Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 18:18:48 -0000 On 25. Dec 2011, at 17:47 , Pawel Tyll wrote: > Hi Alexander, > >> Changes: >> * Tables (actually, radix trees) are now created/freed on demand. > Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily > high number that would allow flexible numbering of tables? Arbitrarily > high being 0xFFFFFFFF or some other nice large number that won't step > on my ideas :) which also gets us to the point that the man page need to be updated along with the same changes and I cannot see that as part of the diff. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 18:56:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8297106566B; Sun, 25 Dec 2011 18:56:39 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5498FC08; Sun, 25 Dec 2011 18:56:39 +0000 (UTC) Received: from secured.by.ipfw.ru ([81.200.11.182] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RetF4-000IQm-20; Sun, 25 Dec 2011 22:56:18 +0400 Message-ID: <4EF7719A.8020902@FreeBSD.org> Date: Sun, 25 Dec 2011 22:55:22 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> <1413850829.20111225184712@nitronet.pl> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC6E4F7F37CDABE2B10BCA50A" Cc: Pawel Tyll , freebsd-net@freebsd.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, Jason Hellenthal Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 18:56:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC6E4F7F37CDABE2B10BCA50A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb wrote: > On 25. Dec 2011, at 17:47 , Pawel Tyll wrote: >=20 >> Hi Alexander, >> >>> Changes: >>> * Tables (actually, radix trees) are now created/freed on demand. >> Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily= >> high number that would allow flexible numbering of tables? Arbitrarily= >> high being 0xFFFFFFFF or some other nice large number that won't step= >> on my ideas :) At the moment maximum number of tables remains the same however it is now possible to define IPFW_TABLES_MAX to 65k without much (memory) overhead. Since pointer to tables are stored in array, defining 2^32 tables require 4G * (8+8+1) memory for pointers only. >=20 > which also gets us to the point that the man page need to be updated al= ong > with the same changes and I cannot see that as part of the diff. Sure. This is actually the first part of commit, interface table changes and proper ipv6 'lookup' keyword support requires another change that is planned to be committed separately (with man page update) By the way, I see two possible syntax changes for interface tables: ipfw add .. skipto tablearg ip from any to any lookup or ipfw add .. skipto tablearg ip from any to any recv|xmit|via table(X) Personally I like 'lookup' variant. >=20 > /bz >=20 --------------enigC6E4F7F37CDABE2B10BCA50A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk73cZ4ACgkQwcJ4iSZ1q2mK9QCdGWa9AbInBY6UIoMvENYDtffF zngAn30PDes9RRdzqSPIHKZPKCsVxhVH =2B3J -----END PGP SIGNATURE----- --------------enigC6E4F7F37CDABE2B10BCA50A-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 19:20:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBC9106566B; Sun, 25 Dec 2011 19:20:39 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 294118FC0C; Sun, 25 Dec 2011 19:20:39 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8CF4525D37C3; Sun, 25 Dec 2011 19:20:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 597DCBD7C5B; Sun, 25 Dec 2011 19:20:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id bS3L1snqkRa0; Sun, 25 Dec 2011 19:20:34 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E4C2EBD7C5A; Sun, 25 Dec 2011 19:20:33 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4EF7719A.8020902@FreeBSD.org> Date: Sun, 25 Dec 2011 19:20:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <762A1F72-F7F2-4076-BD9B-49E0DDE32643@lists.zabbadoz.net> References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> <1413850829.20111225184712@nitronet.pl> <4EF7719A.8020902@FreeBSD.org> To: Alexander V. Chernikov X-Mailer: Apple Mail (2.1084) Cc: Pawel Tyll , "Andrey V. Elsukov" , Jason Hellenthal , freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 19:20:39 -0000 On 25. Dec 2011, at 18:55 , Alexander V. Chernikov wrote: > Bjoern A. Zeeb wrote: >> On 25. Dec 2011, at 17:47 , Pawel Tyll wrote: >>=20 >>> Hi Alexander, >>>=20 >>>> Changes: >>>> * Tables (actually, radix trees) are now created/freed on demand. >>> Does this mean IPFW_TABLES_MAX can now be safely set to = arbitrarily >>> high number that would allow flexible numbering of tables? = Arbitrarily >>> high being 0xFFFFFFFF or some other nice large number that won't = step >>> on my ideas :) > At the moment maximum number of tables remains the same however it is > now possible to define IPFW_TABLES_MAX to 65k without much (memory) > overhead. Since pointer to tables are stored in array, defining 2^32 > tables require 4G * (8+8+1) memory for pointers only. >>=20 >> which also gets us to the point that the man page need to be updated = along >> with the same changes and I cannot see that as part of the diff. > Sure. This is actually the first part of commit, interface table = changes > and proper ipv6 'lookup' keyword support requires another change that > is planned to be committed separately (with man page update) >=20 >=20 > By the way, I see two possible syntax changes for interface tables: changes or additions? Try not to break old config files please if not = needed. >=20 > ipfw add .. skipto tablearg ip from any to any lookup > > or > ipfw add .. skipto tablearg ip from any to any recv|xmit|via table(X) >=20 > Personally I like 'lookup' variant. >=20 >>=20 >> /bz >>=20 >=20 >=20 --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 19:21:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C308106564A for ; Sun, 25 Dec 2011 19:21:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B6EAD8FC13 for ; Sun, 25 Dec 2011 19:21:20 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E3AFB7300B; Sun, 25 Dec 2011 20:37:55 +0100 (CET) Date: Sun, 25 Dec 2011 20:37:55 +0100 From: Luigi Rizzo To: "Alexander V. Chernikov" Message-ID: <20111225193755.GB10707@onelab2.iet.unipi.it> References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> <1413850829.20111225184712@nitronet.pl> <4EF7719A.8020902@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EF7719A.8020902@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: "Andrey V. Elsukov" , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, "Bjoern A. Zeeb" , Pawel Tyll Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 19:21:21 -0000 On Sun, Dec 25, 2011 at 10:55:22PM +0400, Alexander V. Chernikov wrote: > Bjoern A. Zeeb wrote: > > On 25. Dec 2011, at 17:47 , Pawel Tyll wrote: > > > >> Hi Alexander, > >> > >>> Changes: > >>> * Tables (actually, radix trees) are now created/freed on demand. > >> Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily > >> high number that would allow flexible numbering of tables? Arbitrarily > >> high being 0xFFFFFFFF or some other nice large number that won't step > >> on my ideas :) > At the moment maximum number of tables remains the same however it is > now possible to define IPFW_TABLES_MAX to 65k without much (memory) > overhead. Since pointer to tables are stored in array, defining 2^32 > tables require 4G * (8+8+1) memory for pointers only. perhaps you could reuse some of the infrastructure i have for looking up rule numbers -- i keep them sorted into an array (and if i am not mistaken there are generation numbers to validate pointers) so lookups are O(log N) in the worst case, and direct lookups are O(1) after the first attempt. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Dec 25 19:45:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C071065670 for ; Sun, 25 Dec 2011 19:45:11 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 95C268FC13 for ; Sun, 25 Dec 2011 19:45:11 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Reu0M-000DPo-Rc for freebsd-net@freebsd.org; Sun, 25 Dec 2011 20:45:10 +0100 Date: Sun, 25 Dec 2011 20:44:55 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1634551546.20111225204455@nitronet.pl> To: "Alexander V. Chernikov" In-Reply-To: <4EF7719A.8020902@FreeBSD.org> References: <1674097252.20111218125051@nitronet.pl> <4EEDD566.8020609@FreeBSD.org> <20111220163355.GA87584@DataIX.net> <4EF73A4A.3050902@FreeBSD.org> <1413850829.20111225184712@nitronet.pl> <4EF7719A.8020902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org, "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org, Jason Hellenthal Subject: Re: IPFW eXtended tables [Was: Re: IPFW tables, dummynet and IPv6] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 19:45:12 -0000 > At the moment maximum number of tables remains the same however it is > now possible to define IPFW_TABLES_MAX to 65k without much (memory) > overhead. Since pointer to tables are stored in array, defining 2^32 > tables require 4G * (8+8+1) memory for pointers only. 65k is also a good amount. Gives me 10 tables per vlan. :) > By the way, I see two possible syntax changes for interface tables: > ipfw add .. skipto tablearg ip from any to any lookup > > or > ipfw add .. skipto tablearg ip from any to any recv|xmit|via table(X) > Personally I like 'lookup' variant. recv|xmit|via is in the ipfw spirit, so while personal tastes are always important, I would personally keep it consistent. From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 01:51:42 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EF40106564A; Mon, 26 Dec 2011 01:51:42 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 356028FC1B; Mon, 26 Dec 2011 01:51:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQ1pg77081058; Mon, 26 Dec 2011 01:51:42 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQ1pgVE081054; Mon, 26 Dec 2011 01:51:42 GMT (envelope-from eadler) Date: Mon, 26 Dec 2011 01:51:42 GMT Message-Id: <201112260151.pBQ1pgVE081054@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/163482: IP address is not round robined if DNS name has many IPs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 01:51:42 -0000 Synopsis: IP address is not round robined if DNS name has many IPs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Mon Dec 26 01:51:26 UTC 2011 Responsible-Changed-Why: assign http://www.freebsd.org/cgi/query-pr.cgi?pr=163482 From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 01:52:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23A3210656D2; Mon, 26 Dec 2011 01:52:10 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE4438FC14; Mon, 26 Dec 2011 01:52:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQ1q9fs081170; Mon, 26 Dec 2011 01:52:09 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQ1q9GV081166; Mon, 26 Dec 2011 01:52:09 GMT (envelope-from eadler) Date: Mon, 26 Dec 2011 01:52:09 GMT Message-Id: <201112260152.pBQ1q9GV081166@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/163481: freebsd do not add itself to ping route packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 01:52:10 -0000 Synopsis: freebsd do not add itself to ping route packet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Mon Dec 26 01:51:55 UTC 2011 Responsible-Changed-Why: assign http://www.freebsd.org/cgi/query-pr.cgi?pr=163481 From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 07:44:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 651941065673 for ; Mon, 26 Dec 2011 07:44:04 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E010B8FC0A for ; Mon, 26 Dec 2011 07:44:03 +0000 (UTC) Received: by eaaf13 with SMTP id f13so13888922eaa.13 for ; Sun, 25 Dec 2011 23:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=RdSJ49IRyFJPU7ShycpASVt3zA3x7P+DPJ/1xB3Clu4=; b=G3ymCicQCdw9l+MCAdaeWzCCeaFwF1oQx5dF2xA78mNBEIFtu349Oz2BipCUpTgQYr 5gGKjoBF5kS77Iiouc5XsA9LZjsY3ZBpZ/He95La8w46cZpQvLU2+PL2VJ3dFsCYByjT dJq00u6zMKKJoVirtUGUYdeC7skN79Ko50/mc= Received: by 10.205.112.6 with SMTP id eq6mr6183134bkc.16.1324885442788; Sun, 25 Dec 2011 23:44:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.17 with HTTP; Sun, 25 Dec 2011 23:43:21 -0800 (PST) In-Reply-To: <4EF61535.4030507@gmx.com> References: <4EF038B9.5050203@gmx.com> <4EF18D7D.1050609@gmx.com> <4EF61535.4030507@gmx.com> From: saeedeh motlagh Date: Mon, 26 Dec 2011 11:13:21 +0330 Message-ID: To: Nikos Vassiliadis , Alexander Lunev , Alireza Torabi , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: vlan without ip address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 07:44:04 -0000 hi Nikos yes i read it and thank you so much but my problem is not solved yet :(. would you please tell me step by step how should i do to have a vlan freebsd switch? we have four freebsd system as end nodes and one freebsd system as a switch. two of four systems should be the member of vlan10 and two others should be the member of vlan11. consider that the range of ip address for both vlan are the same (192.168.2.0). the ip addresses of vlan10 members are: 192.168.2.28 and 192.168.2.29 the ip addresses of vlan11 members are: 192.168.2.150 and 192.168.2.151 thanks yours On Sat, Dec 24, 2011 at 9:38 PM, Nikos Vassiliadis wrote: > On 12/24/2011 4:09 PM, saeedeh motlagh wrote: > >> hi again and thanks for all your replies >> i've reviewed all suggestions and tested them all but i still haven't >> reached an exact answer to my own scenario. >> if you don't mind i wanna try to explain it more in details. >> >> the simplest scenario is to configure a freebsd box to act as a switch. >> this switch should act as a vlan switch, in case it has to support both >> access ports and trunk ports. >> as we know, when a switch supports vlan access ports, it will tag all >> incoming packets from that access port with the related vlan id. in this >> case, any node can be a member of our vlan by simply connecting it to >> that access port; for sure this end node needs no additional vlan >> configurations, cause its packets will be tagged by the attached switch >> box. >> >> now my problem is that, i configure that freebsd box but it doesn't act >> as expected. and the question is how to solve this problem... >> >> if more details are needed, my testing freebsd box contains four >> gbethernet interfaces; we have four other end points, each connected to >> one of those four interfaces. all these nodes are in the same network >> but in two different vlans. now i wanna know how to configure my freebsd >> box to act as a vlan supported switch. >> >> i'm on a real force to find the answer ASAP so any suggestions would be >> greatly appreciated. >> yours >> > > Hello, > > I have sent you a little template with the commands you should use. > I don't think a can do more than that. The general advices apply: > break the task in smaller pieces > examine each port with tcpdump -e > just connect two nodes on the freebsd switch and see what's going on > > HTH, Nikos > From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 11:07:12 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6148F1065672 for ; Mon, 26 Dec 2011 11:07:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE748FC15 for ; Mon, 26 Dec 2011 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQB7Cnm022560 for ; Mon, 26 Dec 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQB7BRj022558 for freebsd-net@FreeBSD.org; Mon, 26 Dec 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Dec 2011 11:07:11 GMT Message-Id: <201112261107.pBQB7BRj022558@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 11:07:12 -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/163482 net IP address is not round robined if DNS name has many o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 383 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 11:50:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1753B106564A for ; Mon, 26 Dec 2011 11:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DE7F38FC08 for ; Mon, 26 Dec 2011 11:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQBoAqp066060 for ; Mon, 26 Dec 2011 11:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQBoAWY066059; Mon, 26 Dec 2011 11:50:10 GMT (envelope-from gnats) Date: Mon, 26 Dec 2011 11:50:10 GMT Message-Id: <201112261150.pBQBoAWY066059@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: kern/163481: freebsd do not add itself to ping route packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 11:50:11 -0000 The following reply was made to PR kern/163481; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, kes-kes@yandex.ru Cc: Subject: Re: kern/163481: freebsd do not add itself to ping route packet Date: Mon, 26 Dec 2011 11:46:41 +0000 (UTC) Unfortunately there is HTML escapes in there, probably due to non-ASCII characters. Could you please re-mail without that so that it would be parseable? From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 13:34:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C8C106564A; Mon, 26 Dec 2011 13:34:10 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DAB818FC13; Mon, 26 Dec 2011 13:34:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQDY95J066914; Mon, 26 Dec 2011 13:34:09 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQDY9uW066910; Mon, 26 Dec 2011 13:34:09 GMT (envelope-from eadler) Date: Mon, 26 Dec 2011 13:34:09 GMT Message-Id: <201112261334.pBQDY9uW066910@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/163478: [re] interface does not count bytes on interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 13:34:10 -0000 Old Synopsis: interface does not count bytes on interface New Synopsis: [re] interface does not count bytes on interface Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Mon Dec 26 13:33:43 UTC 2011 Responsible-Changed-Why: assign http://www.freebsd.org/cgi/query-pr.cgi?pr=163478 From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 13:43:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A598C106566B for ; Mon, 26 Dec 2011 13:43:47 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC8C8FC15 for ; Mon, 26 Dec 2011 13:43:47 +0000 (UTC) Received: by eekc50 with SMTP id c50so13133419eek.13 for ; Mon, 26 Dec 2011 05:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ees8L+HnAV8+s8HAAuyn24DY0yYxYNv8nYOzmx1EH5E=; b=gqA8l4VPn5dnV/LEw34BSqlwWGrgpYTDJv/nDibHdtoOU2Bz2Ew0VFJftrnRPcccyx +u55i9b0AKVg9l/QiuRSeqiJ2e+nwayeIy0Nyn89Z/GooGQaGq9SJTJx66Mcg1UX6hKQ gxVCPEndAjPayAk7V9Ha/Lik3k+vQrhjA0ftA= MIME-Version: 1.0 Received: by 10.213.28.7 with SMTP id k7mr8262380ebc.11.1324907026342; Mon, 26 Dec 2011 05:43:46 -0800 (PST) Received: by 10.14.96.5 with HTTP; Mon, 26 Dec 2011 05:43:46 -0800 (PST) Date: Mon, 26 Dec 2011 19:13:46 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 13:43:47 -0000 Hello sir/madam, I am new to this. Kindly reply. I am modifying the native ARP version to thwart any ARP Poisoning attack against my machine. I need to save some additional data to achieve my idea. So, My question is, can I do a file read/write operation using C code from within any ARP function (precisely from in_arpinput() function in net/if_ether.c) ? If no, how can I do it? If yes, at what location my files would reside? Can I access those files after system reboot? or it will be in some temporary location and flushed off after every reboot? Thank You. -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 14:34:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 182E8106566B for ; Mon, 26 Dec 2011 14:34:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCA3F8FC17 for ; Mon, 26 Dec 2011 14:34:31 +0000 (UTC) Received: by iadj38 with SMTP id j38so22599686iad.13 for ; Mon, 26 Dec 2011 06:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=nGF2D6r//XBPMVKfYyjXJVt0Tav2vejvq8VccAkP0Q4=; b=Ea3nO16ntVZ4ZzpYRN0k65lXs5kSSojK+aEnDWOv2eKdx1btnbWrn776Q9q91fE/7o DZYvz+L0lzsZGDtnHRrg4J1khOy5j3siDK3Pf5e189o0b299CkjGP8yqzHeNFEQeBv0v k4peurWSvBprLflGaVdF0hN20Uc+EFomY8g+4= Received: by 10.50.45.195 with SMTP id p3mr26339249igm.2.1324910071273; Mon, 26 Dec 2011 06:34:31 -0800 (PST) Received: from DataIX.net (24-247-9-230.dhcp.aldl.mi.charter.com. [24.247.9.230]) by mx.google.com with ESMTPS id g34sm78150175ibk.10.2011.12.26.06.34.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Dec 2011 06:34:29 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pBQEYQEn019468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Dec 2011 09:34:26 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pBQEYL4d019467; Mon, 26 Dec 2011 09:34:21 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Mon, 26 Dec 2011 09:34:21 -0500 From: Jason Hellenthal To: Rajneesh Kumar Message-ID: <20111226143421.GB17435@DataIX.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-net@freebsd.org Subject: Re: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 14:34:32 -0000 See siftr(4). This module writes to a file. On Mon, Dec 26, 2011 at 07:13:46PM +0530, Rajneesh Kumar wrote: > Hello sir/madam, > > I am new to this. Kindly reply. > > I am modifying the native ARP version to thwart any ARP Poisoning attack > against my machine. I need to save some additional data to achieve my idea. > So, My question is, can I do a file read/write operation using C code from > within any ARP function (precisely from in_arpinput() function in > net/if_ether.c) ? > If no, how can I do it? > If yes, at what location my files would reside? Can I access those files > after system reboot? or it will be in some temporary location and flushed > off after every reboot? > Thank You. > > -- > Regards, > Rajneesh > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- ;s =; From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 16:44:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED569106566C for ; Mon, 26 Dec 2011 16:44:08 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA588FC08 for ; Mon, 26 Dec 2011 16:44:08 +0000 (UTC) Received: by eekc50 with SMTP id c50so13329592eek.13 for ; Mon, 26 Dec 2011 08:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=SExwOVt6nulEK0ApR5kG95m8oBzwebF/PUfahtV+fR0=; b=PKzg9T3C2DiMI3KD0UCbca0KnfzeIUFzOjgKQ1ptmt7FEZS9k/lIysqqUpbQvOdVHE kxYaUlxmXqCdUqcUUFJXyn05RmkHJUK/Bi8ctW/dvH9aKPJCwKpYvY1xBrvR2kVxGly0 yYvgoxX1YZ7H00vq4//QSF6v6lVJFGNMiS5jI= MIME-Version: 1.0 Received: by 10.14.123.16 with SMTP id u16mr10108332eeh.30.1324917847380; Mon, 26 Dec 2011 08:44:07 -0800 (PST) Received: by 10.14.96.5 with HTTP; Mon, 26 Dec 2011 08:44:07 -0800 (PST) Date: Mon, 26 Dec 2011 22:14:07 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Which function can allocate memory for a given structure type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 16:44:09 -0000 Hello sir/madam, Please help! I am trying to modify the ARP module. I want to know which function can allocate memory for a given structure type and return me back the same? e.g. I want to have declared a pointer of sockaddr_dl{} type. Now I want to allocate memory to it. How can I do it? Thank You! -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 18:12:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F588106564A for ; Mon, 26 Dec 2011 18:12:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id F2E798FC18 for ; Mon, 26 Dec 2011 18:12:13 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pBQICBY7038527 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Dec 2011 10:12:12 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EF8B91F.5040807@freebsd.org> Date: Mon, 26 Dec 2011 10:12:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Rajneesh Kumar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Which function can allocate memory for a given structure type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 18:12:14 -0000 On 12/26/11 8:44 AM, Rajneesh Kumar wrote: > Hello sir/madam, > > Please help! > I am trying to modify the ARP module. I want to know which function can > allocate memory for a given structure type and return me back the same? > e.g. I want to have declared a pointer of sockaddr_dl{} type. Now I want to > allocate memory to it. How can I do it? > > Thank You! for in-kernel resources, there is a special section (section 9) in the freeBSD man pages.. in this case start with man 9 malloc and fiollow teh "see also" links. here's a link to get you started. http://www.freebsd.org/cgi/man.cgi?query=malloc&sektion=9 From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 19:20:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1E6B106564A for ; Mon, 26 Dec 2011 19:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4A08FC0C for ; Mon, 26 Dec 2011 19:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQJKAex077788 for ; Mon, 26 Dec 2011 19:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQJKAd6077787; Mon, 26 Dec 2011 19:20:10 GMT (envelope-from gnats) Date: Mon, 26 Dec 2011 19:20:10 GMT Message-Id: <201112261920.pBQJKAd6077787@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= Cc: Subject: Re[2]: kern/163481: freebsd do not add itself to ping route packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 19:20:10 -0000 The following reply was made to PR kern/163481; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: "Bjoern A. Zeeb" Cc: bug-followup@FreeBSD.org Subject: Re[2]: kern/163481: freebsd do not add itself to ping route packet Date: Mon, 26 Dec 2011 21:16:07 +0200 Çäðàâñòâóéòå, Bjoern. Âû ïèñàëè 26 äåêàáðÿ 2011 ã., 13:46:41: BAZ> Unfortunately there is HTML escapes in there, probably due to BAZ> non-ASCII characters. Could you please re-mail without that BAZ> so that it would be parseable? screen shot http://piccy.info/view3/2409865/88357f995c395d5eb93428ddd4cfc932/ -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 19:53:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73EEC106566C for ; Mon, 26 Dec 2011 19:53:16 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 37C138FC0C for ; Mon, 26 Dec 2011 19:53:15 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 188582280C for ; Mon, 26 Dec 2011 19:53:15 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id 8F658101AED68 for ; Mon, 26 Dec 2011 19:53:21 +0000 (GMT) Message-ID: <4EF8D0A2.5010604@rewt.org.uk> Date: Mon, 26 Dec 2011 19:53:06 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 19:53:16 -0000 Hi guys, Hope you're all enjoying the holiday. Is anyone using bsnmpd with vlan interfaces? I see the following: ifOutOctets.10 = Counter32: 0 ifOutOctets.11 = Counter32: 3061 ifOutOctets.12 = Counter32: 0 ifOutOctets.13 = Counter32: 0 The ones with 0 are vlan interfaces, everything else is fine - is this a known issue or am I doing something wrong? Thanks, Joe From owner-freebsd-net@FreeBSD.ORG Mon Dec 26 20:25:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D225106564A for ; Mon, 26 Dec 2011 20:25:37 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [IPv6:2a02:6b8:0:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id 7503C8FC08 for ; Mon, 26 Dec 2011 20:25:36 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward14.mail.yandex.net (Yandex) with ESMTP id 953E91981BC3; Tue, 27 Dec 2011 00:25:35 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324931135; bh=1lyGtbPmauCVRkXVXigS7bUrBQxJr33wLHw+WNojqiA=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VdnBOqX58PGsPw6ML3qJbdToXOASOFP5m2OoP9xwRhGTXxN7cb47/vloT5jv9ETs9 9PMWGuAu42Vn/cumZHoP/AV+Vpwob5VAVqo8W3gEUnMdE3XZx47cxrqEocvTJanD7E dwCFZziLngqAzWRaC/Bc8YKCIwLM3+26+Ys29ha8= Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 70C551B603E4; Tue, 27 Dec 2011 00:25:35 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1324931135; bh=1lyGtbPmauCVRkXVXigS7bUrBQxJr33wLHw+WNojqiA=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VdnBOqX58PGsPw6ML3qJbdToXOASOFP5m2OoP9xwRhGTXxN7cb47/vloT5jv9ETs9 9PMWGuAu42Vn/cumZHoP/AV+Vpwob5VAVqo8W3gEUnMdE3XZx47cxrqEocvTJanD7E dwCFZziLngqAzWRaC/Bc8YKCIwLM3+26+Ys29ha8= Received: from unknown (unknown [77.93.52.20]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id PYHCC0PI-PZHm9F4E; Tue, 27 Dec 2011 00:25:35 +0400 X-Yandex-Spam: 1 Date: Mon, 26 Dec 2011 22:25:32 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <7910609468.20111226222532@yandex.ru> To: Joe Holden In-Reply-To: <4EF8D0A2.5010604@rewt.org.uk> References: <4EF8D0A2.5010604@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 20:25:37 -0000 Çäðàâñòâóéòå, Joe. Âû ïèñàëè 26 äåêàáðÿ 2011 ã., 21:53:06: JH> Hi guys, JH> Hope you're all enjoying the holiday. JH> Is anyone using bsnmpd with vlan interfaces? I see the following: JH> ifOutOctets.10 = Counter32: 0 JH> ifOutOctets.11 = Counter32: 3061 JH> ifOutOctets.12 = Counter32: 0 JH> ifOutOctets.13 = Counter32: 0 JH> The ones with 0 are vlan interfaces, everything else is fine - is this a JH> known issue or am I doing something wrong? This is mine PR http://www.freebsd.org/cgi/query-pr.cgi?pr=163478 any utilies does not show outoctets for vlan interfaces. but show packets =) -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 00:54:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DF91065670 for ; Tue, 27 Dec 2011 00:54:43 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 33E168FC0C for ; Tue, 27 Dec 2011 00:54:43 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfLJS-000EFJ-CZ for freebsd-net@freebsd.org; Tue, 27 Dec 2011 01:54:42 +0100 Date: Tue, 27 Dec 2011 01:54:31 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1498545030.20111227015431@nitronet.pl> To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Subject: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 00:54:43 -0000 Hi lists, Are there any profiling tools in the system or ports that would allow me to determine how much processing is being done per packet and how long does it take? I would like to predict possible PPS load for my system and perhaps locate and remove some bottlenecks. Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces without much latency increase, when running on modern hardware with Intel NICs? Majority of processing tasks would probably be setfib according to matches in tables. Pawel. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 03:12:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9267F1065670 for ; Tue, 27 Dec 2011 03:12:54 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 284398FC0A for ; Tue, 27 Dec 2011 03:12:53 +0000 (UTC) Received: by eekc50 with SMTP id c50so13645625eek.13 for ; Mon, 26 Dec 2011 19:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=DNC3rX+sanN8D6lF/Z7b8ELu78JQZIfDen6pCsaRoSw=; b=KpG9SoiKlLr3ypI3f+sRTsE2ACBpPLBl4E/3khwqaiaAesCyI9xPHisB3H3g2kMssv DOYqWzElpR2vibl7C4fyEGTqKIUcy8NMLjzU85/iqrwQUWjlEkuqw7Ff948ww5eDx8NO /83agrJy7Ta7fEXy4QuSmOU3JSVFXnxwZtAtE= MIME-Version: 1.0 Received: by 10.213.28.7 with SMTP id k7mr8653296ebc.11.1324955573261; Mon, 26 Dec 2011 19:12:53 -0800 (PST) Received: by 10.14.96.5 with HTTP; Mon, 26 Dec 2011 19:12:52 -0800 (PST) Date: Tue, 27 Dec 2011 08:42:52 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Failed to compile kernel because ioctl.h not found X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 03:12:54 -0000 Hi list, I did slight modification in ARP module of 4.4FreeBSD-Lite (getting help from the book TCP/IP illustrated vol 2 by Richard Stevens). After that I found this kernel is replaced by a new version. I am trying to incorporate those changes in new kernel but facing problem. There was #include in if_ether.c of old module. But its not there in the new one. While compilation it shows me error ioctl.h is not found, please use xxxio.h instead. Which header I should include in place of ioctl.h ?? Also there was a function called arplookup() in if_ether.c but its not there in the new kernel. Which function is now used to perform the same task in the new kernel? Any help would be appreciated. Thank You. -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 03:27:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B7D1065675 for ; Tue, 27 Dec 2011 03:27:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7476D8FC12 for ; Tue, 27 Dec 2011 03:27:26 +0000 (UTC) Received: by iadj38 with SMTP id j38so23717315iad.13 for ; Mon, 26 Dec 2011 19:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YMxhwSkJJ+QHOiCBdeBHtGWfVbepqnhu/fyodrN5SS4=; b=hkgwxuVnySWO+rMyNUKLmnl821r9ufvGH0fOEYdVuZLACrhGC5wzixuo4wsgtJq8Tl v69RP5OqNhTEcQkxKQ2/D5TVW8oeUZHiggK7yHJ6gFPgFKFwXEEXIfW4D+sstINgWUHs ZoQ15NWLO+kK3kVA4ErWoHYV5l4BmY5GqJa7A= Received: by 10.42.180.9 with SMTP id bs9mr27200005icb.0.1324956445738; Mon, 26 Dec 2011 19:27:25 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 36sm84851582ibc.6.2011.12.26.19.27.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Dec 2011 19:27:25 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 26 Dec 2011 19:25:29 -0800 From: YongHyeon PYUN Date: Mon, 26 Dec 2011 19:25:29 -0800 To: Joe Holden Message-ID: <20111227032528.GA1844@michelle.cdnetworks.com> References: <4EF8D0A2.5010604@rewt.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <4EF8D0A2.5010604@rewt.org.uk> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 03:27:26 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 26, 2011 at 07:53:06PM +0000, Joe Holden wrote: > Hi guys, > > Hope you're all enjoying the holiday. > > Is anyone using bsnmpd with vlan interfaces? I see the following: > > ifOutOctets.10 = Counter32: 0 > ifOutOctets.11 = Counter32: 3061 > ifOutOctets.12 = Counter32: 0 > ifOutOctets.13 = Counter32: 0 > > The ones with 0 are vlan interfaces, everything else is fine - is this a > known issue or am I doing something wrong? Try attached patch and let me know how it goes. > > Thanks, > Joe --5mCyUwZo2JvN/JJP Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="vlan.diff" Index: sys/net/if_vlan.c =================================================================== --- sys/net/if_vlan.c (revision 228906) +++ sys/net/if_vlan.c (working copy) @@ -1012,10 +1012,12 @@ { struct ifvlan *ifv; struct ifnet *p; - int error; + int error, len, mcast; ifv = ifp->if_softc; p = PARENT(ifv); + len = m->m_pkthdr.len; + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; BPF_MTAP(ifp, m); @@ -1025,7 +1027,7 @@ */ if (!UP_AND_RUNNING(p)) { m_freem(m); - ifp->if_collisions++; + ifp->if_oerrors++; return (0); } @@ -1081,9 +1083,11 @@ * Send it, precisely as ether_output() would have. */ error = (p->if_transmit)(p, m); - if (!error) + if (!error) { ifp->if_opackets++; - else + ifp->if_omcasts += mcast; + ifp->if_obytes += len; + } else ifp->if_oerrors++; return (error); } --5mCyUwZo2JvN/JJP-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 04:05:53 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBFAE106564A; Tue, 27 Dec 2011 04:05:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3538FC12; Tue, 27 Dec 2011 04:05:53 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR45q4l024855; Tue, 27 Dec 2011 08:05:52 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR45p64024854; Tue, 27 Dec 2011 08:05:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 08:05:51 +0400 From: Gleb Smirnoff To: YongHyeon PYUN Message-ID: <20111227040551.GH8035@FreeBSD.org> References: <4EF8D0A2.5010604@rewt.org.uk> <20111227032528.GA1844@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111227032528.GA1844@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" , Joe Holden , jhb@FreeBSD.org Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 04:05:53 -0000 On Mon, Dec 26, 2011 at 07:25:29PM -0800, YongHyeon PYUN wrote: Y> Index: sys/net/if_vlan.c Y> =================================================================== Y> --- sys/net/if_vlan.c (revision 228906) Y> +++ sys/net/if_vlan.c (working copy) Y> @@ -1012,10 +1012,12 @@ Y> { Y> struct ifvlan *ifv; Y> struct ifnet *p; Y> - int error; Y> + int error, len, mcast; Y> Y> ifv = ifp->if_softc; Y> p = PARENT(ifv); Y> + len = m->m_pkthdr.len; Y> + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; Y> Y> BPF_MTAP(ifp, m); Y> Y> @@ -1025,7 +1027,7 @@ Y> */ Y> if (!UP_AND_RUNNING(p)) { Y> m_freem(m); Y> - ifp->if_collisions++; Y> + ifp->if_oerrors++; Y> return (0); Y> } Y> Y> @@ -1081,9 +1083,11 @@ Y> * Send it, precisely as ether_output() would have. Y> */ Y> error = (p->if_transmit)(p, m); Y> - if (!error) Y> + if (!error) { Y> ifp->if_opackets++; Y> - else Y> + ifp->if_omcasts += mcast; Y> + ifp->if_obytes += len; Y> + } else Y> ifp->if_oerrors++; Y> return (error); Y> } Thanks, Pyun! You can count me in as reviewer. I have also added jhb@ to Cc, the author of changed code, so that he can review, too. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 04:17:30 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B701F106566B; Tue, 27 Dec 2011 04:17:30 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEA68FC0C; Tue, 27 Dec 2011 04:17:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR4HSvD024919; Tue, 27 Dec 2011 08:17:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR4HSwH024918; Tue, 27 Dec 2011 08:17:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 08:17:28 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20111227041728.GI8035@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201112221130.01823.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Watson , net@FreeBSD.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 04:17:30 -0000 On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: J> You can find the patch for 8.x at J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch Just my two pennies: for head/ patching if ip_carp.c should be straightforward: 1) Using W in carp_alloc_if() and carp_free_if(). 2) Using R everywhere else. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 04:36:18 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45AE81065670 for ; Tue, 27 Dec 2011 04:36:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id BCF638FC0A for ; Tue, 27 Dec 2011 04:36:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR4aGXx025031; Tue, 27 Dec 2011 08:36:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR4aGCo025030; Tue, 27 Dec 2011 08:36:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 08:36:16 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111227043616.GJ8035@FreeBSD.org> References: 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-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 04:36:18 -0000 On Thu, Dec 15, 2011 at 09:51:09PM +0200, Sami Halabi wrote: S> Hi, S> S> I've searched the net andfound basicly 2 threads talking about the message: S> S> ng_mppc_decompress: too many (4094) packets dropped, disabling node S> S> in FBSD 6.3 S> http://lists.freebsd.org/pipermail/freebsd-bugs/2008-April/030183.html its S> a pr 123045 S> and 5.4. http://markmail.org/message/lptpp4qmiwksazxc S> basicly suggested to set define MPPE_MAX_REKEY to a higher values S> and found somewhere a patch that changes it to variable rather than using S> it as macro S> S> i saw no answer indicating this really solves the problem. S> S> did anyone have a solution tothe problem? i'm suffering from it even i have S> about 200 concurrent connections, as i read MPD+FREEBSD usually can utilize S> thousands of sessions. Do you run the node in compression or in encryption mode? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 04:47:57 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46460106566B; Tue, 27 Dec 2011 04:47:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B80C18FC08; Tue, 27 Dec 2011 04:47:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR4ls1p025084; Tue, 27 Dec 2011 08:47:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR4lsB9025083; Tue, 27 Dec 2011 08:47:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 08:47:54 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111227044754.GK8035@FreeBSD.org> References: 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-isp@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 04:47:57 -0000 On Thu, Dec 15, 2011 at 09:51:09PM +0200, Sami Halabi wrote: S> Hi, S> S> I've searched the net andfound basicly 2 threads talking about the message: S> S> ng_mppc_decompress: too many (4094) packets dropped, disabling node S> S> in FBSD 6.3 S> http://lists.freebsd.org/pipermail/freebsd-bugs/2008-April/030183.html its S> a pr 123045 S> and 5.4. http://markmail.org/message/lptpp4qmiwksazxc S> basicly suggested to set define MPPE_MAX_REKEY to a higher values S> and found somewhere a patch that changes it to variable rather than using S> it as macro S> S> i saw no answer indicating this really solves the problem. S> S> did anyone have a solution tothe problem? i'm suffering from it even i have S> about 200 concurrent connections, as i read MPD+FREEBSD usually can utilize S> thousands of sessions. A couple of questions: 1) Is the number always 4094? 2) Have you tried to disable this code, thus never disable node? How this performs? A patch for this is avaliable in http://www.freebsd.org/cgi/query-pr.cgi?pr=123045&cat= -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 05:25:04 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEFCE1065673 for ; Tue, 27 Dec 2011 05:25:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 2A02E8FC0A for ; Tue, 27 Dec 2011 05:25:03 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR5P2si025293; Tue, 27 Dec 2011 09:25:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR5P2Uk025292; Tue, 27 Dec 2011 09:25:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 09:25:02 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111227052502.GL8035@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 05:25:04 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Thu, Dec 15, 2011 at 09:51:09PM +0200, Sami Halabi wrote: S> I've searched the net andfound basicly 2 threads talking about the message: S> S> ng_mppc_decompress: too many (4094) packets dropped, disabling node The 4094 value both in your report and in the old PR look suspicious. Can you please try the attached patch and report which values are logged now. -- Totus tuus, Glebius. --bp/iNruPH9dso1Pn Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="ng_mppc.c.diff" Index: ng_mppc.c =================================================================== --- ng_mppc.c (revision 228838) +++ ng_mppc.c (working copy) @@ -647,9 +647,9 @@ rekey = ((d->cfg.bits & MPPE_STATELESS) != 0) ? numLost : (numLost / (MPPE_UPDATE_MASK + 1)); if (rekey > MPPE_MAX_REKEY) { - log(LOG_ERR, "%s: too many (%d) packets" + log(LOG_ERR, "%s: too many (%u %u) packets" " dropped, disabling node %p!", - __func__, numLost, node); + __func__, cc, d->cc, node); priv->recv.cfg.enable = 0; goto failed; } --bp/iNruPH9dso1Pn-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 06:13:17 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A985B106566C for ; Tue, 27 Dec 2011 06:13:17 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 8289C8FC0A for ; Tue, 27 Dec 2011 06:13:17 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pBR6D7qS029167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Dec 2011 22:13:10 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id pBR6D7QO029166; Mon, 26 Dec 2011 22:13:07 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA27125; Mon, 26 Dec 11 22:11:59 PST Date: Tue, 27 Dec 2011 05:11:59 -0800 From: perryh@pluto.rain.com To: jhell@DataIX.net Message-Id: <4ef9c41f.rC8YkQQx738CJ3EN%perryh@pluto.rain.com> References: <20111226143421.GB17435@DataIX.net> In-Reply-To: <20111226143421.GB17435@DataIX.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: iwc2010005@gmail.com, freebsd-net@freebsd.org Subject: Re: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:13:17 -0000 Jason Hellenthal wrote: > > See siftr(4). This module writes to a file. Is siftr(4) new since 8.1? $ man siftr No manual entry for siftr $ cd /usr/ports $ ls -d */*siftr* ls: */*siftr*: No such file or directory From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 06:23:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F584106564A for ; Tue, 27 Dec 2011 06:23:25 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4818FC0C for ; Tue, 27 Dec 2011 06:23:24 +0000 (UTC) Received: by eekc50 with SMTP id c50so13714397eek.13 for ; Mon, 26 Dec 2011 22:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=OA+sU0nSdO9smd6K+t9swoMO3R/YUDzUMuMvbvgJrCM=; b=XD1HbvVBQ9vON3HK8H0yZT0thMOH+2wZ9y/F2RgGWuT2AXkDknDk9Kvx6zOpJfmOgj VrW80CHpxdSyIvdQxRck9tBXgeaYSXphywlO/Q12sxSCQHVoRE/VzzTUSpKdSkgAV8jg E8E51jl0IDoyNh4LM7ShzhQpPil5WiN0UOYss= MIME-Version: 1.0 Received: by 10.213.28.7 with SMTP id k7mr8755210ebc.11.1324967003255; Mon, 26 Dec 2011 22:23:23 -0800 (PST) Received: by 10.14.96.5 with HTTP; Mon, 26 Dec 2011 22:23:23 -0800 (PST) Date: Tue, 27 Dec 2011 11:53:23 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:23:25 -0000 Hi list, During my development, I want to check if my modules compile successfully or not. I am only changing the ARP portion and whenever I compile my kernel, it takes around 20mins and compiles all different modules also. I just want to compile and check whether my ARP modules, which I have changed, compile fine or not. How to do it? -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 06:35:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF0C1106564A for ; Tue, 27 Dec 2011 06:35:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC638FC0A for ; Tue, 27 Dec 2011 06:35:35 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so15564072vcb.13 for ; Mon, 26 Dec 2011 22:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Vu3orE8llaknCzsHa2O/S+6sHgqz0og1270ueCEgrv8=; b=dr1aFrMa1qy2XOFHNwG/YgGkIX6KWWBA2TQIDId2oC+81UuJPpuYd22GABM7ddARna D1Rddh3+2vRVGt+xbNPUY67jPGWPBRU0aFAmQDzC4xQGdNxlQLZlsTXocDdHEh4OfYr4 4HAMmgGT0TMW3MU/mb8jV3tAwTVwR5Y5os5cw= MIME-Version: 1.0 Received: by 10.220.149.193 with SMTP id u1mr15732565vcv.33.1324967733044; Mon, 26 Dec 2011 22:35:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Mon, 26 Dec 2011 22:35:33 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Dec 2011 22:35:33 -0800 X-Google-Sender-Auth: IzHLgGkxPx8VHfgwp6jSUfnx5Rg Message-ID: From: Adrian Chadd To: Rajneesh Kumar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:35:35 -0000 Shouldn't just a normal "make" in the kernel config directory only rebuild those parts that have changed? Adrian On 26 December 2011 22:23, Rajneesh Kumar wrote: > Hi list, > > During my development, I want to check if my modules compile successfully > or not. I am only changing the ARP portion and whenever I compile my > kernel, it takes around 20mins and compiles all different modules also. > I just want to compile and check whether my ARP modules, which I have > changed, compile fine or not. How to do it? > > -- > Regards, > Rajneesh > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 06:40:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B9A1065670 for ; Tue, 27 Dec 2011 06:40:25 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56F1A8FC08 for ; Tue, 27 Dec 2011 06:40:24 +0000 (UTC) Received: by werb13 with SMTP id b13so10199632wer.13 for ; Mon, 26 Dec 2011 22:40:24 -0800 (PST) Received: by 10.216.136.204 with SMTP id w54mr20349352wei.44.1324968024217; Mon, 26 Dec 2011 22:40:24 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Mon, 26 Dec 2011 22:40:03 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Mon, 26 Dec 2011 22:40:03 -0800 X-Google-Sender-Auth: vp6H0EJmsGKWYUkPVDMXfO-HWHA Message-ID: To: Rajneesh Kumar Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:40:25 -0000 On Mon, Dec 26, 2011 at 22:23, Rajneesh Kumar wrote: > During my development, I want to check if my modules compile successfully > or not. I am only changing the ARP portion and whenever I compile my > kernel, it takes around 20mins and compiles all different modules also. > I just want to compile and check whether my ARP modules, which I have > changed, compile fine or not. How to do it? You need to tell us what process you are using so we can give an example that best fits your existing workflow. There are ways we suggest for users and ways developers use, and it would be a shame to give you irrelevant suggestions. If you're using "make buildkernel" then you can add -DNO_CLEAN (or perhaps it's -DNOCLEAN) to avoid cleaning out the object directory first. This will keep dependencies up-to-date for you, and only rebuild what's necessary. What may be better, if you don't need a cross-compiler, is to do the kernel configuration by hand. So you might do something like: cd /path/to/src/sys/amd64/conf config GENERIC cd ../compile/GENERIC make depend make kernel And then when you make changes you can just do "make kernel". If you make a change that requires rerunning config(8), it will tell you to do "make cleandepend && make depend" or something like that first, to fix header and option dependencies that may not exist with your new configuration. Hopefully one of those two things will help, as anything else you might be doing is probably based on one of those processes, but if not you should let us know what you're doing now. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 06:44:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E5F106564A; Tue, 27 Dec 2011 06:44:04 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from procyon.xvoid.org (procyon.xvoid.org [IPv6:2001:470:28:4ba:20c:29ff:feb6:11bc]) by mx1.freebsd.org (Postfix) with ESMTP id A18A98FC15; Tue, 27 Dec 2011 06:44:03 +0000 (UTC) Received: from procyon.xvoid.org (yuri@procyon.xvoid.org [IPv6:::1]) by procyon.xvoid.org (8.14.5/8.14.5) with ESMTP id pBR6i11D010028; Tue, 27 Dec 2011 10:44:01 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.5/8.14.5/Submit) id pBR6i1Fo010027; Tue, 27 Dec 2011 10:44:01 +0400 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Tue, 27 Dec 2011 10:44:01 +0400 From: Yuri Pankov To: Adrian Chadd Message-ID: <20111227064401.GB4177@procyon.xvoid.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rajneesh Kumar , freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:44:04 -0000 On Mon, Dec 26, 2011 at 10:35:33PM -0800, Adrian Chadd wrote: > On 26 December 2011 22:23, Rajneesh Kumar wrote: > > Hi list, > > > > During my development, I want to check if my modules compile successfully > > or not. I am only changing the ARP portion and whenever I compile my > > kernel, it takes around 20mins and compiles all different modules also. > > I just want to compile and check whether my ARP modules, which I have > > changed, compile fine or not. How to do it? > > Shouldn't just a normal "make" in the kernel config directory only > rebuild those parts that have changed? It also does a lot of cleanup and stuff, which can be skipped using -DKERNFAST (which in turn defines NO_KERNEL{CONFIG,CLEAN,DEPEND,OBJ}), if you know what you are doing. This is all described in Makefile.inc1. There's also MODULES_OVERRIDE (described in make.conf(5)), and, of course, sys/modules/ :-) Yuri From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 07:38:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD2C106567C for ; Tue, 27 Dec 2011 07:38:54 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id B9A088FC12 for ; Tue, 27 Dec 2011 07:38:53 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id pBR7caLx034687; Tue, 27 Dec 2011 14:38:36 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4EF975FC.5080604@rdtc.ru> Date: Tue, 27 Dec 2011 14:38:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20111226143421.GB17435@DataIX.net> <4ef9c41f.rC8YkQQx738CJ3EN%perryh@pluto.rain.com> In-Reply-To: <4ef9c41f.rC8YkQQx738CJ3EN%perryh@pluto.rain.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: iwc2010005@gmail.com, jhell@DataIX.net, freebsd-net@freebsd.org Subject: Re: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:38:54 -0000 27.12.2011 20:11, perryh@pluto.rain.com ÐÉÛÅÔ: > Jason Hellenthal wrote: >> >> See siftr(4). This module writes to a file. > > Is siftr(4) new since 8.1? > > $ man siftr > No manual entry for siftr > $ cd /usr/ports > $ ls -d */*siftr* > ls: */*siftr*: No such file or directory HISTORY SIFTR first appeared in FreeBSD 7.4 and FreeBSD 8.2. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 07:44:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15DE106564A for ; Tue, 27 Dec 2011 07:44:26 +0000 (UTC) (envelope-from 3gW35Tg4JC74qywxivmhiwxio6kqemp.gsqjviifwh-rixjviifwh.svk@M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com) Received: from mail-qw0-f80.google.com (mail-qw0-f80.google.com [209.85.216.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA9C8FC15 for ; Tue, 27 Dec 2011 07:44:26 +0000 (UTC) Received: by qadb40 with SMTP id b40so6219216qad.7 for ; Mon, 26 Dec 2011 23:44:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.215.10 with SMTP id hc10mr54854727qab.8.1324969345678; Mon, 26 Dec 2011 23:02:25 -0800 (PST) X-Google-Appengine-App-Id: s~musteridestek2 Message-ID: <20cf300fafbf30163804b50d7766@google.com> Date: Tue, 27 Dec 2011 07:02:25 +0000 From: Merhaba-musteri-destek-9WR2WISWL7VK@musteridestek2.appspotmail.com To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fw:inanilmaz Fiyatlar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:44:27 -0000 R8O2csO8bnTDvGxlbWVrIMSww6dpbiBUbEtMQVlsTi4NCg0KDQpUaGUgQmVhdGxlcw0KDQoNCiBG cm9tIDE5NjMgdG8gMTk3MCwgVGhlIEJlYXRsZXMgcmVsZWFzZWQgYSBzdHJpbmcgb2YgaWNvbmlj IGFsYnVtcyDigJQgYW5kICANCnRoZWlyIGluZmx1ZW5jZSBjb250aW51ZXMgdG8gcmV2ZXJiZXJh dGUgdGhyb3VnaCBtdXNpYyB0b2RheS4gTm93LCBhbGwgb2YgIA0KdGhvc2Ugc3R1ZGlvIGFsYnVt cywgYXMgd2VsbCBhcyB0aGUgcmVtYXJrYWJsZSBjb21waWxhdGlvbiBvZiBOby4gMSBoaXRzLCAg DQoxLCBhcmUgYXZhaWxhYmxlIGZyb20gJDkuOTkgZm9yIGEgbGltaXRlZCB0aW1lLiBQbHVzLCB3 YXRjaCBhIHN0cmVhbWluZyAgDQp2aWRlbyBvZiB0aGUgbmV3ZXN0IEJlYXRsZXMgVFYgc3BvdCBh bmQgYSBzaG9ydCBvdmVydmlldyBvZiB0aGUgYmFuZCdzICANCm11c2ljIGFuZCBoaXN0b3J5Lg0K DQoNCg0KQ2hlY2sgSXQgT3V0IEdvDQoNCg0KDQoNCg0KR3JlYXQgQWxidW1zLCBHcmVhdCBQcmlj ZXMNCg0KR2V0IHNvbWUgb2YgMjAxMSdzIG1vc3QgZXhjaXRpbmcgY2hhcnQtdG9wcGVycyDigJQg aW5jbHVkaW5nIG11c2ljIGZyb20gIA0KQ29sZHBsYXksIEZvbyBGaWdodGVycywgYW5kIEJyaXRu ZXkgU3BlYXJzIOKAlCBhbG9uZyB3aXRoIGEgaG9zdCBvZiBjbGFzc2ljICANCmhpdHMgZnJvbSBw b3AgbWFzdGVycyBFbHRvbiBKb2huLCBOZWlsIERpYW1vbmQsIGFuZCBtb3JlLiBFYWNoIGFsYnVt IGlzICANCmp1c3QgJDcuOTkgZm9yIGEgbGltaXRlZCB0aW1lLg0KDQoNCg0KQ2hlY2sgSXQgT3V0 IEdvDQoNCg0KDQpDaGFydCBUb3BwZXJzDQoNCg0KDQoNCg0KDQpHdWlkZWQgQnkgVm9pY2VzIFRo ZSBHaXJsIFdpdGggdGhlIERyYWdvbiBUYXR0b28gVGhlIEZyYXkNCg0KDQoNCg0KDQpBcHAgU3Rv cmUgUmV3aW5kIDIwMTENCg0KVGhpcyB5ZWFyIHdhcyBmaWxsZWQgc29tZSBhbWF6aW5nIGFwcHMu IEZpbmQgb3V0IHdoaWNoIG9uZXMgd2UgY2hvc2UgYXMgdGhlICANCmJlc3QuIFN0cmVhbSB2aWRl byB0cmFpbGVycyBvZiBvdXIgQXBwIG9mIHRoZSBZZWFyIGFuZCBHYW1lIG9mIHRoZSBZZWFyIGZv ciAgDQppUGhvbmUgYW5kIGlQYWQgZnJvbSB5b3VyIGNvbXB1dGVyLCBicm93c2UgdGhlIHllYXIn cyB0b3AgZG93bmxvYWRzLCBhbmQgIA0KbW9yZS4NCg0KDQoNCkFwcHMgZm9yIGlQaG9uZSBHbw0K DQoNCg0KDQoNCkFwcHMgZm9yIGlQYWQgR28NCg0KDQoNCkFwcCBTdG9yZSBSZXdpbmQgMjAxMQ0K DQoNCg0KDQoNCg0KSGlwc3RhbWF0aWMgRGlzcG9zYWJsZSBBcHBsZSBBcHBzIEdyYW5kIFRoZWZ0 IEF1dG8gMw0KDQoNCg0KDQoNCk1vbmV5YmFsbA0KDQpCcmFkIFBpdHQgdHVybmVkIGluIG9uZSBv ZiB0aGUgYmVzdCBwZXJmb3JtYW5jZXMgb2YgdGhlIHllYXIgaW4gdGhpcyAgDQplbmdyb3NzaW5n LCByZWFsLWxpZmUgZHJhbWEgYWJvdXQgYSBtYWpvciBsZWFndWUgYmFzZWJhbGwgdGVhbSdzIGdl bmVyYWwgIA0KbWFuYWdlciBmaWdodGluZyBhZ2FpbnN0IHRoZSBzeXN0ZW0gdG8gYnVpbGQgYSB3 aW5uaW5nIHRlYW0uDQoNCg0KDQpDaGVjayBJdCBPdXQgR28NCg0KDQoNCk1vbmV5YmFsbA0KDQoN Cg0KDQoNCg0KR3JlYXQgRmlsbXMgYXQgR3JlYXQgUHJpY2VzIEF2YXRhciBNaWRuaWdodCBpbiBQ YXJpcw0KDQoNCg0KDQoNCkNvbXBsZXRlIE15IFNlYXNvbg0KDQpOb3cgd2hlbiB5b3UndmUgYm91 Z2h0IGluZGl2aWR1YWwgZXBpc29kZXMgb2YgYSBUViBzaG93LCB0aGUgYW1vdW50IHlvdSd2ZSAg DQphbHJlYWR5IHNwZW50IG9uIGVwaXNvZGVzIGlzIGRlZHVjdGVkIGZyb20gdGhlIG92ZXJhbGwg cHJpY2Ugb2YgdGhlIHNlYXNvbiAgDQpvciBTZWFzb24gUGFzcy4NCg0KDQoNCkNoZWNrIEl0IE91 dCBHbw0KDQoNCg0KQ29tcGxldGUgTXkgU2Vhc29uDQoNCg0KDQoNCg0KDQpBcnJlc3RlZCBEZXZl bG9wbWVudCBQYW4gQW0gSG9saWRheSBUViBTaG93cw0KDQoNCg0KDQoNCkhvbGlkYXkgQ2hpbGRy ZW4ncyBCb29rcyBPbGQgVGltZSBSYWRpbyBQb2RjYXN0IFJlZGVlbSBpVHVuZXMgR2lmdCBDYXJk cw0KDQoNCg0KDQoNCkluc2lkZSBpVHVuZXMNCg0KDQoNCk5ldyBNdXNpYw0KDQoNCg0KDQoNClRo ZSBEcmVhbWVyLCBUaGUgQmVsaWV2ZXINCg0KDQoNCg0KDQpUaGUgRHJlYW1lciwgVGhlIEJlbC4u Lg0KDQpDb21tb24NCg0KDQoNCg0KV2lsZCBPbmVzIChmZWF0LiBTaWEpIC0gU2luZ2xlDQoNCg0K DQoNCg0KV2lsZCBPbmVzIChmZWF0LiBTaWEuLi4NCg0KRmxvIFJpZGENCg0KDQoNCg0KUmlnaHQg QmFjayBBdGNoYSBCYWJlIC0gU2luZ2xlDQoNCg0KDQoNCg0KUmlnaHQgQmFjayBBdGNoYSBCYWIu Li4NCg0KVGltIE1jR3Jhdw0KDQoNCg0KDQpKVUlDRQ0KDQoNCg0KDQoNCkpVSUNFDQoNClJvc2Nv ZSBEYXNoDQoNCg0KDQoNClRNOjEwMyBIdXN0bGVyeiBBbWJpdGlvbiAoRGVsdXhlIFZlcnNpb24p DQoNCg0KDQoNCg0KVE06MTAzIEh1c3RsZXJ6IEFtYmkuLi4NCg0KWW91bmcgSmVlenkNCg0KDQoN Cg0KTmFrZWQgLSBTaW5nbGUNCg0KDQoNCg0KDQpOYWtlZCAtIFNpbmdsZQ0KDQpEZXYgJiBFbnJp cXVlIElnbGVzaWFzDQoNCg0KDQoNCkJldHRlciBUaGFuIEkgS25vdyBNeXNlbGYgLSBTaW5nbGUN Cg0KDQoNCg0KDQpCZXR0ZXIgVGhhbiBJIEtub3cgTS4uLg0KDQpBZGFtIExhbWJlcnQNCg0KDQoN Cg0KVGltZSBJcyBMb3ZlIC0gU2luZ2xlDQoNCg0KDQoNCg0KVGltZSBJcyBMb3ZlIC0gU2luZ2xl DQoNCkpvc2ggVHVybmVyDQoNCg0KDQoNCkV2ZXJ5Ym9keSBUYWxrcyAtIFNpbmdsZQ0KDQoNCg0K DQoNCkV2ZXJ5Ym9keSBUYWxrcyAtIFNpLi4uDQoNCk5lb24gVHJlZXMNCg0KDQoNCg0KTmV3IFlv cmsgLSBTaW5nbGUNCg0KDQoNCg0KDQpOZXcgWW9yayAtIFNpbmdsZQ0KDQpTbm93IFBhdHJvbA0K DQoNCg0KDQoNCg0KDQoNCk5vLiAxIEFsYnVtDQoNCg0KDQoNCg0KVE06MTAzIEh1c3RsZXJ6IEFt Yml0aW9uIChEZWx1eGUgVmVyc2lvbikNCg0KDQoNCg0KDQpUTToxMDMgSHVzdGxlcnogQW1iaXRp b24NCihEZWx1eGUgVmVyc2lvbikNCg0KWW91bmcgSmVlenkNCg0KDQoNCg0KDQoNCg0KDQpWaWRl byBTcG90bGlnaHQNCg0KDQoNCg0KDQpTdHJhdyBEb2dzDQoNCg0KDQoNCg0KU3RyYXcgRG9ncw0K DQppVHVuZXMgRXh0cmFzDQoNCg0KDQoNCkRvbHBoaW4gVGFsZQ0KDQoNCg0KDQoNCkRvbHBoaW4g VGFsZQ0KDQpOZXcgUmVsZWFzZSBNb3ZpZQ0KDQoNCg0KDQozMCBSb2NrLCBTZWFzb24gNg0KDQoN Cg0KDQoNCjMwIFJvY2sNCg0KU25lYWsgUGVlaw0KDQoNCg0KDQpBIENoYXJsaWUgQnJvd24gQ2hy aXN0bWFzDQoNCg0KDQoNCg0KQSBDaGFybGllIEJyb3duIENocmlzdG1hcw0KDQpTcGVjaWFscyAr IE1vcmUNCg0KDQoNCg0KDQpUaGUgaVR1bmVzIFN0b3JlLCBpQm9va3N0b3JlLCBhbmQgQXBwIFN0 b3JlIGFyZSBhdmFpbGFibGUgb25seSB0byBwZXJzb25zICANCmFnZSAxMyBvciBvbGRlciBhbmQg aW4gdGhlIFVTIGlUdW5lcyAxMCBvciBsYXRlciwgY29tcGF0aWJsZSBoYXJkd2FyZSBhbmQgIA0K c29mdHdhcmUsIGFuZCBJbnRlcm5ldCBhY2Nlc3MgKGZlZXMgbWF5IGFwcGx5KSBhcmUgcmVxdWly ZWQuIEJvb2tzIHJlcXVpcmUgIA0KaUJvb2tzIDEuNSBvbiBhIGRldmljZSB3aXRoIGlPUyA0LjIg b3IgbGF0ZXIuIFNvbWUgY29udGVudCBoYXMgc3BlY2lmaWMgIA0KaGFyZHdhcmUgb3Igc29mdHdh cmUgcmVxdWlyZW1lbnRzOyBwbGVhc2UgcmV2aWV3IHByb2R1Y3QgaW5mb3JtYXRpb24gYmVmb3Jl ICANCnB1cmNoYXNpbmcuIEZ1bGwgdGVybXMgYXBwbHksIGF2YWlsYWJsZSBhdCAgDQp3d3cuYXBw bGUuY29tL2xlZ2FsL2l0dW5lcy91cy90ZXJtcy5odG1sLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBz ZWUgIA0Kd3d3LmFwcGxlLmNvbS9pdHVuZXMvLiBDb250ZW50IHByaWNlcyBhbmQgYXZhaWxhYmls aXR5IHN1YmplY3QgdG8gY2hhbmdlICANCmFuZCBkbyBub3QgaW5jbHVkZSB0YXhlcy4NCg0KaVR1 bmVzIGZvciBNYWMgYW5kIFdpbmRvd3MNCg0KQ29weXJpZ2h0IMKpIDIwMTEgQXBwbGUgSW5jLiAx IEluZmluaXRlIExvb3AsIEN1cGVydGlubywgQ0EgOTUwMTQNCkFsbCByaWdodHMgcmVzZXJ2ZWQg 4oCiIFByaXZhY3kgUG9saWN5IOKAoiBUZXJtcyBhbmQgQ29uZGl0aW9ucw0KaVR1bmVzIFN0b3Jl IEN1c3RvbWVyIFNlcnZpY2Ug4oCiIERvd25sb2FkIGlUdW5lcw0KU3Vic2NyaWJlIOKAoiBVbnN1 YnNjcmliZQ0KDQoNCg0KDQoNCg0KDQowDQoNCg0K From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 07:45:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C8051065672 for ; Tue, 27 Dec 2011 07:45:54 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5718E8FC0A for ; Tue, 27 Dec 2011 07:45:54 +0000 (UTC) Received: by iadj38 with SMTP id j38so24198356iad.13 for ; Mon, 26 Dec 2011 23:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Slkgs1rRS7ToMOiCpi2w3b3Uh7WrJm5U+qNGsjCkQ9Y=; b=L+o7yOeyR4uUIw5MKH6edCMvigNmfb5/rtB5xTffIP1r9gTEYD9EFUo0CO8LrY1g+I o//ouYoGMdnoeC+WC3AAVUyfVvLmcgznGxbEfWVmBtsZZh/2CZdVYNQ7SWufoqPNZc5O KuXb0yU0QwXfnjBw5rXaVuVGml4pxM9YiKW5c= MIME-Version: 1.0 Received: by 10.42.153.6 with SMTP id k6mr28218281icw.30.1324971953917; Mon, 26 Dec 2011 23:45:53 -0800 (PST) Received: by 10.231.41.206 with HTTP; Mon, 26 Dec 2011 23:45:53 -0800 (PST) In-Reply-To: <20111227043616.GJ8035@FreeBSD.org> References: <20111227043616.GJ8035@FreeBSD.org> Date: Tue, 27 Dec 2011 09:45:53 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:45:54 -0000 Hi, >Do you run the node in compression or in encryption mode? I enabled the compression in the mpd.conf if you mean that so its beoing negotiated, but isee in the mpd portal not all the clients use compression Sami 2011/12/27 Gleb Smirnoff > On Thu, Dec 15, 2011 at 09:51:09PM +0200, Sami Halabi wrote: > S> Hi, > S> > S> I've searched the net andfound basicly 2 threads talking about the > message: > S> > S> ng_mppc_decompress: too many (4094) packets dropped, disabling node > S> > S> in FBSD 6.3 > S> http://lists.freebsd.org/pipermail/freebsd-bugs/2008-April/030183.htmlits > S> a pr 123045 > S> and 5.4. http://markmail.org/message/lptpp4qmiwksazxc > S> basicly suggested to set define MPPE_MAX_REKEY to a higher values > S> and found somewhere a patch that changes it to variable rather than > using > S> it as macro > S> > S> i saw no answer indicating this really solves the problem. > S> > S> did anyone have a solution tothe problem? i'm suffering from it even i > have > S> about 200 concurrent connections, as i read MPD+FREEBSD usually can > utilize > S> thousands of sessions. > > Do you run the node in compression or in encryption mode? > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 07:50:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A102A106566B for ; Tue, 27 Dec 2011 07:50:06 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2FB8FC08 for ; Tue, 27 Dec 2011 07:50:05 +0000 (UTC) Received: by iadj38 with SMTP id j38so24206772iad.13 for ; Mon, 26 Dec 2011 23:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WxjE/vnNQ2UZ5AdaqCRjzFzq9wJO50YzAP6qX5TSbdU=; b=Oeo2vPhytRwBjtdGPzk+nwdeg+m0G6qYguN5l6622x4cfWhhXiXdlfsRZCAWjKINHa pw2U0ylJbMeoYi7BCV7nwanTovVyxeS89jLojTsJKd2d5cUyPK8GEC7YxR0uGatM+Pq3 53H/VCcnyZ4GcGJfzKLtdQzW8OTAFirPC1lW4= MIME-Version: 1.0 Received: by 10.42.153.6 with SMTP id k6mr28232844icw.30.1324972205661; Mon, 26 Dec 2011 23:50:05 -0800 (PST) Received: by 10.231.41.206 with HTTP; Mon, 26 Dec 2011 23:50:05 -0800 (PST) In-Reply-To: References: <20111227044754.GK8035@FreeBSD.org> Date: Tue, 27 Dec 2011 09:50:05 +0200 Message-ID: From: Sami Halabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:50:06 -0000 On Tue, Dec 27, 2011 at 9:44 AM, Sami Halabi wrote: > Hi, > > >1) Is the number always 4094? > > No, i see 4092, 4093 also: > Dec 24 09:17:04 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > dropped > , disabling node 0xffffff003051e400! > Dec 24 09:17:04 mpd2 kernel: > Dec 24 14:22:45 mpd2 kernel: ng_mppc_decompress: too many (4093) packets > dropped > , disabling node 0xffffff003d53db00! > Dec 24 14:22:45 mpd2 kernel: > Dec 24 19:28:45 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > dropped > , disabling node 0xffffff00304e8500! > > > >2) Have you tried to disable this code, thus never disable node? How > >this performs? A patch for this is avaliable in > >http://www.freebsd.org/cgi/query-pr.cgi?pr=123045&cat= > didn't try yet.. should I? i saw later mail by you with patch.... > > Sami > > > 2011/12/27 Gleb Smirnoff > >> On Thu, Dec 15, 2011 at 09:51:09PM +0200, Sami Halabi wrote: >> S> Hi, >> S> >> S> I've searched the net andfound basicly 2 threads talking about the >> message: >> S> >> S> ng_mppc_decompress: too many (4094) packets dropped, disabling node >> S> >> S> in FBSD 6.3 >> S> http://lists.freebsd.org/pipermail/freebsd-bugs/2008-April/030183.htmlits >> S> a pr 123045 >> S> and 5.4. http://markmail.org/message/lptpp4qmiwksazxc >> S> basicly suggested to set define MPPE_MAX_REKEY to a higher values >> S> and found somewhere a patch that changes it to variable rather than >> using >> S> it as macro >> S> >> S> i saw no answer indicating this really solves the problem. >> S> >> S> did anyone have a solution tothe problem? i'm suffering from it even i >> have >> S> about 200 concurrent connections, as i read MPD+FREEBSD usually can >> utilize >> S> thousands of sessions. >> >> A couple of questions: >> >> 1) Is the number always 4094? >> 2) Have you tried to disable this code, thus never disable node? How >> this performs? A patch for this is avaliable in >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123045&cat= >> >> -- >> Totus tuus, Glebius. >> > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 08:42:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4F6A1065673; Tue, 27 Dec 2011 08:42:58 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A20888FC08; Tue, 27 Dec 2011 08:42:58 +0000 (UTC) Received: by iadj38 with SMTP id j38so24308546iad.13 for ; Tue, 27 Dec 2011 00:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sRmezDcPRcDA9uwfuJQ7l8ipJ6HNmyIlqQNQ2sqDUmA=; b=Gx2dT2T/3Qql9mu0ij+SRQV1QhA1kXWPycjqbZZZsb0id4TLrx4CtdDU6uAdEfdjcV 2KYZ3EispTTXjAASX35982Abq4pnyESICFY/S+RTyKfr2CRVPsNmPo3aCdowVlVMvh12 v3UWgSDGwgaBMO92cG8YAyharmwPhKQwmwC/0= MIME-Version: 1.0 Received: by 10.50.190.201 with SMTP id gs9mr30398570igc.1.1324975378133; Tue, 27 Dec 2011 00:42:58 -0800 (PST) Received: by 10.231.41.206 with HTTP; Tue, 27 Dec 2011 00:42:58 -0800 (PST) In-Reply-To: <20111227083503.GP8035@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> Date: Tue, 27 Dec 2011 10:42:58 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 08:42:59 -0000 Hi, i see in the logs many 4092, and a bit 4093 and 4094 as the log shows. I applied the both patches (the one you sent and the on on the pr) but i didn't load the new module yet: # kldunload ng_mppc kldunload: can't unload file: Device busy # I'm afraid to force it so my MPD won't crash to usesrs... what do you recommend? Sami 2011/12/27 Gleb Smirnoff > On Tue, Dec 27, 2011 at 09:44:23AM +0200, Sami Halabi wrote: > S> Hi, > S> > S> >1) Is the number always 4094? > S> > S> No, i see 4092, 4093 also: > S> Dec 24 09:17:04 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff003051e400! > S> Dec 24 09:17:04 mpd2 kernel: > S> Dec 24 14:22:45 mpd2 kernel: ng_mppc_decompress: too many (4093) packets > S> dropped > S> , disabling node 0xffffff003d53db00! > S> Dec 24 14:22:45 mpd2 kernel: > S> Dec 24 19:28:45 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff00304e8500! > > That's more interesting. Have you ever got 4095? > > Stay tuned, I hope I will come up with a patch today. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 09:06:17 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4D23106566C for ; Tue, 27 Dec 2011 09:06:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 30D228FC16 for ; Tue, 27 Dec 2011 09:06:16 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBR96Fxn026961; Tue, 27 Dec 2011 13:06:15 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBR96FLn026960; Tue, 27 Dec 2011 13:06:15 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 13:06:15 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111227090615.GQ8035@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> 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-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 09:06:17 -0000 Sami, On Tue, Dec 27, 2011 at 10:42:58AM +0200, Sami Halabi wrote: S> i see in the logs many 4092, and a bit 4093 and 4094 as the log shows. S> S> I applied the both patches (the one you sent and the on on the pr) but i S> didn't load the new module yet: S> # kldunload ng_mppc S> kldunload: can't unload file: Device busy S> # S> S> I'm afraid to force it so my MPD won't crash to usesrs... what do you S> recommend? Yes, you need to drop all users. No other way to upgrade. But don't hurry with it, yet. I think I will come up with a fix soon. The patch in the PR isn't actually a good idea. My patch that improves logging isn't needed any more, since I have already found a box with a big evidence of this error. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 09:30:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71F4B1065680 for ; Tue, 27 Dec 2011 09:30:42 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 143288FC0A for ; Tue, 27 Dec 2011 09:30:42 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pBR9UdeL043473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Dec 2011 01:30:40 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id pBR9Ud1a043472; Tue, 27 Dec 2011 01:30:39 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA27771; Tue, 27 Dec 11 01:27:47 PST Date: Tue, 27 Dec 2011 08:27:48 -0800 From: perryh@pluto.rain.com To: egrosbein@rdtc.ru Message-Id: <4ef9f204.c2ZP2f73gFwo7lUU%perryh@pluto.rain.com> References: <20111226143421.GB17435@DataIX.net> <4ef9c41f.rC8YkQQx738CJ3EN%perryh@pluto.rain.com> <4EF975FC.5080604@rdtc.ru> In-Reply-To: <4EF975FC.5080604@rdtc.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: iwc2010005@gmail.com, freebsd-net@freebsd.org, jhell@DataIX.net Subject: Re: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 09:30:42 -0000 Eugene Grosbein wrote: > 27.12.2011 20:11, perryh@pluto.rain.com ?????: > > Jason Hellenthal wrote: > >> > >> See siftr(4). This module writes to a file. > > > > Is siftr(4) new since 8.1? > > HISTORY > SIFTR first appeared in FreeBSD 7.4 and FreeBSD 8.2. which explains why there's no manpage for it in 8.1 :) It turns out that siftr(4) does not directly manipulate its logfiles, instead using alq(9) which has been around since 5.0. To (partly) answer the original question, it looks as if alq(9) can handle opening/creating and writing to the file -- and siftr(4) will serve as an example of using alq(9) -- but on a brief perusal it does not look as if alq(9) includes a mechanism to read back the data. One kernel operation that does directly process data from files -- as opposed to passing the data to a userland process for processing -- is execve(2), which must examine the file header to identify the type of executable being invoked. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 09:47:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B6D21065679; Tue, 27 Dec 2011 09:47:06 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA4198FC16; Tue, 27 Dec 2011 09:47:05 +0000 (UTC) Received: by iadj38 with SMTP id j38so24433455iad.13 for ; Tue, 27 Dec 2011 01:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fr95WqfKIgVTnQiNnAl9Ke1khu1H/oPbVY3srivQGu4=; b=MiUrKaXJRGGbEyI7lzJkvniccN3c0V8gGRwbMJ1yb4lqBQJNIv0kdHJTcvEaP1pUtc dPOMvvQa4ow+RZ+8/JwtcEIXFN2zCemMXwD0OA14qhIXBYxRx+HxyfNp5Pp0OHfiODvw X7OJATyTx3oQrHU4ZhNzyLQpJTWc+D5h2rf1g= MIME-Version: 1.0 Received: by 10.50.51.168 with SMTP id l8mr29983511igo.5.1324979223011; Tue, 27 Dec 2011 01:47:03 -0800 (PST) Received: by 10.231.41.206 with HTTP; Tue, 27 Dec 2011 01:47:02 -0800 (PST) In-Reply-To: <20111227090615.GQ8035@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20111227090615.GQ8035@glebius.int.ru> Date: Tue, 27 Dec 2011 11:47:02 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 09:47:06 -0000 okay, i reverted back to my original ng_mppc.c. btw: there an alternative module in here: http://www.mavhome.dp.ua/MPPC/ maybe this helps.. Sami 2011/12/27 Gleb Smirnoff > Sami, > > On Tue, Dec 27, 2011 at 10:42:58AM +0200, Sami Halabi wrote: > S> i see in the logs many 4092, and a bit 4093 and 4094 as the log shows. > S> > S> I applied the both patches (the one you sent and the on on the pr) but i > S> didn't load the new module yet: > S> # kldunload ng_mppc > S> kldunload: can't unload file: Device busy > S> # > S> > S> I'm afraid to force it so my MPD won't crash to usesrs... what do you > S> recommend? > > Yes, you need to drop all users. No other way to upgrade. But don't hurry > with it, yet. I think I will come up with a fix soon. > > The patch in the PR isn't actually a good idea. My patch that improves > logging isn't needed any more, since I have already found a box with > a big evidence of this error. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 10:38:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7740F106564A for ; Tue, 27 Dec 2011 10:38:27 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 152968FC0A for ; Tue, 27 Dec 2011 10:38:26 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so20819977wgb.31 for ; Tue, 27 Dec 2011 02:38:25 -0800 (PST) Received: by 10.227.60.14 with SMTP id n14mr26989507wbh.5.1324980933901; Tue, 27 Dec 2011 02:15:33 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id dd4sm64320659wib.1.2011.12.27.02.15.32 (version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 02:15:32 -0800 (PST) Message-ID: <4EF99AC5.4030104@my.gd> Date: Tue, 27 Dec 2011 11:15:33 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1498545030.20111227015431@nitronet.pl> In-Reply-To: <1498545030.20111227015431@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: PF vs IPFW (was: Re: Firewall Profiling.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 10:38:27 -0000 On 12/27/11 1:54 AM, Pawel Tyll wrote: > Hi lists, > > Are there any profiling tools in the system or ports that would allow > me to determine how much processing is being done per packet and how > long does it take? I would like to predict possible PPS load for my > system and perhaps locate and remove some bottlenecks. > > Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces > without much latency increase, when running on modern hardware > with Intel NICs? Majority of processing tasks would probably be setfib > according to matches in tables. > > Pawel. > Sorry for hijacking the thread. Is there a reason some people use IPFW over PF ? Like, performance perhaps ? Since its inclusion in the base system, I have only ever used PF and have never had major problems with it. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 10:40:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AB91106566B for ; Tue, 27 Dec 2011 10:40:41 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A554A8FC15 for ; Tue, 27 Dec 2011 10:40:40 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so9777911wib.13 for ; Tue, 27 Dec 2011 02:40:39 -0800 (PST) Received: by 10.216.138.219 with SMTP id a69mr20848093wej.6.1324982439465; Tue, 27 Dec 2011 02:40:39 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fq7sm27558099wbb.1.2011.12.27.02.40.37 (version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 02:40:38 -0800 (PST) Message-ID: <4EF9A0A7.1000304@my.gd> Date: Tue, 27 Dec 2011 11:40:39 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 10:40:41 -0000 On 12/27/11 7:23 AM, Rajneesh Kumar wrote: > Hi list, > > During my development, I want to check if my modules compile successfully > or not. I am only changing the ARP portion and whenever I compile my > kernel, it takes around 20mins and compiles all different modules also. > I just want to compile and check whether my ARP modules, which I have > changed, compile fine or not. How to do it? > You could always use MODULES_OVERRIDE to specify which modules you'd like to build. You'll still be recompiling the kernel itself but without *many* unneeded modules. Find for example a snippet from my /etc/make.conf: KERNCONF=DAM MODULES_OVERRIDE=geom/geom_label geom/geom_mirror aio zfs krpc opensolaris From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 10:56:17 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A43A1065672; Tue, 27 Dec 2011 10:56:17 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9608FC14; Tue, 27 Dec 2011 10:56:16 +0000 (UTC) Received: by iadj38 with SMTP id j38so24563855iad.13 for ; Tue, 27 Dec 2011 02:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xdWiVtPOgn90G+xchC9rKyAaDyfjLswj4XHMnbejq68=; b=mNCVkJ3hwUHad7tyviufMx7C6IV+rD+EXgm2OYBxWn/N+9dKkQuXTQ3DM3Ov0tiw0I ddoipoxRBy71GTjSgEkG24T7gQaN6jVJxCmY4LSS2aFoWG9HWVpNcccUvywnz3cBOLHI RJZPZeDQBIGNPdMECmqywd7lcaAxVTeuTYiPg= MIME-Version: 1.0 Received: by 10.50.195.164 with SMTP id if4mr30323076igc.11.1324981742631; Tue, 27 Dec 2011 02:29:02 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.183.76 with HTTP; Tue, 27 Dec 2011 02:29:02 -0800 (PST) In-Reply-To: <20111227041728.GI8035@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <20111227041728.GI8035@FreeBSD.org> Date: Tue, 27 Dec 2011 11:29:02 +0100 X-Google-Sender-Auth: rJv_TloSuegnQTrHb0NZ38hsTjA Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Watson , John Baldwin , net@freebsd.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 10:56:17 -0000 2011/12/27 Gleb Smirnoff : > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: > J> You can find the patch for 8.x at > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch > > Just my two pennies: for head/ patching if ip_carp.c should > be straightforward: > > 1) Using W in carp_alloc_if() and carp_free_if(). > 2) Using R everywhere else. > I would not say that is true! Look at this https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELENG_8_1/carp_livelock_fixes.diff I already did this for carp on pfSense for 8.x and should be the same for HEAD. That has undergone testing and catching up where R vs W. > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 11:37:15 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 080E9106564A; Tue, 27 Dec 2011 11:37:15 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id C0DC21543CB; Tue, 27 Dec 2011 11:37:13 +0000 (UTC) Message-ID: <4EF9ADBC.8090402@FreeBSD.org> Date: Tue, 27 Dec 2011 15:36:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111117 Thunderbird/8.0 MIME-Version: 1.0 To: Pawel Tyll References: <1498545030.20111227015431@nitronet.pl> In-Reply-To: <1498545030.20111227015431@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 11:37:15 -0000 On 27.12.2011 04:54, Pawel Tyll wrote: > Hi lists, > > Are there any profiling tools in the system or ports that would allow > me to determine how much processing is being done per packet and how > long does it take? I would like to predict possible PPS load for my > system and perhaps locate and remove some bottlenecks. > > Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces > without much latency increase, when running on modern hardware > with Intel NICs? Majority of processing tasks would probably be setfib > according to matches in tables. IPFW seems to add more or less constant overhead per rule. In our setup, ~20 rules increase load by 100% (one core). We are able to reach 10GE (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. However, even with ipfw add 1 allow ip from any to any 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. > > Pawel. > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 12:12:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F3DE106564A for ; Tue, 27 Dec 2011 12:12:51 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 112AF8FC12 for ; Tue, 27 Dec 2011 12:12:50 +0000 (UTC) Received: by iadj38 with SMTP id j38so24701482iad.13 for ; Tue, 27 Dec 2011 04:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DeeF4yYcO5bv+3PeTXP4UbaASpcPgbmfOvXb2pt/umY=; b=fFlBnUgCn/CKDDxtLXPc1H2IkAJxPuNZtgwq+oc/+Ia3VO9Ut5yrIqv0IZnfxiLSak JJbTtzQx+XiXNVo23HAYEgexvVjyNPWOfm05CqtxHNXY8B6a79ohhMXpoWBE4aqnRYg7 GngCbQvT0/5UcQddMiMqARJdZA/dbCv+OCcZA= MIME-Version: 1.0 Received: by 10.50.190.201 with SMTP id gs9mr31425509igc.1.1324987970121; Tue, 27 Dec 2011 04:12:50 -0800 (PST) Received: by 10.231.41.206 with HTTP; Tue, 27 Dec 2011 04:12:50 -0800 (PST) In-Reply-To: <4EF9ADBC.8090402@FreeBSD.org> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> Date: Tue, 27 Dec 2011 14:12:50 +0200 Message-ID: From: Sami Halabi To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Tyll , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 12:12:51 -0000 Hi, do you use dummynet? what is the server hardware configuration and tunings you did to acheive 10Gbps ? Sami On Tue, Dec 27, 2011 at 1:36 PM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > On 27.12.2011 04:54, Pawel Tyll wrote: > >> Hi lists, >> >> Are there any profiling tools in the system or ports that would allow >> me to determine how much processing is being done per packet and how >> long does it take? I would like to predict possible PPS load for my >> system and perhaps locate and remove some bottlenecks. >> >> Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces >> without much latency increase, when running on modern hardware >> with Intel NICs? Majority of processing tasks would probably be setfib >> according to matches in tables. >> > IPFW seems to add more or less constant overhead per rule. In our setup, > ~20 rules increase load by 100% (one core). We are able to reach 10GE > (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. > However, even with ipfw add 1 allow ip from any to any > 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in > rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. > > >> Pawel. >> >> >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org >> " >> >> > > -- > WBR, Alexander > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 13:34:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E08106566C for ; Tue, 27 Dec 2011 13:34:19 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 563158FC17 for ; Tue, 27 Dec 2011 13:34:19 +0000 (UTC) Received: from [89.204.155.136] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RfW3D-0000b2-3K for freebsd-net@freebsd.org; Tue, 27 Dec 2011 13:22:39 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id pBRCMrOU001439 for ; Tue, 27 Dec 2011 13:22:54 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id pBRCMq7Y001438 for freebsd-net@freebsd.org; Tue, 27 Dec 2011 13:22:52 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 27 Dec 2011 13:22:51 +0100 From: Matthias Apitz To: freebsd-net@freebsd.org Message-ID: <20111227122251.GA1427@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 89.204.155.136 Subject: ppp.conf "set speed" && UMTS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 13:34:19 -0000 Hello, I'm using PPP with an USB UMTS stick (Huawei E1750). The speed for upload and download can be measured with, for example, pages like: http://www.speedtest.net/ the results vary of course a bit, but usually they are between 1 and 4 Mbps; how those values fit with the speed of the device /dev/cuaU0.0 which I set in ppp.conf to the maximum value as set speed 921600 and as well in /usr/include/sys/_termios.h I don't see any higher possible speed for the interface... do I miss something? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 14:01:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC5B1106566C for ; Tue, 27 Dec 2011 14:01:22 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7B01F8FC13 for ; Tue, 27 Dec 2011 14:01:22 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXaj-00061L-LC for freebsd-net@freebsd.org; Tue, 27 Dec 2011 15:01:21 +0100 Date: Tue, 27 Dec 2011 15:00:47 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <623366116.20111227150047@nitronet.pl> To: "Alexander V. Chernikov" In-Reply-To: <4EF9ADBC.8090402@FreeBSD.org> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:01:22 -0000 > IPFW seems to add more or less constant overhead per rule. In our setup, > ~20 rules increase load by 100% (one core). We are able to reach 10GE > (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. > However, even with ipfw add 1 allow ip from any to any > 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in > rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. Does this include jumbo-frames? 1.1 mpps is far from 10gbit with standard Internet 1500-byte traffic, unless you meant 11.1 mpps :) Are there any plans or hopes for efficiency increase? Something like netmap? (http://info.iet.unipi.it/~luigi/netmap/) From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 14:09:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74586106566B; Tue, 27 Dec 2011 14:09:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3260F8FC13; Tue, 27 Dec 2011 14:09:21 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5BB3A7300B; Tue, 27 Dec 2011 15:26:00 +0100 (CET) Date: Tue, 27 Dec 2011 15:26:00 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20111227142600.GA65456@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <623366116.20111227150047@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:09:22 -0000 On Tue, Dec 27, 2011 at 03:00:47PM +0100, Pawel Tyll wrote: > > IPFW seems to add more or less constant overhead per rule. In our setup, > > ~20 rules increase load by 100% (one core). We are able to reach 10GE > > (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. > > However, even with ipfw add 1 allow ip from any to any > > 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in > > rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. > Does this include jumbo-frames? 1.1 mpps is far from 10gbit with > standard Internet 1500-byte traffic, unless you meant 11.1 mpps :) a 1500-byte frame is 12k bits so you need 830 Kpps to saturate the 10G link in one direction (and say another 450 Kpps as acks in the other direction). I reported the performance of ipfw+dummynet http://info.iet.unipi.it/~luigi/papers/20091201-dummynet.pdf on a 2.3GHz box and 800MHz RAM. The E5645 mentioned in the original msg is probably 2x faster than my test machine. > Are there any plans or hopes for efficiency increase? Something like > netmap? (http://info.iet.unipi.it/~luigi/netmap/) plans, yes - not sure how long it will take. I have compiled ipfw+dummynet as a standalone module (outside the kernel) but have not yet hooked the code to netmap to figure out how fast it can run. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 14:12:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5AC01065672 for ; Tue, 27 Dec 2011 14:12:44 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 71DF08FC1B for ; Tue, 27 Dec 2011 14:12:44 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXlj-0006Kz-KX for freebsd-net@freebsd.org; Tue, 27 Dec 2011 15:12:43 +0100 Date: Tue, 27 Dec 2011 15:12:29 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <72628217.20111227151229@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20111227142600.GA65456@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:12:44 -0000 > a 1500-byte frame is 12k bits so you need 830 Kpps > to saturate the 10G link in one direction (and say another 450 Kpps > as acks in the other direction). Obviously, sorry. Didn't have enough sleep lately :) From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 14:18:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C57621065670 for ; Tue, 27 Dec 2011 14:18:20 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA738FC15 for ; Tue, 27 Dec 2011 14:18:20 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXr9-0006Pr-J8 for freebsd-net@freebsd.org; Tue, 27 Dec 2011 15:18:19 +0100 Date: Tue, 27 Dec 2011 15:18:04 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <143974317.20111227151804@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20111227142600.GA65456@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:18:20 -0000 > plans, yes - not sure how long it will take. I have compiled > ipfw+dummynet as a standalone module (outside the kernel) > but have not yet hooked the code to netmap to figure out how fast > it can run. If I understand correctly, this would require netmap to catch every packet from interfaces that would be firewalled/routed using ipfw, and then during processing determine if packet is destined for local host or network and write it out to host kernel for normal processing or quickly write it out to some destination OS? In other words, userland routing engine using netmap? :) From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 14:25:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A9B106564A; Tue, 27 Dec 2011 14:25:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4608FC0A; Tue, 27 Dec 2011 14:25:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 85EF07300A; Tue, 27 Dec 2011 15:41:48 +0100 (CET) Date: Tue, 27 Dec 2011 15:41:48 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20111227144148.GA65684@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> <143974317.20111227151804@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <143974317.20111227151804@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:25:10 -0000 On Tue, Dec 27, 2011 at 03:18:04PM +0100, Pawel Tyll wrote: > > plans, yes - not sure how long it will take. I have compiled > > ipfw+dummynet as a standalone module (outside the kernel) > > but have not yet hooked the code to netmap to figure out how fast > > it can run. > If I understand correctly, this would require netmap to catch every > packet from interfaces that would be firewalled/routed using ipfw, and > then during processing determine if packet is destined for local host > or network and write it out to host kernel for normal processing or > quickly write it out to some destination OS? In other words, userland > routing engine using netmap? :) correct. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 15:13:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C8A106564A for ; Tue, 27 Dec 2011 15:13:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8EFBB8FC0C for ; Tue, 27 Dec 2011 15:13:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAAfg+U6DaFvO/2dsb2JhbABCFoR5qD6BcgEBBSNWGxgCAg0ZAlkZiAKjdJElgS+CToR4ggSBFgSIN4xLklI X-IronPort-AV: E=Sophos;i="4.71,415,1320642000"; d="scan'208";a="150012150" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 27 Dec 2011 10:13:21 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 757EBB3F06; Tue, 27 Dec 2011 10:13:21 -0500 (EST) Date: Tue, 27 Dec 2011 10:13:21 -0500 (EST) From: Rick Macklem To: perryh@pluto.rain.com Message-ID: <1274472810.645142.1324998801469.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4ef9c41f.rC8YkQQx738CJ3EN%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: iwc2010005@gmail.com, freebsd-net@freebsd.org, jhell@DataIX.net Subject: Re: Can we do perform a C style file Read/Write from within a ARP module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 15:13:22 -0000 perryh wrote: > Jason Hellenthal wrote: > > > > See siftr(4). This module writes to a file. > > Is siftr(4) new since 8.1? > > $ man siftr > No manual entry for siftr > $ cd /usr/ports > $ ls -d */*siftr* > ls: */*siftr*: No such file or directory > You can look at: http://people.freebsd.org/~rmacklem/nfs_clpackrat.c I won't say it is the best or even a good way to do it, but this code reads/writes files directly in the kernel. rick From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 15:15:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE43C106564A for ; Tue, 27 Dec 2011 15:15:57 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2678FC0A for ; Tue, 27 Dec 2011 15:15:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pBREp1js034541; Tue, 27 Dec 2011 07:51:01 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pBREp1XY034538; Tue, 27 Dec 2011 07:51:01 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 27 Dec 2011 07:51:01 -0700 (MST) From: Warren Block To: Rajneesh Kumar In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 27 Dec 2011 07:51:01 -0700 (MST) Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 15:15:57 -0000 On Tue, 27 Dec 2011, Rajneesh Kumar wrote: > During my development, I want to check if my modules compile successfully > or not. I am only changing the ARP portion and whenever I compile my > kernel, it takes around 20mins and compiles all different modules also. > I just want to compile and check whether my ARP modules, which I have > changed, compile fine or not. How to do it? Others have mentioned ways to reduce what is rebuilt. devel/ccache can be used in combination with those. Even by itself it ought to seriously reduce kernel compile time. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 15:23:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B452106566B for ; Tue, 27 Dec 2011 15:23:06 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5048FC08 for ; Tue, 27 Dec 2011 15:23:05 +0000 (UTC) Received: by werb13 with SMTP id b13so10468749wer.13 for ; Tue, 27 Dec 2011 07:23:04 -0800 (PST) Received: by 10.216.136.75 with SMTP id v53mr15758606wei.42.1324999384803; Tue, 27 Dec 2011 07:23:04 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ep16sm28391659wbb.21.2011.12.27.07.23.03 (version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 07:23:04 -0800 (PST) Message-ID: <4EF9E2D6.7050705@my.gd> Date: Tue, 27 Dec 2011 16:23:02 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 15:23:06 -0000 On 12/27/11 3:51 PM, Warren Block wrote: > On Tue, 27 Dec 2011, Rajneesh Kumar wrote: > >> During my development, I want to check if my modules compile successfully >> or not. I am only changing the ARP portion and whenever I compile my >> kernel, it takes around 20mins and compiles all different modules also. >> I just want to compile and check whether my ARP modules, which I have >> changed, compile fine or not. How to do it? > > Others have mentioned ways to reduce what is rebuilt. devel/ccache can > be used in combination with those. Even by itself it ought to seriously > reduce kernel compile time. > Hey up Warren, Would ccache also help with world/ports compile times ? Are there any drawbacks to using it ? (the underlying question being: is it worthy of a production environment ?) From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 17:46:57 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA38C106566B; Tue, 27 Dec 2011 17:46:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 48D8F8FC15; Tue, 27 Dec 2011 17:46:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBRHkuZb030807; Tue, 27 Dec 2011 21:46:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBRHkuYg030806; Tue, 27 Dec 2011 21:46:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2011 21:46:55 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20111227174655.GS8035@glebius.int.ru> References: <201112221130.01823.jhb@freebsd.org> <20111227041728.GI8035@FreeBSD.org> 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: Robert Watson , John Baldwin , net@FreeBSD.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 17:46:57 -0000 On Tue, Dec 27, 2011 at 11:29:02AM +0100, Ermal Lu?i wrote: E> 2011/12/27 Gleb Smirnoff : E> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: E> > J> You can find the patch for 8.x at E> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch E> > E> > Just my two pennies: for head/ patching if ip_carp.c should E> > be straightforward: E> > E> > 1) Using W in carp_alloc_if() and carp_free_if(). E> > 2) Using R everywhere else. E> > E> E> I would not say that is true! E> E> Look at this https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELENG_8_1/carp_livelock_fixes.diff E> I already did this for carp on pfSense for 8.x and should be the same for HEAD. E> That has undergone testing and catching up where R vs W. Ermal, in head/ we already got new CARP implementation. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 18:40:20 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DBA7106564A; Tue, 27 Dec 2011 18:40:20 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 33C738FC08; Tue, 27 Dec 2011 18:40:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBRIeKLY004039; Tue, 27 Dec 2011 18:40:20 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBRIeJ2V003992; Tue, 27 Dec 2011 18:40:19 GMT (envelope-from yongari) Date: Tue, 27 Dec 2011 18:40:19 GMT Message-Id: <201112271840.pBRIeJ2V003992@freefall.freebsd.org> To: kes-kes@yandex.ru, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/163478: [re] interface does not count bytes on interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 18:40:20 -0000 Synopsis: [re] interface does not count bytes on interface State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Dec 27 18:38:15 UTC 2011 State-Changed-Why: I believe this has nothing to do with re(4). See a possible patch for vlan(4) at the following URL. http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030818.html Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Dec 27 18:38:15 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=163478 From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:19:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D3D106566C for ; Tue, 27 Dec 2011 19:19:14 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B1E568FC19 for ; Tue, 27 Dec 2011 19:19:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pBRJJDKj036816; Tue, 27 Dec 2011 12:19:13 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pBRJJDLh036813; Tue, 27 Dec 2011 12:19:13 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 27 Dec 2011 12:19:13 -0700 (MST) From: Warren Block To: Damien Fleuriot In-Reply-To: <4EF9E2D6.7050705@my.gd> Message-ID: References: <4EF9E2D6.7050705@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 27 Dec 2011 12:19:13 -0700 (MST) Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:19:15 -0000 On Tue, 27 Dec 2011, Damien Fleuriot wrote: > On 12/27/11 3:51 PM, Warren Block wrote: >> On Tue, 27 Dec 2011, Rajneesh Kumar wrote: >> >>> During my development, I want to check if my modules compile successfully >>> or not. I am only changing the ARP portion and whenever I compile my >>> kernel, it takes around 20mins and compiles all different modules also. >>> I just want to compile and check whether my ARP modules, which I have >>> changed, compile fine or not. How to do it? >> >> Others have mentioned ways to reduce what is rebuilt. devel/ccache can >> be used in combination with those. Even by itself it ought to seriously >> reduce kernel compile time. > > Would ccache also help with world/ports compile times ? Yes, if some of it is already in the cache. Ports change relatively rarely, so I don't use ccache for them. > Are there any drawbacks to using it ? (the underlying question being: is > it worthy of a production environment ?) It needs cache space and probably slows things down a bit when code is not already in the cache. Some source updates invalidate a lot of the cache. But no other problems I've noticed. Times for 8-STABLE on an E8400 CPU, everything in the cache. make -j4 buildworld: Normal 19:41 ccache 6:02 make -j4 buildkernel (custom kernel): Normal 8:43 ccache 2:47 Those are best-case times. A typical ccache buildworld after csup to -stable is about 9 minutes on this system. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:22:40 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B79C106564A for ; Tue, 27 Dec 2011 19:22:40 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 341208FC1D for ; Tue, 27 Dec 2011 19:22:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBRJMdbO031285; Tue, 27 Dec 2011 23:22:39 +0400 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBRJMcmr031284; Tue, 27 Dec 2011 23:22:38 +0400 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 27 Dec 2011 23:22:38 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111227192238.GV8035@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:22:40 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Tue, Dec 27, 2011 at 09:44:23AM +0200, Sami Halabi wrote: S> >1) Is the number always 4094? S> S> No, i see 4092, 4093 also: S> Dec 24 09:17:04 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped S> , disabling node 0xffffff003051e400! S> Dec 24 09:17:04 mpd2 kernel: S> Dec 24 14:22:45 mpd2 kernel: ng_mppc_decompress: too many (4093) packets S> dropped S> , disabling node 0xffffff003d53db00! S> Dec 24 14:22:45 mpd2 kernel: S> Dec 24 19:28:45 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped S> , disabling node 0xffffff00304e8500! Well, here is my histrogram of probability: 38 4094 5 4093 3 4095 1 4092 1 4091 1 4087 1 4083 1 3275 1 2173 1 2172 1 2171 1 2170 1 2169 1 2137 1 2135 1 2132 1 2122 1 2121 1 2120 1 1130 1 1013 I believe that problem is caused by re-ordering of packets that may happen on the Internet. We definitely didn't lose 4094 packets so often. Shift of 4095 means that we received a packet that should be the previous one. Shift of 4094 means that we received a packet, that should have been two packets ago. I have no idea why this condition is much more probable :( Today I thought of some patch that would detect and fix reordering, but failed to find any elegant way on fixing this MPPE poor design. So, I have decided to remove the protection at all. The decision is based on the following facts: 1) Our current limit of 1000 isn't by an order of magnitude greater than maximum possible rekeying number - 4095. So, the DoS protection is quite not really a noticable one. 2) Since ng_mppc was developed CPUs got faster by more than an order of magnitude. 3) Linux implementations do as much rekeying as needed. 4) It looks like Windows does too. Not very clear from the article, but out of ordering is mentioned here: http://technet.microsoft.com/en-us/library/cc958061.aspx I suggest the attached patch. Can you please test it for a period of time and report how it goes? I am going to try it, too. -- Totus tuus, Glebius. --wq9mPyueHGvFACwf Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="ng_mppc.c.diff" Index: ng_mppc.c =================================================================== --- ng_mppc.c (revision 228916) +++ ng_mppc.c (working copy) @@ -98,15 +98,6 @@ /* Key length */ #define KEYLEN(b) (((b) & MPPE_128) ? 16 : 8) -/* - * When packets are lost with MPPE, we may have to re-key arbitrarily - * many times to 'catch up' to the new jumped-ahead sequence number. - * Since this can be expensive, we pose a limit on how many re-keyings - * we will do at one time to avoid a possible D.O.S. vulnerability. - * This should instead be a configurable parameter. - */ -#define MPPE_MAX_REKEY 1000 - /* MPPC packet header bits */ #define MPPC_FLAG_FLUSHED 0x8000 /* xmitter reset state */ #define MPPC_FLAG_RESTART 0x4000 /* compress history restart */ @@ -641,20 +632,13 @@ #endif #ifdef NETGRAPH_MPPC_ENCRYPTION if ((d->cfg.bits & MPPE_BITS) != 0) { - u_int rekey; - /* How many times are we going to have to re-key? */ - rekey = ((d->cfg.bits & MPPE_STATELESS) != 0) ? - numLost : (numLost / (MPPE_UPDATE_MASK + 1)); - if (rekey > MPPE_MAX_REKEY) { - log(LOG_ERR, "%s: too many (%d) packets" - " dropped, disabling node %p!", - __func__, numLost, node); - priv->recv.cfg.enable = 0; - goto failed; - } - - /* Re-key as necessary to catch up to peer */ + /* + * When packets are lost or re-ordered with MPPE, + * we may have to re-key up to 0xfff times to 'catch + * up' to the new jumped-ahead sequence number. Yep, + * this is heavy, but what else can we do? + */ while (d->cc != cc) { if ((d->cfg.bits & MPPE_STATELESS) != 0 || (d->cc & MPPE_UPDATE_MASK) --wq9mPyueHGvFACwf-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:23:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A3241065670 for ; Tue, 27 Dec 2011 19:23:32 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id B4A338FC19 for ; Tue, 27 Dec 2011 19:23:31 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 9DF9422813 for ; Tue, 27 Dec 2011 19:23:30 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id BD032101A2A94; Tue, 27 Dec 2011 19:23:38 +0000 (GMT) Message-ID: <4EFA1B30.9040405@rewt.org.uk> Date: Tue, 27 Dec 2011 19:23:28 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4EF8D0A2.5010604@rewt.org.uk> <20111227032528.GA1844@michelle.cdnetworks.com> In-Reply-To: <20111227032528.GA1844@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:23:32 -0000 YongHyeon PYUN wrote: > On Mon, Dec 26, 2011 at 07:53:06PM +0000, Joe Holden wrote: >> Hi guys, >> >> Hope you're all enjoying the holiday. >> >> Is anyone using bsnmpd with vlan interfaces? I see the following: >> >> ifOutOctets.10 = Counter32: 0 >> ifOutOctets.11 = Counter32: 3061 >> ifOutOctets.12 = Counter32: 0 >> ifOutOctets.13 = Counter32: 0 >> >> The ones with 0 are vlan interfaces, everything else is fine - is this a >> known issue or am I doing something wrong? > > Try attached patch and let me know how it goes. > >> Thanks, >> Joe Hi, Patch works as expected, thanks! Joe From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:25:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E57E1065670 for ; Tue, 27 Dec 2011 19:25:57 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C44D68FC13 for ; Tue, 27 Dec 2011 19:25:56 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so21330900wgb.31 for ; Tue, 27 Dec 2011 11:25:55 -0800 (PST) Received: by 10.227.204.208 with SMTP id fn16mr28890322wbb.6.1325013955812; Tue, 27 Dec 2011 11:25:55 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fg15sm29128063wbb.7.2011.12.27.11.25.54 (version=SSLv3 cipher=OTHER); Tue, 27 Dec 2011 11:25:55 -0800 (PST) Message-ID: <4EFA1BC1.5060605@my.gd> Date: Tue, 27 Dec 2011 20:25:53 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Warren Block References: <4EF9E2D6.7050705@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:25:57 -0000 On 12/27/11 8:19 PM, Warren Block wrote: > On Tue, 27 Dec 2011, Damien Fleuriot wrote: >> On 12/27/11 3:51 PM, Warren Block wrote: >>> On Tue, 27 Dec 2011, Rajneesh Kumar wrote: >>> >>>> During my development, I want to check if my modules compile >>>> successfully >>>> or not. I am only changing the ARP portion and whenever I compile my >>>> kernel, it takes around 20mins and compiles all different modules also. >>>> I just want to compile and check whether my ARP modules, which I have >>>> changed, compile fine or not. How to do it? >>> >>> Others have mentioned ways to reduce what is rebuilt. devel/ccache can >>> be used in combination with those. Even by itself it ought to seriously >>> reduce kernel compile time. >> >> Would ccache also help with world/ports compile times ? > > Yes, if some of it is already in the cache. Ports change relatively > rarely, so I don't use ccache for them. > >> Are there any drawbacks to using it ? (the underlying question being: is >> it worthy of a production environment ?) > > It needs cache space and probably slows things down a bit when code is > not already in the cache. Some source updates invalidate a lot of the > cache. But no other problems I've noticed. > > Times for 8-STABLE on an E8400 CPU, everything in the cache. > > make -j4 buildworld: > Normal 19:41 > ccache 6:02 > > make -j4 buildkernel (custom kernel): > Normal 8:43 > ccache 2:47 > > Those are best-case times. A typical ccache buildworld after csup to > -stable is about 9 minutes on this system. That sounds good enough. Are there any performance hits during production, as in, when not busy rebuilding the world or whatever, just normal daily operation ? From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:54:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF649106564A for ; Tue, 27 Dec 2011 19:54:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 505068FC13 for ; Tue, 27 Dec 2011 19:54:49 +0000 (UTC) Received: by lahl5 with SMTP id l5so6495783lah.13 for ; Tue, 27 Dec 2011 11:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/rDP5B+ihlKF5Im5E+s1s5XMkv9WabdLdfv+duxT7IE=; b=qoaM94lil53cfNLhOayn07AIm0mCMOtJccFYvlde/AzHAO8v0y70EOrIfkaLUi9lA8 B5z+jfAWZjGVZ7m+F8uKA4DjdcD/HK23P1ggXVsrqurkEjP08swxK2MB6dEjzHBZHKqD 2SXcjO2KLe8WU5xFsmWJiDR5kAqWLcWKJcCTE= Received: by 10.152.131.131 with SMTP id om3mr22893551lab.38.1325014258197; Tue, 27 Dec 2011 11:30:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Tue, 27 Dec 2011 11:30:27 -0800 (PST) In-Reply-To: References: <4EF9E2D6.7050705@my.gd> From: Eitan Adler Date: Tue, 27 Dec 2011 14:30:27 -0500 Message-ID: To: Warren Block Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Damien Fleuriot Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:54:50 -0000 On Tue, Dec 27, 2011 at 2:19 PM, Warren Block wrote: > make -j4 buildworld: Try adding -DNO_CLEAN here, > Normal =C2=A019:41 > ccache =C2=A0 6:02 > > make -j4 buildkernel (custom kernel): Try adding -DKERNFAST here for incremental builds. > Normal =C2=A08:43 > ccache =C2=A02:47 --=20 Eitan Adler From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 19:55:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEE0C10656A4 for ; Tue, 27 Dec 2011 19:55:34 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id A188E8FC14 for ; Tue, 27 Dec 2011 19:55:34 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pBRJjKiv085924 for ; Tue, 27 Dec 2011 11:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1325015120; bh=h7LVGwvZkYupzirp8Kg5BQ7W6USdt4Wu5O5cZBNtA5g=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=jh2dmUBj8w5M9CHYyOVGO7utBL5wg4KEwJxBWPL7+LYHlUQ9RkYCRBm6eXmN9GwCU U/yl2ppX9G+e3o6yxu4xK70rV1uLidJRP2GowCMoz3omD0o7vN9HfVwo0CwaFk+cYS kYoU4Iu6isFPXEylOVs3WRKe67LuTrp9x+aaIwvc= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Dec 2011 11:45:20 -0800 Message-ID: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: i386 compile sys/dev/ie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:55:34 -0000 Doing a lot of compiles recently and keep noting this noise in sys/dev/ie: /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'ieget': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:775: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:792: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:804: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'ie_readframe': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:850: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'iestart_locked': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:962: warning: passing argument 2 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:974: warning: cast discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'check_ie_present': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1026: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1035: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1038: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1062: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'setup_rfa': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1387: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1411: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'mc_setup': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1459: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1459: warning: passing argument 2 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function 'ieinit_locked': /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1497: warning: assignment discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1530: warning: passing argument 1 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1530: warning: passing argument 2 of 'bcopy' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1553: warning: assignment discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1564: warning: assignment discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1567: warning: assignment discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1574: warning: assignment discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1579: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1580: warning: passing argument 1 of 'bzero' discards qualifiers from pointer target type /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: At top level: /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1155: warning: 'ee16_read_eeprom' defined but not used /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1097: warning: 'find_ie_mem_size' defined but not used From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 20:22:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 717CC106566C for ; Tue, 27 Dec 2011 20:22:13 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2FE098FC08 for ; Tue, 27 Dec 2011 20:22:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pBRKMCQU037275; Tue, 27 Dec 2011 13:22:12 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pBRKMCG5037272; Tue, 27 Dec 2011 13:22:12 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 27 Dec 2011 13:22:12 -0700 (MST) From: Warren Block To: Damien Fleuriot In-Reply-To: <4EFA1BC1.5060605@my.gd> Message-ID: References: <4EF9E2D6.7050705@my.gd> <4EFA1BC1.5060605@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 27 Dec 2011 13:22:12 -0700 (MST) Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 20:22:13 -0000 On Tue, 27 Dec 2011, Damien Fleuriot wrote: >> Those are best-case times. A typical ccache buildworld after csup to >> -stable is about 9 minutes on this system. > > That sounds good enough. > > Are there any performance hits during production, as in, when not busy > rebuilding the world or whatever, just normal daily operation ? ccache is only called when compiling. There's a little extra overhead in make.conf, probably not significant. And the disk space used for the cache. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 20:36:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0314A1065673 for ; Tue, 27 Dec 2011 20:36:04 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCC48FC1B for ; Tue, 27 Dec 2011 20:36:03 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so10286384wib.13 for ; Tue, 27 Dec 2011 12:36:02 -0800 (PST) Received: by 10.181.12.43 with SMTP id en11mr64401935wid.6.1325018162599; Tue, 27 Dec 2011 12:36:02 -0800 (PST) Received: from [192.168.0.12] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id ej17sm29299000wbb.14.2011.12.27.12.36.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Dec 2011 12:36:01 -0800 (PST) References: <4EF9E2D6.7050705@my.gd> <4EFA1BC1.5060605@my.gd> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5A2883E2-C132-4E56-900D-5CCDE42A1FD2@my.gd> X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Tue, 27 Dec 2011 21:35:52 +0100 To: Warren Block Cc: "freebsd-net@freebsd.org" Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 20:36:04 -0000 On 27 Dec 2011, at 21:22, Warren Block wrote: > On Tue, 27 Dec 2011, Damien Fleuriot wrote: >=20 >>> Those are best-case times. A typical ccache buildworld after csup to >>> -stable is about 9 minutes on this system. >>=20 >> That sounds good enough. >>=20 >> Are there any performance hits during production, as in, when not busy >> rebuilding the world or whatever, just normal daily operation ? >=20 > ccache is only called when compiling. There's a little extra overhead in m= ake.conf, probably not significant. And the disk space used for the cache. Thanks for a the info Warren, I'll see about putting it in production, I'd l= ove saving some time when updating boxes. Besides, smaller update times (as in, human time spent) will help me defend f= bsd against debian kfreebsd :/ From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 20:38:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DB571065675 for ; Tue, 27 Dec 2011 20:38:14 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 20F7C8FC18 for ; Tue, 27 Dec 2011 20:38:13 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so21392337wgb.31 for ; Tue, 27 Dec 2011 12:38:13 -0800 (PST) Received: by 10.227.60.129 with SMTP id p1mr28627635wbh.27.1325018293182; Tue, 27 Dec 2011 12:38:13 -0800 (PST) Received: from [192.168.0.12] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id m13sm29322503wbh.0.2011.12.27.12.38.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Dec 2011 12:38:12 -0800 (PST) References: <4EF9E2D6.7050705@my.gd> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <214F5252-CAAA-4E8A-83E0-C18D52C0DF67@my.gd> X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Tue, 27 Dec 2011 21:38:02 +0100 To: Eitan Adler Cc: Warren Block , "freebsd-net@freebsd.org" Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 20:38:14 -0000 On 27 Dec 2011, at 20:30, Eitan Adler wrote: > On Tue, Dec 27, 2011 at 2:19 PM, Warren Block wrote: >> make -j4 buildworld: > Try adding -DNO_CLEAN here, >=20 I don't know, I'm ever afraid of running into whatever issues when not perfo= rming a clean full rebuild... >> Normal 19:41 >> ccache 6:02 >>=20 >> make -j4 buildkernel (custom kernel): >=20 > Try adding -DKERNFAST here for incremental builds. >=20 See above ;) I seem to remember this skips make depends and such ? When should one go for a fast build ? >> Normal 8:43 >> ccache 2:47 >=20 >=20 >=20 > --=20 > Eitan Adler From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 20:56:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40DF1106564A; Tue, 27 Dec 2011 20:56:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 107878FC14; Tue, 27 Dec 2011 20:56:36 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Rfe4Y-0000yv-QG; Tue, 27 Dec 2011 12:56:35 -0800 Message-ID: <4EFA30FA.7070807@sippysoft.com> Date: Tue, 27 Dec 2011 12:56:26 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, Robert Watson , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 20:56:40 -0000 So it's actually happening: Nov 8 21:38:02 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff05e5798bd0 Nov 13 03:34:49 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff02e5b05930 Nov 30 04:18:11 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03b2d2e000 Nov 30 20:24:12 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03a35e33f0 Nov 30 22:03:20 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03a6349690 Dec 5 03:33:01 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff02e0c9e930 Dec 9 06:02:06 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff038a4fea80 I'd love to try that socket closure locking patch that the Robert suggested, but kinda loaded right now. Robert, will it be too much to ask if you could provide me with the patch that applies to the latest 8-STABLE for a test? I'd give it a spin on 2-3 production boxes. And yes, those servers do a lot of socket ops per second, I'd say in the order of hundreds if not thousands per second. -Maxim On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote: > On Mon, 7 Nov 2011, Maxim Sobolev wrote: > >> On 11/7/2011 2:57 PM, Maxim Sobolev wrote: >>> On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >>>> Unlikely; the inp is properly locked there and the udp info attach >>>> better still be valid there; your problem is most likely elsewhere; >>>> try to see if you have other threads and see what they do at the same >>>> time, etc. You would need to race with udp_detach(); you also want >>>> to make sure that the inp still looks sane from either ddb or a dump >>>> and we are not talking about random memory corruption here. >>> >>> Well, as you can see from the trace it points pretty strongly to that >>> piece of code. And as I said this panic is completely reproducible, >>> we've seen it at least 5 times to date in exactly this location. >>> Unfortunately the trace is rather long so we could not capture it in >>> full before, until we've switched to the 80x50 mode. >>> >>> If it was a memory corruption it would be just random fault, while here >>> we have it failing in this point reliably. >>> >>> Unfortunately the panic happens in the driver thread context (I >>> believe), so the KDB/dump is not working. After panicing the machine >>> just hangs there. Keyboard is not working and I need to do a hard reset. >>> >>> Is there any other explanation that you can think of? Is it possible for >>> some other portion of the code (i.e. network driver, DMA engine etc) to >>> trash this structure by writing something off bound? Or something along >>> the lines? >> >> OK, I've put the following catch to prove the case: >> >> up = intoudpcb(inp); >> if (up == NULL) { >> printf("BZZT! Something is terribly wrong, up == >> NULL!\n"); >> INP_RUNLOCK(inp); >> goto badunlocked; >> } >> if (up->u_tun_func == NULL) { >> >> I am going to give it a spin on two busiest boxes and see if I can log >> anything. > > Now if you are clever you'd also log the inp there as the above will > only prove the case that something is wrong but still not help us in > anything to figure out what. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 20:57:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61A7106567C; Tue, 27 Dec 2011 20:57:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id E9B968FC1B; Tue, 27 Dec 2011 20:57:20 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Rfe5G-0000zc-R9; Tue, 27 Dec 2011 12:57:19 -0800 Message-ID: <4EFA3127.20705@FreeBSD.org> Date: Tue, 27 Dec 2011 12:57:11 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, Robert Watson , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 20:57:22 -0000 So it's actually happening: Nov 8 21:38:02 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff05e5798bd0 Nov 13 03:34:49 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff02e5b05930 Nov 30 04:18:11 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03b2d2e000 Nov 30 20:24:12 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03a35e33f0 Nov 30 22:03:20 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff03a6349690 Dec 5 03:33:01 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff02e0c9e930 Dec 9 06:02:06 dal09 kernel: BZZT! Something is terribly wrong, up == NULL! inp = 0xffffff038a4fea80 I'd love to try that socket closure locking patch that the Robert suggested, but kinda loaded right now. Robert, will it be too much to ask if you could provide me with the patch that applies to the latest 8-STABLE for a test? I'd give it a spin on 2-3 production boxes. And yes, those servers do a lot of socket ops per second, I'd say in the order of hundreds if not thousands per second. -Maxim On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote: > On Mon, 7 Nov 2011, Maxim Sobolev wrote: > >> On 11/7/2011 2:57 PM, Maxim Sobolev wrote: >>> On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >>>> Unlikely; the inp is properly locked there and the udp info attach >>>> better still be valid there; your problem is most likely elsewhere; >>>> try to see if you have other threads and see what they do at the same >>>> time, etc. You would need to race with udp_detach(); you also want >>>> to make sure that the inp still looks sane from either ddb or a dump >>>> and we are not talking about random memory corruption here. >>> >>> Well, as you can see from the trace it points pretty strongly to that >>> piece of code. And as I said this panic is completely reproducible, >>> we've seen it at least 5 times to date in exactly this location. >>> Unfortunately the trace is rather long so we could not capture it in >>> full before, until we've switched to the 80x50 mode. >>> >>> If it was a memory corruption it would be just random fault, while here >>> we have it failing in this point reliably. >>> >>> Unfortunately the panic happens in the driver thread context (I >>> believe), so the KDB/dump is not working. After panicing the machine >>> just hangs there. Keyboard is not working and I need to do a hard reset. >>> >>> Is there any other explanation that you can think of? Is it possible for >>> some other portion of the code (i.e. network driver, DMA engine etc) to >>> trash this structure by writing something off bound? Or something along >>> the lines? >> >> OK, I've put the following catch to prove the case: >> >> up = intoudpcb(inp); >> if (up == NULL) { >> printf("BZZT! Something is terribly wrong, up == >> NULL!\n"); >> INP_RUNLOCK(inp); >> goto badunlocked; >> } >> if (up->u_tun_func == NULL) { >> >> I am going to give it a spin on two busiest boxes and see if I can log >> anything. > > Now if you are clever you'd also log the inp there as the above will > only prove the case that something is wrong but still not help us in > anything to figure out what. From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 21:37:47 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D37A106566B for ; Tue, 27 Dec 2011 21:37:47 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0122D8FC25 for ; Tue, 27 Dec 2011 21:37:46 +0000 (UTC) Received: by iadj38 with SMTP id j38so25610956iad.13 for ; Tue, 27 Dec 2011 13:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ufu3T6BiahVcBr2RIWvsHFxAVtHscKK8Aj5Ps0eciJE=; b=pc9cAREyeb8eYOpSt4/lFjdbY1PfpGV7RuaAOTQlrcTdlYKpVwbDoS/Hg/QV+g+/5v sdMH0/kyjbv/BM2Ytd9vG4K7vV37b9/ORryTA+upkaHCjqrRZLa8KXKQLwyK8RXV34I3 xoF/CKYTEIarFyJZfLG03Xxx/ntftwt0ieJ/Y= MIME-Version: 1.0 Received: by 10.50.183.199 with SMTP id eo7mr33131848igc.5.1325020127122; Tue, 27 Dec 2011 13:08:47 -0800 (PST) Received: by 10.231.41.206 with HTTP; Tue, 27 Dec 2011 13:08:47 -0800 (PST) In-Reply-To: <20111227192238.GV8035@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227192238.GV8035@glebius.int.ru> Date: Tue, 27 Dec 2011 23:08:47 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 21:37:47 -0000 Hi Gleb, Thanks for your patch, i applied it and its production already. i had to stop mpd, and once started it i saw that all home routers connected immediatly. most of them don't use mppc, so I wonder why this problem happend in the first place. whats surprising i had few hours ago the same problem: Dec 27 14:11:29 mpd2 kernel: ng_mppc_decompress: too many (4092) packets dropped, disabling node 0xffffff000ba12700! Dec 27 14:11:29 mpd2 kernel: Dec 27 19:19:10 mpd2 kernel: ng_mppc_decompress: too many (4092) packets dropped, disabling node 0xffffff0006307400! Dec 27 19:19:10 mpd2 kernel: i hope the patch will solve the problem for good now, i'll let it work for the coming few days andif something will go wrong i'll paste you. Sami 2011/12/27 Gleb Smirnoff > On Tue, Dec 27, 2011 at 09:44:23AM +0200, Sami Halabi wrote: > S> >1) Is the number always 4094? > S> > S> No, i see 4092, 4093 also: > S> Dec 24 09:17:04 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff003051e400! > S> Dec 24 09:17:04 mpd2 kernel: > S> Dec 24 14:22:45 mpd2 kernel: ng_mppc_decompress: too many (4093) packets > S> dropped > S> , disabling node 0xffffff003d53db00! > S> Dec 24 14:22:45 mpd2 kernel: > S> Dec 24 19:28:45 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff00304e8500! > > Well, here is my histrogram of probability: > > 38 4094 > 5 4093 > 3 4095 > 1 4092 > 1 4091 > 1 4087 > 1 4083 > 1 3275 > 1 2173 > 1 2172 > 1 2171 > 1 2170 > 1 2169 > 1 2137 > 1 2135 > 1 2132 > 1 2122 > 1 2121 > 1 2120 > 1 1130 > 1 1013 > > I believe that problem is caused by re-ordering of packets that may happen > on the Internet. We definitely didn't lose 4094 packets so often. > > Shift of 4095 means that we received a packet that should be the previous > one. Shift of 4094 means that we received a packet, that should have been > two packets ago. I have no idea why this condition is much more probable :( > > Today I thought of some patch that would detect and fix reordering, but > failed to find any elegant way on fixing this MPPE poor design. > > So, I have decided to remove the protection at all. The decision is based > on > the following facts: > > 1) Our current limit of 1000 isn't by an order of magnitude greater than > maximum possible rekeying number - 4095. So, the DoS protection is quite > not really a noticable one. > 2) Since ng_mppc was developed CPUs got faster by more than an order of > magnitude. > 3) Linux implementations do as much rekeying as needed. > 4) It looks like Windows does too. Not very clear from the article, but > out of ordering is mentioned here: > > http://technet.microsoft.com/en-us/library/cc958061.aspx > > I suggest the attached patch. Can you please test it for a period > of time and report how it goes? > > I am going to try it, too. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 21:58:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7541065675; Tue, 27 Dec 2011 21:58:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA518FC1C; Tue, 27 Dec 2011 21:58:16 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id pBRLwDGb004986; Tue, 27 Dec 2011 16:58:13 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4EFA3F6F.9040404@sentex.net> Date: Tue, 27 Dec 2011 16:58:07 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> In-Reply-To: <4EF9ADBC.8090402@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Pawel Tyll , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 21:58:16 -0000 On 12/27/2011 6:36 AM, Alexander V. Chernikov wrote: >> Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces >> without much latency increase, when running on modern hardware >> with Intel NICs? Majority of processing tasks would probably be setfib >> according to matches in tables. > IPFW seems to add more or less constant overhead per rule. In our setup, > ~20 rules increase load by 100% (one core). We are able to reach 10GE > (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. > However, even with ipfw add 1 allow ip from any to any > 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in > rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. Dont some of the modern 10G adapters support filtering in the card itself ? eg cxgbe. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 22:05:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39494106566B; Tue, 27 Dec 2011 22:05:06 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id E0FA08FC1F; Tue, 27 Dec 2011 22:05:05 +0000 (UTC) Received: from secured.by.ipfw.ru ([81.200.11.182] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Rff8n-000Ap9-Ak; Wed, 28 Dec 2011 02:05:01 +0400 Message-ID: <4EFA40D7.60206@FreeBSD.org> Date: Wed, 28 Dec 2011 02:04:07 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Mike Tancsa References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> In-Reply-To: <4EFA3F6F.9040404@sentex.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig133DE841CFC96306967DCD86" Cc: Pawel Tyll , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 22:05:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig133DE841CFC96306967DCD86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mike Tancsa wrote: > On 12/27/2011 6:36 AM, Alexander V. Chernikov wrote: >>> Is IPFW efficient enough to firewall 2x10GE (in+out) interface= s >>> without much latency increase, when running on modern hardwar= e >>> with Intel NICs? Majority of processing tasks would probably be setfi= b >>> according to matches in tables. >> IPFW seems to add more or less constant overhead per rule. In our setu= p, >> ~20 rules increase load by 100% (one core). We are able to reach 10GE= >> (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules= =2E >> However, even with ipfw add 1 allow ip from any to any >> 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in >> rtable only). YMMV, but 2x10G is too much at the moment even without i= pfw. >=20 >=20 > Dont some of the modern 10G adapters support filtering in the card > itself ? eg cxgbe. We're using Intel 8259X, it supports hardware filtering (flow director and some other specific things like DCB) but: 1) Flow director is currently not supported (on FreeBSD) 2) There is no ipfw opcode compiler (however it seems that it's not too hard to write one).. 3) If ruleset is more or less optimized firewall is not the main CPU consumer. >=20 > ---Mike >=20 >=20 >=20 --------------enig133DE841CFC96306967DCD86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk76QNoACgkQwcJ4iSZ1q2mnbQCgiVScHKonwfmyCiYIHM5W0Zx0 CRUAnRiV13bJ0nMuJz+qOCSNQMmi2zC9 =5lTC -----END PGP SIGNATURE----- --------------enig133DE841CFC96306967DCD86-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 22:24:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE29A106564A for ; Tue, 27 Dec 2011 22:24:07 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 94FD48FC0A for ; Tue, 27 Dec 2011 22:24:07 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pBRMO5Ja038115; Tue, 27 Dec 2011 15:24:05 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pBRMO48T038112; Tue, 27 Dec 2011 15:24:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 27 Dec 2011 15:24:04 -0700 (MST) From: Warren Block To: Damien Fleuriot In-Reply-To: <214F5252-CAAA-4E8A-83E0-C18D52C0DF67@my.gd> Message-ID: References: <4EF9E2D6.7050705@my.gd> <214F5252-CAAA-4E8A-83E0-C18D52C0DF67@my.gd> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 27 Dec 2011 15:24:05 -0700 (MST) Cc: Eitan Adler , "freebsd-net@freebsd.org" Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 22:24:08 -0000 On Tue, 27 Dec 2011, Damien Fleuriot wrote: > > On 27 Dec 2011, at 20:30, Eitan Adler wrote: > >> On Tue, Dec 27, 2011 at 2:19 PM, Warren Block wrote: >>> make -j4 buildworld: >> Try adding -DNO_CLEAN here, >> > > I don't know, I'm ever afraid of running into whatever issues when not performing a clean full rebuild... The times I gave were for removing /usr/obj/usr before buildworld. >>> Normal 19:41 >>> ccache 6:02 From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 00:50:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63B22106564A for ; Wed, 28 Dec 2011 00:50:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 266148FC08 for ; Wed, 28 Dec 2011 00:50:44 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so11840701obb.13 for ; Tue, 27 Dec 2011 16:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pUtUe96JUea04YrihrZGgyKM7mMt+99SRq3e3a40YGM=; b=KZQ24IuQoErHiI3EBXeUI6zKKn+2Gks0xP7Fj4k08Xn0OfJLNco7Bt77ftkugtF+yK DgSYElRPWBpB3lNBFFwnyG7BSRPMKDOkSUPGUp1534auvpG8vzGtXErfZb+JcMjO8ZGp SDAZ/0cqWc0x2OSesppCXRWeXpqAMR74zYmqU= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr18516203obw.10.1325032040097; Tue, 27 Dec 2011 16:27:20 -0800 (PST) Received: by 10.182.171.67 with HTTP; Tue, 27 Dec 2011 16:27:20 -0800 (PST) In-Reply-To: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> References: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Wed, 28 Dec 2011 03:27:20 +0300 Message-ID: From: Sergey Kandaurov To: Sean Bruno Content-Type: multipart/mixed; boundary=f46d044787a510e6be04b51c1088 Cc: "freebsd-net@freebsd.org" Subject: Re: i386 compile sys/dev/ie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 00:50:45 -0000 --f46d044787a510e6be04b51c1088 Content-Type: text/plain; charset=ISO-8859-1 On 27 December 2011 23:45, Sean Bruno wrote: > Doing a lot of compiles recently and keep noting this noise in > sys/dev/ie: > > > > /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function > 'ieget': > /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning: > passing argument 1 of 'bcopy' discards qualifiers from pointer target > type [snip similar] These type of errors are because bzero takes a volatile argument but wants a non-volatile. This can be "solved" by casting to remove volatile modifier. > /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: At top level: > /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1155: warning: > 'ee16_read_eeprom' defined but not used > /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1097: warning: > 'find_ie_mem_size' defined but not used These were used in probe routine and are left from the newbus rewrite. I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] -- wbr, pluknet --f46d044787a510e6be04b51c1088 Content-Type: text/x-patch; charset=US-ASCII; name="ie.diff" Content-Disposition: attachment; filename="ie.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gwplpzq10 ZGlmZiAtdXJwTiBzeXMvZGV2L2llLm9yaWcvaWZfaWUuYyBzeXMvZGV2L2llL2lmX2llLmMKLS0t IHN5cy9kZXYvaWUub3JpZy9pZl9pZS5jCTIwMTEtMTItMjggMDI6MDA6MTkuMDAwMDAwMDAwICsw NDAwCisrKyBzeXMvZGV2L2llL2lmX2llLmMJMjAxMS0xMi0yOCAwNDowNTozNi4wMDAwMDAwMDAg KzA0MDAKQEAgLTE2OSwxNyArMTY5LDEyIEBAIHN0YXRpYyB2b2lkCWllc3RhcnRfbG9ja2VkCQko c3RydWN0IGlmbmUKIAogc3RhdGljIF9faW5saW5lIHZvaWQKIAkJZWUxNl9pbnRlcnJ1cHRfZW5h YmxlCShzdHJ1Y3QgaWVfc29mdGMgKik7Ci1zdGF0aWMgdm9pZAllZTE2X2VlcHJvbV9vdXRiaXRz CShzdHJ1Y3QgaWVfc29mdGMgKiwgaW50LCBpbnQpOwotc3RhdGljIHZvaWQJZWUxNl9lZXByb21f Y2xvY2sJKHN0cnVjdCBpZV9zb2Z0YyAqLCBpbnQpOwotc3RhdGljIHVfc2hvcnQJZWUxNl9yZWFk X2VlcHJvbQkoc3RydWN0IGllX3NvZnRjICosIGludCk7Ci1zdGF0aWMgaW50CWVlMTZfZWVwcm9t X2luYml0cwkoc3RydWN0IGllX3NvZnRjICopOwogCiBzdGF0aWMgX19pbmxpbmUgdm9pZAogCQlp ZV9hY2sJCQkoc3RydWN0IGllX3NvZnRjICosIHVfaW50KTsKIHN0YXRpYyB2b2lkCWllcmVzZXQJ CQkoc3RydWN0IGllX3NvZnRjICopOwogc3RhdGljIHZvaWQJaWVfcmVhZGZyYW1lCQkoc3RydWN0 IGllX3NvZnRjICosIGludCk7CiBzdGF0aWMgdm9pZAlpZV9kcm9wX3BhY2tldF9idWZmZXIJKHN0 cnVjdCBpZV9zb2Z0YyAqKTsKLXN0YXRpYyB2b2lkCWZpbmRfaWVfbWVtX3NpemUJKHN0cnVjdCBp ZV9zb2Z0YyAqKTsKIHN0YXRpYyBpbnQJY29tbWFuZF9hbmRfd2FpdAkoc3RydWN0IGllX3NvZnRj ICosCiAJCQkJCSBpbnQsIHZvaWQgdm9sYXRpbGUgKiwgaW50KTsKIHN0YXRpYyB2b2lkCXJ1bl90 ZHIJCQkoc3RydWN0IGllX3NvZnRjICosCkBAIC0zMDAsMTIgKzI5NSwxMiBAQCBpZV9hdHRhY2go ZGV2aWNlX3QgZGV2KQogCX0KIAlzYy0+cmJ1ZmZzID0KIAkgICAgKHZvbGF0aWxlIHN0cnVjdCBp ZV9yZWN2X2J1Zl9kZXNjICoqKSZzYy0+cmZyYW1lc1tzYy0+bmZyYW1lc107Ci0Jc2MtPmNidWZm cyA9ICh2b2xhdGlsZSB1X2NoYXIgKiopJnNjLT5yYnVmZnNbc2MtPm5yeGJ1ZnNdOworCXNjLT5j YnVmZnMgPSBfX0RFVk9MQVRJTEUodV9jaGFyICoqLCAmc2MtPnJidWZmc1tzYy0+bnJ4YnVmc10p OwogCXNjLT54bWl0X2NtZHMgPQogCSAgICAodm9sYXRpbGUgc3RydWN0IGllX3htaXRfY21kICoq KSZzYy0+Y2J1ZmZzW3NjLT5ucnhidWZzXTsKIAlzYy0+eG1pdF9idWZmcyA9CiAJICAgICh2b2xh dGlsZSBzdHJ1Y3QgaWVfeG1pdF9idWYgKiopJnNjLT54bWl0X2NtZHNbc2MtPm50eGJ1ZnNdOwot CXNjLT54bWl0X2NidWZmcyA9ICh2b2xhdGlsZSB1X2NoYXIgKiopJnNjLT54bWl0X2J1ZmZzW3Nj LT5udHhidWZzXTsKKwlzYy0+eG1pdF9jYnVmZnMgPSBfX0RFVk9MQVRJTEUodV9jaGFyICoqLCAm c2MtPnhtaXRfYnVmZnNbc2MtPm50eGJ1ZnNdKTsKIAogCWlmIChib290dmVyYm9zZSkKIAkJZGV2 aWNlX3ByaW50ZihzYy0+ZGV2LCAiaGFyZHdhcmUgdHlwZSAlcywgcmV2aXNpb24gJWRcbiIsCkBA IC03NzEsNyArNzY2LDcgQEAgaWVnZXQoc3RydWN0IGllX3NvZnRjICpzYywgc3RydWN0IG1idWYg KgogCQlpZiAodGhpc2xlbiA+IG0tPm1fbGVuIC0gdGhpc21ib2ZmKSB7CiAJCQlpbnQJbmV3bGVu ID0gbS0+bV9sZW4gLSB0aGlzbWJvZmY7CiAKLQkJCWJjb3B5KCh2X2NhZGRyX3QpIChzYy0+Y2J1 ZmZzW2hlYWRdICsgb2Zmc2V0KSwKKwkJCWJjb3B5KHNjLT5jYnVmZnNbaGVhZF0gKyBvZmZzZXQs CiAJCQkgICAgICBtdG9kKG0sIGNhZGRyX3QpICt0aGlzbWJvZmYsICh1bnNpZ25lZCkgbmV3bGVu KTsKIAkJCS8qIGlnbm9yZSBjYXN0LXF1YWwgd2FybmluZyAqLwogCQkJbSA9IG0tPm1fbmV4dDsK QEAgLTc4OCw3ICs3ODMsNyBAQCBpZWdldChzdHJ1Y3QgaWVfc29mdGMgKnNjLCBzdHJ1Y3QgbWJ1 ZiAqCiAJCSAqIHBvaW50ZXJzLCBhbmQgc28gb24uCiAJCSAqLwogCQlpZiAodGhpc2xlbiA8IG0t Pm1fbGVuIC0gdGhpc21ib2ZmKSB7Ci0JCQliY29weSgodl9jYWRkcl90KSAoc2MtPmNidWZmc1to ZWFkXSArIG9mZnNldCksCisJCQliY29weShzYy0+Y2J1ZmZzW2hlYWRdICsgb2Zmc2V0LAogCQkJ ICAgIG10b2QobSwgY2FkZHJfdCkgK3RoaXNtYm9mZiwgKHVuc2lnbmVkKSB0aGlzbGVuKTsKIAkJ CXRoaXNtYm9mZiArPSB0aGlzbGVuOwkvKiB3ZSBhcmUgdGhpcyBmYXIgaW50byB0aGUKIAkJCQkJ CSAqIG1idWYgKi8KQEAgLTgwMCw3ICs3OTUsNyBAQCBpZWdldChzdHJ1Y3QgaWVfc29mdGMgKnNj LCBzdHJ1Y3QgbWJ1ZiAqCiAJCSAqIGJ1ZmZlcidzIGNvbnRlbnRzIGludG8gdGhlIGN1cnJlbnQg bWJ1Zi4gIERvIHRoZQogCQkgKiBjb21iaW5hdGlvbiBvZiB0aGUgYWJvdmUgYWN0aW9ucy4KIAkJ ICovCi0JCWJjb3B5KCh2X2NhZGRyX3QpIChzYy0+Y2J1ZmZzW2hlYWRdICsgb2Zmc2V0KSwKKwkJ YmNvcHkoc2MtPmNidWZmc1toZWFkXSArIG9mZnNldCwKIAkJICAgICAgbXRvZChtLCBjYWRkcl90 KSArIHRoaXNtYm9mZiwgKHVuc2lnbmVkKSB0aGlzbGVuKTsKIAkJbSA9IG0tPm1fbmV4dDsKIAkJ dGhpc21ib2ZmID0gMDsJCS8qIG5ldyBtYnVmLCBzdGFydCBhdCB0aGUgYmVnaW5uaW5nICovCkBA IC04NDYsNyArODQxLDcgQEAgaWVfcmVhZGZyYW1lKHN0cnVjdCBpZV9zb2Z0YyAqc2MsIGludAlu dQogCXN0cnVjdCBldGhlcl9oZWFkZXIgKmVoOwogI2VuZGlmCiAKLQliY29weSgodl9jYWRkcl90 KSAoc2MtPnJmcmFtZXNbbnVtXSksICZyZmQsCisJYmNvcHkoX19ERVZPTEFUSUxFKGNhZGRyX3Qs IHNjLT5yZnJhbWVzW251bV0pLCAmcmZkLAogCSAgICAgIHNpemVvZihzdHJ1Y3QgaWVfcmVjdl9m cmFtZV9kZXNjKSk7CiAKIAkvKgpAQCAtOTM2LDcgKzkzMSw3IEBAIGllc3RhcnRfbG9ja2VkKHN0 cnVjdCBpZm5ldCAqaWZwKQogewogCXN0cnVjdAkgaWVfc29mdGMgKnNjID0gaWZwLT5pZl9zb2Z0 YzsKIAlzdHJ1Y3QJIG1idWYgKm0wLCAqbTsKLQl2b2xhdGlsZSB1bnNpZ25lZCBjaGFyICpidWZm ZXI7CisJdW5zaWduZWQgY2hhciAqYnVmZmVyOwogCXVfc2hvcnQJIGxlbjsKIAogCS8qCkBAIC0x MDIzLDcgKzEwMTgsNyBAQCBjaGVja19pZV9wcmVzZW50KHN0cnVjdCBpZV9zb2Z0YyAqc2MpCiAK IAlzY3AgPSAodm9sYXRpbGUgc3RydWN0IGllX3N5c19jb25mX3B0ciAqKSAodWludHB0cl90KQog CSAgICAgIChyZWFsYmFzZSArIElFX1NDUF9BRERSKTsKLQliemVybygodm9sYXRpbGUgY2hhciAq KSBzY3AsIHNpemVvZiAqc2NwKTsKKwliemVybyhfX0RFVk9MQVRJTEUodm9pZCAqLCBzY3ApLCBz aXplb2YgKnNjcCk7CiAKIAkvKgogCSAqIEZpcnN0IHdlIHB1dCB0aGUgSVNDUCBhdCB0aGUgYm90 dG9tIG9mIG1lbW9yeTsgdGhpcyB0ZXN0cyB0byBtYWtlCkBAIC0xMDMyLDEwICsxMDI3LDEwIEBA IGNoZWNrX2llX3ByZXNlbnQoc3RydWN0IGllX3NvZnRjICpzYykKIAkgKiBvcGVyYXRpb24uCiAJ ICovCiAJaXNjcCA9ICh2b2xhdGlsZSBzdHJ1Y3QgaWVfaW50X3N5c19jb25mX3B0ciAqKSBzYy0+ aW9tZW1ib3Q7Ci0JYnplcm8oKHZvbGF0aWxlIGNoYXIgKilpc2NwLCBzaXplb2YgKmlzY3ApOwor CWJ6ZXJvKF9fREVWT0xBVElMRShjaGFyICosIGlzY3ApLCBzaXplb2YgKmlzY3ApOwogCiAJc2Ni ID0gKHZvbGF0aWxlIHN0cnVjdCBpZV9zeXNfY3RsX2Jsb2NrICopIHNjLT5pb21lbWJvdDsKLQli emVybygodm9sYXRpbGUgY2hhciAqKXNjYiwgc2l6ZW9mICpzY2IpOworCWJ6ZXJvKF9fREVWT0xB VElMRShjaGFyICosIHNjYiksIHNpemVvZiAqc2NiKTsKIAogCXNjcC0+aWVfYnVzX3VzZSA9IHNj LT5idXNfdXNlOwkvKiA4LWJpdCBvciAxNi1iaXQgKi8KIAlzY3AtPmllX2lzY3BfcHRyID0gKGNh ZGRyX3QpICh1aW50cHRyX3QpCkBAIC0xMDU5LDcgKzEwNTQsNyBAQCBjaGVja19pZV9wcmVzZW50 KHN0cnVjdCBpZV9zb2Z0YyAqc2MpCiAJaXNjcCA9ICh2b2lkICopIEFsaWduKChjYWRkcl90KSAo dWludHB0cl90KQogCQkJICAgICAgKHJlYWxiYXNlICsgSUVfU0NQX0FERFIgLQogCQkJICAgICAg IHNpemVvZihzdHJ1Y3QgaWVfaW50X3N5c19jb25mX3B0cikpKTsKLQliemVybygodm9sYXRpbGUg Y2hhciAqKSBpc2NwLCBzaXplb2YgKmlzY3ApOwkvKiBpZ25vcmUgY2FzdC1xdWFsICovCisJYnpl cm8oX19ERVZPTEFUSUxFKGNoYXIgKiwgaXNjcCksIHNpemVvZiAqaXNjcCk7CS8qIGlnbm9yZSBj YXN0LXF1YWwgKi8KIAogCXNjcC0+aWVfaXNjcF9wdHIgPSAoY2FkZHJfdCkgKHVpbnRwdHJfdCkK IAkgICAgKCh2b2xhdGlsZSBjaGFyICopIGlzY3AgLSAodm9sYXRpbGUgY2hhciAqKSAodWludHB0 cl90KSByZWFsYmFzZSk7CkBAIC0xMDg4LDI2ICsxMDgzLDYgQEAgY2hlY2tfaWVfcHJlc2VudChz dHJ1Y3QgaWVfc29mdGMgKnNjKQogCXJldHVybiAoMSk7CiB9CiAKLS8qCi0gKiBEaXZpbmUgdGhl IG1lbW9yeSBzaXplIG9mIGllIGJvYXJkIFVOSVQuCi0gKiBCZXR0ZXIgaG9wZSB0aGVyZSdzIG5v dGhpbmcgaW1wb3J0YW50IGhpZGluZyBqdXN0IGJlbG93IHRoZSBpZSBjYXJkLi4uCi0gKi8KLXN0 YXRpYyB2b2lkCi1maW5kX2llX21lbV9zaXplKHN0cnVjdCBpZV9zb2Z0YyAqc2MpCi17Ci0JdW5z aWduZWQgc2l6ZTsKLQotCXNjLT5pb3NpemUgPSAwOwotCi0JZm9yIChzaXplID0gNjU1MzY7IHNp emUgPj0gODE5Mjsgc2l6ZSAtPSA4MTkyKSB7Ci0JCWlmIChjaGVja19pZV9wcmVzZW50KHNjKSkg ewotCQkJcmV0dXJuOwotCQl9Ci0JfQotCi0JcmV0dXJuOwotfQotCiB2b2lkCiBlbF9yZXNldF81 ODYoc3RydWN0IGllX3NvZnRjICpzYykKIHsKQEAgLTExNTAsODIgKzExMjUsNiBAQCBlZTE2X2No YW5fYXR0bihzdHJ1Y3QgaWVfc29mdGMgKnNjKQogCW91dGIoUE9SVChzYykgKyBJRUUxNl9BVFRO LCAwKTsKIH0KIAotdV9zaG9ydAotZWUxNl9yZWFkX2VlcHJvbShzdHJ1Y3QgaWVfc29mdGMgKnNj LCBpbnQgbG9jYXRpb24pCi17Ci0JaW50CWVjdHJsLCBlZGF0YTsKLQotCWVjdHJsID0gaW5iKHNj LT5wb3J0ICsgSUVFMTZfRUNUUkwpOwotCWVjdHJsICY9IElFRTE2X0VDVFJMX01BU0s7Ci0JZWN0 cmwgfD0gSUVFMTZfRUNUUkxfRUVDUzsKLQlvdXRiKHNjLT5wb3J0ICsgSUVFMTZfRUNUUkwsIGVj dHJsKTsKLQotCWVlMTZfZWVwcm9tX291dGJpdHMoc2MsIElFRTE2X0VFUFJPTV9SRUFELCBJRUUx Nl9FRVBST01fT1BTSVpFMSk7Ci0JZWUxNl9lZXByb21fb3V0Yml0cyhzYywgbG9jYXRpb24sIElF RTE2X0VFUFJPTV9BRERSX1NJWkUpOwotCWVkYXRhID0gZWUxNl9lZXByb21faW5iaXRzKHNjKTsK LQllY3RybCA9IGluYihzYy0+cG9ydCArIElFRTE2X0VDVFJMKTsKLQllY3RybCAmPSB+KElFRTE2 X1JFU0VUX0FTSUMgfCBJRUUxNl9FQ1RSTF9FRURJIHwgSUVFMTZfRUNUUkxfRUVDUyk7Ci0Jb3V0 YihzYy0+cG9ydCArIElFRTE2X0VDVFJMLCBlY3RybCk7Ci0JZWUxNl9lZXByb21fY2xvY2soc2Ms IDEpOwotCWVlMTZfZWVwcm9tX2Nsb2NrKHNjLCAwKTsKLQlyZXR1cm4gZWRhdGE7Ci19Ci0KLXN0 YXRpYyB2b2lkCi1lZTE2X2VlcHJvbV9vdXRiaXRzKHN0cnVjdCBpZV9zb2Z0YyAqc2MsIGludCBl ZGF0YSwgaW50IGNvdW50KQotewotCWludAllY3RybCwgaTsKLQotCWVjdHJsID0gaW5iKHNjLT5w b3J0ICsgSUVFMTZfRUNUUkwpOwotCWVjdHJsICY9IH5JRUUxNl9SRVNFVF9BU0lDOwotCWZvciAo aSA9IGNvdW50IC0gMTsgaSA+PSAwOyBpLS0pIHsKLQkJZWN0cmwgJj0gfklFRTE2X0VDVFJMX0VF REk7Ci0JCWlmIChlZGF0YSAmICgxIDw8IGkpKSB7Ci0JCQllY3RybCB8PSBJRUUxNl9FQ1RSTF9F RURJOwotCQl9Ci0JCW91dGIoc2MtPnBvcnQgKyBJRUUxNl9FQ1RSTCwgZWN0cmwpOwotCQlERUxB WSgxKTsJLyogZWVwcm9tIGRhdGEgbXVzdCBiZSBzZXR1cCBmb3IgMC40IHVTZWMgKi8KLQkJZWUx Nl9lZXByb21fY2xvY2soc2MsIDEpOwotCQllZTE2X2VlcHJvbV9jbG9jayhzYywgMCk7Ci0JfQot CWVjdHJsICY9IH5JRUUxNl9FQ1RSTF9FRURJOwotCW91dGIoc2MtPnBvcnQgKyBJRUUxNl9FQ1RS TCwgZWN0cmwpOwotCURFTEFZKDEpOwkJLyogZWVwcm9tIGRhdGEgbXVzdCBiZSBoZWxkIGZvciAw LjQgdVNlYyAqLwotfQotCi1zdGF0aWMgaW50Ci1lZTE2X2VlcHJvbV9pbmJpdHMoc3RydWN0IGll X3NvZnRjICpzYykKLXsKLQlpbnQJZWN0cmwsIGVkYXRhLCBpOwotCi0JZWN0cmwgPSBpbmIoc2Mt PnBvcnQgKyBJRUUxNl9FQ1RSTCk7Ci0JZWN0cmwgJj0gfklFRTE2X1JFU0VUX0FTSUM7Ci0JZm9y IChlZGF0YSA9IDAsIGkgPSAwOyBpIDwgMTY7IGkrKykgewotCQllZGF0YSA9IGVkYXRhIDw8IDE7 Ci0JCWVlMTZfZWVwcm9tX2Nsb2NrKHNjLCAxKTsKLQkJZWN0cmwgPSBpbmIoc2MtPnBvcnQgKyBJ RUUxNl9FQ1RSTCk7Ci0JCWlmIChlY3RybCAmIElFRTE2X0VDVFJMX0VFRE8pIHsKLQkJCWVkYXRh IHw9IDE7Ci0JCX0KLQkJZWUxNl9lZXByb21fY2xvY2soc2MsIDApOwotCX0KLQlyZXR1cm4gKGVk YXRhKTsKLX0KLQotc3RhdGljIHZvaWQKLWVlMTZfZWVwcm9tX2Nsb2NrKHN0cnVjdCBpZV9zb2Z0 YyAqc2MsIGludCBzdGF0ZSkKLXsKLQlpbnQJZWN0cmw7Ci0KLQllY3RybCA9IGluYihzYy0+cG9y dCArIElFRTE2X0VDVFJMKTsKLQllY3RybCAmPSB+KElFRTE2X1JFU0VUX0FTSUMgfCBJRUUxNl9F Q1RSTF9FRVNLKTsKLQlpZiAoc3RhdGUpIHsKLQkJZWN0cmwgfD0gSUVFMTZfRUNUUkxfRUVTSzsK LQl9Ci0Jb3V0YihzYy0+cG9ydCArIElFRTE2X0VDVFJMLCBlY3RybCk7Ci0JREVMQVkoOSk7CQkv KiBFRVNLIG11c3QgYmUgc3RhYmxlIGZvciA4LjM4IHVTZWMgKi8KLX0KLQogc3RhdGljIF9faW5s aW5lIHZvaWQKIGVlMTZfaW50ZXJydXB0X2VuYWJsZShzdHJ1Y3QgaWVfc29mdGMgKnNjKQogewpA QCAtMTM4NCw3ICsxMjgzLDcgQEAgc2V0dXBfcmZhKHN0cnVjdCBpZV9zb2Z0YyAqc2MsIHZfY2Fk ZHJfdAogCS8qIEZpcnN0IGxheSB0aGVtIG91dCAqLwogCWZvciAoaSA9IDA7IGkgPCBzYy0+bmZy YW1lczsgaSsrKSB7CiAJCXNjLT5yZnJhbWVzW2ldID0gcmZkOwotCQliemVybygodm9sYXRpbGUg Y2hhciAqKSByZmQsIHNpemVvZiAqcmZkKTsJLyogaWdub3JlIGNhc3QtcXVhbCAqLworCQliemVy byhfX0RFVk9MQVRJTEUoY2hhciAqLCByZmQpLCBzaXplb2YgKnJmZCk7CS8qIGlnbm9yZSBjYXN0 LXF1YWwgKi8KIAkJcmZkKys7CiAJfQogCkBAIC0xNDA4LDExICsxMzA3LDExIEBAIHNldHVwX3Jm YShzdHJ1Y3QgaWVfc29mdGMgKnNjLCB2X2NhZGRyX3QKIAogCWZvciAoaSA9IDA7IGkgPCBzYy0+ bnJ4YnVmczsgaSsrKSB7CiAJCXNjLT5yYnVmZnNbaV0gPSByYmQ7Ci0JCWJ6ZXJvKCh2b2xhdGls ZSBjaGFyICopcmJkLCBzaXplb2YgKnJiZCk7CisJCWJ6ZXJvKF9fREVWT0xBVElMRShjaGFyICos IHJiZCksIHNpemVvZiAqcmJkKTsKIAkJcHRyID0gQWxpZ252b2wocHRyICsgc2l6ZW9mICpyYmQp OwogCQlyYmQtPmllX3JiZF9sZW5ndGggPSBJRV9SQlVGX1NJWkU7CiAJCXJiZC0+aWVfcmJkX2J1 ZmZlciA9IE1LXzI0KE1FTShzYyksIHB0cik7Ci0JCXNjLT5jYnVmZnNbaV0gPSAodm9sYXRpbGUg dm9pZCAqKSBwdHI7CisJCXNjLT5jYnVmZnNbaV0gPSBfX0RFVk9MQVRJTEUodm9pZCAqLCBwdHIp OwogCQlwdHIgKz0gSUVfUkJVRl9TSVpFOwogCQlyYmQgPSAodm9sYXRpbGUgdm9pZCAqKSBwdHI7 CiAJfQpAQCAtMTQ0OCwxNCArMTM0NywxNCBAQCBzZXR1cF9yZmEoc3RydWN0IGllX3NvZnRjICpz Yywgdl9jYWRkcl90CiBzdGF0aWMgaW50CiBtY19zZXR1cChzdHJ1Y3QgaWVfc29mdGMgKnNjKQog ewotCXZvbGF0aWxlIHN0cnVjdCBpZV9tY2FzdF9jbWQgKmNtZCA9ICh2b2xhdGlsZSB2b2lkICop c2MtPnhtaXRfY2J1ZmZzWzBdOworCXN0cnVjdCBpZV9tY2FzdF9jbWQgKmNtZCA9ICh2b2lkICop c2MtPnhtaXRfY2J1ZmZzWzBdOwogCiAJY21kLT5jb20uaWVfY21kX3N0YXR1cyA9IDA7CiAJY21k LT5jb20uaWVfY21kX2NtZCA9IElFX0NNRF9NQ0FTVCB8IElFX0NNRF9MQVNUOwogCWNtZC0+Y29t LmllX2NtZF9saW5rID0gMHhmZmZmOwogCiAJLyogaWdub3JlIGNhc3QtcXVhbCAqLwotCWJjb3B5 KCh2X2NhZGRyX3QpIHNjLT5tY2FzdF9hZGRycywgKHZfY2FkZHJfdCkgY21kLT5pZV9tY2FzdF9h ZGRycywKKwliY29weSgoY2FkZHJfdCkgc2MtPm1jYXN0X2FkZHJzLCAoY2FkZHJfdCkgY21kLT5p ZV9tY2FzdF9hZGRycywKIAkgICAgICBzYy0+bWNhc3RfY291bnQgKiBzaXplb2YgKnNjLT5tY2Fz dF9hZGRycyk7CiAKIAljbWQtPmllX21jYXN0X2J5dGVzID0gc2MtPm1jYXN0X2NvdW50ICogNjsJ LyogZ3Jyci4uLiAqLwpAQCAtMTQ5MSw3ICsxMzkwLDcgQEAgaWVpbml0X2xvY2tlZChzdHJ1Y3Qg aWVfc29mdGMgKnNjKQogewogCXN0cnVjdCBpZm5ldCAqaWZwID0gc2MtPmlmcDsKIAl2b2xhdGls ZSBzdHJ1Y3QgaWVfc3lzX2N0bF9ibG9jayAqc2NiID0gc2MtPnNjYjsKLQljYWRkcl90IHB0cjsK Kwl2X2NhZGRyX3QgcHRyOwogCWludAlpOwogCiAJcHRyID0gQWxpZ252b2woKHZvbGF0aWxlIGNo YXIgKikgc2NiICsgc2l6ZW9mICpzY2IpOwpAQCAtMTUwMCw3ICsxMzk5LDcgQEAgaWVpbml0X2xv Y2tlZChzdHJ1Y3QgaWVfc29mdGMgKnNjKQogCSAqIFNlbmQgdGhlIGNvbmZpZ3VyZSBjb21tYW5k IGZpcnN0LgogCSAqLwogCXsKLQkJdm9sYXRpbGUgc3RydWN0IGllX2NvbmZpZ19jbWQgKmNtZCA9 ICh2b2xhdGlsZSB2b2lkICopIHB0cjsKKwkJc3RydWN0IGllX2NvbmZpZ19jbWQgKmNtZCA9IF9f REVWT0xBVElMRSh2b2lkICosIHB0cik7CiAKIAkJaWVfc2V0dXBfY29uZmlnKGNtZCwgc2MtPnBy b21pc2MsCiAJCQkJc2MtPmhhcmRfdHlwZSA9PSBJRV9TVEFSTEFOMTApOwpAQCAtMTUyMCwxNCAr MTQxOSwxNCBAQCBpZWluaXRfbG9ja2VkKHN0cnVjdCBpZV9zb2Z0YyAqc2MpCiAJICogTm93IHNl bmQgdGhlIEluZGl2aWR1YWwgQWRkcmVzcyBTZXR1cCBjb21tYW5kLgogCSAqLwogCXsKLQkJdm9s YXRpbGUgc3RydWN0IGllX2lhc2V0dXBfY21kICpjbWQgPSAodm9sYXRpbGUgdm9pZCAqKSBwdHI7 CisJCXN0cnVjdCBpZV9pYXNldHVwX2NtZCAqY21kID0gX19ERVZPTEFUSUxFKHZvaWQgKiwgcHRy KTsKIAogCQljbWQtPmNvbS5pZV9jbWRfc3RhdHVzID0gMDsKIAkJY21kLT5jb20uaWVfY21kX2Nt ZCA9IElFX0NNRF9JQVNFVFVQIHwgSUVfQ01EX0xBU1Q7CiAJCWNtZC0+Y29tLmllX2NtZF9saW5r ID0gMHhmZmZmOwogCi0JCWJjb3B5KCh2b2xhdGlsZSBjaGFyICopSUZfTExBRERSKGlmcCksCi0J CSAgICAgICh2b2xhdGlsZSBjaGFyICopJmNtZC0+aWVfYWRkcmVzcywgc2l6ZW9mIGNtZC0+aWVf YWRkcmVzcyk7CisJCWJjb3B5KChjaGFyICopSUZfTExBRERSKGlmcCksCisJCSAgICAgIChjaGFy ICopJmNtZC0+aWVfYWRkcmVzcywgc2l6ZW9mIGNtZC0+aWVfYWRkcmVzcyk7CiAJCXNjYi0+aWVf Y29tbWFuZF9saXN0ID0gTUtfMTYoTUVNKHNjKSwgY21kKTsKIAkJaWYgKGNvbW1hbmRfYW5kX3dh aXQoc2MsIElFX0NVX1NUQVJULCBjbWQsIElFX1NUQVRfQ09NUEwpCiAJCSAgICB8fCAhKGNtZC0+ Y29tLmllX2NtZF9zdGF0dXMgJiBJRV9TVEFUX09LKSkgewpAQCAtMTU2OSwxNSArMTQ2OCwxNSBA QCBpZWluaXRfbG9ja2VkKHN0cnVjdCBpZV9zb2Z0YyAqc2MpCiAKIAkvKiB0cmFuc21pdCBidWZm ZXJzICovCiAJZm9yIChpID0gMDsgaSA8IHNjLT5udHhidWZzIC0gMTsgaSsrKSB7Ci0JCXNjLT54 bWl0X2NidWZmc1tpXSA9ICh2b2xhdGlsZSB2b2lkICopcHRyOworCQlzYy0+eG1pdF9jYnVmZnNb aV0gPSBfX0RFVk9MQVRJTEUodm9pZCAqLCBwdHIpOwogCQlwdHIgKz0gSUVfQlVGX0xFTjsKIAkJ cHRyID0gQWxpZ252b2wocHRyKTsKIAl9Ci0Jc2MtPnhtaXRfY2J1ZmZzW3NjLT5udHhidWZzIC0g MV0gPSAodm9sYXRpbGUgdm9pZCAqKSBwdHI7CisJc2MtPnhtaXRfY2J1ZmZzW3NjLT5udHhidWZz IC0gMV0gPSBfX0RFVk9MQVRJTEUodm9pZCAqLCBwdHIpOwogCiAJZm9yIChpID0gMTsgaSA8IHNj LT5udHhidWZzOyBpKyspIHsKLQkJYnplcm8oKHZfY2FkZHJfdCkgc2MtPnhtaXRfY21kc1tpXSwg c2l6ZW9mICpzYy0+eG1pdF9jbWRzW2ldKTsKLQkJYnplcm8oKHZfY2FkZHJfdCkgc2MtPnhtaXRf YnVmZnNbaV0sIHNpemVvZiAqc2MtPnhtaXRfYnVmZnNbaV0pOworCQliemVybyhfX0RFVk9MQVRJ TEUoY2FkZHJfdCwgc2MtPnhtaXRfY21kc1tpXSksIHNpemVvZiAqc2MtPnhtaXRfY21kc1tpXSk7 CisJCWJ6ZXJvKF9fREVWT0xBVElMRShjYWRkcl90LCBzYy0+eG1pdF9idWZmc1tpXSksIHNpemVv ZiAqc2MtPnhtaXRfYnVmZnNbaV0pOwogCX0KIAogCS8qCmRpZmYgLXVycE4gc3lzL2Rldi9pZS5v cmlnL2lmX2lldmFyLmggc3lzL2Rldi9pZS9pZl9pZXZhci5oCi0tLSBzeXMvZGV2L2llLm9yaWcv aWZfaWV2YXIuaAkyMDExLTEyLTI4IDAyOjAzOjE0LjAwMDAwMDAwMCArMDQwMAorKysgc3lzL2Rl di9pZS9pZl9pZXZhci5oCTIwMTEtMTItMjggMDI6NDE6MTMuMDAwMDAwMDAwICswNDAwCkBAIC01 NSwxMiArNTUsMTIgQEAgc3RydWN0IGllX3NvZnRjIHsKIAl2b2xhdGlsZSBzdHJ1Y3QgaWVfc3lz X2N0bF9ibG9jayAqc2NiOwogCXZvbGF0aWxlIHN0cnVjdCBpZV9yZWN2X2ZyYW1lX2Rlc2MgKipy ZnJhbWVzOwkvKiBuZnJhbWVzIHdvcnRoICovCiAJdm9sYXRpbGUgc3RydWN0IGllX3JlY3ZfYnVm X2Rlc2MgKipyYnVmZnM7CS8qIG5yeGJ1ZnMgd29ydGggKi8KLQl2b2xhdGlsZSB1X2NoYXIgKipj YnVmZnM7CQkJLyogbnJ4YnVmcyB3b3J0aCAqLworCXVfY2hhciAqKmNidWZmczsJCQkvKiBucnhi dWZzIHdvcnRoICovCiAJaW50CSByZmhlYWQsIHJmdGFpbCwgcmJoZWFkLCByYnRhaWw7CiAKIAl2 b2xhdGlsZSBzdHJ1Y3QgaWVfeG1pdF9jbWQgKip4bWl0X2NtZHM7CS8qIG50eGJ1ZnMgd29ydGgg Ki8KIAl2b2xhdGlsZSBzdHJ1Y3QgaWVfeG1pdF9idWYgKip4bWl0X2J1ZmZzOwkvKiBudHhidWZz IHdvcnRoICovCi0Jdm9sYXRpbGUgdV9jaGFyCSAqKnhtaXRfY2J1ZmZzOwkJCS8qIG50eGJ1ZnMg d29ydGggKi8KKwl1X2NoYXIJICoqeG1pdF9jYnVmZnM7CQkJLyogbnR4YnVmcyB3b3J0aCAqLwog CWludAkgeG1pdF9jb3VudDsKIAogCXN0cnVjdAkgaWVfZW5fYWRkciBtY2FzdF9hZGRyc1tNQVhN Q0FTVCArIDFdOwo= --f46d044787a510e6be04b51c1088-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 06:04:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 938D71065673; Wed, 28 Dec 2011 06:04:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38D4E8FC0A; Wed, 28 Dec 2011 06:04:13 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so16776120vbb.13 for ; Tue, 27 Dec 2011 22:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eHsilh6EyNi7uQ0/KWddazU3lR/2y1QPbiS8IFz0jrs=; b=imRWS9V9Jn6AgO2l0wJpnMdVvRKlnkSSXGurl0RxUWF2naqeyuQfwrOAFONIoCL7Jt nrls1XQYthvz+TXqWsJBo9GNi/eJ/Z3Bqus+8ngnhKC3gECYUPlqoDwvxKBzemKDt3n+ vsLmjaAeZWpPouz+QLyd44UhsnfYUI93oswdU= MIME-Version: 1.0 Received: by 10.52.180.98 with SMTP id dn2mr6075431vdc.83.1325052253241; Tue, 27 Dec 2011 22:04:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 27 Dec 2011 22:04:13 -0800 (PST) In-Reply-To: <4EFA40D7.60206@FreeBSD.org> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> Date: Tue, 27 Dec 2011 22:04:13 -0800 X-Google-Sender-Auth: 4pc5sHR8RuZAneZxcuJQsHfOftw Message-ID: From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Tyll , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, Mike Tancsa Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:04:14 -0000 I can't help but remember when "someone" wrote an ipfw rule compiler - ie, take ipfw ruleset, generate C code. Maybe someone should write one and open source it this time.. :) Adrian From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 06:26:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E95F106564A; Wed, 28 Dec 2011 06:26:49 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 377B08FC0C; Wed, 28 Dec 2011 06:26:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3df3:fd3e:2c60:3d1d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 1B3114AC1C; Wed, 28 Dec 2011 10:26:47 +0400 (MSK) Date: Wed, 28 Dec 2011 10:26:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <91777482.20111228102644@serebryakov.spb.ru> To: Luigi Rizzo In-Reply-To: <20111227142600.GA65456@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pawel Tyll , freebsd-net@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:26:49 -0000 Hello, Luigi. You wrote 27 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 18:26:00: > plans, yes - not sure how long it will take. I have compiled > ipfw+dummynet as a standalone module (outside the kernel) > but have not yet hooked the code to netmap to figure out how fast > it can run. I still don't understand why it should be faster than "normal" way, as it is essentially same (ipfw + dummynet) code + some additional context switches for netmap (to userland and back). What does netmap shave off from packet processing in this particular case, to compensate context switches? I --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 06:28:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40260106566B; Wed, 28 Dec 2011 06:28:49 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F24C78FC19; Wed, 28 Dec 2011 06:28:48 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3df3:fd3e:2c60:3d1d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 67B154AC1C; Wed, 28 Dec 2011 10:28:47 +0400 (MSK) Date: Wed, 28 Dec 2011 10:28:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <444957640.20111228102844@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pawel Tyll , Mike Tancsa , "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:28:49 -0000 Hello, Adrian. You wrote 28 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 10:04:13: > Maybe someone should write one and open source it this time.. :) In presence of LLVM in the base, it looks, that we should generate native code from IPFW bytecodes, without intermediate C code :) Looks doeable! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 06:32:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C871065673 for ; Wed, 28 Dec 2011 06:32:36 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0A758FC12 for ; Wed, 28 Dec 2011 06:32:34 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so10618666wib.13 for ; Tue, 27 Dec 2011 22:32:34 -0800 (PST) Received: by 10.180.85.4 with SMTP id d4mr67007399wiz.0.1325053954201; Tue, 27 Dec 2011 22:32:34 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Tue, 27 Dec 2011 22:32:13 -0800 (PST) In-Reply-To: <91777482.20111228102644@serebryakov.spb.ru> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> <91777482.20111228102644@serebryakov.spb.ru> From: Juli Mallett Date: Tue, 27 Dec 2011 22:32:13 -0800 X-Google-Sender-Auth: mzCMSmJFPtcjYjVXdzHYg21rMkA Message-ID: To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pawel Tyll , "Alexander V. Chernikov" , Luigi Rizzo , freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:32:36 -0000 2011/12/27 Lev Serebryakov : > Hello, Luigi. > You wrote 27 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 18:= 26:00: > >> plans, yes - not sure how long it will take. I have compiled >> ipfw+dummynet as a standalone module (outside the kernel) >> but have not yet hooked the code to netmap to figure out how fast >> it can run. > =C2=A0I still don't understand why it should be faster than "normal" way, > as it is essentially same (ipfw + dummynet) code + some additional > context switches for netmap (to userland and back). > =C2=A0What does netmap shave off from packet processing in this particula= r > case, to compensate context switches? I Reloading of mbufs into DMA descriptors? mbuf allocator overhead itself? Interrupts. Context switches under constant heavy load. Some indirection in the network stack. From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 06:59:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A7A106566B for ; Wed, 28 Dec 2011 06:59:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id DC9F08FC16 for ; Wed, 28 Dec 2011 06:59:03 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBS6wxcB013676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2011 17:59:00 +1100 Date: Wed, 28 Dec 2011 17:58:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20111228162621.G936@besplex.bde.org> Message-ID: <20111228164938.F936@besplex.bde.org> References: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> <20111228162621.G936@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Sergey Kandaurov , Sean Bruno Subject: Re: i386 compile sys/dev/ie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:59:04 -0000 On Wed, 28 Dec 2011, Bruce Evans wrote: > On Wed, 28 Dec 2011, Sergey Kandaurov wrote: >> These were used in probe routine and are left from the newbus rewrite. >> I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] > > Use of the __DEVOLATILE() abomination is never correct. It exploits the > bug that -Wcast-qual is broken for casts through [u]intptr_t. PS: I used to maintain some bad fixes in this area for ie, but now have only the following: % .Index: if_ie.c % .=================================================================== % .RCS file: /home/ncvs/src/sys/dev/ie/if_ie.c,v % .retrieving revision 1.99 % .diff -u -2 -r1.99 if_ie.c % .--- if_ie.c 17 Mar 2004 17:50:35 -0000 1.99 % .+++ if_ie.c 31 May 2004 06:57:05 -0000 % .@@ -159,4 +159,7 @@ % . #define IE_BUF_LEN ETHER_MAX_LEN /* length of transmit buffer */ % . % .+/* XXX this driver uses `volatile' and `caddr_t' to a fault. */ % .+typedef volatile char *v_caddr_t; /* core address, pointer to volatile */ % .+ % . /* Forward declaration */ % . struct ie_softc; I never allowed the __DEFOO() abominations in my , and at one time had all uses to them in /usr/src removed and ready to commit (there were about 2 of them. There are hundreds if not thousands now :-(). c_caddr_t and v_caddr_t are as abominable as __DEFOO(), so of course I never allowed them in my . But v_caddr_t is still easy to remove, since it is only used in the ie driver. It is used the break warnings from -Wcast-qual that more natural casts would give (but warnings still result from the implicit conversion for bcopy()): % if_ie.c:static v_caddr_t setup_rfa (struct ie_softc *, v_caddr_t); The very idea of a v_caddr_t is nonsense. caddr_t is a bad old type for a "core address". In most cases, it means the same as "void *", but was used because "void *" didn't exist. In FreeBSD, it must be precisely "char *" to work, since pointer arithmetic is perpetrated on it (the pointer arithmetic defeats its opaqueness). In a few cases, it is used for physical or device memory accesses. In must places, it should be spelled "void *", and in other places it should be replaced by a vm virtual or physical address type, or a bus space type. To this mess, the ie driver, but mercifully no other code in /usr/src, adds v_caddr_t. caddr_t is supposed to be opaque, but if we just cast to that we will get a cast-qual error if we start with one of ie's excessively qualified pointers. Also, "const caddr_t" doesn't work since it puts the const in the wrong place. This is "solved" by looking inside caddr_t to add the const there. ie uses v_caddr_t as follows: First, in the above, some of the excessive qualifiers are in setup_rfa()'s return type and second parameter... % if_ie.c: setup_rfa(sc, (v_caddr_t) sc->rframes[0]); % if_ie.c: setup_rfa(sc, (v_caddr_t) sc->rframes[0]); /* ignore cast-qual */ ... this makes even calling setup_rfa() difficult. We start with a volatile struct ie_mumble **rframes. We can't just cast this to void * or caddr_t since this would cause a -Wcast-qual warning. Casting it to "volatile void *" would be even worse, since it removes a volatile qualifier that is in the (technically) right place and adds it back in a wrong place. So we use v_caddr_t to keep it in the same place. % if_ie.c: bcopy((v_caddr_t) (sc->cbuffs[head] + offset), % if_ie.c: bcopy((v_caddr_t) (sc->cbuffs[head] + offset), % if_ie.c: bcopy((v_caddr_t) (sc->cbuffs[head] + offset), Similarly. cbuffs is a volatile u_char **. We want to aplply bcopy() to (cbuffs[head] + offset), which is a volatile u_char *. We assume that bcopy() is still the 1980's version which takes a caddr_t, although it took a (void *) even in 1992. So we originally tried to bogusly cast the arg to caddr_t. This had no effect, as would the more correct cast to (void *) have done, since the prototype converts to void * anyway. Eventually, -Wcast-qual was used and this bug was detected. (There may be a more serious bug involving char * being incompatble with void *. A grandfather kludge keeps char * equivalent to void * in many context. But it is not clear what happens with complicated qualifiers.) Some time later, the -Wcast-qual was broken using a volatile cast. But the warning for converting away the qualifier by the prototype remained. Omitting the cast would have had the same effect. % if_ie.c: bcopy((v_caddr_t) (sc->rframes[num]), &rfd, Similarly. % if_ie.c:static v_caddr_t % if_ie.c:setup_rfa(struct ie_softc *sc, v_caddr_t ptr) The definition matching the above prototype. % if_ie.c: bcopy((v_caddr_t) sc->mcast_addrs, (v_caddr_t) cmd->ie_mcast_addrs, Similarly. % if_ie.c: bzero((v_caddr_t) sc->xmit_cmds[i], sizeof *sc->xmit_cmds[i]); % if_ie.c: bzero((v_caddr_t) sc->xmit_buffs[i], sizeof *sc->xmit_buffs[i]); Same mistakes for bzero(). My change isolates the v_caddr_t mistake in ie. The c_caddr_t mistake is used 17 times in the kernel and 75 times in /usr/src. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 07:04:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A99106564A; Wed, 28 Dec 2011 07:04:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E20138FC0C; Wed, 28 Dec 2011 07:04:24 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so16826905vbb.13 for ; Tue, 27 Dec 2011 23:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tu1ZzkUqZXe2PvcT4ikIXOl5ImN76QkxYyiY55FNMZo=; b=IXoWvC+3GSdSSLU7969Cgb7eGpNnERYPwmyvste7tnVCHZOaQ0wcwCP0kccVst4pcn iORmoZMvzuqeu6t/92qk2v9SG9dA43R40n0IbbYwrXfIhlQWjVtWdwOENGAWnWKeJGuN GJSgTyu3hLqOeYaQziHz6u61aPfrR0pxzOJno= MIME-Version: 1.0 Received: by 10.52.180.98 with SMTP id dn2mr6132224vdc.83.1325055864033; Tue, 27 Dec 2011 23:04:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 27 Dec 2011 23:04:23 -0800 (PST) In-Reply-To: References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> <91777482.20111228102644@serebryakov.spb.ru> Date: Tue, 27 Dec 2011 23:04:23 -0800 X-Google-Sender-Auth: 22Lo90bWFEv3b3vj7SJXU19hylI Message-ID: From: Adrian Chadd To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pawel Tyll , lev@freebsd.org, "Alexander V. Chernikov" , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, Luigi Rizzo Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 07:04:25 -0000 On 27 December 2011 22:32, Juli Mallett wrote: > Reloading of mbufs into DMA descriptors? =A0mbuf allocator overhead > itself? =A0Interrupts. =A0Context switches under constant heavy load. > Some indirection in the network stack. Keeping caches primed? Not doing lots of very-deep-stack stuff for each packet, which is the bane of all current kernel-space UNIX implementations of frame forwarding? :) Adrian From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 07:52:20 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8807E1065673 for ; Wed, 28 Dec 2011 07:52:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1CA778FC0A for ; Wed, 28 Dec 2011 07:52:19 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBS5liRe024702 for ; Wed, 28 Dec 2011 16:47:44 +1100 Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBS5lexq009382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2011 16:47:41 +1100 Date: Wed, 28 Dec 2011 16:47:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sergey Kandaurov In-Reply-To: Message-ID: <20111228162621.G936@besplex.bde.org> References: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: i386 compile sys/dev/ie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 07:52:20 -0000 On Wed, 28 Dec 2011, Sergey Kandaurov wrote: > On 27 December 2011 23:45, Sean Bruno wrote: >> Doing a lot of compiles recently and keep noting this noise in >> sys/dev/ie: >> >> /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function >> 'ieget': >> /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning: >> passing argument 1 of 'bcopy' discards qualifiers from pointer target >> type > [snip similar] > > These type of errors are because bzero takes a volatile argument but wants > a non-volatile. This can be "solved" by casting to remove volatile modifier. You mean that the warning about these errors can be broken by casting to remove the volatile qualifier (except casting has no effect except to do the same thing that the prototype does, and should cause a warning from -Wcast-qual). Either the memory is not actually volatile, in which case the pointer to it is misdeclared, or it is volatile, in which case using bcopy() on it gives undefined behaviour, depending on how bcopy() os implemented (bcopy() might access the memory out of order, or more than once, or with granularity that doesn't work). If the memory consists of device registers, then it is another error to access it using bcopy() instead of bus-space. IIRC, the volatiles in ie are: - the result of being a very old driver that was never converted to using bus space. No one wants to waste time converting it. - some for device memory and some for driver memory - the result of excessive use of volatile for non-volatile memory, especially for the non-device part, since when it was written in 1992/3, the general useless of volatile wasn't well understood but you could trick the compiler into working by sprinkling volatile. Originally, splimp() should have been used to make most accesses non- volatile. Now, mutex locking should do this even better. splimp() is no longer used, but there is still a bogus comment documenting where it "should" be used, and no comments about its mutex locking. > These were used in probe routine and are left from the newbus rewrite. > I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] Use of the __DEVOLATILE() abomination is never correct. It exploits the bug that -Wcast-qual is broken for casts through [u]intptr_t. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 08:08:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C6B8106564A for ; Wed, 28 Dec 2011 08:08:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 100538FC13 for ; Wed, 28 Dec 2011 08:08:26 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so12181770obb.13 for ; Wed, 28 Dec 2011 00:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YEFUE2/jo0OeWrg5F7/WYNcyQh9q8ptFFkbbcCgA+0Q=; b=phwaFxrr64g9ziNCH3aHWhLBoElqtm6iIx3DukG4FPtzQ3xpPf6RfjWgVIbr5RC5Io 6QicGnYNvlp0Ff3CQf2+KpEW1LeY1hQghvLU2XlBAevJfS6M5w2XQgHRaZ+Mkiukb0Ce 2t+bRUhE+iQ89pVuAYkRVlmi/8g09gasTWIEQ= MIME-Version: 1.0 Received: by 10.182.160.1 with SMTP id xg1mr27890974obb.30.1325059706421; Wed, 28 Dec 2011 00:08:26 -0800 (PST) Received: by 10.182.171.67 with HTTP; Wed, 28 Dec 2011 00:08:26 -0800 (PST) In-Reply-To: <20111228164938.F936@besplex.bde.org> References: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> <20111228162621.G936@besplex.bde.org> <20111228164938.F936@besplex.bde.org> Date: Wed, 28 Dec 2011 11:08:26 +0300 Message-ID: From: Sergey Kandaurov To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: i386 compile sys/dev/ie X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 08:08:27 -0000 On 28 December 2011 10:58, Bruce Evans wrote: > On Wed, 28 Dec 2011, Bruce Evans wrote: > >> On Wed, 28 Dec 2011, Sergey Kandaurov wrote: > > >>> These were used in probe routine and are left from the newbus rewrite. >>> I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] >> >> >> Use of the __DEVOLATILE() abomination is never correct. =A0It exploits t= he >> bug that -Wcast-qual is broken for casts through [u]intptr_t. Agreed. > PS: I used to maintain some bad fixes in this area for ie, but now > have only the following: > > % .Index: if_ie.c > % .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > % .RCS file: /home/ncvs/src/sys/dev/ie/if_ie.c,v > % .retrieving revision 1.99 > % .diff -u -2 -r1.99 if_ie.c > % .--- if_ie.c =A017 Mar 2004 17:50:35 -0000 =A0 =A0 =A01.99 > % .+++ if_ie.c =A031 May 2004 06:57:05 -0000 > % .@@ -159,4 +159,7 @@ > % . #define IE_BUF_LEN =A0ETHER_MAX_LEN =A0 /* length of transmit buffer = */ > % . % .+/* XXX this driver uses `volatile' and `caddr_t' to a fault. */ > % .+typedef =A0 =A0 volatile char *v_caddr_t; =A0 =A0 =A0 /* core address= , pointer to > volatile */ > % .+ > % . /* Forward declaration */ > % . struct ie_softc; Perhaps, it should be finally committed. :) > I never allowed the __DEFOO() abominations in my , and at > one time had all uses to them in /usr/src removed and ready to commit > (there were about 2 of them. =A0There are hundreds if not thousands now := -(). > c_caddr_t and v_caddr_t are as abominable as __DEFOO(), so of course I > never allowed them in my . =A0But v_caddr_t is still easy to > remove, since it is only used in the ie driver. =A0It is used the break > warnings from -Wcast-qual that more natural casts would give (but warning= s > still result from the implicit conversion for bcopy()): > > % if_ie.c:static v_caddr_t setup_rfa =A0 =A0 =A0 =A0 =A0 =A0(struct ie_so= ftc *, > v_caddr_t); > > The very idea of a v_caddr_t is nonsense. =A0caddr_t is a bad old type fo= r > a "core address". =A0In most cases, it means the same as "void *", but wa= s > used because "void *" didn't exist. =A0In FreeBSD, it must be precisely > "char *" to work, since pointer arithmetic is perpetrated on it (the > pointer arithmetic defeats its opaqueness). =A0In a few cases, it is > used for physical or device memory accesses. =A0In must places, it should > be spelled "void *", and in other places it should be replaced by > a vm virtual or physical address type, or a bus space type. > > To this mess, the ie driver, but mercifully no other code in /usr/src, > adds v_caddr_t. =A0caddr_t is supposed to be opaque, but if we just cast > to that we will get a cast-qual error if we start with one of ie's > excessively qualified pointers. =A0Also, "const caddr_t" doesn't work > since it puts the const in the wrong place. =A0This is "solved" by lookin= g > inside caddr_t to add the const there. > > ie uses v_caddr_t as follows: > > First, in the above, some of the excessive qualifiers are in setup_rfa()'= s > return type and second parameter... > > % if_ie.c: =A0 =A0 =A0setup_rfa(sc, (v_caddr_t) sc->rframes[0]); > % if_ie.c: =A0 =A0 =A0setup_rfa(sc, (v_caddr_t) sc->rframes[0]); =A0 =A0 = =A0/* ignore > cast-qual */ > > ... this makes even calling setup_rfa() difficult. =A0We start with a > volatile struct ie_mumble **rframes. =A0We can't just cast this to void * > or caddr_t since this would cause a -Wcast-qual warning. =A0Casting it > to "volatile void *" would be even worse, since it removes a volatile > qualifier that is in the (technically) right place and adds it back in > a wrong place. =A0So we use v_caddr_t to keep it in the same place. I should say for above that initially sc->rframes was: volatile struct ie_recv_frame_desc *rframes[MXFRAMES]; as well as its friends rbuffs, cbuffs, etc. Then it was changed to the current volatile ** form, and MXFRAMES was replaced to some dynamic value calculated from rman, so that gives even less chances to fix the ie code properly. /* * based on the amount of memory we have, allocate our tx and rx * resources. */ factor =3D rman_get_size(sc->mem_res) / 8192; sc->nframes =3D factor * NFRAMES; sc->nrxbufs =3D factor * NRXBUFS; sc->ntxbufs =3D factor * NTXBUFS; /* * Since all of these guys are arrays of pointers, allocate as one * big chunk and dole out accordingly. */ allocsize =3D sizeof(void *) * (sc->nframes + (sc->nrxbufs * 2) + (sc->ntxbufs * 3)); sc->rframes =3D (volatile struct ie_recv_frame_desc **) malloc(allo= csize, M_DEVB= UF, M_NOWAIT= ); then all these numerous buffs volatile friends point somewhere to this memory by setting its pointer to rframes like. sc->rbuffs =3D (volatile struct ie_recv_buf_desc **)&sc->rframes[sc->nframes]; This prompts me to that the volatile qualifier is probably abused for many sc fields there. > % if_ie.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy((v_caddr_t) (= sc->cbuffs[head] + > offset), > % if_ie.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy((v_caddr_t) (= sc->cbuffs[head] + > offset), > % if_ie.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy((v_caddr_t) (sc->cbuffs[head]= + offset), > > Similarly. =A0cbuffs is a volatile u_char **. =A0We want to aplply bcopy(= ) > to (cbuffs[head] + offset), which is a volatile u_char *. =A0We assume th= at > bcopy() is still the 1980's version which takes a caddr_t, although it > took a (void *) even in 1992. =A0So we originally tried to bogusly cast t= he > arg to caddr_t. =A0This had no effect, as would the more correct cast to > (void *) have done, since the prototype converts to void * anyway. > Eventually, -Wcast-qual was used and this bug was detected. =A0(There may= be > a more serious bug involving char * being incompatble with void *. =A0A > grandfather kludge keeps char * equivalent to void * in many context. > But it is not clear what happens with complicated qualifiers.) =A0Some > time later, the -Wcast-qual was broken using a volatile cast. =A0But > the warning for converting away the qualifier by the prototype > remained. =A0Omitting the cast would have had the same effect. > > % if_ie.c: =A0 =A0 =A0bcopy((v_caddr_t) (sc->rframes[num]), &rfd, > > Similarly. > > % if_ie.c:static v_caddr_t > % if_ie.c:setup_rfa(struct ie_softc *sc, v_caddr_t ptr) > > The definition matching the above prototype. > > % if_ie.c: =A0 =A0 =A0bcopy((v_caddr_t) sc->mcast_addrs, (v_caddr_t) > cmd->ie_mcast_addrs, > > Similarly. > > % if_ie.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0bzero((v_caddr_t) sc->xmit_cmds[i],= sizeof > *sc->xmit_cmds[i]); > % if_ie.c: =A0 =A0 =A0 =A0 =A0 =A0 =A0bzero((v_caddr_t) sc->xmit_buffs[i]= , sizeof > *sc->xmit_buffs[i]); > > Same mistakes for bzero(). Honestly, I can hardly imagine where v_caddr_t is used there properly, and if not then why it still ever exists... [Of course, this can be explained by my low C skills.] > My change isolates the v_caddr_t mistake in ie. > > The c_caddr_t mistake is used 17 times in the kernel and 75 times in > /usr/src. > > Bruce Thanks for your valuable comments. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 08:09:00 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC3AA106566C; Wed, 28 Dec 2011 08:09:00 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 85D3D8FC0A; Wed, 28 Dec 2011 08:09:00 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so12182621obb.13 for ; Wed, 28 Dec 2011 00:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Y56qS+cR1Irx3Gr68I7eMd8SPOB51rRp9ZKuHLPI3bs=; b=NEpfzeOZ1ja+RO7uu5d8JfYFzV+yqgFNYbFtkmQhDX+oEofbP8ruuHVQQkU9gFZYXQ DUNA/t/PwPmmdoxB0t4GQWuRyChD0VGPQOayBWHPFFbaZDYweEzmFHO4HPHOYo2xcAol JZawGqQZiTo3+DIHcf6D8hoXwzBdhvUykPoUE= MIME-Version: 1.0 Received: by 10.50.161.135 with SMTP id xs7mr29607690igb.15.1325059740000; Wed, 28 Dec 2011 00:09:00 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.183.76 with HTTP; Wed, 28 Dec 2011 00:08:59 -0800 (PST) In-Reply-To: <20111227174655.GS8035@glebius.int.ru> References: <201112221130.01823.jhb@freebsd.org> <20111227041728.GI8035@FreeBSD.org> <20111227174655.GS8035@glebius.int.ru> Date: Wed, 28 Dec 2011 09:08:59 +0100 X-Google-Sender-Auth: aapGDDRAVctUW_XbzdJXt17XZP8 Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Watson , John Baldwin , net@freebsd.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 08:09:01 -0000 2011/12/27 Gleb Smirnoff : > On Tue, Dec 27, 2011 at 11:29:02AM +0100, Ermal Lu?i wrote: > E> 2011/12/27 Gleb Smirnoff : > E> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: > E> > J> You can find the patch for 8.x at > E> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch > E> > > E> > Just my two pennies: for head/ patching if ip_carp.c should > E> > be straightforward: > E> > > E> > 1) Using W in carp_alloc_if() and carp_free_if(). > E> > 2) Using R everywhere else. > E> > > E> > E> I would not say that is true! > E> > E> Look at this https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELENG_8_1/carp_livelock_fixes.diff > E> I already did this for carp on pfSense for 8.x and should be the same for HEAD. > E> That has undergone testing and catching up where R vs W. > > Ermal, > > in head/ we already got new CARP implementation. > Gleb, yeah but the 'new' there is just the interface provided to be configured and not the protocol or code perse. To me it is the same from locking perspective in 8.x and HEAD For sure i will have to come to this when we move to 9 or HEAD in pfSense but still think its not that simple as you said. Regards, Ermal From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:04:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A75A106568D; Wed, 28 Dec 2011 10:04:19 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 17DAA8FC19; Wed, 28 Dec 2011 10:04:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 248747300A; Wed, 28 Dec 2011 11:20:57 +0100 (CET) Date: Wed, 28 Dec 2011 11:20:57 +0100 From: Luigi Rizzo To: Lev Serebryakov Message-ID: <20111228102057.GA74183@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <623366116.20111227150047@nitronet.pl> <20111227142600.GA65456@onelab2.iet.unipi.it> <91777482.20111228102644@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91777482.20111228102644@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Pawel Tyll , freebsd-net@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:04:19 -0000 On Wed, Dec 28, 2011 at 10:26:44AM +0400, Lev Serebryakov wrote: > Hello, Luigi. > You wrote 27 ??????? 2011 ?., 18:26:00: > > > plans, yes - not sure how long it will take. I have compiled > > ipfw+dummynet as a standalone module (outside the kernel) > > but have not yet hooked the code to netmap to figure out how fast > > it can run. > I still don't understand why it should be faster than "normal" way, > as it is essentially same (ipfw + dummynet) code + some additional > context switches for netmap (to userland and back). > What does netmap shave off from packet processing in this particular > case, to compensate context switches? I if you get called with reasonably large batches (10..50 packets, as it may well happen if you have any sort of interrupt mitigation), the context switch cost is amortised over the batch, so you shouldn't see much of it. If all the traffic goes to the local host you can't save anything. But if you manage to do the forwarding (so it's not just ipfw but also ip_fastforward) within the netmap layer, you save the recycling of mbufs (which is expensive), and also the code can be slightly optimized because packets have a single format, are contiguous, and carry almost no metadata. but definitely, the gains need to be measured and i have no such numbers so far. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:25:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DCF106564A for ; Wed, 28 Dec 2011 10:25:27 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A44B78FC0A for ; Wed, 28 Dec 2011 10:25:27 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 55FE6C492D; Wed, 28 Dec 2011 12:09:07 +0200 (EET) Date: Wed, 28 Dec 2011 12:09:19 +0200 From: Aleksandr Rybalko To: Rajneesh Kumar Message-Id: <20111228120919.f329f62b.ray@dlink.ua> In-Reply-To: References: Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Compiling only "network" part of the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:25:28 -0000 On Tue, 27 Dec 2011 11:53:23 +0530 Rajneesh Kumar wrote: >> Hi list, >> >> During my development, I want to check if my modules compile >> successfully or not. I am only changing the ARP portion and whenever >> I compile my kernel, it takes around 20mins and compiles all >> different modules also. I just want to compile and check whether my >> ARP modules, which I have changed, compile fine or not. How to do it? hi, or if you need rebuild only several modules with native build just do: cd /usr/src/syc/modules/${required_module} make make install :) >> >> -- >> Regards, >> Rajneesh >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" -- Alexandr Rybalko aka Alex RAY From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:25:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F1B01065670 for ; Wed, 28 Dec 2011 10:25:28 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A4A828FC0C for ; Wed, 28 Dec 2011 10:25:27 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 0AA32C4934; Wed, 28 Dec 2011 12:06:01 +0200 (EET) Date: Wed, 28 Dec 2011 12:06:11 +0200 From: Aleksandr Rybalko To: Matthias Apitz Message-Id: <20111228120611.2b5c895c.ray@dlink.ua> In-Reply-To: <20111227122251.GA1427@tiny> References: <20111227122251.GA1427@tiny> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ppp.conf "set speed" && UMTS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:25:28 -0000 On Tue, 27 Dec 2011 13:22:51 +0100 Matthias Apitz wrote: >> >> Hello, >> >> I'm using PPP with an USB UMTS stick (Huawei E1750). The speed for >> upload and download can be measured with, for example, pages like: >> http://www.speedtest.net/ >> the results vary of course a bit, but usually they are between >> 1 and 4 Mbps; >> >> how those values fit with the speed of the device /dev/cuaU0.0 which >> I set in ppp.conf to the maximum value as >> >> set speed 921600 >> >> and as well in /usr/include/sys/_termios.h I don't see any higher >> possible speed for the interface... do I miss something? >> Hi Matthias, IIRC "set speed" ignored for USB modems (only USB-to-serial or USB dialup modems use it). Some time ago I deal with that problem for linux based devices and found that problem may be fixed by ignore reported USB endpoint transfer size. Some devices report it with value 0x200 (512 bytes) but works fine with 0x1000 (4096). And with last value give much bigger throughput. This is wMaxPacketSize value in `usbconfig -u 4 -a 2 dump_curr_config_desc` output. u3g driver already set it to 2048, if your modem hooked by another driver try to change it from 0 (use reported) to 2048/4096. >> Thanks >> >> matthias >> -- >> Matthias Apitz >> e - w http://www.unixarea.de/ >> UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) >> UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" -- Alexandr Rybalko aka Alex RAY From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 10:26:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02563106566B; Wed, 28 Dec 2011 10:26:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id ADFCB8FC1E; Wed, 28 Dec 2011 10:26:11 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 17E7C73027; Wed, 28 Dec 2011 11:42:51 +0100 (CET) Date: Wed, 28 Dec 2011 11:42:51 +0100 From: Luigi Rizzo To: Lev Serebryakov Message-ID: <20111228104251.GB74183@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> <444957640.20111228102844@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444957640.20111228102844@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Pawel Tyll , Adrian Chadd , "Alexander V. Chernikov" , Mike Tancsa , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:26:12 -0000 On Wed, Dec 28, 2011 at 10:28:44AM +0400, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 ??????? 2011 ?., 10:04:13: > > > Maybe someone should write one and open source it this time.. :) > In presence of LLVM in the base, it looks, that we should generate > native code from IPFW bytecodes, without intermediate C code :) > Looks doeable! There is a problem here. You have to trust the native code before allowing its execution in the kernel. So either you implement some form of sandboxing or code validator before accepting a blob of native code from the setsockopt(), or you generate the code directly within the kernel. But with these sizes you cannot embed clang or gcc in the kernel: > size /usr/bin/clang text data bss dec hex filename 31892505 538200 76544 32507249 1f00571 /usr/bin/clang > size /usr/libexec/cc1 text data bss dec hex filename 6172008 39800 723320 6935128 69d258 /usr/libexec/cc1 maybe you can embed tcc or libtcc: > size `which tcc` text data bss dec hex filename 127573 600 42680 170853 29b65 /usr/local/bin/tcc though i would guess that a custom code generator is probably simpler to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its amd64 counterpart) cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 11:19:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9167106566B for ; Wed, 28 Dec 2011 11:19:22 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 732D28FC13 for ; Wed, 28 Dec 2011 11:19:22 +0000 (UTC) Received: from [82.113.99.106] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RfrXT-0005Xo-Vi; Wed, 28 Dec 2011 12:19:21 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id pBSBJKFt002039; Wed, 28 Dec 2011 12:19:21 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id pBSBJKlg002038; Wed, 28 Dec 2011 12:19:20 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Wed, 28 Dec 2011 12:19:19 +0100 From: Matthias Apitz To: Aleksandr Rybalko Message-ID: <20111228111918.GA1983@tiny> References: <20111227122251.GA1427@tiny> <20111228120611.2b5c895c.ray@dlink.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111228120611.2b5c895c.ray@dlink.ua> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 82.113.99.106 Cc: freebsd-net@freebsd.org Subject: Re: ppp.conf "set speed" && UMTS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 11:19:23 -0000 El día Wednesday, December 28, 2011 a las 12:06:11PM +0200, Aleksandr Rybalko escribió: > >> how those values fit with the speed of the device /dev/cuaU0.0 which > >> I set in ppp.conf to the maximum value as > >> > >> set speed 921600 > >> > >> and as well in /usr/include/sys/_termios.h I don't see any higher > >> possible speed for the interface... do I miss something? > >> > > Hi Matthias, > IIRC "set speed" ignored for USB modems (only USB-to-serial or USB > dialup modems use it). > > Some time ago I deal with that problem for linux based devices and > found that problem may be fixed by ignore reported USB endpoint > transfer size. Some devices report it with value 0x200 (512 bytes) but > works fine with 0x1000 (4096). And with last value give much bigger > throughput. > > This is wMaxPacketSize value in `usbconfig -u 4 -a 2 > dump_curr_config_desc` output. > > u3g driver already set it to 2048, if your modem hooked by another > driver try to change it from 0 (use reported) to 2048/4096. Hi Aleksandr, The device attaches to the u3g driver: /var/log/messages: ... Dec 28 08:01:20 tiny kernel: ugen4.4: at usbus4 Dec 28 08:01:20 tiny kernel: u3g0: on usbus4 Dec 28 08:01:20 tiny kernel: u3g0: Found 4 ports. and the usbconfig(8) gives the attached output below; most of the wMaxPacketSize values are 0x0200, some are 0x0040; which one should I change to 0x1000 (4096), and how? the source of the driver sys/dev/usb/serial/u3g.c has a #define for U3G_BSIZE set to 2048 and sets this into the structs for U3G_BULK_WR and U3G_BULK_RD, should this be visible with usbconfig(8)? the output below was done while the link is up; Thanks matthias # usbconfig -u 4 -a 4 dump_curr_config_desc ugen4.4: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x00a1 bNumInterfaces = 0x0006 bConfigurationValue = 0x0001 iConfiguration = 0x0001 bmAttributes = 0x00e0 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0003 wMaxPacketSize = 0x0040 bInterval = 0x0005 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0084 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 2 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0002 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0085 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 3 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0003 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0086 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0020 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 4 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0004 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0087 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0005 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 5 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0005 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0006 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0088 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 13:19:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028E5106564A; Wed, 28 Dec 2011 13:19:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9B88FC14; Wed, 28 Dec 2011 13:19:51 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so17168448vbb.13 for ; Wed, 28 Dec 2011 05:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4WeCu+9h0n/CZYKMhHqG6HOIY7CEYelYJqfFbFn1bo4=; b=QleX062eeFEiVYCvVOr1QX4k70WW5BV0g4wxgl5NOlsT/IzUMXPPYmSqYC/Rh86bwi q8RLxBwhgJLqX5nvk6wC2OTfsQvwxjPG0VHe20LX/ad8URLMqBGV8EP9/s+Ddav1Lofm W5q6DuxWR5k+cvRSp4FzBNHe6MH8Id4WWaRZc= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr8982467vdf.117.1325078390786; Wed, 28 Dec 2011 05:19:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 28 Dec 2011 05:19:50 -0800 (PST) In-Reply-To: <20111228104251.GB74183@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> <444957640.20111228102844@serebryakov.spb.ru> <20111228104251.GB74183@onelab2.iet.unipi.it> Date: Wed, 28 Dec 2011 05:19:50 -0800 X-Google-Sender-Auth: rhd_ItVLxhaoU8eUjsrZOIRkOVc Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Tyll , Lev Serebryakov , "Alexander V. Chernikov" , Mike Tancsa , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 13:19:52 -0000 .. the idea was just to take the rules and generate a kld to load. There's no need to overly complicate things! Adrian From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 14:59:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C8C41065670 for ; Wed, 28 Dec 2011 14:59:19 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id E1FC98FC08 for ; Wed, 28 Dec 2011 14:59:16 +0000 (UTC) Received: (qmail 9913 invoked from network); 28 Dec 2011 12:32:34 -0200 Received: by simscan 1.4.0 ppid: 9908, pid: 9911, t: 0.0071s scanners:none Received: from unknown (HELO eksffa.bh.freebsdbrasil.com.br) (eksffa@freebsdbrasil.com.br@10.69.69.7) by capeta.freebsdbrasil.com.br with ESMTPA; 28 Dec 2011 12:32:34 -0200 From: Patrick Tracanelli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Dec 2011 12:32:36 -0200 Message-Id: <3277161C-D037-4B47-9368-AC47EEA27FBC@freebsdbrasil.com.br> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1250) X-Mailer: Apple Mail (2.1250) Subject: Netgraph VLAN in VLAN (q-in-q) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 14:59:19 -0000 Hello, I need to setup a typical q-in-q environment, here's what I am working = on: ngctl mkpeer em2: vlan lower downstream ngctl name em2:lower vlanL1 ngctl connect em2: vlanL1: upper nomatch ngctl mkpeer vlanL1: eiface vlan2589 ether ngctl msg vlanL1: addfilter '{ vlan=3D2589 hook=3D"vlan2589" }' # assign em2 mac address ifconfig ngeth0 lladdr 00:21:5e:8a:0e:73 # Do everything again but the new vlan will have the previous # as parent... ngctl mkpeer ngeth0: vlan lower downstream ngctl name ngeth0:lower vlanL2 ngctl connect ngeth0: vlanL2: upper nomatch ngctl mkpeer vlanL2: eiface vlan110 ether ngctl msg vlanL2: addfilter '{ vlan=3D110 hook=3D"vlan110" }' ifconfig ngeth1 lladdr 00:21:5e:8a:0e:73 But when I run: # ngctl mkpeer ngeth0: vlan lower downstream I get: ngctl: send msg: Protocol family not supported I am clueless what I am doing wrong at this point. Can someone help me = with this little ng problem? Its an 8.2-STABLE on i386 box. Thank you :) -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:57:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50517106566C; Wed, 28 Dec 2011 15:57:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DAD8C8FC18; Wed, 28 Dec 2011 15:57:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3df3:fd3e:2c60:3d1d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id A432D4AC32; Wed, 28 Dec 2011 19:57:28 +0400 (MSK) Date: Wed, 28 Dec 2011 19:57:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1742895255.20111228195725@serebryakov.spb.ru> To: Luigi Rizzo In-Reply-To: <20111228104251.GB74183@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> <444957640.20111228102844@serebryakov.spb.ru> <20111228104251.GB74183@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pawel Tyll , Adrian Chadd , Lev Serebryakov , "Alexander V. Chernikov" , Mike Tancsa , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 15:57:31 -0000 Hello, Luigi. You wrote 28 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 14:42:51: > There is a problem here. You have to trust the native code > before allowing its execution in the kernel. So either you root could load any KLD. So, I think, we could trust any code "uploaded" via setsocopt()... Yes, it looks dangerous, but, again, if root is compromised, attacker could compile and load kernel module as well. > implement some form of sandboxing or code validator > before accepting a blob of native code from the setsockopt(), > or you generate the code directly within the kernel. > But with these sizes you cannot embed clang or gcc in the kernel: clang is bad example, it needs to process C/C++ code (frontend). Custom-written compiler with LLVM as backend could have very reasonable size. But not for kernel side, for sure, in any case! > though i would guess that a custom code generator is probably simpler > to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its > amd64 counterpart) Yep, as we have BPF JIT, it could be simpler. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 19:37:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC9A71065675 for ; Wed, 28 Dec 2011 19:37:36 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 798C78FC1E for ; Wed, 28 Dec 2011 19:37:36 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so22430286wgb.31 for ; Wed, 28 Dec 2011 11:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=vX7LiJqRpAf6spEvMb2Cd0wRMGSlpnop+YRp4ZrJUKA=; b=qEy0etbiaqGkv+fzRhwk8HJGJjWeO8r/m3eTk/qHJIu18C9Z2rLG/A8xpvy1bGFMmi z9QkJPj6HlosUmk1np+iJVf2qttHI3P8g5zjxFSS46YGxcvVWKEghjNpnXhK+I97Qmyj xkxAX2EmP0hGC22LsRagzpk8j5uMq3PIhxH5U= Received: by 10.227.208.78 with SMTP id gb14mr32484968wbb.21.1325101055150; Wed, 28 Dec 2011 11:37:35 -0800 (PST) Received: from rimwks1w7x64 ([31.47.165.90]) by mx.google.com with ESMTPS id di5sm77025807wib.3.2011.12.28.11.37.31 (version=SSLv3 cipher=OTHER); Wed, 28 Dec 2011 11:37:33 -0800 (PST) From: rozhuk.im@gmail.com To: "'Patrick Tracanelli'" , References: <3277161C-D037-4B47-9368-AC47EEA27FBC@freebsdbrasil.com.br> In-Reply-To: <3277161C-D037-4B47-9368-AC47EEA27FBC@freebsdbrasil.com.br> Date: Thu, 29 Dec 2011 04:37:26 +0900 Message-ID: <4efb6ffd.455fb40a.1880.14e0@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczFcVG5TgFd3FL8RqGGdHlvuKF8UQAJW3Ig Content-Language: ru Cc: Subject: RE: Netgraph VLAN in VLAN (q-in-q) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 19:37:37 -0000 Hi! If you need custom encap tag, use this: http://www.freebsd.org/cgi/query-pr.cgi?pr=161908 Scheme: ng_ether <-> ng_vlan(outer/metro tag) <-> ng_vlan(inner/customer tag) <-> ng_eiface > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Patrick Tracanelli > Sent: Wednesday, December 28, 2011 11:33 PM > To: freebsd-net@freebsd.org > Subject: Netgraph VLAN in VLAN (q-in-q) > > Hello, > > I need to setup a typical q-in-q environment, here's what I am working > on: > > ngctl mkpeer em2: vlan lower downstream > ngctl name em2:lower vlanL1 > ngctl connect em2: vlanL1: upper nomatch > ngctl mkpeer vlanL1: eiface > vlan2589 ether ngctl msg vlanL1: addfilter '{ vlan=2589 hook="vlan2589" }' > > # assign em2 mac address > ifconfig ngeth0 lladdr 00:21:5e:8a:0e:73 > > # Do everything again but the new vlan will have the previous # as > parent... > ngctl mkpeer ngeth0: vlan lower downstream ngctl name ngeth0:lower > vlanL2 ngctl connect ngeth0: vlanL2: upper nomatch ngctl mkpeer vlanL2: > eiface vlan110 ether ngctl msg vlanL2: addfilter '{ vlan=110 > hook="vlan110" }' > > ifconfig ngeth1 lladdr 00:21:5e:8a:0e:73 > > But when I run: > > # ngctl mkpeer ngeth0: vlan lower downstream > > I get: > > ngctl: send msg: Protocol family not supported > > I am clueless what I am doing wrong at this point. Can someone help me > with this little ng problem? > > Its an 8.2-STABLE on i386 box. > > Thank you :) > > -- > Patrick Tracanelli > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 19:42:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24E2F1065672 for ; Wed, 28 Dec 2011 19:42:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE6838FC19 for ; Wed, 28 Dec 2011 19:42:30 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so17557496vbb.13 for ; Wed, 28 Dec 2011 11:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0SXJ1jDWkEsiUAfP+eBsqFEf35CZdFBlqqLBzpS0FqM=; b=NE7T0OFRf+BocPPaLiJSRjChvGwGUnyxcZ7ofHoGtsauAI4tLA3QLbKq5Qvu4e/O3G v/mtzUCPyW4Bf2lrCV/VqYi3/ze/zSlBA8qSCBZeAreOnkRoX5sMO9S38DOJDzfc5gMI CZuYM4wMSVGLgfX0wMYRODBrxLSIMZ/+iBUfQ= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr9596494vdf.117.1325101349293; Wed, 28 Dec 2011 11:42:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 28 Dec 2011 11:42:29 -0800 (PST) In-Reply-To: <4efb6ffd.455fb40a.1880.14e0@mx.google.com> References: <3277161C-D037-4B47-9368-AC47EEA27FBC@freebsdbrasil.com.br> <4efb6ffd.455fb40a.1880.14e0@mx.google.com> Date: Wed, 28 Dec 2011 11:42:29 -0800 X-Google-Sender-Auth: VxgSdXEbl4q-N1t8GuC6FrnaVbc Message-ID: From: Adrian Chadd To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Netgraph VLAN in VLAN (q-in-q) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 19:42:31 -0000 On 28 December 2011 11:37, wrote: > Hi! > > > If you need custom encap tag, use this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=161908 > > Scheme: ng_ether <-> ng_vlan(outer/metro tag) <-> ng_vlan(inner/customer > tag) <-> ng_eiface Hm, have you found someone to review this and commit it to FreeBSD? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 16:24:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD38106566B; Thu, 29 Dec 2011 16:24:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6408FC15; Thu, 29 Dec 2011 16:24:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id CA95646B37; Thu, 29 Dec 2011 11:24:25 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 418EAB974; Thu, 29 Dec 2011 11:24:25 -0500 (EST) From: John Baldwin To: =?windows-1251?b?yu7t/Oru4iDF4uPl7ejp?= Date: Thu, 29 Dec 2011 11:12:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <201112200952.44690.jhb@freebsd.org> <1632420869.20111225180133@yandex.ru> In-Reply-To: <1632420869.20111225180133@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Message-Id: <201112291112.59912.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 11:24:25 -0500 (EST) Cc: Andre Oppermann , freebsd-net@freebsd.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org, Kostik Belousov , Lawrence Stewart Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:24:26 -0000 On Sunday, December 25, 2011 11:01:33 am =CA=EE=ED=FC=EA=EE=E2 =C5=E2=E3=E5= =ED=E8=E9 wrote: > =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, John. >=20 > =C2=FB =EF=E8=F1=E0=EB=E8 20 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 16:52:44: >=20 > JB> On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote: > >> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: > >> > An update. I've sent Pawel a testing patch to see if my hypothesis = is correct > >> > (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is then= I intend > >> > to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fix. > >>=20 > >> Unfortunately it paniced today. Take a look at: > >>=20 > >> http://people.freebsd.org/~pjd/misc/tcp_panic.jpg >=20 > JB> Ok, the one use case I was worried about is happening regularly befor= e your > JB> panic, so that is good. Can you use gdb to figure out which call to > JB> tcp_output() is actually panic'ing? I wonder if it is this case: >=20 > JB> /* > JB> * Return any desired output. > JB> */ > JB> if (needoutput || (tp->t_flags & TF_ACKNOW)) { > JB> (void) tcp_output(tp); > JB> /* XXX: Debug */ > JB> KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), > JB> ("tcp_input: negative window after ACK")); >=20 > JB> And if 'needoutput' is true, but TF_ACKNOW is not set, and tcp_output= () decides > JB> to not do anything. I've updated tcp_negwin_test.patch to not panic = if that call > JB> to tcp_output() doesn't actually send a packet. Please re-test. >=20 >=20 > # uname -a > FreeBSD meta-up 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #4: Sat Dec 24 13:5= 9:20 EET 2011 @:/usr/obj/usr/src/sys/KES_KERN_v10 i386 >=20 > rebooting once per day. Now I compile kernel with debug options. > Can you advice me which and where I find debug info when it will > reboting next time? so I can help to debug problem Are you using the patch at the URL above (tcp_negwin_test.patch)? If not, can you try applying that patch and seeing if you still get any panics? =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 16:24:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E37B106564A; Thu, 29 Dec 2011 16:24:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 737168FC1A; Thu, 29 Dec 2011 16:24:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2B29A46B46; Thu, 29 Dec 2011 11:24:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 79E5BB974; Thu, 29 Dec 2011 11:24:26 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Thu, 29 Dec 2011 11:24:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EF8D0A2.5010604@rewt.org.uk> <20111227032528.GA1844@michelle.cdnetworks.com> <20111227040551.GH8035@FreeBSD.org> In-Reply-To: <20111227040551.GH8035@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201112291124.23626.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 11:24:26 -0500 (EST) Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , Joe Holden Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:24:27 -0000 On Monday, December 26, 2011 11:05:51 pm Gleb Smirnoff wrote: > On Mon, Dec 26, 2011 at 07:25:29PM -0800, YongHyeon PYUN wrote: > Y> Index: sys/net/if_vlan.c > Y> =================================================================== > Y> --- sys/net/if_vlan.c (revision 228906) > Y> +++ sys/net/if_vlan.c (working copy) > Y> @@ -1012,10 +1012,12 @@ > Y> { > Y> struct ifvlan *ifv; > Y> struct ifnet *p; > Y> - int error; > Y> + int error, len, mcast; > Y> > Y> ifv = ifp->if_softc; > Y> p = PARENT(ifv); > Y> + len = m->m_pkthdr.len; > Y> + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; > Y> > Y> BPF_MTAP(ifp, m); > Y> > Y> @@ -1025,7 +1027,7 @@ > Y> */ > Y> if (!UP_AND_RUNNING(p)) { > Y> m_freem(m); > Y> - ifp->if_collisions++; > Y> + ifp->if_oerrors++; > Y> return (0); > Y> } > Y> > Y> @@ -1081,9 +1083,11 @@ > Y> * Send it, precisely as ether_output() would have. > Y> */ > Y> error = (p->if_transmit)(p, m); > Y> - if (!error) > Y> + if (!error) { > Y> ifp->if_opackets++; > Y> - else > Y> + ifp->if_omcasts += mcast; > Y> + ifp->if_obytes += len; > Y> + } else > Y> ifp->if_oerrors++; > Y> return (error); > Y> } > > Thanks, Pyun! You can count me in as reviewer. > > I have also added jhb@ to Cc, the author of changed code, so that he > can review, too. I didn't really change it, I just unindented it when the loop was removed during the transition to if_transmit. :) However, this patch looks good to me. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 16:41:02 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE08310657AB; Thu, 29 Dec 2011 16:41:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3F78FC12; Thu, 29 Dec 2011 16:41:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 1B27446B2E; Thu, 29 Dec 2011 11:41:02 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A14C6B93A; Thu, 29 Dec 2011 11:41:01 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Thu, 29 Dec 2011 11:36:01 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> <20111227041728.GI8035@FreeBSD.org> In-Reply-To: <20111227041728.GI8035@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201112291136.01889.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 11:41:01 -0500 (EST) Cc: Robert Watson , net@freebsd.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:41:02 -0000 On Monday, December 26, 2011 11:17:28 pm Gleb Smirnoff wrote: > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: > J> You can find the patch for 8.x at > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch > > Just my two pennies: for head/ patching if ip_carp.c should > be straightforward: > > 1) Using W in carp_alloc_if() and carp_free_if(). > 2) Using R everywhere else. Yes, this is what I did, but with an extra XXX: @@ -1512,10 +1512,11 @@ carp_alloc_if(struct ifnet *ifp) cif->cif_ifp = ifp; TAILQ_INIT(&cif->cif_vrs); - IF_ADDR_LOCK(ifp); + /* XXX: Race, shouldn't this be checking for concurrent calls? */ + IF_ADDR_WLOCK(ifp); ifp->if_carp = cif; if_ref(ifp); - IF_ADDR_UNLOCK(ifp); + IF_ADDR_WUNLOCK(ifp); return (cif); @@ -1534,10 +1535,10 @@ carp_free_if(struct carp_if *cif) KASSERT(TAILQ_EMPTY(&cif->cif_vrs), ("%s: softc list not empty", __func__)); - IF_ADDR_LOCK(ifp); + IF_ADDR_WLOCK(ifp); ifp->if_carp = NULL; if_rele(ifp); - IF_ADDR_UNLOCK(ifp); + IF_ADDR_WUNLOCK(ifp); CIF_LOCK_DESTROY(cif); Specifically, if two threads both call carp_alloc() at the same time and both see a value of NULL for ifp->if_carp (and I really do not like side effects like assignments in conditional expressions of if() and while()), then both threads can call carp_if_alloc(). Instead, carp_if_alloc() should be doing something like this: IF_ADDR_LOCK(ifp); if (ifp->if_carp != NULL) { CIF_LOCK_DESTROY(cif); free(cif, M_CARP); cif = ifp->if_carp; } else ifp->if_carp = cif; IF_ADDR_UNLOCK(ifp); return (cif); Similarly, you have a race in the SIOCSVH ioctl handling code. You check for a duplicate carp device for a specific (ifnet, vhid), tuple, but carp_alloc() doesn't do a recheck when adding the new softc to the cif_vrs list. Rather, what it should do is move that loop into carp_alloc() while holding the CIF_LOCK() and free the already-created softc and fail carp_alloc() if it finds a duplicate. You also have a race between concurrent carp_alloc() and carp_destroy(). Specifically, carp_alloc() might find a cif and be in the process of building a new carp softc when a carp_destroy() tears down the cif. The right way to fix this is to add a reference count to the cif and have carp_alloc_if() always bump the reference count. carp_destroy() would need to drop the reference count, but under IF_ADDR_LOCK() and only do a carp_free_if() if the count drops to zero. You'd have to grab IF_ADDR_LOCK() in the caller and let carp_free_if() unlock it internally. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 17:13:12 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC5A41065670; Thu, 29 Dec 2011 17:13:12 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 41D4E8FC14; Thu, 29 Dec 2011 17:13:12 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBTHDBar019188; Thu, 29 Dec 2011 21:13:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBTHDApD019187; Thu, 29 Dec 2011 21:13:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 29 Dec 2011 21:13:10 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20111229171310.GB12721@glebius.int.ru> References: <201112221130.01823.jhb@freebsd.org> <20111227041728.GI8035@FreeBSD.org> <201112291136.01889.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201112291136.01889.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Watson , net@FreeBSD.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 17:13:13 -0000 On Thu, Dec 29, 2011 at 11:36:01AM -0500, John Baldwin wrote: J> On Monday, December 26, 2011 11:17:28 pm Gleb Smirnoff wrote: J> > On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote: J> > J> You can find the patch for 8.x at J> > J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch J> > J> > Just my two pennies: for head/ patching if ip_carp.c should J> > be straightforward: J> > J> > 1) Using W in carp_alloc_if() and carp_free_if(). J> > 2) Using R everywhere else. J> J> Yes, this is what I did, but with an extra XXX: J> J> @@ -1512,10 +1512,11 @@ carp_alloc_if(struct ifnet *ifp) J> cif->cif_ifp = ifp; J> TAILQ_INIT(&cif->cif_vrs); J> J> - IF_ADDR_LOCK(ifp); J> + /* XXX: Race, shouldn't this be checking for concurrent calls? */ J> + IF_ADDR_WLOCK(ifp); J> ifp->if_carp = cif; J> if_ref(ifp); J> - IF_ADDR_UNLOCK(ifp); J> + IF_ADDR_WUNLOCK(ifp); J> J> return (cif); J> J> @@ -1534,10 +1535,10 @@ carp_free_if(struct carp_if *cif) J> KASSERT(TAILQ_EMPTY(&cif->cif_vrs), ("%s: softc list not empty", J> __func__)); J> J> - IF_ADDR_LOCK(ifp); J> + IF_ADDR_WLOCK(ifp); J> ifp->if_carp = NULL; J> if_rele(ifp); J> - IF_ADDR_UNLOCK(ifp); J> + IF_ADDR_WUNLOCK(ifp); J> J> CIF_LOCK_DESTROY(cif); J> J> J> Specifically, if two threads both call carp_alloc() at the same time and both J> see a value of NULL for ifp->if_carp (and I really do not like side effects J> like assignments in conditional expressions of if() and while()), then both J> threads can call carp_if_alloc(). Instead, carp_if_alloc() should be doing J> something like this: J> J> IF_ADDR_LOCK(ifp); J> if (ifp->if_carp != NULL) { J> CIF_LOCK_DESTROY(cif); J> free(cif, M_CARP); J> cif = ifp->if_carp; J> } else J> ifp->if_carp = cif; J> IF_ADDR_UNLOCK(ifp); J> J> return (cif); J> J> Similarly, you have a race in the SIOCSVH ioctl handling code. You check J> for a duplicate carp device for a specific (ifnet, vhid), tuple, but J> carp_alloc() doesn't do a recheck when adding the new softc to the cif_vrs J> list. Rather, what it should do is move that loop into carp_alloc() while J> holding the CIF_LOCK() and free the already-created softc and fail J> carp_alloc() if it finds a duplicate. J> J> You also have a race between concurrent carp_alloc() and carp_destroy(). J> Specifically, carp_alloc() might find a cif and be in the process of building J> a new carp softc when a carp_destroy() tears down the cif. The right way to J> fix this is to add a reference count to the cif and have carp_alloc_if() J> always bump the reference count. carp_destroy() would need to drop the J> reference count, but under IF_ADDR_LOCK() and only do a carp_free_if() if the J> count drops to zero. You'd have to grab IF_ADDR_LOCK() in the caller and let J> carp_free_if() unlock it internally. I know all these races. When hacking on new CARP, I understood that trying to avoid them would make code much more hairy. Also, races between two threads that change configuration of networking exist not in CARP only. So I decided to make a sleepable serializer of the ioctl, like I suggested on mail thread about if_cloners, and then you noticed that sx_lock() is already invented and works better :) So the question is still open, I think that we need some clear and generic approach like serializing ifioctl(), instead of making zillions of re-checking and rollbacking when we temporary drop some nerworking lock for malloc(M_WAITOK). As temporary measure we can use this serializing lock not in ifioctl() but in more specific branches of ioctl() call tree, for example in carp_ioctl(). -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 18:21:30 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320661065687; Thu, 29 Dec 2011 18:21:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E3A528FC18; Thu, 29 Dec 2011 18:21:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8136F46B2C; Thu, 29 Dec 2011 13:21:29 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EB129B93F; Thu, 29 Dec 2011 13:21:28 -0500 (EST) From: John Baldwin To: Sergey Kandaurov Date: Thu, 29 Dec 2011 12:12:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231446.38057.jhb@freebsd.org> <4EF6752C.4040109@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112291212.52682.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 13:21:29 -0500 (EST) Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Minor fixes to netinet6/icmp6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:21:30 -0000 On Sunday, December 25, 2011 4:45:55 am Sergey Kandaurov wrote: > On 25 December 2011 04:58, John Baldwin wrote: > > On 12/23/11 6:38 PM, Sergey Kandaurov wrote: > >> > >> On 23 December 2011 23:46, John Baldwin wrote: > >>> > >>> I found these nits while working on the patches to convert if_addr_mtx to > >>> an > >>> rwlock. The first change is cosmetic, it just un-inlines a > >>> TAILQ_FOREACH(). > >>> The second change is an actual bug. The code is currently reading > >>> TAILQ_FIRST(&V_ifnet) without holding the appropriate lock. > >>> > >>> Index: icmp6.c > >>> =================================================================== > >>> --- icmp6.c (revision 228777) > >>> +++ icmp6.c (working copy) > >>> @@ -1780,7 +1780,7 @@ ni6_addrs(struct icmp6_nodeinfo *ni6, struct mbuf > >>> } > >>> > >>> IFNET_RLOCK_NOSLEEP(); > >>> - for (ifp = TAILQ_FIRST(&V_ifnet); ifp; ifp = TAILQ_NEXT(ifp, > >>> if_list)) { > >>> + TAILQ_FOREACH(ifp,&V_ifnet, if_list) { > >>> addrsofif = 0; > >>> IF_ADDR_LOCK(ifp); > >>> TAILQ_FOREACH(ifa,&ifp->if_addrhead, ifa_link) { > >> > >> > >> FWIW, there are much more of them in netinet6. > >> Some time ago I started to un-expand them to queue(3). > >> [not unfinished yet..] > > > > > > I went ahead and did a sweep for queue(3) changes in netinet6. I went a bit > Great, thank you! This sweep is long overdue. > > > further and removed things like the ndpr_next hack, etc. This only includes > > queue(3) changes though, not your other fixes like moving common code out of > Oops, yeah. This is an unrelated change. > > > blocks. I also fixed a few places to use *_EMPTY() instead of checking > > *_FIRST() against NULL. There should be no functional change. > > > > http://www.FreeBSD.org/~jhb/patches/inet6_queue.patch > > Looks good. Please, commit with two notes: > > a) You changed a loop with precondition > while (i < DRLSTSIZ) { ... } > into > if (i >= DRLSTSIZ) > and moved it below i++ increment, which effectively became > a loop with post-condition like do { ...} while (). > To preserve the current behavior I would move this check up > right under *_FOREACH() loop, like this: > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > if (i >= DRLSTSIZ) > break; Note that i is initialized to 0 before the loop starts (albeit that is harder to see because of the style bug of it being initialized in its declaration). I considered instead rewriting this as: for (i = 0, dr = TAILQ_FIRST(&V_nd_defrouter); dr && i < DRLSTSIZ; i++, dr = TAILQ_NEXT(dr, dr_entry)) { However, that is a bit verbose. I can move it up, the compiler probably "knows" that i is zero on the first loop and might skip the check anyway. > b) > It should be safe to use non-SAFE() FOREACH() variants of > queue(3) macros for most occurrences. SAFE() versions are > usually only used when you need to add/remove an element > on list w/o need to subsequent restart the *_FOREACH() loop. I only used them where the existing code was already using that idiom. I just checked them all and each instance is potentially freeing or deleting the current item while iterating the list. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 20:26:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE595106566B; Thu, 29 Dec 2011 20:26:08 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5357A8FC14; Thu, 29 Dec 2011 20:26:08 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4F61F821; Thu, 29 Dec 2011 21:26:06 +0100 (CET) Date: Thu, 29 Dec 2011 21:25:02 +0100 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20111229202501.GA1889@garage.freebsd.pl> References: <20111022084931.GD1697@garage.freebsd.pl> <201112200952.44690.jhb@freebsd.org> <1632420869.20111225180133@yandex.ru> <201112291112.59912.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <201112291112.59912.jhb@freebsd.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andre Oppermann , freebsd-net@freebsd.org, =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= , freebsd-current@freebsd.org, Kostik Belousov , Lawrence Stewart Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 20:26:09 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2011 at 11:12:59AM -0500, John Baldwin wrote: > On Sunday, December 25, 2011 11:01:33 am =D0=9A=D0=BE=D0=BD=D1=8C=D0=BA= =D0=BE=D0=B2 =D0=95=D0=B2=D0=B3=D0=B5=D0=BD=D0=B8=D0=B9 wrote: > > =D0=97=D0=B4=D1=80=D0=B0=D0=B2=D1=81=D1=82=D0=B2=D1=83=D0=B9=D1=82=D0= =B5, John. > >=20 > > =D0=92=D1=8B =D0=BF=D0=B8=D1=81=D0=B0=D0=BB=D0=B8 20 =D0=B4=D0=B5=D0=BA= =D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16:52:44: > >=20 > > JB> On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote: > > >> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: > > >> > An update. I've sent Pawel a testing patch to see if my hypothesi= s is correct > > >> > (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is th= en I intend > > >> > to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fi= x. > > >>=20 > > >> Unfortunately it paniced today. Take a look at: > > >>=20 > > >> http://people.freebsd.org/~pjd/misc/tcp_panic.jpg > >=20 > > JB> Ok, the one use case I was worried about is happening regularly bef= ore your > > JB> panic, so that is good. Can you use gdb to figure out which call to > > JB> tcp_output() is actually panic'ing? I wonder if it is this case: > >=20 > > JB> /* > > JB> * Return any desired output. > > JB> */ > > JB> if (needoutput || (tp->t_flags & TF_ACKNOW)) { > > JB> (void) tcp_output(tp); > > JB> /* XXX: Debug */ > > JB> KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), > > JB> ("tcp_input: negative window after ACK")); > >=20 > > JB> And if 'needoutput' is true, but TF_ACKNOW is not set, and tcp_outp= ut() decides > > JB> to not do anything. I've updated tcp_negwin_test.patch to not pani= c if that call > > JB> to tcp_output() doesn't actually send a packet. Please re-test. > >=20 > >=20 > > # uname -a > > FreeBSD meta-up 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #4: Sat Dec 24 13= :59:20 EET 2011 @:/usr/obj/usr/src/sys/KES_KERN_v10 i386 > >=20 > > rebooting once per day. Now I compile kernel with debug options. > > Can you advice me which and where I find debug info when it will > > reboting next time? so I can help to debug problem >=20 > Are you using the patch at the URL above (tcp_negwin_test.patch)? If not, > can you try applying that patch and seeing if you still get any panics? I applied 1.5 days ago, so far now panics and no other messages. I modified the patch a bit to not panic, but print a message when panic was suppose to happen. This box is too valuable for me to panic it too often. Because there were no debug messages I understand that the scenerio didn't happen yet and not that the problem is fixed, right? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk78zJ0ACgkQForvXbEpPzR7RACcC+FS4llTUDG0av+6s26iwxl3 OOsAoPTMGfHUwJg+TgWm9gdJb+NXuIB5 =dh23 -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 20:27:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBCB1065679; Thu, 29 Dec 2011 20:27:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D04108FC18; Thu, 29 Dec 2011 20:27:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 88C3A46B3F; Thu, 29 Dec 2011 15:27:31 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6FF0AB93F; Thu, 29 Dec 2011 15:27:29 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org, Robert Watson Date: Thu, 29 Dec 2011 15:27:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> In-Reply-To: <201112221130.01823.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112291527.26763.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 15:27:31 -0500 (EST) Cc: Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 20:27:32 -0000 On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote: > Another bit of lock contention I ran into between a device driver doing slow > MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device drivers > typically hold this lock while iterating the list of multicast addresses to > program their MAC filter. OTOH, ip_input() uses this lock to check to see if > an incoming packet is a broadcast packet or not. So even with the pcbinfo > contention from my previous patch addressed, I still ran into a problem with > IF_ADDR_LOCK(). We already have some partial support for making this lock be > an rwlock (the APIs that drivers now use implies an rlock), so I finished the > transition and checked various non-driver users to see which ones could use a > read lock (most uses can). The current patch I have for this is on 8, but if > folks think this is a good idea I can work on porting it to HEAD. For HEAD > the strategy I would use would be to split this up into 2 phases: > > 1) Add IF_ADDR locking macros to differentiate read locks vs write locks along > with appropriate assertion macros. Update current users of the locking > macros to use either read or write locks explicitly. To preserve KPI, > the existing LOCK/UNLOCK macros would map to write lock operations. In > the initial patch, the locking would still be implemented via a mtx. > > 2) Replace the mutex with an rwlock and update the locking macros as > appropriate. > > Phase 1 should definitely be MFC'able. Phase 2 may or may not be. Robert had > the foresight to change drivers to use explicit function wrappers around > IF_ADDR_LOCK, and sizeof(struct mtx) == sizeof(struct rwlock), so if we > changed the lock type the KBI for existing device drivers would all be fine. > Most of the remaining uses of the locking macros are in parts of the kernel > that aren't loadable (such as inet and inet6). We can look at the places that > to do change and if any of them are in kld's then it would be up to re@ to > decide if 2) was actually safe to merge. However, even if Phase 2 cannot be > MFC'd, having phase 1 makes it easier for downstream consumers to apply Phase > 2 locally if they need it. I've gone ahead with this approach. I have three separate patches that should implement Phase 1. All of them can be found at http://www.FreeBSD.org/~jhb/patches/ - if_addr_dev.patch This fixes a few new device drivers that were using the locking macros directly rather than the wrapper functions Robert added. I've already sent this directly to the relevant driver maintainers for their review. - if_addr_macros.patch This adds new locking macros to support read locks vs write locks. However, they all still map to mutex operations. - if_addr_uses.patch This changes callers of the existing macros to use either read or write locks. This is the patch that could use the most review. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 21:21:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5E51065672; Thu, 29 Dec 2011 21:21:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1BAD78FC0C; Thu, 29 Dec 2011 21:21:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id ACD4846B0D; Thu, 29 Dec 2011 16:21:04 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 29175B93A; Thu, 29 Dec 2011 16:21:04 -0500 (EST) From: John Baldwin To: Pawel Jakub Dawidek Date: Thu, 29 Dec 2011 16:18:42 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <201112291112.59912.jhb@freebsd.org> <20111229202501.GA1889@garage.freebsd.pl> In-Reply-To: <20111229202501.GA1889@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112291618.43170.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 16:21:04 -0500 (EST) Cc: =?utf-8?q?=D0=9A=D0=BE=D0=BD=D1=8C=D0=BA=D0=BE=D0=B2?=, Andre Oppermann , freebsd-net@freebsd.org, =?utf-8?q?_=D0=95=D0=B2=D0=B3=D0=B5=D0=BD=D0=B8=D0=B9?= , freebsd-current@freebsd.org, Kostik Belousov , Lawrence Stewart Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:21:05 -0000 On Thursday, December 29, 2011 3:25:02 pm Pawel Jakub Dawidek wrote: > On Thu, Dec 29, 2011 at 11:12:59AM -0500, John Baldwin wrote: > > On Sunday, December 25, 2011 11:01:33 am =D0=9A=D0=BE=D0=BD=D1=8C=D0=BA= =D0=BE=D0=B2 =D0=95=D0=B2=D0=B3=D0=B5=D0=BD=D0=B8=D0=B9 wrote: > > > =D0=97=D0=B4=D1=80=D0=B0=D0=B2=D1=81=D1=82=D0=B2=D1=83=D0=B9=D1=82=D0= =B5, John. > > >=20 > > > =D0=92=D1=8B =D0=BF=D0=B8=D1=81=D0=B0=D0=BB=D0=B8 20 =D0=B4=D0=B5=D0= =BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16:52:44: > > >=20 > > > JB> On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wro= te: > > > >> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: > > > >> > An update. I've sent Pawel a testing patch to see if my hypothe= sis is correct > > > >> > (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is = then I intend > > > >> > to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the = fix. > > > >>=20 > > > >> Unfortunately it paniced today. Take a look at: > > > >>=20 > > > >> http://people.freebsd.org/~pjd/misc/tcp_panic.jpg > > >=20 > > > JB> Ok, the one use case I was worried about is happening regularly b= efore your > > > JB> panic, so that is good. Can you use gdb to figure out which call= to > > > JB> tcp_output() is actually panic'ing? I wonder if it is this case: > > >=20 > > > JB> /* > > > JB> * Return any desired output. > > > JB> */ > > > JB> if (needoutput || (tp->t_flags & TF_ACKNOW)) { > > > JB> (void) tcp_output(tp); > > > JB> /* XXX: Debug */ > > > JB> KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt), > > > JB> ("tcp_input: negative window after ACK")); > > >=20 > > > JB> And if 'needoutput' is true, but TF_ACKNOW is not set, and tcp_ou= tput() decides > > > JB> to not do anything. I've updated tcp_negwin_test.patch to not pa= nic if that call > > > JB> to tcp_output() doesn't actually send a packet. Please re-test. > > >=20 > > >=20 > > > # uname -a > > > FreeBSD meta-up 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #4: Sat Dec 24 = 13:59:20 EET 2011 @:/usr/obj/usr/src/sys/KES_KERN_v10 i386 > > >=20 > > > rebooting once per day. Now I compile kernel with debug options. > > > Can you advice me which and where I find debug info when it will > > > reboting next time? so I can help to debug problem > >=20 > > Are you using the patch at the URL above (tcp_negwin_test.patch)? If n= ot, > > can you try applying that patch and seeing if you still get any panics? >=20 > I applied 1.5 days ago, so far now panics and no other messages. > I modified the patch a bit to not panic, but print a message when panic > was suppose to happen. This box is too valuable for me to panic it too > often. Because there were no debug messages I understand that the > scenerio didn't happen yet and not that the problem is fixed, right? Yes. It would be best to see the messages logged to be safe. Thanks. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 29 22:55:41 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0249B1065672; Thu, 29 Dec 2011 22:55:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 870748FC15; Thu, 29 Dec 2011 22:55:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBTMtdAK020548; Fri, 30 Dec 2011 02:55:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBTMtdOM020547; Fri, 30 Dec 2011 02:55:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 30 Dec 2011 02:55:39 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20111229225539.GD12721@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <201112291527.26763.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 22:55:41 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote: J> - if_addr_uses.patch This changes callers of the existing macros to use J> either read or write locks. This is the patch that J> could use the most review. Reviewing your patch I've found several problems not introduced by it, but already existing, and somewhat related to your patch: 1) Unneeded use of _SAFE version of TAILQ: igmp.c:3338 in6.c:1339 mld6.c:2993 2) Potential race when dropping a lock inside FOREACH loop: igmp.c:2058 mld6.c:1419 mld6.c:1704 (this one isn't even a SAFE, so would crash earlier) 3) I've found that in6_ifawithifp() doesn't do what it is supposed to, as well as uses incorrect locking during this. As last resort it should run through global list of addresses, not run throgh the ifp one again. Patch attached. -- Totus tuus, Glebius. --3MwIy2ne0vdjdPXF Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="in6.c.diff" Index: in6.c =================================================================== --- in6.c (revision 228971) +++ in6.c (working copy) @@ -2188,10 +2188,10 @@ { int dst_scope = in6_addrscope(dst), blen = -1, tlen; struct ifaddr *ifa; - struct in6_ifaddr *besta = 0; + struct in6_ifaddr *ia; struct in6_ifaddr *dep[2]; /* last-resort: deprecated */ - dep[0] = dep[1] = NULL; + ia = dep[0] = dep[1] = NULL; /* * We first look for addresses in the same scope. @@ -2219,45 +2219,43 @@ /* * call in6_matchlen() as few as possible */ - if (besta) { + if (ia) { if (blen == -1) - blen = in6_matchlen(&besta->ia_addr.sin6_addr, dst); + blen = in6_matchlen(&ia->ia_addr.sin6_addr, dst); tlen = in6_matchlen(IFA_IN6(ifa), dst); if (tlen > blen) { blen = tlen; - besta = (struct in6_ifaddr *)ifa; + ia = (struct in6_ifaddr *)ifa; } } else - besta = (struct in6_ifaddr *)ifa; + ia = (struct in6_ifaddr *)ifa; } } - if (besta) { - ifa_ref(&besta->ia_ifa); + if (ia) { + ifa_ref(&ia->ia_ifa); IF_ADDR_UNLOCK(ifp); - return (besta); + return (ia); } IF_ADDR_UNLOCK(ifp); IN6_IFADDR_RLOCK(); - TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family != AF_INET6) - continue; - if (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_ANYCAST) + TAILQ_FOREACH(ia, &V_in6_ifaddrhead, ia_link) { + if (ia->ia6_flags & IN6_IFF_ANYCAST) continue; /* XXX: is there any case to allow anycast? */ - if (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_NOTREADY) + if (ia->ia6_flags & IN6_IFF_NOTREADY) continue; /* don't use this interface */ - if (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_DETACHED) + if (ia->ia6_flags & IN6_IFF_DETACHED) continue; - if (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_DEPRECATED) { + if (ia->ia6_flags & IN6_IFF_DEPRECATED) { if (V_ip6_use_deprecated) dep[1] = (struct in6_ifaddr *)ifa; continue; } - if (ifa != NULL) - ifa_ref(ifa); + if (ia != NULL) + ifa_ref(&ia->ia_ifa); IN6_IFADDR_RUNLOCK(); - return (struct in6_ifaddr *)ifa; + return (ia); } IN6_IFADDR_RUNLOCK(); --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 01:20:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5404106564A for ; Fri, 30 Dec 2011 01:20:14 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id A4F5C8FC13 for ; Fri, 30 Dec 2011 01:20:14 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 6D7C322812 for ; Fri, 30 Dec 2011 01:20:13 +0000 (UTC) Received: from [127.0.0.1] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id D00CC10025C27; Fri, 30 Dec 2011 01:20:24 +0000 (GMT) Message-ID: <4EFD11C8.7090409@rewt.org.uk> Date: Fri, 30 Dec 2011 01:20:08 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Baldwin References: <4EF8D0A2.5010604@rewt.org.uk> <20111227032528.GA1844@michelle.cdnetworks.com> <20111227040551.GH8035@FreeBSD.org> <201112291124.23626.jhb@freebsd.org> In-Reply-To: <201112291124.23626.jhb@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 01:20:15 -0000 John Baldwin wrote: > On Monday, December 26, 2011 11:05:51 pm Gleb Smirnoff wrote: >> On Mon, Dec 26, 2011 at 07:25:29PM -0800, YongHyeon PYUN wrote: >> Y> Index: sys/net/if_vlan.c >> Y> =================================================================== >> Y> --- sys/net/if_vlan.c (revision 228906) >> Y> +++ sys/net/if_vlan.c (working copy) >> Y> @@ -1012,10 +1012,12 @@ >> Y> { >> Y> struct ifvlan *ifv; >> Y> struct ifnet *p; >> Y> - int error; >> Y> + int error, len, mcast; >> Y> >> Y> ifv = ifp->if_softc; >> Y> p = PARENT(ifv); >> Y> + len = m->m_pkthdr.len; >> Y> + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; >> Y> >> Y> BPF_MTAP(ifp, m); >> Y> >> Y> @@ -1025,7 +1027,7 @@ >> Y> */ >> Y> if (!UP_AND_RUNNING(p)) { >> Y> m_freem(m); >> Y> - ifp->if_collisions++; >> Y> + ifp->if_oerrors++; >> Y> return (0); >> Y> } >> Y> >> Y> @@ -1081,9 +1083,11 @@ >> Y> * Send it, precisely as ether_output() would have. >> Y> */ >> Y> error = (p->if_transmit)(p, m); >> Y> - if (!error) >> Y> + if (!error) { >> Y> ifp->if_opackets++; >> Y> - else >> Y> + ifp->if_omcasts += mcast; >> Y> + ifp->if_obytes += len; >> Y> + } else >> Y> ifp->if_oerrors++; >> Y> return (error); >> Y> } >> >> Thanks, Pyun! You can count me in as reviewer. >> >> I have also added jhb@ to Cc, the author of changed code, so that he >> can review, too. > > I didn't really change it, I just unindented it when the loop was removed > during the transition to if_transmit. :) However, this patch looks good to > me. > I have been running with this patch for a couple of days now, counters appear to be working as expected Thanks, Joe From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 01:34:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67821106564A; Fri, 30 Dec 2011 01:34:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10EF68FC14; Fri, 30 Dec 2011 01:34:55 +0000 (UTC) Received: by iadj38 with SMTP id j38so30958215iad.13 for ; Thu, 29 Dec 2011 17:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=S6Zdn/tu9Fp9iFjw3VitDYUzZpr936Qhopxf4MM9IKo=; b=b1TYkhp+yaLfGMaueOBNOXUxVsNJC8Ze3szn9dldX9bJCjFPL2mUnIO7IBtuLzYPCq 9/dX8Pra/wf0cRRaJdoWSlOGPtfAIt3ZNJ1JbjLKIRIDpCxhz4sC17n0Zb0NreJr+jzm HqMtdH9kypC4DNPeSF4/3/XcNlHBhoQ1IUtH0= Received: by 10.42.244.137 with SMTP id lq9mr39044516icb.28.1325208895586; Thu, 29 Dec 2011 17:34:55 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id h9sm121258949ibh.11.2011.12.29.17.34.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 17:34:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 29 Dec 2011 17:32:59 -0800 From: YongHyeon PYUN Date: Thu, 29 Dec 2011 17:32:59 -0800 To: Joe Holden Message-ID: <20111230013259.GH10465@michelle.cdnetworks.com> References: <4EF8D0A2.5010604@rewt.org.uk> <20111227032528.GA1844@michelle.cdnetworks.com> <20111227040551.GH8035@FreeBSD.org> <201112291124.23626.jhb@freebsd.org> <4EFD11C8.7090409@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFD11C8.7090409@rewt.org.uk> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , John Baldwin Subject: Re: bsnmpd not showing out octets for vlan interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 01:34:56 -0000 On Fri, Dec 30, 2011 at 01:20:08AM +0000, Joe Holden wrote: > John Baldwin wrote: > >On Monday, December 26, 2011 11:05:51 pm Gleb Smirnoff wrote: > >>On Mon, Dec 26, 2011 at 07:25:29PM -0800, YongHyeon PYUN wrote: > >>Y> Index: sys/net/if_vlan.c > >>Y> =================================================================== > >>Y> --- sys/net/if_vlan.c (revision 228906) > >>Y> +++ sys/net/if_vlan.c (working copy) > >>Y> @@ -1012,10 +1012,12 @@ > >>Y> { > >>Y> struct ifvlan *ifv; > >>Y> struct ifnet *p; > >>Y> - int error; > >>Y> + int error, len, mcast; > >>Y> > >>Y> ifv = ifp->if_softc; > >>Y> p = PARENT(ifv); > >>Y> + len = m->m_pkthdr.len; > >>Y> + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; > >>Y> > >>Y> BPF_MTAP(ifp, m); > >>Y> > >>Y> @@ -1025,7 +1027,7 @@ > >>Y> */ > >>Y> if (!UP_AND_RUNNING(p)) { > >>Y> m_freem(m); > >>Y> - ifp->if_collisions++; > >>Y> + ifp->if_oerrors++; > >>Y> return (0); > >>Y> } > >>Y> > >>Y> @@ -1081,9 +1083,11 @@ > >>Y> * Send it, precisely as ether_output() would have. > >>Y> */ > >>Y> error = (p->if_transmit)(p, m); > >>Y> - if (!error) > >>Y> + if (!error) { > >>Y> ifp->if_opackets++; > >>Y> - else > >>Y> + ifp->if_omcasts += mcast; > >>Y> + ifp->if_obytes += len; > >>Y> + } else > >>Y> ifp->if_oerrors++; > >>Y> return (error); > >>Y> } > >> > >>Thanks, Pyun! You can count me in as reviewer. > >> > >>I have also added jhb@ to Cc, the author of changed code, so that he > >>can review, too. > > > >I didn't really change it, I just unindented it when the loop was removed > >during the transition to if_transmit. :) However, this patch looks good to > >me. > > > I have been running with this patch for a couple of days now, counters > appear to be working as expected > FYI: patch committed to HEAD(r228967). > Thanks, > Joe From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 14:59:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 830A2106566B for ; Fri, 30 Dec 2011 14:59:06 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9398FC08 for ; Fri, 30 Dec 2011 14:59:06 +0000 (UTC) Received: by iadj38 with SMTP id j38so32203595iad.13 for ; Fri, 30 Dec 2011 06:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=hcSdgUZ5GmCsJw+Sqfsi05Sa5l4uEjYYJrh0uRyxzBU=; b=EvhrR3qbHZ5r6Tnh1Khyx0p8r4xmWhAr2ZG8hW1k5tdBP0kTT++n0y9E34g/1ecXI4 GUPLbdnRBeGZIElkOGHw63Q7zhDLK7X4XaeoMOwSCgNKWXNCnofUYDi+sI4LB2DrEKHm YHIoPJ3PojcSgB1iKqgTJXO4bK3AXkl+EnZo0= Received: by 10.42.153.6 with SMTP id k6mr41738787icw.30.1325257145769; Fri, 30 Dec 2011 06:59:05 -0800 (PST) Received: from DataIX.net (24-247-9-230.dhcp.aldl.mi.charter.com. [24.247.9.230]) by mx.google.com with ESMTPS id rc7sm86242619igb.0.2011.12.30.06.59.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Dec 2011 06:59:03 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pBUEx13V031314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Dec 2011 09:59:01 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pBUEws0W031308; Fri, 30 Dec 2011 09:58:54 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Fri, 30 Dec 2011 09:58:54 -0500 From: Jason Hellenthal To: "Bjoern A. Zeeb" Message-ID: <20111230145854.GA22414@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: Cc: freebsd-net@freebsd.org, Marcin Cieslak Subject: Re: IPv6 not responding on some aliases (recent 8-stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 14:59:06 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2011 at 09:17:09AM +0000, Bjoern A. Zeeb wrote: >=20 > On 22. Dec 2011, at 20:39 , Marcin Cieslak wrote: >=20 > >>> Bjoern A. Zeeb wrote: > >>> I initially thought it's a transport layer issue, since previously (b= efore > >>> I changed configuration) 30%-50% SSH connection attempts succeeded > >>> (but prefix was wrong on the "primary" IPv6 address :1000). > >>> Now I get no packets on receiving side at all for those "broken" IPv6= addresses. > >>=20 > >> Talk to ywhomever is providing in front of you to > >> 1) either relax nd6 table limits or > >> 2) to route a /64 to your host to only have 1 entry in the neighbour t= able. > >>=20 > >> That's most likely the problem given my crystal ball and experience. > >=20 > > Thank you for insightful analysis!=20 > > Seems like this provider has some significant IPv6 takeup, which is > > good news - sorry for hassle, but problems started after upgrade.=20 > >=20 > > I'll talk to my upstream then, thanks! >=20 > Please let us know of the results, especially if my crystal ball was wron= g. >=20 I have seen this behavior before when one of the addresses on an interface = is in a DMZ while the others are not. But this was with IPv4. I would assum= e IPv6 would have acted the same way but left it untested as it was not cri= tical. Take this as informational only and double check your switches, fire= walls, etc... --=20 ;s =3D; --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO/dGtAAoJEJBXh4mJ2FR+QVgH/Rk8Ns+BRylps4qCSCNTbWg8 iIdYhCFP2rQmdZUdRlbrIAVFaKGQawYiBGh/cYmaA9zZ9t5kF0oIGBLcW2Xtz/eA 30M0vyUN/m6UDLK1ERttZ/mNdQUTsZpPtaSYoKNjW8D+KttNL1cNE9LRwfSs4aPU UIiA3NTqrfoue1QWsqz23UkOI9EY1fU54xKlEKGRGXzlErQoAumxKB8OCGnazgON yBJWVS1zgSvb5Lz9AOhZqTjBaFntqWyUK4D+T21+B71F/TjGDtJxpsV9LFvjP2R3 GgUaLp/OFAZefcOFCTEVuVp12eoPeTKQO961ysiSc+76aZBOvmvwlYULTZmNV+4= =VknF -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 19:48:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B44106564A; Fri, 30 Dec 2011 19:48:36 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0D78FC13; Fri, 30 Dec 2011 19:48:36 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RgiRP-000DOY-0b; Fri, 30 Dec 2011 11:48:35 -0800 Message-ID: <4EFE158C.2040705@FreeBSD.org> Date: Fri, 30 Dec 2011 11:48:28 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 19:48:36 -0000 On 11/24/2011 11:24 PM, Robert N. M. Watson wrote: >>> There was recently a commit to fix a race condition in 10-CURRENT which >>> >> I think is not slated to be merged for 9.0. You might check the commit >>> >> logs there and see if that fixes the problems you have -- if so, we >>> >> might want to reconsider the plan not to merge for 9.0. >>> >> >>> >> (It relates to a race condition on closing sockets..) >> > >> > Thank you for the tip. I will give it a try and see what happens. So far, after installing that trap we have not seen any panics yet. I have not checked logs yet if my trap actually has catch anything or not. > Do we know if this fix has been merged to stable/9 and releng/9.0? Given multiple reports of instability without it, I think we would be well-served to merge it at this point. Hey Robert, sorry to bother you again, but can you at least point me towards specific SVN revisions that I need to get merged? I tried to google it and also browsed my svn history for the last 4 months using keyword "sockets", but nothing came up. This fix is critical for any system that does lot of fault-ctitical networking, and FreeBSD has always been solid in this regard. It saved us at least 10-15 crashes across 5 machines in the last month. Thanks! -Maxim From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 23:08:16 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7611065670 for ; Fri, 30 Dec 2011 23:08:16 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3E08FC0C for ; Fri, 30 Dec 2011 23:08:15 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBUN8EPk027210; Sat, 31 Dec 2011 03:08:14 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBUN8ExZ027209; Sat, 31 Dec 2011 03:08:14 +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, 31 Dec 2011 03:08:14 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20111230230814.GG12721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227192238.GV8035@glebius.int.ru> 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: net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 23:08:16 -0000 Sami, On Tue, Dec 27, 2011 at 11:08:47PM +0200, Sami Halabi wrote: S> Thanks for your patch, i applied it and its production already. S> i had to stop mpd, and once started it i saw that all home routers S> connected immediatly. S> most of them don't use mppc, so I wonder why this problem happend in the S> first place. S> whats surprising i had few hours ago the same problem: S> Dec 27 14:11:29 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped, disabling node 0xffffff000ba12700! S> Dec 27 14:11:29 mpd2 kernel: S> Dec 27 19:19:10 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped, disabling node 0xffffff0006307400! S> Dec 27 19:19:10 mpd2 kernel: S> S> i hope the patch will solve the problem for good now, i'll let it work for S> the coming few days andif something will go wrong i'll paste you. How is the patched kernel running? Do you use L2TP or PPPoE? /me uses PPTP mostly, which handles any reordering problems correctly, so I can't even test my patch. If I produce a reordering event artifically, the ng_pptpgre filters bogus packet out. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Dec 30 23:31:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41EE1106564A; Fri, 30 Dec 2011 23:31:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 16A718FC08; Fri, 30 Dec 2011 23:31:46 +0000 (UTC) Received: from [192.168.2.105] (host86-161-238-124.range86-161.btcentralplus.com [86.161.238.124]) by cyrus.watson.org (Postfix) with ESMTPSA id 10DA846B09; Fri, 30 Dec 2011 18:31:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: <4EFE158C.2040705@FreeBSD.org> Date: Fri, 30 Dec 2011 23:31:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> <4EFE158C.2040705@FreeBSD.org> To: Maxim Sobolev X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 23:31:46 -0000 On 30 Dec 2011, at 19:48, Maxim Sobolev wrote: > On 11/24/2011 11:24 PM, Robert N. M. Watson wrote: >>>> There was recently a commit to fix a race condition in 10-CURRENT = which >>>> >> I think is not slated to be merged for 9.0. You might check the = commit >>>> >> logs there and see if that fixes the problems you have -- if = so, we >>>> >> might want to reconsider the plan not to merge for 9.0. >>>> >> >>>> >> (It relates to a race condition on closing sockets..) >>> > >>> > Thank you for the tip. I will give it a try and see what happens. = So far, after installing that trap we have not seen any panics yet. I = have not checked logs yet if my trap actually has catch anything or not. >> Do we know if this fix has been merged to stable/9 and releng/9.0? = Given multiple reports of instability without it, I think we would be = well-served to merge it at this point. >=20 > Hey Robert, sorry to bother you again, but can you at least point me = towards specific SVN revisions that I need to get merged? I tried to = google it and also browsed my svn history for the last 4 months using = keyword "sockets", but nothing came up. This fix is critical for any = system that does lot of fault-ctitical networking, and FreeBSD has = always been solid in this regard. It saved us at least 10-15 crashes = across 5 machines in the last month. Hi Maxim: Looking back at a recent post from you, it appears that you are on 8.x = and not 9.x, as I had assumed form your original e-mail. The patch I was = referring to in 9-CURRENT has long since been merged for 9.0 and will = appear in that release. However, it does not apply to 8.x, as the bug it = fixed was introduced during the 9.x cycle. We'll need to do a = from-scratch diagnosis here rather than assume it's the same problem. = Could I ask you to follow up to this post with version information, = stack traces from relevant threads, etc? I am not aware of any other = reports of UDP-related crashes along the lines of what you've described = in 8.x, so it may be being triggered by some unusual aspect of your = workload (or just bad luck). Sorry that there's no instant "merge a = patch" fix for this one. Thanks, Robert= From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 00:35:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4188106566B for ; Sat, 31 Dec 2011 00:35:16 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECDB8FC1D for ; Sat, 31 Dec 2011 00:35:16 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rgmul-0000jG-Km for freebsd-net@freebsd.org; Sat, 31 Dec 2011 01:35:11 +0100 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 31 Dec 2011 01:35:11 +0100 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 31 Dec 2011 01:35:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Marcin Cieslak Date: Sat, 31 Dec 2011 00:35:00 +0000 (UTC) Organization: http://saper.info Lines: 17 Message-ID: References: <20111230145854.GA22414@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: IPv6 not responding on some aliases (recent 8-stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 00:35:16 -0000 > I have seen this behavior before when one of the addresses on an interface = > is in a DMZ while the others are not. But this was with IPv4. I would assum= > e IPv6 would have acted the same way but left it untested as it was not cri= > tical. Take this as informational only and double check your switches, fire= > walls, etc... Unfortunately, this is a hosting provider. I have rebooted the box to use their custom rescue netboot image (based on FreeBSD 8.0 running on QEMU) and ... still one of the addresses didn't work in this setup. However, two reboots later situation returned to normal, and all IPv6 addresses respond. NDP table theory sounds plausible to me, except... connection establishment to the IPv6 address port 22/tcp takes sometimes noticeably too long (other TCP ports are usually fine). But this is probably another story... //Marcin From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 00:46:48 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 786231065670; Sat, 31 Dec 2011 00:46:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 49D8E8FC18; Sat, 31 Dec 2011 00:46:48 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Rgn5z-000ECt-1f; Fri, 30 Dec 2011 16:46:47 -0800 Message-ID: <4EFE5B70.9050807@FreeBSD.org> Date: Fri, 30 Dec 2011 16:46:40 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> <4EFE158C.2040705@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 00:46:48 -0000 On 12/30/2011 3:31 PM, Robert N. M. Watson wrote: > Looking back at a recent post from you, it appears that you are on 8.x and not 9.x, as I had assumed form your original e-mail. The patch I was referring to in 9-CURRENT has long since been merged for 9.0 and will appear in that release. However, it does not apply to 8.x, as the bug it fixed was introduced during the 9.x cycle. We'll need to do a from-scratch diagnosis here rather than assume it's the same problem. Could I ask you to follow up to this post with version information, stack traces from relevant threads, etc? I am not aware of any other reports of UDP-related crashes along the lines of what you've described in 8.x, so it may be being triggered by some unusual aspect of your workload (or just bad luck). Sorry that there's no instant "merge a patch" fix for this one. I see. Would you guys mind if I put that NULL pointer check into the code for the time being and turn it into some kind of big nasty warning in 8-stable branch only? As far as I can tell, the most harm it can do is some memory being leaked. And this condition happens just few times a day, so it's not a biggie. By the way it would be interesting project to put libexecinfo interface into the FreeBSD kernel. It would provide interesting new aspect of debugging such rare non-critical conditions by dumping stack traces and possibly doing some damage control instead of plainly crashing. -Maxim From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 00:58:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75AA106564A; Sat, 31 Dec 2011 00:58:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id B8BCC8FC18; Sat, 31 Dec 2011 00:58:02 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RgnGr-000EEF-OS; Fri, 30 Dec 2011 16:58:01 -0800 Message-ID: <4EFE5E12.7080103@FreeBSD.org> Date: Fri, 30 Dec 2011 16:57:54 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Robert N. M. Watson" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> <4EFE158C.2040705@FreeBSD.org> <4EFE5B70.9050807@FreeBSD.org> In-Reply-To: <4EFE5B70.9050807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 00:58:03 -0000 On 12/30/2011 4:46 PM, Maxim Sobolev wrote: > I see. Would you guys mind if I put that NULL pointer check into the > code for the time being and turn it into some kind of big nasty warning > in 8-stable branch only? I could also open a ticket, put all debug information collected to date in there. And encourage people to report to it once they see this warning on their system. Then it would provide more information about the exposure. It is definitely looks like locking issue somewhere, not just bad luck or flaky hardware, as we see it happening consistently on top 4 most UDP-loaded systems here, and it correlates well with the load. With my small NULL catch the machines have been running happily for a month now, so there is no visible side-effects. -Maxim From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 05:49:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C3BF106564A for ; Sat, 31 Dec 2011 05:49:08 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id E0DE78FC08 for ; Sat, 31 Dec 2011 05:49:07 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so13568590wib.13 for ; Fri, 30 Dec 2011 21:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=f8zYPIf/Jxkm11KwiM1WAsA4qzjhMv/6o+ayWEs6z78=; b=aAcQFK4Ev8M5W4FlDKRCh7OAPjEvNblrhLUDa3W5DYKLuHhEJKkew9CkhtUtBrN/2o YGfVoAy113GxW4CTYBbuXN/lm9oR3DmePG+oLrzWxZUP/y7YMBljBRbt9IsS/l4b+qSK LK9q+Fkl6fv5evjAhemV+9VxND2Et+jf4je/0= Received: by 10.180.19.138 with SMTP id f10mr115225896wie.3.1325310546804; Fri, 30 Dec 2011 21:49:06 -0800 (PST) Received: from rimwks1w7x64 ([31.47.165.90]) by mx.google.com with ESMTPS id ei9sm98117630wid.0.2011.12.30.21.49.04 (version=SSLv3 cipher=OTHER); Fri, 30 Dec 2011 21:49:05 -0800 (PST) From: rozhuk.im@gmail.com To: References: <201110232234.p9NMYer5039763@freefall.freebsd.org> In-Reply-To: <201110232234.p9NMYer5039763@freefall.freebsd.org> Date: Sat, 31 Dec 2011 14:48:56 +0900 Message-ID: <4efea251.890bb50a.4fb2.4076@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01CCC7CB.546BA110" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcyR0/3akjaCaX1bRXmhqztKzYBhfw1qilHw Content-Language: ru Cc: Subject: RE: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 05:49:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01CCC7CB.546BA110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Who can commit? > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of eadler@FreeBSD.org > Sent: Monday, October 24, 2011 7:35 AM > To: eadler@FreeBSD.org; freebsd-bugs@FreeBSD.org; freebsd- > net@FreeBSD.org > Subject: Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ > support > > Old Synopsis: ng_vlan update for QinQ support New Synopsis: [netgraph] > [patch] ng_vlan update for QinQ support > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: eadler > Responsible-Changed-When: Sun Oct 23 22:34:17 UTC 2011 > Responsible-Changed-Why: > assign and add tags > > http://www.freebsd.org/cgi/query-pr.cgi?pr=161908 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ------=_NextPart_000_0011_01CCC7CB.546BA110 Content-Type: application/octet-stream; name="ng_vlan.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ng_vlan.patch" --- /usr/src/sys/netgraph/ng_vlan.c.orig 2009-08-03 17:13:06.000000000 = +0900=0A= +++ /usr/src/sys/netgraph/ng_vlan.c 2011-10-23 03:41:00.000000000 +0900=0A= @@ -1,5 +1,6 @@=0A= /*-=0A= * Copyright (c) 2003 IPNET Internet Communication Company=0A= + * Copyright (c) 2011 Rozhuk Ivan =0A= * All rights reserved.=0A= *=0A= * Redistribution and use in source and binary forms, with or without=0A= @@ -46,6 +47,22 @@=0A= #include =0A= #include =0A= =0A= +=0A= +=0A= +struct ng_vlan_private {=0A= + hook_p downstream_hook;=0A= + hook_p nomatch_hook;=0A= + int encap_enable;=0A= + u_int16_t encap_proto;=0A= + hook_p vlan_hook[(EVL_VLID_MASK + 1)];=0A= +};=0A= +typedef struct ng_vlan_private *priv_p;=0A= +=0A= +#define VLAN_TAG_MASK 0xFFFF=0A= +#define HOOK_VLAN_TAG_SET_MASK ((uintptr_t)((~0) & ~(VLAN_TAG_MASK)))=0A= +#define IS_HOOK_VLAN_SET(hook_data) ((((uintptr_t)hook_data) & = HOOK_VLAN_TAG_SET_MASK) =3D=3D HOOK_VLAN_TAG_SET_MASK)=0A= +=0A= +=0A= static ng_constructor_t ng_vlan_constructor;=0A= static ng_rcvmsg_t ng_vlan_rcvmsg;=0A= static ng_shutdown_t ng_vlan_shutdown;=0A= @@ -105,11 +122,46 @@=0A= },=0A= {=0A= NGM_VLAN_COOKIE,=0A= + NGM_VLAN_DEL_VID_FLT,=0A= + "delvidflt",=0A= + &ng_parse_uint16_type,=0A= + NULL=0A= + },=0A= + {=0A= + NGM_VLAN_COOKIE,=0A= NGM_VLAN_GET_TABLE,=0A= "gettable",=0A= NULL,=0A= &ng_vlan_table_type=0A= },=0A= + {=0A= + NGM_VLAN_COOKIE,=0A= + NGM_VLAN_GET_ENCAP,=0A= + "getencap",=0A= + NULL,=0A= + &ng_parse_uint32_type=0A= + },=0A= + {=0A= + NGM_VLAN_COOKIE,=0A= + NGM_VLAN_SET_ENCAP,=0A= + "setencap",=0A= + &ng_parse_uint32_type,=0A= + NULL=0A= + },=0A= + {=0A= + NGM_VLAN_COOKIE,=0A= + NGM_VLAN_GET_ENCAP_PROTO,=0A= + "getencapproto",=0A= + NULL,=0A= + &ng_parse_uint16_type=0A= + },=0A= + {=0A= + NGM_VLAN_COOKIE,=0A= + NGM_VLAN_SET_ENCAP_PROTO,=0A= + "setencapproto",=0A= + &ng_parse_uint16_type,=0A= + NULL=0A= + },=0A= { 0 }=0A= };=0A= =0A= @@ -126,47 +178,43 @@=0A= };=0A= NETGRAPH_INIT(vlan, &ng_vlan_typestruct);=0A= =0A= -struct filter {=0A= - LIST_ENTRY(filter) next;=0A= - u_int16_t vlan;=0A= - hook_p hook;=0A= -};=0A= =0A= -#define HASHSIZE 16=0A= -#define HASH(id) ((((id) >> 8) ^ ((id) >> 4) ^ (id)) & 0x0f)=0A= -LIST_HEAD(filterhead, filter);=0A= =0A= -typedef struct {=0A= - hook_p downstream_hook;=0A= - hook_p nomatch_hook;=0A= - struct filterhead hashtable[HASHSIZE];=0A= - u_int32_t nent;=0A= -} *priv_p;=0A= +//**********************************************************************= **=0A= +// HELPER STUFF=0A= +//**********************************************************************= **=0A= =0A= -static struct filter *=0A= -ng_vlan_findentry(priv_p priv, u_int16_t vlan)=0A= +static __inline int=0A= +m_chk(struct mbuf **mp, int len)=0A= {=0A= - struct filterhead *chain =3D &priv->hashtable[HASH(vlan)];=0A= - struct filter *f;=0A= + if ((*mp)->m_pkthdr.len < len) {=0A= + m_freem((*mp));=0A= + (*mp) =3D NULL;=0A= + return (EINVAL);=0A= + }=0A= + if ((*mp)->m_len < len && ((*mp) =3D m_pullup((*mp), len)) =3D=3D NULL)=0A= + return (ENOBUFS);=0A= =0A= - LIST_FOREACH(f, chain, next)=0A= - if (f->vlan =3D=3D vlan)=0A= - return (f);=0A= - return (NULL);=0A= +return (0);=0A= }=0A= =0A= +//**********************************************************************= **=0A= +// NETGRAPH NODE STUFF=0A= +//**********************************************************************= **=0A= +=0A= static int=0A= ng_vlan_constructor(node_p node)=0A= {=0A= priv_p priv;=0A= - int i;=0A= =0A= priv =3D malloc(sizeof(*priv), M_NETGRAPH, M_NOWAIT | M_ZERO);=0A= if (priv =3D=3D NULL)=0A= return (ENOMEM);=0A= - for (i =3D 0; i < HASHSIZE; i++)=0A= - LIST_INIT(&priv->hashtable[i]);=0A= + priv->encap_enable =3D 1;=0A= + priv->encap_proto =3D htons(ETHERTYPE_VLAN);=0A= + =0A= NG_NODE_SET_PRIVATE(node, priv);=0A= +=0A= return (0);=0A= }=0A= =0A= @@ -193,13 +241,14 @@=0A= ng_vlan_rcvmsg(node_p node, item_p item, hook_p lasthook)=0A= {=0A= const priv_p priv =3D NG_NODE_PRIVATE(node);=0A= - int error =3D 0;=0A= struct ng_mesg *msg, *resp =3D NULL;=0A= struct ng_vlan_filter *vf;=0A= - struct filter *f;=0A= hook_p hook;=0A= struct ng_vlan_table *t;=0A= - int i;=0A= + uintptr_t hook_data;=0A= + int i, vlan_count;=0A= + u_int16_t vid;=0A= + int error =3D 0;=0A= =0A= NGI_GET_MSG(item, msg);=0A= /* Deal with message according to cookie and command. */=0A= @@ -214,12 +263,12 @@=0A= }=0A= vf =3D (struct ng_vlan_filter *)msg->data;=0A= /* Sanity check the VLAN ID value. */=0A= - if (vf->vlan & ~EVL_VLID_MASK) {=0A= + if (vf->vid & ~EVL_VLID_MASK || vf->pcp & ~7 || vf->cfi & ~1) {=0A= error =3D EINVAL;=0A= break;=0A= }=0A= /* Check that a referenced hook exists. */=0A= - hook =3D ng_findhook(node, vf->hook);=0A= + hook =3D ng_findhook(node, vf->hook_name);=0A= if (hook =3D=3D NULL) {=0A= error =3D ENOENT;=0A= break;=0A= @@ -231,30 +280,18 @@=0A= break;=0A= }=0A= /* And is not already in service. */=0A= - if (NG_HOOK_PRIVATE(hook) !=3D NULL) {=0A= + if (IS_HOOK_VLAN_SET(NG_HOOK_PRIVATE(hook))) {=0A= error =3D EEXIST;=0A= break;=0A= }=0A= /* Check we don't already trap this VLAN. */=0A= - if (ng_vlan_findentry(priv, vf->vlan)) {=0A= + if (priv->vlan_hook[vf->vid] !=3D NULL) {=0A= error =3D EEXIST;=0A= break;=0A= }=0A= - /* Create filter. */=0A= - f =3D malloc(sizeof(*f),=0A= - M_NETGRAPH, M_NOWAIT | M_ZERO);=0A= - if (f =3D=3D NULL) {=0A= - error =3D ENOMEM;=0A= - break;=0A= - }=0A= - /* Link filter and hook together. */=0A= - f->hook =3D hook;=0A= - f->vlan =3D vf->vlan;=0A= - NG_HOOK_SET_PRIVATE(hook, f);=0A= - /* Register filter in a hash table. */=0A= - LIST_INSERT_HEAD(=0A= - &priv->hashtable[HASH(f->vlan)], f, next);=0A= - priv->nent++;=0A= + /* Link vlan and hook together. */=0A= + NG_HOOK_SET_PRIVATE(hook, (void *)(HOOK_VLAN_TAG_SET_MASK | = EVL_MAKETAG(vf->vid, vf->pcp, vf->cfi)));=0A= + priv->vlan_hook[vf->vid] =3D hook;=0A= break;=0A= case NGM_VLAN_DEL_FILTER:=0A= /* Check that message is long enough. */=0A= @@ -264,35 +301,125 @@=0A= }=0A= /* Check that hook exists and is active. */=0A= hook =3D ng_findhook(node, (char *)msg->data);=0A= - if (hook =3D=3D NULL ||=0A= - (f =3D NG_HOOK_PRIVATE(hook)) =3D=3D NULL) {=0A= + if (hook =3D=3D NULL) {=0A= + error =3D ENOENT;=0A= + break;=0A= + }=0A= + hook_data =3D (uintptr_t)NG_HOOK_PRIVATE(hook);=0A= + if (IS_HOOK_VLAN_SET(hook_data) =3D=3D 0) {=0A= + error =3D ENOENT;=0A= + break;=0A= + }=0A= +#ifdef NETGRAPH_DEBUG=0A= + if (priv->vlan_hook[EVL_VLANOFTAG(hook_data)] !=3D hook)=0A= + printf("%s: NGM_VLAN_DEL_FILTER: Invalid VID for Hook =3D %s\n", = __func__, (char *)msg->data);=0A= +#endif=0A= + /* Purge a rule that refers to this hook. */=0A= + priv->vlan_hook[EVL_VLANOFTAG(hook_data)] =3D NULL;=0A= + NG_HOOK_SET_PRIVATE(hook, NULL);=0A= + break;=0A= + case NGM_VLAN_DEL_VID_FLT:=0A= + /* Check that message is long enough. */=0A= + if (msg->header.arglen !=3D sizeof(u_int16_t)) {=0A= + error =3D EINVAL;=0A= + break;=0A= + }=0A= + vid =3D (*((u_int16_t *)msg->data));=0A= + /* Sanity check the VLAN ID value. */=0A= + if (vid & ~EVL_VLID_MASK) {=0A= + error =3D EINVAL;=0A= + break;=0A= + }=0A= + /* Check that hook exists and is active. */=0A= + hook =3D priv->vlan_hook[vid];=0A= + if (hook =3D=3D NULL) {=0A= + error =3D ENOENT;=0A= + break;=0A= + }=0A= + hook_data =3D (uintptr_t)NG_HOOK_PRIVATE(hook);=0A= + if (IS_HOOK_VLAN_SET(hook_data) =3D=3D 0) {=0A= error =3D ENOENT;=0A= break;=0A= }=0A= +#ifdef NETGRAPH_DEBUG=0A= + if (EVL_VLANOFTAG(hook_data) !=3D vid)=0A= + printf("%s: NGM_VLAN_DEL_VID_FLT: Invalid VID Hook =3D %us, must = be: %us\n", __func__, (u_int16_t)EVL_VLANOFTAG(hook_data), vid);=0A= +#endif=0A= /* Purge a rule that refers to this hook. */=0A= + priv->vlan_hook[vid] =3D NULL;=0A= NG_HOOK_SET_PRIVATE(hook, NULL);=0A= - LIST_REMOVE(f, next);=0A= - priv->nent--;=0A= - free(f, M_NETGRAPH);=0A= break;=0A= case NGM_VLAN_GET_TABLE:=0A= + /* calculate vlans */=0A= + vlan_count =3D 0;=0A= + for (i =3D 0; i < (EVL_VLID_MASK + 1); i ++) {=0A= + if (priv->vlan_hook[i] !=3D NULL=0A= + && NG_HOOK_IS_VALID(priv->vlan_hook[i]))=0A= + vlan_count ++;=0A= + }=0A= +=0A= + /* allocate memory for responce */=0A= NG_MKRESPONSE(resp, msg, sizeof(*t) +=0A= - priv->nent * sizeof(*t->filter), M_NOWAIT);=0A= + vlan_count * sizeof(*t->filter), M_NOWAIT);=0A= if (resp =3D=3D NULL) {=0A= error =3D ENOMEM;=0A= break;=0A= }=0A= +=0A= + /* pack data to responce */=0A= t =3D (struct ng_vlan_table *)resp->data;=0A= - t->n =3D priv->nent;=0A= + t->n =3D 0;=0A= vf =3D &t->filter[0];=0A= - for (i =3D 0; i < HASHSIZE; i++) {=0A= - LIST_FOREACH(f, &priv->hashtable[i], next) {=0A= - vf->vlan =3D f->vlan;=0A= - strncpy(vf->hook, NG_HOOK_NAME(f->hook),=0A= + for (i =3D 0; i < (EVL_VLID_MASK + 1); i ++) {=0A= + hook =3D priv->vlan_hook[i];=0A= + if (hook =3D=3D NULL=0A= + || NG_HOOK_NOT_VALID(hook))=0A= + continue;=0A= + hook_data =3D (uintptr_t)NG_HOOK_PRIVATE(hook);=0A= + if (IS_HOOK_VLAN_SET(hook_data) =3D=3D 0)=0A= + continue;=0A= +#ifdef NETGRAPH_DEBUG=0A= + if (EVL_VLANOFTAG(hook_data) !=3D i)=0A= + printf("%s: NGM_VLAN_GET_TABLE: hook %s VID =3D %us, must be: = %i\n", __func__, NG_HOOK_NAME(hook), = (u_int16_t)EVL_VLANOFTAG(hook_data), i);=0A= +#endif=0A= + vf->vid =3D i;=0A= + vf->pcp =3D EVL_PRIOFTAG(hook_data);=0A= + vf->cfi =3D EVL_CFIOFTAG(hook_data);=0A= + strncpy(vf->hook_name, NG_HOOK_NAME(hook),=0A= NG_HOOKSIZ);=0A= - vf++;=0A= - }=0A= + vf ++;=0A= + t->n ++;=0A= + }=0A= + break;=0A= + case NGM_VLAN_GET_ENCAP:=0A= + NG_MKRESPONSE(resp, msg, sizeof(u_int32_t), M_NOWAIT);=0A= + if (resp =3D=3D NULL) {=0A= + error =3D ENOMEM;=0A= + break;=0A= + }=0A= + (*((u_int32_t *)resp->data)) =3D priv->encap_enable;=0A= + break;=0A= + case NGM_VLAN_SET_ENCAP:=0A= + if (msg->header.arglen !=3D sizeof(u_int32_t)) {=0A= + error =3D EINVAL;=0A= + break;=0A= + }=0A= + priv->encap_enable =3D ((*((u_int32_t *)msg->data)) !=3D 0);=0A= + break;=0A= + case NGM_VLAN_GET_ENCAP_PROTO:=0A= + NG_MKRESPONSE(resp, msg, sizeof(u_int16_t), M_NOWAIT);=0A= + if (resp =3D=3D NULL) {=0A= + error =3D ENOMEM;=0A= + break;=0A= + }=0A= + (*((u_int16_t *)resp->data)) =3D ntohs(priv->encap_proto);=0A= + break;=0A= + case NGM_VLAN_SET_ENCAP_PROTO:=0A= + if (msg->header.arglen !=3D sizeof(u_int16_t)) {=0A= + error =3D EINVAL;=0A= + break;=0A= }=0A= + priv->encap_proto =3D htons((*((u_int16_t *)msg->data)));=0A= break;=0A= default: /* Unknown command. */=0A= error =3D EINVAL;=0A= @@ -302,8 +429,6 @@=0A= case NGM_FLOW_COOKIE:=0A= {=0A= struct ng_mesg *copy;=0A= - struct filterhead *chain;=0A= - struct filter *f;=0A= =0A= /*=0A= * Flow control messages should come only=0A= @@ -314,17 +439,16 @@=0A= break;=0A= if (lasthook !=3D priv->downstream_hook)=0A= break;=0A= -=0A= /* Broadcast the event to all uplinks. */=0A= - for (i =3D 0, chain =3D priv->hashtable; i < HASHSIZE;=0A= - i++, chain++)=0A= - LIST_FOREACH(f, chain, next) {=0A= + for (i =3D 0; i < (EVL_VLID_MASK + 1); i ++) {=0A= + if (priv->vlan_hook[i] =3D=3D NULL)=0A= + continue;=0A= +=0A= NG_COPYMESSAGE(copy, msg, M_NOWAIT);=0A= if (copy =3D=3D NULL)=0A= - continue;=0A= - NG_SEND_MSG_HOOK(error, node, copy, f->hook, 0);=0A= + continue;=0A= + NG_SEND_MSG_HOOK(error, node, copy, priv->vlan_hook[i], 0);=0A= }=0A= -=0A= break;=0A= }=0A= default: /* Unknown type cookie. */=0A= @@ -343,16 +467,19 @@=0A= struct ether_header *eh;=0A= struct ether_vlan_header *evl =3D NULL;=0A= int error;=0A= - u_int16_t vlan;=0A= + uintptr_t hook_data;=0A= + u_int16_t vid;=0A= struct mbuf *m;=0A= - struct filter *f;=0A= + hook_p dst_hook;=0A= +=0A= =0A= - /* Make sure we have an entire header. */=0A= NGI_GET_M(item, m);=0A= - if (m->m_len < sizeof(*eh) &&=0A= - (m =3D m_pullup(m, sizeof(*eh))) =3D=3D NULL) {=0A= +=0A= + /* Make sure we have an entire header. */=0A= + error =3D m_chk(&m, ETHER_HDR_LEN);=0A= + if (error !=3D 0) {=0A= NG_FREE_ITEM(item);=0A= - return (EINVAL);=0A= + return (error);=0A= }=0A= eh =3D mtod(m, struct ether_header *);=0A= if (hook =3D=3D priv->downstream_hook) {=0A= @@ -360,75 +487,104 @@=0A= * If from downstream, select between a match hook=0A= * or the nomatch hook.=0A= */=0A= + dst_hook =3D priv->nomatch_hook;=0A= if (m->m_flags & M_VLANTAG ||=0A= - eh->ether_type =3D=3D htons(ETHERTYPE_VLAN)) {=0A= + eh->ether_type =3D=3D priv->encap_proto) {=0A= if (m->m_flags & M_VLANTAG) {=0A= /*=0A= * Packet is tagged, m contains a normal=0A= * Ethernet frame; tag is stored out-of-band.=0A= */=0A= - vlan =3D EVL_VLANOFTAG(m->m_pkthdr.ether_vtag);=0A= - } else {=0A= - if (m->m_len < sizeof(*evl) &&=0A= - (m =3D m_pullup(m, sizeof(*evl))) =3D=3D NULL) {=0A= + vid =3D EVL_VLANOFTAG(m->m_pkthdr.ether_vtag);=0A= + } else { /* eh->ether_type =3D=3D priv->encap_proto */=0A= + error =3D m_chk(&m, (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN));=0A= + if (error !=3D 0) {=0A= NG_FREE_ITEM(item);=0A= - return (EINVAL);=0A= + return (error);=0A= }=0A= evl =3D mtod(m, struct ether_vlan_header *);=0A= - vlan =3D EVL_VLANOFTAG(ntohs(evl->evl_tag));=0A= + vid =3D EVL_VLANOFTAG(ntohs(evl->evl_tag));=0A= }=0A= - if ((f =3D ng_vlan_findentry(priv, vlan)) !=3D NULL) {=0A= +=0A= + if (priv->vlan_hook[vid] !=3D NULL) {=0A= + dst_hook =3D priv->vlan_hook[vid];=0A= if (m->m_flags & M_VLANTAG) {=0A= m->m_pkthdr.ether_vtag =3D 0;=0A= m->m_flags &=3D ~M_VLANTAG;=0A= } else {=0A= - evl->evl_encap_proto =3D evl->evl_proto;=0A= - bcopy(mtod(m, caddr_t),=0A= - mtod(m, caddr_t) +=0A= - ETHER_VLAN_ENCAP_LEN,=0A= - ETHER_HDR_LEN);=0A= + /* =0A= + * move DstMAC and SrcMAC to ETHER_TYPE=0A= + * before: [dst_mac] [src_mac] [ether_type_encap(TPID)] = [PCP/CFI/VID] [ether_type] [payload]=0A= + * |-----------------| = >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |---------------------|=0A= + * after: [free space] [dst_mac] [src_mac] [ether_type] [payload]=0A= + * |-----------------| |---------------------|=0A= + */=0A= + bcopy((char *)evl, ((char *)evl + ETHER_VLAN_ENCAP_LEN),=0A= + (ETHER_ADDR_LEN * 2));=0A= m_adj(m, ETHER_VLAN_ENCAP_LEN);=0A= }=0A= }=0A= - } else=0A= - f =3D NULL;=0A= - if (f !=3D NULL)=0A= - NG_FWD_NEW_DATA(error, item, f->hook, m);=0A= - else=0A= - NG_FWD_NEW_DATA(error, item, priv->nomatch_hook, m);=0A= + }=0A= } else {=0A= /*=0A= * It is heading towards the downstream.=0A= * If from nomatch, pass it unmodified.=0A= * Otherwise, do the VLAN encapsulation.=0A= */=0A= - if (hook !=3D priv->nomatch_hook) {=0A= - if ((f =3D NG_HOOK_PRIVATE(hook)) =3D=3D NULL) {=0A= + dst_hook =3D priv->downstream_hook;=0A= + if (dst_hook !=3D NULL && hook !=3D priv->nomatch_hook) {=0A= + hook_data =3D (uintptr_t)NG_HOOK_PRIVATE(hook);=0A= + if (IS_HOOK_VLAN_SET(hook_data) =3D=3D 0) {=0A= + m_freem(m);=0A= NG_FREE_ITEM(item);=0A= - NG_FREE_M(m);=0A= return (EOPNOTSUPP);=0A= }=0A= - M_PREPEND(m, ETHER_VLAN_ENCAP_LEN, M_DONTWAIT);=0A= - /* M_PREPEND takes care of m_len and m_pkthdr.len. */=0A= - if (m =3D=3D NULL || (m->m_len < sizeof(*evl) &&=0A= - (m =3D m_pullup(m, sizeof(*evl))) =3D=3D NULL)) {=0A= - NG_FREE_ITEM(item);=0A= - return (ENOMEM);=0A= + if (priv->encap_enable =3D=3D 0) {=0A= + /* just set packet header tag */=0A= + m->m_flags |=3D M_VLANTAG;=0A= + m->m_pkthdr.ether_vtag =3D (hook_data & VLAN_TAG_MASK);=0A= + } else {=0A= + /*=0A= + * Transform the Ethernet header into an Ethernet header=0A= + * with 802.1Q encapsulation.=0A= + * mod of: ether_vlanencap =0A= + */=0A= + M_PREPEND(m, ETHER_VLAN_ENCAP_LEN, M_DONTWAIT);=0A= + /* M_PREPEND takes care of m_len and m_pkthdr.len. */=0A= + if (m =3D=3D NULL)=0A= + error =3D ENOMEM;=0A= + else=0A= + error =3D m_chk(&m, (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN));=0A= + if (error !=3D 0) {=0A= + NG_FREE_ITEM(item);=0A= + return (error);=0A= + }=0A= + /* move DstMAC and SrcMAC from ETHER_TYPE=0A= + * before: [free - prepended space] [dst_mac] [src_mac] = [ether_type] [payload]=0A= + * <<<<<<<<<<<<<<<<<<<<<< |-----------------| = |--------------------|=0A= + * after: [dst_mac] [src_mac] [ether_type_encap(TPID)] = [PCP/CFI/VID] [ether_type] [payload]=0A= + * |-----------------| |----------- inserted tag = -----------| |--------------------| =0A= + */=0A= + evl =3D mtod(m, struct ether_vlan_header *);=0A= + bcopy(((char *)evl + ETHER_VLAN_ENCAP_LEN),=0A= + (char *)evl, (ETHER_ADDR_LEN * 2));=0A= + evl->evl_encap_proto =3D priv->encap_proto;=0A= + evl->evl_tag =3D htons((hook_data & VLAN_TAG_MASK));=0A= }=0A= - /*=0A= - * Transform the Ethernet header into an Ethernet header=0A= - * with 802.1Q encapsulation.=0A= - */=0A= - bcopy(mtod(m, char *) + ETHER_VLAN_ENCAP_LEN,=0A= - mtod(m, char *), ETHER_HDR_LEN);=0A= - evl =3D mtod(m, struct ether_vlan_header *);=0A= - evl->evl_proto =3D evl->evl_encap_proto;=0A= - evl->evl_encap_proto =3D htons(ETHERTYPE_VLAN);=0A= - evl->evl_tag =3D htons(f->vlan);=0A= }=0A= - NG_FWD_NEW_DATA(error, item, priv->downstream_hook, m);=0A= }=0A= - return (error);=0A= +=0A= + /* send packet */=0A= + if (dst_hook !=3D NULL) {=0A= + NG_FWD_NEW_DATA(error, item, dst_hook, m);=0A= + return (error);=0A= + }=0A= +=0A= + /* no hook to send */=0A= + m_freem(m);=0A= + NG_FREE_ITEM(item);=0A= +=0A= + return (ENETDOWN);=0A= }=0A= =0A= static int=0A= @@ -446,7 +602,7 @@=0A= ng_vlan_disconnect(hook_p hook)=0A= {=0A= const priv_p priv =3D NG_NODE_PRIVATE(NG_HOOK_NODE(hook));=0A= - struct filter *f;=0A= + uintptr_t hook_data;=0A= =0A= if (hook =3D=3D priv->downstream_hook)=0A= priv->downstream_hook =3D NULL;=0A= @@ -454,11 +610,9 @@=0A= priv->nomatch_hook =3D NULL;=0A= else {=0A= /* Purge a rule that refers to this hook. */=0A= - if ((f =3D NG_HOOK_PRIVATE(hook)) !=3D NULL) {=0A= - LIST_REMOVE(f, next);=0A= - priv->nent--;=0A= - free(f, M_NETGRAPH);=0A= - }=0A= + hook_data =3D (uintptr_t)NG_HOOK_PRIVATE(hook);=0A= + if (IS_HOOK_VLAN_SET(hook_data))=0A= + priv->vlan_hook[EVL_VLANOFTAG(hook_data)] =3D NULL;=0A= }=0A= NG_HOOK_SET_PRIVATE(hook, NULL);=0A= if ((NG_NODE_NUMHOOKS(NG_HOOK_NODE(hook)) =3D=3D 0) &&=0A= =0A= =0A= --- /usr/src/sys/netgraph/ng_vlan.h.orig 2009-08-03 17:13:06.000000000 = +0900=0A= +++ /usr/src/sys/netgraph/ng_vlan.h 2011-10-22 19:11:01.000000000 +0900=0A= @@ -1,5 +1,6 @@=0A= /*-=0A= * Copyright (c) 2003 IPNET Internet Communication Company=0A= + * Copyright (c) 2011 Rozhuk Ivan =0A= * All rights reserved.=0A= *=0A= * Redistribution and use in source and binary forms, with or without=0A= @@ -43,19 +44,28 @@=0A= enum {=0A= NGM_VLAN_ADD_FILTER =3D 1,=0A= NGM_VLAN_DEL_FILTER,=0A= - NGM_VLAN_GET_TABLE=0A= + NGM_VLAN_DEL_VID_FLT,=0A= + NGM_VLAN_GET_TABLE,=0A= + NGM_VLAN_GET_ENCAP,=0A= + NGM_VLAN_SET_ENCAP,=0A= + NGM_VLAN_GET_ENCAP_PROTO,=0A= + NGM_VLAN_SET_ENCAP_PROTO,=0A= };=0A= =0A= /* For NGM_VLAN_ADD_FILTER control message. */=0A= struct ng_vlan_filter {=0A= - char hook[NG_HOOKSIZ];=0A= - u_int16_t vlan;=0A= -}; =0A= + char hook_name[NG_HOOKSIZ];=0A= + u_int16_t vid; /* VID - VLAN Identifier */=0A= + u_int8_t pcp; /* PCP - Priority Code Point */=0A= + u_int8_t cfi; /* CFI - Canonical Format Indicator */=0A= +};=0A= =0A= /* Keep this in sync with the above structure definition. */=0A= #define NG_VLAN_FILTER_FIELDS { \=0A= - { "hook", &ng_parse_hookbuf_type }, \=0A= - { "vlan", &ng_parse_uint16_type }, \=0A= + { "hook", &ng_parse_hookbuf_type }, \=0A= + { "vid", &ng_parse_uint16_type }, \=0A= + { "pcp", &ng_parse_uint8_type }, \=0A= + { "cfi", &ng_parse_uint8_type }, \=0A= { NULL } \=0A= }=0A= =0A= ------=_NextPart_000_0011_01CCC7CB.546BA110-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 06:33:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCA73106564A for ; Sat, 31 Dec 2011 06:33:29 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 880868FC08 for ; Sat, 31 Dec 2011 06:33:29 +0000 (UTC) Received: by iadj38 with SMTP id j38so33388169iad.13 for ; Fri, 30 Dec 2011 22:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=7yK2SYA8+m4jvL6Q59/73MnTjintwMdHVMj251tNrT0=; b=lYSua60A8+/ROQ7RnDUqg5fdT9rSP7LYGfZZJRpN8G0ea7TJk65SEmxvntUxo09B6r qlHPG/FZ9+BfpDqI1l+S+FAanfiyx9dp174rQub+UggdxSNnJE1YRSM4TrzIlBu9Z4dC FluZxIjGpbeOg9I06+AoqTazYyMRhwG/CmJ6c= Received: by 10.50.183.199 with SMTP id eo7mr49420204igc.5.1325313208813; Fri, 30 Dec 2011 22:33:28 -0800 (PST) Received: from DataIX.net (24-247-9-230.dhcp.aldl.mi.charter.com. [24.247.9.230]) by mx.google.com with ESMTPS id yg2sm90271641igb.1.2011.12.30.22.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Dec 2011 22:33:27 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pBV6XMcr095825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Dec 2011 01:33:23 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pBV6XHYf095824; Sat, 31 Dec 2011 01:33:17 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sat, 31 Dec 2011 01:33:17 -0500 From: Jason Hellenthal To: Marcin Cieslak Message-ID: <20111231063317.GA90338@DataIX.net> References: <20111230145854.GA22414@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: Cc: freebsd-net@freebsd.org Subject: Re: IPv6 not responding on some aliases (recent 8-stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 06:33:30 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 31, 2011 at 12:35:00AM +0000, Marcin Cieslak wrote: > > I have seen this behavior before when one of the addresses on an interf= ace =3D > > is in a DMZ while the others are not. But this was with IPv4. I would a= ssum=3D > > e IPv6 would have acted the same way but left it untested as it was not= cri=3D > > tical. Take this as informational only and double check your switches, = fire=3D > > walls, etc... >=20 > Unfortunately, this is a hosting provider. I have rebooted the box > to use their custom rescue netboot image (based on FreeBSD 8.0 running > on QEMU) and ... still one of the addresses didn't work in this setup. > However, two reboots later situation returned to normal, and all > IPv6 addresses respond. NDP table theory sounds plausible to me, > except... connection establishment to the IPv6 address port 22/tcp > takes sometimes noticeably too long (other TCP ports are usually fine). >=20 > But this is probably another story... >=20 Speaking just in the terms of too long of a connection wait on port 22. Fir= ewall off port 113 in and out. block drop in log quick proto tcp to any port =3D auth block out quick proto tcp to any port =3D auth That should help in terms of the speed at which you connect. Good luck with= the OP though. Happy Holiday... --=20 ;s =3D; --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO/qysAAoJEJBXh4mJ2FR+sjUIAIdg9LrPIMC7UcF6xeWu4nwW 4DLOk7o0/Hh7WtGC9ay/6c2CqGHygLFwnvC21FiLGbNJBAenFwZXjWTFOAau35FZ JH5hFh94PSqhhnRXQ7kEVes0AzH1uY9kE5tQp6GR0oj+MEjPygVxtbyQjtYE4ZYF psqdM/Yze91+sc+L/gJP1FDMjYv4OWHKT38rRIFg4abrH/6DcuM8iSl5x2NdtK3s XhkBAuKtU9yUTO06h7JBFxeDz3GUlXQNeBeM/uclCwJVDYWT5goO8+NzQirzPAbh f0xiBvkVfG+VVNhy0y54/8g/Wi+qPLxCLOGJMJe/KqTINZU0CrYQ7F7/Cuku12A= =TJby -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 07:12:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D450A106564A for ; Sat, 31 Dec 2011 07:12:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9F78FC08 for ; Sat, 31 Dec 2011 07:12:08 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so19752443vcb.13 for ; Fri, 30 Dec 2011 23:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Y9+3U5zRKvVYw8X6MvH/x+UM3v5yfJEBRFDpDLbhDCI=; b=Q99H8DZ4ZV2K9r+XMeQIhBuYQLyHig+/N8NSWh69CKRcgBwA/4uaKW8k8oITAj5++E PqiMMH/D4AHBtTPHiFtWfPAnl45kXSyOPxzQGEzqd90AvEK7fA3x5JiHhyL/fQj/wpbi NNQs0Gs9XmkTlVEPFr5M5qj2kAypPMbOE7V5Q= MIME-Version: 1.0 Received: by 10.220.213.200 with SMTP id gx8mr24321884vcb.13.1325315527753; Fri, 30 Dec 2011 23:12:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 30 Dec 2011 23:12:07 -0800 (PST) In-Reply-To: <4efea251.890bb50a.4fb2.4076@mx.google.com> References: <201110232234.p9NMYer5039763@freefall.freebsd.org> <4efea251.890bb50a.4fb2.4076@mx.google.com> Date: Fri, 30 Dec 2011 23:12:07 -0800 X-Google-Sender-Auth: 7Mfr3rmhsnMVJE2K8xpEMW1Oc30 Message-ID: From: Adrian Chadd To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 07:12:08 -0000 On 30 December 2011 21:48, wrote: > > Who can commit? > Bug me after January 3rd. :) Adrian From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 08:12:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42DEF106564A for ; Sat, 31 Dec 2011 08:12:50 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF6988FC12 for ; Sat, 31 Dec 2011 08:12:49 +0000 (UTC) Received: by eekc50 with SMTP id c50so17068043eek.13 for ; Sat, 31 Dec 2011 00:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=+OAFfETvyDWG3goIaVwyYyFanOGkbxlTMD862U/R+jM=; b=Kem5KOcd/0mZliiF6s5kyxJCw0TCBd7WFGfGsK5qfv6v78IcUGP9tUrRIGaOM26wop vnPgEznq/4MgIDuaCOF8VR48jFYrj2olsGOVsxUgdH6Fw1OX3DsycRGdowJ8art9eymh 30t/iP1+038Ff0Ida83e0lxrqZk5dZeMXu8uA= MIME-Version: 1.0 Received: by 10.14.123.16 with SMTP id u16mr16713816eeh.30.1325319168587; Sat, 31 Dec 2011 00:12:48 -0800 (PST) Received: by 10.14.96.5 with HTTP; Sat, 31 Dec 2011 00:12:48 -0800 (PST) Date: Sat, 31 Dec 2011 13:42:48 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Modifying "arp" command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 08:12:50 -0000 Hello list, I want to modify the "arp" command in FreeBSD. Precisely I don't want it to display the time to expire for every entry. Which file should I edit? Will it be effective after kernel compilation and re-build? -- Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 08:18:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75ED106566B for ; Sat, 31 Dec 2011 08:18:00 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60F8F8FC0A for ; Sat, 31 Dec 2011 08:18:00 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so20210408wgb.1 for ; Sat, 31 Dec 2011 00:17:59 -0800 (PST) Received: by 10.227.197.77 with SMTP id ej13mr8003998wbb.25.1325319479235; Sat, 31 Dec 2011 00:17:59 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Sat, 31 Dec 2011 00:17:38 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Sat, 31 Dec 2011 00:17:38 -0800 X-Google-Sender-Auth: nSDODfRroLx9uZgtLXUJsXAmuMc Message-ID: To: Rajneesh Kumar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Modifying "arp" command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 08:18:00 -0000 Hi Rajneesh, On Sat, Dec 31, 2011 at 00:12, Rajneesh Kumar wrote: > I want to modify the "arp" command in FreeBSD. Precisely I don't want it = to > display the time to expire for every entry. Which file should I edit? Wil= l > it be effective after kernel compilation and re-build? The arp command is part of userland, not the kernel. It is a utility which runs from user-space and can be run from any running system. Unless your file system is embedded in your kernel, you shouldn't need to rebuild your kernel. For arp, since it is in /usr/sbin, the source is in src/usr.sbin/arp. The file arp.c is the one you want to edit. So check our that directory, or go to it in your existing checkout, and edit arp.c. Run "make" to rebuild the arp binary. If you want to install it on your running system, do "make install" =E2=80=94 you have to do that as root, so use sudo or su first. You may want to send your changes to the list after you make them, as although this is a very simple change, it may be something the wider developer community would be interested, and could conceivably be committed. For example, if you added a new command line option to hide expiration times, or to make the output more machine-readable, or something of that sort, that might be of general utility. Good luck! Juli. From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 08:37:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EB9106566C for ; Sat, 31 Dec 2011 08:37:13 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DEF398FC08 for ; Sat, 31 Dec 2011 08:37:12 +0000 (UTC) Received: by werb13 with SMTP id b13so12749732wer.13 for ; Sat, 31 Dec 2011 00:37:11 -0800 (PST) Received: by 10.216.136.204 with SMTP id w54mr28831919wei.44.1325320631198; Sat, 31 Dec 2011 00:37:11 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Sat, 31 Dec 2011 00:36:50 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Sat, 31 Dec 2011 00:36:50 -0800 X-Google-Sender-Auth: dWmmugQNC0t3LvsBH9Eg9dsKKKE Message-ID: To: Rajneesh Kumar Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: Modifying "arp" command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 08:37:13 -0000 Hi Rajneesh, On Sat, Dec 31, 2011 at 00:31, Rajneesh Kumar wrote: > Hi Juli > > Thank You for the prompt reply. But I can't find any directory called > src/usr.sbin/arp > Also If I am trying to find the file arp.c using find command (i.e., find / > -name arp.c), its unable to locate any such file. It isn't in the kernel. Do you have anything other than the kernel checked out? What version of the source tree do you have checked out? How did you check it out? If you want just the arp command from head, you can do something like this: svn co http://svn.freebsd.org/base/head/usr.sbin/arp Then the arp sources will be in the arp subdirectory of your current directory. Beware that "make install" won't work in this case, as the variable BINDIR (the executable into which the binary is installed) is set up usr.sbin/Makefile.inc. You can either run your modified arp binary out of your current directory, install it by hand (copying it over your existing one) or set BINDIR when doing make install, like "sudo make install BINDIR=/usr/sbin", for example. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 11:27:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E1811065670 for ; Sat, 31 Dec 2011 11:27:13 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A8AAA8FC1F for ; Sat, 31 Dec 2011 11:27:12 +0000 (UTC) Received: by eaaf13 with SMTP id f13so18686221eaa.13 for ; Sat, 31 Dec 2011 03:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x/M9vzgGeYBbfoXngsw1VKRIvVRq6hqhjCGMlWdOKCA=; b=tsHblAVH6TQoXnu3PjVD5RgD90ktzsi7885SHRpfWDV7bBfSpcrh8Ixl7Q2eUvqMUz rhzLVAp7vdFXrG2v+zAqgdO4fPK249Vy2wlCKpM4Hkedo3iOT+G3mgsjAr/+d2YsDaw9 tAHWwB+VrunmlszDhYn00S/r3lBCRMVr3bCFs= Received: by 10.205.133.139 with SMTP id hy11mr3969396bkc.98.1325330831485; Sat, 31 Dec 2011 03:27:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.17 with HTTP; Sat, 31 Dec 2011 03:26:30 -0800 (PST) In-Reply-To: <4EFAE551.8040101@gmx.com> References: <4EF038B9.5050203@gmx.com> <4EF18D7D.1050609@gmx.com> <4EF61535.4030507@gmx.com> <4EF8394F.8050108@gmx.com> <4EFAE551.8040101@gmx.com> From: saeedeh motlagh Date: Sat, 31 Dec 2011 14:56:30 +0330 Message-ID: To: Nikos Vassiliadis , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Lunev , Alireza Torabi Subject: Re: vlan without ip address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 11:27:13 -0000 thank you guys for your answers but my problem is not solved yet:(( the thing is, i wanna have something like this: a freebsd box which acts like switch (for example cisco 2960). i want to define vlanX on one interface (without any ip address) and it tags any passing packets through that interface as vlanX (any passing packet will have vlanX ID). i've tried bridging interfaces (to simulate vlan ports) but its problem is that it doesn't perform any vlan tagging. i've also tried defining vlan as sub-interface. but problem is, it doesn't tag every passing packets on real interface (it only works if we set ip address for vlan, and then it just tags packets which their destination is ip address of vlan sub-interface) does anyone knows what should i do? Cheers. to me, the most important thing is that i is to vlan tagging while configure vlans without any ip addresses. is it possible? From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 16:05:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14E89106564A for ; Sat, 31 Dec 2011 16:05:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B01CC8FC13 for ; Sat, 31 Dec 2011 16:05:08 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so19974882vcb.13 for ; Sat, 31 Dec 2011 08:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kH9wAdJoTob92AHOamMbKk/S3MHXUqq/8e2E+m05xzo=; b=JVRHaRAwtVa94EgFIm7z5Ka9zMDxgVj0KLxGk83kGVO1SzmgFkKfdy/C2jBNAPHu8d 8orq1W35CI127/RyLZmnPItmeMkRWbkUumMeN3UIPtwAfv80XX3xPpMPPUOkhmuyqwFW /6b2a50JZE/cgdsG4+0xuLhcAeTPAbujEx98U= MIME-Version: 1.0 Received: by 10.220.213.137 with SMTP id gw9mr24812160vcb.3.1325347507950; Sat, 31 Dec 2011 08:05:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Sat, 31 Dec 2011 08:05:07 -0800 (PST) In-Reply-To: References: <4EF038B9.5050203@gmx.com> <4EF18D7D.1050609@gmx.com> <4EF61535.4030507@gmx.com> <4EF8394F.8050108@gmx.com> <4EFAE551.8040101@gmx.com> Date: Sat, 31 Dec 2011 08:05:07 -0800 X-Google-Sender-Auth: ok6eWoa6ExkmD2V3sJysDZ7Cs1k Message-ID: From: Adrian Chadd To: saeedeh motlagh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Alexander Lunev , Nikos Vassiliadis , Alireza Torabi Subject: Re: vlan without ip address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 16:05:09 -0000 This has worked for me in the past. Have you disabled all the hardware vlan and ip offload options on those interfaces? You should be able to use tcpdump on the parent interfaces to see if the tagged packets are going in/out. Adrian From owner-freebsd-net@FreeBSD.ORG Sat Dec 31 22:31:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3123F106566C for ; Sat, 31 Dec 2011 22:31:11 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB2538FC0A for ; Sat, 31 Dec 2011 22:31:10 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so14061229wib.13 for ; Sat, 31 Dec 2011 14:31:09 -0800 (PST) Received: by 10.180.20.18 with SMTP id j18mr95462511wie.20.1325370669294; Sat, 31 Dec 2011 14:31:09 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Sat, 31 Dec 2011 14:30:48 -0800 (PST) In-Reply-To: References: <4EF038B9.5050203@gmx.com> <4EF18D7D.1050609@gmx.com> <4EF61535.4030507@gmx.com> <4EF8394F.8050108@gmx.com> <4EFAE551.8040101@gmx.com> From: Juli Mallett Date: Sat, 31 Dec 2011 14:30:48 -0800 X-Google-Sender-Auth: y8D_poUZwLFwRfWTPEl7FwRRAic Message-ID: To: saeedeh motlagh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Alexander Lunev , Nikos Vassiliadis , Alireza Torabi Subject: Re: vlan without ip address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 22:31:11 -0000 On Sat, Dec 31, 2011 at 03:26, saeedeh motlagh wrote: > thank you guys for your answers but my problem is not solved yet:(( > > the thing is, i wanna have something like this: > a freebsd box which acts like switch (for example cisco 2960). i want to > define vlanX on one interface (without any ip address) and it tags any > passing packets through that interface as vlanX (any passing packet will > have vlanX ID). Did you see my previous message about VLAN interfaces in FreeBSD not being like the VLANs one can define in a switch? You do not need the interface to add any tag to incoming packets, if that is what you are saying. Have you tried just bridging the interfaces without VLANs to see if that does what you want? You may also be adding the VLAN in the wrong place. If you create an interface em0.4, which is tagged VLAN 4 on em0, then any incoming packet on em0 which has a VLAN tag of 4 will appear on em0.4. If you send any packets on em0.4, then they will be sent out em0 with a VLAN tag of for VLAN 4 added. Is that what you want? It may be helpful for you to draw us a diagram. Use specific examples. Show an incoming packet. Does it have a VLAN tag? If so, what is the VLAN number? What is the name of the physical interface on which it arrives? Do you want that VLAN tag to be removed? Do you want another VLAN tag to be added? Do you want it bridged to another interface? If so, which interface? When it comes out that other interface, should it have a VLAN tag? If so, with what VLAN number? You've mentioned that you're using bridging, then you say you want switching, then you give a specific example of a switch you want FreeBSD to act like. FreeBSD will not act like that switch. You may be able to accomplish the same thing, but the performance, configuration and operation will be different. If you want FreeBSD to act exactly like a Cisco switch with a few lines in rc.conf, then you should probably stop now, FreeBSD is the wrong tool for the job. If, however, you can be very specific about what it is you want to do, instead of just repeating the same things about switches and VLANs, then we might be able to help you do it with FreeBSD. We'd all very much like to, but what you're trying to do is not clear. Forget all about what the VLAN interfaces are named, forget all about IP addresses, and tell us what you want to do. Thanks, Juli.