From owner-freebsd-ipfw@FreeBSD.ORG Sun Dec 25 15:00:35 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Sun Dec 25 15:36:37 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Sun Dec 25 17:47:29 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E524B106566B for ; Sun, 25 Dec 2011 17:47:29 +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 9B2F98FC0C for ; Sun, 25 Dec 2011 17:47:29 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1ResAS-000BXM-Qk for freebsd-ipfw@freebsd.org; Sun, 25 Dec 2011 18:47:28 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 17:47:30 -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-ipfw@FreeBSD.ORG Sun Dec 25 18:18:47 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Sun Dec 25 18:56:39 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Sun Dec 25 19:20:39 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Sun Dec 25 19:37:12 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B63411065675; Sun, 25 Dec 2011 19:37: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 6A79E8FC1B; Sun, 25 Dec 2011 19:37:12 +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: Jason Hellenthal , "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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 19:37:12 -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-ipfw@FreeBSD.ORG Sun Dec 25 19:45:10 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA3C106566B for ; Sun, 25 Dec 2011 19:45:10 +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 EECDA8FC0C for ; Sun, 25 Dec 2011 19:45:09 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Reu0L-000DPW-77 for freebsd-ipfw@freebsd.org; Sun, 25 Dec 2011 20:45:09 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 19:45:10 -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-ipfw@FreeBSD.ORG Mon Dec 26 11:07:09 2011 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C20871065680 for ; Mon, 26 Dec 2011 11:07:09 +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 AF5C18FC08 for ; Mon, 26 Dec 2011 11:07: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 pBQB79kR022524 for ; Mon, 26 Dec 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQB79K8022522 for freebsd-ipfw@FreeBSD.org; Mon, 26 Dec 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Dec 2011 11:07:09 GMT Message-Id: <201112261107.pBQB79K8022522@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 11:07:09 -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/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o f kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 40 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Dec 27 00:54:42 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D33106566C for ; Tue, 27 Dec 2011 00:54:42 +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 5483B8FC0A for ; Tue, 27 Dec 2011 00:54:42 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfLJQ-000EF1-No for freebsd-ipfw@freebsd.org; Tue, 27 Dec 2011 01:54:40 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 00:54:42 -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-ipfw@FreeBSD.ORG Tue Dec 27 11:37:15 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Tue Dec 27 12:43:40 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F7691065673; Tue, 27 Dec 2011 12:43:40 +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 5D3E68FC08; Tue, 27 Dec 2011 12:43:40 +0000 (UTC) Received: by iadj38 with SMTP id j38so24755102iad.13 for ; Tue, 27 Dec 2011 04:43:39 -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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 12:43:40 -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-ipfw@FreeBSD.ORG Tue Dec 27 14:01:08 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F8CB106564A for ; Tue, 27 Dec 2011 14:01:08 +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 2DAB38FC15 for ; Tue, 27 Dec 2011 14:01:08 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXaV-00060p-Cd for freebsd-ipfw@freebsd.org; Tue, 27 Dec 2011 15:01:07 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:01:08 -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-ipfw@FreeBSD.ORG Tue Dec 27 14:09:22 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Tue Dec 27 14:12:43 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D3F106566C for ; Tue, 27 Dec 2011 14:12: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 B4D728FC17 for ; Tue, 27 Dec 2011 14:12:42 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXlh-0006Kh-Uo for freebsd-ipfw@freebsd.org; Tue, 27 Dec 2011 15:12:41 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:12:43 -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-ipfw@FreeBSD.ORG Tue Dec 27 14:18:17 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF80106564A for ; Tue, 27 Dec 2011 14:18:17 +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 182EC8FC13 for ; Tue, 27 Dec 2011 14:18:16 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RfXr6-0006PG-3U for freebsd-ipfw@freebsd.org; Tue, 27 Dec 2011 15:18:16 +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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 14:18:17 -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-ipfw@FreeBSD.ORG Tue Dec 27 14:25:10 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Tue Dec 27 21:58:16 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Tue Dec 27 22:05:06 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 06:26:49 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 06:28:49 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 06:29:50 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBB9106566B for ; Wed, 28 Dec 2011 06:29:50 +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 5217C8FC14 for ; Wed, 28 Dec 2011 06:29:50 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so16797185vbb.13 for ; Tue, 27 Dec 2011 22:29:49 -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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:29:50 -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-ipfw@FreeBSD.ORG Wed Dec 28 07:00:22 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CD4E106567A; Wed, 28 Dec 2011 07:00:22 +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 29E8A8FC0A; Wed, 28 Dec 2011 07:00:07 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so10636120wib.13 for ; Tue, 27 Dec 2011 23:00:07 -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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 07:00:22 -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-ipfw@FreeBSD.ORG Wed Dec 28 07:04:25 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 10:04:19 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 10:26:12 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 13:19:52 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 15:57:31 2011 Return-Path: Delivered-To: freebsd-ipfw@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-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: IPFW Technical Discussions 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-ipfw@FreeBSD.ORG Wed Dec 28 23:18:53 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CBF106566B; Wed, 28 Dec 2011 23:18:53 +0000 (UTC) (envelope-from alancyang@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 61F9F8FC12; Wed, 28 Dec 2011 23:18:52 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so22591837wgb.31 for ; Wed, 28 Dec 2011 15:18:51 -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=v6lQyIQcad3dwkzO6BnbcG/VTvXnHzwMXMmXmq8+6CA=; b=ECT0mu15dxmtiUF+VWhyx8RB1tuwFWBEOvMYPV+sncHyRoceVp9Brp6AhejNU8PWHW vU/H+MGSmVfsS9GNjxV0WYai247LQfDYiBjMi6HFwvpAsF/ZNLxEf1xcHzG4lKTf5UC3 Ytft3hzkT4BoNyorTpr8pQ5+e0d8DWvdBu4rw= MIME-Version: 1.0 Received: by 10.227.60.68 with SMTP id o4mr4565833wbh.22.1325114331314; Wed, 28 Dec 2011 15:18:51 -0800 (PST) Received: by 10.216.167.13 with HTTP; Wed, 28 Dec 2011 15:18:51 -0800 (PST) In-Reply-To: References: <4EDE2739.1040104@FreeBSD.org> <20111208132002.R16498@sola.nimnet.asn.au> <20111209021345.Y11090@sola.nimnet.asn.au> <20111220153458.I64681@sola.nimnet.asn.au> Date: Wed, 28 Dec 2011 15:18:51 -0800 Message-ID: From: alan yang To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ian Smith , araujo@freebsd.org, Sergey Matveychuk Subject: Re: ipfw dscp support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 23:18:53 -0000 > > reading ipfw-classifyd divert socket sendto() with packet sin_port set > to flow->if_fwrule (ftp =3D=3D 1000 for instance), was expecting ipfw > would continue with next rule which is 1010 in above. =A0But ipfw seems > to have continue with matching rule 500. > with further looking, divert and ipfw rule processing work as documented in man page. sorry about above confusion.